DIY AI 게이트웨이: 아키텍처, 검증된 도구, 그리고 GxP 규정 준수를 위해 필요한 것들

OpenAI, Anthropic, Google, 로컬 모델 등 여러 LLM 제공업체(Provider)를 동시에 운영하고 있다면 이미 그 고통을 잘 알고 계실 것입니다. 여러 마이크로서비스에 흩어져 있는 API 키, 지출 비용에 대한 통합 뷰의 부재, 특정 제공업체에 장애가 발생하면 애플리케이션 전체가 함께 중단되는 문제, 그리고 규제 대상 환경에 있는 경우 밤잠을 설치게 만드는 컴플라이언스(규제 준수) 공백까지 존재합니다.

해답은 바로 AI 게이트웨이(AI Gateway)입니다. 그리고 이는 직접(DIY) 구축할 수 있습니다.

AI 게이트웨이의 실제 역할

AI 게이트웨이는 애플리케이션과 LLM 제공업체 사이에 위치하는 리버스 프록시(reverse proxy)입니다. Kong, Nginx, Envoy와 같은 전통적인 API 게이트웨이는 일반적인 HTTP 트래픽을 처리하지만, AI 특화 구조체(constructs)—즉 토큰 예산(token budget), 모델 라우팅, 스트리밍 시맨틱, 또는 $0.50짜리 요청과 $5.00짜리 요청 간의 차이점 등을 이해하지 못합니다.

전용 AI 게이트웨이는 단일 표준 엔드포인트(일반적으로 OpenAI의 /v1/chat/completions 스키마를 모방)를 제공하여 이 문제를 해결합니다. 프론트엔드나 자율 에이전트(autonomous agents)는 localhost:4000(또는 내부 URI)을 바라보고, 게이트웨이가 사용자가 구성한 각 제공업체에 맞게 요청을 변환하여 전달합니다.

주요 핵심 기능은 다음과 같습니다:

• 통합 API (Unified API) — 모든 제공업체를 위한 단일 엔드포인트입니다. 애플리케이션은 대상이 Claude인지 GPT-4인지 신경 쓸 필요가 없습니다.
• 지능형 라우팅 (Intelligent Routing) — 모델 이름, 비용, 지연 시간(latency), 가용성을 기반으로 적절한 제공업체에 요청을 전송합니다.
• 장애 조치 및 재시도 (Failover and Retry) — OpenAI가 429(Rate Limit)나 500 오류를 반환하면, 게이트웨이가 처리 도중 자동으로 백업 제공업체로 경로를 재설정합니다.
• 속도 제한 (Rate Limiting) — 비용 급증을 방지하기 위한 클라이언트별, 키별 쓰로틀링(throttling)을 지원합니다.
• 중앙 집중식 키 관리 (Centralized Key Management) — 애플리케이션은 게이트웨이에 대해서만 인증합니다. 게이트웨이가 제공업체 키를 안전하게 보관하며, 클라이언트는 이를 절대 직접 보지 못합니다.
• 캐싱 (Caching) — 중복 요청에 대한 비용 낭비를 방지하는 완전 일치(exact-match) 또는 시맨틱(semantic) 캐싱을 제공합니다.
• 비용 추적 (Cost Tracking) — 프로젝트별, 클라이언트별, 모델별 토큰 수 집계 및 지출 모니터링을 수행합니다.
• 감사 로깅 (Audit Logging) — 모든 요청, 응답, 토큰 수, 지연 시간 지표를 한곳에 기록합니다.

아키텍처 구성은 다음과 같습니다:

Your App(s)
    │
    ▼
┌─────────────────────────────────┐
│         AI Gateway              │
│                                 │
│  Auth → Route → Cache → Proxy   │
│    │              │        │    │
│    ▼              ▼        ▼    │
│  Rate Limit   Logging   Failover│
└─────────────────────────────────┘
    │         │         │
    ▼         ▼         ▼
  OpenAI  Anthropic  Ollama (local)

DIY(자체 구축)를 위한 두 가지 경로

경로 1: 자체 호스팅 오픈소스 (대부분의 팀에 권장)

AI 게이트웨이를 직접 구축해 본 팀들이 전하는 가장 중요한 교훈은 변환 계층(translation layer)을 처음부터 직접 만들지 말라는 것입니다. 문제는 유지보수입니다. 제공업체들은 API를 끊임없이 변경합니다(새로운 구조화된 출력 포맷, 스트리밍 사양 변경, 도구 호출(tool calling) 업데이트 등). 50개 이상의 제공업체에 대한 변환 코드를 유지 관리하는 것은 전담 인력이 필요한 작업입니다.

더 나은 접근 방식은 검증된 오픈소스 프록시를 배포하고, 그 위에 조직 자체의 컴플라이언스 미들웨어를 구축하는 것입니다.

이 분야의 독보적인 선두 주자는 LiteLLM입니다. LiteLLM은 100개 이상의 LLM API를 OpenAI 표준 포맷으로 변환해 주는 Python 기반 프록시입니다. YAML 파일로 설정하고 서버 형태로 배포하기만 하면, 라우팅, 로드 밸런싱, 폴백(fallback), 지출 추적 등을 기본적으로 처리해 줍니다.

# litellm_config.yaml
model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: sk-your-key
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: sk-ant-your-key

router_settings:
  routing_strategy: least-busy
  num_retries: 2
  fallbacks:
    - gpt-4o: [claude-sonnet]

실행 명령어는 litellm --config litellm_config.yaml --port 4000 단 하나입니다. 애플리케이션의 엔드포인트를 http://localhost:4000/v1/chat/completions로 설정하면 모든 기능이 즉시 정상 작동합니다.

Portkey Gateway 또한 훌륭한 대안입니다. 핵심 코어가 매우 가볍고(~45KB), TypeScript 기반이며, 250개 이상의 모델을 지원하고 npx @portkey-ai/gateway 명령어로 간편하게 실행할 수 있습니다.

API 인프라로 이미 Kong을 사용 중이라면 Kong with AI Plugins가 유용합니다. Gateway 3.12(2025년 10월) 버전부터 Kong은 AI 트래픽을 위한 네이티브 MCP 프록시 지원, OIDC 인증, 속도 제한 기능을 기본 탑재하고 있습니다.

경로 2: 직접 구현 (최대 수준의 통제력)

도구 호출(tool-calling) 루프 인터셉트, 에이전트 제약 조건 강제, 맞춤형 토큰 압축 파이프라인 통합 등 고도로 특화된 동작이 필요하다면 자체 커스텀 프록시를 구축해야 합니다.

권장 기술 스택은 다음과 같습니다:

최소 기능 제품(MVP) 수준의 게이트웨이는 모델-제공업체 매핑을 수행하는 포워딩 프록시 형태로 약 100줄 내외로 작성할 수 있습니다. 하지만 멀티 제공업체 스트리밍, 정교한 에러 복구, 응답 캐싱, 감사 로깅까지 모두 처리하는 프로덕션 레벨의 게이트웨이는 현실적으로 500~2,000줄 규모가 필요합니다.

기능별 구현 난이도 매트릭스는 다음과 같습니다:

가장 까다로운 난제: 스트리밍

AI 게이트웨이를 직접 구축하는 모든 팀은 동일한 장벽에 부딪히게 됩니다. 바로 SSE(Server-Sent Events) 스트리밍 처리입니다.

문제는 제공업체마다 스트리밍 이벤트 포맷이 제각각이라는 점입니다. 게이트웨이는 전체 응답을 버퍼링하지 않고 실시간으로 토큰을 파이프 통과시켜야 합니다. 그래야만 사용자가 토큰이 하나씩 생성되는 화면을 지연 없이 볼 수 있습니다. 하지만 GxP 환경처럼 감사 추적(audit trail)을 위해 전체 응답을 반드시 기록해야 하는 경우, 각 청크(chunk)를 클라이언트에 전달하는 동시에 백그라운드에서 하나의 완성된 응답으로 합쳐야 합니다.

바로 이 지점에서 단순한 프록시 아키텍처가 무너집니다. 전체 응답을 버퍼링한 뒤 전달하는 순진한 방식은 실시간 사용자 경험(UX)을 완전히 망가뜨립니다. 반대로 무조건 전달만 하는 단순 포워딩 방식은 감사 로그를 남길 수 없게 만듭니다. 올바른 구현 방식은 TransformStream이나 이에 상응하는 메커니즘을 사용하여, 각 청크를 클라이언트에 즉시 전달하면서 동시에 로깅용 버퍼로 복사하는 것입니다.

바닥부터 직접 구현(from scratch)을 계획하고 있다면, 전체 엔지니어링 시간의 30~40%를 오직 이 스트리밍 문제 해결에 할당해야 합니다.

규제 대상 환경이 의미하는 바

생명과학, 제약, 또는 기타 GxP 규제를 받는 환경의 팀에게 AI 게이트웨이는 선택 사항인 인프라가 아닙니다. 책임감 있고 안전하게 AI를 배포할 수 있는 유일한 방법입니다.

게이트웨이가 필수 불가결한 이유

GxP 컴플라이언스 스택

규제 대상 환경을 위한 자체 게이트웨이를 구성할 때는 다음 계층들을 순서대로 배치해야 합니다:

1. 인증 (Authentication, OAuth 2.1/OIDC) — 누가 이 요청을 보내고 있는가?
2. 인가 (Authorization, RBAC/FGA) — 해당 사용자가 이 모델을 사용할 권한이 있는가?
3. PII/PHI 마스킹 (Microsoft Presidio) — 민감 데이터가 외부 제공업체로 전달되기 전에 제거/비식별화
4. 프롬프트 인젝션 탐지 (Prompt Injection Detection) — 이 프롬프트가 시스템을 조작하려는 악의적 시도인가?
5. 예산 및 속도 제한 검사 (Budget/Rate Limit Check) — 사용자가 할당된 쿼터를 초과했는가?
6. 캐시 확인 (Cache Check) — 캐시된 데이터로 즉시 응답할 수 있는가?
7. 모델 라우팅 및 장애 조치 (Model Routing + Failover) — 어떤 제공업체가 이 요청을 처리할 것인가?
8. 불변 감사 로그 (Immutable Audit Log, WORM 스토리지, 해시 체인) — 모든 트랜잭션을 위변조 방지 형태로 기록

이것이 바로 “조립형 DIY(Assembled DIY)” 접근 방식입니다. 핵심 프록시로 LiteLLM을 배포하고, 그 앞단에 FastAPI 기반의 컴플라이언스 미들웨어를 구축하면, 50개 이상의 제공업체 API 변환 코드를 직접 유지 관리하지 않고도 거버넌스에 대한 100%의 통제권을 확보할 수 있습니다.

GxP를 위한 권장 기술 스택

게이트웨이가 해결할 수 없는 영역

규제 대상 환경의 모든 팀이 반드시 인지해야 할 핵심적인 한계점들이 있습니다:

• 게이트웨이는 파이프라인을 보호할 뿐, 모델의 출력 자체를 보증하지는 못합니다. LLM이 환각(hallucination)을 일으키는 경우 게이트웨이가 이를 걸러낼 수는 없습니다. 중요한 의사결정에는 별도의 출력 검증 계층과 인간 참여(Human-in-the-Loop, HITL) 프로세스가 필수적입니다.
• 게이트웨이는 전자서명을 직접 생성할 수 없습니다. 작업 이력을 로깅할 수는 있지만, 법적 효력을 갖는 전자서명은 밸리데이션된 전자서명 시스템과의 연동이 필요합니다.
• 게이트웨이는 비결정론적 모델을 밸리데이션할 수 없습니다. 전통적인 GAMP 5 밸리데이션은 결정론적(deterministic) 시스템을 전제로 합니다. 하지만 LLM은 비결정론적입니다. 따라서 모델과 프롬프트에 대해서는 별도의 컴퓨터 소프트웨어 보증(CSA, Computer Software Assurance) 라이프사이클을 적용해야 합니다.

보안: 절대 타협할 수 없는 필수 수칙

요약 및 결론

자체(DIY) AI 게이트웨이를 구축하는 것은 AI 스택에서 취할 수 있는 가장 실용적인 인프라 투자 중 하나입니다. 아키텍처 패턴은 이미 정립되어 있고, 오픈소스 도구 생태계는 성숙했으며, 나아갈 경로는 명확합니다.

대부분의 일반적인 팀이라면: LiteLLM을 코어 프록시로 배포하고, 그 위에 커스텀 컴플라이언스 미들웨어 계층을 추가한 뒤, 애플리케이션의 엔드포인트를 localhost:4000으로 지정하십시오. 이를 통해 거버넌스, 비용, 데이터 주권을 완벽히 통제할 수 있는 엔터프라이즈급 AI 인프라를 확보할 수 있습니다.

규제 대상 환경이라면: PII 비식별화를 위한 Presidio, 관측성을 위한 Langfuse, 감사 추적을 위한 WORM 스토리지를 추가하십시오. 게이트웨이는 사내 데이터와 외부 세계 사이에서 단일 정책 적용 지점(single enforcement point) 역할을 하며 GxP AI 전략의 든든한 중추가 되어 줄 것입니다.

현실적인 엔지니어링 리소스를 계획하십시오. 기본적인 셋업에는 12주가 소요되며, 규제 준수를 완벽히 갖춘 배포에는 12개월이 필요합니다. 그리고 모든 것을 바닥부터 직접 구현한다면 최소 포워딩 프록시에 회자되는 “100줄”이 아니라, 프로덕션 품질을 갖추기 위해 500~2,000줄의 코드가 필요하다는 점을 명심해야 합니다.

필요한 도구는 이미 준비되어 있습니다. 아키텍처 또한 충분히 검증되었습니다. 이제 남은 질문은 단 하나입니다. 이를 지금 선제적으로 구축할 것인가, 아니면 첫 번째 컴플라이언스 감사(audit)에 떠밀려 뒤늦게 구축할 것인가입니다.

관련 기사

• MCP 게이트웨이 패턴: GxP 컴플라이언스를 위해 팩트 체크된 아키텍처
• 비용 동결과 기하급수적 성장: 생명과학을 위한 규제 준수형 AI 게이트웨이 아키텍처
• 규제 대상 생명과학 분야 AI 에이전트를 위한 참조 아키텍처