통신 분야에서 실질적인 변화를 일으키는 AI 애플리케이션은 일반적인 고객 서비스용 챗봇이 아닙니다. 이들은 네트워크 운영, BSS(Business Support Systems), OSS(Operations Support Systems)에 통합되어 인간의 분석이 따라갈 수 없는 방대한 양과 속도의 데이터를 처리할 수 있는 시스템입니다. 이 포스트에서는 파일럿 단계를 넘어 성공한 사용 사례와 그렇지 못한 사례들의 장애물이 무엇이었는지 다룹니다.

통신 산업이 대부분의 산업과는 다른 규모를 가진 이유

통신사는 수백만 명의 가입자에게 서비스를 제공하고 하루에 수십억 개의 이벤트를 처리하는 인프라를 운영합니다. 네트워크 로그, 고객 상호작용, 과금 이벤트 및 장치 텔레메트리(Telemetry)는 전통적인 분석 방식으로는 실시간으로 대응할 수 없는 데이터 양을 생성합니다. 이러한 규모는 AI에게 기회인 동시에 제약 사항이기도 합니다. 데이터는 존재하지만, 모든 AI 시스템은 네트워크 운영 환경이 요구하는 지연 시간(Latency)과 처리량(Throughput) 내에서 작동해야 하기 때문입니다.

브라질의 한 중견 통신사는 시간당 수억 개의 네트워크 이벤트를 처리합니다. 문제를 알리는 데 10초가 걸리는 이상 탐지(Anomaly Detection) 모델은 장애 확산 시나리오에서 운영상의 효용성이 없습니다. 실시간 요구 사항은 단순한 희망 사항이 아니라, 사용 사례가 실행 가능하기 위한 최소한의 요건입니다.

이는 모델보다 아키텍처가 중요하다는 것을 의미합니다. 어떤 LLM(Large Language Model)도 저지연 데이터 파이프라인을 대체할 수는 없습니다. 통신 분야에서 작동하는 AI 시스템은 일반적으로 고속 문제 해결을 위한 전문 모델과 합성 및 인터페이스 문제를 위한 LLM을 함께 보유하고 있습니다. 이 두 가지를 결합하는 과정에서 대부분의 팀이 통합 노력의 중요성을 과소평가하곤 합니다.

네트워크 운영 및 이상 탐지

AI 기반 NOC(Network Operations Centers)는 이상 탐지 (Anomaly Detection) 모델을 사용하여 고객이 보고하기 전에 서비스 저하를 식별합니다. AI는 네트워크 계층 간의 신호를 상관 분석하고, 장애가 확산될 가능성이 높은 지점을 예측하며, 탐지부터 복구까지의 시간을 단축하는 사고 요약본을 생성합니다. LLM (Large Language Model) 구성 요소는 사고 요약 및 제안된 복구 단계를 생성합니다. 이상 탐지는 네트워크 텔레메트리 (Telemetry) 데이터로 학습된 전문 모델에 의해 처리됩니다.

실질적인 이점은 모델이 NOC 엔지니어를 대체하는 것이 아닙니다. 엔지니어가 어떤 알람이 발생했는지, 이벤트 순서가 어떠한지, 이전의 유사한 사고에서 어떤 복구 조치가 효과적이었는지와 같은 사전 구성된 컨텍스트를 가지고 각 사고에 대응하기 시작한다는 점입니다. 분류 (Triage) 시간이 단축됩니다. 무엇을 할지에 대한 인간의 결정은 그대로 유지됩니다.

실제 운영 환경에서 성공한 사례들은 한 가지 공통된 특징을 가지고 있습니다. 모델이 일반적인 네트워크 데이터가 아닌, 특정 통신 사업자의 텔레메트리 데이터로 학습되었다는 점입니다. 이상 징후는 해당 인프라의 베이스라인 (Baseline)에 의해 정의됩니다. 다른 사업자의 데이터로 학습된 모델은 실제 운영이 불가능할 정도로 많은 오탐 (False Positives)을 발생시킵니다.

이탈 예측 및 방지 (Churn Prediction and Prevention)

통신 분야에서의 이탈 예측 (Churn Prediction)은 성숙한 ML (Machine Learning) 애플리케이션입니다. AI 에이전트가 여기에 더하는 가치는 적절한 채널을 통해 적절한 시점에 적절한 제안으로 개입할 수 있는 능력입니다. 이탈 모델은 위험이 있는 고객을 식별합니다. AI 에이전트는 고객의 이력, 고객이 이전에 반응했던 채널, 그리고 비즈니스 규칙이 허용하는 제안 내용을 바탕으로 어떤 개입을 할지 결정합니다. 에이전트는 이탈 모델을 대체하는 것이 아니라, 모델의 출력값 (Output)을 바탕으로 행동합니다. 구현에 관한 내용은 고객 유지 (Customer Retention)에서 다룹니다.

성공하는 이탈(Churn) 방지 시스템과 그렇지 못한 시스템의 차이는 예측 모델에 있는 경우가 거의 없습니다. 차이는 채널 행동 데이터의 품질과 상담원이 조회할 수 있는 비즈니스 규칙의 세분성(Granularity)에 있습니다. 이탈 위험이 있는 것으로 식별된 고객이 잘못된 채널을 통해 잘못된 제안을 받게 되면, 상호작용 전보다 상호작용 후에 이탈할 확률이 더 높아집니다.

이 유스케이스(Use case)를 실제 운영 환경(Production)에 적용한 통신사들은 파일럿(Pilot) 단계의 발표 자료에는 거의 등장하지 않는 두 가지 요소에 투자했습니다. 바로 상담원이 선택할 수 있도록 충분한 메타데이터(Metadata)를 갖춘 제안 카탈로그와, 상담원이 결정을 내리기 전에 조회할 수 있는 상호작용 이력 기록입니다. 이 두 가지가 없다면 상담원은 아무런 정보 없이(In the dark) 결정을 내리게 됩니다.

대규모 고객 서비스

통신사는 청구 문의, 요금제 변경 요청, 기술적 문제 해결과 같이 반복적인 지원 문의를 대량으로 처리합니다. 가장 가치 있는 AI의 적용은 일반적인 챗봇(Chatbot)이 아니라, 분류(Triaging) 및 풍부화(Enrichment) 시스템입니다. AI는 문의 내용을 분류하고, 계정 및 상호작용 이력에서 관련 정보를 검색하여, 상담원이나 자동화 시스템에 사전 채워진 컨텍스트(Context)와 함께 제공합니다. 상담원이 정보를 찾는 대신 문제를 해결하는 데 시간을 쓰게 되므로 해결 시간(Resolution time)이 단축됩니다.

문의 회피(Deflection)와 지능형 분류(Intelligent triaging)의 차이는 중요합니다. 회피(Deflection)는 상담원 없이 문의를 해결하려고 시도합니다. 반면 지능형 분류(Intelligent triaging)는 문의의 일부는 상담원이 필요할 것이라고 가정하고, 해당 전환이 생산적으로 이루어지는 데 집중합니다. 복잡한 기술적 사례에 대해 완전한 회피(Total deflection)를 시도했던 통신사들은 일반적으로 에스컬레이션(Escalation) 볼륨의 증가와 만족도 하락을 보고합니다. 첫 단계로서의 지능형 분류(Intelligent triaging)는 더 일관된 결과를 보여줍니다.

디플렉션 (Deflection) 사용 사례는 특정 유형의 문의에 가장 효과적입니다. 즉, 고객이 청구 항목에 대한 설명을 필요로 하는 청구 관련 문의(billing inquiries)와 조치가 명확히 정의된 셀프 서비스 요청(self-service requests)이 이에 해당합니다. 이러한 범위를 벗어날 경우, 시스템은 언제 해결 시도를 멈추고 문맥(context)과 함께 상담원에게 전환해야 하는지를 알아야 합니다. 구현 패턴에 대해서는 지원 디플렉션 (support deflection)에서 다룹니다.

활성화 및 번호 이동 사기 탐지

SIM 스왑 (SIM swap) 사기, 도용된 신원을 이용한 부정 활성화, 그리고 번호 이동 (portability) 사기는 통신사(telecoms)에 상당한 비용 부담을 주는 항목입니다. 활성화 패턴을 분석하고, 행동 신호(behavioral signals)를 교차 검증하며, 번호 이동 요청에서 이상 징후를 식별하는 AI 시스템은 규칙 기반 (rule-based) 시스템이 놓치는 사기 유형을 탐지합니다. 운영상의 요구 사항은 낮은 오탐률 (false positive rate)입니다. 정당한 활성화를 수동 검토 대상으로 표시하는 것은 고객 경험과 운영 부하 측면에서 실제적인 비용을 발생시킵니다.

통신 분야의 사기 탐지 모델은 사기꾼들이 기술을 능동적으로 변경하기 때문에 다른 산업 분야의 모델보다 더 빠르게 성능이 저하됩니다. 6개월 전에 학습된 모델은 오늘날 현저히 낮은 정확도로 작동하고 있을 수 있습니다. 재학습 빈도와 긴급 재학습 트리거 기준을 포함한 모델 유지 관리 계획은 구현의 세부 사항이 아니라 비즈니스 케이스 (business case)의 일부입니다. 이러한 계획이 없는 시스템은 짧은 시간 내에 파일럿 결과와 실제 운영 결과가 괴리되는 현상을 보입니다.

외부 신원 확인 시스템, 신용 정보국 (credit bureaus), 그리고 기기 데이터베이스와의 통합 여부가 대부분의 사기 탐지 프로젝트의 성패를 결정합니다. 탐지 모델의 성능은 수신하는 신호의 품질만큼만 뛰어날 수 있습니다. 풍부한 외부 신호 통합을 구축한 통신사들은 동일한 유형의 사기에 대해 실질적으로 더 높은 탐지율을 보고하고 있습니다.

통합의 제약 사항

통신 분야의 대부분의 AI 프로젝트는 통합 단계에서 속도가 저하됩니다. 데이터는 AI 시스템이 필요로 하는 액세스 표준에 맞춰 설계되지 않은 BSS (Business Support Systems) 및 OSS (Operations Support Systems) 시스템에 존재합니다. API는 느리거나, 속도 제한 (rate limiting)이 있거나, 배치 처리 (batch processing)를 요구합니다. 실시간 개입 (real-time intervention)을 위해서는 실시간 데이터가 필요합니다. AI 애플리케이션을 지원하기 위한 데이터 인프라를 구축하는 것이 종종 프로젝트 시간의 대부분을 차지하며, 정작 AI 자체는 그보다 적은 비중을 차지합니다. 이러한 제약을 과소평가하는 팀은 합성 데이터 (synthetic data) 또는 지연된 데이터를 기반으로 AI를 구축하며, 프로덕션 (production) 성능이 개발 (development) 단계와 다를 때 당혹감을 느낍니다.

이러한 문제가 나타나는 가장 흔한 방식은 다음과 같습니다: 파일럿 프로젝트가 레거시 시스템 (legacy systems)에서 내보낸 배치 처리된 데이터를 사용하여 실행됩니다. 모델은 이 데이터에서 잘 작동합니다. 프로젝트가 프로덕션으로 넘어가 동일한 시스템의 실시간 데이터가 필요해지면, 기존 API의 지연 시간 (latency) 때문에 해당 유스 케이스 (use case)를 실행할 수 없게 됩니다. 그러면 팀은 원래 프로젝트 범위에 없던 데이터 파이프라인 (data pipeline)을 구축해야 하며, 이는 일정에 수개월을 추가하게 됩니다.

일관되게 프로덕션 단계에 도달하는 팀들은 모델의 첫 번째 코드 라인을 작성하기 전에, 실제 데이터 소스를 매핑하고 실제 액세스 지연 시간을 테스트하는 데 전용 스프린트 (sprint)를 할애합니다. 이 스프린트는 시간 낭비가 아닙니다. 이는 더 큰 투자가 이루어지기 전에 특정 통신사의 환경에서 해당 유스 케이스가 실행 가능한지 여부를 결정합니다. 대안은 변경 비용이 높은 최종 통합 단계에서 문제를 발견하는 것입니다.

통신 분야에서 작동하는 아키텍처 패턴은 중간 스트리밍 계층 (streaming layer)을 통해 데이터 계층 (data layer)과 AI 계층 (AI layer)을 분리하는 것입니다. BSS 및 OSS 시스템은 Kafka와 같은 브로커 (broker)로 이벤트를 공급합니다. AI 모델은 필요한 지연 시간으로 이 브로커에서 데이터를 소비합니다. 레거시 시스템은 모델에 의해 직접 액세스되지 않습니다. 이러한 분리는 결합도 (coupling)를 낮추고 모델과 레거시 시스템이 독립적으로 진화할 수 있도록 합니다.

studiolabsai.com에서 처음 게시되었습니다. Studio Labs는 엔터프라이즈 팀을 위한 프로덕션용 AI (Production AI)를 구축합니다. 미팅 예약하기.