Set up OpenAI ChatGPT Codex with LiteLLM on Amazon ECS and Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Codex의 로컬 작업·도구 실행을 유지하면서, 고객 AWS 계정의 Amazon ECS에서 운영하는 LiteLLM을 통해 Amazon Bedrock 모델 접근과 사용 정책을 중앙 관리하는 구성을 설명한다.

📌 핵심 요약

• Codex는 개발자 워크스테이션에서 파일을 읽고 승인된 도구를 실행하며, 모델 요청은 LiteLLM의 /v1/responses 엔드포인트를 거쳐 Amazon Bedrock으로 전달한다.
• LiteLLM은 모델 인증·라우팅, 사용자·팀별 키, 예산, 호출률 제한, 사용량 관측을 제공하지만, 고객이 게이트웨이 가용성·데이터베이스·업그레이드·장애 대응·용량 계획을 책임진다.
• 배포 예시는 us-east-1에서 검증됐으며, 게이트웨이 별칭 openai.gpt-5.5를 LiteLLM 설정의 bedrock_mantle/openai.gpt-5.5에 연결한다. 모델 가용성은 계정과 리전에 따라 달라진다.
• 배포는 사전 검사, 불변 이미지 빌드, 실행하지 않은 CloudFormation 변경 세트 검토, 실제 배포 순서로 진행하며, TLS·접속 CIDR 제한·프라이빗 서브넷과 사용자별 제한 키를 적용한다.
• Codex의 공급자·인증 설정은 사용자 수준 ~/.codex/config.toml에 추가하고 Responses API를 사용한다. 인증 도우미는 지정된 AWS 프로필로 Secrets Manager의 키를 조회해 토큰을 전달하므로 설정 파일에 토큰을 저장하지 않는다.

🧩 주요 포인트

1. 로컬 실행과 모델 접근의 역할 분리 → LiteLLM은 각 모델 호출을 통제하고, Codex의 샌드박스와 승인 정책은 로컬 도구 실행을 계속 통제한다.
2. 사용자·팀별 키와 중앙 사용 정책 → 공유된 상위 모델 호출 경로에서도 게이트웨이 수준의 사용자 식별과 소비 통제가 가능하지만 자체 운영 책임이 따른다.
3. 불변 이미지·변경 세트 검토·외부 토큰 조회 → 배포 대상을 고정하고 변경을 사전에 검토하며, Codex 설정 파일에 인증 토큰을 저장하지 않는 구성을 제공한다.

🧠 상세 정리

1. 기업 도입의 배경과 구성 목적

원문은 생성형 AI 코딩 에이전트 활용이 개인 실험에서 조직 차원의 관리된 도입으로 확대될 때 필요한 통제를 출발점으로 삼는다. 개발자는 에이전트로 저장소를 이해하고 코드를 작성하며 테스트와 여러 단계의 엔지니어링 작업을 수행하지만, 조직은 모델 접근과 사용량 귀속을 일관되게 관리하고 예산·호출률 제한과 관측 기능도 적용해야 한다. 이를 위해 고객 AWS 계정의 Amazon ECS에 LiteLLM 게이트웨이를 배포하고 Amazon Bedrock의 OpenAI 모델에 연결하는 구성을 제시한다. 전체 구현은 guidance-codex 저장소에 있으며, 본문의 주된 배포 경로는 LiteLLM on AWS 빠른 시작 안내를 따른다.

2. 모델 요청과 로컬 도구 실행의 흐름

Codex는 현재 작업 문맥과 사용 가능한 도구 정의를 LiteLLM의 /v1/responses 엔드포인트로 전송한다. 요청은 Application Load Balancer와 AWS WAF의 네트워크·웹 계층 통제를 거쳐 AWS Fargate의 LiteLLM에 도달하며, LiteLLM은 호출자 인증과 모델·소비 정책 확인 후 ECS 작업 역할로 Amazon Bedrock을 호출한다. 모델이 반환한 텍스트나 함수 호출은 LiteLLM을 통해 Codex로 돌아오고, 도구 실행이 필요하면 Codex가 로컬 샌드박스와 승인 정책에 따라 처리한 뒤 결과를 다음 요청에 담는다. 따라서 게이트웨이는 각 모델 호출을 관리하며, AWS 계정의 범용 셸을 받거나 Codex의 로컬 승인 절차를 대체하지 않는다.

3. 지원 인프라와 자체 운영의 선택 기준

참조 배포는 LiteLLM 상태·사용량·예산 데이터를 Amazon RDS for PostgreSQL에 보관하고, Secrets Manager와 AWS KMS로 게이트웨이 및 제한 키를 관리한다. CloudWatch 로그·Container Insights·경보는 운영 상태를 관측하며, Amazon ECR은 불변 게이트웨이 이미지를 보관하고 AWS WAF 관리형 보호와 출발지 IP 기반 호출률 제한은 선택적으로 제공된다. 원문은 기본 AWS 자격 증명, IAM 정책, CloudTrail 로그만으로 요구사항을 충족한다면 Amazon Bedrock 직접 접근이 가장 단순한 선택이라고 설명한다. 개발자·팀·모델 공급자 전반의 추가 통제가 필요하면 LiteLLM이 유용하지만, 고객은 게이트웨이 가용성부터 데이터베이스 수명주기, 버전 업그레이드, 장애 대응과 용량 계획까지 직접 책임진다.

4. 사전 요구사항과 배포 환경 설정

실습에는 VPC·ECS·로드 밸런서·RDS 등 관련 AWS 리소스를 생성할 권한과 배포 리전에서 선택한 OpenAI 모델을 사용할 수 있는 접근 권한이 필요하다. 로컬 도구로는 인증된 프로필을 갖춘 AWS CLI 버전 2, Buildx가 포함된 Docker, Codex CLI, Python 3가 요구되며, HTTPS에는 공개 Route 53 호스팅 영역이나 같은 리전의 기존 ACM 인증서가 필요하다. 검증 환경은 us-east-1이고, 게이트웨이 별칭 openai.gpt-5.5는 bedrock_mantle/openai.gpt-5.5에 연결되지만 모델 가용성은 계정과 리전에 따라 달라진다. 저장소의 예제 파일을 복사한 .env.deploy는 Git에서 제외되며, 여기에 프로필·리전·접속 CIDR·DNS·인증서 값을 지정하고 로드 밸런서, Fargate, RDS, 로그, 모델 추론 등의 과금도 고려한다.

5. 사전 검사와 불변 이미지 기반 배포

배포는 make litellm-check로 읽기 전용 사전 검사를 수행하는 단계에서 시작하며, AWS CLI와 자격 증명, Docker, 이미지 참조, 리전 일치, CIDR 제한, TLS 입력값 등을 확인한다. 빌드 단계는 다이제스트로 고정된 LiteLLM 기본 이미지를 사용해 Amazon ECR에 이미지를 푸시하고, 결과 다이제스트를 Git에서 제외된 로컬 상태 파일에 기록한다. 이어 make litellm-plan은 CloudFormation 변경 세트를 생성하되 실행하지 않아 배포 내용을 먼저 검토할 수 있도록 한다. 검토 후 쓰기 확인 변수를 지정해 배포하면 네트워킹 스택과 게이트웨이 스택이 순서대로 적용되며, 상태 명령으로 스택 상태와 출력을 확인하고 CloudFormation에는 변경 가능한 태그 대신 불변 다이제스트를 전달한다.

6. 운영 안정성과 네트워크 보호

운영 지향 설정 예시는 TLS와 WAF를 활성화하고 RDS 다중 가용 영역을 사용하며, ECS 작업 수는 희망값과 최솟값을 각각 2개, 최댓값을 10개로 지정한다. ECS 서비스에는 배포 회로 차단기 기반 롤백과 Application Load Balancer 상태 검사가 적용되고, 참조 템플릿은 목표 추적 자동 확장, 로그·데이터 암호화, RDS 백업, 로드 밸런서 접근 로그와 운영 경보도 구성한다. 고객 환경에서는 신뢰할 수 있는 DNS 이름과 ACM 인증서를 사용하고, 로드 밸런서 접근을 승인된 회사 또는 VPN의 CIDR로 제한하도록 설명한다. 기존 고객 네트워크를 사용할 때는 공개 서브넷과 비공개 애플리케이션·데이터베이스 서브넷을 구분하며, ECS 작업과 RDS를 비공개 영역에 배치하고 포트 4000과 5432를 공개하지 않는다.

7. 사용자·팀별 제한 키와 소비 정책

원문은 개발자에게 LiteLLM 마스터 키를 배포하지 않고, 사용자 또는 팀에 대응하는 식별 정보와 정책을 Git에서 제외된 배포 파일에 지정하도록 안내한다. 예제는 [email protected]에 연결된 키에 gpt-5.5 모델, 최대 예산 50, 예산 기간 30d, 분당 토큰 한도 100000과 분당 요청 한도 1000을 설정한다. 키 발급 도우미는 자식 프로세스 내부에서 마스터 자격 증명을 가져와 /key/generate를 호출하고, 생성된 키를 KMS로 암호화된 Secrets Manager 비밀에 직접 저장하며 자격 증명을 명령 인수나 터미널 출력에 노출하지 않는다. 조직 배포에서는 개발자 프로필이 자신에게 할당된 비밀만 읽고 스택의 KMS 키로 복호화하도록 권한을 부여하며, 팀이나 환경별로 비밀 경로와 IAM 정책을 분리한다.

8. Codex 공급자 설정과 토큰 조회

make litellm-codex-config는 CloudFormation에서 배포된 게이트웨이 엔드포인트를 읽어 Codex 공급자 설정을 출력하며, 사용자 설정 파일을 자동으로 수정하지 않는다. 출력은 사용자 수준 ~/.codex/config.toml에 추가해야 하고, 공급자·인증 설정은 프로젝트 내부의 .codex/config.toml에서는 무시된다고 설명한다. 예제는 gpt-5.5 모델과 litellm-gateway 공급자, /v1 기본 주소, responses 통신 API를 지정하고 웹 검색을 비활성화한다. Codex는 표준 입력 없이 인증 명령을 실행해 표준 출력에서 토큰을 읽으며, 도우미는 지정된 AWS 프로필로 Secrets Manager의 현재 키를 조회하므로 토큰이 설정 파일에 저장되지 않는다. 제공된 본문은 관리 UI 설명 도중 끝나므로, 도입부에서 예고한 의미적 연속성·스트리밍·함수 호출 검증과 대안 구성의 상세 절차는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 중앙 게이트웨이의 통제 범위는 모델 접근 경로이며, 로컬 파일 접근과 도구 실행의 승인 책임은 Codex에 남는다.
• LiteLLM 도입 판단에는 중앙 정책의 필요성과 함께 게이트웨이·데이터베이스를 직접 운영하는 부담을 포함해야 한다.
• 불변 이미지 참조, 실행 전 변경 세트 검토, 사용자별 제한 키는 각각 배포 대상 고정, 변경 검토, 접근·소비 통제라는 다른 목적을 담당한다.

✅ 액션 아이템

• LiteLLM의 중앙 사용 정책 필요성과 게이트웨이 가용성·데이터베이스·업그레이드 운영 책임을 함께 평가.
• us-east-1과 대상 계정의 openai.gpt-5.5 가용성을 확인하고, 사전 검사·불변 이미지 빌드·CloudFormation 변경 세트 검토 순서로 배포 준비.
• 사용자 수준 ~/.codex/config.toml에 Responses API 공급자 설정과 Secrets Manager 기반 인증을 적용하고 사용자별 제한 키를 연결.

❓ 열린 질문

• LiteLLM에서 사용자·팀별 키에 적용할 예산과 호출률 제한은 어떻게 정할 것인가?
• 게이트웨이 가용성·데이터베이스·업그레이드·장애 대응·용량 계획의 운영 책임은 누가 맡을 것인가?
• 대상 계정과 us-east-1에서 openai.gpt-5.5 모델을 사용할 수 있는가?