U Mobile이 Amazon Bedrock AgentCore로 에이전틱 통신사 운영을 구축한 방법

말레이시아의 최신 5G 네트워크 제공업체인 U Mobile은 항상 지속적인 자동화를 통해 더 적은 자원으로 더 많은 성과를 내는 린(lean) 방식으로 통신사 운영을 수행해 왔습니다. 새로운 AI 기능이 제공되자 U Mobile은 기본적인 생산성 향상을 넘어 운영 효율성을 강화하는 방법을 모색했습니다. 진정한 기회는 더 상류, 즉 운영 팀이 문제를 처음부터 진단하고 해결하는 방식에 있었습니다. 이러한 린 운영 원칙이 AiDaH의 기반이 되었습니다. 일회성 기술 이니셔티브가 아니라, 복잡성을 추가하지 않고 운영을 간소화하고 역량을 확장해 온 오랜 여정의 다음 단계였습니다.

가입자가 데이터 추가 상품을 구매할 수 없을 때, 이를 해결하는 것은 단일 문제가 아닙니다. 이것은 조율(coordination) 문제입니다. 고객 서비스 상담원은 에러 코드에 대한 인터페이스 로그를 조회해야 합니다. 그런 다음 동일한 상담원이 비즈니스 지원 시스템 API를 통해 가입자 자격을 조회하고, 내부 지식 베이스에서 적용 가능한 비즈니스 정책을 교차 확인해야 합니다. 이 모든 과정은 응답 한 마디를 작성하기 전에 여러 시스템에 걸쳐 이루어집니다. 그리고 이것이 실패하면 티켓이 백엔드 IT 팀으로 에스컬레이션되고 가입자는 더 오래 기다려야 합니다.

전통적인 자동화 도구는 상담원이 더 나은 응답을 작성하도록 도울 수 있습니다. 하지만 여러 시스템을 탐색하고, 결과를 분석하고, 시정 조치를 제안하는 것은 불가능합니다. 이 격차를 해소하려면 Amazon Bedrock AgentCore 위에 구축된 에이전틱 아키텍처가 필요합니다.

U Mobile의 정보시스템 부서(ISD)가 바로 그것을 구축했습니다. AWS 및 AWS 파트너인 Axrail과 협력하여 Amazon Bedrock AgentCore 위에 AiDaH(AI-Driven Agentic Helpdesk)를 만들었으며, 이는 어떤 프레임워크나 모델로도 에이전트를 규모에 맞게 구축, 연결, 최적화할 수 있는 플랫폼입니다. 두 가지 기능이 이 선택을 결정했습니다. 관리형 에이전트 런타임 덕분에 운영해야 할 에이전트 인프라가 없었습니다. 내장 메모리 기능은 별도의 상태 저장소를 구축하지 않고도 대화 컨텍스트를 여러 턴에 걸쳐 유지했습니다. 여정을 시작한 지 1년 만에 AiDaH는 6개 사업 부문에 걸쳐 150개가 넘는 문서화된 운영 시나리오를 처리하고 있습니다. U Mobile의 내부 측정 결과에 따르면 주요 카테고리에서 장애 티켓 건수가 최대 84.5% 감소했습니다.

이 게시물에서는 AiDaH의 기반이 되는 6계층 아키텍처를 살펴봅니다. 이어서 플랫폼 아래의 보안 기반을 설명하고, 팀이 구축에 사용한 스펙 기반(spec-driven) 방법론에 대한 간단한 소개로 마무리합니다.

문제: 너무 많은 시스템, 너무 많은 마찰

U Mobile의 IT 환경은 현대 통신 산업의 전형적인 복잡성을 반영합니다. 비즈니스 지원 및 고객 관계 관리 시스템, 이동번호 이동성(number portability) 플랫폼, 빅데이터 분석, 인프라 모니터링 도구가 온프레미스와 클라우드에 걸친 하이브리드 환경에서 운영되고 있습니다.

AiDaH 이전에는 이러한 파편화로 인해 루틴한 진단조차도 별도의 시스템과 포털에 걸쳐 로그를 수동으로 확인하고, 가입자 자격을 조회하고, 지식 베이스에서 비즈니스 정책을 참조해야 했습니다. 매번 조회는 컨텍스트 전환이었고, 매번 컨텍스트 전환은 시간 낭비였으며, 해결되지 않은 문의는 백엔드 IT 팀으로의 에스컬레이션으로 이어졌습니다. 추가 운영 도메인으로 커버리지를 확장하는 것은 문제를 더욱 악화시켰는데, 새로운 시스템마다 일반적으로 맞춤형 통합이 필요했기 때문입니다.

ISD 팀의 전략은 세 가지 축에 기반했습니다.

1. Reach: 백엔드 시스템 전반에서 실시간으로 조율하는 에이전트.
2. Depth: 다단계 근본 원인 분석을 위한 사고 연쇄(chain-of-thought) 추론.
3. Community: 역할 기반 접근 제어와 내장 가드레일을 갖춘 안전한 멀티 테넌트 프레임워크로, 모든 부서에서 사용 가능.

여정: 지식 베이스에서 에이전틱 플랫폼으로

AiDaH는 '크게 생각하고, 작게 시작하라'는 원칙으로 시작되었습니다. U Mobile은 2025년 말에 두 개의 파일럿 에이전트와 완전관리형 검색 증강 생성(RAG) 기능인 Amazon Bedrock Knowledge Bases로 개념화를 시작했습니다. 2026년 1분기 파일럿을 통해 4개의 에이전트와 20개의 운영 시나리오로 내부 IT 헬프데스크를 온라인으로 전환했습니다. 2026년 내내 플랫폼은 강화되고 확장되어 3계층 라우팅을 추가했고 연중 무렵 6개의 에이전트에 도달했습니다. AiDaH는 2026년 3분기에 8개의 에이전트로 50명의 L2 콜센터 및 지점 사용자에게 공식 출시되었으며, 현재 150개가 넘는 문서화된 운영 시나리오를 다루고 있습니다.

실무에서 에이전틱이 의미하는 것

전통적인 AI 지원과 에이전틱 AI의 차이는 실제 사례를 통해 가장 잘 설명됩니다.

전통적인 AI 어시스턴트의 경우, '해외에서 모바일 데이터가 작동하지 않음'을 처리하는 지원 상담원은 응답 작성 도움과 몇 가지 권장 문제 해결 단계를 받지만, 로밍 상태 확인, 자격 검증, 티켓 발급, 최종 답변 전송은 여전히 수동으로 수행해야 합니다.

AiDaH의 경우, 시스템이 가입자의 로밍 구성을 독립적으로 확인하고, 국제 데이터 자격을 검증하며, 특정 장애 지점을 식별합니다. 그런 다음 시정 계획을 수립합니다. 어떤 서비스를 재설정할지, 어떤 구성을 푸시할지, 네트워크 티켓이 필요한지 여부 등입니다. 지원 상담원이 검토하고 확인하면 조치가 실행됩니다. 이전에는 상담원의 시간을 소모하던 조사 과정이 이제는 상담원이 첫 줄을 읽기 전에 완료됩니다. 사람의 의사결정 지점은 중요한 곳, 즉 실시간 가입자 계정에 변경 사항이 발생하는 순간에 그대로 유지됩니다.

한 프로덕션 사례에서 한 가입자가 애드온을 구매할 수 없다고 보고했습니다. AiDaH는 이 장애를 “Subscriber has pending order.”라는 오류 코드로 추적했습니다. 또한 해당 고객이 3일 동안 여러 채널을 통해 동일한 구매를 30회 이상 시도했으며, 모든 시도가 동일한 미결 주문(pending order) 때문에 차단되었음을 밝혀냈습니다. AiDaH는 근본 원인과 해결 절차를 단일 응답으로 제시했습니다. 이전에는 여러 시스템에 걸친 수동 조사가 필요했을 것입니다.

아키텍처: 6개의 계층, 하나의 인터페이스

AiDaH는 Amazon Bedrock AgentCore 기반의 계층화된 아키텍처로 실행되며, 아시아 태평양(싱가포르) 리전에 배포되었습니다. 직원들은 Microsoft Teams를 통해 상호작용하며, 이는 대부분의 사용자가 이미 일하는 환경에서 만나주기 위한 의도적인 선택으로, 새로운 애플리케이션을 배우거나 포털을 전환할 필요가 없습니다.

다음 다이어그램은 이 계층들이 어떻게 맞물려 있는지 보여줍니다.

그림 1: AiDaH의 계층화된 아키텍처

그림 1에서 보듯이, 이 플랫폼은 6개의 계층으로 구성되어 있습니다.

계층 1: 직원 인터페이스

직원들은 Microsoft Teams와 Amazon CloudFront가 서비스하고 AWS WAF로 보호되는 웹 포털을 통해 AiDaH에 접속하며, AWS Lambda 백엔드와 프로그래밍 방식 트리거를 위한 REST API가 함께 제공됩니다.

계층 2: 오케스트레이션

Amazon Bedrock AgentCore 기반의 라우팅 두뇌입니다. 모든 요청은 역할 기반 액세스 제어, 신원 검증, 가드레일을 포괄하는 사전 보안 점검(pre-flight security check)을 통과한 후, 비용 최적화된 라우팅 계층에 들어갑니다. 약 70퍼센트의 요청은 모델 호출 없이 결정론적 키워드 매칭으로 처리되고, 20퍼센트는 경량 모델로 분류되며, 10퍼센트만 전체 오케스트레이터를 필요로 합니다. 해당 요청을 확실하게 처리할 수 있는 가장 저렴한 경로가 실행됩니다.

계층 3: 전문 에이전트

고객 관계 관리, 고객 문제 관리, 번호 이동성, 주문 및 SIM 운영, 인프라 모니터링, 빅데이터 분석, 클라우드 비용 관리, 재무 운영을 아우르는 8명의 전문가입니다. 이들은 Agent2Agent(A2A) 프로토콜로 통신하며, 이를 통해 하위 작업을 위임하고 어떤 단일 에이전트로도 감당할 수 없는 교차 시스템 워크플로를 완료할 수 있습니다.

계층 4: 게이트웨이 및 백엔드 API

Amazon Bedrock AgentCore의 기능인 AgentCore Gateway가 U Mobile의 백엔드를 통합된 Model Context Protocol(MCP) 인터페이스를 통해 에이전트에 노출합니다. 각 게이트웨이 뒤에는 에이전트의 의도를 특정 시스템에 대한 호출로 변환하는 AWS Lambda 함수와 MCP 서버가 있습니다.

계층 5: 데이터 및 지식

완전관리형 RAG 기능인 Amazon Bedrock Knowledge Bases는 Amazon OpenSearch Serverless 벡터 스토어를 사용하여 에이전트의 응답을 관리되는 콘텐츠에 기반시킵니다. 콘텐츠는 공유 엔터프라이즈 지식 베이스와 별도의 재무 코퍼스로 구성됩니다. Amazon Bedrock AgentCore의 기능인 AgentCore memory가 대화 맥락을 여러 턴에 걸쳐 유지하고, Amazon DynamoDB에는 6계층 역할 기반 액세스 제어 모델과 세션 메타데이터가 저장됩니다.

계층 6: 운영 시스템

U Mobile의 온프레미스 및 클라우드 운영 시스템은 AWS Transit Gateway와 퍼블릭 인터넷 노출이 없는 IPsec 암호화 터널인 AWS Site-to-Site VPN을 통해 접근됩니다.

요청이 계층을 통과하는 방식

단일 요청을 추적하면 계층 간의 상호작용이 구체적으로 드러납니다. 지원 요원이 Microsoft Teams의 AiDaH 채널에 port-in 상태 질문을 입력하는 경우를 생각해 봅시다.

1. 인터페이스: Teams 메시지는 AWS Lambda 함수에 도달하고, 이 함수가 요청과 호출자의 페더레이션된 신원을 오케스트레이터에 전달합니다.
2. 사전 점검: 오케스트레이터는 Amazon DynamoDB에 저장된 6계층 역할 기반 액세스 제어 모델을 기준으로 호출자를 확인하고, Amazon Bedrock AgentCore의 기능인 AgentCore Identity가 발급한 토큰을 검증하며, 수신 프롬프트에 Amazon Bedrock Guardrails를 적용합니다. 이 검사 중 하나라도 실패한 요청은 여기서 중단됩니다.
3. 라우팅: 오케스트레이터는 요청을 처리할 수 있는 가장 저렴한 계층을 선택합니다. “port-in status”와 같이 인식된 문구는 결정론적으로 매칭되어 모델 호출을 완전히 건너뜁니다. 모호한 표현은 경량 분류기로 전달되고, 새롭거나 여러 부분으로 된 질문은 전체 오케스트레이터로 전달됩니다.
4. 에이전트 인스턴스화: 선택된 전문 에이전트는 Amazon Bedrock AgentCore의 기능인 AgentCore runtime에서 세션으로 실행됩니다. AgentCore memory가 대화를 복원(rehydrate)하여 에이전트가 사용자에게 반복해서 묻는 대신 이전 턴의 가입자 번호와 기존 조사 결과를 이어받습니다.
5. 도구 검색 및 호출: 에이전트는 AgentCore Gateway에 자신이 사용할 자격이 있는 도구를 조회합니다. 각 게이트웨이는 백엔드를 타입화된 입출력을 갖는 MCP 도구로 게시하므로, 에이전트는 하드코딩된 통합 로직이 아닌 이름과 스키마로 도구를 선택합니다. Amazon Cognito가 해당 호출에 대한 OAuth 인증을 중개합니다.
6. 백엔드 호출: 게이트웨이의 Lambda 함수 또는 MCP 서버가 도구 호출을 대상 시스템에 대한 요청으로 변환하고, AWS Transit Gateway와 Site-to-Site VPN 터널을 통과하여 온프레미스 번호 이동성 플랫폼에 도달합니다. 민감한 필드는 응답이 모델에 도달하기 전에 돌아오는 길에 마스킹됩니다.
7. 추론 및 협업: 답변이 여러 도메인에 걸쳐 있는 경우, 에이전트는 Agent2Agent 프로토콜을 통해 위임합니다. 예를 들어 번호이동(port-in) 문의가 과금 차단 문제로 판명되면 비즈니스 지원 시스템 에이전트에게 인계되고, 그 결과는 하나의 서술로 병합됩니다.
8. 응답 및 감사: 에이전트는 Amazon Bedrock Knowledge Bases를 근거로 설명을 확보한 후, 조사 결과와 제안된 조치를 Teams로 반환하여 사람의 확인을 받습니다. Amazon Bedrock AgentCore의 기능인 AgentCore Observability는 프롬프트, 도구 호출, 토큰 수, 지연 시간의 전체 추적 기록을 Amazon CloudWatch에 기록하고, AWS CloudTrail이 해당 API 활동을 기록합니다.

새로운 운영 도메인을 온보딩할 때는 5단계에서 게이트웨이와 해당 MCP 도구 정의를 추가합니다. 1–4단계, 그리고 7단계와 8단계는 변경되지 않습니다. 안정적인 코어가 있기에 새 도메인 하나를 추가할 때마다 드는 한계 비용이 낮게 유지됩니다.

프로덕션 환경의 Amazon Bedrock AgentCore 기능

다음 표는 각 AgentCore 기능을 AiDaH에서 수행하는 역할과 매핑한 것입니다.

기반 보안 확보

가입자 데이터, 청구 시스템 및 네트워크 인프라에 접근하는 에이전틱 AI 플랫폼을 배포하는 일은 애플리케이션 수준의 보안 이상을 요구합니다. 안전한 클라우드 기반이 필요합니다. U Mobile은 두 가지 방식으로 접근했습니다. 기반이 되는 AWS Landing Zone을 검증·강화하고, Amazon Bedrock AgentCore의 보안 기능 위에 구축한 것입니다.

Landing Zone 보안 – AiDaH를 프로덕션으로 확장하기 전에 U Mobile은 AWS에 의뢰하여 플랫폼을 호스팅하는 Landing Zone에 대한 Well-Architected Security Review를 수행했습니다. 이 검토는 AWS 보안 모범 사례에 따라 환경을 검증했습니다. 인프라 보호는 AWS Control Tower 가드레일과 AWS Organizations 서비스 제어 정책을 통해 최우선으로 이루어졌습니다. 이어서 검토는 중앙화된 자격 증명 페더레이션과 인그레스 및 이그레스에 대한 네트워크 보안 제어를 살폈습니다. AWS Security Hub의 통합 보안 결과와 모든 아키텍처 계층 전반의 암호화 표준으로 평가를 마무리했습니다. 그 결과는 두 가지였습니다. 모든 AiDaH 구성 요소가 독립적으로 검증된 기반 위에서 작동한다는 확신, 그리고 지속적인 개선을 위한 우선순위가 정해진 로드맵입니다.

애플리케이션 계층 보안 – 모든 에이전트 행동은 특정 인증된 사용자로 추적됩니다. 직원은 Microsoft Entra ID를 통해 페더레이션하고, AgentCore Identity가 에이전트 호출을 승인하는 수명이 짧은 토큰을 발급합니다. Amazon Cognito는 게이트웨이에서 OAuth 인증을 중개합니다. 따라서 에이전트는 호출한 사용자가 볼 자격이 있는 시스템에만 접근할 수 있습니다. 6단계 역할 기반 액세스 제어 모델이 에이전트별, 도구별, 데이터 소스별로 권한을 강제합니다. 민감한 가입자 데이터는 모델에 도달하기 전에 게이트웨이에서 마스킹되며, Amazon Bedrock Guardrails가 콘텐츠 정책을 강제합니다.

모든 프롬프트, 도구 호출 및 응답은 AgentCore Observability를 통해 Amazon CloudWatch Logs로 스트리밍되고, AWS CloudTrail이 기반이 되는 API 활동을 기록합니다. 이 감사 추적이 중요합니다. AiDaH는 현재 U Mobile의 L2 지원 표준 운영 절차에 명문화되어 있으며 운영 감사를 받습니다. 모든 컴퓨팅은 프라이빗 VPC 서브넷에서 실행되고, 온프레미스 연결은 오직 암호화된 VPN을 통해서만 이루어지며, AWS Key Management Service (AWS KMS)가 저장 및 전송 중 데이터의 암호화 키를 관리합니다.

문서화된 150개 이상의 운영 시나리오

AiDaH가 다루는 시나리오는 현재 6개 도메인에 걸쳐 있습니다. 다음 표는 각 도메인의 커버리지를 요약한 것입니다.

진전 측정: AI 역량 모델

진전 상황을 추적하고 조직 전체의 공통 어휘를 확립하기 위해, 팀은 기본 디지털 접근부터 자율적인 자가 치유 운영에 이르는 8단계 AI 역량 모델을 채택했습니다. 이 모델은 TM Forum의 Autonomous Networks 성숙도 수준을 비롯한 업계 사고를 바탕으로 하며, U Mobile의 운영 환경에 맞게 조정되었습니다. 다음 표는 8개 수준을 나열한 것입니다.

AiDaH는 최초 파일럿 후 9개월 만에 Level 7에 도달했습니다. 전문 에이전트들이 협업하고, 도구를 사용하며, 통제된 지식을 검색하고, 여러 도메인에 걸친 운영 의사결정을 지원합니다. 인간의 개입 없이 문제를 탐지, 진단, 해결하는 Level 8이 현재의 목표입니다.

도입 촉진: 도구에서 팀원으로

AiDaH를 배포하는 것이 하나의 과제였습니다. 사람들이 이를 신뢰하고 사용하도록 만드는 것은 또 다른 과제였습니다.

ISD는 도입이 기술 문제가 아니라 행동 변화의 과제라는 점을 일찌감치 인식했습니다. 직원들은 익숙한 워크플로우, 신뢰하는 도구, 친숙한 에스컬레이션 경로에 익숙해져 있었습니다. AiDaH의 도입은 깊이 자리 잡은 습관을 바꾸도록 요구하는 것이었습니다. 또한 AI가 정보를 검색하고, 문제를 진단하며, 그들을 대신해 다음 단계를 제안하도록 신뢰하는 것을 의미했습니다.

팀은 지향적 프롬프팅에 의존했습니다. 개방형 탐색을 기대하는 대신, ISD는 일반적인 시나리오를 위한 구조화된 프롬프트 템플릿을 제공했습니다. 이 템플릿들은 “AiDaH에게 무엇이든 물어보세요”를 “여기에 청구서 확인이나 포트인 상태를 요청하는 정확한 방법이 있습니다”로 바꾸어 놓았습니다. 이는 망설임을 줄였고 즉각적이고 실질적인 결과를 낳았습니다. 응답이 빠르고, 정확하며, 실행 가능하다는 것이 입증되자 소문이 퍼졌습니다. 내부 설문에서 이 플랫폼은 사용 용이성에서 5점 만점에 4.6점을 받았으며, 이제 일일 사용은 최전선 팀들 사이에서 일상이 되었습니다.

가장 명확한 신호는 AiDaH가 U Mobile의 L2 지원 표준 운영 절차(SOP)에 공식적으로 편입되었을 때 나타났습니다. 선택적 도구에서 감사 가능한 SOP로의 전환이 실험에서 운영으로의 이행을 보여주는 지점이었습니다.

ISD의 접근 방식은 완성된 솔루션을 구매하는 것이 결코 아니었습니다. 그 여정을 소유하는 것이었습니다. 즉, 내부 AI 역량을 구축하고, 책임 있는 실험을 장려하며, 실용적인 AI 활용 능력을 일상 운영 리듬에 통합하는 것이었습니다. AiDaH 자체를 넘어, ISD는 팀들이 사용 사례, 기법, 초기 실험을 공유하는 전담 내부 AI 채널을 운영하고 있습니다. 목표는 AI 전문성을 한 팀에 집중시키는 것이 아니라 분산시켜, 모든 부서가 통제된 가드레일 내에서 AI를 자신 있게 사용할 수 있도록 하는 것입니다. 진전은 순탄하지 않았습니다. 그 과정에는 좌절과 재조정이 있었으며, 그 하나하나가 플랫폼과 팀을 더욱 강하게 만들었습니다.

결과

U Mobile의 내부 측정에 따르면, 2026년 1월부터 9월 사이 세 개의 주요 카테고리에서 월간 장애 티켓(volume)이 감소했습니다:

• 프로비저닝 및 네트워크 티켓은 84.5 퍼센트 감소했습니다.
• 일반 문의는 81.6 퍼센트 감소했습니다.
• 청구 및 과금은 48.7 퍼센트 감소했습니다.

팀의 구축 방법: Kiro를 활용한 스펙 기반 개발

U Mobile은 스펙 기반 개발을 중심으로 구축된 AWS의 에이전틱 IDE인 Kiro를 사용하여 AiDaH의 개발을 가속화했습니다. Kiro에서는 새로운 기능이 프롬프트가 아닌 스펙으로 시작됩니다: 요구 사항, 설계, 작업 분해를 먼저 작성하고 검토한 후, 그 합의된 산출물에 기반하여 코드 생성이 이루어집니다. AiDaH에서 이것은 에이전트와 도구 경계에서 가장 중요했습니다. 새로운 운영 도메인이 추가될 때마다 새로운 게이트웨이, MCP 도구 정의 세트, 그리고 누가 이를 호출할 수 있는지를 결정하는 역할 기반 액세스 제어 항목이 필요합니다. 이를 먼저 문서화함으로써 각 새로운 도메인은 새로운 설계 작업이 아닌 반복 가능한 작업 단위가 되었습니다.

지원 도구체인은 전통적입니다. 팀은 로컬 개발에는 에이전트 훅과 MCP 통합을 갖춘 Kiro IDE를, 파이프라인 자동화에는 Kiro CLI를 사용했습니다. 소스 컨트롤은 GitLab에서运行하며, AWS CodePipeline과 AWS CodeBuild가 지속적 통합을 주도하고, 컨테이너 이미지는 Amazon Elastic Container Registry(Amazon ECR)에 게시되며, SonarQube가 지속적인 코드 품질 검사를 제공합니다. 스펙이 코드 생성을 주도했습니다. 이러한 규율 덕분에 소규모 팀이 2개 사용 사례의 개념 증명에서 12주 스프린트 주기로 150개가 넘는 문서화된 사용 사례로 성장할 수 있었습니다.

주요 아키텍처 결정

여러 선택이 AiDaH가 개념 증명에서 프로덕션 플랫폼으로 확장되는 방식을 형성했습니다. 그중 네 가지가 두드러지며, 각각은 다음 운영 도메인을 추가하는 비용을 줄이거나 플랫폼이 성장하면서도 관리 가능하게 유지하는 데 기여했습니다.

관리형 인프라로서의 AgentCore – 커스텀 에이전트 프레임워크를 구축하는 대신, 팀은 Amazon Bedrock AgentCore의 내장된 확장, 아이덴티티, 메모리, 관찰 가능성 기능을 사용했습니다. AWS가 기본 프로비저닝, 확장, 패치를 관리하여 인프라 엔지니어링의 전체 계층을 없앴습니다.

범용 도구 연결을 위한 MCP – Model Context Protocol 표준화를 통해 AiDaH는 에이전트 로직을 재구축하지 않고도 새로운 백엔드 시스템을 온보딩할 수 있습니다. 각 새로운 운영 도메인에는 새로운 통합 아키텍처가 아닌 새로운 게이트웨이만 필요합니다.

전문가 협업을 위한 A2A – Agent2Agent 프로토콜은 도메인 전문가들이 서로 하위 작업을 위임할 수 있게 합니다. 고객 기록, 인터페이스 로그, 청구 데이터에 걸친 쿼리는 관련 에이전트들 사이에서 자연스럽게 라우팅됩니다.

보안 기반 우선 – 프로덕션으로 확장하기 전에 Landing Zone에서 Well-Architected Security Review를 수행함으로써, 보안 제어가 사후에 덧붙여지는 것이 아니라 모든 새로운 에이전트와 게이트웨이에 상속됩니다.

향후 계획

U Mobile의 로드맵은 폭과 깊이의 확장에 초점을 맞추고 있습니다: 추가 운영 도메인과 백엔드 통합을 온보딩하는 동시에, 플랫폼의 역량을 단일 시스템 쿼리에서 다중 시스템 상관 진단으로 발전시키는 것입니다. 더 장기적인 목표, 즉 역량 모델의 Level 8은 지원 에이전트에게 정보를 제공하는 단계에서 자율적으로 문제를 해결하는 단계로 나아가는 것입니다.

보안 거버넌스도 병행하여 성숙해지고 있습니다. 팀은 NIST SP 800-53, OWASP Top 10 for LLM Applications, CSA AI Trust Framework, MITRE ATLAS와 실무를 정렬하고 있습니다. 말레이시아의 개인정보보호법 및 말레이시아 통신멀티미디어위원회 규정과의 준수도 함께 계속되고 있습니다.

결론

AiDaH는 AI가 보조를 넘어 행동하기 시작할 때 무엇이 달라지는지 보여줍니다. 1년도 채 되지 않아 U Mobile은 2개 에이전트의 개념 증명에서 150개가 넘는 문서화된 운영 시나리오를 서비스하는 8개의 전문 에이전트로 발전했습니다. U Mobile의 내부 측정에 따르면 주요 카테고리에서 장애 티켓이 최대 84.5 퍼센트까지 감소했으며, U Mobile은 이제 이 플랫폼을 공식 L2 지원 절차에 반영했습니다.

우리는 6개 계층을 살펴보고, Teams에서 온프레미스 시스템까지 그리고 다시 돌아오는 요청의 흐름을 따라가며, 프로덕션 확장에 앞서 수행된 Well-Architected Security Review를 설명했습니다. 기술적 기반이 중요했지만, 화려하지 않은 작업도 그러했습니다. 여기에는 확장 전에 Landing Zone을 검증하고, 직원들이 시작 방법을 알 수 있도록 구조화된 프롬프트를 작성하며, 도입을 배포 마일스톤이 아닌 행동 변화 문제로 다루는 것이 포함되었습니다. 유사한 시스템 파편화에 직면한 팀들은 동일한 패턴이 유용하다고 느낄 수 있습니다. 관리형 에이전트 런타임으로 시작하고, 통합 경계에 표준 도구 프로토콜을 추가하며, 확장 후가 아닌 확장 전에 보안 검토를 수행하세요.

방향은 명확합니다: 안전하게 확장하고, 책임 있게 자동화하며, 하나의 신중하고 통제된 단계씩 자율적이고 자가 치유되는 운영을 향해 꾸준히 나아가는 것입니다.

자세히 알아보려면 Amazon Bedrock AgentCore 및 Amazon Bedrock AgentCore Developer Guide를 방문하세요. 스펙 기반 개발을 탐구하려면 Kiro.

저자 소개