How U Mobile built agentic telco operations with Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

U Mobile은 Amazon Bedrock AgentCore 기반 AiDaH로 6개 사업 부문의 150개 이상 운영 시나리오를 지원하며, 내부 측정에서 주요 유형의 장애 티켓이 최대 84.5% 감소했다고 보고했다.

📌 핵심 요약

• U Mobile의 정보시스템 부문(ISD)은 AWS 및 AWS 파트너 Axrail과 함께 AiDaH를 구축해, 여러 시스템에 분산된 로그·가입자 자격·업무 정책을 조사하고 해결 방안을 제안하는 통신 운영 업무를 연결했다.
• AiDaH는 2025년 말 2개 시범 에이전트로 구상을 시작해 2026년 1분기 4개 에이전트·20개 운영 시나리오를 시험했으며, 2026년 3분기에는 8개 에이전트로 L2 콜센터·지점 사용자 50명에게 서비스를 개시했다. 현재 6개 사업 부문의 150개 이상 문서화된 운영 시나리오를 지원하며, 주요 유형의 장애 티켓 감소율은 내부 측정 기준 최대 84.5%다.
• 6계층 아키텍처는 사용자 인터페이스, 오케스트레이션, 전문 에이전트, 게이트웨이·백엔드 API, 데이터·지식, 운영 시스템으로 구성된다. 요청의 약 70%는 모델 호출 없는 키워드 매칭, 20%는 경량 모델 분류, 10%는 전체 오케스트레이터를 통해 처리된다.
• Amazon Bedrock AgentCore의 관리형 Runtime과 Memory는 에이전트 인프라 운영 및 별도 대화 상태 저장소 구축 부담을 줄인다. 전문 에이전트는 A2A로 협업하고, Gateway는 MCP 인터페이스로 백엔드를 연결하며, 새 운영 영역은 게이트웨이와 MCP 도구 정의를 추가하는 방식으로 확장한다.
• AiDaH는 6단계 역할 기반 접근 제어, 신원·토큰 검증, Amazon Bedrock Guardrails, 민감 필드 마스킹, VPN 연결과 감사 기록을 적용한다. 실제 가입자 계정의 변경은 담당자 확인 후 실행하며, 부가상품 구매 실패 사례에서는 3일간 여러 채널에서 30회 넘게 반복된 시도의 공통 원인인 미처리 주문을 찾아 해결 절차와 함께 제시했다.

🧩 주요 포인트

1. 분산된 조회와 원인 분석을 연결 → 응답 작성 지원을 넘어 조사·해결안 제시까지 자동화하되, 실제 가입자 계정 변경에는 사람의 확인을 유지한다.
2. 약 70%·20%·10%의 3단계 라우팅과 관리형 Runtime·Memory 활용 → 요청 복잡도에 맞춰 모델 사용을 배분하고 인프라·대화 상태 관리 부담을 줄이는 구조다.
3. A2A 협업과 MCP 연결의 공통 기반 → 새 운영 영역마다 전체 처리 흐름을 다시 만들 필요를 줄인다. 최대 84.5%의 티켓 감소는 주요 유형에 대한 내부 측정치이므로 전체 업무의 동일한 개선율로 일반화할 수 없다.

🧠 상세 정리

1. 분산된 통신 운영에서 발생한 조정 비용

말레이시아의 최신 5G 네트워크 사업자로 소개된 U Mobile은 지속적인 자동화로 적은 자원으로 운영 역량을 확대해 왔으며, AiDaH도 이 연장선에서 출발했다. 가입자가 데이터 부가상품을 구매하지 못하면 상담원은 인터페이스 로그에서 오류 코드를 찾고, 업무 지원 시스템 API로 가입 자격을 확인한 뒤, 내부 지식 기반에서 적용할 정책을 조회해야 했다. 업무 지원·고객 관계 관리, 번호이동, 빅데이터 분석, 인프라 모니터링 시스템이 온프레미스와 클라우드에 분산돼 있어 단순한 진단도 여러 시스템과 포털 사이의 이동을 요구했다. 해결되지 않은 문의는 백엔드 IT 조직으로 이관돼 가입자의 대기 시간이 늘었고, 새 운영 영역을 추가할 때마다 개별 통합을 만드는 부담도 발생했다. 이에 ISD는 실시간 백엔드 조정을 뜻하는 Reach, 다단계 근본 원인 분석을 위한 추론을 뜻하는 Depth, 역할 기반 접근 제어와 가드레일을 갖춘 다중 테넌트 기반을 뜻하는 Community를 전략의 세 축으로 삼았다.

2. 지식 기반 시범 서비스에서 운영 플랫폼으로 확장

U Mobile의 ISD는 AWS 및 AWS 파트너 Axrail과 협력해 AI-Driven Agentic Helpdesk인 AiDaH를 구축했으며, 크게 구상하되 작게 시작한다는 원칙을 적용했다. 2025년 말에는 2개 시범 에이전트와 완전관리형 RAG 기능인 Amazon Bedrock Knowledge Bases를 바탕으로 구상을 시작했고, 2026년 1분기에는 내부 IT 헬프데스크에서 4개 에이전트로 20개 운영 시나리오를 시험했다. 이후 2026년 동안 플랫폼을 보강하고 3단계 라우팅을 추가했으며, 연중반에는 에이전트가 6개로 늘었다. 2026년 3분기에는 8개 에이전트로 L2 콜센터와 지점 사용자 50명에게 서비스를 개시했고, 여정 시작 후 1년 이내에 6개 사업 부문의 150개 이상 문서화된 운영 시나리오를 처리하게 됐다고 원문은 설명한다. 주요 유형의 장애 티켓은 U Mobile 내부 측정에서 최대 84.5% 감소했지만, 제공된 본문에는 유형별 측정 조건이나 전체 티켓에 대한 감소율이 제시되지 않았다.

3. 조사를 수행하는 에이전트와 사람의 변경 승인

원문은 해외에서 모바일 데이터가 작동하지 않는 상황을 통해 일반적인 AI 지원과 AiDaH의 차이를 설명한다. 일반적인 AI 도우미가 응답 초안과 점검 절차를 제안하더라도 담당자는 로밍 상태와 이용 자격을 직접 확인하고 티켓을 생성해야 하지만, AiDaH는 로밍 설정과 국제 데이터 이용 자격을 조사해 구체적인 실패 지점을 찾는다. 이어 초기화할 서비스, 적용할 설정, 네트워크 티켓 필요 여부를 포함한 해결 계획을 구성하고, 담당자가 검토·확인하면 조치가 실행되므로 실제 가입자 계정을 바꾸는 시점의 판단은 사람에게 남는다. 실제 운영 사례에서는 부가상품 구매 실패의 오류 코드인 “Subscriber has pending order”를 추적하고, 가입자가 3일간 여러 채널에서 30회 넘게 같은 구매를 시도했지만 동일한 미처리 주문 때문에 차단됐다는 사실을 확인했다. AiDaH는 이전에 여러 시스템을 수작업으로 조사해야 얻을 수 있었던 근본 원인과 해결 절차를 하나의 응답으로 제시했다.

4. 6계층 구조와 비용을 고려한 요청 분기

AiDaH는 아시아 태평양 싱가포르 리전의 Amazon Bedrock AgentCore를 기반으로 운영되며, 사용자 인터페이스부터 실제 운영 시스템까지 6개 계층으로 구성된다. 첫 계층은 직원들이 이미 사용하는 Microsoft Teams를 주요 접점으로 삼고, Amazon CloudFront로 제공하며 AWS WAF로 보호하는 웹 포털, AWS Lambda 백엔드, 프로그램 호출용 REST API도 제공한다. 두 번째 오케스트레이션 계층에서는 모든 요청에 역할 기반 접근 제어, 신원 검증, 가드레일을 적용하는 사전 보안 검사를 수행한 뒤 처리 경로를 정한다. 요청의 약 70%는 결정적 키워드 매칭으로 모델 호출 없이 처리하고, 20%는 경량 모델로 분류하며, 나머지 10%만 전체 오케스트레이터를 사용한다. 이는 요청을 충분한 확신으로 처리할 수 있는 경로 가운데 가장 저렴한 경로를 선택하는 설계이며, 제공된 본문에는 이 라우팅으로 절감한 실제 비용 금액은 제시되지 않았다.

5. 전문 에이전트의 협업과 백엔드 연결

세 번째 계층에는 고객 관계 관리, 고객 문제 관리, 번호이동, 주문·SIM 운영, 인프라 모니터링, 빅데이터 분석, 클라우드 비용 관리, 재무 운영을 담당하는 8개 전문 에이전트가 배치된다. 이들은 Agent2Agent인 A2A 프로토콜로 하위 작업을 위임하며, 단일 에이전트로 처리하기 어려운 여러 시스템에 걸친 업무를 함께 수행한다. 네 번째 계층의 AgentCore Gateway는 U Mobile의 백엔드를 통일된 Model Context Protocol인 MCP 인터페이스로 노출하고, 각 게이트웨이 뒤의 AWS Lambda 함수나 MCP 서버가 에이전트의 요청을 해당 시스템 호출로 변환한다. 각 도구는 입력과 출력의 형식을 제공하므로 에이전트는 도구 이름과 스키마를 기준으로 사용할 기능을 선택하며, 호출에 필요한 OAuth 권한 부여는 Amazon Cognito가 중개한다. 이 구조는 새 운영 영역을 연결하는 접점을 게이트웨이와 MCP 도구 정의로 모으면서, 에이전트 간 협업을 통해 여러 영역의 결과를 하나의 설명으로 결합하도록 한다.

6. 지식·대화 맥락·접근 권한과 운영망 연결

다섯 번째 데이터·지식 계층은 Amazon Bedrock Knowledge Bases와 Amazon OpenSearch Serverless 벡터 저장소를 사용해 관리되는 콘텐츠를 응답의 근거로 제공한다. 지식 콘텐츠는 공통 기업 지식 기반과 별도의 재무 자료군으로 구성되며, AgentCore Memory는 가입자 번호, 주문 ID, 이전 조사 결과 같은 대화 맥락을 여러 차례의 대화에 걸쳐 유지한다. Amazon DynamoDB에는 6단계 역할 기반 접근 제어 모델과 세션 메타데이터를 저장하므로, 대화 맥락 유지와 권한·세션 정보 관리는 서로 구분된 역할을 맡는다. 여섯 번째 계층의 온프레미스·클라우드 운영 시스템은 AWS Transit Gateway와 AWS Site-to-Site VPN으로 연결되며, 원문은 이 경로를 공용 인터넷에 노출되지 않는 IPsec 암호화 터널로 설명한다. 관리형 에이전트 실행 환경과 내장 메모리는 별도 에이전트 인프라 및 대화 상태 저장소를 운영할 필요를 줄인다는 점에서 플랫폼 선택의 핵심 이유였다.

7. 번호이동 문의가 처리되는 실제 흐름

직원이 Microsoft Teams의 AiDaH 채널에 번호이동 유입 상태를 질문하면, 메시지를 받은 AWS Lambda가 요청과 호출자의 연동 신원 정보를 오케스트레이터로 전달한다. 오케스트레이터는 Amazon DynamoDB의 6단계 역할 기반 접근 제어 모델로 호출자를 확인하고, AgentCore Identity가 발급한 토큰을 검증하며, 입력 프롬프트에 Amazon Bedrock Guardrails를 적용해 하나라도 통과하지 못하면 요청을 중단한다. 이후 인식 가능한 표현은 키워드 경로로, 모호한 표현은 경량 분류기로, 새롭거나 여러 부분으로 구성된 질문은 전체 오케스트레이터로 보내고, 선택된 전문 에이전트는 AgentCore Runtime 세션에서 이전 대화 맥락을 복원한다. 에이전트는 Gateway에서 사용 권한이 있는 도구를 찾아 호출하고, Lambda 함수나 MCP 서버가 이를 번호이동 시스템 요청으로 변환해 Transit Gateway와 VPN을 거쳐 전달하며, 반환되는 민감 필드는 모델에 도달하기 전에 마스킹한다. 번호이동 문제가 청구 차단과 연결된 경우에는 A2A로 업무 지원 시스템 에이전트에 작업을 위임하고, 결과를 합친 뒤 지식 기반을 근거로 설명과 해결안을 Teams에 반환해 사람의 확인을 받는다.

8. 관리형 실행·추적 기능과 공통 기반의 확장성

원문 마지막의 기능 표는 AgentCore Runtime이 AiDaH와 하위 에이전트를 자동 확장되는 관리형 컨테이너로 실행하고, Memory가 여러 대화 차례에 걸쳐 가입자 번호와 주문 ID, 이전 조사 결과를 유지한다고 정리한다. Identity는 권한 있는 사용자만 에이전트를 호출하도록 단기 액세스 토큰을 발급하고, Gateway는 통합된 보안 MCP 인터페이스를 통해 백엔드와 연결하는 역할을 맡는다. 앞선 요청 흐름 설명에 따르면 AgentCore Observability는 프롬프트, 도구 호출, 토큰 수, 지연 시간의 전체 추적 정보를 Amazon CloudWatch에 기록하며, AWS CloudTrail은 관련 API 활동을 기록한다. 새 운영 영역을 추가할 때는 도구 탐색·호출 단계에 게이트웨이와 MCP 도구 정의를 추가하고, 사용자 접점부터 에이전트 실행까지의 단계와 협업·응답 단계는 유지하므로, 원문은 이 안정적인 공통 기반이 영역별 추가 비용을 낮추는 요인이라고 설명한다. 다만 제공된 본문은 기능 표의 Observability 설명 도중에 끝나며, 앞부분에서 예고한 별도 보안 기반 설명과 명세 중심 개발 방법의 구체적인 내용은 포함하지 않는다.

🧾 핵심 주장 / 시사점

• AiDaH의 운영상 변화는 응답 문장을 더 잘 만드는 데서 그치지 않고, 여러 시스템의 조회 결과를 연결해 원인과 해결안을 담당자에게 전달하는 데 있다.
• 키워드 매칭·경량 분류·전체 오케스트레이터의 단계적 사용과 공통 MCP 연결 구조는 모델 사용 비용과 새 운영 영역의 통합 부담을 함께 관리하려는 설계다.
• 최대 84.5%의 티켓 감소는 주요 유형에 대한 U Mobile 내부 측정 결과다. 전체 티켓 감소율이나 비용 절감액까지 입증한 수치로 해석하기에는 제공된 근거가 제한적이다.

✅ 액션 아이템

• 최대 84.5%의 장애 티켓 감소를 해석할 때 주요 유형 대상의 내부 측정이라는 범위를 명시.
• 약 70%·20%·10%의 3단계 라우팅을 기준으로 요청 복잡도에 따른 모델 사용 배분을 검토.
• 새 운영 영역 확장 시 A2A 협업과 MCP 연결의 적용 범위, 실제 가입자 계정 변경에 대한 담당자 확인을 함께 검토.

❓ 열린 질문

• 최대 84.5%의 장애 티켓 감소는 어떤 주요 유형과 비교 기간을 대상으로 측정됐는가?
• 약 70%·20%·10%의 3단계 라우팅 비중은 요청 복잡도와 운영 영역이 달라질 때 어떻게 변하는가?
• 150개 이상 운영 시나리오에서 실제 가입자 계정 변경에 대한 담당자 확인은 어떤 기준과 범위로 적용되는가?