모델 예산과 권한을 중앙 제어하는 LiteLLM 기반 Codex-Bedrock 연결 구조

기업용 코딩 에이전트의 관리형 도입과 중앙 제어 필요성

개별 개발자의 실험 단계를 넘어 조직 차원의 관리형 도입으로 전환하는 기업은 모델 접근 제어와 소비 추적을 위한 중앙 집중식 체계를 구축한다. OpenAI Codex(이하 Codex)를 사용하는 개발자는 로컬 워크스테이션의 샌드박스 환경에서 리포지토리 분석, 코드 작성, 테스트 수행과 같은 다단계 엔지니어링 작업을 처리한다. 조직은 이러한 에이전트 활동이 확산됨에 따라 팀 단위로 모델 접근 권한을 제어하고 소비 주체를 명확히 구분하여 비용을 할당해야 하는 과제에 직면한다. 특히 예산 설정과 속도 제한(Rate Limit)을 적용하고 모델 접근 경로를 실시간으로 관찰하는 거버넌스 체계가 없으면 API 호출 폭주로 인한 서비스 불안정성과 비용 통제 불능 상태가 발생한다.

기업은 Codex의 로컬 태스크 루프와 외부 모델 추론 계층을 분리하여 운영함으로써 이 문제를 해결한다. Codex는 개발자 워크스테이션에서 로컬 파일을 읽고 승인된 도구를 실행하는 책임을 유지하며, 모델 추론 요청만 고객의 AWS 계정 내 인프라로 라우팅한다. 이를 통해 조직은 개발자의 로컬 작업 환경을 변경하지 않고도 기업 수준의 보안 정책과 비용 제어 로직을 모델 소비 계층에 즉시 적용할 수 있다. 결과적으로 중앙 제어 구조는 개별 실험의 자율성과 엔터프라이즈 수준의 통제권 사이의 균형을 맞추는 핵심 기제로 작동한다.

Amazon ECS 기반 LiteLLM 게이트웨이 아키텍처와 요청 흐름

시스템 팀은 Amazon Elastic Container Service(Amazon ECS)에 LiteLLM 게이트웨이를 배포하여 Codex와 Amazon Bedrock 사이의 인증, 라우팅, 예산, 속도 제한을 중앙에서 제어한다. LiteLLM은 API 호환 엔드포인트를 통해 모델 라우팅, 가상 키 발행, 사용량 텔레메트리를 제공하는 오픈 소스 AI 게이트웨이로 작동하며, 고객은 이를 자체 AWS 계정 내부에서 직접 운영한다. 전체 요청 흐름은 개발자 워크스테이션에서 시작해 ALB, ECS(LiteLLM), Amazon Bedrock으로 이어지는 5단계 경로를 통해 단일 모델 턴(Turn)을 처리한다.

이 아키텍처에서 LiteLLM은 모델 인증과 게이트웨이 텔레메트리를 담당하는 공유 제어 지점이 되며, Codex는 로컬 도구 실행 루프의 책임만 보유한다. 본 구조는 AWS us-east-1(미국 동부 버지니아) 리전에서 검증되었으며, 게이트웨이 별칭 `openai.gpt-5.5`를 `bedrock_mantle/openai.gpt-5.5` 모델에 매핑하여 동작한다. 인프라 구성 요소로는 트래픽 분산을 위한 Application Load Balancer(ALB), 컨테이너 관리를 위한 ECS Fargate, 상태 저장을 위한 Amazon RDS, 비정상 요청 차단을 위한 AWS WAF가 포함된다. 이러한 계층적 구조는 게이트웨이가 AWS 계정 내에서 일반 목적의 셸 권한을 갖지 않도록 제한하면서도, 각 모델 호출 단계마다 정밀한 거버넌스를 적용할 수 있게 한다.

LiteLLM 게이트웨이 배포 프로세스와 실행 명령어

운영자는 저장소 복제, 이미지 빌드, 스택 배포의 순차적 단계를 통해 LiteLLM 인프라를 구축한다. 먼저 `guidance-codex` 저장소를 복제하고 AWS 프로필, 리전, 소스 CIDR, DNS 설정값이 포함된 `.env.deploy` 파일을 생성한다. 이후 헬퍼 도구를 사용하여 다이제스트(Digest)로 버전이 고정된 LiteLLM 베이스 이미지를 빌드하고 Amazon ECR에 푸시한다. 이 과정에서 `docker buildx build --push` 명령어를 사용하며, 빌드 결과로 생성된 불변의 ECR 다이제스트를 로컬 상태 파일에 기록하여 배포의 일관성을 확보한다.

인프라 배포는 AWS CloudFormation을 통해 수행하며, 실행 전 변경 사항을 검토하기 위해 `--no-execute-changeset` 옵션을 사용한다.

bash

1. 저장소 복제

git clone guidance-codex

2. 이미지 빌드 및 ECR 푸시

docker buildx build --push

3. CloudFormation 변경 세트 생성 및 검토

aws cloudformation deploy --no-execute-changeset

배포 완료 후 ECS 서비스에는 배포 서킷 브레이커 롤백과 ALB 상태 확인 기능이 적용되며, 타겟 추적 오토스케일링을 통해 트래픽 변동에 대응한다. 또한 암호화된 로그와 데이터, RDS 백업, ALB 액세스 로그 및 운영 알람을 설정하여 엔터프라이즈 수준의 가용성을 확보한다. 모든 배포 과정은 `cfn-lint`를 통한 구문 검증과 AWS CLI v2 기반의 프리플라이트(Preflight) 체크를 거쳐 리전 일관성과 CIDR 제한 사항을 사전에 확인한다.

직접 접근 방식과 게이트웨이 방식의 선택 기준 및 트레이드오프

시스템 설계자는 네이티브 AWS ID, IAM 정책, AWS CloudTrail 로그만으로 요구사항을 충족할 수 있는 경우 Amazon Bedrock에 직접 접근하는 최저 복잡도 옵션을 선택한다. 직접 접근 방식은 중간 계층이 없어 지연 시간이 짧고 관리 포인트가 적다는 장점이 있다. 반면, 개발자나 팀 단위로 일관된 제어권이 필요하거나 여러 모델 제공자를 통합 관리해야 하는 경우에는 LiteLLM 게이트웨이 방식이 적합하다. 특히 가상 키를 통해 실제 AWS 루트 키를 은닉하고, 팀별 쿼터 독점을 방지하기 위한 세부 예산 및 속도 제한이 필요할 때 게이트웨이의 효용이 극대화된다.

다만 게이트웨이 도입 시 운영 팀은 인프라 관리 책임이라는 트레이드오프를 감수해야 한다. 운영 팀은 게이트웨이의 가용성 유지, 데이터베이스 생명주기 관리, 버전 업그레이드, 장애 대응 및 용량 계획(Capacity Planning)을 직접 수행해야 한다. 이는 단순 API 호출 권한 부여를 넘어 서버리스 또는 컨테이너 인프라의 운영 오버헤드를 수반함을 의미한다. 따라서 인프라 복잡도를 최소화해 빠른 배포를 우선할 것인지, 아니면 운영 비용을 지불하고 정밀한 중앙 제어권을 확보할 것인지가 선택의 핵심 기준이 된다.

엔터프라이즈 거버넌스를 위한 보안 설정 및 사용자 구성

관리자는 LiteLLM `/key/generate` API를 호출하여 특정 모델, 예산, 속도 정책이 결합된 가상 키를 발행하고 이를 KMS로 암호화하여 AWS Secrets Manager에 저장한다. 마스터 키는 관리자 권한의 헬퍼 프로세스 내부에서만 처리되어 터미널 로그에 노출되지 않으며, 각 개발자 프로필은 IAM 정책을 통해 자신에게 할당된 scoped-key 시크릿만 읽고 복호화할 수 있도록 제한된다. 네트워크 보안을 위해 ALB 접근 범위를 기업 VPN CIDR로 제한하고, ECS 태스크와 Amazon RDS를 프라이빗 서브넷에 배치하여 외부 노출 지점을 최소화한다.

개발자는 배포 후 제공된 엔드포인트와 가상 키를 사용자 레벨의 설정 파일인 `~/.codex/config.toml`에 추가하여 게이트웨이에 연결한다. 설정 파일에는 다음과 같은 프로바이더 블록이 포함되어야 한다.

toml

[providers.litellm]
endpoint = "https://<your-gateway-endpoint>"
api_key = "<your-virtual-key>"

이러한 별칭(Alias) 구조를 적용하면 인프라 관리자가 백엔드에서 모델 버전을 변경하더라도 개발자는 설정 파일을 수정할 필요 없이 동일한 별칭으로 최신 모델을 사용할 수 있다. 결과적으로 이 아키텍처는 모델 식별자를 은닉하여 인프라 변경 사항이 개발 환경에 직접 전달되는 경로를 차단하고, 중앙 집중식 거버넌스를 통해 엔터프라이즈 AI 도입의 안정성을 확보하는 최적의 경로를 제공한다. 상세한 구현 방법은 guidance-codex 저장소에서 확인할 수 있다.