요약 (TL;DR): API gateway는 서비스 간의 HTTP 트래픽을 관리합니다 — 인증 (auth), 라우팅 (routing), 속도 제한 (rate limiting), REST 및 gRPC를 위한 부하 분산 (load balancing). AI gateway는 LLM 워크로드를 관리합니다 — 토큰 기반 속도 제한 (token-based rate limiting), 모델 라우팅 (model routing), 비용 귀속 (cost attribution), 시맨틱 캐싱 (semantic caching), 가드레일 (guardrails). 마이크로서비스에는 API gateway를 사용하세요. LLM 트래픽에는 AI gateway를 사용하세요. 대부분의 프로덕션 팀은 결국 서로 다른 계층에 위치한 두 가지 모두가 필요하게 됩니다. 이 포스트는 각각이 정확히 어디에 적합한지 살펴봅니다.

우리가 플랫폼에 LLM 기능을 추가하기 시작했을 때, 이미 마이크로서비스를 위해 Kong을 실행하고 있었습니다. 본능적인 생각은 자연스러웠습니다: LLM 트래픽도 Kong을 통해 라우팅하는 것이었죠. 동일한 인증 (auth), 동일한 속도 제한 (rate limiting), 동일한 관측성 스택 (observability stack). 모든 것을 지배하는 하나의 게이트웨이 말입니다.

그것은 작동했습니다 — 약 6개월 동안, 그리고 단지 요청이 통과된다는 의미에서만 말이죠. 하지만 실제로 AI 워크로드를 관리하는 데 유용한 기능은 전혀 제공하지 못했습니다. 우리는 각 팀이 토큰에 얼마를 쓰고 있는지 전혀 알 수 없었습니다. 청구서가 도착하기 전에 작동할 예산 상한선 (budget cap)을 설정할 방법도 없었습니다. 우리의 속도 제한 (rate limits)은 분당 요청 수 (requests per minute)를 기준으로 했기 때문에, 50k 토큰 프롬프트가 포함된 단일 요청이 200 토큰 프롬프트가 포함된 요청과 동일하게 취급되었습니다. 그리고 OpenAI에 부분적인 장애가 발생했을 때, Kong은 "대신 Anthropic을 시도하라"는 개념이 없었습니다 — 우리는 그냥 에러를 반환할 뿐이었습니다.

이 중 어느 것도 Kong에 대한 비판이 아닙니다. Kong은 설계된 대로 정확히 수행하고 있습니다. 문제는 API gateway가 근본적으로 다른 범주의 인프라 문제를 처리할 것이라고 기대했던 우리였습니다.

여기에 정확한 차이점과, 이것이 아키텍처 측면에서 왜 중요한지가 있습니다.

API gateway가 실제로 하는 일

API gateway는 클라이언트 애플리케이션과 백엔드 서비스 사이에 위치하는 리버스 프록시 (reverse proxy)입니다. 이는 서비스 간 HTTP 통신의 공통 관심사 (cross-cutting concerns)를 처리합니다: 인증 (authentication), 권한 부여 (authorization), 속도 제한 (rate limiting), 부하 분산 (load balancing), SSL 종료 (SSL termination), 요청 변환 (request transformation), 그리고 URL 경로 또는 헤더를 기반으로 한 라우팅 (routing).

API gateway를 통한 전형적인 요청 흐름:

1. 클라이언트가 게이트웨이 엔드포인트(endpoint)로 요청을 보냅니다.
2. 게이트웨이가 인증 (authentication) (API key, JWT, OAuth token)을 확인합니다.
3. 게이트웨이가 속도 제한 (rate limiting)을 적용합니다 — 이 클라이언트가 요청 할당량 (quota)을 초과했습니까?
4. 게이트웨이가 경로 (path)를 기반으로 적절한 업스트림 (upstream) 서비스로 라우팅 (routing)합니다.
5. 게이트웨이가 모든 요청/응답 변환 (transformation)을 적용합니다.
6. 응답이 게이트웨이를 통해 클라이언트에게 반환됩니다.

여기서 모든 것의 단위는 **HTTP 요청 (HTTP request)**입니다. 속도 제한은 초당 또는 분당 요청 수로 측정됩니다. 비용은 콘텐츠가 아닌 컴퓨팅 (compute) 단위로 측정됩니다. 게이트웨이는 요청 본문 (request body)의 _내용_이 무엇인지 알지 못하며 상관하지 않습니다 — 게이트웨이는 바이트 (bytes)를 라우팅할 뿐입니다.

API 게이트웨이는 다음과 같은 경우에 가장 효과적입니다:

• 일관된 인증 (auth) 및 속도 제한 (rate limiting)이 필요한 여러 백엔드 마이크로서비스 (microservices)가 있는 경우
• 모든 REST 또는 gRPC 트래픽에 대해 단일 인그레스 (ingress) 지점을 원하는 경우
• 요청/응답 변환 (transformation) 또는 프로토콜 변환 (protocol translation)이 필요한 경우
• Kubernetes 클러스터 전반에 걸쳐 서비스 메시 (service mesh) 정책을 강제하는 경우
• 트래픽이 동기적 (synchronous)이고 상태가 없는 (stateless) 경우

Kong, NGINX, AWS API Gateway, Apigee — 이들은 모두 이 분야에서 매우 뛰어납니다. 이들은 10년 넘게 프로덕션 환경에서 검증되었습니다.

AI 게이트웨이가 실제로 하는 일

AI 게이트웨이는 애플리케이션 코드와 LLM 제공업체 (LLM providers) 사이에 위치하는 미들웨어 (middleware)입니다. 이는 LLM 트래픽의 횡단 관심사 (cross-cutting concerns)인 모델 라우팅 (model routing), 토큰 기반 속도 제한 (token-based rate limiting), 비용 귀속 (cost attribution), 시맨틱 캐싱 (semantic caching), 폴백 체인 (fallback chains), 가드레일 (guardrails), 그리고 프롬프트/응답 로깅 (prompt/response logging)을 처리합니다.

AI 게이트웨이를 통한 전형적인 요청 흐름:

1. 애플리케이션이 게이트웨이의 OpenAI 호환 엔드포인트(OpenAI-compatible endpoint)로 프롬프트(prompt)를 전송합니다.
2. 게이트웨이가 요청을 인증(authenticate)하고 팀/사용자의 토큰 예산(token budget)을 확인합니다.
3. 게이트웨이가 토큰 기반 속도 제한(token-based rate limiting)을 적용합니다 — 이 팀이 토큰 할당량(token quota)을 초과했습니까?
4. 게이트웨이가 설정된 규칙(비용, 지연 시간(latency), 폴백(fallback))에 따라 적절한 모델로 라우팅(route)합니다.
5. 게이트웨이가 입력 가드레일(input guardrails, 개인정보(PII) 탐지, 프롬프트 인젝션(prompt injection) 체크)을 적용합니다.
6. 요청이 LLM 제공업체(LLM provider)로 전달됩니다.
7. 게이트웨이가 응답에 대해 출력 가드레일(output guardrails)을 적용합니다.
8. 게이트웨이가 토큰 수, 비용, 지연 시간, 사용자 귀속(user attribution) 정보를 포함하여 전체 요청을 로깅(log)합니다.
9. 응답이 애플리케이션으로 반환됩니다.

여기서의 단위는 HTTP 요청이 아니라 **토큰(token)**입니다. 단일 HTTP 요청이 5만 개의 토큰을 포함하여 0.75달러의 비용이 발생할 수 있는 반면, 다른 요청은 200개의 토큰을 포함하여 0.003달러의 비용이 발생할 수 있습니다. 요청 수준의 속도 제한(Request-level rate limiting)은 이들을 동일하게 취급하지만, 토큰 수준의 속도 제한(Token-level rate limiting)은 그렇지 않습니다.

AI 게이트웨이는 다음과 같은 경우에 가장 효과적입니다:

• 하나 이상의 LLM 제공업체로 트래픽을 라우팅하며 통합된 관측성(unified observability)이 필요한 경우
• 여러 팀이나 애플리케이션이 LLM을 호출하고 있어 비용 귀속(cost attribution)이 필요한 경우
• 모델 장애 시 사용자에게 에러를 노출하는 대신 자동 폴백(automatic failover)을 트리거해야 하는 경우
• 청구서가 도착한 후가 아니라, 도착하기 전에 지출 한도를 강제해야 하는 경우
• 프롬프트나 응답에 대한 가드레일(guardrails)이 컴플라이언스(compliance) 또는 안전 요구 사항인 경우
• 도구를 호출하는 에이전트(agents)를 배포 중이며 거버넌스가 적용된 MCP 액세스가 필요한 경우

핵심 차이점, 정확한 정의

두 게이트웨이 모두 트래픽을 관리합니다. 차이점은 그 트래픽의 어떤 *차원(dimension)*을 이해하느냐에 있습니다.

API 게이트웨이는 HTTP — 경로(paths), 메서드(methods), 헤더(headers), 인증 토큰(authentication tokens)을 이해합니다.

AI 게이트웨이는 LLM 의미론(LLM semantics) — 토큰 수(token counts), 모델 기능(model capabilities), 추론당 비용(cost per inference), 프롬프트 내용(prompt content), 응답 안전성(response safety)을 이해합니다.

이것이 바로 하나를 다른 하나로 대체할 수 없는 이유입니다. 기술적으로는 Kong을 통해 LLM 요청을 라우팅할 수 있습니다. Kong은 인증(auth)을 수행하고, 요청 횟수(request count)를 기준으로 속도 제한(rate limit)을 적용하며, OpenAI로 요청을 라우팅할 수 있습니다. 하지만 Kong은 데이터 과학 팀이 지난주 Claude Opus에 847달러를 사용했다는 사실을 알려줄 수 없으며, Claude가 속도 제한을 걸 때 자동으로 GPT-4o-mini로 전환하거나, 프롬프트 주입(prompt injection) 시도를 모델에 도달하기 전에 차단할 수도 없습니다. 이러한 기능들은 LLM 요청이 실제로 무엇인지 이해하는 계층(layer)을 필요로 합니다.

우리가 저지른 실수 — 그리고 여러분이 저지르고 있을지도 모르는 실수

우리는 토큰 수준의 속도 제한(token-level rate limiting)이 Kong의 플러그인으로 구현할 수 있는 것이라고 가정했습니다. 우리는 OpenAI 요청 본문(request body)을 파싱하고, 토큰 추정치를 추출하며, 제한을 적용하려고 시도하는 Lua 플러그인을 만드는 데 2주를 보냈습니다. 기술적으로는 개발 환경에서 작동했습니다. 하지만 스트리밍 응답(streaming responses) 환경에서는 작동하지 않았습니다(토큰이 점진적으로 도착하기 때문에 스트림이 끝날 때까지 전체를 알 수 없습니다). 요청 형식이 다른 Anthropic을 추가했을 때도 작동하지 않았습니다. 토큰 카운팅이 전혀 없는 자체 호스팅 모델(self-hosted model)을 추가했을 때도 작동하지 않았습니다.

더 깊은 문제는 이것입니다. 우리는 API Gateway 내부에서 AI Gateway를 구축하고 있었습니다. 시맨틱 캐싱(semantic caching), 모델 폴백(model fallback), 토큰 기반 속도 제한(token-based rate limiting), 팀별 비용 귀속(per-team cost attribution) 등 우리에게 필요한 모든 기능은 각각 커스텀 플러그인을 필요로 했을 것입니다. 그 경로의 최종 상태는 우리 팀이 유지 관리하며 모든 운영 오버헤드(operational overhead)를 수반하는, Kong 플러그인 모음으로 구현된 커스텀 AI Gateway가 되는 것이었습니다.

어느 시점에 이르면 솔직한 질문을 던지게 됩니다. 이미 존재하는 것을 왜 직접 만들려고 하는가?

우리의 답은 LLM 트래픽을 위한 전용 AI Gateway (AI 게이트웨이)로 전환하고, 그 외의 모든 것에는 Kong을 유지하는 것이었습니다. Kong 설정은 정확히 동일하게 유지되었습니다. LLM 서비스들은 제공업체(provider)로 직접 연결되는 대신 AI Gateway를 통해 라우팅되기 시작했습니다. 각 서비스의 설정에서 OPENAI_BASE_URL과 ANTHROPIC_BASE_URL을 설정하고 이를 AI Gateway 엔드포인트로 지정함으로써, 애플리케이션 코드를 수정하지 않고도 토큰 수준의 관측성 (observability)을 확보했습니다.

둘 다 필요한가요, 아니면 하나만 필요한가요?

마이크로서비스 (microservices)만 있고 LLM 워크로드 (workloads)가 없는 경우: API Gateway (API 게이트웨이)가 필요합니다. 전용 AI Gateway는 아무런 도움이 되지 않습니다.

LLM 워크로드는 있지만 마이크로서비스가 없는 경우 (드문 사례): AI Gateway가 필요합니다. 일반적인 API Gateway는 귀하에게 필요한 기능을 처리할 수 없습니다.

둘 다 있는 경우 (현재 대부분의 팀): 서로 다른 계층 (layers)에서 작동하는 두 가지가 모두 필요합니다. API Gateway는 서비스 메시 (service mesh)를 처리하고, AI Gateway는 LLM 트래픽을 처리합니다. 이들은 경쟁하는 것이 아니라, 스택 (stack)의 서로 다른 부분에 위치합니다.

실제 구성 방식은 다음과 같습니다: API Gateway의 관점에서 볼 때, AI Gateway는 하나의 추가적인 업스트림 (upstream) 서비스입니다. 외부 트래픽 → API Gateway → 귀하의 서비스 → AI Gateway → LLM 제공업체. 각 계층은 설계된 목적에 맞는 역할을 수행합니다.

우리가 사용하는 것과 그 이유

우리는 서비스 메시를 위해 Kong을 계속 사용했습니다. Kong은 약 30개의 내부 서비스를 위한 인증 (auth) 및 라우팅을 처리하며, 우리는 이를 위해 수년간 운영상의 투자를 해왔습니다.

LLM 트래픽의 경우, TrueFoundry의 AI Gateway로 이동했습니다. 중요했던 구체적인 요소들은 다음과 같습니다:

인메모리 (in-memory) 기반의 토큰 단위 속도 제한 (rate limiting). 인증, 예산 확인, 속도 제한이 요청이 나가기 전 모두 인메모리에서 실행됩니다. 요청마다 외부 DB를 조회할 필요가 없으며, 장애 발생 시 허용(fail open)될 수 있는 Redis 의존성도 없습니다. 벤치마크 결과에 따르면 1 vCPU에서 10ms 미만의 오버헤드로 350+ RPS를 기록했으며, 이는 저희의 자체 테스트에서도 확인되었습니다.

핫 패스(hot path)에서의 팀별 예산 집행 강제. 특정 팀이 할당된 토큰 예산에 도달하면, 이후의 요청은 속도 제한(rate-limit) 에러를 반환합니다. 사후 알림이 아니라, 비용이 발생하기 전에 에러를 발생시키는 것입니다. 이것이 바로 새벽 2시에 울리던 결제 관련 알림 문제를 해결한 아키텍처적 차이입니다.

모델 폴백 체인 (Model fallback chains). 저희는 우선순위에 따라 Claude Opus 4 → Claude Sonnet 4.6 → GPT-4o → GPT-4o-mini 순으로 구성했습니다. Claude의 속도 제한(rate limits)이 발생하면 트래픽은 자동으로 폴백(fallback) 모델로 라우팅됩니다. 덕분에 모델 장애 발생 시에도 저희 앱은 에러를 반환하지 않게 되었습니다.

통합 비용 귀속 (Unified cost attribution). 자체 호스팅 중인 Llama 배포를 포함하여, 팀별, 모델별, 애플리케이션별 지출을 보여주는 단일 대시보드를 구축했습니다. 이전에는 상호 참조가 불가능한 세 개의 별도 결제 대시보드를 사용해야 했습니다.

솔직한 트레이드오프(tradeoff)를 말씀드리자면: TrueFoundry는 Kubernetes-native 방식이므로, 이미 K8s를 사용하고 있지 않다면 설정 오버헤드가 발생합니다. 더 가벼운 솔루션을 원한다면, LiteLLM이 더 낮은 인프라 오버헤드로 핵심적인 라우팅과 비용 추적을 제공합니다. 다만 SSO 및 팀 수준의 거버넌스 기능은 엔터프라이즈 라이선스가 필요하지만, 소규모 설정에서는 훌륭한 시작점이 될 수 있습니다.

결정을 명확하게 해주는 질문

지금 누군가 당신에게 이렇게 묻는다면: "지난주에 어떤 팀이 LLM 호출에 가장 많은 비용을 썼고, 어떤 모델을 사용했나요?" — 당신은 답할 수 있습니까?

만약 그렇다면: 당신의 AI 게이트웨이는 제대로 작동하고 있는 것입니다.
만약 아니라면: 당신은 API 게이트웨이로 AI 게이트웨이의 역할을 수행하게 하고 있는 것이며, LLM 사용량이 늘어날수록 그 격차로 인한 비용은 점점 더 커질 것입니다.

현재 여러분의 설정은 어떠신가요? AI 트래픽을 일반 API 게이트웨이를 통해 라우팅하고 계신가요, 아니면 전용 레이어를 추가하셨나요? 특히 Apigee나 AWS API Gateway를 사용하는 팀들이 네이티브 AI 기능이 가치가 있다고 느끼는지, 아니면 결국 별도의 AI 게이트웨이 레이어를 구축하게 되었는지 궁금합니다. 댓글로 알려주세요.