Amazon Bedrock Managed Agents: OpenAI 에이전트를 AWS에서 운영하는 방법

에이전트를 직접 만들다 보면 정작 모델을 호출하는 코드보다 그 주변을 챙기는 코드가 더 길어지곤 합니다. 모델이 요청한 도구를 실행하고 결과를 다시 모델에 넣는 반복 루프를 짜야 합니다. 여러 턴에 걸친 대화를 저장하고, 길어진 컨텍스트도 정리해야 합니다. 명령을 실행할 격리된 환경과 그 권한까지 애플리케이션이 직접 준비해야 했습니다.

Amazon Bedrock Managed Agents, powered by OpenAI(이하 BMA)는 이 일을 AWS가 대신 맡아 운영하는 관리형 서비스입니다. BMA는 AWS와 OpenAI가 OpenAI Agents API를 바탕으로 함께 만든 서비스로, 2026년 9월 29일 프리뷰로 공개되었습니다. 개발자는 세션을 하나 만들면서 모델, 지침, 도구, 실행 환경을 지정하고 메시지를 보내기만 하면 됩니다.

1. Amazon Bedrock Managed Agents 한눈에 보기

1.1 BMA가 대신 맡는 일

BMA의 역할을 한 문장으로 줄이면 “에이전트의 생각은 BMA 안에서, 손발은 고객 계정의 실행 환경에서 움직인다”입니다. 모델을 호출하고 다음 할 일을 정하는 실행 루프는 BMA 안에서 실행되고, 명령과 도구는 고객 계정의 실행 환경에서 실행됩니다.

이 실행 루프를 Codex 하네스(Harness)라고 부릅니다. OpenAI의 Codex에서 가져온 루프로, 모델에게 다음 할 일을 묻고, 모델이 고른 도구를 실행하고, 그 결과를 다시 모델에 넘기는 과정을 반복합니다. 직접 구현할 때와 비교하면 표 1과 같습니다.

표 1. 에이전트를 직접 구현할 때와 BMA를 사용할 때의 차이 (BMA 프리뷰 발표문과 Amazon Bedrock User Guide 기준)

그림 1은 요청 하나가 처리되는 모습입니다. 에이전트가 명령을 실행하거나 파일을 다뤄야 하면, BMA는 그 작업을 고객 계정의 실행 환경으로 보냅니다. 실행 환경에서는 codex exec-server라는 프로세스가 BMA에 연결된 채로 기다리다가 전달받은 명령만 실행합니다.

그림 1. BMA의 동작 구조 (Amazon Bedrock User Guide와 AgentCore Developer Guide의 BMA 문서 기준)

글 전체에서 사용하는 용어는 표 2와 같습니다.

표 2. BMA의 핵심 용어 (Amazon Bedrock User Guide의 BMA 프리뷰 문서 기준)

BMA는 리전별 엔드포인트(https://bedrock-mantle.{region}.api.aws)로 제공됩니다. 프리뷰 리전은 미국 동부(버지니아 북부), 미국 서부(오레곤), 미국 동부(오하이오) 세 곳입니다. 프리뷰 기간에는 BMA 자체 요금이 없고, 모델 추론과 에이전트가 사용하는 AWS 리소스 비용만 발생합니다.

1.2 실행 환경 두 가지

실행 환경은 두 가지 중에서 선택할 수 있습니다.

• 자체 호스팅: 이미 운영 중인 서버나 컨테이너에서 exec server를 직접 실행합니다.
• AgentCore Runtime: exec server를 담은 컨테이너를 Amazon Bedrock AgentCore Runtime에 배포해 둡니다.

처음이라면 AgentCore Runtime으로 시작하는 것을 권장합니다. BMA가 필요할 때 Runtime을 실행하므로 서버를 구동할 필요가 없습니다. 세션마다 전용 microVM(가벼운 가상 머신)이 만들어져 서로 분리되고, AgentCore CLI가 프로젝트 템플릿과 배포 명령도 제공합니다.

1.3 첫 세션 실행 절차

BMA를 가장 빠르게 시험하는 방법은 AgentCore CLI의 BMA 템플릿입니다. 공식 문서에 따르면 프로젝트 생성부터 후속 메시지 전송까지 약 15분이 걸립니다. 준비물은 Node.js 20 이상, uv(Python 패키지 관리 도구), AWS 자격증명, 사용할 모델에 대한 접근 권한입니다.

아래 명령은 AWS 문서의 절차를 따르며, 이 문법이 동작하는 CLI 0.31 버전으로 설치를 고정했습니다. 버전 없이 설치하면 npm의 latest 태그인 1.0.x가 설치되는데, 1.0.x의 create는 --framework 옵션을 받지 않습니다. 1.0.x를 사용한다면 agentcore create --help에서 BMA 템플릿 옵션을 먼저 확인합니다.

# 1. 프로젝트 생성: BedrockManagedAgents 프레임워크 템플릿
npm install -g @aws/agentcore@0.31
export AWS_REGION=us-east-1
agentcore create --name MyManagedAgent --framework BedrockManagedAgents
cd MyManagedAgent

# 2. 배포: CodeBuild가 계정 안에서 이미지를 빌드하고 Runtime을 생성
agentcore deploy
agentcore status          # 출력에서 Runtime ARN 확인

# 3. 세션 실행 (ARN은 status 출력의 실제 값으로 바꿈)
RUNTIME_ARN="arn:aws:bedrock-agentcore:us-east-1:<계정 ID>:runtime/<Runtime ID>"
cd app/MyManagedAgent
uv run client.py --runtime "$RUNTIME_ARN"

# 4. 같은 세션에 후속 메시지 보내기 (3번 출력의 세션 ID 사용)
SESSION_ID="<세션 ID>"
uv run client.py --runtime "$RUNTIME_ARN" --session-id "$SESSION_ID" \
  --input "Run cat acr-report.txt and show the output."

3번 명령을 실행하면 세션 ID, 에이전트가 실행한 명령과 출력, 최종 답변이 차례로 출력됩니다. 4번 명령은 같은 세션 ID로 후속 메시지를 보내, 에이전트가 앞 턴의 작업을 기억하는지 확인합니다. 시험이 끝나면 agentcore remove all과 agentcore deploy를 차례로 실행합니다. 이 명령은 Runtime과 실행 역할, 프로젝트 스택을 지우지만 모든 리소스를 지우지는 않습니다. Runtime, 이미지 빌드, 빌드용 Lambda 함수의 CloudWatch Logs 로그 그룹, Amazon ECR 저장소의 KMS 키(30일 삭제 대기 후 삭제), 첫 배포 때 만든 CDKToolkit 스택, 계정 전체에 적용되는 CloudWatch Transaction Search 설정(추가 요금 발생 가능)은 남습니다. 예제 클라이언트가 직접 만든 세션 역할도 스택에 속하지 않으므로 IAM에서 따로 확인합니다.

예제 클라이언트는 OpenAI Python SDK를 그대로 사용합니다. 바꾸는 곳은 두 군데뿐입니다. 접속 주소(base_url)를 BMA 엔드포인트로 바꾸고, API 키 자리에 AWS 자격증명으로 짧은 수명의 토큰을 만드는 함수를 넣습니다.

client = OpenAI(api_key=lambda: provide_token(region=region),
                base_url=f"https://bedrock-mantle.{region}.api.aws/openai/v1")
events = client.beta.agents.sessions.create(
    agent={"model": BMA_MODEL_ID, "instructions": "Use the available tools to complete the task."},
    environment={"type": "aws_bedrock_agentcore", "runtime_arn": args.runtime},   # 일부 필드 생략
    input=args.input, stream=True)

세션 생성 요청에는 모델과 지침(agent), 실행 환경(environment), 첫 메시지(input)가 담깁니다. 코드에서 생략한 필드 중에는 세션 역할(role_arn)도 있으며, 프리뷰에서는 필수입니다. 뒤에서 소개할 AI Document Studio도 같은 구조를 사용하고, agent에 MCP 도구를 더했습니다. MCP(Model Context Protocol)는 에이전트가 외부 도구를 호출할 때 사용하는 표준 규약입니다.

1.4 모델과 리전 선택

BMA에서 GPT-6.1 Sol을 사용하려면 us-east-1 리전의 bedrock-mantle 엔드포인트에서 모델 ID openai.gpt-6.1-sol을 지정합니다.

GPT-6.1 Sol은 2026년 9월 29일 출시된 모델입니다. 이 모델은 성능과 비용을 함께 고려해야 하는 작업을 위한 모델이며, 복잡한 문서 이해와 여러 단계로 이뤄진 업무 흐름에 맞춰져 있습니다. 같은 모델이 bedrock-runtime 엔드포인트에서는 us.openai.gpt-6.1-sol, global.openai.gpt-6.1-sol 같은 리전 간 추론 프로파일(Cross-Region Inference) ID로만 제공되는데, BMA는 bedrock-mantle에서만 동작하고 리전 간 추론 프로파일도 지원하지 않으므로 us.나 global.이 붙지 않은 리전 내(In-Region) 모델 ID를 사용합니다.

모델 ID는 모델 목록 API(/v1/models)로 확인한 뒤, 실제로 BMA 세션이 만들어지는지 시험한 뒤 코드에 고정합니다. 목록에 보이는 모델이라고 모두 BMA에서 바로 사용되는 것은 아닙니다. 참고로 BMA 문서의 예제는 기본 모델로 openai.gpt-5.6-luna를 사용합니다.

1.5 AgentCore Runtime에서 에이전트를 실행하는 세 가지 방식

AgentCore Runtime에서 에이전트를 실행하는 방법은 BMA만 있는 것은 아닙니다. Strands Agents나 Claude Agent SDK 같은 다양한 에이전트 프레임워크를 컨테이너에 넣어 Runtime에서 실행할 수도 있습니다.

그림 2. AgentCore Runtime에서 에이전트를 실행하는 세 가지 방식의 실행 루프 위치와 모델 호출 권한

세부 차이는 표 3과 같습니다.

표 3. AgentCore Runtime에서 에이전트를 실행하는 세 가지 방식 비교 (AgentCore Developer Guide, Strands Agents 문서, Claude Agent SDK 문서 기준, 2026년 10월 28일 확인. Claude Agent SDK의 Bedrock 설정은 AWS 샘플 저장소 기준이며, BMA는 프리뷰입니다)

Strands Agents와 Claude Agent SDK는 실행 루프가 고객 컨테이너 안에 있어 루프의 동작을 코드로 세밀하게 바꿀 수 있습니다. 대신 대화 상태 저장, 컨텍스트 정리, 모델 호출 권한도 컨테이너 쪽에서 챙겨야 합니다. BMA는 루프와 세션을 BMA가 운영하기 때문에, 실행 환경에는 도구가 필요로 하는 권한만 주면 됩니다.

어떤 방식을 고를지는 다음 기준으로 판단하면 됩니다.

• Strands Agents: 모델을 자유롭게 고르고 실행 루프를 코드로 직접 제어하고 싶을 때
• BMA: 루프와 세션 운영을 BMA에 맡기고 OpenAI 모델을 사용하고 싶을 때
• Claude Agent SDK: Claude Code의 도구와 작업 방식을 그대로 에이전트에 가져오고 싶을 때

각 방식의 배포 방법은 Strands Agents 배포 문서, Claude Agent SDK 문서, AWS 샘플 저장소에서 확인할 수 있습니다.

2. 예시: AI Document Studio의 아키텍처와 흐름

지금부터는 BMA로 만든 실제 앱을 예로 들어 구성과 흐름을 살펴봅니다. AI Document Studio는 엑셀, CSV, 텍스트 파일이나 메모를 올리고 원하는 결과를 적으면 차트, 다이어그램, 편집할 수 있는 PowerPoint와 Word 문서를 만들어 주는 데모 앱입니다.

2.1 전체 아키텍처

AI Document Studio 아키텍처는 단순합니다. 브라우저의 요청이 서울 엣지의 CloudFront를 거쳐 버지니아 북부의 Lambda Web Function, Studio Worker, BMA(openai.gpt-6.1-sol), 문서 전용 Runtime으로 이어지고, MCP 도구가 만든 차트와 문서 파일이 S3에 저장됩니다.

그림 3. AI Document Studio 아키텍처 (2026년 10월 27일 us-east-1 배포 기준. 번호 1~6은 요청 처리 순서입니다)

그림 3의 구성 요소는 다섯 가지이며, 각자 맡은 일이 하나씩입니다.

• 화면과 API: Node.js 24로 작성한 Lambda Web Function 하나가 맡고, 앞에 Amazon CloudFront를 둡니다.
• 작업 처리: Studio worker(Lambda)가 BMA 세션을 만들고 메시지를 보냅니다.
• 에이전트: BMA가 openai.gpt-6.1-sol 모델로 실행 루프와 세션 상태를 맡습니다.
• 실행 환경: 문서 전용 AgentCore Runtime에서 문서 MCP 도구 6개와 Skills 3개가 실행됩니다.
• 저장소: 비공개 Amazon S3 버킷에 입력 파일, 작업 상태, 결과 파일을 둡니다.

2.2 요청 하나가 처리되는 흐름

그림 3의 번호 1~6을 따라가면 요청 하나가 처리되는 순서를 알 수 있습니다.

1. 사용자의 요청이 서울 엣지의 CloudFront를 거쳐 Web Function에 도착합니다.

2. Web Function이 입력 파일과 작업 상태를 S3에 저장합니다.

3. Web Function이 worker를 비동기로 호출하고 곧바로 응답합니다.

4. worker가 작업마다 새 BMA 세션을 만들고 요청을 보냅니다.

5. BMA가 문서 Runtime을 실행하고, MCP 도구가 차트와 문서 파일을 만들어 S3에 저장합니다.

6. 진행 단계는 SSE(Server-Sent Events, 서버가 브라우저로 데이터를 계속 흘려보내는 방식)로 화면에 표시되고, 완료된 파일은 인증된 다운로드로 받습니다.

이 흐름에서 애플리케이션 코드가 하는 일은 파일 저장, 세션 생성, 진행 상황 전달 세 가지입니다. 어떤 도구를 어떤 순서로 몇 번 호출할지는 4~5번 사이에서 BMA의 Codex 하네스가 정합니다.

3. BMA로 구현할 때 편한 점

3.1 실행 루프 대신 세션 요청 하나

worker가 보내는 세션 생성 요청은 첫 세션 예제와 같은 구조이고, agent 안에 tools 항목을 더했습니다.

"agent": {
  "model": "openai.gpt-6.1-sol",
  "instructions": "...",
  "tools": [{
    "type": "mcp",
    "server_label": "document_studio",
    "transport": {
      "type": "stdio",
      "command": "/opt/studio/venv/bin/python",
      "args": ["-m", "studio.document_tools.mcp_server", "--job-id", "<작업 ID>"],
      "env_vars": ["APP_REGION", "STUDIO_BUCKET", "AWS_CONTAINER_CREDENTIALS_FULL_URI"]
    },
    "allowed_tools": ["inspect_inputs", "read_table", "read_text",
                      "create_chart", "create_diagram", "create_documents"]
  }]
}

*instructions와 env_vars는 일부만 표시했고 required, cwd 같은 필드는 생략했습니다.*

눈여겨볼 항목은 네 가지입니다.

• transport.type: "stdio": MCP 서버가 Runtime 안에서 프로그램으로 실행되고 표준 입출력으로 통신합니다. 별도 서버를 띄울 필요가 없습니다.
• --job-id: MCP 서버를 작업 하나에 묶습니다. 이 서버는 지정한 작업의 파일만 읽습니다.
• env_vars: 환경 변수의 이름만 적습니다. 자격증명은 Runtime이 원래 가진 것을 그대로 사용합니다.
• allowed_tools: 모델이 호출할 수 있는 도구를 6개로 한정합니다.

첫 메시지는 세션을 만든 뒤 입력 이벤트(agent.session.input.message)로 따로 보냅니다. worker에는 도구 결과를 모델에 다시 넣는 반복, 대화 기록 저장, 긴 컨텍스트 정리 코드가 없습니다. 도구를 바꾸고 싶을 때도 MCP 서버와 allowed_tools만 고치면 됩니다.

3.2 컨테이너 이미지로 준비하는 실행 환경과 진행 표시

문서 Runtime은 컨테이너 이미지 하나로 준비합니다. 이미지에는 공식 lifecycle 서버(수정하지 않고 그대로 사용), Linux ARM64용 Codex 0.164.0, 문서 MCP 서버와 Python 렌더러, Skills 3개가 들어갑니다. 배포는 CloudFormation 앱 스택이 Runtime, IAM 역할, Web Function, 버킷을 함께 만들고, Runtime은 BMA가 필요할 때 실행되어 호출이 없으면 15분 뒤 종료됩니다.

Skills(차트, 다이어그램, PowerPoint와 Word 구성)에는 “빈 칸을 0으로 바꾸지 않는다” 같은 작성 규칙을 적어 두어, 절차를 바꿀 때 코드 대신 파일만 고치면 됩니다. 다만 Skills는 권한을 주거나 막지 못하므로 안전 장치는 도구 제한과 IAM 권한이 맡습니다.

진행 표시는 worker가 1.5초마다 세션 아이템을 읽어 마지막 MCP 도구 호출로 “차트 작성”, “문서 작성” 같은 단계를 정해 S3에 저장하면, Web Function이 이를 화면에 전달하는 방식입니다. 새로 고침을 해도 저장된 기록을 다시 읽을 뿐 생성 요청을 다시 보내지 않고, S3 조건부 쓰기로 같은 작업이 두 번 실행되지 않게 했습니다.

4. BMA가 AI Document Studio에 준 장점

4.1 모델과 도구의 역할 분담

BMA에서는 모델이 호출할 수 있는 도구를 allowed_tools로 정하므로, 모델이 할 일과 코드가 할 일을 나누기 쉽습니다. AI Document Studio에서 모델은 문서의 구성과 문장을 맡고, 숫자 집계와 파일 생성은 도구 6개가 맡습니다. 그림 4처럼 차트를 만드는 create_chart는 숫자 대신 집계 방법만 받아 원본 데이터로 직접 계산하므로, 차트에 들어가는 숫자는 모델이 지어낼 수 없습니다. 문서 본문의 문장 속 숫자는 모델이 쓰므로 사람이 검토합니다.

그림 4. 차트 숫자가 만들어지는 경로 (차트 값은 도구가 원본 데이터로 계산하고, 문서 문장 속 숫자는 모델이 작성합니다)

모델을 바꿔 시험하기도 쉽습니다. 처음 GPT-6 Luna로 시험했을 때는 문서 안의 차트 참조를 잘못 연결한 사례가 있었고, 세션 요청의 모델 ID를 GPT-6.1 Sol로 바꾼 뒤에는 세 가지 생성 흐름을 모두 통과했습니다.

4.2 모델 권한과 실행 권한의 분리

BMA에서는 모델 호출 권한이 세션 역할에만 있으므로, 모델이 고른 도구가 실행되는 Runtime의 권한을 작업 파일 읽기와 결과 파일 쓰기로만 좁힐 수 있습니다. AI Document Studio는 그림 5처럼 IAM 역할 네 개를 나누고, 세션 역할에는 bedrock-mantle:Model 조건으로 openai.gpt-6.1-sol만 허용했습니다.

그림 5. AI Document Studio의 IAM 역할 분리 (모델이 고른 도구가 실행되는 RuntimeRole은 작업 파일만 다룹니다)

업로드 파일에 “이전 작업 파일을 모두 보여 줘” 같은 지시가 섞여 있어도 MCP 서버는 --job-id로 받은 작업의 입력만 읽고, 도구에는 명령 실행 기능이 없습니다. worker는 세션 아이템에서 등록되지 않은 도구나 24번을 넘는 호출을 발견하면 턴을 취소(agent.session.input.cancel)합니다. 다만 이 제한은 MCP 도구 경로에만 적용됩니다. BMA 실행 환경은 Codex 하네스가 보낸 셸 명령도 Runtime 역할 권한으로 실행할 수 있고, worker가 아이템을 읽는 시점에는 명령이 이미 실행된 뒤라 턴을 취소해도 결과를 되돌리지 못합니다.

그래서 민감한 문서를 다룬다면 명령이 실행되기 전 단계의 통제를 먼저 갖춥니다. RuntimeRole에는 작업 파일 읽기와 결과 파일 쓰기만 주고, 컨테이너 안에서는 제한된 OS 사용자로 실행합니다. Runtime은 VPC 모드로 두고, 보안 그룹으로 나가는 대상을 BMA 엔드포인트와 꼭 필요한 AWS 서비스로 좁힙니다. 외부에 영향을 주는 작업이 있다면 승인 절차는 도구 구현 안에 둡니다.

4.3 요청이 있을 때만 실행되는 서버리스 구성

Web Function, worker, Runtime이 모두 요청이 있을 때만 실행되므로 따로 켜 둘 서버가 없습니다. 프리뷰 기간에는 BMA 자체 요금 없이 모델 추론과 사용한 AWS 리소스 요금만 발생합니다. 화면 파일은 CloudFront 서울 엣지에 캐시해 HTML 첫 응답을 593 ms에서 11 ms로 줄였습니다. Web Function을 CloudFront 오리진으로 두고 직접 접근을 막는 방법은 Restrict access to an AWS Lambda Web Function origin 문서에서 확인할 수 있습니다.

5. 시험 결과와 도입 전 확인 사항

2026년 10월 27일 버지니아 북부에 배포한 앱에서 예제 파일로 세 가지 흐름을 시험했습니다. 세 흐름 모두 1분 안에 끝났습니다.

표 4. 실제 문서 생성 시험 결과 (2026년 10월 27일, openai.gpt-6.1-sol, us-east-1. 소요 시간은 요청부터 완료까지)

그림 6. 월별 매출 엑셀로 차트, PowerPoint, Word를 만든 결과 화면

세 흐름에서 파일 15개가 만들어졌고, PowerPoint 안의 편집 가능한 차트 값은 원본 엑셀의 여섯 값과 정확히 일치했습니다. 완료 전에 새로 고침을 해도 생성 요청이 다시 발생하지 않았습니다. 네 역할의 IAM 권한 평가 10건과 로컬 테스트 113개도 통과했습니다. 데모의 비용과 실행 시간을 예측할 수 있도록 파일은 한 번에 1개(최대 5 MiB), 작업 시간은 300초 이내로 제한했습니다.

실제 업무에 도입하기 전에는 다음 세 가지를 확인해 보시기 바랍니다.

• 프리뷰 제약: 하위 에이전트(Subagent)와 코드 방식의 도구 호출(Code mode)은 아직 지원되지 않고, 세션 입력은 텍스트만 가능합니다. 정식 출시 때 API와 IAM 권한 이름을 다시 확인해야 합니다.
• 데이터 처리 위치: 화면은 서울 엣지에서 빠르게 보이지만, 파일 분석과 문서 생성은 us-east-1에서 일어납니다. 국내 리전 처리가 필요한 업무라면 이 흐름을 먼저 검토합니다.
• 사용자 인증: 데모는 신뢰하는 사용자 몇 명이 이용 키 하나를 함께 사용합니다. 회사 전체에 제공한다면 사용자별 로그인과 작업 분리를 먼저 추가합니다.

6. 마치며

BMA를 사용하면 OpenAI 에이전트의 실행 루프, 대화 상태, 컨텍스트 관리를 직접 만들지 않아도 됩니다. 세션을 하나 만들면서 모델, 지침, 도구, 실행 환경을 지정하고 메시지를 보내면 되며, AgentCore CLI 템플릿으로 15분 안팎이면 첫 세션을 실행해 볼 수 있습니다.

직접 만든 에이전트와 비교한 BMA의 장점은 네 가지로 정리할 수 있습니다.

• 빠른 시작: 실행 루프와 대화 저장소를 만들지 않고도 세션 요청 하나와 AgentCore CLI 템플릿으로 첫 에이전트를 실행해 볼 수 있습니다.
• 익숙한 개발 방식: OpenAI Python SDK를 그대로 사용하고 접속 주소와 인증만 AWS 방식으로 바꿉니다. OpenAI API 키를 따로 관리하지 않아도 됩니다.
• AWS 보안과 감사: 에이전트마다 IAM 역할을 지정하고, 모델 권한은 세션 역할에, 실행 권한은 실행 환경에 나눠 둡니다. 지원되는 API 활동은 AWS CloudTrail에 기록됩니다.
• 적은 운영 부담: 실행 환경을 AgentCore Runtime에 두면 필요할 때만 실행되고 세션마다 분리되므로, 서버를 켜 두고 관리할 필요가 없습니다.

AI Document Studio에서도 애플리케이션 코드는 파일 저장, 세션 생성, 진행 상황 전달만 맡았고, 개발자는 어떤 도구를 두고 어떤 권한을 줄지에 집중할 수 있었습니다. BMA는 익숙한 OpenAI SDK 코드를 그대로 두고 AWS의 IAM, CloudTrail, AgentCore Runtime 위에서 에이전트를 운영할 수 있다는 큰 장점을 제공합니다.이 글의 구성과 예시가 여러분의 BMA 기반 에이전트 검토에 실질적인 참고가 되기를 바랍니다.

참고 자료

• Amazon Bedrock Managed Agents, powered by OpenAI, is now available in preview – What’s New (2026-09-29)
• Amazon Bedrock Managed Agents, powered by OpenAI (preview) – Amazon Bedrock User Guide
• Set up permissions and prerequisites – Amazon Bedrock User Guide
• Run your agent on Amazon Bedrock AgentCore Runtime – Amazon Bedrock User Guide
• Work with sessions, events, and results – Amazon Bedrock User Guide
• Add skills and tools – Amazon Bedrock User Guide
• Security and IAM roles – Amazon Bedrock User Guide
• BMA preview REST API reference – Amazon Bedrock User Guide
• Preview availability and limitations – Amazon Bedrock User Guide
• Get started with Amazon Bedrock Managed Agents (with OpenAI) on AgentCore Runtime – Amazon Bedrock AgentCore Developer Guide
• Configure lifecycle settings – Amazon Bedrock AgentCore Developer Guide
• GPT-6.1 Sol – Amazon Bedrock 모델 카드
• Amazon CloudFront now supports AWS Lambda Web Functions as an origin – What’s New (2026-10-12)
• Restrict access to an AWS Lambda Web Function origin – Amazon CloudFront Developer Guide
• AWS Lambda Web Functions – AWS Lambda Developer Guide
• Runtimes – AWS Lambda Developer Guide

본문의 설정과 한도는 2026년 10월 28일 기준 BMA 프리뷰 문서와 필자의 배포 설정을 바탕으로 합니다. 프리뷰 기능과 API, 모델 제공 리전은 정식 출시 전에 바뀔 수 있습니다. 시험 결과는 2026년 10월 27일 버지니아 북부(us-east-1)에 배포한 AI Document Studio로 측정한 값이며, 응답 시간 측정은 서울 리전 EC2 한 대 기준입니다. 입력 파일, 요청 내용, 시점에 따라 결과가 달라질 수 있습니다.