OpenAI·Codex Bedrock GA, AWS IAM으로 쓰는 GPT-5.5
OpenAI GPT-5.5, GPT-5.4, Codex가 Amazon Bedrock GA로 전환됐습니다. IAM, Region, Codex 기능 공백을 짚습니다.
- 무슨 일: OpenAI와 AWS가 2026년 6월 1일 GPT-5.5, GPT-5.4, Codex on Amazon Bedrock GA를 발표했습니다.
- AWS는
ResponsesAPI 호환 엔드포인트, Bedrock API key, AWS SDK credential chain, Region 내 처리를 공개했습니다.
- AWS는
- 개발자 영향: Codex CLI·앱·IDE가
amazon-bedrockprovider로 모델 호출을 보낼 수 있습니다.- 좌석 라이선스 대신 token 과금, IAM·quota·CloudTrail·PrivateLink 같은 AWS 운영 단위가 도입됩니다.
- 주의점: Bedrock 구성의 Codex는 로컬 워크플로 중심입니다.
- OpenAI Help Center는 image generation, voice transcription, cloud plugin store, cloud agents, MCP namespace tools와 tool discovery가 현재 제외된다고 적었습니다.
OpenAI와 AWS가 2026년 6월 1일 OpenAI GPT-5.5, GPT-5.4 모델과 Codex on Amazon Bedrock 일반 제공(GA)을 발표했습니다. OpenAI 발표문은 이 결정을 "기업이 이미 사용하는 보안, 거버넌스, 배포 워크플로 안에서 OpenAI를 쓰는 경로"로 설명했고, AWS News Blog는 Responses API 호환 엔드포인트와 Codex 설정값을 함께 공개했습니다. 모델 성능표보다 조달 경로, 인증, Region, 과금 방식이 앞에 나온 발표입니다.
이번 발표에서 개발자가 먼저 확인할 문장은 OpenAI의 "OpenAI frontier models and Codex are generally available on AWS"입니다. OpenAI는 Bedrock을 통해 "수백만 AWS 고객"이 OpenAI 모델과 Codex를 쓸 수 있다고 적었고, Codex를 "매주 500만 명 이상"이 사용하는 소프트웨어 엔지니어링 에이전트라고 설명했습니다. AWS News Blog는 Codex 사용자를 "매주 400만 명 이상 개발자"로 적었습니다. 두 수치는 같은 날 발표 안에서도 다르므로, 숫자 자체보다 OpenAI와 AWS가 Codex를 개인 개발자 도구가 아니라 기업 배포 대상 워크로드로 포장했다는 점이 더 읽을 만합니다.
AWS 쪽 세부사항은 더 실무적입니다. AWS는 GPT-5.5를 "가장 어려운 고객 워크로드"용, GPT-5.4를 가격 대비 성능용 선택지로 설명했습니다. 두 모델은 Amazon Bedrock의 next-generation inference engine에서 Responses API로 호출됩니다. 예시 엔드포인트는 https://bedrock-mantle.us-east-2.api.aws/openai/v1이고, Python의 OpenAI SDK를 그대로 쓰되 base_url과 model id를 Bedrock 값으로 바꿉니다.
from openai import OpenAI
client = OpenAI(
base_url="https://bedrock-mantle.us-east-2.api.aws/openai/v1",
api_key="<BEDROCK_API_KEY>",
)
response = client.responses.create(
model="openai.gpt-5.5",
input="Design a distributed architecture on AWS in Python.",
reasoning={"effort": "medium"},
text={"verbosity": "low"},
)
이 코드는 새 SDK를 배우라는 신호가 아닙니다. AWS가 OpenAI API surface를 Bedrock 안으로 끌어와 기존 Python, curl, OpenAI SDK 기반 코드를 부분적으로 유지하려는 신호입니다. Bedrock이 model catalog, IAM, quota, billing, logging을 맡고, 애플리케이션 코드는 OpenAI Responses API에 가까운 모양을 유지합니다. API 모양이 같아도 운영 책임은 달라집니다. 장애, quota, Region, billing 문의는 OpenAI 계정이 아니라 AWS 계정과 Bedrock 지원 경로로 이동합니다.
| 항목 | OpenAI API 직접 사용 | Amazon Bedrock 경유 |
|---|---|---|
| 인증 | OpenAI API key 또는 ChatGPT 계정 기반 설정 | Bedrock API key, AWS SDK credential chain, IAM 통제 |
| API 경로 | OpenAI-hosted Responses API | Bedrock의 OpenAI-compatible Responses API |
| 운영 단위 | OpenAI 조직, 프로젝트, rate limit, billing | AWS 계정, Region, quota, CloudTrail, Bedrock controls |
| Codex 범위 | OpenAI-hosted 기능과 cloud agent 기능에 가까움 | 로컬 CLI·앱·IDE inference 중심, 일부 cloud 기능 제외 |
Codex 쪽 변화는 설정 파일에서 더 선명합니다. AWS는 Codex CLI, Codex App, VS Code, JetBrains, Xcode 통합에서 모든 model inference를 Bedrock의 Responses API로 보낼 수 있다고 적었습니다. Bedrock API key를 쓰는 경우 AWS_BEARER_TOKEN_BEDROCK를 환경 변수로 두고, ~/.codex/config.toml에 provider와 Region을 적습니다.
model = "openai.gpt-5.5"
model_provider = "amazon-bedrock"
[model_providers.amazon-bedrock.aws]
region = "us-east-2"

이 설정은 Codex를 "AWS 안에서 호스팅되는 에이전트"로 바꾸는 설정이 아닙니다. OpenAI Help Center는 Bedrock 구성에서 Codex가 로컬 CLI, desktop app, IDE extension으로 실행되고 inference request만 Amazon Bedrock으로 전달된다고 설명합니다. 요청 경로에 OpenAI-hosted Responses API가 들어가지 않는다는 설명도 붙었습니다. 코드 편집, 테스트 실행, 터미널 작업은 여전히 로컬 Codex harness와 사용자 환경에서 일어나고, 모델 호출과 계정 통제 계층이 AWS 쪽으로 이동합니다.
기업 개발팀 입장에서는 이 차이가 큽니다. 보안팀은 "개발자가 어떤 에이전트를 설치했는가"보다 "모델 요청이 어느 계정, 어느 Region, 어느 log trail, 어느 quota 아래에서 나가는가"를 묻습니다. Bedrock 경유 Codex는 그 질문에 AWS식 답을 줍니다. IAM과 model access control, billing, quota, Region 정책, Bedrock controls로 모델 호출을 묶을 수 있기 때문입니다. 반대로 OpenAI 계정의 cloud plugin store, cloud-managed tool discovery, Codex cloud agents에 기대는 워크플로는 같은 방식으로 따라오지 않습니다.
OpenAI Help Center가 적은 제외 목록은 기사에서 가장 실무적인 부분입니다. Bedrock 구성에서는 image generation, voice transcription, cloud plugin store, cloud configuration and policy management가 현재 제공되지 않습니다. Codex cloud agents도 빠집니다. OpenAI는 review, security, web agents를 예로 들었습니다. MCP namespace tools와 tool search도 현재 사용할 수 없으므로 MCP와 tool discovery 기능이 제한될 수 있다고 적었습니다. "Bedrock에서 Codex가 된다"와 "OpenAI 계정에서 쓰던 Codex의 모든 cloud 기능이 된다"는 같은 말이 아닙니다.
개발팀이 migration을 검토한다면 첫 테스트는 모델 품질이 아니라 작업 종류별 feature inventory가 되어야 합니다. 로컬 저장소에서 코드 수정, 테스트 실행, 리팩터링을 하는 Codex CLI 흐름은 Bedrock inference와 잘 맞습니다. 반대로 cloud review agent, security agent, web agent, cloud plugin store, managed tool discovery를 쓰는 팀은 OpenAI API 경로와 Bedrock 경로를 분리해 봐야 합니다. 같은 Codex라는 이름 아래서도 인증, 도구 발견, 실행 위치, 로그 소유자가 달라집니다.
Region도 비용과 품질만큼 중요합니다. AWS는 6월 1일 기준 GPT-5.5를 US East (Ohio)에서 제공하고, GPT-5.4를 US East (Ohio)와 US West (Oregon)에서 제공한다고 적었습니다. 데이터 레지던시 요구가 있는 고객에게는 선택한 Bedrock Region 안에 처리가 머문다고 설명했습니다. 이 문장은 미국 리전 안에서 통제해야 하는 기업에는 도움이 되지만, 다른 국가와 산업 규제를 가진 팀에는 아직 부족할 수 있습니다. AWS가 "full list of Regions"를 확인하라고 남긴 이유도 여기 있습니다.
latency와 capacity 설명도 낙관적으로만 읽기 어렵습니다. AWS는 GPT-5.5를 fast, GPT-5.4를 medium speed로 소개하면서도 실제 지연은 reasoning effort, 출력 길이, tool calls, background mode, Region, quota, throttling, prompt size, cache hits에 좌우된다고 적었습니다. Bedrock의 inference engine은 수요가 높을 때 요청을 거절하기보다 queue에 넣는다고 설명했습니다. 서비스 관점에서는 429 대신 queue가 나을 수 있지만, 대화형 코딩 에이전트에서는 queue 시간이 개발자 체감 속도로 바로 드러납니다.
과금 문장도 별도로 봐야 합니다. AWS는 "좌석 라이선스와 개발자별 약정 없이 token 단위로 지불"한다고 설명했습니다. 팀별 seat 조달을 싫어하는 조직에는 매력적인 문장입니다. 하지만 코딩 에이전트는 일반 챗봇보다 토큰 사용량이 튀기 쉽습니다. 대형 monorepo 탐색, test failure 로그, 반복 patch, background reasoning이 합쳐지면 seat 비용 대신 account-level token budget과 quota 관리가 필요합니다. Bedrock으로 옮긴 뒤 비용 통제가 쉬워지는 것이 아니라 비용 통제 단위가 AWS 비용 관리 체계로 바뀝니다.
OpenAI가 발표문 끝에 Daybreak를 붙인 점도 눈에 띕니다. OpenAI는 Daybreak가 cyber models와 Codex Security를 포함한다고 설명했습니다. secure code review, threat modeling, patch validation, dependency risk analysis, detection, remediation guidance를 개발 루프 안으로 가져오려는 구상입니다. 다만 이 문단은 "future availability"입니다. 6월 1일 GA 범위에 Daybreak가 포함됐다고 쓰면 과장입니다. 지금 확인된 것은 OpenAI 모델과 Codex의 Bedrock 경로이고, 보안 전용 cloud agent는 향후 경로로만 언급됐습니다.
AWS의 4월 28일 preview 발표와 비교하면 GA 발표에서 빠진 단어도 있습니다. 4월 AWS What's New는 OpenAI models, Codex, OpenAI 기반 Managed Agents를 limited preview로 묶었습니다. 각 agent가 identity를 갖고 action을 logging하며 Bedrock AgentCore default compute environment에서 실행된다고 설명했습니다. 6월 1일 AWS News Blog는 GPT-5.5, GPT-5.4, Codex 사용법을 전면에 두고 Managed Agents를 같은 수준으로 다루지 않았습니다. 현재 발행 기사에서는 Managed Agents를 GA 항목처럼 쓰지 않는 편이 안전합니다.
커뮤니티 반응은 preview 시점부터 신중했습니다. Hacker News 스레드에서는 4월 발표가 press release 중심이고 실제 제품 가용성을 봐야 한다는 댓글이 붙었습니다. Reddit 쪽에서는 Bedrock UI에 보이는지, Region별로 바로 쓸 수 있는지, 기존 OpenAI API 대비 latency와 cost가 어떻게 달라지는지 묻는 글이 이어졌습니다. 이 반응은 자연스럽습니다. Bedrock 같은 중간 계층은 계약과 governance friction을 줄일 수 있지만, 개발자가 매일 느끼는 속도와 기능 parity를 자동으로 보장하지는 않습니다.
한국어권 독자에게 이번 발표의 독특한 부분은 "OpenAI가 AWS에 들어왔다"보다 "Codex가 AWS 인증과 결제 아래 들어왔다"입니다. 모델 API는 이미 여러 cloud marketplace와 gateway를 통해 유통됩니다. 코딩 에이전트는 다릅니다. 에이전트는 파일을 읽고, 테스트를 돌리고, patch를 만들고, sometimes long-horizon 작업을 유지합니다. 이때 기업은 모델 provider만이 아니라 실행 위치, 권한, 로그, 리뷰 단위, tool discovery를 함께 봅니다. Bedrock GA는 그 질문을 OpenAI 제품팀만이 아니라 AWS platform 팀도 같이 받겠다는 신호입니다.
개발자 실험 순서는 단순합니다. 첫째, OpenAI 직접 경로에서 쓰던 prompt와 harness를 Bedrock Responses API로 호출해 결과 차이를 봅니다. 둘째, Codex CLI에서 model_provider = "amazon-bedrock"를 켜고 동일 저장소의 작은 작업을 실행합니다. 셋째, Region별 latency, queue, quota, tool call 길이를 측정합니다. 넷째, cloud plugin store, MCP tool discovery, Codex cloud agents가 필요한 workflow를 별도 목록으로 뺍니다. 이 네 단계가 끝나기 전에는 "Bedrock으로 통합"이라는 조달 문구가 실제 개발 워크플로에 맞는지 판단하기 어렵습니다.
마지막으로, 이번 GA는 Microsoft와 AWS의 단순 cloud 경쟁 기사로만 쓰기에는 너무 좁고 구체적인 발표입니다. OpenAI 모델이 Bedrock catalog에 들어온 사건이기도 하지만, 더 직접적인 변화는 기업 개발팀의 AI coding agent 구매 단위가 바뀐다는 점입니다. API key를 개인이나 팀 단위로 나눠 들고 쓰던 Codex가 AWS account, IAM, Region, token billing, Bedrock quota 아래에서 운영될 수 있습니다. 그 대가로 OpenAI-hosted cloud 기능 일부는 빠지고, 지원 경계도 OpenAI와 AWS 사이로 나뉩니다. 생산 도입을 검토하는 팀은 모델 이름보다 이 경계를 먼저 읽어야 합니다.