A shared agentic platform for Wood Mackenzie, on Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Wood Mackenzie는 에이전트의 운영 전환을 가로막는 중복 인프라와 평가·거버넌스 문제를 줄이기 위해 Amazon Bedrock AgentCore 기반의 공유 플랫폼 APEX를 구축했다.

📌 핵심 요약

• 원문이 인용한 2026년 초까지의 업계 조사에서 최소 한 기능에 에이전트를 운영 규모로 확대한 조직은 약 4분의 1이며, Wood Mackenzie의 내부 파악으로는 AI 개념검증의 88%가 광범위한 배포에 도달하지 못했다. 주요 장애물은 모델보다 평가·관측 가능성, 거버넌스·신원 관리와 중복 인프라 등 아키텍처 문제로 제시된다.
• APEX는 Woody, Lens AI, ST Trading App이 런타임·인증·메모리·도구·평가 기반을 공유하도록 설계됐다. Wood Mackenzie는 관리형 인프라, 모델 중립성, 자동 확장, 기본 제공 가드레일·신원 관리, AWS Enterprise Support를 AgentCore 선택의 핵심 이유로 들었다.
• AgentCore는 다양한 프레임워크와 Amazon Bedrock 외부 모델도 지원하며, 런타임은 세션 격리와 최대 8시간의 실행 창을 제공하고 수천 개의 동시 호출로 확장된다. 서비스별 사용량 과금이 적용되며 I/O 대기 중에는 CPU 요금이 발생하지 않는다. 원문은 에이전트 작업 시간의 30~70%가 대기라고 설명한다.
• APEX는 Okta를 신원 정보의 기준으로 사용하며 사용자 권한을 하위 도구·데이터 호출까지 전달한다. Woodmac Agent Registry는 에이전트·도구·스킬 재사용을 지원하고, AgentCore Gateway와 Policy는 도구 접근 및 Cedar 기반 정책 집행을 담당한다.
• Amazon Bedrock Knowledge Bases 기반 RAG와 AgentCore memory는 각각 사내 콘텐츠 근거와 단기·장기 맥락을 제공한다. AgentCore Observability는 OpenTelemetry 호환 텔레메트리를 Amazon CloudWatch로 보내 요청 추적을 지원하지만, 제공된 원문은 AgentCore Evaluation을 소개하기 시작한 지점에서 끊겨 구체적인 평가 방식이나 도입 성과는 확인할 수 없다.

🧩 주요 포인트

1. Woody·Lens AI·ST Trading App의 공통 기반 통합 → 팀별 인프라 중복을 줄이고 에이전트·도구·평가의 조직 내 재사용을 가능하게 하는 구조.
2. 모델 중립성과 I/O 대기 중 CPU 비과금 → 업무 로직을 유지한 모델 교체와 대기 시간이 긴 에이전트 작업의 비용 관리에 유리하다는 도입 논리.
3. 사용자 권한의 하위 호출 전파, Cedar 정책, 요청 추적 → 접근 통제와 문제 진단을 플랫폼 책임으로 묶되, 평가 효과와 운영 성과는 제공된 원문만으로 검증하기 어려움.

🧠 상세 정리

1. 실험에서 운영으로 넘어갈 때 커지는 아키텍처 부담

원문은 작동하는 에이전트 시제품은 짧은 시간에 만들 수 있지만, 여러 사용자를 대상으로 운영하려면 동시성, 세션 격리, 신원 관리, 영속 상태, 확장과 가드레일이라는 별도의 공학적 과제가 생긴다고 설명한다. 2026년 초까지의 업계 조사에서는 기업의 AI 실험이 거의 보편화됐지만 최소 한 기능에서 에이전트를 운영 규모로 확대한 조직은 약 4분의 1이며, Wood Mackenzie 내부에서는 AI 개념검증의 88%가 광범위한 배포에 이르지 못한 것으로 파악했다. Forrester는 실패 원인을 일반적인 버그보다 모호성, 조정 실패, 예측하기 어려운 시스템 동작에서 찾으며, 원문은 비결정적인 에이전트의 오류를 미리 알아내기 어려운 평가·관측 가능성 문제를 가장 자주 지목되는 단일 장애물로 제시한다. 거버넌스와 신원 관리도 뒤따르는 문제로, 상당수 경영진이 오작동하는 에이전트를 즉시 중단할 수 없다고 보고했으며 팀별 인증·메모리·추적 구현과 모델 고정이 부담을 키운다고 설명한다.

2. 세 애플리케이션을 위한 공유 플랫폼 선택

APEX 도입 전에는 Woody, Lens AI, ST Trading App이 각각 자체 에이전트 스택을 구축하는 방향으로 진행되고 있었으며, 원문은 그대로 두면 런타임과 신원 관리, 관측 기능, 모델 연결을 세 번 구현하게 됐을 것이라고 설명한다. APEX는 Agentic Platform for Energy eXperience의 약자로, 이러한 공통 기반을 한 플랫폼에 모아 각 팀이 제품을 차별화하는 업무 로직에 집중하게 하려는 목적에서 만들어졌다. Wood Mackenzie는 호스팅 방식, 비용 구조, 모델 중립성, 확장성, 거버넌스와 기업 지원을 기준으로 AgentCore를 LangChain, CrewAI, n8n 및 모델 제공자 직접 이용 방식 등과 비교했다. 원문의 비교는 직접 운영해야 하는 라이브러리나 제한된 관리 기능 대신 AWS 관리형 플랫폼을 택한 이유를 설명하며, 공통 플랫폼을 표준화하면서도 팀별 프레임워크와 모델 선택권을 유지할 수 있다는 점을 강조한다.

3. 관리형 인프라와 모델 선택의 유연성

AgentCore 선택의 다섯 가지 결정 요인은 관리형 인프라, 모델 중립성, 자동 확장, 기본 제공 가드레일·신원 관리, AWS Enterprise Support였다. 원문에 따르면 AgentCore는 2025년 10월 정식 출시됐으며 당시 모든 서비스에 Amazon VPC, AWS PrivateLink, AWS CloudFormation과 리소스 태깅 지원이 추가돼 플랫폼 팀이 클러스터 운영보다 에이전트 기능에 집중할 수 있게 됐다. Strands Agents, LangGraph, LangChain, LlamaIndex, CrewAI, Google ADK, OpenAI Agents SDK 등과 함께 사용할 수 있고 MCP와 A2A 프로토콜도 지원하며, 모델은 Amazon Bedrock에서 실행되는 것으로 제한되지 않는다. Claude, GPT-4.1, Amazon Nova, Mistral, Llama 등을 활용해 계획과 실행에 서로 다른 모델을 배정하거나 제공자를 교체하면서 대화 맥락과 업무 로직을 유지할 수 있다고 설명한다. 런타임은 완전한 세션 격리와 최대 8시간의 실행 창을 제공하며 0에서 수천 개의 동시 호출까지 확장되고, 기업 지원에는 상시 지원과 기술 담당 관리자 및 계정 팀과의 관계가 포함된다.

4. 대기 시간이 긴 작업에 맞춘 사용량 과금

AgentCore의 과금은 선불 약정이나 최소 요금이 없는 사용량 기반이며, 각 서비스가 독립적으로 청구되는 구조로 설명된다. 따라서 팀은 전체 에이전트를 한꺼번에 이전하지 않고 AgentCore memory 같은 단일 기능부터 도입할 수 있어, 플랫폼 채택 범위를 필요에 맞게 정할 수 있다. 런타임 요금은 활성 CPU와 메모리 사용량을 초 단위로 계산하며 I/O 대기 중에는 CPU 요금이 발생하지 않는데, 원문은 에이전트 작업이 보통 시간의 30~70%를 모델 응답, 도구 호출 또는 데이터베이스 질의를 기다리는 데 쓴다고 설명한다. 미리 할당한 컴퓨팅 자원에서는 이런 대기 시간에도 비용을 지불하게 된다는 비교가 제시되지만, Wood Mackenzie의 실제 비용 절감액이나 절감률은 제공되지 않았으므로 과금 구조의 장점과 실측 성과는 구분할 필요가 있다.

5. 애플리케이션부터 인프라 코드까지 이어지는 계층 구조

APEX의 상위 계층에서는 사용자가 Woody, Lens AI, ST Trading App과 상호작용하고, 각 애플리케이션은 APEX 프런트엔드 SDK를 통해 에이전트 기능을 이용한다. 프런트엔드는 제품 팀이 사용자 인터페이스에 에이전트 기능을 넣을 때마다 백엔드 연결을 다시 만들지 않도록 공통 프레임워크를 제공하며, 백엔드에는 AgentCore의 Runtime, Identity, Gateway, Memory, Observability와 오케스트레이터, 검색용 벡터 데이터베이스, 모델 접근 및 가드레일이 배치된다. 별도의 WM 인프라 코드 프레임워크는 AWS CDK와 GitHub로 플랫폼 자원을 프로비저닝하고 버전을 관리하며 가드레일도 코드로 정의한다. 또 다른 축인 MCP 계층은 AWS Marketplace와 파트너 시스템을 포함한 외부 시스템을 표준 프로토콜로 연결하므로, 애플리케이션 통합과 자원 관리 및 외부 연결이 하나의 공유 구조 안에서 역할을 나누게 된다.

6. 사용자 권한을 유지하는 요청 처리와 자산 재사용

백엔드로 들어온 요청은 먼저 사용자 인증과 AgentCore Identity를 거쳐 호출자의 신원과 허용된 작업을 확인하며, Wood Mackenzie는 Okta를 신원 정보의 기준으로 사용한다고 밝힌다. 권한 확인은 입구에서 한 번 수행하는 절차로 끝나지 않고 모든 에이전트 호출에 반영돼, 사용자를 대신하는 에이전트가 하위 도구와 데이터에 접근할 때도 해당 사용자의 권한을 전달하도록 설계됐다. 오케스트레이터는 요청을 라우팅하면서 Woodmac Agent Registry를 참조하는데, 이 레지스트리는 거버넌스와 승인 절차를 포함해 조직 전체의 에이전트·도구·스킬을 발견하고 공유하며 재사용하는 장소다. 에이전트 코드는 서버리스 방식의 세션 격리 환경에서 실행되고, 런타임 내부의 AI Agents Studio는 여러 프레임워크를 수용하며 Amazon Bedrock 모델 카탈로그를 통한 모델 호출은 제공자 교체 시 에이전트 코드를 다시 쓰지 않게 하는 구성으로 설명된다.

7. 도구 연결과 검색·메모리·정책의 결합

APEX는 도구를 조합 가능한 구성 요소로 노출하며, 원문은 안전한 코드 실행을 위한 Code Interpreter와 브라우저 작업을 위한 Amazon Nova Act 웹 도구를 사례로 제시한다. AgentCore Gateway는 API, AWS Lambda 함수와 기존 MCP 서버를 에이전트가 사용할 수 있는 도구로 바꾸고 Tools Repository를 활용해 검색과 호출을 제공하며, IAM, OAuth 2.1, API 키 인증을 지원하는 단일 보안 엔드포인트 역할을 한다. 사내 비정형 문서를 포함한 콘텐츠는 Amazon Bedrock Knowledge Bases를 이용하는 벡터 데이터베이스 기반 RAG로 검색해 답변의 근거를 제공하고, AgentCore memory는 단기·장기 맥락을 유지해 세션을 넘는 대화와 에이전트 간 상태 공유를 지원한다. Amazon Bedrock Guardrails와 Policy는 콘텐츠 필터링, 개인정보 탐지 및 정책 집행을 담당하며, 특히 Policy는 Gateway와 통합돼 모든 도구 호출을 실시간으로 가로채고 자연어 규칙을 AWS의 오픈소스 정책 언어인 Cedar로 변환한다고 설명한다.

8. 관측 가능성의 구현과 제공된 설명의 한계

원문은 에이전트 출력이 비결정적이므로 운영의 핵심 질문을 단순히 작동하는지에서 언제 제대로 작동하지 않게 됐는지 알아낼 수 있는지로 전환한다. AgentCore Observability는 세션 수, 지연 시간, 실행 시간, 토큰 사용량과 오류율을 포함하는 OpenTelemetry 호환 텔레메트리를 Amazon CloudWatch로 보내며, Wood Mackenzie는 이를 통해 단일 요청을 세션에서 개별 스팬까지 추적할 수 있다고 설명한다. 각 구성 요소의 로그를 요청 흐름의 해당 단계에서 확인하게 하는 방식은 로그가 여러 그룹에 흩어진 상태에서 문제를 조사하는 부담을 줄이는 방향이지만, 제공된 원문은 그 위에 AgentCore Evaluation을 소개하기 시작한 지점에서 끝난다. 따라서 도입부에서 예고한 APEX Studio의 단일 제어 화면, 내부·외부 애플리케이션의 상세 적용, 평가와 거버넌스 격차 해소 및 멀티에이전트 발전 방향은 이 자료만으로 완결된 설명이나 성과를 확인할 수 없다.

🧾 핵심 주장 / 시사점

• APEX의 핵심은 개별 에이전트의 모델 성능 개선보다 반복되는 운영 책임을 공통 기반으로 옮기는 데 있으며, 이는 원문이 실패 원인을 주로 아키텍처에서 찾는 진단과 연결된다.
• 플랫폼 표준화와 모델·프레임워크 선택의 유연성을 함께 추구한다는 점에서, APEX는 조직 차원의 재사용과 제품 팀의 구현 선택권을 동시에 확보하려는 설계다.
• 권한 전파와 도구 호출 정책, 요청 추적은 운영 통제의 구체적 수단이지만, 이들이 실제로 개념검증의 배포 전환율이나 평가 품질을 얼마나 개선했는지는 제공된 자료에 나타나지 않는다.

✅ 액션 아이템

• Woody, Lens AI, ST Trading App의 런타임·인증·메모리·도구·평가 공유 범위와 중복 인프라 축소 가능성을 검토한다.
• 에이전트 작업의 대기 시간 30~70%와 I/O 대기 중 CPU 비과금 구조를 바탕으로 AgentCore의 비용 적합성을 검토한다.
• Okta 권한의 하위 호출 전파, Cedar 정책 집행, AgentCore Observability의 요청 추적을 검토하고 AgentCore Evaluation의 구체적인 평가 방식과 도입 성과를 추가로 확인한다.

❓ 열린 질문

• APEX 도입 이후 Wood Mackenzie에서 AI 개념검증의 88%가 광범위한 배포에 도달하지 못하던 상황은 얼마나 개선됐는가?
• 대기 시간이 30~70%인 에이전트 작업에서 I/O 대기 중 CPU 비과금은 실제 운영 비용에 어느 정도 영향을 주는가?
• AgentCore Evaluation은 어떤 방식으로 평가를 수행하며, AgentCore Observability의 요청 추적과 함께 운영 품질 개선에 어떤 성과를 냈는가?