LLM Gateway 2-Tier 아키텍처
작성일: 2026-03-16 | 읽는 시간: 약 20분
개요
LLM 서빙 환경에서는 인프라 레벨의 트래픽 관리와 LLM 프로바이더 추상화라는 두 가지 서로 다른 관심사를 분리해야 합니다. 단일 Gateway로 모든 기능을 처리하려 하면 복잡성이 급증하고 각 레이어의 특화된 기능을 최적화하기 어렵습니다.
단일 Gateway의 한계
| 관심사 | 요구사항 | 단일 Gateway 문제점 |
|---|---|---|
| 인프라 트래픽 관리 | Kubernetes 네이티브 라우팅, mTLS, 서킷 브레이커, 네트워크 정책 | LLM 특화 로직과 혼재되어 복잡도 증가 |
| LLM 프로바이더 추상화 | 100+ 프로바이더 통합, 토큰 카운팅, 시맨틱 캐싱, 비용 추적 | Envoy/Gateway API 확장으로 구현 시 비표준 의존성 발생 |
| AI 프로토콜 | MCP(Model Context Protocol), A2A(Agent-to-Agent), JSON-RPC 세션 | 범용 Gateway는 stateful 세션 지원 미비 |
2-Tier 접근의 장점
Tier 1 (인프라 Gateway): Kubernetes Gateway API 표준 구현체(kgateway)로 트래픽 제어, 라우팅, 보안, 네트워크 정책을 처리합니다. Envoy 기반의 성능과 Kubernetes 생태계 네이티브 통합을 제공합니다.
Tier 2 (LLM Gateway): LLM 프로바이더 추상화에 특화된 경량 게이트웨이(Bifrost, LiteLLM 등)로 100+ 프로바이더 통합, 비용 추적, 시맨틱 캐싱, cascade routing을 담당합니다.
이 분리를 통해:
- 각 티어는 자신의 관심사에만 집중하여 최적화
- Tier 1은 Kubernetes 표준을 따라 이식성 확보
- Tier 2는 빠르게 진화하는 LLM 생태계에 민첩하게 대응
- 운영팀은 인프라와 AI 워크로드를 독립적으로 관리 가능
주요 목표
- 트래픽 제어: Kubernetes Gateway API 표준 기반 라우팅
- 프로바이더 추상화: OpenAI/Anthropic/Bedrock/Azure/GCP 통합 API
- 비용 최적화: Cascade routing, semantic caching, budget control
- AI 프로토콜 지원: MCP/A2A 네이티브 라우팅