Customer-triggered AI Agents: TPG Telecom이 상담원용 망 진단 에이전트를 고객이 직접 부르게 하려는 계획
TPG Telecom은 망 성능·장애·변경 이력·민원을 엮어 고객 문제를 실시간으로 찾는 에이전트를 상담원 뒤에 붙였고 해당 고객군 해지율이 약 40% 줄었다고 밝혔습니다. 다음은 고객이 자기 서비스 화면에서 이 진단을 직접 부르게 하는 것이며 보안과 토큰 비용을 지켜보며 천천히 넓힐 계획입니다.
통신사 상담 에이전트의 가치는 답변 문장을 잘 쓰는 데보다 흩어진 망 신호를 고객 한 명의 문제로 엮는 데서 나옵니다. TPG Telecom은 이 진단을 상담원 뒤에서 먼저 써서 해당 고객군 해지율을 약 40% 낮췄고 이제 고객 화면으로 옮기려 합니다. 따라 하려면 고객과 망 장비를 잇는 매핑, 장애 단위로 진단을 재사용하는 구조, 고객에게 열기 전의 보안·비용 한도가 먼저 있어야 합니다.
요약
호주 통신사 TPG Telecom의 기술 운영 총괄(General Manager of Technology Operations) Gaston De Arriba가 멜버른 Cisco Live!에서 에이전트 활용 현황과 다음 계획을 발표했고 iTnews의 Ry Crozier가 2026년 11월 12일 이를 전했습니다. 출발점은 TPG가 2026년 3월 들여온 Splunk 도구군입니다. TPG는 이 도구로 서비스 운영을 AIOps(IT 운영 데이터에 머신러닝을 적용해 장애를 빨리 찾고 미리 막는 방식)로 바꾸는 중입니다. 목표는 망과 IT 환경을 실시간으로 보고 고객이 느끼기 전에 문제를 예측해 푸는 것입니다. 지금 에이전트는 콜센터 뒤에서 일합니다. 서비스 문제로 고객이 전화하면 에이전트가 망 성능 지표, KPI, 장애(incident), 변경(change), 민원 데이터를 모아 서로 맞춰 보고 그 고객이 겪는 문제를 실시간으로 짚습니다. 그런 다음 상담원에게 고객에게 무엇을 말할지, 망에서 어떤 해결책을 실행할지 추천합니다.
성과로 De Arriba는 에이전트가 쓰인 고객군(cohort)에서 해지율이 약 40% 줄었다고 말했습니다. 예상하지 못한 효과도 있었습니다. 고객은 자기 서비스에 문제가 생긴 줄 모르는 경우가 많은데, TPG가 먼저 조치하면서 들어오는 전화가 줄었습니다. 감소 폭은 밝히지 않았습니다. 다음 단계는 고객이 자기 서비스에서 에이전트 워크플로를 직접 실행하게 하는 것입니다. 고객은 화면에서 서비스 성능을 확인합니다. 개선하려면 무엇을 하면 되는지 안내받고 그래도 안 되면 전화 없이 콜센터에 장애 티켓을 올립니다. De Arriba는 자가 점검과 자가 복구를 늘리고 고객을 더 잘 이해해 불만을 빨리 풀겠다고 했습니다. 동시에 TPG는 에이전트가 정해진 경계 안에서만 움직이도록 천천히 진행하고 고객이 에이전트를 직접 쓸 때 커지는 보안 문제와 운영비가 불어나는 ‘tokenomics’ 위험을 지켜보겠다고 밝혔습니다. 아래에서는 이 흐름을 다섯 가지 메커니즘으로 나누고 실제로 돌릴 때 필요한 설정과 일정을 덧붙입니다.
핵심 메커니즘
Signal Correlation: 망 신호 다섯 가지를 고객 한 명의 문제로 엮는다
무엇인가. 망 성능 지표, KPI, 장애, 변경, 민원처럼 서로 다른 시스템에 쌓이는 운영 데이터를 고객 한 명의 서비스를 기준으로 겹쳐 보는 단계입니다.
어떻게 작동하나. 고객이 전화하면 그 고객의 서비스가 지나는 망 요소(기지국, 노드, 회선 경로)를 찾습니다. 같은 시간대에 그 요소에서 생긴 성능 저하, 열려 있는 장애, 최근 변경, 비슷한 민원을 모읍니다. 에이전트는 신호가 겹치는 지점에서 원인 후보를 고르고 근거와 함께 내놓습니다. 상담원이나 운영자가 시스템 다섯 개를 따로 열어 보던 일을 통화 중에 한 번에 끝내는 셈입니다.
언제 쓰고 언제 안 쓰나. 원인이 단말보다 망 쪽에 있을 가능성이 큰 문의(속도 저하, 끊김, 개통 직후 불통)에 맞습니다. 요금·계약 문의에는 필요 없습니다.
원문의 예. TPG 에이전트는 상담원 뒤에서 이 다섯 가지 데이터를 모아 고객의 문제를 실시간으로 짚습니다. 바탕은 3월 도입한 Splunk 도구군입니다. Cisco의 2026년 3월 발표에 따르면 Splunk Enterprise가 실시간 망 모니터링과 장애·고장 연결을, Splunk ITSI(IT Service Intelligence, 서비스 상태를 머신러닝으로 감시·예측하는 제품)가 서비스 상태 예측을 맡습니다.
작은 예시(가상). 저녁 9시에 인터넷이 느리다는 전화가 옵니다. 고객 회선이 물린 지역 노드에서 40분 전 설정 변경이 있었고 같은 노드 고객 민원이 1시간 사이 6건 들어왔습니다. 에이전트는 “변경 이후 노드 성능 저하”를 1순위 원인으로 내고 변경 ID와 민원 건수를 근거로 붙입니다.
Two-sided Recommendation: 상담원에게 ‘고객에게 할 말’과 ‘망에서 할 일’을 함께 준다
무엇인가. 진단 결과를 두 갈래 추천으로 바꾸는 단계입니다. 하나는 상담원이 고객에게 전할 설명이고 다른 하나는 망 쪽에서 실행할 해결책입니다.
어떻게 작동하나. 상담원은 진단을 직접 하지 않습니다. 화면에 뜬 추천을 확인해 고객에게 상황을 설명하고 망 조치안은 담당 쪽에 넘깁니다. 고객 응대와 망 운영이 같은 진단을 보고 움직이니, 고객이 들은 설명과 실제 조치가 어긋날 일이 줄어듭니다.
언제 쓰고 언제 안 쓰나. 상담원의 망 지식이 깊지 않고 상담 조직과 망 운영 조직이 나뉜 회사에서 효과가 큽니다. 망 조치를 자동으로 실행할지, 사람이 확인한 뒤 실행할지는 원문에서 밝히지 않았습니다.
원문의 예. TPG 에이전트는 배경에서 돌며 상담원에게 고객과 나눌 정보와 망에 적용할 해결책을 함께 추천합니다.
Proactive Fix: 고객이 모르는 문제를 먼저 고쳐 전화를 줄인다
무엇인가. 고객이 불편을 느끼거나 전화하기 전에 회사가 먼저 망 문제를 찾아 처리하는 운영 방식입니다.
어떻게 작동하나. 같은 진단을 전화한 고객 한 명이 아니라 같은 망 요소에 물린 고객 전체에 적용합니다. 서비스 상태가 나빠질 조짐이 보이면 조치하고 필요하면 고객에게 알립니다. Cisco 발표가 밝힌 TPG의 목표도 머신러닝으로 서비스 문제를 예측해 고객이 영향을 받기 전에 푸는 것입니다.
언제 쓰고 언제 안 쓰나. 망 쪽 원인이라 회사가 혼자 고칠 수 있는 문제에 맞습니다. 댁내 공유기나 단말 설정처럼 고객 손이 필요한 문제는 다음 메커니즘의 고객 호출 에이전트로 넘깁니다.
원문의 예. De Arriba는 고객이 자기 문제를 모르는 경우가 많고 먼저 조치하니 인입 전화가 꽤 줄었다고 했습니다. 감소 폭은 밝히지 않았습니다.
Customer-triggered Agents: 같은 진단을 고객이 자기 화면에서 부른다
무엇인가. 상담원용 진단 에이전트를 고객 셀프서비스로 여는 다음 단계입니다.
어떻게 작동하나. 고객이 자기 서비스 화면에서 에이전트 워크플로를 실행합니다. 화면에서 서비스 성능을 보고 직접 해 볼 개선 방법을 안내받습니다. 그래도 안 되면 전화 없이 콜센터에 장애 티켓을 올립니다. 진단의 재료는 상담원용과 같고 바뀌는 것은 누가 부르느냐입니다.
언제 쓰고 언제 안 쓰나. 상담원 단계에서 진단 정확도와 조치 기준이 검증된 뒤에 엽니다. 진단이 자주 틀리는 문의 유형은 상담원 경로에 남겨 둡니다.
원문의 예. TPG가 원하는 방향이며 아직 계획 단계입니다. 원문은 출시 일정을 밝히지 않았습니다. De Arriba가 밝힌 목표는 자가 점검과 자가 복구, 고객 이해, 불만 해결 속도입니다.
Bounded Rollout: 경계·보안·tokenomics를 보며 천천히 연다
무엇인가. 에이전트가 할 수 있는 일의 범위를 먼저 정하고 그 안에서 단계적으로 넓히는 원칙입니다.
어떻게 작동하나. TPG는 에이전트가 정해진 경계 안에서 움직이게 하려고 천천히, 목적을 갖고 진행한다고 밝혔습니다. 가장 큰 관심사는 에이전트를 고객 경험에 실제로 좋은 쪽으로 쓰는 것입니다. 고객이 에이전트와 직접 만나는 순간 보안이 우선순위로 올라오고 에이전트는 운영비를 쉽게 키울 수 있어 비용도 계속 감시합니다. tokenomics는 에이전트 호출이 늘수록 토큰 사용량과 비용이 함께 커지는 구조를 가리킵니다.
언제 쓰고 언제 안 쓰나. 호출량을 회사가 통제할 수 없는 고객 대면 에이전트에는 반드시 필요합니다. 상담원 수만큼만 호출되는 내부용 단계에서는 월 예산 한도로도 충분합니다.
원문의 예. 경계의 구체적인 내용, 보안 통제 방식, 비용 한도는 원문에서 밝히지 않았습니다.
통념과 다른 주장
흔히 이렇게 봅니다콜센터에 AI를 넣는 목적은 상담 처리 시간과 상담 인력 비용을 줄이는 것이라고 흔히 봅니다.
저자는 이렇게 봅니다De Arriba가 내세운 성과는 처리 시간이 아니라 해지율과 전화 수였습니다. 에이전트가 망 문제를 짚어 고치게 하자 고객이 덜 떠났고 먼저 고치니 전화할 일 자체가 줄었다는 것입니다.
근거에이전트가 쓰인 고객군에서 해지가 약 40% 줄었고 그는 이를 "we reduced around 40 percent the churn"이라고 말했습니다. 선제 조치로 인입 전화도 줄었습니다.
저자가 든 사례
TPG Telecom 상담원 지원 진단 에이전트
| 구분 | 내용 |
|---|---|
| 상황 | 서비스 문제로 전화한 고객의 원인을 상담원이 바로 알기 어려움 |
| 한 일 | 에이전트가 망 성능 지표·KPI·장애·변경·민원을 엮어 실시간 진단, 상담원에게 고객 안내와 망 해결책 추천 |
| 결과 | 해당 고객군 해지율 약 40% 감소, 선제 조치로 인입 전화 감소(폭은 원문에서 밝히지 않음) |
| 연결 | Signal Correlation, Two-sided Recommendation, Proactive Fix |
TPG Telecom AIOps 기반 구축
| 구분 | 내용 |
|---|---|
| 상황 | 망과 IT 환경 전체를 실시간으로 보고 장애를 빨리 찾고 미리 막아야 함 |
| 한 일 | 2026년 3월 Splunk 도구군 도입. Cisco 발표 기준 Splunk Enterprise(망 모니터링·장애 연결), ITSI(서비스 상태 예측), Enterprise Security(보안 위협 탐지·대응), SOAR |
| 결과 | 상담원용 진단 에이전트의 데이터 기반이 됨. 별도 수치는 원문에서 밝히지 않음 |
| 연결 | Signal Correlation, Proactive Fix |
고객 호출 에이전트 계획
| 구분 | 내용 |
|---|---|
| 상황 | 고객이 전화해야만 진단이 시작됨 |
| 한 일(계획) | 고객이 자기 서비스 화면에서 성능 확인, 개선 안내, 장애 티켓 생성을 직접 실행 |
| 결과 | 아직 계획 단계, 일정은 원문에서 밝히지 않음 |
| 연결 | Customer-triggered Agents, Bounded Rollout |
기술 디테일: 망 진단 에이전트를 만드는 법
Signal Correlation을 돌리려면 고객과 망 요소를 잇는 매핑부터 만듭니다. 고객 서비스 ID에서 접속 장비, 기지국이나 노드, 상위 회선 경로까지 이어지는 테이블이 없으면 다섯 가지 신호를 고객 한 명에게 묶을 수 없습니다. 개통·이전·해지 때 바로 갱신하고 전체는 하루 한 번 다시 맞춥니다. 시범 전에 매핑이 없는 고객 비율을 재고 5%를 넘으면 그 고객군은 시범에서 뺍니다(가상 기준).
신호 수집은 LLM이 아니라 조회 도구가 하게 나눕니다. 에이전트에 아래 다섯 도구를 붙이고 각 도구는 운영 데이터 플랫폼(TPG라면 Splunk)에 미리 정해 둔 집계 쿼리를 돌려 요약 행만 돌려줍니다. 원본 로그를 모델에 넘기면 토큰이 폭증하고 판단도 흐려집니다. 기본 시간 창은 전화 시점 앞 2시간, 변경 이력은 24시간으로 둡니다(가상 기준).
진단은 구조화 출력으로 받습니다. 상담원 화면과 망 운영 티켓이 같은 필드를 읽게 하려면 자유 문장 대신 아래 같은 JSON을 강제합니다(가상 예시). evidence가 비어 있거나 confidence가 0.6 아래면 원인을 단정하지 않고 “추가 확인 필요”로 표시합니다.
{
"service_id": "SVC-0012345",
"suspected_cause": "node_degradation_after_change",
"evidence": [
{"source": "change", "id": "CHG-88213", "at": "2026-11-12T20:21"},
{"source": "kpi", "metric": "node_throughput", "drop_pct": 38},
{"source": "complaint", "count_1h": 6}
],
"confidence": 0.82,
"customer_message": "지역 장비 작업 뒤 속도가 떨어졌고 복구 조치 중입니다.",
"network_action": "CHG-88213 롤백 검토 요청",
"needs_human": true
}같은 장애는 한 번만 진단합니다. Proactive Fix와 고객 호출 에이전트를 함께 쓰면, 장애 하나에 걸린 고객 수백 명이 비슷한 시간에 진단을 부릅니다. 망 요소와 장애 ID를 진단 키로 삼아 결과를 15~30분 캐시하고 고객별로는 안내 문장만 다시 만듭니다. 이렇게 하면 토큰 사용량이 고객 수가 아니라 장애 수를 따라갑니다. tokenomics 위험을 줄이는 데 가장 먼저 손댈 곳입니다.
고객에게 열기 전에 권한과 입력을 좁힙니다. 고객 호출 에이전트는 로그인 세션의 service_id로만 조회하게 묶고 쓰기 권한은 장애 티켓 생성 하나만 줍니다. 고객 화면에는 내부 변경 ID, 장비명, 다른 고객 정보를 내보내지 않습니다. 자유 입력창 대신 “속도 확인”, “끊김 진단” 같은 버튼으로 시작하면 프롬프트 인젝션(prompt injection, 입력 문장으로 에이전트 지시를 바꾸려는 공격) 표면이 줄어듭니다. 세션당 진단 3회, 하루 10회 같은 호출 한도와 세션당 토큰 상한을 둡니다(가상 기준).
정확도와 효과는 따로 잽니다. 정확도는 상담원 단계에서 에이전트가 낸 1순위 원인과 장애가 최종 종결된 원인의 일치율로 봅니다. 같은 사례를 temperature 0으로 3회 돌려 원인이 바뀌는 사례는 따로 모아 프롬프트와 도구를 고칩니다. 효과는 에이전트가 처리한 고객군과 처리하지 않은 비교 고객군의 90일 해지율을 나란히 봅니다.
| 지표 | 뜻 | 시범 통과 기준(가상) |
|---|---|---|
| 원인 일치율 | 1순위 원인 = 최종 종결 원인 | 80% 이상 |
| 반복 편차 | 3회 실행 중 원인이 바뀐 사례 비율 | 5% 이하 |
| 근거 누락률 | evidence 없이 원인을 낸 비율 | 0건 |
| 진단 지연 | 전화 연결부터 추천 표시까지 | 20초 이내 |
| 90일 해지율 | 처리 고객군 vs 비교 고객군 | 비교군보다 낮음 |
현업 실행 디테일: 누가, 언제, 무엇을
역할(가상 예시).
| 역할 | 하는 일 |
|---|---|
| 고객센터 운영 리더 | 시범 문의 유형을 고르고 상담원 화면의 추천 표시 방식과 연결 기준을 정함 |
| 망 운영(NOC·SOC) 리더 | 망 조치안을 누가 승인하고 실행할지 정하고, 종결 원인 코드를 정리 |
| 데이터 엔지니어 | 고객-망 요소 매핑, 다섯 조회 도구의 집계 쿼리 작성 |
| AI 엔지니어 | 에이전트 프롬프트, 구조화 출력, 캐시, 평가 자동화 |
| 보안 담당 | 고객 호출 단계의 권한 범위, 노출 금지 정보, 인젝션 대응 검토 |
| 재무 담당 | 진단 1건당 비용, 월 토큰 예산, 해지 감소의 금액 환산 기준 확정 |
시작 전 준비물. 최근 3개월 망 관련 문의 상위 10개 유형과 각 유형의 최종 종결 원인, 고객-망 요소 매핑 테이블, 장애·변경 관리 시스템의 조회 권한, 고객군별 해지율 기준값이 필요합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 매핑 품질 점검, 다섯 조회 도구 연결 | 매핑 누락률 보고, 도구 응답 샘플 |
| 3~4주 | 그림자 진단: 상담원에게 보이지 않게 진단만 돌려 종결 원인과 비교 | 원인 일치율, 반복 편차 |
| 5~6주 | 상담원 일부(한 팀)에게 추천 표시 | 상담원 피드백, 진단 지연, 건당 비용 |
| 7~8주 | 처리 고객군과 비교 고객군 비교, 확대 여부 결정 | 진행 판정 문서 |
운영 리더가 먼저 답할 질문.
- 망 조치안은 에이전트 추천만 하나, 사람이 승인하면 자동 실행하나?
- 같은 장애로 전화한 고객에게 회사가 먼저 연락할 기준은 무엇인가?
- 해지율을 비교할 고객군을 어떻게 나누나?
- 고객 화면에 보여 줘도 되는 망 정보와 숨길 정보는 무엇인가?
진행 판정 기준(가상 예시). 그림자 진단에서 원인 일치율 80%와 근거 누락 0건을 넘겨야 상담원 시범으로 갑니다. 상담원 시범에서 진단 지연 20초 이내, 건당 비용이 예산 안이면 전체 상담원으로 넓힙니다. 고객 호출 단계는 상담원 경로에서 최소 한 분기의 해지율 비교 결과가 나온 뒤 조회 전용으로 먼저 열고 티켓 생성은 그다음에 붙입니다.
AX 적용 제언. 국내 통신사뿐 아니라 인터넷·IPTV 사업자, 전력·가스 같은 망 사업자, 클라우드·SaaS 기업의 장애 문의에 그대로 옮길 수 있습니다. 순서는 TPG가 간 길과 같습니다. 운영 데이터를 한 곳에서 조회할 수 있는 기반을 먼저 갖추고 상담원 뒤에서 진단을 검증한 다음, 고객 화면으로 엽니다. 이 사례에서 가져올 것은 특정 제품이 아니라 성과 지표의 선택입니다. 상담 처리 시간 대신 해지율과 인입 전화 수를 목표로 두면, 에이전트 예산을 고객센터 비용이 아니라 매출 방어로 설명할 수 있습니다. 경영진에게는 고객 호출 단계의 토큰 비용 상한과 보안 검토를 출시 조건으로 함께 올립니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 기사 | iTnews, Ry Crozier, 2026년 11월 12일 |
| 발표 자리 | Cisco Live! 멜버른 |
| 발표자 | Gaston De Arriba, TPG Telecom 기술 운영 총괄 GM |
| 기반 | 2026년 3월 도입한 Splunk 도구군, AIOps 방식 서비스 운영 |
| 함께 읽은 자료 | Cisco 발표(2026년 3월 4일): Splunk Enterprise, ITSI, Enterprise Security, SOAR. 대상 브랜드 Vodafone, TPG, iiNet, Lebara, felix |
| 현재 에이전트 | 콜센터 뒤에서 망 성능 지표·KPI·장애·변경·민원을 엮어 실시간 진단, 고객 안내와 망 해결책 추천 |
| 성과 | 에이전트가 쓰인 고객군 해지율 약 40% 감소, 인입 전화 감소(폭 미공개) |
| 다음 계획 | 고객이 자기 서비스에서 에이전트 워크플로 실행: 성능 확인, 개선 안내, 전화 없이 장애 티켓 |
| 관리 조건 | 정해진 경계, 고객 경험, 보안, tokenomics(운영비 증가) |
핵심 개념
- AIOps
- IT·망 운영 데이터에 머신러닝을 적용해 장애를 빨리 찾고 미리 막는 운영 방식입니다.
- cohort
- 같은 조건으로 묶어 결과를 비교하는 고객 집단. 여기서는 에이전트가 처리한 고객들입니다.
- churn
- 일정 기간 안에 서비스를 해지하고 떠난 고객의 비율입니다.
- trouble ticket
- 고객이나 운영자가 장애를 접수해 처리 과정을 추적하는 기록입니다.
- self-healing
- 시스템이 문제를 스스로 찾아 사람 개입 없이 복구하는 동작입니다.
- tokenomics
- 에이전트 호출이 늘면 토큰 사용량과 운영비가 함께 커지는 비용 구조를 가리키는 말입니다.
- ITSI
- Splunk IT Service Intelligence. 서비스 상태를 지표로 묶어 감시하고 머신러닝으로 악화를 예측합니다.
내 메모
TODO: 내 생각 추가
원문은 iTnews의 「TPG Telecom wants customer-triggered AI agents」(Ry Crozier, 2026.11.12)입니다. TPG의 Splunk 도입 범위와 제품 이름은 Cisco 발표 「Cisco to Power TPG Telecom’s Next Generation Security and Service Operations Across Australia with Splunk」(2026.3.4)를 함께 읽어 보탰습니다. 요약, 핵심 메커니즘의 원문 예, 사례는 두 자료가 밝힌 내용을 AX Partners가 다시 정리한 것입니다. 기술 디테일과 현업 실행 디테일의 도구 구성, JSON 예시, 캐시, 권한 범위, 수치 기준, 역할과 일정, 그리고 디테일 절의 표는 실제로 돌릴 때 필요한 것을 새로 작성한 가상 예시이며 인포그래픽은 모두 새로 그렸습니다. 전체 내용은 원문에서 볼 수 있습니다.