통신 NOC에서 AI 활용을 검토할 때는 대개 장애 티켓 분류와 원인 분석부터 살펴봅니다. 하지만 실제 NOC AI 도입 단계에서는 모델보다 데이터가 오가는 경로를 먼저 결정해야 합니다.
NOC의 장애 티켓에는 가입자 식별자와 장비 IP, 회선 ID, 알람 순서, 토폴로지, SLA 조건, 변경 이력이 함께 담깁니다. 각 정보는 따로 떨어져 있지 않고 하나의 장애 상황 안에서 서로 맞물립니다. AI가 원인을 분석하거나 티켓을 분류하려면 이러한 연결 관계를 따라갈 수 있어야 하는데요.
원본 운영 데이터를 그대로 외부 모델에 보내는 방식은 많은 조직에서 승인하기 어렵습니다. 그렇다고 이름과 번호만 가리는 것으로도 충분하지 않습니다. 회선과 장비, 알람과 장애 시점을 잇는 관계까지 사라질 수 있기 때문입니다. 통신 NOC에 AI를 도입하려면 데이터를 가져올 시스템과 외부로 보낼 범위, 모델 응답을 어느 시스템에서 원래 값과 다시 연결할지를 먼저 정해야 합니다.
핵심은 원본값과 대체어를 연결하는 매핑을 고객 환경 안에 두는 것입니다. 외부 모델에는 민감한 값을 대체어로 바꾸되 업무에 필요한 데이터 관계는 유지한 데이터만 보냅니다. 모델 응답이 돌아오면 고객 환경 안에서 재구성(Reconstruction)을 거쳐 대체어를 원래 값과 다시 연결하고, 결과를 티켓이나 운영 기록에 반영합니다. LLM Capsule 아키텍처는 원본값과 매핑을 고객 환경에 남겨 두고, 승인된 모델에는 민감한 값을 바꾼 데이터를 전달한 뒤 돌아온 결과를 기존 업무 기록에 다시 연결하는 전체 흐름을 설명합니다.
핵심 요약
통신 NOC AI 도입은 다음 다섯 단계를 하나의 데이터 경로로 연결해 검증해야 합니다.
- 어떤 NOC 시스템에서 무엇을 읽고 어디에 결과를 기록할지 정합니다.
- 가입자 정보뿐 아니라 조직이 민감하다고 정한 운영 식별자를 정책에 포함합니다.
- 표, 계층, 알람 순서와 참조 관계를 유지하는 보호 작업본을 만듭니다.
- 업무별로 승인된 외부 또는 온프레미스 모델 경로를 선택합니다.
- 결과를 고객 환경 안에서 재구성해 원래 업무 시스템에 기록하고 실행 이력을 남깁니다.
NOC에서 보호해야 할 데이터는 개인정보에 그치지 않습니다
NOC 티켓에서 보호해야 할 정보는 개인정보만이 아닙니다. 장애 분석에 쓰이는 정보는 다음 다섯 범주로 나눌 수 있습니다.
- 가입자 데이터: MSISDN, IMSI, IMEI, 고객명, 계정 번호처럼 개인이나 계정을 식별하는 값
- 네트워크 식별자: 장비 ID, 사이트 ID, 회선 ID, RAN 셀 ID, IP 대역, VLAN 태그처럼 장비와 회선, 사이트를 구분하고 연결하는 값
- 운영 순서: 알람 체인, 장애 이력, 에스컬레이션 경로, 티켓 의존성처럼 장애 발생부터 대응까지의 순서를 보여 주는 기록
- SLA와 업무 맥락: 고객사, 계약 조건, 서비스 등급, 예상 영향 범위처럼 대응 우선순위를 정하는 정보
- 구성 정보: 장비 설정, 라우팅 테이블, BGP 피어링, 방화벽 규칙, 네트워크 토폴로지처럼 운영 구조를 드러내는 정보
어떤 값을 보호할지는 조직과 업무마다 다릅니다. NOC 운영팀과 데이터·보안 담당자는 개인정보 목록만 확인하지 말고, 회선 명명 규칙이나 내부 사이트 코드, 서비스 등급처럼 조직 내부에서만 의미가 통하는 식별 정보도 함께 정해야 합니다.
유럽전기통신표준협회(European Telecommunications Standards Institute, ETSI)의 ZSM 보안 요구사항은 개인 데이터, 보안 관련 데이터, 관리 데이터를 구분하는데요. 관리 데이터에는 네트워크 자동화에 쓰이는 구성 정보와 성능 데이터가 포함됩니다. 이 기준으로 보면 NOC의 보호 대상은 개인정보에 그치지 않습니다. AI 업무가 실제로 읽고 쓰는 구성 정보와 성능 데이터 등 운영 데이터까지 함께 검토해야 합니다.
1. 데이터를 가져올 곳과 결과를 기록할 곳을 정합니다
첫 단계에서는 커넥터 개수보다 실제 업무 흐름을 먼저 확인합니다.
예를 들어 장애 티켓을 분류한다면 티켓 시스템에서 필요한 데이터를 읽고, 분류 결과도 같은 티켓에 기록할 수 있습니다. 원인 분석에 로그와 네트워크 연결 정보가 필요하다면 로그 뷰어, 구성 데이터베이스, 런북 저장소까지 확인해야 하는데요. 이 단계에서 시스템별로 가져올 데이터와 접근 권한, 결과를 기록할 위치를 정합니다. 데이터를 읽을 수 있어도 결과를 기록할 권한이 없으면 업무를 끝낼 수 없으므로 읽기와 쓰기 권한을 따로 확인해야 합니다.
현재 LLM Capsule 아키텍처는 REST, gRPC, JDBC, Graph API를 연결 방식으로 안내합니다. 다만 실제 운영 환경에서 사용할 수 있는지는 제품의 현재 지원 범위와 대상 시스템의 연결 조건을 함께 확인해야 합니다. 통합 페이지에는 아직 준비 중인 연동도 있는데요. 목록에 표시돼 있다는 이유만으로 바로 연결할 수 있다고 판단해서는 안 됩니다.
2. . 보호 정책은 NOC 업무 단위로 정의합니다
민감한 값의 목록만 만드는 것으로는 충분하지 않습니다. 누가 어떤 업무에서 어떤 데이터를 어느 모델로 보낼 수 있는지까지 정책으로 정해야 하는데요. 정책 버전과 적용 팀, 데이터 범위, 사용자 권한, 사용할 수 있는 모델 경로를 함께 기록합니다.
가입자 번호는 기본 보호 대상이 될 수 있지만, 통신사마다 사용하는 회선 ID와 사이트 코드, 내부 서비스 등급은 조직이 직접 지정해야 합니다. 같은 값도 업무에 따라 필요한 범위와 접근 권한이 달라집니다. 장애 티켓 분류, 고객 영향 분석, 사후 보고서 작성에 필요한 데이터와 담당자가 서로 다르기 때문입니다.
정책이 바뀐 뒤에도 각 요청에 어떤 정책 버전을 적용했는지 확인할 수 있어야 합니다. LLM Capsule 제품 페이지에서는 조직이 지정한 식별 정보인 고객 정의 마커와 정책 버전, 역할별 접근 범위, 실행 기록을 현재 제품 흐름의 일부로 설명합니다. 이 기록이 있어야 문제가 발생했을 때 어떤 정책과 권한으로 요청을 처리했는지 확인할 수 있습니다.
3. 값만 바꾸고 운영 관계는 남깁니다
NOC 데이터에서는 개별 식별자만큼 값 사이의 연결 관계가 중요합니다. 회선 ID가 어느 장비와 사이트에 연결되는지, 어떤 알람이 먼저 발생했는지, 어느 SLA가 적용되는지가 남아 있어야 모델이 실제 업무 질문을 처리할 수 있습니다.
LLM Capsule은 민감한 운영값을 문맥보존형 대체어로 바꿔 외부 모델이 사용할 작업본을 만드는데요. 원본값과 대체어를 연결하는 매핑은 고객 환경 안에 남고, 외부로 이동하는 작업본에는 표의 구조와 필드 구분, 항목 사이의 참조 관계가 유지됩니다. 여기서 문맥 보존은 모델이 모든 내용을 정확히 이해한다고 보장한다는 뜻이 아닙니다. 업무에 필요한 관계를 유지한 상태로 데이터를 승인된 경로에 전달한다는 의미입니다.
대체어가 생성됐는지만 확인해서는 부족합니다. 같은 회선이 티켓 본문과 네트워크 연결 정보, 로그에서 같은 대체어로 이어지는지 확인해야 합니다. 알람의 시간 순서가 유지되는지, 정책에 등록되지 않은 식별 정보가 나타났을 때 처리를 중단하거나 별도로 표시하는지도 시험해야 합니다.
4. 모델 경로는 업무별로 승인합니다
모든 NOC 업무에 같은 모델 경로를 사용할 필요는 없습니다. 조직 정책에 따라 승인된 외부 모델을 사용할 수도 있고, 사내에 설치한 모델이 필요한 업무도 있는데요. 모델이 외부에 있는지 내부에 있는지만으로 판단할 수는 없습니다. 어떤 업무 데이터를 어느 모델에 보내고, 어느 지역에서 처리할지 업무별로 승인해야 합니다.
업무별 모델 경로를 승인할 때는 업무 목적과 데이터 유형, 적용한 정책 버전을 먼저 기록합니다. 누가 또는 어떤 시스템이 어떤 모델을 호출하는지, 데이터가 어느 지역에서 처리되고 얼마나 보관되는지도 함께 남겨야 합니다. 외부 모델을 사용하는 경우에는 원본값과 내부 매핑이 고객 환경 안에 남는지 확인해야 하는데요. 사내 모델 역시 설치 위치만으로 검토가 끝나는 것은 아닙니다. 모델 접근 권한과 실행 기록, 결과가 돌아갈 시스템까지 확인해야 합니다.
모델 사용을 승인했다고 해서 모든 응답을 자동으로 실행해도 되는 것은 아닙니다. ETSI의 AI 기반 네트워크 자동화 요구사항은 필요할 때 모델 분석을 멈추거나 우회하고, 사람 또는 다른 애플리케이션으로 넘길 수 있어야 한다고 설명하는데요. 미국 국립표준기술연구소(National Institute of Standards and Technology, NIST)의 AI 위험관리 프레임워크도 AI가 맡을 업무 범위와 사람의 감독 절차를 문서화하도록 권고합니다. NOC 파일럿에서는 분류, 분석 제안, 실행 명령을 구분하고 각 단계의 권한과 중단 조건을 정해야 합니다.
5. 재구성한 결과가 실제 티켓에 반영되는지 확인합니다
모델의 응답을 받았다고 해서 NOC 업무가 끝나는 것은 아닙니다. 응답에 포함된 대체어를 고객 환경 안의 매핑으로 원래 값에 다시 연결한 뒤, 권한이 있는 사용자가 보는 티켓이나 보고서에 기록해야 하는데요.
LLM Capsule의 재구성(Reconstruction)은 모델이 원본값을 추측하는 과정이 아닙니다. 고객 환경에 보관된 매핑을 사용해 응답 속 대체어를 원래 값에 다시 연결하는데요. 같은 매핑과 입력에는 같은 결과를 내는 결정적(deterministic) 동작입니다. 결과가 지정한 시스템에 중복 없이 기록되는지 확인하고, 원래 값과 연결되지 않는 항목을 어떻게 처리할지, 누가 결과를 볼 수 있는지도 정해야 합니다.
데이터 소스와 정책, 모델 호출, 재구성, 결과 기록은 한 건의 실행 이력으로 묶어야 합니다. 장애 대응 결과에 문제가 생기면 이 기록에서 어떤 정책과 모델 경로가 적용됐는지 확인할 수 있습니다.
이러한 실행 이력은 사후 점검에도 필요한데요. ETSI는 자동화 과정에서 나온 AI·ML 결과를 나중에 다시 해석하고, 어떤 제어가 적용됐는지 확인할 수 있어야 한다고 설명합니다. 입력 데이터의 오류와 누락, 잘못된 순서, 시간에 따른 데이터 특성 변화도 확인 항목에 포함합니다. 실행 이력에는 성공한 결과뿐 아니라 발견한 입력 문제와 사람이 검토하도록 넘긴 단계도 함께 남겨야 합니다.
파일럿을 끝내기 전에 확인할 기준
통신 NOC AI 워크플로우를 다음 단계로 진행하려면 아래 항목을 실제 테스트 결과와 기록으로 확인해야 합니다.
- 실제 NOC 티켓과 운영 데이터에서 보호해야 할 값과 관계를 정했나요?
- 원본값과 내부 매핑이 고객 환경 안에 남는지 확인했나요?
- 같은 회선이나 장비가 티켓, 로그, 네트워크 연결 정보에서 같은 대상으로 이어지나요?
- 업무별 정책에 사용할 모델과 호출 주체, 처리 위치가 기록되어 있나요?
- 정책에 등록되지 않은 식별 정보, 매핑 실패, 권한 오류, 중복 기록 같은 실패 상황을 시험했나요?
- 재구성한 결과가 원래 티켓이나 운영 기록에 중복 없이 한 번만 반영되나요?
- 적용한 정책 버전부터 모델 호출과 결과 기록까지 하나의 실행 이력에서 확인할 수 있나요?
이 기준은 통신 규제 준수 여부를 판단하는 체크리스트가 아닙니다. 실제 승인은 적용 지역과 데이터 종류, 통신사 정책, 모델 사업자, 배포 구조에 따라 달라지는데요. 법무·보안·운영 담당자가 실제 테스트 결과와 조직의 승인 기준을 함께 검토해야 합니다.
실제 NOC 티켓 한 장으로 데이터 경로를 확인하세요
첫 검증부터 범위를 크게 잡을 필요는 없습니다. 장애 티켓 한 장을 고르고, 원인 분석에 필요한 로그나 네트워크 연결 정보만 함께 준비합니다. 여기에 반드시 지켜야 할 승인 조건 하나를 정하는데요. 원본값을 고객 환경 안에 둘 것인지, 어떤 모델을 사용할 것인지, 결과를 어느 시스템에 기록할 것인지처럼 실제로 확인할 수 있는 조건이어야 합니다.
그다음 보호할 식별 정보와 모델 경로, 결과를 돌려보낼 시스템, 실패했을 때의 처리 방법을 정합니다. 이렇게 범위를 좁히면 원본값이 고객 환경 안에 남는지, 외부 모델에 어떤 데이터가 전달되는지, 응답이 원래 티켓에 중복 없이 기록되는지를 하나의 흐름으로 확인할 수 있습니다. 실제 NOC 데이터로 같은 경로를 점검하려면 아래에서 검토할 워크플로우를 신청할 수 있습니다.
