단일 LLM Gateway 아키텍처 : Claude Code와 Codex를 Amazon Bedrock을 통해 한 곳에서

Claude Code와 Codex를 비롯한 AI 코딩 에이전트는 이미 엔터프라이즈 개발 조직의 일상적인 생산성 도구로 자리잡았습니다. 도구가 빠르게 발전하는 만큼 개발자들은 더 나은 모델과 기능을 따라 다양한 도구를 적극적으로 사용하고 있습니다.

이제 조직의 고민은 “도입할 것인가”가 아니라 “어떻게 운영할 것인가”입니다. AI 코딩 에이전트는 소스 코드와 작업 컨텍스트를 LLM에 전달하고, 그 비용은 사용량에 비례해 발생하며, 어떤 데이터가 모델로 전달되는지에 따라 보안 리스크가 달라집니다. 따라서 개발자에게 도구를 제공하는 것만으로는 충분하지 않으며, 비용과 보안, 관측을 함께 다루는 운영 체계가 뒷받침되어야 합니다.

이 블로그에서는 개발자에게는 도구 선택의 자유를 주면서 조직에는 일관된 거버넌스를 제공하는 아키텍처를 살펴봅니다.

1. 단일 구성이 필요한 이유

엔터프라이즈 환경에서 Claude Code와 Codex 같은 AI 코딩 에이전트를 본격적으로 도입하면, 가장 먼저 부딪히는 질문은 “어떤 도구를 표준으로 삼을 것인가”입니다. 조직 입장에서는 도구를 하나로 표준화하고 싶은 이유가 분명합니다. 구매와 정산을 단일 계약으로 처리해 비용 관리를 단순화하고, 벤더 보안 검토와 규제·감사 대응을 한 번만 수행하며, 라이선스관리와 사내 교육·온보딩·헬프데스크 지원을 하나의 도구에 집중할 수 있기 때문입니다.

그러나 개발 현장의 상황은 다릅니다. 개발자마다 선호하는 도구가 다르고, 같은 개발자라도 신규 기능 구현, 디버깅, 문서화 등 작업의 성격에 따라 다른 도구를 사용하려 합니다. 때로는 Codex나 Claude Code가 아닌 또 다른 도구를 쓰고 싶어 하기도 합니다. AI 코딩 에이전트에 대한 선호도는 빠르게 변화 할 수 있어 개발 도구 선택 자유도는 더욱 중요합니다.

그래서더 중요한 질문은 “어떤 도구를 표준으로 삼을 것인가”가 아니라 “서로 다른 도구를 어떻게 하나의 일관된 운영 체계 안에서 관리할 것인가”입니다. 개발자에게는 도구를 자유롭게 선택할 수 있게 하고, 조직은 그 선택과 무관하게 거버넌스를 일관되게 유지하는 것, 단일 LLM Gateway 아키텍처는 바로 이 두 가지를 동시에 달성하기 위한 구성입니다.

1.1. 개발자 선호도 차이

AI 코딩 에이전트는 하나로 수렴하지 않습니다. 같은 조직 안에서도 개발자마다, 또 작업의 성격에 따라 선호하는 도구가 다릅니다.

어떤 개발자는 깊은 추론(Deep Reasoning)과 대규모 리팩토링에 강한 Claude 계열 모델 기반의 Claude Code를 선호합니다.
어떤 개발자는 빠른 코드 생성과 익숙한 워크플로우를 이유로 GPT 계열 모델 기반의 Codex를 선호합니다.
같은 개발자라도 신규 기능 구현, 디버깅, 문서화 등 작업의 성격에 따라 도구를 바꿔 쓰기도 합니다.

이러한 다양성은 억제해야 할 문제가 아니라 생산성의 원천입니다. 조직이 하나의 도구만 허용하는 정책으로 다양성을 막으면 개발 생산성이 떨어질 수 있습니다. 따라서 도구 선택은 개발자에게 맡기는 것이 바람직합니다. 다만 그 자유가 조직의 통제 불능으로 이어지지 않으려면, 도구 선택과 별개로 작동하는 거버넌스 장치가 필요합니다.

1.2. 거버넌스 일원화

개발자에게 도구 선택의 자유를 허용하면, 조직은 그만큼 다섯 가지 영역에서 통제력을 확보해야 합니다.

사용성 : 도구가 여러 개여도 인증과 접속 경로는 하나로 유지되어야 하며, 새로운 도구가 추가되더라도 개발자 온보딩 방식이 달라지지 않아야 합니다.
예산 : 어떤 개발자가 Claude Code나 Codex로 얼마를 사용했는지 일관되게 집계하고, 예산 한도를 초과하면 실시간으로 차단할 수 있어야 합니다.
MCP : 개발자가 연결하는 MCP(Model Context Protocol) 서버와 그 자격증명, 접근 권한을 조직이 중앙에서 관리할 수 있어야 합니다.
보안 : 하드코딩된 자격증명 입력, 고객 개인정보(PII) 입력, 프롬프트 인젝션(Prompt Injection)을 도구와 무관하게 동일한 정책으로 차단할 수 있어야 합니다.
Observability : 호출 로그와 토큰 사용량, 입출력 응답을 도구·모델·사용자와 무관하게 일관된 방식으로 수집하고 추적할 수 있어야 합니다.

이 다섯 가지를 도구마다 따로 구현하면, 관리해야 할 항목은 도구 수에 비례해 늘어나는 것이 아니라 항목과 도구의 조합만큼 늘어납니다. 도구가 추가될 때마다 인증, 예산, 보안, 관측 정책을 처음부터 다시 적용해야 한다면, 조직은 결국 도구를 제한하는 방향으로 돌아가게 됩니다. 단일 LLM Gateway는 모든 도구의 요청이 거쳐가는 단일 진입점(Single Entry Point)에 이 다섯 가지 거버넌스를 한 번만 구현합니다. 이렇게 하면 도구의 개수와 무관하게 하나의 지점에서 누가, 얼마나, 어떤 데이터를, 어떻게 사용하는지를 일관되게 통제할 수 있습니다.

1.3. Bedrock-Runtime과 Bedrock-Mantle의 차이

AWS에서는 Agent 기반의 LLM 사용패턴과 더 다양한 LLM 모델의 추론 성능을 향상시키기 위해 Bedrock-Mantle이라는 새로운 추론 엔드포인트를 출시했습니다. Bedrock-Mantle 엔드포인트는 OpenAI 호환 API를 지원하며 비동기 및 Stateful 호출을 지원합니다. 이로 인해 단일 게이트웨이가 필요한 또 하나의 이유는, Claude 모델과 GPT 모델이 Amazon Bedrock 내에서 서로 다른 호출 경로를 사용하기 때문입니다. 블로그를 작성하는 시점 기준으로 두 경로는 다음과 같은 차이가 있습니다.

Bedrock-Runtime (Claude 계열)
- 기존 Amazon Bedrock의 표준 호출 경로로, Claude Code는 Invoke API를 통해 호출합니다.
- 인증은 게이트웨이(LiteLLM)에 부여된 IAM Role 정책을 기반으로 수행됩니다.
- 서울 리전(ap-northeast-2)에서 직접 사용하거나 Global CRIS(Cross-Region Inference)를 통해 호출할 수 있습니다.
- CloudTrail 호출 기록, Invocation Logging 기반 프롬프트 로깅 등 관측(Observability) 기능이 기본적으로 지원됩니다.
Bedrock-Mantle (Claude 계열 및 GPT 계열)
- 최신 모델을 호출하기 위한 엔드포인트로, Codex는 OpenAI 호환의 Response API를 통해 호출합니다.
- 인증은 Amazon Bedrock을 통해 발급한 API Key를 기반으로 수행됩니다.
- CloudTrail 자동 기록, Application Inference Profile, Invocation Logging 기반 프롬프트 로깅 등 일부 관측 기능이 아직 동일하게 지원되지 않습니다.

이처럼 두 경로는 API 형태, 인증 방식, 지원 리전, 기능까지 차이가 있습니다. 이 차이를 개발자나 도구가 직접 흡수해야 한다면 클라이언트 설정과 네트워크 구성, 로깅 전략이 모델마다 갈라지게 됩니다. 단일 LLM Gateway는 이러한 차이를 게이트웨이 내부에서 흡수하여, 개발자에게는 하나의 인증 방식과 하나의 엔드포인트만 노출합니다. 리전 차이는 게이트웨이의 네트워크 구성(VPC Peering, Private DNS)으로, 관측 기능의 차이는 게이트웨이 단의 통합 로깅으로 보완합니다.

2. Claude Code/Codex – 단일 LLM Gateway 아키텍처

Claude Code와 Codex을 Amazon Bedrock을 사용하는 구조에서 통합된 사용 환경을 구성하기 위해 LLM Gateway을 사용합니다. LLM Gateway란 여러 LLM 서비스를 단일 API로 통합하여 인증, 라우팅, 로깅, 비용 관리, 속도 제한 등을 중앙에서 처리하는 Proxy 구조의 서비스입니다.

아키텍처 소개

2.1. LLM Gateway

이번 블로그에서 사용한 LLM Gateway는 오픈소스에서 대표적으로 많이 사용하는 LiteLLM을 사용했습니다. LiteLLM을 고객의 서울 리전 Private Subnet에 EC2 기반으로 설치하며, LiteLLM에서 저장되는 로그 및 메트릭들을 Amazon RDS for PostgreSQL에 저장합니다.

LiteLLM – Config.yaml 구성 예시

model_list:
    - model_name: bedrock-claude-4-8-opus
      litellm_params:
        model: bedrock/global.anthropic.claude-opus-4-8
        aws_region_name: ap-northeast-2

    - model_name: bedrock-gpt-5-5
      litellm_params:
        model: bedrock_mantle/openai.gpt-5.5
        api_key: [Bedrock API Key]
        api_base: [Bedrock-Mantle Endpoint] # ex: https://vpce-...bedrock-mantle.us-east-1.vpce.amazonaws.com/openai/v1
 
 general_settings: 
  master_key: [사용할 Master Key]
  database_url: [Amazon RDS Postres 주소]
  store_model_in_db: true # 프롬프트 로깅을 위한 설정
  store_prompts_in_spend_logs: true # 프롬프트 로깅을 위한 설정

2.2. 네트워크 구성

1. 1. 서울 리전과 버지니아 리전의 VPC 사용 : 블로그를 작성하는 시점에서는 Claude 모델은 Bedrock-Runtime을 통해 Global CRIS 모델을 통해 서울리전에서 사용이 가능합니다. 그러나 최신 GPT 모델은 Bedrock-Mantle 엔드포인트를 통해 호출이 가능하며 블로그를 작성하는 시점에서 us-east-1, us-east-2, us-west-2리전에서 호출이 가능합니다.
  2. 완전한 Private Network 구성 : 개발자들의 로컬 환경(오피스)와 AWS 환경과는 Direct Connect 또는 Site-to-Site VPN을 통해 사설 네트워크를 구축합니다. 이를 통해 Claude Code 및 Codex의 사용 환경을 퍼블릭 네트워크를 경유하지 않는 Private Network로 구성 할 수 있습니다.

2.3. 각 모델 별 호출

1. Claude Code : Claude Code에서 Amazon Bedrock 호출시 Invoke API을 사용하며, Bedrock 호출 시 인증은 LiteLLM에 부여된 IAM Role의 정책을 기반으로 인증합니다.
2. Codex : Codex에서 Amazon Bedrock 호출 시 Response API을 사용하며, Amazon Bedrock을 통해 발급한 API Key을 기반으로 호출합니다.
3. 지원 리전의 차이 : Claude 모델은 서울 리전(ap-northeast-2) 직접 사용 및 Cross-Region Inference가 가능하지만, GPT 모델은 블로그를 작성하는 시점에서 US 리전 (us-east-1, us-east-2, us-west-2)에서만 사용 가능합니다.

3. 각 항목 별 통합 방안

3.1 . 사용성의 통합

Amazon Bedrock 기반의 단일 LLM Gateway을 구성함으로써 개발자는 개인 선호에 따른 Claude Code 및 Codex을 선택하여 사용 할 수 있습니다. 또한 Claude Code 및 Codex 사용시 각기 다른 인증 및 엔드포인트가 아닌, 단일 인증 방식 및 동일한 엔드포인트를 통해 Claude Code와 Codex을 사용 할 수 있습니다.

단일 인증 방식 : LLM Gateway을 사용하게 될 경우 사용자는 LLM Gateway에서 발급 받은 API Key을 통해 Amazon Bedrock 기반의 LLM을 호출 할 수 있습니다. 사용자의 호출을 전달받은 LLM Gateway는 사용자를 대신하여 Amazon Bedrock을 호출하게 되며 부여된 IAM Role 또는 API Key을 기반으로 인증을 수행하게 됩니다. 만약 사내 SSO 시스템과의 연동이 필요 할 경우 API Key HelperScript를 사용하여 키 인증 방식을 변경 할 수 있습니다.
단일 엔드 포인트 : LLM Gateway을 Proxy로 두어 Claude Code 및 Codex 사용 시, 모두 LLM Gateway을 단일 엔드포인트로 사용하게 됩니다. 이를 통해 개발자는 각기 다른 엔드포인트가 아닌 LLM Gateway 엔드포인트 만을 사용하여 Claude Code 및 Codex을 사용 할 수 있으며, 관리자 입장에서도 사용 툴에 대한 관리성을 높일 수 있습니다.

개발자 로컬에서의 환경 구성

Claude Code – ~/.claude/settings.json

{
    "env": {
      "ANTHROPIC_AUTH_TOKEN": "[LLMGW API Key]",
      "CLAUDE_CODE_USE_BEDROCK": "1",
      "CLAUDE_CODE_SKIP_BEDROCK_AUTH": "1",
      "ANTHROPIC_BEDROCK_BASE_URL": "https://[LLM GW Endpoint]:4000/bedrock"
    },
    "availableModels": ["opus"],
    "modelOverrides": {
      "claude-opus-4-8": "bedrock-claude-4-8-opus"
    }
  }

Codex – ~/.codex/config.toml

# 셸 환경변수 (~/.zshrc 또는 ~/.bashrc)
export LITELLM_API_KEY=[LLMGW API Key]

# ~/.codex/config.toml

model = "bedrock-gpt-5-5"
model_provider = "litellm"

[model_providers.litellm]
name = "LiteLLM Proxy"
base_url = "https://[LLM GW Endpoint]:4000/v1"
env_key = "LITELLM_API_KEY"
wire_api = "responses"

3.2. 예산 관리의 통합

LLM Gateway를 도입했을 때 가장 큰 운영상의 이점 중 하나는 _비용 가시성과 토큰 사용에 대한 실시간 통제_입니다.

Amazon Bedrock을 직접 호출하는 구조에서는 “어떤 개발자가 Claude Code로 얼마를 사용했는지”, “Codex 사용량은 얼마인지”를 구분하기 위해 별도의 태깅 전략이나 로그 파이프라인을 구축해야 합니다. 반면 LLM Gateway를 도입하면 이러한 비용 추적과 예산 통제를 중앙에서 일관되게 수행할 수 있으며, 각 개발자에게 부여된 예산 한도 내에서 Claude Code와 Codex를 자유롭게 사용할 수 있는 환경을 제공할 수 있습니다.

LLM Gateway에서는 개발자별로 발급된 API Key 단위로 예산을 설정할 수 있으며, 부여된 예산을 초과할 경우 Claude Code와 Codex의 호출을 실시간으로 차단합니다. 이를 통해 관리자는 예산 초과로 인한 비용 리스크를 사전에 방지할 수 있고, 개발자는 자신의 사용량을 인지하며 책임감 있게 도구를 활용할 수 있습니다.

LLM Gateway에서 각 개발자에게 부여된 API Key을 기준으로 전체 예산을 설정 할 수 있습니다. 개발자가 부여된 예산을 초과해서 사용 할 경우 Claude Code 또는 Codex에 대한 사용을 실시간으로 제어 할 수 있습니다.

Claude Code에서의 비용 초과로 인한 실시간 통제

Codex에서의 비용 초과로 인한 실시간 통제

3.3. MCP 통합

MCP(Model Context Protocol)는 AI 코딩 에이전트가 외부 도구 및 데이터 소스에 접근할 수 있도록 하는 프로토콜입니다. 개발자는 MCP 서버를 통해 Claude Code 및 Codex에서 GitHub, Jira, 사내 데이터베이스, 내부 API 등 다양한 시스템에 직접 접근하여 작업할 수 있습니다. MCP는 AI 코딩 에이전트의 실질적인 생산성을 결정짓는 핵심 요소이지만, 조직 차원에서 관리되지 않으면 자격증명 분산, 비인가 접근, 감사 불가라는 세 가지 리스크를 동시에 발생시킵니다. 단일 LLM Gateway을 구성함으로써 MCP에 대한 관리를 두가지 차원에서 통합 할 수 있습니다. LiteLLM에 대한 MCP 상세 설정은 공식 문서에서 확인 할 수 있습니다.

1) 조직 관리형 MCP 서버의 중앙 배포

조직이 승인한 MCP 서버에 대한 자격증명은 단일 LLM Gateway에서 중앙 관리합니다. 이를 통해 개발자는 MCP 서버의 자격증명을 직접 보유하지 않으며, LLM Gateway에서 발급받은 API Key 하나로 모든 MCP 서버에 인증합니다. 만약 사용자가 사용하는 API KEY에 MCP에 대한 사용이 승인되지 않았다면, 아래와 같이 MCP 사용 인증에 실패하며 각 사용자 별 MCP 사용에 대한 권한 제어를 할 수 있습니다.

2) MCP 도구 호출의 관측과 통제

MCP 도구 호출은 LLM 요청의 일부(tool_use, tool_result)로 포함되어 LLM Gateway를 통과합니다. 따라서 별도의 로깅 파이프라인 없이도 누가 어떤 MCP 도구를 호출했는지, 그 입출력이 무엇인지를 LLM Gateway 로그에서 통합 추적할 수 있습니다.

3.4. 보안을 위한 Guardrails 통합

Claude Code와 Codex 같은 AI 코딩 도구는 개발자가 작업 중인 소스 코드, 로그, 환경 변수, 데이터베이스 스키마 등 민감한 컨텍스트를 LLM에 전달합니다. 이 과정에서 의도치 않게 하드코딩된 자격증명, 고객 개인정보(PII), 사내 보안 정책상 외부 반출이 금지된 코드가 모델로 전송될 수 있으며, 악의적인 프롬프트 인젝션(Prompt Injection) 시도가 발생할 수도 있습니다.

LLM Gateway는 Claude Code와 Codex의 모든 요청과 응답이 거쳐가는 단일 진입점입니다. 이 위치에 Guardrails를 통합하면, 두 도구 모두에 일관된 보안 정책을 적용할 수 있으며, 새로운 AI 코딩 도구가 추가되더라도 동일한 보안 수준을 자동으로 확보할 수 있습니다. LiteLLM은 특정 벤더에 종속되지 않고 다양한 Guardrail Provider를 플러그인 형태로 통합할 수 있도록 설계되어 있고 필요하다면 Custom Guardrail를 통해 회사에 필요한 필터를 추가할 수 있습니다.

아래는 LiteLLM에서 기본적으로 제공하는 LiteLLM Content Filter을 통한 Guardrails을 적용한 예시입니다. AWS Access Key와 AWS Secret Key에 대한 사용을 사전에 차단하는 Guardrails 구성입니다.

실제 Claude Code 및 Codex의 프롬프트에 AWS Access Key와 AWS Secret Key가 포함 될 시 자동으로 LLM Gateway 단에서 차단 할 수 있습니다.

3.5. Observability의 통합

LLM 기반 서비스를 운영할 때 가장 어려운 부분 중 하나는 “무슨 일이 일어났는지 추적하는 것” 입니다. 일반적인 API 호출과 달리 LLM 호출은 입력 프롬프트, 출력 응답, 사용된 토큰 수, 모델별 응답 시간, 캐싱 여부 등 추적해야 할 정보가 다양하며, 동일한 입력에도 결과가 달라질 수 있어 디버깅이 까다롭습니다. 또한 Claude Code와 Codex처럼 도구가 다양해질수록 호출 패턴과 사용량을 일관된 관점에서 관찰하기가 점점 어려워집니다. 또한 블로그를 작성하는 시점의 Bedrock-Runtime과 Bedrock-Mantle 간 AWS 상에서의 Observability 간 차이가 존재합니다.

호출 기록에 대한 차이
- Claude(Bedrock-runtime) 모델을 호출 시 CloudTrails에 자동으로 호출에 대한 정보가 기록되지만, GPT(Bedrock-Mantle)에 대한 호출은 CloudTrails에 자동으로 호출 정보가 기록되지 않습니다. Mantle 엔드포인트에 대한 호출 기록을 저장하기 위해서는 별도의 Data Type 기반의 Trails을 생성하여 CloudWatch에서의 확인이 가능합니다.
프롬프트 로깅 기록에 대한 차이
- Claude(Bedrock-runtime)에 대한 프롬프트 로깅은 Bedrock에서 Invocation Logging을 활성화하면 CloudWatch에서 사용자들의 프롬프트를 기록 할 수 있습니다. 그러나 현재 Mantle에 대한 Invocation Logging은 현재 지원하지 않습니다.

LLM Gateway는 모든 호출이 통과하는 단일 진입점으로 각 엔드포인트마다 별도의 로깅 시스템을 구축하지 않고 하나의 LLM Gateway에서 통합 할 수 있습니다. 또한 Claude 및 GPT 모델에 대한 호출 기록을 AWS 상에 자세히 기록하기 위해서는 별도의 CloudWatch 비용이 발생하는 사항을 로깅 및 메트릭을 별도의 Postgres 데이터베이스에 저장하여 CloudWatch에 대한 추가 비용 없이 로깅 및 메트릭 정보들을 기록 할 수 있습니다. LiteLLM에서는 기본적으로 Request 및 Reponse에 대한 기록은 기본으로 비활성화 되어있습니다. 이를 활성화 하기 위해서는 아래와 같이 Config에 설정을 통해 활성화 할 수 있습니다.

# config.yaml

general_settings:
  store_model_in_db: true # 프롬프트 로깅을 위한 설정
  store_prompts_in_spend_logs: true # 프롬프트 로깅을 위한 설정

4. 결론

엔터프라이즈 환경에서 Claude Code와 Codex 같은 AI 코딩 도구를 도입하려면 단순히 모델에 접근할 수 있는 것 이상의 고민이 필요합니다. 누가 사용하는지, 얼마나 사용하는지, 어떤 데이터가 모델로 흘러가는지, 장애나 보안 사고가 발생했을 때 어떻게 추적할 것인지 — 이러한 운영 요건은 도구가 늘어날수록 기하급수적으로 복잡해집니다.

본 블로그에서는 단일 LLM Gateway를 배치하여 Claude Code와 Codex를 하나의 일관된 환경으로 통합하는 아키텍처를 살펴보았습니다. LLM Gateway라는 단일 진입점을 둠으로써 사용성, 예산 관리, MCP 통합, 보안 Guardrails, Observability에 대한 통합을 효과를 얻을 수 있습니다. 이 포스팅에서 살펴본 단일 LLM Gateway을 둠으로써 Claude Code와 Codex을 Amazon Bedrock을 사용하는 핵심 이점을 정리하면,

1. 사용성 : 단일 인증과 단일 엔드포인트로 Claude Code와 Codex를 일관되게 사용할 수 있습니다.
2. 예산 관리 : 단일 API Key 단위로 두 도구의 예산을 통합하고 초과 시 호출을 실시간 차단합니다.
3. MCP 통합 : MCP 서버의 자격증명을 중앙에서 관리하고 사용 권한과 호출 내역을 통합 추적합니다.
4. 보안 Guardrails : 단일 진입점에서 PII·자격증명·프롬프트 인젝션을 동일한 정책으로 차단합니다.
5. Observability 통합 : Bedrock-Runtime과 Mantle의 로깅 차이를 게이트웨이에서 흡수해 호출 기록을 한곳에 수집합니다.

이러한 통합은 단순히 “편의성”의 문제가 아니라, AI 코딩 도구를 조직 차원에서 안전하고 지속 가능하게 운영하기 위한 거버넌스 인프라입니다. LLM Gateway를 한 번 구축해두면, 앞으로 등장할 새로운 AI 코딩 도구나 모델이 추가되더라도 동일한 인증·예산·보안·관측 정책을 즉시 확장 적용할 수 있습니다. 즉, “도구마다 따로 운영하는 구조” 에서 “플랫폼 위에서 도구를 선택하는 구조” 로 패러다임을 전환할 수 있는 기반이 됩니다.

AWS 기술 블로그