OpenAI Codex on Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Codex를 개발자 워크스테이션에서 실행하면서 Amazon Bedrock으로 추론 요청을 보내고, 조직의 통제 요구에 맞는 접근 경로와 AWS 신원·관측·비용 증거를 검증해 최소 권한 파일럿부터 도입을 확대하는 방법을 설명한다.

📌 핵심 요약

• 기본 권고는 Native AWS Access로 소규모 최소 권한 파일럿을 시작하는 것이다. AWS 관리형 라우팅이나 Amazon Bedrock Guardrails가 필요하면 AgentCore Gateway를, 요청 경로에서 통제를 적용하려면 LLM Gateway를 선택하며, 커스텀 통합은 기존 선택지로 특정 요구를 충족할 수 없을 때 고려한다.
• 예제는 GPT-5.6 Sol을 사용하지만, 도입 전에 Sol·Terra·Luna 각각의 가용성을 선택한 계정, AWS 리전, 추론 경로에서 확인해야 한다. Native AWS Access에서는 기존 인력 신원 공급자와 IAM Identity Center를 통해 임시 AWS 자격 증명을 발급하며, 공급자 설정은 사용자 수준 또는 관리형 구성에 둔다.
• 파일럿은 AWS CLI 로그인과 Amazon Bedrock Runtime 직접 호출, Codex 공급자 구성, 비운영 저장소의 안전한 읽기 전용 작업 순서로 검증한다. 접근 확대 전에 승인 모델 접근, 신원·호출·감사 기록과 선택적 텔레메트리, 접근 철회 후 새 호출 거부를 확인하고, 두 사용자의 세션과 기록이 구분되는지도 시험한다.
• Codex OpenTelemetry는 클라이언트 활동을, Amazon Bedrock 서비스 지표와 활성화된 모델 호출 로그는 서비스 측 활동을 설명한다. 사용자 귀속과 비용에는 AWS 신원·감사 기록 및 AWS Cost and Usage Report(CUR)를 함께 사용해야 하며, 토큰 사용량을 비용 보고서로 제시해서는 안 된다. 게이트웨이 경로의 최종 사용자별 비용 배분에는 게이트웨이 텔레메트리와 지출 기록이 필요하다.
• 관측 예제는 관리 대상 파일럿 장치의 ADOT 수집기와 Amazon CloudWatch Coding Agent Insights 대시보드를 사용한다. 사용자·팀별 집계에는 검증된 신원 속성이 필요하며, 전송 가능한 코드·프롬프트·파일·도구 출력을 정의하고 승인되지 않은 비밀정보와 제한 데이터를 제외해야 한다. 생성된 변경은 병합 전에 개발자가 검토·테스트해야 하며, 텔레메트리만으로 정확성이나 안전성을 입증할 수 없다.

🧩 주요 포인트

1. 필요한 통제 수준 → 접근 경로와 운영 책임 결정: IAM으로 충분한 파일럿은 Native AWS Access에서 시작하고, 관리형 라우팅·Guardrails 또는 요청 경로 통제가 필요할 때 게이트웨이를 선택하면 불필요한 운영 부담을 줄일 수 있다.
2. 단계별 호출 검증과 두 사용자 시험 → 접근 문제의 원인과 귀속 경계 확인: AWS 접근과 Codex 구성을 나누어 검증하고, 별도 세션·기록 및 접근 철회 결과를 확인해야 도입 확대의 근거가 생긴다.
3. 클라이언트 활동·서비스 활동·신원·청구 증거의 구분 → 관측 해석과 비용 배분의 정확성 확보: CloudWatch 운영 지표는 활동 파악에 활용하되, 사용자 귀속과 비용 판단에는 배포 경로에 맞는 별도 증거를 결합해야 한다.

🧠 상세 정리

1. 도입 배경과 기본 설계

개발자들은 익숙하지 않은 코드를 탐색하고 변경을 수행하며 반복적인 엔지니어링 작업을 처리하기 위해 Codex와 Amazon Bedrock을 함께 사용하고 있다. 플랫폼 팀의 과제는 이 도구를 제공하면서 모델 접근, 신원, 운영을 위한 별도 체계를 추가로 만들지 않는 것이다. Codex는 개발자 워크스테이션에서 계속 실행되고, 지원되는 OpenAI 모델의 추론에는 Amazon Bedrock을 사용할 수 있으므로, 핵심 설계 대상은 모델 요청의 전달 경로와 정책·운영 통제의 적용 위치다. 글은 기존 AWS 신원, IAM, 리전, 관측 관행 안에 이 경로를 통합하고, 소규모 최소 권한 파일럿에서 시작해 접근 확대 전 필요한 검증을 수행하도록 권고한다. 예제 모델은 GPT-5.6 Sol이지만, 시작 전에 Amazon Bedrock의 리전별 지원 모델 문서를 검토해 Sol·Terra·Luna가 계획한 리전과 추론 경로에서 제공되는지 확인해야 한다.

2. 통제 요구에 따른 접근 경로 선택

기업 도입에서는 인증뿐 아니라 허용 사용자, 승인 모델과 리전, 구성 저장 위치, 수집할 텔레메트리, 사용량 배분 방식, 허용할 스킬과 Model Context Protocol(MCP) 서버까지 정해야 한다. 현재 요구를 충족하는 가장 단순한 접근 경로가 대체로 운영 부담도 가장 낮으며, AWS 신원과 IAM 통제로 충분하다면 Native AWS Access가 일반적인 출발점이다. Amazon Bedrock AgentCore는 다양한 프레임워크와 모델로 에이전트를 구축·연결·최적화하는 플랫폼이며, 그 기능인 AgentCore Gateway는 AWS 관리형 라우팅이나 Amazon Bedrock Guardrails 등이 필요한 팀에 적합하다. 이미 게이트웨이를 운영하거나 요청 경로에서 통제를 적용하려는 조직에는 LLM Gateway가 맞고, 커스텀 게이트웨이는 이 패턴의 고급 형태로 분류된다. 오픈 소스 Guidance for Codex on AWS 저장소는 Native AWS Access, AgentCore Gateway, ECS의 LiteLLM, Portkey, ADOT와 CloudWatch 관련 빠른 시작 자료를 제공하므로, 선택한 아키텍처에 맞는 예제로 파일럿을 진행하고 환경에 맞게 조정할 수 있다.

3. Native AWS Access의 신원과 사전 조건

Native AWS Access에서는 직원이 기존 인력 신원 공급자로 로그인하고, IAM Identity Center가 Codex에서 사용할 임시 AWS 자격 증명을 발급한다. 예제에서 Okta는 SAML로 인증을 처리하고 SCIM으로 사용자와 그룹을 IAM Identity Center에 프로비저닝하며, 신원 공급자 자체를 Codex에 설정하지는 않는다. 파일럿 사용자는 전용 그룹에 추가하고 해당 그룹을 IAM Identity Center에 프로비저닝하되, 할당 범위는 파일럿으로 제한해야 한다. 선택한 계정·리전·추론 경로에서 Sol·Terra·Luna를 각각 확인하고, 사용할 API가 요구하면 추론 프로파일도 준비해야 한다. 권한은 Codex의 모델 추론, 직접 검증 명령, 선택한 관측 목적지에 필요한 범위로 제한하며, 실행 전 비운영 저장소와 롤백 책임자도 정해야 한다.

4. 직접 호출 검증과 Codex 공급자 구성

구성 검증은 IAM Identity Center용 AWS CLI 프로파일로 로그인한 뒤 Amazon Bedrock Runtime을 직접 호출하고, Codex를 승인 모델로 설정한 다음 안전한 작업을 실행하는 순서다. 예제는 aws sso login --profile codex-bedrock으로 로그인하고 AWS_PROFILE을 설정한 뒤, us-east-2에서 bedrock-runtime converse를 사용해 us.openai.gpt-5.6-sol에 짧은 응답을 요청한다. 이 직접 호출은 AWS 접근 문제를 분리해 확인하는 단계이므로, 실패하면 프로파일, 리전, 모델 또는 추론 프로파일 접근, IAM 권한을 먼저 해결해야 한다. Codex 구성에서는 model_provider를 amazon-bedrock으로, model을 openai.gpt-5.6-sol로 지정하고, AWS 설정에 codex-bedrock 프로파일과 us-east-2 리전을 넣는다. 이때 Codex의 모델 ID와 직접 호출 예제의 모델 식별자를 구분해야 하며, 저장소가 공급자를 바꾸지 못하도록 설정은 ~/.codex/config.toml 같은 사용자 수준 또는 관리형 구성에 유지한다.

5. 파일럿 증거, 접근 철회와 두 사용자 격리

사용자를 추가하기 전에는 파일럿이 승인 모델에 도달하고 예상 기록을 남기며 접근을 정상적으로 철회할 수 있는지 확인해야 한다. aws sts get-caller-identity는 예상한 IAM Identity Center의 역할 수임 세션을 반환해야 하고, 파일럿 프로파일은 시험에 선택한 API와 리전을 통해 승인 모델을 호출할 수 있어야 한다. 이어 비운영 저장소에서 안전한 읽기 전용 Codex 작업을 완료하고, 신원·호출·감사 기록과 구성한 경우의 텔레메트리 등 예상 요청 경로 증거를 확인한다. 접근 철회는 구성 또는 IAM Identity Center 할당을 제거하고, 활성 세션을 조직 절차에 따라 처리하거나 만료를 기다린 뒤 새 호출이 거부되는지 검증하는 방식이다. 신원 격리는 한 사용자만으로 확인할 수 없으므로 두 파일럿 사용자가 별도로 로그인해 같은 무해한 작업을 수행하고, 역할 수임 세션과 감사 기록 및 구성된 텔레메트리가 서로 구분되는지 시험해야 한다. 로컬 수집기의 승인된 신원 문맥 추가도 관리형 등록 절차의 일부로 배포·구성된 경우에만 가능하다는 경계를 둔다.

6. 게이트웨이 검증과 커스텀 통합의 책임

중앙 라우팅이나 Amazon Bedrock Guardrails를 위한 AWS 관리형 인프라가 필요하면 AgentCore Gateway를 선택할 수 있고, 기존 LLM Gateway가 있거나 요청 경로의 통제가 필요하면 해당 게이트웨이를 활용할 수 있다. 어떤 경로든 파일럿 사용자에게 제공하기 전에 선택한 게이트웨이를 검증해야 한다는 것이 원문의 요구다. LLM Gateway에서는 먼저 Codex 요청 형식을 수용하는지 확인하고, 게이트웨이 팀이 정한 로그인 또는 토큰 흐름을 사용해야 한다. 사용자 초대 전에는 모델 라우팅, 모니터링, 실패 처리, 롤백을 시험해 접근 경로가 실제 운영 요구를 충족하는지 확인한다. 커스텀 기업 통합은 Native AWS Access, AgentCore Gateway, 기존 게이트웨이가 특정 요구를 충족하지 못할 때만 고려하는 가장 복잡한 선택지이며, 설계·보안·테스트·지원·운영이 필요한 또 하나의 서비스이므로 플랫폼 엔지니어링과 보안 조직이 처음부터 책임을 맡아야 한다.

7. 관측·신원·비용 증거와 데이터 통제

Codex OpenTelemetry, Amazon Bedrock 서비스 기록, AWS 신원 기록과 청구 데이터는 서로 다른 질문에 답하므로 배포 경로에 맞게 연관 지어 해석해야 한다. Codex OpenTelemetry는 클라이언트 활동을 설명하고, Amazon Bedrock 서비스 지표와 활성화된 모델 호출 로그는 서비스 측 활동을 보여주며, AWS 신원 기록과 AWS Cost and Usage Report(CUR)는 신원 및 청구 사용량의 증거를 제공한다. Native IAM Identity Center 접근에서는 호출자 신원 배분을 사용하는 CUR 2.0이 SSO 주체를 드러낼 수 있지만, 게이트웨이 경로의 최종 사용자별 배분에는 게이트웨이 텔레메트리와 지출 기록이 필요하다. 따라서 토큰 사용량을 비용 보고서로 제시해서는 안 되며, 선택한 모델 경로로 전송될 수 있는 코드·프롬프트·파일·도구 출력의 범위도 정의해야 한다. 조직이 해당 데이터 흐름을 승인하지 않았다면 비밀정보와 제한 데이터를 제외하고, 생성된 변경은 병합 전에 개발자가 검토하고 테스트해야 하며, 텔레메트리 자체가 정확성이나 안전성을 입증하지는 않는다.

8. ADOT와 CloudWatch를 통한 운영 관측

관측 예제는 Guidance for Codex on AWS 저장소의 ADOT 수집기 구성과 CloudWatch 대시보드를 사용하며, 승인된 수집기를 관리 대상 파일럿 장치마다 설치하고 AWS 인증을 구성하도록 안내한다. Codex의 otel 설정은 environment를 pilot으로, log_user_prompt를 false로 두고, 바이너리 프로토콜의 otlp-http 지표를 http://127.0.0.1:4318/v1/metrics로 전송하도록 지정한다. 안전한 Codex 작업을 실행한 뒤 관리형 CloudWatch 대시보드에 예상 운영 지표가 나타나는지 확인하며, 수집 항목에는 토큰 사용량, 턴, API 요청, 요청 시간, 도구 호출, 세션 출처 등이 포함된다. 사용자·팀별 대시보드 집계는 로컬 수집기가 검증된 신원 속성을 추가한 이후에만 가능하고, Bedrock 서비스 지표는 선택한 Runtime·Mantle·AgentCore 경로에 문서화된 네임스페이스, 지표명, 차원을 사용해야 한다. Amazon CloudWatch Coding Agent Insights 관리형 대시보드는 ADOT를 통해 수집한 Codex의 클라이언트 활동을 이해하는 데 사용하며, 사용자 귀속이나 비용 증거가 필요할 때는 AWS 신원·감사·청구 기록을 별도로 활용해야 한다.

🧾 핵심 주장 / 시사점

• 접근 경로 선택의 기준은 필요한 통제의 위치다. 기존 AWS 신원과 IAM으로 요구를 충족할 수 있는지 먼저 판단하고, 추가 요구가 있을 때 게이트웨이의 운영 책임을 수용하는 접근이 제시된다.
• 파일럿 성공은 모델 응답만으로 판단할 수 없다. 승인 경로의 호출, 사용자별 구분, 증거 수집, 접근 철회까지 확인해야 확대에 필요한 운영 근거가 갖춰진다.
• 관측 가능성과 비용 귀속, 코드의 정확성은 별개의 검증 대상이다. 활동 지표가 풍부해도 신뢰할 수 있는 신원·청구 증거나 개발자의 검토·테스트를 대신할 수는 없다.

✅ 액션 아이템

• 필요한 통제에 따라 Native AWS Access·AgentCore Gateway·LLM Gateway를 선택하고, Sol·Terra·Luna의 계정·AWS 리전·추론 경로별 가용성 확인.
• Native AWS Access 파일럿에서 Amazon Bedrock Runtime 직접 호출, Codex 읽기 전용 작업, 두 사용자의 세션·기록 구분, 접근 철회 후 새 호출 거부 검증.
• Codex OpenTelemetry·AWS 신원·감사 기록·CUR를 배포 경로에 맞게 연계하고, 승인되지 않은 비밀정보·제한 데이터 제외와 생성된 변경의 병합 전 검토·테스트 적용.

❓ 열린 질문

• 현재 필요한 통제는 Native AWS Access의 IAM으로 충족되는가, 아니면 AgentCore Gateway나 LLM Gateway가 필요한가?
• 선택한 계정·AWS 리전·추론 경로에서 Sol·Terra·Luna의 가용성과 승인 모델 접근이 확인되었는가?
• Codex OpenTelemetry와 AWS 신원·감사 기록·CUR를 통해 사용자별 활동과 비용을 구분하고, 게이트웨이 경로라면 필요한 텔레메트리와 지출 기록을 확보할 수 있는가?