LLM Gateway vs Router vs Inference Provider: 아키텍처 경계 이해하기

LLM 게이트웨이, 라우터, 그리고 추론 제공자(Inference Provider)는 모델 서빙 스택의 세 가지 다른 계층이며, 이들을 혼동하는 것은 팀들이 AI 제품을 설계할 때 가장 흔히 저지르는 실수입니다. 게이트웨이는 애플리케이션과 가장 가까운 곳에 위치하여 인증, 정규화, 관측 가능성(observability)을 처리합니다. 라우터는 주어진 요청을 어떤 모델이나 제공자가 처리할지 결정합니다. 추론 제공자는 실제로 가중치를 실행하고 토큰을 반환하는 주체입니다.

이 경계를 잘못 설정하면 통합이 취약해집니다. 팀들은 특정 제공자의 SDK를 하드코딩했다가, 몇 달 뒤 폴백(fallback) 모델을 추가하거나 Claude Sonnet 5, GPT-5.5, DeepSeek V4 Flash 간의 비용을 비교해야 할 때 요청 처리 로직의 상당 부분을 다시 작성해야 한다는 사실을 깨닫게 됩니다. 이 글에서는 세 계층을 분리하고, 각 책임이 어디에 있는지 설명하며, 각 범주의 벤더를 평가하기 위한 의사결정 프레임워크를 제공합니다.

핵심 요약

• 추론 제공자는 모델 가중치를 실행하고 API(OpenAI, Anthropic, Google, DeepSeek 또는 vLLM과 같은 자체 호스팅 엔진)를 노출합니다. 라우터는 요청별로 제공자나 모델을 선택합니다. 게이트웨이는 인증, 포맷팅, 로깅, 페일오버(failover)를 통합하여 애플리케이션 측에 제공하는 계층입니다.
• 라우팅 로직(비용 기반, 지연 시간 기반 또는 성능 기반 선택)은 독립형 서비스로 존재할 수도 있고 게이트웨이 내부의 기능으로 존재할 수도 있습니다. 이는 게이트웨이 그 자체와는 다른 개념입니다.
• 추론 제공자를 자체 호스팅하는 것, API 기반 제공자를 사용하는 것, 다중 제공자 게이트웨이를 사용하는 것은 상호 배타적이지 않습니다. 프로덕션 시스템은 모델과 워크로드에 따라 이 세 가지를 모두 결합하는 경우가 많습니다.
• "라우터"로 마케팅되는 제품이 호스팅하지 않는 OpenAI 호환 엔드포인트 간의 라우팅만 수행할 수도 있고, "게이트웨이"가 아직 필요하지 않은 거버넌스 기능과 라우팅을 번들로 제공할 수도 있으므로, 벤더가 실제로 어느 계층에서 운영되는지 질문하여 평가하십시오.

추론 제공자의 실제 역할

추론 제공자는 모델 가중치, GPU(또는 동등한 가속기), 저수준 서빙 엔진을 소유한 계층입니다. 여기에는 Anthropic(Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5), OpenAI(GPT-5.5), Google(Gemini 3.5 Flash), Zhipu(GLM-5.2), DeepSeek(DeepSeek V4 Pro, DeepSeek V4 Flash)와 같은 상용 API 제공자와 Qwen3.7 Plus, MiniMax M3, Kimi K2.7 Code와 같은 오픈 가중치 모델의 자체 호스팅 배포가 포함됩니다.

자체 호스팅을 하는 경우, 추론 제공자 계층은 직접 실행하는 소프트웨어입니다. vLLM의 서빙 문서는 LLM 워크로드를 대규모로 서빙하기 위해 연속 배치(continuous batching)와 메모리 효율적인 어텐션 처리를 중심으로 구축된 추론 엔진을 설명하며, 이는 자체 호스팅 모델 배포 바로 아래에 위치하는 구성 요소입니다. vLLM(또는 유사한 엔진)을 실행하면 해당 모델에 대한 추론 제공자가 되어 비용 및 데이터 지역성에 대한 제어권을 얻는 대신 GPU 용량 계획, 확장성, 가동 시간에 대한 책임을 지게 됩니다.

상용 API를 사용하는 경우, 제공자의 인프라와 속도 제한(rate limit)이 제약 조건이 됩니다. 각 제공자는 고유한 인증 체계, 요청 및 응답 스키마, 오류 코드, 속도 제한 동작을 가지고 있습니다. 이 계층에서 모델 품질, 컨텍스트 윈도우, 원시 지연 시간이 결정됩니다. 라우터나 게이트웨이는 추론 제공자의 성능을 바꿀 수 없으며, 단지 접근 방식을 바꿀 뿐입니다.

라우터의 역할

라우터는 들어오는 요청에 대해 목적지, 모델 또는 제공자를 선택하는 의사결정 로직입니다. 라우팅은 비용(단순 쿼리는 DeepSeek V4 Flash나 Gemini 3.5 Flash로 보내고, 복잡한 쿼리는 Claude Opus 4.8로 예약), 지연 시간(특정 모델에 대해 현재 가장 빠르게 응답하는 제공자를 선호), 가용성(첫 번째 제공자가 저하되면 두 번째 제공자로 페일오버) 등 여러 축에서 발생할 수 있습니다.

모델 라우팅에 대한 OpenRouter의 공개 설명은 모델 수준에서의 이 패턴을 설명합니다. 오픈 가중치 모델에 대한 요청은 동일한 가중치를 호스팅하는 여러 제공자에게 라우팅될 수 있으므로, 단일 논리적 모델 호출이 여러 백엔드 중 하나에 의해 수행될 수 있습니다. OpenRouter의 제공자 선택 문서는 순서 선호도를 표현하고 특정 제공자를 고려 대상에서 제외하는 매개변수를 추가로 설명하며, 이는 호출자가 플랫폼에 전적으로 맡기지 않고 라우팅 의도를 명시적으로 표현하는 메커니즘입니다.

중요한 아키텍처 포인트는 라우팅이 정책일 뿐, 그 자체로 제품 범주는 아니라는 점입니다. 애플리케이션 코드에서 직접 기본적인 라우팅을 구현하거나(작업 유형에 따른 간단한 if/else 또는 오류 발생 시 재시도 루프), 전용 라우팅 계층을 구매하거나, 더 넓은 게이트웨이 내부에 번들된 기능을 사용할 수 있습니다. 라우팅 기능을 평가할 때는 어떤 신호(가격, 지연 시간, 오류율, 모델 성능)를 사용하는지, 그리고 해당 신호가 구성 가능한지 아니면 고정되어 있는지 확인하십시오.

게이트웨이의 역할

게이트웨이는 애플리케이션 코드가 실제로 통신하는 계층입니다. 그 역할은 어떤 추론 제공자가 최종적으로 요청을 처리하든 상관없이 일관된 인터페이스를 제공하는 것입니다. 게이트웨이는 일반적으로 다음을 포함합니다:

• 제공자 간 통합된 요청 및 응답 스키마를 제공하여 GPT-5.5에서 Claude Sonnet 5로 전환할 때 파싱 로직을 다시 작성할 필요가 없게 합니다.
• 인증 및 키 관리를 통해 제공자 자격 증명이 애플리케이션 코드 전체에 흩어지지 않게 합니다.
• 사용 중인 모든 모델과 제공자에 대한 로깅, 사용량 추적, 비용 귀속을 수행합니다.
• 제공자가 느리거나, 속도 제한이 있거나, 오류를 반환할 때 페일오버 및 재시도 동작을 수행합니다.
• 선택적으로, 전체 제품이 아닌 여러 기능 중 하나로서의 라우팅 로직을 포함합니다.

TokenLab의 모델 연구 페이지는 프론티어 모델(Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash), 코딩 지향 모델(Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash), 저비용 라우팅 후보(DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3)를 포함하여 제공자 전반의 현재 모델을 카탈로그화하고 있으며, 이는 게이트웨이 사용자가 무엇으로 라우팅할지 결정할 때 필요한 참조 자료입니다. 통합 문제 자체에 대한 더 자세한 내용은 TokenLab의 2026년 통합 AI API 게이트웨이가 중요한 이유에 대한 글을 참조하십시오.

아키텍처 경계의 구체화

경계는 세 계층을 모두 통과하는 단일 요청을 추적하면 가장 쉽게 이해할 수 있습니다.

1. 애플리케이션이 작업 유형이나 모델 선호도를 지정하여 게이트웨이 엔드포인트로 채팅 완료 요청을 보냅니다.
2. 게이트웨이가 요청을 인증하고, 각 후보 제공자의 예상 스키마로 정규화한 뒤 라우팅 로직으로 전달합니다.
3. 라우터가 구성된 정책(비용 상한, 지연 시간 목표, 명시적 제공자 순서)을 평가하여 목적지를 선택합니다(예: Anthropic API를 통한 Claude Sonnet 5, 또는 vLLM을 통해 서빙되는 자체 호스팅 DeepSeek V4 Pro 인스턴스).
4. 추론 제공자가 모델을 실행하고 토큰을 반환합니다.
5. 게이트웨이가 응답을 일관된 형태로 다시 정규화하고, 관측 가능성 계층을 위해 결과(지연 시간, 비용, 사용된 제공자, 성공 또는 실패 여부)를 기록합니다.

각 계층은 독립적으로 실패할 수 있습니다. 제공자 중단은 추론 계층의 문제이고, 잘못된 라우팅 결정(긴 컨텍스트 요청을 작은 컨텍스트 윈도우를 가진 모델로 보내는 것)은 라우터 계층의 문제이며, 파서를 깨뜨리는 일관성 없는 응답 스키마는 게이트웨이 계층의 문제입니다. 어떤 계층에서 오류가 발생했는지 이해하는 것이 디버깅을 가능하게 합니다. AI API를 위한 신뢰성 인프라에 대한 TokenLab의 글은 이러한 계층 전반의 실패 격리에 대해 더 깊이 다룹니다.

의사결정 체크리스트

게이트웨이, 라우터, 직접 제공자 통합 또는 이들의 조합이 필요한지 평가할 때 이 체크리스트를 사용하십시오.

질문	예	아니오
현재 하나 이상의 모델이나 제공자를 호출하고 있거나, 12개월 이내에 그럴 예정입니까?	제공자별 직접 SDK 호출이 아닌 게이트웨이 또는 라우터 계층이 필요합니다.	단기적으로는 직접 제공자 SDK 통합으로 충분할 수 있습니다.
제공자가 저하되거나 속도 제한이 걸릴 때 자동 페일오버가 필요합니까?	상태 확인 및 폴백 순서가 포함된 라우터 수준의 로직이 필요합니다.	애플리케이션 코드 내 수동 재시도로 초기에는 충분할 수 있습니다.
제공자 전반의 모델별 비용 및 사용량 가시성이 한곳에서 필요합니까?	게이트웨이 수준의 로깅 및 귀속 기능이 필요합니다.	제공자 네이티브 대시보드로 현재는 충분할 수 있습니다.
오픈 가중치 모델(GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code)을 자체 호스팅하고 있습니까?	추론 제공자 계층도 운영 중이며 vLLM과 같은 서빙 인프라가 필요합니다.	상용 API 제공자에 전적으로 의존할 수 있습니다.
작업 유형별로 라우팅해야 합니까(분류에는 저렴한 모델, 추론에는 프론티어 모델)?	단순 페일오버가 아닌 명시적인 라우터 정책이 필요합니다.	단일 기본 모델로 충분할 수 있습니다.

요청 형태 예시

아래 예시는 기본 모델 선호도와 폴백 목록을 모두 표현하는 게이트웨이 스타일 요청의 일반적인 형태를 보여주며, 이는 OpenRouter의 제공자 선택 문서에서 라우팅 선호도를 표현하는 방식과 일치합니다. 필드 이름은 예시로 간주하고, 배포 전에 선택한 게이트웨이의 현재 API 참조를 통해 정확한 매개변수를 확인하십시오.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

이 형태에서 게이트웨이는 요청 정규화와 응답 계약을 소유하고, 라우터는 routing_policy와 fallback_models 해석을 소유하며, 최종적으로 선택된 제공자가 실제로 완료(completion) 생성을 수행합니다. 프로덕션에서 특정 필드 이름을 사용하기 전에 현재 문서와 정확한 요청 및 응답 스키마를 확인하십시오.

제한 사항

OpenRouter와 vLLM의 공개 문서는 일반적인 라우팅 및 서빙 메커니즘을 설명할 뿐, 보편적인 보장을 제공하지 않습니다. 정확한 지연 시간, 가격 책정, 페일오버 동작은 제공자마다 다르며 시간이 지남에 따라 변경되므로, 이 글이 아닌 제공자 문서를 통해 현재 수치를 직접 확인하십시오. vLLM을 사용한 자체 호스팅은 운영 책임(용량 계획, 확장, 패치)을 팀으로 옮기는 것이며, 인프라 작업을 제거하는 것이 아니라 재배치하는 것입니다. 어떤 라우팅 정책도 근본적으로 잘못된 모델 선택(예: 긴 컨텍스트 추론이 필요한 작업을 해당 작업에 적합하지 않은 모델로 보내는 것)을 보완할 수 없습니다. 라우터 구성은 워크로드에 대한 모델 성능 평가를 대신할 수 없으며, 이것이 바로 TokenLab의 모델 연구와 같은 최신 모델 참조를 유지하는 것이 중요한 이유입니다.

FAQ

게이트웨이는 라우터와 같습니까? 아니요. 라우터는 모델이나 제공자를 선택하기 위한 의사결정 로직입니다. 게이트웨이는 인증, 정규화, 로깅과 함께 라우팅을 하나의 가능한 기능으로 포함하는 더 넓은 애플리케이션 측 계층입니다.

직접 추론 제공자가 되면서 게이트웨이를 사용할 수 있습니까? 네. vLLM과 같은 엔진을 통해 서빙되는 자체 호스팅 모델은 게이트웨이가 사용자 정의 또는 OpenAI 호환 엔드포인트를 지원하는 한 상용 API 제공자와 동일한 게이트웨이 뒤에 위치할 수 있습니다.

첫날부터 세 계층이 모두 필요합니까? 반드시 그렇지는 않습니다. 초기 프로토타입에는 단일 제공자 직접 통합이 합리적입니다. 페일오버, 다중 모델 비용 제어 또는 제공자 비교가 필요해지는 즉시 라우팅 기능이 포함된 게이트웨이를 도입하는 것이 엔지니어링 비용 측면에서 가치가 있습니다.

어떤 계층을 먼저 도입할지 평가 중이라면 TokenLab의 모델 연구 페이지에서 현재 모델 옵션을 검토하고, 초기부터 하나의 통합에 얽매이지 않고 라우팅과 제공자를 점진적으로 추가할 수 있는 게이트웨이 설정으로 시작하십시오.