Wood Mackenzie, Amazon Bedrock AgentCore 위에 공유 에이전트 플랫폼 구축
Wood Mackenzie는 운영용 AI 에이전트를 위해 신원, 런타임, 관찰 가능성, 가드레일을 표준화하려고 Amazon Bedrock AgentCore 위에 APEX를 구축했다.
Wood Mackenzie는 APEX라는 공유형 에이전틱 AI 플랫폼을 Amazon Bedrock AgentCore 위에 구축해, 각 애플리케이션마다 런타임, 신원 제어, 관찰 가능성, 안전장치를 다시 만드는 대신 운영용 에이전트를 배포할 수 있는 공통 기반을 팀에 제공하고 있다.
AWS가 공개한 이 회사 사례는 APEX가 Woody, Lens AI, ST Trading App의 세 가지 애플리케이션을 지원한다고 설명한다. 이 아키텍처는 제품 팀이 서로 다른 에이전트 프레임워크와 모델을 선택하되 표준화된 운영 계층에 의존할 수 있도록 설계됐다. 이는 엔터프라이즈 AI의 핵심 문제를 다룬다. 즉, 프로토타입은 빠르게 만들 수 있지만, 비결정적 시스템을 사용자, 도구, 데이터 전반에서 안전하게 운영하는 일은 훨씬 더 어렵다.
같은 AWS 블로그 묶음에서는 Abnormal AI가 이메일 보안 시스템에서 AgentCore Code Interpreter를 사용하는 사례도 다룬다. 이 사례들을 함께 보면 AWS가 AgentCore를 단순한 개발 서비스가 아니라, 격리, 정책 집행, 실시간 워크플로에서의 제어된 컴퓨팅 접근이 필요한 에이전트를 위한 인프라로 포지셔닝하고 있음을 보여준다.
Wood Mackenzie의 에이전트를 위한 공유 기반
Wood Mackenzie에 따르면 APEX 이전에는 Woody, Lens AI, ST Trading App이 각각 자체 에이전트 스택을 개발하고 있었다. 이런 접근 방식은 인증, 확장, 추적, 모델 접근, 가드레일의 개별 구현을 필요로 했을 것이다. 또한 팀 간에 도구, 메모리, 평가 관행을 공유하기 어렵게 만들었을 것이다.
APEX는 이러한 역량을 중앙화한다. 백엔드는 Amazon Bedrock AgentCore Runtime, Identity, Gateway, Memory, Observability와 함께 오케스트레이터, 검색 인프라, Amazon Bedrock 모델 카탈로그를 통한 모델 접근, Amazon Bedrock Guardrails를 사용한다. 프런트엔드 소프트웨어 개발 키트가 플랫폼을 사용자-facing 애플리케이션과 연결한다.
이 설계는 모든 팀이 같은 에이전트 프레임워크를 사용해야 한다고 요구하지 않는다. Wood Mackenzie는 자사의 환경이 Strands Agents, LangGraph, CrewAI, n8n, Vertex, OpenAI의 에이전트 도구를 지원할 수 있다고 말한다. AgentCore는 Model Context Protocol(MCP)과 Agent-to-Agent 프로토콜도 지원해, 외부 시스템과 에이전트가 일회성 통합이 아니라 표준화된 인터페이스를 통해 연결될 수 있게 한다.
이 유연성은 플랫폼의 매력에서 중요한 부분이다. Wood Mackenzie에 따르면 팀은 애플리케이션 로직을 다시 작성하지 않고 모델을 바꿀 수 있고, 하나의 모델은 계획에, 다른 모델은 실행에 사용할 수 있으며, 공급자 간 가격과 성능을 비교할 수도 있다. 회사는 Claude, GPT-4.1, Amazon Nova, Mistral, Llama를 플랫폼에서 접근 가능한 모델로 나열하지만, 해당 글은 모델 품질이나 전환 비용에 대한 독립적 측정은 제공하지 않는다.
신원과 운영이 플랫폼 계층으로 이동하다
APEX는 인가를 사용자가 애플리케이션에 들어갈 때만 수행하는 검사가 아니라, 각 에이전트 호출의 속성으로 취급한다. Wood Mackenzie는 AgentCore Identity가 사용자의 권한을 후속 도구 및 데이터 호출 전반에 전달해, 에이전트가 사용자를 대신하거나 별도로 정의된 접근 제어 아래 행동할 수 있게 한다고 말한다. 회사는 Okta를 ID 공급자의 단일 진실 공급원으로 사용한다.
플랫폼에는 Woodmac Agent Registry도 포함되어 있어, 팀이 거버넌스와 승인 워크플로의 적용을 받는 에이전트, 도구, 스킬을 발견하고 재사용할 수 있다. 이 레지스트리는 기존 기능을 공유할 수 있을 때 코드 복제를 막기 위한 것이다.
AWS는 AgentCore Runtime을 세션 격리형 서버리스 환경으로 설명하며, 0에서 수천 개의 동시 호출까지 확장할 수 있고 실행 시간은 최대 8시간까지 가능하다고 말한다. AWS는 또한 AgentCore 서비스가 2025년 10월의 정식 출시 이후 Amazon Virtual Private Cloud, AWS PrivateLink, CloudFormation, 리소스 태깅 같은 기능을 지원한다고 밝힌다.
비용 관리를 위해 이 서비스는 선불 약정이나 최소 요금 없이 사용량 기반 요금을 적용한다. AWS는 런타임 과금이 초당 활성 CPU 및 메모리 사용량에 기반하며, 입출력 대기 중에는 CPU 요금이 제외된다고 말한다. 회사는 에이전트 워크플로가 시간의 30%~70%를 모델 응답, 도구, 데이터베이스를 기다리는 데 쓸 수 있어, 이런 과금 방식이 기존에 프로비저닝된 컴퓨팅을 놀게 만들었을 워크로드에 적합하다고 지적한다.
증거는 상세하지만 벤더가 통제한다
이 이야기에 담긴 가장 강한 주장은 독립 감사가 아니라 AWS와 Wood Mackenzie에서 나온 것이다. Wood Mackenzie는 내부적으로 자사의 AI 개념 증명 중 88%가 광범위한 배포로 이어지지 않는다고 보고한다. 또한 이 글은 업계 설문과 Forrester 연구를 인용해 평가, 관찰 가능성, 거버넌스, 신원이 에이전트 확장의 주요 장벽이라고 주장하지만, 더 넓은 통계를 독립적으로 평가할 만큼의 출처 세부 정보는 제공하지 않는다.
아키텍처 자체는 인증부터 오케스트레이션, 런타임, 모델 접근, 도구 호출에 이르는 요청 경로를 포함해 실무적으로 설명된다. 그러나 이 글은 APEX의 프로덕션 트래픽, 에이전트 수, 지연 시간, 오류율, 운영 비용, 측정 가능한 비즈니스 성과를 공개하지 않는다. 따라서 구매자는 이 사례를 구현 참고 자료이자 벤더 지원 사례 연구로 보아야 하며, AgentCore가 다른 기업에서도 같은 결과를 낸다는 증거로 봐서는 안 된다.
Abnormal AI 사례는 별도의 규모 주장을 제공한다. AWS는 Abnormal AI가 수십억 개의 메시지에 대한 실시간 이메일 위협 탐지에 관여하는 에이전트에 AgentCore Code Interpreter를 사용한다고 말하며, 더 넓은 탐지 시스템은 어려운 사례에만 점점 더 비용이 큰 분석을 적용한다. AWS는 또한 Fortune 500의 25% 이상이 Abnormal AI를 사용하며, 회사 코드 변경의 80%가 어떤 식으로든 에이전트를 포함한다고 보고한다. 이는 회사나 벤더가 보고한 수치이며, 글은 독립적 검증을 제공하지 않는다.
Code Interpreter는 AgentCore 스토리에 또 다른 기능을 더한다. 에이전트가 Python 또는 Node.js 코드를 실행하고, 파일을 처리하고, 계산을 수행하고, 결과물을 만들고, 생성된 작업을 검증할 수 있는 일시적 MicroVM 샌드박스를 제공한다. AWS는 세션이 15분에서 8시간까지 지속될 수 있고, 퍼블릭 네트워킹 또는 VPC 모드를 지원하며, CloudWatch와 CloudTrail을 통해 로그를 제공한다고 말한다. Abnormal AI의 사용 사례는 에이전트가 언어 모델 추론만으로는 부족하며 제어된 실행 환경이 필요할 수 있음을 보여준다.
이 플랫폼이 빌더와 기업에 의미하는 것
AI 빌더에게 가장 큰 변화는 엔지니어링 노력을 어디에 쓰는지가 바뀐다는 점이다. 팀은 공통 플랫폼이 반복적인 인프라 문제를 맡는 동안 도메인 워크플로, 검색 품질, 도구 설계, 평가에 집중할 수 있다. 이는 성공적인 데모에서 여러 사용자와 동시 세션을 지원하는 서비스로 가는 시간을 줄일 수 있다.
대신 중앙 플랫폼 팀에 대한 아키텍처 의존이 생긴다. 공유 레지스트리, 공통 정책 계층, 표준화된 관찰 가능성은 중복을 줄일 수 있지만, 온보딩, 승인, 프레임워크 지원이 느리면 병목이 될 수도 있다. Wood Mackenzie가 프레임워크와 모델 선택권을 유지하기로 한 결정은 이런 위험을 줄이지만, 세심한 인터페이스 설계와 플랫폼 거버넌스의 필요성을 없애지는 않는다.
기업에게는 지원 모델의 긴 목록보다 신원 전파와 세션 격리가 더 중요하다. 내부 도구를 호출할 수 있는 에이전트는 워크플로 전반에서 이해 가능하고 취소 가능한 권한을 필요로 한다. AgentCore Identity, Gateway 정책, Cedar 기반 규칙은 이런 요구를 해결하기 위한 것이지만, 조직은 여전히 특이한 프롬프트, 연결된 도구 호출, 부분 실패 상황에서 정책 동작을 시험해야 한다.
Abnormal AI의 배포는 에이전트 시스템에서 계층형 비용 모델의 필요성도 보여준다. 가벼운 규칙과 분류기는 대량 사례를 처리하고, 더 비싼 에이전트와 코드 실행은 불확실하거나 복잡한 경우에만 사용된다. 이러한 패턴은 특히 지연 시간과 작업당 비용이 중요한 환경에서 모든 작업을 대형 모델로 보내는 것보다 더 실용적일 수 있다.
앞으로 주목할 점
다음에 의미 있는 신호는 홍보가 아니라 운영 지표가 될 것이다. Wood Mackenzie의 APEX는 애플리케이션 전반의 도입 현황, 에이전트 실패율, 평가 커버리지, 지연 시간, 정책 위반, 워크플로당 비용에 대한 공개 데이터가 있을 때 더 평가하기 쉬워질 것이다.
빌더는 또한 팀이 고립된 실험에서 공유 도구와 멀티에이전트 워크플로로 이동할 때 AgentCore의 프레임워크 및 모델 비종속성이 여전히 실용적인지 살펴봐야 한다. MCP 및 Agent-to-Agent 연결 지원은 재사용을 늘릴 수 있지만, 플랫폼 팀이 모니터링해야 할 신뢰 경계의 수도 늘릴 수 있다.
기업 구매자에게 중요한 후속 과제는 독립적인 고객 레퍼런스, 지속적 동시성 하에서의 더 명확한 가격, 사고 대응 통제, 그리고 연결된 애플리케이션을 방해하지 않고 에이전트를 비활성화하거나 롤백할 수 있다는 증거다. Code Interpreter 배포는 데이터 보존, 네트워크 접근, 패키지 제어, 생성 코드 격리에 대한 추가 검토가 필요하다.
Creati.ai 관점
Wood Mackenzie의 APEX가 주목할 만한 이유는 또 하나의 에이전트 애플리케이션을 도입했기 때문이 아니라, 부족했던 프로덕션 계층을 재사용 가능한 제품으로 다루기 때문이다. 회사의 설명은 기업 팀이 신원, 런타임 동작, 관찰 가능성, 정책을 표준화하는 내부 에이전트 플랫폼으로 이동하고 있으며, 비즈니스 팀에는 자신들의 모델과 프레임워크를 선택할 여지를 남겨두고 있음을 시사한다.
증거는 여전히 벤더 통제 하에 있으며, APEX를 검증된 템플릿으로 입증할 성능이나 재무 데이터는 공개되지 않았다. 그래도 이 아키텍처는 엔터프라이즈 AI에 대한 실용적인 방향을 가리킨다. 에이전트 도입은 또 하나의 인상적인 프로토타입을 만드는 것보다, 권한, 평가, 격리, 비용을 매일 운영할 수 있을 만큼 가시화하는 데 더 크게 좌우될 가능성이 높다.
