이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Codex의 모델 추론 요청을 고객 AWS 계정 안의 LiteLLM 게이트웨이로 보내면 모델 접근, 사용자별 키, 예산, 요청·토큰 한도, 사용량 기록을 중앙에서 관리할 수 있습니다. Codex는 개발자 워크스테이션에서 로컬 파일과 승인된 도구를 계속 실행하고, LiteLLM은 AWS WAF와 Application Load Balancer를 거쳐 Amazon Bedrock의 승인된 모델로 각 Responses API 요청을 중계합니다. AWS ECS Fargate, RDS for PostgreSQL, Secrets Manager, KMS, ECR, CloudWatch를 조합한 참조 배포는 semantic continuation, 스트리밍, function call까지 검증하지만 게이트웨이 운영과 데이터베이스, 업그레이드, 장애 대응 부담은 고객 팀이 맡아야 합니다. 네이티브 IAM Identity Center 통제가 충분하면 직접 Amazon Bedrock 연결이 더 단순하고, 운영 부담을 줄여야 하면 Portkey 같은 관리형 또는 하이브리드 경로를 같은 Responses 계약 테스트로 평가해야 합니다.
섹션별 상세
Codex는 로컬 sandbox와 승인 설정을 유지한 채 모델 추론 요청만 고객 AWS 계정으로 보낼 수 있어, 코드와 도구 실행 경계를 개발자 워크스테이션에 남깁니다. 개발자가 현재 작업 맥락과 도구 정의를 LiteLLM의 /v1/responses endpoint로 보내면 AWS WAF와 Application Load Balancer가 요청을 통과시키고, ECS Fargate의 LiteLLM이 인증과 모델·소비 정책을 적용한 뒤 Amazon Bedrock을 호출합니다. 모델이 도구를 요청하면 Codex가 로컬에서 명령을 실행하고 결과를 다음 Responses 요청으로 다시 보내므로, 중앙 게이트웨이는 모델 턴을 통제하지만 개발자 환경의 일반-purpose shell을 대신 제공하지 않습니다.
LiteLLM을 중간 제어점으로 두면 개발자와 팀마다 모델 접근 방식이 달라지는 문제를 모델 alias, virtual key, 예산, requests-per-minute·tokens-per-minute 제한으로 통일할 수 있습니다. 각 요청은 ECS task role로 Amazon Bedrock에 도달하지만, LiteLLM의 scoped key와 요청 기록에는 원래 사용자나 팀의 식별 정보를 남길 수 있어 사용량과 비용을 귀속할 수 있습니다. 그 대신 고객 팀이 게이트웨이 가용성, RDS 수명주기, 버전 업그레이드, 장애 대응, 용량 계획을 직접 맡으므로 직접 Bedrock 연결보다 운영 범위가 커집니다.
bash
git clone https://github.com/openai-on-aws/guidance-codex.git
cd guidance-codex
git checkout feat/enterprise-gateway-readiness
cp deployment/litellm/.env.deploy.example \
deployment/litellm/.env.deployCodex용 LiteLLM 배포 저장소를 복제하고 검토된 기능 브랜치와 배포 환경 파일을 준비합니다.
bash
CONFIRM_AWS_WRITE=1 make litellm-build
# Direct helper invocation used by Make:
# CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh buildDigest가 고정된 LiteLLM 이미지를 빌드해 Amazon ECR에 푸시하고, 변경 가능한 태그 대신 이미지 digest를 기록합니다.
참조 배포는 VPC 내부 private subnet의 ECS Fargate와 RDS for PostgreSQL을 중심으로 구성하고, Secrets Manager와 KMS로 키를 보호하며, ECR에는 digest가 고정된 LiteLLM 이미지를 저장합니다. ENABLE_TLS=true, ALLOWED_CIDR, ENABLE_WAF, DB_MULTI_AZ=true, DESIRED_COUNT=2, MIN_TASK_COUNT=2, MAX_TASK_COUNT=10 같은 설정으로 HTTPS, 네트워크 제한, 웹 보호와 확장 범위를 정하고, ECS circuit-breaker rollback과 ALB health check로 배포 상태를 확인합니다. ECS task port 4000과 PostgreSQL port 5432를 공개하지 않고 승인된 corporate 또는 VPN CIDR만 ALB에 접근시키는 구성이 고객 환경의 기본 보안 조건으로 제시됩니다.
bash
CODEX_API_SECRET_ID=codex-litellm-gateway/alice-key
[email protected]
[email protected]
CODEX_KEY_MODELS=gpt-5.5
CODEX_KEY_MAX_BUDGET=50
CODEX_KEY_BUDGET_DURATION=30d
CODEX_KEY_TPM_LIMIT=100000
CODEX_KEY_RPM_LIMIT=1000사용자별 LiteLLM 키에 허용 모델, 예산 기간, 분당 토큰 한도와 요청 한도를 설정합니다.
개발자에게 LiteLLM master key를 배포하지 않고 사용자별 Secrets Manager secret을 읽을 IAM 권한만 부여하는 방식으로 인증 범위를 좁힙니다. 예시 키는 gpt-5.5만 허용하고 최대 예산 50, 30d 기간, TPM 100000, RPM 1000을 지정하며, 생성된 자격 증명은 KMS로 암호화된 secret에 직접 기록됩니다. Codex의 auth command는 실행 시점에 named AWS profile로 토큰을 읽어 표준 출력으로 전달하므로 bearer token이 config.toml에 저장되지 않습니다.
toml
model = "gpt-5.5"
model_provider = "litellm-gateway"
web_search = "disabled"
[model_providers.litellm-gateway]
name = "LiteLLM Gateway"
base_url = "https://codex-gateway.example.com/v1"
wire_api = "responses"
[model_providers.litellm-gateway.auth]
command = "/absolute/path/to/python3"
args = [ "/absolute/path/to/deployment/scripts/aws-secret-auth.py", "--aws-cli", "/absolute/path/to/aws", "--region", "us-east-1", "--secret-id", "codex-litellm-gateway/alice-key", "--field", "LITELLM_API_KEY", "--profile", "developer-profile", "print-token" ]
timeout_ms = 30000
refresh_interval_ms = 300000Codex가 LiteLLM의 Responses API를 사용하고, 인증 토큰은 AWS Secrets Manager에서 실행 시점에 읽도록 사용자 설정을 구성합니다.
단순한 텍스트 응답 성공만으로는 Codex 에이전트 호환성을 판단할 수 없어, 포함된 strict probe가 Responses object의 필드와 출력 형태, previous_response_id의 실제 상태 연속성, server-sent event streaming, call ID를 포함한 강제 function-tool call을 검사합니다. 라이브 검증에서는 CloudFormation CREATE_COMPLETE, ECS service ACTIVE, 1 desired와 1 running Fargate task, COMPLETED rollout, healthy ALB target이 확인됐고, PostgreSQL 17.9는 available 상태이며 암호화되고 외부 공개가 차단됐습니다. 이 검사는 load test가 아니므로 운영 전에는 동시 세션, 장시간 stream, 취소, 키 폐기, 장애 복구와 예상 최대 트래픽을 별도로 점검해야 합니다.
bash
codex exec --sandbox read-only --ephemeral \
"Reply with exactly LITELLM_GATEWAY_OK and no other text."
codex exec --sandbox read-only --ephemeral \
"Read README.md with shell tools and summarize the deployment architecture. Do not modify files."첫 명령은 게이트웨이 연결을 확인하고, 두 번째 명령은 로컬 파일 읽기 도구를 포함한 Codex 작업 루프를 점검합니다.
LiteLLM Request Logs는 key alias, upstream Amazon Bedrock model, token count, request duration, cost와 상태 코드를 기록해 모델 접근 경로를 추적하게 합니다. 도구를 사용하는 Codex 작업은 로컬 도구 결과를 후속 Responses 요청으로 보내므로 로그에 여러 행이 생기며, Usage 화면은 검증 기간에 총 15개 요청, 성공 14개, 총 735 tokens, 총 지출 0.01달러를 표시합니다. 운영팀은 ECS와 ALB, RDS, LiteLLM 거부, 토큰과 비용, secret 접근, IAM 변경, WAF 차단을 함께 관찰하고 프롬프트와 응답의 기록 여부에는 마스킹·암호화·접근 통제·보존 정책을 적용해야 합니다.
AWS native identity와 CloudTrail 감사 기록만으로 요구사항을 충족하면 IAM Identity Center profile을 사용하는 amazon-bedrock Codex provider가 더 단순한 기준 경로입니다. 이 방식은 게이트웨이와 데이터베이스 운영을 제거하고 개발자의 AWS session identity를 CloudTrail에 남기지만, 중앙 gateway-level hard budget과 routing policy는 제공하지 않습니다. 관리형 control plane이나 hybrid data plane을 선호하면 Portkey를 사용할 수 있으나, vendor licensing, 데이터 처리, 리전 가용성, 장애 방식, 지원 경계를 검토하고 LiteLLM과 동일하게 semantic continuation, streaming, function call, 실제 Bedrock route와 IAM role을 검증해야 합니다.
용어 해설
- Responses API
- — Codex 같은 에이전트가 모델과 대화하고 도구 호출을 이어가기 위한 API 형식입니다. 단순한 텍스트 응답뿐 아니라 previous_response_id를 이용한 의미적 연속성, 서버 전송 이벤트 스트리밍, function call과 call ID 처리를 포함합니다. 게이트웨이가 이 계약을 제대로 보존해야 에이전트 작업 루프가 정상 작동합니다.
- 범위 지정 키(Scoped Key)
- — 특정 사용자나 팀에만 할당하고 모델 목록, 예산, 토큰 한도, 요청 횟수 한도를 연결한 인증 키입니다. LiteLLM은 이 키를 요청 기록과 연결해 사용량을 구분하고, 설정된 소비 한도를 넘은 요청을 거부합니다. 개발자에게 master key를 배포하지 않으면서 사용자별 통제를 유지하는 방식입니다.
- 의미적 연속성(Semantic Continuation)
- — 이전 응답의 식별자를 다음 요청에 전달하는 것만으로 끝내지 않고, 후속 요청이 실제로 이전 응답의 내용을 이어받는지 확인하는 동작입니다. 기사에서는 첫 응답에 고유한 표식을 넣고 다음 응답에서 그 표식을 회수하는 방식으로 검증합니다. 에이전트의 다단계 작업에서 대화 상태가 보존되는지 판단하는 핵심 검사입니다.
- 함수 호출(Function Calling)
- — 모델이 직접 실행하는 대신 호출할 도구와 인자를 응답으로 반환하고, 클라이언트가 해당 함수를 실행한 뒤 결과를 다음 요청에 전달하는 방식입니다. Codex에서는 LiteLLM이 모델 요청을 중계하고 실제 도구 실행은 개발자 워크스테이션의 로컬 sandbox가 맡습니다. 따라서 Responses API가 call ID와 도구 결과의 연속 흐름을 보존해야 합니다.
- 목표 추적 자동 확장(Target Tracking Autoscaling)
- — 서비스의 관측 지표를 목표값과 비교해 실행 중인 작업 수를 자동으로 조정하는 ECS 확장 방식입니다. 이 배포 구성은 MIN_TASK_COUNT와 MAX_TASK_COUNT 범위 안에서 LiteLLM 작업 수를 관리합니다. 요청 증가에 대응하면서도 운영자가 고정된 작업 수만 유지하지 않도록 하는 인프라 기능입니다.
기술
- OpenAI ChatGPT Codex
- LiteLLM
- Amazon ECS
- Amazon Fargate
- Amazon Bedrock
- Amazon RDS for PostgreSQL
- AWS Secrets Manager
- AWS KMS
- Amazon CloudWatch
- Amazon ECR
- AWS WAF
- Application Load Balancer
- AWS CloudFormation
- AWS IAM Identity Center
- Portkey
- Docker Buildx
- AWS CLI
활용 사례
- 개발자별 Codex 모델 접근과 비용 귀속
- 승인된 Amazon Bedrock 모델 alias만 제공하는 기업용 코딩 에이전트 운영
- 사용자·팀별 예산과 TPM·RPM 제한
- Codex의 로컬 도구 실행과 중앙 모델 요청 통제의 분리
- Responses API 호환성 검증과 모델 경로 관측
언급된 리소스
문서OpenAI on Amazon Bedrock
문서Amazon Bedrock documentation
튜토리얼LiteLLM on AWS quickstart
튜토리얼IAM Identity Center quickstart
튜토리얼Portkey evaluation quickstart
문서Production deployment guidance
문서Codex custom model providers
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 04.수집 2026. 09. 04.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
