AI 애플리케이션이 처음에는 OpenAI API 하나만 호출하더라도 운영 단계에 들어가면 상황이 달라집니다. 부서마다 Anthropic, Gemini, AWS Bedrock, Azure OpenAI와 사내 GPU 모델을 함께 사용하고, 공급자 장애 시 대체 모델로 전환해야 하며, 사용자별 비용과 데이터 반출 정책도 관리해야 합니다.
각 애플리케이션이 이 기능을 직접 구현하면 인증키와 재시도 코드가 서비스마다 흩어지고, 모델을 바꿀 때마다 요청 형식과 오류 처리를 다시 작성하게 됩니다. AI Gateway는 애플리케이션과 여러 모델 제공자 사이에 놓여 모델 호출을 하나의 정책과 관측 지점으로 모으는 중간 계층입니다.
이 글에서는 AI Gateway가 일반 API Gateway와 무엇이 다른지, 내부에서 실제로 어떤 프로토콜과 데이터가 오가는지, LiteLLM·Envoy AI Gateway·Kong·Apache APISIX·Higress·Portkey 중 무엇을 선택해야 하는지 살펴봅니다. 마지막에는 “AI Gateway의 de facto는 누구인가?”라는 질문에도 명확히 답합니다.
결론부터 말하면: 제품 하나가 de facto는 아니다
2026년 8월 기준으로 AI Gateway 전체 시장을 지배하는 단 하나의 공식 표준이나 제품은 없습니다. 대신 계층을 나누면 답이 선명해집니다.
따라서 한 문장으로 정리하면 다음과 같습니다.
인터페이스의 de facto는 OpenAI 호환 API이고, 범용 오픈소스 구현체의 de facto에 가장 가까운 프로젝트는 LiteLLM이다. 다만 Kubernetes 내부 추론 라우팅에서는 Gateway API Inference Extension과 Envoy 계열이 별도의 표준 축을 만든다.
GitHub Star는 설치 대수나 품질을 증명하지 않지만 생태계 관심도를 보는 보조 지표는 됩니다. LiteLLM 공식 저장소는 현재 100개 이상의 LLM API를 OpenAI 또는 Native 형식으로 호출하는 Gateway를 표방하고, 5만 개가 넘는 Star와 활발한 릴리스를 보유합니다. 이런 범용성 때문에 새 AI 플랫폼이 멀티모델 진입점을 만들 때 가장 먼저 검토되는 OSS 중 하나입니다. 다만 이 평가는 “공식 표준”이라는 뜻이 아니라 채택과 호환성에 기반한 실무적 판단입니다.
AI Gateway는 정확히 무엇을 하는가
일반 API Gateway도 TLS 종료, 인증, Rate Limit, 라우팅과 로깅을 수행합니다. AI Gateway는 여기에 모델 호출의 의미를 이해하는 기능을 추가합니다.
model,messages,input,tools,stream같은 LLM 요청 필드 해석- OpenAI 형식을 Anthropic Messages, Gemini, Bedrock 등 공급자별 형식으로 변환
- 모델명, 비용, 지연시간, 장애 상태와 데이터 등급을 이용한 라우팅
- 토큰 단위 사용량, 모델별 단가와 사용자·프로젝트별 예산 집계
- 긴 스트리밍 연결과 공급자별 오류·재시도 처리
- Prompt·Response의 개인정보, 금지 콘텐츠와 Prompt Injection 검사 연계
- 동일·유사 Prompt 캐시와 Semantic Cache
- Tool Call, Embedding, 이미지·음성 등 모델 기능별 정책 적용
그림: AI Gateway의 일반적인 요청·응답 경로 · LiteLLM, Kong AI Gateway, Envoy AI Gateway 공식 문서를 바탕으로 재구성
요청이 들어오면 Gateway는 먼저 사용자의 Virtual Key나 JWT를 확인하고, 테넌트·예산·모델 허용 목록을 검사합니다. 그다음 공통 요청을 대상 공급자의 형식과 인증 방식으로 바꾸고, 적절한 모델 또는 배포로 전달합니다. 응답에서는 토큰 사용량과 지연시간을 기록하고 필요하면 출력 가드레일을 적용한 뒤 스트림을 클라이언트에 돌려줍니다.
핵심은 “프록시 하나를 더 둔다”가 아닙니다. 애플리케이션에 흩어진 모델별 접속 코드와 운영 정책을 중앙의 Model Access Layer로 끌어올리는 것입니다.
HTTP를 쓰는가, 내부 데이터 포맷은 무엇인가
대부분의 AI Gateway 외부 인터페이스는 HTTPS 위의 REST 스타일 API를 사용하고 Body에는 JSON을 넣습니다. 스트리밍 출력은 흔히 Server-Sent Events, 즉 SSE를 사용합니다. OpenAI Responses API도 stream=true일 때 SSE 이벤트를 반환합니다.
대표적인 요청 모양은 다음과 같습니다.
POST /v1/chat/completions HTTP/1.1
Authorization: Bearer virtual-key
Content-Type: application/json
{
"model": "customer-support-model",
"messages": [
{"role": "user", "content": "환불 정책을 알려줘"}
],
"stream": true
}
여기서 customer-support-model은 실제 공급자의 모델명이 아닐 수도 있습니다. Gateway 내부의 논리 모델명으로 두고 다음처럼 여러 배포에 연결할 수 있습니다.
customer-support-model
├─ 70% → Azure OpenAI 배포 A
├─ 20% → AWS Bedrock 모델 B
└─ 장애 시 → 사내 vLLM 모델 C
Gateway에서 공급자 쪽으로 나갈 때는 같은 HTTP/JSON이라도 URL, Header와 Body Schema가 달라집니다. AWS Bedrock은 SigV4 인증이 필요할 수 있고, Anthropic은 Messages API의 필드와 Header를 사용하며, Gemini는 자체 generateContent 구조를 사용합니다. Gateway가 이 차이를 번역합니다.
OpenAI 호환은 표준 규격인가
아닙니다. POST /v1/chat/completions, messages, tools, stream 같은 구조가 광범위하게 구현되어 사실상의 공통 언어가 되었지만, IETF RFC나 W3C·CNCF가 관리하는 독립 표준은 아닙니다. OpenAI 제품의 API 계약을 다른 프로젝트가 호환 구현한 것입니다.
또한 “OpenAI compatible”이라고 적혀 있어도 호환 범위는 서로 다릅니다.
- Chat Completions만 되고 Responses API는 되지 않을 수 있음
- Tool Call의 병렬 실행이나 Structured Output이 다를 수 있음
- 이미지·음성·Batch·Embedding Endpoint 지원 범위가 다름
- SSE Event 이름과 종료 방식이 다를 수 있음
- Prompt Cache, Reasoning Token과 Usage 필드가 누락될 수 있음
- 공급자 고유 기능을 공통 Schema로 표현하지 못할 수 있음
따라서 호환성은 체크박스 하나가 아니라 Endpoint × 모델 × 기능 × 스트리밍 × 오류 처리의 조합으로 시험해야 합니다.
그림: AI Gateway의 프로토콜 계층과 사실상의 인터페이스 · OpenAI API, LiteLLM, Higress AI Proxy 문서를 바탕으로 재구성
AI Gateway가 필요한 시점
모델 하나를 호출하는 작은 서비스라면 Gateway가 오히려 운영 요소만 늘릴 수 있습니다. 다음 조건 중 여러 개가 생길 때 도입 가치가 커집니다.
모델과 공급자가 둘 이상이다
가격, 성능, 데이터 위치와 장애 위험 때문에 모델을 바꾸거나 병행해야 한다면 공통 Endpoint와 논리 모델명이 유용합니다. 애플리케이션을 고치지 않고 Gateway의 Routing 정책만 바꿀 수 있습니다.
조직 공통 인증과 비용 통제가 필요하다
공급자 API Key를 모든 팀에 배포하는 대신 Gateway의 짧은 수명 토큰이나 Virtual Key를 발급합니다. 사용자·부서·프로젝트별 모델 허용 목록, 월 예산, TPM·RPM 한도를 중앙에서 적용할 수 있습니다.
장애 대응과 재시도가 중요하다
LLM 호출은 일반 API보다 오래 걸리고 Rate Limit이나 일시적 용량 부족이 자주 발생합니다. Gateway는 Timeout, 지수 Backoff, Circuit Breaker, Fallback을 일관되게 적용합니다. 단, 응답이 시작된 스트리밍 요청을 다른 모델로 넘기면 중복 문장이나 과금 문제가 생길 수 있으므로 재시도 가능 지점을 명확히 해야 합니다.
보안과 감사가 필요하다
누가 어떤 모델에 어떤 등급의 데이터를 보냈는지 추적하고, 외부 모델에는 개인정보가 포함된 Prompt를 보내지 않도록 해야 합니다. Gateway는 DLP·Guardrail·감사 로그를 연결하기 좋은 지점입니다.
하지만 Gateway에 원문 Prompt와 Response를 무조건 저장하면 그 Gateway가 가장 큰 개인정보 저장소가 됩니다. 기본값은 본문 비저장, 필요한 경우 마스킹·암호화·보존기간·열람권한을 분리하는 편이 안전합니다.
대표 오픈소스 AI Gateway 비교
LiteLLM Proxy — 범용 OSS의 첫 번째 후보
LiteLLM은 Python SDK와 중앙 Proxy Server를 모두 제공합니다. 애플리케이션은 OpenAI SDK의 base_url만 LiteLLM으로 바꾸고, LiteLLM은 공급자별 요청·응답과 오류를 변환합니다.
장점은 지원 범위입니다. Chat, Responses, Embedding, 이미지, 음성, Batch 등 다양한 Endpoint와 다수 공급자를 한 프로젝트에서 다룹니다. Virtual Key, 사용자·팀별 비용, Budget, Load Balancing, Fallback과 Observability도 AI 플랫폼 팀의 요구에 가깝습니다.
따라서 “일단 여러 외부 모델과 사내 모델을 하나의 API로 묶고 싶다”면 가장 먼저 PoC할 만합니다. 다만 기능이 빠르게 늘어나는 만큼 Stable Image 고정, 변경 로그 검토, 부하·스트리밍·DB 장애 시험이 필수입니다.
Envoy AI Gateway — Kubernetes 데이터 플레인에 가까운 선택
Envoy AI Gateway는 Envoy Gateway 위에서 생성형 AI 서비스 접근을 관리합니다. Kubernetes Gateway API와 CRD로 Provider, Route와 Backend를 선언하고, Envoy 데이터 플레인에서 요청 변환·인증·트래픽 정책을 수행하는 방향입니다.
플랫폼 팀이 이미 Envoy, Gateway API, GitOps와 OpenTelemetry를 운영한다면 별도 Python Gateway를 도입하는 것보다 자연스럽습니다. 중앙 Gateway에서 인증과 전역 Rate Limit을 처리하고, 팀 또는 모델 계층 Gateway에서 세부 Routing을 맡기는 2-Tier 구조에도 잘 맞습니다.
한편 Kubernetes의 Gateway API Inference Extension은 조금 다른 문제를 풉니다. 외부 SaaS Provider를 하나의 API로 번역하는 것보다, vLLM 같은 자체 호스팅 Model Server Replica 중 KV Cache, Queue, LoRA와 가속기 상태를 고려해 최적 Endpoint를 고르는 데 초점을 둡니다. 공식 문서도 LiteLLM 같은 상위 AI Gateway와 Kubernetes Inference Gateway를 조합할 수 있다고 설명합니다.
Kong AI Gateway — 기존 API 관리 자산을 재사용할 때
Kong은 AI Proxy Plugin을 통해 OpenAI 형식 요청을 여러 Provider로 변환하고, 기존 Kong의 인증·Rate Limit·Logging과 연결합니다. 이미 Kong Konnect나 Kong Gateway를 전사 표준으로 사용한다면 운영팀, 정책과 관측 체계를 그대로 활용할 수 있다는 점이 큽니다.
다만 “Kong AI Gateway 기능이 모두 오픈소스”라고 묶어 말하면 부정확합니다. AI Proxy처럼 사용할 수 있는 기능과 Enterprise License가 필요한 Semantic Cache·고급 Governance 기능을 도입 전에 구분해야 합니다.
Apache APISIX — 범용 API Gateway에 AI 기능을 더할 때
Apache APISIX는 동적 Routing, 인증, Circuit Breaker와 Observability를 제공하는 Apache 2.0 API Gateway입니다. ai-proxy, ai-proxy-multi, Token Rate Limit 같은 Plugin으로 LLM 요청 변환, 여러 모델 간 Load Balancing과 Fallback을 구성할 수 있습니다.
기존 HTTP·gRPC·마이크로서비스 트래픽과 AI API를 하나의 고성능 Gateway에서 운영하고 싶을 때 적합합니다. MCP Bridge처럼 기존 stdio MCP Server를 HTTP SSE 서비스로 노출하는 기능도 제공하므로 모델 API와 Tool API의 공통 진입점을 검토할 수 있습니다.
Higress — AI, API와 MCP를 Envoy·Wasm으로 통합할 때
Higress는 Istio와 Envoy를 기반으로 하고 Go·Rust·JavaScript Wasm Plugin으로 확장하는 AI Native API Gateway입니다. AI Proxy는 OpenAI API 계약을 기반으로 하며, 멀티모델 Proxy, Token Rate Limit, Cache, WAF, 인증과 MCP Server Hosting을 한 프로젝트에서 다룹니다.
Alibaba 내부와 클라우드 환경에서 발전한 만큼 해당 생태계와 다수의 중국계 모델까지 함께 쓰는 조직에 매력적입니다. 반대로 국내 조직에서는 문서, 지원, 운영 경험과 Open Source·Commercial Version의 기능 경계를 PoC에서 확인하는 편이 좋습니다.
Portkey Gateway — 경량 Gateway와 구성 기반 Routing
Portkey Gateway는 TypeScript 기반의 경량 MIT 프로젝트입니다. Retry, Fallback, Weighted Load Balancing과 Guardrail을 JSON Config로 정의하고 OpenAI 호환 Client로 호출할 수 있습니다. Node·Edge 친화적인 경량 Proxy를 원할 때 비교 대상이 됩니다.
현재 공식 저장소는 Enterprise Gateway Core가 OSS로 합쳐지는 2.0을 Pre-release로 안내합니다. 기능표에서 별표가 붙은 Hosted·Enterprise 전용 기능도 있으므로, 실제 배포할 Branch와 라이선스·운영 기능을 분리해서 판단해야 합니다.
어떤 프로젝트를 선택해야 할까
그림: 운영 환경별 AI Gateway 선택 가이드 · 각 프로젝트의 공식 문서를 바탕으로 재구성
선택 기준은 기능 개수보다 조직의 기존 운영 방식이어야 합니다.
빠른 멀티모델 통합이 우선이라면 LiteLLM
Python 기반 AI 플랫폼 팀이고 OpenAI SDK 호환성이 중요하며, 외부 Provider와 vLLM·Ollama 같은 내부 모델을 빠르게 묶고 싶다면 LiteLLM부터 검증하는 것이 합리적입니다.
Kubernetes와 선언형 네트워크 정책이 우선이라면 Envoy
Gateway API, GitOps, Envoy와 OpenTelemetry가 이미 표준이라면 Envoy AI Gateway를 검토합니다. 자체 GPU Model Serving 최적화가 핵심이면 Gateway API Inference Extension과 llm-d Router 같은 Endpoint Picker 계층도 함께 봐야 합니다.
기존 API Gateway가 있다면 먼저 확장 가능성을 본다
Kong, APISIX 또는 Higress를 이미 안정적으로 운영한다면 새로운 Gateway를 하나 더 추가하기 전에 기존 제품의 AI Plugin이 요구사항을 충족하는지 확인합니다. 인증·감사·장애 대응 체계를 두 벌로 만드는 비용이 생각보다 큽니다.
아주 가벼운 Edge Proxy가 필요하다면 Portkey
Node 환경에서 빠르게 시작하고 코드 중심 Config, Retry·Fallback과 기본 Guardrail이 중요하다면 Portkey가 맞을 수 있습니다. 다만 Pre-release와 상용 기능 경계를 감수할 수 있는지 확인해야 합니다.
PoC에서 반드시 검증할 체크리스트
제품 소개의 지원 목록만 보고 선택하면 운영 단계에서 문제가 드러납니다. 최소한 다음 항목을 실제 트래픽으로 시험해야 합니다.
- 기능 호환성: Chat, Responses, Tool Call, Structured Output, Embedding, 이미지와 Streaming이 대상 모델에서 실제로 동작하는가
- 장애 의미: 429, 5xx, Timeout, Stream 중단 시 어떤 요청만 재시도하며 중복 과금과 중복 출력은 없는가
- 인증과 권한: Provider Key가 애플리케이션에 노출되지 않고 사용자·프로젝트·모델 단위 권한을 강제하는가
- 비용 정확도: Cached Token, Reasoning Token, 이미지·음성 비용과 Provider 할인까지 올바르게 계산하는가
- 데이터 보호: Prompt·Response·Header가 로그, Trace, Error와 관리자 화면에 원문으로 남지 않는가
- 성능: 짧은 요청의 추가 지연, 긴 SSE 연결 수, Backpressure와 Gateway 장애 시 영향이 허용 범위인가
- 운영 복구: 설정 DB나 Control Plane이 멈춰도 기존 Data Plane이 안전하게 동작하는가
- 업그레이드: API Schema, DB Migration, Plugin과 Model Provider 변경을 Canary로 검증할 수 있는가
- 라이선스: OSS Core, Commercial Plugin, Hosted Service의 경계와 Support 조건이 문서화되어 있는가
특히 “Fallback이 된다”는 설명은 부족합니다. 같은 계열 모델의 다른 리전에 넘기는 것과 전혀 다른 모델로 넘기는 것은 답변 품질, Tool Schema와 안전 정책이 달라집니다. 업무별 Golden Dataset으로 정상 응답률과 의미 변화까지 비교해야 합니다.
권장 참조 아키텍처
규모가 커지면 모든 기능을 Gateway 하나에 몰아넣기보다 계층을 나누는 편이 좋습니다.
애플리케이션
→ WAF / 일반 API Gateway
→ AI Gateway
├─ 사용자·테넌트 인증
├─ 모델 허용 목록·예산·Rate Limit
├─ PII / Guardrail 연계
├─ 논리 모델 Routing·Fallback
└─ 토큰·비용·품질 관측
→ 외부 Model API
또는
→ Kubernetes Inference Gateway
→ vLLM / TGI / 사내 Model Server
일반 API Gateway는 인터넷 경계와 조직 공통 API 정책을 담당하고, AI Gateway는 모델 의미를 이해하는 정책을 담당합니다. 자체 호스팅 GPU Cluster 안에서는 Inference Gateway가 Queue와 KV Cache 상태를 고려해 Replica를 고릅니다.
이 구조는 제품도 교체하기 쉽습니다. 상위 AI Gateway는 OpenAI 호환 Endpoint를 유지하고, 하위 Inference Gateway나 Provider를 단계적으로 바꿀 수 있습니다.
마무리
AI Gateway는 단순한 Reverse Proxy가 아닙니다. 여러 모델 공급자의 HTTP/JSON API를 공통 인터페이스로 바꾸고, 인증키·비용·라우팅·장애 대응·관측·보안 정책을 한곳에서 관리하는 AI 플랫폼의 진입점입니다.
현재 시장에 ISO나 IETF가 정한 “AI Gateway 표준 제품”은 없습니다. 대신 OpenAI 호환 API가 애플리케이션 계층의 사실상 공통 언어가 되었고, LiteLLM이 범용 멀티프로바이더 OSS의 대표 선택지에 가장 가깝습니다. Kubernetes 자체 호스팅 추론에서는 Gateway API Inference Extension과 Envoy 계열이 표준화된 별도 축을 만들고 있습니다.
따라서 정답은 하나의 로고가 아니라 운영 환경에 달려 있습니다.
빨리 여러 모델을 묶으려면 LiteLLM, Kubernetes 네트워크와 GPU 추론을 표준화하려면 Envoy·Gateway API 계열, 이미 API Gateway가 있다면 Kong·APISIX·Higress 확장을 먼저 검토하는 것이 현실적인 출발점이다.
참고 자료
'일반IT > AI' 카테고리의 다른 글
| Ollama란 무엇인가 — Docker 컨테이너로 로컬 LLM 설치하고 API까지 사용하기 (0) | 2026.08.01 |
|---|---|
| AI 모델을 위한 가드레일 종류와 대표 오픈소스 — 입력부터 RAG·도구 실행까지 (0) | 2026.08.01 |
| Ollama·vLLM·llama.cpp 차이 — 로컬 LLM 실행 도구는 무엇을 선택해야 할까 (0) | 2026.07.31 |
| AI 에이전트는 어떻게 컴퓨터를 조작할까 — 브라우저 자동화부터 Computer Use까지 (0) | 2026.07.31 |
| GPT 펫이 안 보일 때 해결법 — ChatGPT·Codex Pets 설정과 커스텀 펫 오류 체크리스트 (0) | 2026.07.31 |
