글로벌 연결의 초석인 통신 산업은 5G, IoT, 클라우드 컴퓨팅, AI와 같은 혁신에 힘입어 한동안 기술 르네상스를 맞이하고 있습니다. 결과적으로 네트워크를 관리하는 것이 점점 더 어려워졌습니다. 일상적인 작업을 처리하고, 네트워크 상황을 모니터링하고, 실시간으로 문제에 대응하기 위해서는 자동화가 필요합니다. 그러나 통신 서비스 공급자(CSP)의 기존 기술은 이 환경의 변화하는 요구 사항에 부합하지 않을 수 있습니다. 현대 시대에 성공하기 위해 CSP는 데이터 해석 및 운영을 위한 데이터 과학자, 공급업체 API(애플리케이션 프로그래밍 인터페이스)를 통한 자동화를 위한 소프트웨어 개발자, 서비스 안정성을 보장하기 위한 폐쇄 루프를 설계하는 서비스 보증 엔지니어를 포함한 다재다능한 팀이 필요합니다.
CSP는 다양한 경험을 가진 팀을 구성하여 격차를 해소하는 동시에 동시대의 트렌드에 대한 상당한 발전의 혜택을 누리고 있습니다. 프로그래밍 언어는 로우코드/노코드 패러다임으로 발전해 왔으며, 생성형 AI의 등장으로 기본 모델이 작업에 대한 자연어 설명을 기반으로 공식 코드를 생성할 수 있는 시점에 이르렀습니다. 이를 통해 관리자가 '의도'라는 자연어로 높은 수준의 네트워크 목표를 표현하고 이러한 인간의 의도가 네트워크 정책 및 구성으로 자동 변환되는 의도 기반 네트워킹(IBN) 개념에 새로운 관점을 부여할 수 있었습니다. IBN은 네트워크 관리를 개선할 수 있는 잠재력을 가지고 있으며 통신사 내 인재 격차를 해결하는 데 있어 게임 체인저가 될 수 있습니다. 한 걸음 더 나아가 자율 네트워크(AN)는 의도를 입력으로 활용하여 네트워크의 조건이 변화함에 따라 자율적으로 자체 구성, 자체 최적화 및 자체 치유를 약속합니다.
IBN과 AN의 밝은 미래를 상상할 수 있지만, 의도의 표현, 네트워크 구성에 대한 정확한 번역, 시스템 투명성 및 복잡성 등 실현 가능성과 프로그램 적용에 대한 지속적인 우려가 존재합니다. 이 블로그에서는 실제 적용 가능성이 있는 영역을 자세히 살펴보고 그 과정에서 직면할 수 있는 문제를 분석합니다.
CSP 팀과 네트워크 간의 상호 작용을 간소화해야 할 필요성을 이해하기 위해 새로운 서비스 배포를 예로 들어보겠습니다.
자율 네트워크 기술 아키텍처에 관한 TMF 소개 가이드 1230(IG1230)에 설명된 사양에 따라 CSP 네트워크 운영이 자동화되어 있다고 가정합니다. 이러한 맥락에서 CSP의 OSS에는 (1) 서비스 프로비저닝, 자동 프로비저닝 및 자동 테스트를 위한 오케스트레이터, (2) 데이터를 수집하고 네트워크 상태에 대한 통찰력을 생성하여 폐쇄 루프 제어의 맥락에서 데이터 기반 의사 결정을 용이하게 하는 네트워크 인벤토리가 있는 보증 시스템, (3) 사전 정의된 정책을 사용하여 네트워크 동작을 조정하여 광범위한 CSP의 정책과 일치하도록 보장하는 정책 관리자가 있습니다. 간단히 말해서, 자동화된 작업은 인간이 설계한 TOSCA 서비스 설명자, 구성, 정책 및 설계 시간 동안 서비스 설계자가 인텔리전스와 의사 결정을 추가하는 명령형 워크플로와 서비스의 긴밀한 결합을 중심으로 이루어집니다. 서비스 설계자는 네트워크에서 발생할 수 있는 다양한 상황을 사전에 예측하고 이에 대한 해결 방법을 상세히 안내해야 합니다. 미래의 상황을 예측하고 이를 처리할 정책이 있다면 제로 터치 경험은 달성됩니다.
서비스 설계, 서비스 인스턴스화, 서비스 보증 등 다양한 서비스 수명 주기 단계에 대해 각각 0일차, 1일차, 2일차라는 용어를 사용합니다.
그림 1: 0일 차 서비스 설계 프로세스 – 서비스 자산 설계
그림 2: 0일차/1일차/2일차 상호 작용
요약하자면, 이 설계 단계에서는 새로운 서비스에 대한 지침을 네트워크에 제공해야 하므로 상당한 양의 수작업이 필요합니다.
IBN에서 의도는 CSP가 네트워크에서 달성하고자 하는 높은 수준의 목표를 나타냅니다. 위에서 설명한 것처럼 0일차 작업 중에 복잡한 하위 수준 네트워크 구성을 처리하는 대신 엔지니어링 팀이 의도로 목표를 표현하면 의도를 뒷받침하는 논리가 의도를 의도 목표를 충족하는 필수 네트워크 구성으로 변환합니다.
애플리케이션을 네트워크에 적용한 후 AN은 배포된 서비스를 지속적으로 모니터링하고 구성을 조정하여 작업이 지정된 의도에 맞게 유지되도록 합니다. AN은 의도 사용을 2일차 작업으로 확장합니다.
다음으로, 의도가 의도 이전 시대부터 확립된 관행을 잠재적으로 혁신할 수 있는 몇 가지 측면을 제공합니다.
해결해야 할 두 가지 주요 과제가 있습니다.
TM 포럼에서는 높은 수준의 네트워크 의도를 정의하기 위한 구조화된 프레임워크를 제공하는 TMF921 의도 기반 네트워킹 API를 소개했습니다. TM 포럼에서는 의도를 "의도는 기술 시스템에 주어진 요구 사항, 목표 및 제약 조건을 포함한 모든 기대치를 공식적으로 명시한 것"으로 정의합니다. 그러나 부분 형식 사양은 네트워크 엔지니어가 의도 개념의 잠재력을 최대한 활용하기 위해 이 형식 언어에 익숙해져야 한다는 우려를 불러일으킵니다. 또한 형식 사양이 있는 의도가 반드시 제공되어야 하는 매개변수 수를 줄이는 것은 아닙니다. 이러한 측면은 일반적으로 IBN과 연관되는 예상되는 네트워크 관리 간소화에 도전합니다.
또한 의도 사양을 공식화함으로써 의도 해석 논리를 보유하는 IBN의 핵심 구성 요소인 의도 핸들러는 의도 공식 언어의 결정론적 인터프리터에 불과합니다. 문제는 의도 핸들러를 인간이 모든 잠재적인 네트워크 상태를 예측하고 해결을 위한 구체적인 지침을 제공할 필요가 없는 선언적 작동 방식을 갖춘 자율 시스템으로 발전시키는 방법에 관한 것입니다. 그렇지 않으면 시스템 운영을 자동화에서 자율로 성공적으로 전환할 수 없습니다(TMF IG1230).
향후 블로그에서는 IBN과 AN의 과제와 기회에 대해 더 자세히 다룰 예정입니다. 더 자세히 알아보고 싶으신가요?