AI가 Network Slicing 운영 자동화를 어떻게 바꾸는가

Closed loop와 AI는 같은 말이 아니다

Closed-loop automation은 관측 결과를 분석하고, 목표와 비교해, 조치를 결정·실행한 뒤 다시 결과를 확인하는 제어 구조다. 이 loop는 고정 threshold와 규칙만으로도 동작할 수 있다. AI/ML을 사용했다고 해서 모든 단계가 자동이 되는 것도 아니고, closed loop라고 해서 반드시 AI가 들어가는 것도 아니다.

3GPP TS 28.536은 communication service assurance의 closed control loop를 다루며 NetworkSlice 또는 NetworkSliceSubnet을 관리 대상으로 표현한다. service 또는 slice 상태를 관측하고, 요구 충족 여부를 분석하고, 필요한 조치를 결정하는 절차를 제시한다. 이것은 관리 기능과 정보 모델의 표준화 근거다. 특정 AI 모델의 정확도나 현재 상용 자율운영 성공을 증명하는 자료는 아니다.

ETSI ZSM 009-1은 closed-loop governance framework에서 loop의 시작·중지, policy·rule·trigger·priority, 상태와 성능, lifecycle을 관리하는 capability를 설명한다. delegation도 무제한 위임이 아니라 정해진 범위와 escalation condition 안에서 이뤄진다. 따라서 loop를 만든다는 것은 책임을 지우는 일이 아니라, 자동화가 움직일 수 있는 울타리와 예외 통로를 함께 만드는 일에 가깝다.

대체 설명 telemetry가 분석, 판단 또는 권고, 정책 실행, assurance를 거쳐 human exception loop로 이어지고, 사람이 중지·승인·수정·rollback한 결과가 다시 관측 범위와 정책에 반영되는 여섯 단계 흐름이다. 모바일에서는 위에서 아래 한 열로 읽힌다. 실제 3GPP·ETSI·O-RAN message sequence, 표준 interface, 상용 망 topology 또는 특정 통신사의 자동화 구성이 아니다.

• 1. Telemetry성능·장애·구성·서비스 상태와 측정 context를 수집한다.
• 2. 분석기준선과 목표를 비교하고 이상·상관관계·영향 후보를 좁힌다.
• 3. 판단/권고가능한 조치, 예상 영향, confidence와 근거를 운영자에게 제시한다.
• 4. 정책 실행승인된 권한·범위·시간·변경 규칙 안에서 조치를 적용한다.
• 5. Assurance같은 측정 정의로 결과와 부작용을 다시 확인하고 기록한다.
• 6. Human exception loop불확실·고위험·정책 밖 상황을 멈추고 승인·수정·rollback한다.

운영 단계마다 줄일 수 있는 부담과 남는 책임이 다르다

AI의 역할을 현실적으로 보려면 “자동화 가능/불가능” 두 칸보다 단계별로 나누는 편이 낫다. 아래 표의 ‘AI 지원 가능 범위’는 현재 모든 통신사 망에 보편 배포됐다는 뜻이 아니라, 표준과 framework가 관리 대상으로 다루는 기능 위에 세울 수 있는 제한된 적용 범위다.

이 표에서 가장 자동화하기 쉬운 일은 반복적이면서 입력과 결과가 비교적 명확한 일이다. 시간대·장소·slice·단말군별 지표를 정렬하고, 평소 baseline에서 벗어난 흐름을 표시하고, 관련 alarm과 최근 변경을 묶고, 이미 승인된 runbook 후보를 추천하는 일이다. 운영자가 여러 화면에서 수작업으로 모으던 context를 하나의 evidence bundle로 만드는 것만으로도 조사 시간을 줄일 수 있다.

반대로 목표가 모호하거나 결과를 되돌리기 어렵고 고객 영향이 큰 일은 자동 실행 범위를 좁혀야 한다. 모델이 “latency가 악화될 가능성”을 탐지할 수는 있어도, 어떤 측정점과 통계가 계약상 SLA 판정에 쓰이는지 스스로 정당화하지는 못한다. resource 조정을 추천할 수는 있어도 다른 slice와 public traffic에 미칠 영향을 감수할 권한까지 얻는 것은 아니다. 권고와 권한은 별개의 문제다.

Telemetry는 많다고 좋은 것이 아니라 해석 가능한 상태여야 한다

AI 분석의 출발점은 데이터 양보다 의미가 맞는 telemetry다. 같은 ‘latency’도 측정 시작점과 끝점, percentile, aggregation window, traffic class와 누락 처리에 따라 다른 값을 만든다. slice 식별자, service profile, resource 상태, change record, fault와 performance data의 시간 기준이 맞지 않으면 모델은 그럴듯한 상관관계를 내놓고도 실제 서비스 원인을 놓칠 수 있다.

3GPP TS 28.550은 Network Slice Instance(NSI), Network Slice Subnet Instance(NSSI), Network Function(NF)을 대상으로 management data analytics service가 필요한 measurement를 정하고 measurement job을 이용해 데이터를 수집·분석한 뒤 management analytical data를 제공하는 방식을 다룬다. 여기서 얻을 수 있는 근거는 관리 분석을 service·slice·subnet·function 수준에 연결할 수 있다는 점이다. 분석 결과가 자동으로 참이 되거나 곧바로 정책 실행 권한을 얻는다는 뜻은 아니다.

실제 운영에서는 raw telemetry와 모델 입력 사이에 data contract가 필요하다. 식별자와 단위, 시간 동기, sampling, retention, 결측치, training·inference 사용 허용 범위, 고객·단말 정보의 최소화와 접근 권한을 기록해야 한다. privacy와 보안은 모델 정확도를 높인 뒤 붙이는 부가 조건이 아니라 수집 단계의 설계 조건이다.

분석 결과는 결론보다 검토 가능한 권고에 가까워야 한다

이상 탐지는 “평소와 다르다”를 빠르게 찾는 데 강점이 있다. 여러 domain의 fault·performance·configuration 변화를 함께 보며 원인 후보를 순위화할 수도 있다. 하지만 correlation은 causation과 같지 않다. 최근 정책 변경과 KPI 저하가 함께 나타났다고 해서 그 변경이 유일한 원인이라고 단정할 수 없다.

따라서 권고에는 최소한 대상 slice와 영향 범위, 사용한 데이터 window, 관측된 변화, 비교한 기준, 제안 action, 기대 효과, 부작용, confidence, 실행 전 확인 조건이 붙어야 한다. 설명이 필요한 이유는 AI를 친절하게 보이게 하기 위해서가 아니다. 운영자가 승인·거부·수정할 수 있고, 나중에 같은 판단을 재구성할 수 있게 하기 위해서다.

3GPP TS 28.105는 5G System의 AI/ML model management를 다룬다. 공개 확인한 Release 19 문서에는 training, validation, testing, target network 적용 전 inference emulation, loading과 deployment, inference 활성·비활성, 허용 output 범위 설정, 성능 monitoring·evaluation, update trigger가 포함된다. 또 KPI 저하와 연관된 모델을 식별하고, 권한 있는 소비자가 informed decision·deactivation·fallback에 활용할 explainability output을 제공하는 항목이 있다. 즉 표준이 보여 주는 방향은 모델을 ‘한 번 넣고 믿는 도구’가 아니라 검증·활성·감시·비활성·교체할 관리 대상으로 보는 것이다.

문서 상태도 구분해야 한다. 3GPP portal에서 TS 28.105는 Technical Specification이며 Under Change Control 상태다. 2026년 8월 7일 확인 당시 portal 최신 목록은 Release 19 V19.6.0을 가리키지만, 이 글의 공개 clause 근거는 접근 가능한 ETSI TS 128 105 V19.5.0 PDF에 고정했다. 버전이 바뀌어도 “최신”이라는 말만 옮기지 말고 실제 사용 clause와 구현 profile을 다시 확인해야 한다.

정책 실행은 추천보다 훨씬 강한 권한이다

분석 모델이 action 후보를 내는 것과 network configuration을 바꾸는 것은 위험 수준이 다르다. 자동 실행을 허용한다면 대상 object, 허용 parameter, 변경 폭, 시간 window, 선행 condition, rate limit, 다른 slice의 보호 조건, 승인자, 관측 기간, rollback threshold를 policy로 고정해야 한다. 모델 output이 이 경계를 넘으면 실행하지 않고 exception으로 보내야 한다.

이 글의 중심은 AI가 어디까지 지원하고 누가 통제권을 유지하는가이다. 다구간 KPI·KQI의 측정 구조는 4편의 범위이고, 실제 incident 확대와 복구 절차는 9편의 범위다. 여기서는 AI가 정해진 정책 경계 안에서 권고·제한 실행을 보조한다는 원칙까지만 다룬다.

ITU-T Y.3172는 future network를 위한 ML architecture framework를 제시한다. ML sandbox, pipeline, multi-source data correlation, deployment와 output을 operator policy 아래 두는 구조가 포함된다. 이것은 Recommendation과 framework 수준의 근거다. 특정 사업자가 현재 Network Slicing을 완전자율로 운영한다는 배포 증거가 아니다. sandbox의 의미도 운영망 영향을 차단하거나 기능을 제한한 상태에서 검증하라는 데 있다.

O-RAN ALLIANCE는 2026년 6월 Specification Release 5 완료 발표에서 Non-RT RIC와 Near-RT RIC를 잇는 AI/ML workflow service와 관련 security control을 소개했다. 이는 산업단체의 specification-release 발표다. 이 글은 해당 발표를 표준 message sequence나 사업자 deployment, 매출 또는 보편적 상용 성공으로 확장하지 않는다.

필자는 실행 policy를 모델보다 상위의 운영 계약으로 봐야 한다고 본다. 모델은 허용된 action 중 하나를 추천할 수 있지만, 허용 범위 자체를 조용히 넓힐 수 없어야 한다. production에 반영되는 configuration과 model·policy version을 함께 기록하고, 누가 어떤 근거로 승인했는지 audit trail을 남겨야 한다.

Assurance는 loop의 마지막이 아니라 다음 판단의 입력이다

조치를 실행한 뒤에는 목표 KPI가 개선됐는지, 다른 slice·service·domain에 부작용이 생기지 않았는지 같은 측정 정의로 다시 확인해야 한다. 개선되지 않거나 confidence가 떨어지면 추가 action을 연쇄 실행하기보다 중지·rollback·사람 검토로 전환해야 한다. AI가 만든 조치도 일반 변경과 같은 evidence, rollback, incident 기록을 남겨야 한다.

Assurance 결과는 모델 평가와 network 평가를 분리해서 봐야 한다. network KPI가 좋아졌더라도 모델이 우연한 상관관계를 배웠을 수 있다. 반대로 model precision이 높아도 고객이 합의한 SLS가 충족되지 않을 수 있다. 모델의 drift·오탐·미탐과 서비스의 latency·availability·throughput·fault를 각각 관측한 뒤 연결해야 한다.

Human exception loop는 자동화 실패 뒤에만 등장하는 최후 수단이 아니다. 처음 보는 현상, 상충하는 SLA 목표, 고위험 변경, 보안 경계 접근, 고객 인수 영향, 낮은 confidence, rollback 실패 가능성은 애초에 사람 gate로 분류할 수 있다. 사람이 해야 할 일도 “모든 것을 다시 조사”하는 것이 아니라, AI가 정리한 context와 원본 evidence를 바탕으로 중지·승인·수정·에스컬레이션을 결정하는 쪽으로 바뀐다.

AI가 줄이는 것은 반복량이지 책임의 존재가 아니다

운영 비용 관점에서 AI가 줄일 수 있는 것은 telemetry 정리, first-pass 상관 분석, alarm triage, action 후보 비교, 제한된 반복 설정, 변경 전후 재측정, 보고 초안과 exception context 구성이다. 이 작업이 profile·policy·runbook·test evidence와 연결되면 고객 수가 늘 때 사람의 조사량이 같은 비율로 늘어나는 것을 완화할 수 있다. 이것은 반복 가능한 상품의 운영 조건과 맞닿아 있다.

그러나 SLA 측정 정의와 remedy, 정책의 정당성, security와 least privilege, model·data 검증, 변경 승인, 고객 인수, 예외 조율과 결과 책임은 사라지지 않는다. AI가 얼마나 많은 action을 실행했는지가 성숙도의 유일한 지표도 아니다. 잘 설계된 자동화는 위험이 큰 상황을 더 빨리 멈추고 적절한 사람에게 더 좋은 evidence를 전달할 수 있어야 한다.

공식 근거의 성격도 마지막까지 분리해야 한다. 3GPP TS 28.105·28.536·28.550은 관리 기능과 정보 모델의 Technical Specification이다. ETSI ZSM 009-1과 ITU-T Y.3172는 closed-loop governance와 ML architecture를 설명하는 framework 성격의 문서다. O-RAN Release 5 자료는 산업단체의 specification-release 발표다. 어느 것도 이 글만으로 특정 통신사의 상용 완전자율 운영, 매출 증가 또는 보편적 배포를 입증하지 않는다. 이 글의 단계별 부담 감소와 통제 조건은 이 근거를 엮은 Work 분석이다.

필자는 Network Slicing의 AI 자동화가 사람 없는 망을 만드는 경쟁보다, 반복 가능한 일과 예외를 구분하고 각 action의 권한·evidence·rollback을 명시하는 운영 설계 경쟁에 가깝다고 본다. 다음 질문은 가능성의 범위가 아니라, 이런 loop와 통제 장치를 갖추고도 실제 운영이 어디에서 무너질 수 있는가다. 그 실패 조건과 조직·운영의 붕괴 경로는 다음 검토로 남긴다.