9월 29일 AWS가 public preview로 내놓은 Amazon Bedrock Managed Agents(BMA, powered by OpenAI)는 한 문장으로 요약됩니다.
OpenAI의 agent 하네스를 AWS-native runtime으로 제공한다.
모델 API를 파는 시대 다음에는 agent runtime + identity + 실행환경 + durable state + 거버넌스를 묶어서 파는 시대가 옵니다. BMA는 그 묶음 상품의 AWS판입니다. AWS 주간 요약(10월 5일)에서도 다시 강조됐을 만큼, 양사의 공을 들인 합작입니다.
구조: 무엇이 어디에서 도는가?
BMA의 핵심 부품은 여섯 개입니다.
Session 상태ful 대화. 모델·지시·tool·IAM role·실행환경을 지정
Turn 메시지 1건에 대한 작업 (reasoning + tool calls + 출력)
Exec env 고객이 제공하는 compute (self-hosted 또는 AgentCore)
Exec server codex exec-server 프로세스. BMA로 outbound 연결
Items durable한 대화 결과물 (메시지·명령·MCP 호출 기록)
Session role BMA가 assume하는 IAM role (추론·런타임 호출 권한)
흐름을 그리면 이렇습니다.
내 앱
│ 세션 생성 (모델·지시·role·실행환경 지정)
▼
BMA (bedrock-mantle endpoint)
│ 모델 추론 + 대화 상태 관리 + context compaction
│ ← Codex harness가 loop를 돈다
▼
실행환경 (내 host 또는 AgentCore Runtime의 microVM)
명령 실행·파일 작업·MCP tool 실행
→ 결과와 command output이 Items로 durable 저장
직접 loop를 돌리는 방식과 비교한 글을 읽어본 분이라면 감이 올 겁니다. 지금까지는 저 loop·상태·compaction을 각 팀이 직접 만들었습니다. BMA는 그 하네스 부분을 통째로 관리형으로 가져가고, 실행은 내 compute에서 하게 합니다. 모델 호출은 Bedrock 안에 머물고, 컨테이너는 에이전트가 보낸 명령만 실행합니다. AWS 공식 문서의 아키텍처 그림으로 보면 이렇습니다.
출처: AWS 공식 문서 「Amazon Bedrock Managed Agents, powered by OpenAI (preview)」 아키텍처 다이어그램.
실행환경 선택지: self-hosted vs AgentCore
| 방식 | 내가 제공하는 것 | 어울리는 경우 |
|---|---|---|
| Self-hosted | host·workspace·네트워크·exec server | 기존 개발머신·컨테이너를 쓰고 싶을 때 |
| AgentCore Runtime | exec server 담은 Runtime | 세션별 microVM 격리·관리형 스토리지가 필요할 때 |
AgentCore 쪽은 세션마다 microVM이 뜨고, 내가 통제하는 execution role로 돌며, VPC 연결로 private 리소스에도 닿습니다. skills는 capability directories(최대 32개 경로)에 파일로 두면 discovery되고, MCP는 환경 기반 STDIO 서버로 연결합니다.
권한 모델이 이 상품의 진짜 얼굴입니다. 에이전트마다 자기 IAM role을 갖고, iam:PassRole로 세션 role을 넘기고, 모델 호출은 bedrock-mantle:CreateInference로 좁히고, CloudTrail에 API 활동이 남고, 중요 작업 전에는 human approval을 걸 수 있습니다. 에이전트 권한이 AWS 거버넌스(IAM·CloudTrail·VPC)와 같은 언어로 표현된다는 점이 포인트입니다.
요금은 preview 동안 BMA 추가 요금 없이 쓴 만큼의 추론·리소스 비용만 나옵니다. 정식 출시 시 변경될 수 있습니다.
Preview 제한: 지금 안 되는 것들
공식 문서의 제한 표는 솔직합니다. 도입 전에 반드시 읽어야 합니다.
지원 세션 CRUD, 텍스트 메시지 제출·턴 취소,
durable items 읽기·이벤트 스트리밍,
명령 실행, 파일 기반 skills, STDIO MCP
미지원 서브에이전트 (Subagents: Not supported)
입력 문서화된 입력은 text 중심
(programmatic tool calling / code mode 미포함)
기억 장기 memory 통합 없음
(세션 대화와 workspace 파일은 별개 lifecycle)
보안 고객 관리 KMS 키 옵션 없음
콘솔 API·예제 중심 (콘솔 절차 아님)
엔드포인트 bedrock-mantle 전용 (bedrock-runtime 아님)
리전 us-east-1, us-west-2, us-east-2
"서브에이전트 미지원"과 "text 입력 중심" 두 줄이 가장 큽니다. 멀티에이전트 분업을 염두에 둔 팀이라면 지금 BMA는 단일 에이전트의 긴 일을 맡기는 용도로 보고, 분업 구조는 서브에이전트 오케스트레이션 글 같은 별도 레이어로 설계해야 합니다.
CodeBridge Mini Lab: 직접 loop vs BMA 비교표
브리핑의 액션을 그대로 가져옵니다. AWS를 쓰는 팀이라면 같은 일을 두 방식으로 돌려보고 다음을 비교하세요.
비교 항목 직접 agent loop BMA
------------------------------------------------
agent loop 소유권 내 코드 Codex harness (관리형)
대화 상태 직접 저장 (DB 등) session + durable items
context compaction 직접 구현 하네스 내장
실행환경 내 서버/컨테이너 self-hosted 또는 AgentCore
권한 앱 자체 관리 IAM role·PassRole·CloudTrail
skills/MCP 직접 배선 capability dir·STDIO MCP
서브에이전트 직접 구현 가능 미지원 (preview)
장기 기억 직접 설계 없음 (파일과 분리 설계)
관측 직접 계측 events 스트림 + items
요금 내 infra 전부 추론·리소스 실비 (preview)
판정 기준은 하나입니다. IAM·관측·상태 저장을 다 합쳤을 때 어느 쪽의 총 소유 비용이 낮은가. 모델 성능이 아니라 운영 책임의 문제로 보면 답이 빨리 나옵니다.
결론: 하네스가 인프라가 되면, 차별점은 거버넌스가 된다
정리하면 BMA의 베팅은 이렇습니다.
과거: 모델 API를 잘 고르는 팀이 이긴다
지금: agent loop를 잘 만드는 팀이 이긴다
다음: loop·신원·실행·상태·감사를 묶어주는
인프라 위에서 일하는 팀이 이긴다
모델이 바뀌어도 남는 것은 권한·기록·상태입니다. BMA는 그 남는 것들을 AWS의 언어로 묶었습니다. AWS 위에서 에이전트를 production으로 올릴 계획이라면, 이번 preview 기간에 작은 repo 조사 업무 하나를 BMA 세션으로 돌려보고 items와 events가 내 감사 요구를 만족하는지 확인해보세요. 만족한다면 loop 코드는 버리고 거버넌스에 집중하면 됩니다. 그게 클라우드가 하네스를 품은 이유이기도 합니다.
함께 읽으면 좋은 글
참고 자료
- AWS: Bedrock Managed Agents, powered by OpenAI (preview)
- AWS Docs: BMA overview
- AWS Docs: Preview availability and limitations
- AWS Weekly Roundup (Oct 5, 2026)
이 주제를 직접 따라가며 배우고 싶다면
하네스·루프·상태 저장을 손으로 먼저 만들어보고 관리형과 비교하는 연습이 필요하다면, 에이전트 실행 구조를 쌓는 과정이 이 글의 비교표와 바로 이어집니다.