인텐트 기반 네트워킹(IBN)과 의도 기반 네트워크 운영

1. 개요

가. 정의

인텐트 기반 네트워킹(Intent-Based Networking, IBN) 은 운영자가 네트워크에 바라는 목표·요구·제약을 선언적으로 표현하면, 시스템이 이를 실행 가능한 정책과 구성으로 변환·적용하고 관측 데이터로 목표 달성 여부를 지속 검증하는 폐루프 네트워크 운영 방식이다.

IBN의 중심 전환은 장비별 명령을 사람이 직접 작성하는 방식에서 업무 목표를 먼저 표현하는 방식으로의 이동이다. 운영자는 “어떤 경로를 몇 홉으로 설정하라” 대신 “업무망의 결제 트래픽은 지연 20ms 이하, 가용성 99.99%를 유지하고 인터넷에서 접근하지 못하게 하라”와 같이 원하는 결과를 기술한다. 시스템은 목표를 네트워크의 실제 토폴로지, 자원, 정책, 장비 기능과 대조해 실행 계획을 만들고, 변경 뒤에도 결과가 유지되는지 확인한다.

따라서 IBN은 단순한 자연어 명령 인터페이스나 자동 구성 스크립트가 아니다. 자연어는 요구를 입력하는 보조 수단일 수 있지만, 실행 전에는 모호성을 제거하고 검증 가능한 모델로 정규화해야 한다. 또한 자동화가 장비에 설정을 쓰는 순간 끝나는 것이 아니라, 텔레메트리로 실제 상태를 측정하고 목표와 차이를 판별하는 보증(assurance) 단계까지 포함해야 한다.

3GPP는 인텐트를 “달성 방법을 지정하지 않고 시스템에 주는 요구·목표·제약을 포함하는 기대사항의 집합”으로 정의한다. 이 정의에서 핵심은 무엇(what) 을 달성할지와 어떻게(how) 구현할지를 분리하는 것이다. IBN은 통신망에서 개념이 구체화되었지만, 데이터센터·기업 캠퍼스·클라우드 네트워크의 정책과 서비스 수준 관리에도 적용할 수 있다.

나. 등장 배경과 필요성

기업 네트워크는 온프레미스 데이터센터, 퍼블릭 클라우드, 지사, 모바일 사용자, 5G, IoT가 결합한 다중 도메인 환경으로 복잡해졌다. 장비마다 CLI와 설정 모델이 다르고 변경이 연쇄적으로 연결되어, 숙련된 운영자도 전체 영향 범위와 의존성을 한눈에 파악하기 어렵다. 장비 수가 늘어날수록 반복 설정·변경 검증·장애 조사에 투입되는 시간도 증가하며, 수작업은 구성 편차와 인적 오류를 누적시킨다.

기존 자동화는 정해진 순서의 명령을 빠르게 실행하는 데 유용하지만, 실행 뒤에 업무 목표가 실제로 달성됐는지는 별도로 판단해야 한다. 반면 IBN은 목표를 정책으로 해석하고, 실제 관측 결과가 목표에서 벗어나면 원인을 분석해 수정 계획을 제안하거나 제한된 범위에서 자동 조치한다. 이때 사람의 검토와 승인, 변경 이력 및 롤백은 완전 자율화 여부와 무관하게 통제 장치로 남아야 한다.

IBN은 소프트웨어 정의 네트워킹(SDN)의 제어·데이터 평면 분리와 프로그래머빌리티를 활용하지만 SDN과 동의어는 아니다. SDN은 네트워크를 소프트웨어로 제어할 수 있게 하는 기반 구조이고, IBN은 그 기반 위에서 비즈니스 요구를 표현·실현·보증하는 운영 모델에 가깝다. 즉 SDN은 “제어할 수 있는 능력”을, IBN은 “원하는 결과를 지속적으로 충족시키는 관리 방식”을 강조한다.

다. 핵심 특성

• 목표 중심성: 장비별 절차보다 서비스 품질·접근성·보안 등 결과를 중심으로 기술한다.
• 추상화와 번역: 업무 용어를 네트워크 객체·정책·구성으로 변환하고 구현 세부사항을 감춘다.
• 검증 가능성: 인텐트는 측정 지표, 적용 범위, 조건과 제약을 가져야 한다.
• 폐루프 운영: 실행 후 관측과 평가를 반복해 목표 상태와 실제 상태의 차이를 줄인다.
• 정책 일관성: 다수 장비와 도메인에 정책을 일관되게 배포하고 충돌을 탐지한다.

이 특성은 모두 상호의존적이다. 측정할 수 없는 목표는 보증할 수 없고, 구체적인 범위와 제약이 없는 목표는 번역 단계에서 잘못 해석될 수 있다. 반대로 실행 권한만 광범위하게 부여하고 안전장치를 두지 않으면 자동화의 속도가 장애와 보안 사고의 확산 속도를 높일 수 있다.

2. IBN 참조 아키텍처와 폐루프

IBN은 사람·업무 시스템의 요구를 받아 네트워크 정책과 장비 동작으로 연결하고, 결과를 다시 상위 요구와 대조하는 계층형 구조로 설명할 수 있다. 논리적 기능은 번역(translation), 실행·활성화(activation), 보증(assurance)의 세 축으로 구분되며, 실제 구현은 하나의 컨트롤러 또는 여러 관리 시스템으로 분산될 수 있다. 아래 그림은 인텐트가 정책·구성으로 바뀌고 관측 결과가 보증 기능으로 되돌아오는 기본 경로를 나타낸다.

flowchart LR
  U["업무 사용자·운영자"] --> I["인텐트 모델<br/>요구·목표·제약"]
  I --> T["번역·충돌·실현가능성 검증"]
  T --> P["정책·변경 계획"]
  P --> O["오케스트레이터·컨트롤러"]
  O --> A["도메인 어댑터<br/>API·NETCONF·CLI"]
  A --> N["라우터·스위치·방화벽·클라우드망"]
  N --> M["텔레메트리·로그·성능 지표"]
  M --> Q["보증·편차 분석"]
  Q --> I

인텐트 소비자는 서비스 소유자, 네트워크 운영자, 애플리케이션 또는 상위 관리 시스템이다. 소비자는 네트워크 세부 구성을 직접 지정하는 대신 대상 서비스, 품질 목표, 적용 범위, 유효기간, 보안 제약을 제공한다. 업무 담당자가 표현한 목표를 그대로 운영에 넣기보다는 네트워크 담당자와 서비스 수준을 합의하고 측정 가능한 정의로 바꾸어야 한다.

인텐트 모델과 번역 기능은 요청을 기계가 해석할 수 있는 구조로 정규화한다. 번역 기능은 대상 객체와 지표를 찾고, 누락된 값이나 상충 조건을 탐지하며, 지원되는 기능과 자원을 바탕으로 실현 가능성을 판단한다. 요구가 불가능하거나 서로 충돌하면 조용히 일부를 무시하지 않고, 충돌 항목과 가능한 대안 또는 협상 가능한 목표값을 사용자에게 보고해야 한다.

정책·계획 생성과 오케스트레이션은 목표 상태에 도달하기 위한 변경을 도메인별 실행 단계로 분해한다. 예를 들어 “지점의 결제 시스템만 내부 애플리케이션에 접근”이라는 목표는 주소 그룹, 방화벽 규칙, 라우팅, 인증 정책으로 세분될 수 있다. 계획 단계에서는 의존성, 영향 범위, 자원 부족, 변경 순서, 사전·사후 점검과 보상 동작을 함께 고려해야 한다.

도메인 어댑터와 네트워크 자원은 추상 정책을 장비별 또는 클라우드 사업자별 인터페이스로 전달한다. 어댑터는 REST API, 모델 기반 관리 인터페이스, 장비별 API 등 이기종 수단을 추상화하지만, 기능 차이를 완전히 없애지는 못한다. 따라서 기능 카탈로그와 어댑터 버전, 지원 범위, 오류 처리 방식의 수명주기를 관리해야 멀티벤더 환경에서 결과의 일관성을 유지할 수 있다.

보증 기능은 관리 시스템의 구성 상태만 읽는 데 그치지 않고 실제 패킷 손실, 지연, 가용성, 도달성, 보안 이벤트 등 서비스 관점의 지표를 수집한다. 목표와 실제 지표의 차이, 정책 적용 여부, 데이터의 신선도와 신뢰도를 함께 분석해 목표 충족 상태를 보고한다. 편차가 발견되면 재계산·알림·승인 요청·자동 수정 중 사전에 정한 대응을 수행하고, 수정 후 다시 검증한다.

이 구조에서 중요한 원칙은 설정의 의도 상태(desired state) 와 관측된 실제 상태(observed state) 를 구별하는 것이다. 컨트롤러에 정책이 등록되어 있어도 장비가 이를 수용하지 않았거나 트래픽 경로가 우회되었다면 서비스 결과는 목표와 다를 수 있다. 따라서 보증은 구성 확인과 서비스 결과 검증을 함께 사용하고, 각 결과에 증거·시간 정보·신뢰 수준을 연결해야 한다.

3. 인텐트 모델과 수명주기

가. 인텐트의 구성 요소

인텐트는 자연어 문장 하나가 아니라 적용 범위와 평가 방법을 가진 구조화된 기대사항이다. 일반적으로 대상 객체(object), 기대사항(expectation), 목표(target), 값 또는 조건(condition), 적용 맥락(context), 제약(constraint)을 구분해 표현한다. 예를 들어 “서울 본사의 결제 서비스에 대해 업무시간 중 왕복 지연을 20ms 이하로 유지하고, 외부 인터넷에서 직접 접근하지 못하게 한다”는 대상·시간 범위·성능 목표·보안 제약을 포함한다.

대상 객체는 인텐트가 적용될 네트워크·서비스·단말·구역·슬라이스를 식별한다. 대상을 명확하게 지정하지 않으면 정책이 필요 이상 넓은 범위에 적용되거나, 일부 장비만 대상으로 삼아 서비스 경로가 불완전해질 수 있다. 객체 식별에는 고정 ID뿐 아니라 태그나 위치·역할 등의 맥락 조건이 쓰일 수 있으며, 조건이 바뀔 때 대상 집합이 어떻게 변하는지 평가해야 한다.

목표와 기대사항은 달성하고자 하는 결과와 이를 판정하는 지표를 나타낸다. “빠르게” 또는 “안전하게” 같은 표현만으로는 판정이 불가능하므로 지연 상한, 가용성, 허용 손실, 접근 허용 목록과 같은 수치·정책으로 구체화한다. 단, 단일 지표를 과도하게 최적화하면 비용·복원력·보안 같은 다른 목표를 훼손할 수 있으므로 상호 간 우선순위와 허용 범위를 함께 정의한다.

맥락과 제약은 목표가 유효한 조건을 설명한다. 시간대, 트래픽 유형, 위치, 용량 한도, 규제 구역, 정비 기간, 예산처럼 조건을 지정하면 같은 서비스라도 상황에 따라 다른 정책을 합리적으로 선택할 수 있다. 제약은 목표 달성 과정에서 넘지 말아야 할 경계이며, 예를 들어 “가용성 향상을 위해 비용을 무제한 증액하지 말 것”과 같은 운영 한도를 포함할 수 있다.

인텐트 보고서는 수락·실현 가능성·충족 상태·충돌·실패 원인과 달성된 지표를 소비자에게 전달한다. 요청을 받았다는 확인(acknowledgement)을 실제 목표 달성(fulfilled)과 혼동하지 않도록 상태 모델을 명확히 해야 한다. 보고서는 상위 계층의 조정과 감사에 사용되므로 목표 버전, 적용 범위, 관측 시간, 판단 근거를 보존해야 한다.

나. 관리 수명주기

실무 수명주기는 목표를 접수한 뒤 검증·실행·보증·변경·폐기까지 이어지는 반복 과정이다. 3GPP의 관리 서비스는 인텐트 생성·수정·삭제·조회, 활성화·비활성화, 보고서 조회·구독, 능력 조회와 실현 가능성 확인·협상 절차를 다룬다. 운영자는 이를 도입해 서비스 요구가 변경되거나 계절·이벤트 수요가 달라질 때 정책을 통제된 방식으로 갱신할 수 있다.

flowchart TD
  A["1. 업무 요구 수집"] --> B["2. 표현 정규화·범위 명시"]
  B --> C["3. 기능 탐색·실현 가능성 확인"]
  C -->|가능·협의 완료| D["4. 정책·변경 계획 생성"]
  C -->|불가·충돌| X["대안 제시·협상·승인"]
  X --> B
  D --> E["5. 위험·영향 검토와 승인"]
  E --> F["6. 단계적 활성화"]
  F --> G["7. 텔레메트리 기반 보증"]
  G -->|목표 충족| H["보고·지속 관찰"]
  G -->|편차·장애| R["조정·롤백·운영자 개입"]
  R --> D
  H -->|요구 변경·기간 종료| A

첫째, 요구 수집과 표현 정규화에서는 이해관계자 간 용어를 맞추고 인텐트의 대상, 지표, 시간 조건, 우선순위와 책임자를 식별한다. 입력 문장의 일부를 자동 분석하더라도 애매한 “최대한 빠르게”를 임의의 SLA로 바꾸지 말고, 추가 질문 또는 승인 절차를 요구해야 한다.

둘째, 능력 탐색과 실현 가능성 확인에서는 담당 도메인이 필요한 지표와 정책을 지원하는지, 자원과 장비가 목표를 감당할 수 있는지 확인한다. 실현 가능성은 단순한 문법 검사가 아니라 현재 상태와 다른 인텐트, 공유 자원, 안전·규제 제약을 고려한 판단이어야 한다. 목표가 현실적으로 달성 불가능하면 불가 사유와 조정 가능한 값 또는 대안을 제시하는 협상 과정이 필요하다.

셋째, 계획과 승인에서는 변경 순서, 영향 분석, 위험, 실패 시 복구 전략을 계산한다. 비즈니스 영향이 큰 경로의 경우 자동으로 계획을 작성하더라도 운영자 승인, 정비 시간대, 변경 관리 정책을 통과한 후에만 실행한다. 점진적 배포와 작은 영향 반경은 오류가 발생했을 때 전체 네트워크로 확산되는 위험을 줄인다.

넷째, 활성화와 지속 보증에서는 구성 적용 결과와 실제 서비스 성능을 함께 평가한다. 지표에 이상이 발생하면 조치를 자동 실행할 수 있지만, 조치 권한·변경 속도·재시도 횟수·중단 조건을 미리 제한해야 한다. 정책을 수정한 뒤에도 목표를 충족하는지 다시 측정하고, 불확실하거나 관측 자료가 부족하면 자동 조치보다 경보와 사람의 판단을 우선한다.

4. 운영 방식 비교와 설계 사례

전통적인 장비별 운영에서는 운영자가 구현 절차를 정하고 각 장비에 명령을 입력한다. 이 방식은 제어가 명시적이고 작은 환경에서 이해하기 쉽지만, 규모가 커지면 정책 불일치와 반복 작업이 늘어난다. 스크립트·구성 관리 도구는 실행을 자동화하지만, 사전 정의한 절차의 범위를 넘어서는 결과 검증과 목표 기반의 재조정은 별도 설계가 필요하다.

구분	장비별 명령·스크립트	SDN 기반 자동화	인텐트 기반 운영
입력 관점	장비 동작과 명령	네트워크 자원·정책	업무 목표·요구·제약
구현 책임	운영자가 절차 작성	컨트롤러가 추상화·배포	번역·계획·검증 기능이 연결
검증 수준	명령 성공 여부 중심	정책·구성 적용 여부 중심	목표 결과의 지속 충족 여부
피드백	사후 확인 또는 수작업	컨트롤러 상태와 이벤트	텔레메트리 기반 폐루프 보증
위험 요인	구성 편차·인적 오류	컨트롤러·도메인 종속	잘못된 목표 해석·과도한 자동화

IBN은 SDN을 대체하는 독립 프로토콜이라기보다 SDN 및 기존 관리 체계 위에 놓이는 결과 중심 운영 접근이다. 또한 정책 기반 관리, 구성 관리 자동화와 기능이 겹칠 수 있으므로 제품 이름만으로 IBN 도입 여부를 판단해서는 안 된다. 실제 적용에서 구분 기준은 선언된 목표가 기계 해석 가능한 구조를 가지는지, 실행 후 목표 충족을 측정하는지, 편차에 대한 통제된 피드백 경로가 있는지이다.

사례: 다지점 결제 서비스의 품질·보안 인텐트

금융회사가 지점과 클라우드에 분산된 결제 서비스를 운영한다고 가정한다. 업무 소유자는 “업무시간 동안 결제 애플리케이션 통신의 왕복 지연은 20ms 이하, 월 가용성 목표는 99.99%, 외부 인터넷에서 데이터베이스로 직접 접근 금지”라는 요구를 제시한다. 네트워크 팀은 이를 서비스 그룹·시간대·측정 구간·지표로 구조화하고, 지연과 가용성의 산정 방식, 허용 예외, 데이터베이스 접근 경로를 명시한다.

번역 기능은 WAN 경로, 클라우드 보안 그룹, 방화벽 정책, 서비스 태그와 현재 대역폭을 검토해 실행 계획을 만든다. 현재 링크가 혼잡하여 목표가 실현 불가능하면, 다른 경로 사용, 대역폭 확장, 목표값 조정 중 선택 가능한 방안을 보고하고 소유자의 승인을 받는다. 승인된 변경은 한 지점에서 먼저 검증한 뒤 나머지 지점으로 확대하고, 각 단계에서 결제 지연과 연결 성공률을 확인한다.

운영 중 텔레메트리가 지연 목표 초과와 특정 방화벽 규칙의 우회 가능성을 함께 발견하면, 성능 조정과 보안 차단을 하나의 변경으로 무리하게 결합하지 않는다. 먼저 원인과 정책 충돌을 분류하고, 서비스 연속성에 미치는 영향을 평가한 뒤 제한된 우회 경로 또는 승인된 롤백을 적용한다. 이 사례는 목표를 하나의 문장으로 선언하는 것보다, 목표의 측정·충돌 해결·승인·증거 보존이 IBN의 신뢰성을 좌우한다는 점을 보여준다.

비교: 네트워크 슬라이싱과 IBN

네트워크 슬라이싱은 물리 인프라 위에 서비스 특성별 논리 네트워크를 제공하는 자원 분할·서비스 제공 기술이다. IBN은 요구를 표현하고 그 네트워크가 바라는 결과를 내도록 구성·관찰·조정하는 관리 방식이다. IBN이 슬라이스에 요구를 전달하고 슬라이스 관리가 이를 구체적인 자원으로 구현할 수 있으므로, 양자는 경쟁 개념이 아니라 상하위 수준에서 결합될 수 있다.

5. 심화: 표준화, 자동화 수준과 한계

IBN이라는 용어는 산업계에서 널리 사용되지만 모든 공급자가 동일한 정보 모델과 동작을 제공하는 단일 범용 규격이 완성되었다고 단정해서는 안 된다. 네트워크 장비의 기능, 인텐트 표현, 보고서, 충돌 처리 및 자동 수정 범위는 제품과 도메인에 따라 차이가 있다. 따라서 제품의 마케팅 명칭보다 데이터 모델, API, 상호운용성, 감사 기능, 자동화 권한과 실제 성과 측정 기준을 확인해야 한다.

통신 분야에서는 3GPP TS 28.312가 이동 네트워크의 인텐트 기반 관리 서비스와 인텐트 수명주기·보고·능력 조회·협상 절차를 규정한다. 3GPP 모델은 관리 서비스 소비자와 생산자, 인텐트 기대사항, 인텐트 처리 기능과 보고서를 구분해 네트워크 도메인 간 관리 인터페이스를 구조화한다. 2026년 9월 확인 기준 3GPP 공식 기술 페이지는 TS 28.312의 최신 버전을 V19.1.0으로 표기하므로, 설계·조달 시 적용 Release와 개정판을 공식 페이지에서 다시 확인해야 한다. 3GPP와 별도로 TM Forum은 자율 네트워크의 인텐트 개념, 공통 모델, 수명주기와 관리 API 작업을 발전시키고 있어 관련 규격의 범위와 버전을 구분해 읽어야 한다.

상용 구현의 자율성은 단계적으로 확장하는 것이 바람직하다. 초기에는 인텐트 수집·검증·영향 분석과 변경 계획 생성에 집중하고, 운영자가 검토한 뒤 적용하는 사람-승인형 방식으로 위험을 낮춘다. 측정 데이터와 정책 품질이 검증되면 저위험 작업부터 제한된 자동 실행을 허용하고, 고영향 작업은 승인·롤백·중단 조건을 유지한다.

폐루프 제어의 안정성은 네트워크 제어의 지연과 관측 주기에 영향을 받는다. 너무 빠른 보정은 상태가 충분히 관측되기 전에 반복 변경을 유발해 진동(oscillation)을 만들 수 있고, 너무 느린 보정은 SLA 위반을 오래 방치할 수 있다. 따라서 히스테리시스, 안정화 시간, 변화율 제한, 재시도 한도와 조치별 쿨다운을 두고 실제 환경에서 부하·장애 조건을 시험해야 한다.

6. 고려사항 및 시사점

• 목표의 측정 가능성과 모호성 제거: 업무 표현을 수치·범위·시간·대상·예외로 분해한다. 측정 정의가 부서마다 다르면 대시보드가 녹색이어도 실제 서비스 요구를 충족하지 못할 수 있다.
• 충돌 및 공유 자원 관리: 인텐트 간 우선순위, 자원 경쟁, 정책 상충과 위임 범위를 명시한다. 불가능한 목표는 조용히 무시하지 말고 근거와 협상 대안을 보고해야 한다.
• 변경 안전성과 인간 통제: 영향 분석, 승인 게이트, 점진 배포, 롤백, 중단 스위치와 감사 로그를 구현한다. 자동화 수준은 업무 영향과 복구 가능성에 맞춰 차등화한다.
• 보증 데이터 품질: 텔레메트리의 완전성·정확성·시간 동기화·수집 지연을 관리한다. 데이터가 없다는 사실을 목표 충족으로 간주하지 말고 관측 불능 상태를 별도로 표시한다.
• 멀티벤더 상호운용성: 기능 카탈로그, 공통 객체 모델, 인터페이스 버전과 예외 처리를 검증한다. 추상화 계층이 벤더별 차이를 감추는 대신 숨은 제약을 드러내도록 설계한다.
• 보안·권한·책임성: 인텐트 소비자와 실행 주체를 인증하고 역할 기반 권한, 최소 권한, 정책 서명, 비밀정보 보호와 불변 감사 기록을 적용한다. 목표 입력 경로가 침해되면 정당한 자동화가 공격 수단으로 바뀔 수 있다.
• 성과 지표와 투자 효과: 배포 속도뿐 아니라 변경 실패율, MTTR, SLA 충족률, 구성 편차, 자동 복구의 재발률과 운영자 개입 시간을 함께 측정한다. 기술 도입 자체를 자율성의 성과로 오인하지 않는다.
• 점진적 도입과 운영역량: 관측성·정책 관리·구성 자동화부터 성숙시킨 뒤 도메인 하나와 저위험 사례에서 검증한다. 네트워크·보안·애플리케이션 팀이 공동으로 목표와 책임을 정의해야 지속적으로 운영할 수 있다.

기술사 관점에서 IBN은 SDN, 네트워크 자동화, AIOps, 폐루프 제어와 자율 네트워크를 연결하는 목표 중심 운영 패러다임이다. 성공 여부는 인공지능의 도입 여부보다 업무 목표의 정형화, 신뢰 가능한 관측, 안전한 변경 관리와 책임 구조에 의해 결정된다. 따라서 도입 로드맵은 “완전 자율화”라는 단일 목표보다 측정 가능한 서비스 개선과 통제 가능한 자동화 범위를 단계별로 제시해야 한다.

참고자료

• 3GPP, Intent Driven Management: https://www.3gpp.org/technologies/intent-management
• 3GPP TS 28.312, Intent driven management services for mobile networks (ETSI TS 128 312 V18.8.0): https://www.etsi.org/deliver/etsi_ts/128300_128399/128312/18.08.00_60/ts_128312v180800p.pdf
• TM Forum, Intent-based Automation: https://www.tmforum.org/learn/topics/intent-based-automation/
• Cisco, Intent-Based Networking: https://www.cisco.com/site/us/en/solutions/intent-based-networking/index.html

---

한 줄 요약: IBN은 네트워크에 원하는 목표와 제약을 선언하고 이를 정책·구성으로 실현한 뒤 실제 서비스 지표로 지속 검증하는 폐루프 운영 방식이며, 측정 가능한 인텐트·안전한 자동화·신뢰할 관측성이 성패를 좌우한다.