들어가며

LLM 애플리케이션을 처음 만들 때는 애플리케이션이 모델 공급자의 API를 직접 호출해도 큰 문제가 없습니다. 그러나 여러 팀이 OpenAI, Anthropic, Bedrock, Gemini와 자체 호스팅 모델을 함께 사용하기 시작하면 애플리케이션 코드가 빠르게 복잡해집니다.

• 공급자마다 API 형식과 인증 방식이 다릅니다.
• 모델 이름과 라우팅 규칙을 애플리케이션마다 관리하게 됩니다.
• 공급자 장애 시 재시도와 대체 모델 전환 정책이 필요합니다.
• 요청 수가 아니라 입력·출력 토큰을 기준으로 사용량과 한도를 관리해야 합니다.
• 에이전트가 사용하는 MCP 서버와 도구에도 인증, 인가와 관측성이 필요합니다.

Agent Router는 이 문제를 애플리케이션과 모델 사이의 공통 게이트웨이에서 해결합니다. 애플리케이션은 하나의 OpenAI 호환 API를 호출하고, 플랫폼 팀은 공급자, 자격 증명, 라우팅, 할당량, 장애 조치와 사용량 집계를 중앙에서 관리합니다.

Agent Router를 이해하려면 먼저 Envoy를 전부 공부할 필요는 없습니다. 다음 세 가지 연결점만 잡으면 됩니다.

1. Envoy는 요청 경로에서 실제 트래픽을 처리하는 고성능 L7 프록시입니다.
2. Envoy의 필터 체인과 ext_proc는 AI 전용 처리 로직을 프록시 외부로 확장할 수 있게 합니다.
3. Envoy Gateway와 xDS는 고수준 정책을 실제 Envoy 설정으로 변환해 데이터 플레인에 전달합니다.

Agent Router를 이해하기 위한 최소 Envoy

애플리케이션에서 네트워크 문제를 분리하기

Envoy는 Lyft가 분산 시스템의 애플리케이션 네트워킹 문제를 해결하기 위해 개발했고, 2016년 9월 오픈소스로 공개했습니다. 2017년 9월 CNCF에 합류했으며 현재는 CNCF 졸업 프로젝트입니다. C++로 작성된 독립 프로세스로 동작하며 높은 부하에서도 예측 가능한 성능과 안정성을 제공하는 것을 중요한 목표로 삼았습니다.

Envoy의 출발점은 다음 문장으로 요약할 수 있습니다.

네트워크는 애플리케이션에 투명해야 하며, 문제가 발생했을 때 그 원인을 쉽게 파악할 수 있어야 합니다.

프록시가 없으면 클라이언트가 서비스 인스턴스의 주소와 상태를 알아야 합니다. 인스턴스가 늘거나 장애가 발생하면 클라이언트의 서비스 디스커버리와 로드 밸런싱 코드도 복잡해집니다. 프록시를 중간에 두면 클라이언트는 하나의 주소만 바라보고, 프록시가 사용 가능한 백엔드를 찾고 부하를 분산하며 비정상 인스턴스를 우회합니다.

Envoy는 이 기능을 애플리케이션 밖에서 제공합니다. 따라서 애플리케이션의 언어나 프레임워크와 관계없이 같은 라우팅, 복원력, 보안과 관측성 정책을 적용할 수 있습니다. 이 특성이 여러 언어와 SDK로 작성되는 AI 애플리케이션에도 그대로 이어집니다.

L7 프록시로 서빙

IP 주소와 포트만 보는 L4 프록시는 연결을 어느 서버로 보낼지는 결정할 수 있지만 HTTP 요청의 의미까지는 알지 못합니다. Envoy는 HTTP/1.1, HTTP/2, HTTP/3와 gRPC 같은 애플리케이션 계층 프로토콜을 이해합니다. 그래서 경로와 헤더를 기준으로 요청을 라우팅하고, 요청 단위의 타임아웃·재시도·속도 제한·인증·관측성을 적용할 수 있습니다.

Agent Router에는 한 단계 더 깊은 L7 이해가 필요합니다. 목적지를 고르려면 URL과 헤더뿐 아니라 JSON 본문의 model 필드를 읽어야 하고, 토큰 사용량을 계산하려면 스트리밍 응답도 해석해야 하며, 공급자가 달라지면 요청과 응답 형식을 변환해야 합니다. Envoy의 확장 가능한 L7 처리 구조가 Agent Router의 기반이 되는 이유입니다.

다섯 가지 핵심 용어

다운스트림 요청은 Listener로 들어와 Filter Chain을 통과합니다. HTTP Connection Manager가 바이트 스트림을 HTTP 헤더·본문·트레일러로 해석하고, 마지막의 Router filter가 Route 설정에 따라 Cluster와 Endpoint를 선택합니다. 응답은 반대 순서로 필터를 거쳐 다운스트림으로 돌아갑니다.

Agent Router까지 이어지는 Envoy 기능

Envoy의 기능은 매우 많지만 Agent Router를 소개하는 데 필요한 부분은 다음과 같습니다.

재시도는 특히 주의해야 합니다. 일반 HTTP 요청과 달리 LLM 요청은 비용이 크고 스트리밍이 시작된 뒤에는 다른 공급자로 안전하게 다시 보내기 어렵습니다. 따라서 “5xx면 무조건 세 번 재시도” 같은 일반적인 웹 API 정책보다, 응답 시작 여부와 공급자별 변환·인증을 함께 고려한 제한적인 장애 조치가 필요합니다.

Envoy의 확장 지점: External Processing

Envoy 필터를 C++로 작성해 바이너리에 포함할 수도 있지만, 커스텀 빌드를 계속 유지해야 합니다. Lua와 Wasm도 선택지이지만 Agent Router의 핵심 확장점은 External Processing filter, 줄여서 ext_proc입니다.

ext_proc는 Envoy가 처리 중인 HTTP 요청과 응답의 헤더, 본문 또는 트레일러를 외부 gRPC 서비스에 전달하고 그 결과에 따라 계속 처리하거나 내용을 변경하게 합니다. 덕분에 Envoy 코어를 포크하지 않고도 복잡한 애플리케이션 계층 로직을 추가할 수 있습니다.

과거 자료에는 External Processing filter가 아직 실질적인 기능을 하지 않는다고 설명된 경우가 있습니다. 이는 당시 구현 상태를 반영한 내용입니다. 현재 Agent Router에서는 ext_proc가 AI 요청 처리의 중심 역할을 합니다.

Agent Router의 External Processor는 다음 작업을 수행합니다.

• 요청 본문에서 모델 이름을 읽고 유효성을 검사합니다.
• 선택한 공급자에 맞게 경로, 헤더와 본문을 변환합니다.
• 공급자 자격 증명을 요청에 추가합니다.
• OpenAI 형식과 Bedrock 같은 공급자별 형식 사이를 변환합니다.
• 스트리밍과 비스트리밍 응답에서 토큰 사용량을 추적합니다.
• 공급자 응답을 클라이언트가 기대하는 공통 형식으로 정규화합니다.

이 구조에서 Envoy는 연결, HTTP, 라우팅과 복원력을 담당하고 External Processor는 AI 프로토콜의 의미를 담당합니다. 한 문장으로 줄이면 **“Agent Router가 설정하고, Envoy가 트래픽을 운반한다”**입니다.

Agent Router란 무엇인가

Agent Router는 모델과 도구로 향하는 AI 트래픽을 위한 오픈소스 제어 계층입니다. 애플리케이션에는 일관된 OpenAI 호환 API를 제공하고, 뒤쪽에는 외부 모델 공급자, 자체 호스팅 vLLM 같은 모델 서버와 MCP 서버를 연결합니다.

Agent Router를 사용하면 애플리케이션에서 다음 책임을 분리할 수 있습니다.

• 공급자별 SDK와 API 형식
• API key와 클라우드 인증 정보
• 논리적 모델 이름과 실제 공급자 모델의 매핑
• 트래픽 분할, 우선순위, 재시도와 failover
• 요청 또는 토큰 기반 quota와 rate limit
• 모델·팀·사용자별 사용량 귀속
• MCP 서버와 도구의 노출 범위와 접근 정책

왜 일반 API Gateway만으로는 부족한가

일반 API Gateway도 인증, 경로 기반 라우팅과 요청 수 기반 속도 제한을 수행할 수 있습니다. 하지만 생성형 AI 트래픽에는 추가적인 의미가 있습니다.

• 목적지가 URL이 아니라 요청 본문의 논리적 모델 이름으로 정해질 수 있습니다.
• 공급자마다 서로 다른 요청·응답 스키마와 인증 방식을 사용합니다.
• 스트리밍 응답을 유지하면서 사용 토큰을 추적해야 합니다.
• 분당 요청 수보다 분당 토큰 수가 실제 비용과 용량을 더 잘 나타낼 수 있습니다.
• 장애 조치 시 새 공급자에 맞춰 요청을 다시 변환하고 인증해야 합니다.
• 에이전트는 모델뿐 아니라 MCP 도구 목록 조회와 호출도 수행합니다.

Agent Router는 Envoy Gateway의 범용 게이트웨이 기능 위에 이 AI 전용 처리를 추가합니다.

Agent Router 아키텍처

Agent Router는 Control Plane과 Data Plane을 분리합니다.

Control Plane

Control Plane은 “프록시가 어떻게 동작해야 하는가”를 설정합니다.

1. 사용자가 Kubernetes API에 AIGatewayRoute, AIServiceBackend 같은 리소스를 선언합니다.
2. Agent Router Controller가 AI 전용 리소스의 변경을 감시합니다.
3. Controller가 HTTPRoute와 HTTPRouteFilter, External Processor 설정과 Secret을 생성하거나 갱신합니다.
4. Envoy Gateway Controller가 Gateway API 리소스를 Envoy 설정으로 변환합니다.
5. Agent Router의 Extension Server가 모델 우선순위 같은 AI 전용 동작을 위해 xDS 설정을 보완합니다.
6. Envoy Gateway가 xDS로 실제 Envoy Proxy를 동적으로 설정합니다.

Envoy의 LDS, RDS, CDS, EDS 같은 xDS API를 모두 직접 작성하는 대신 Kubernetes의 고수준 리소스로 원하는 상태를 선언하는 구조입니다. Envoy Gateway는 일반적인 Gateway API, 서비스 디스커버리, 로드 밸런싱과 TLS를 담당하고, Agent Router Controller는 AI 전용 설정에 집중합니다.

주요 리소스의 역할은 다음과 같습니다.

이름이 Envoy AI Gateway에서 Agent Router로 바뀐 뒤에도 이 CRD와 aigateway.envoyproxy.io API 그룹은 그대로 유지됩니다.

Data Plane

Data Plane은 실제 요청 경로에 위치합니다. 핵심 구성 요소는 세 가지입니다.

Envoy Proxy

클라이언트 연결을 받고 HTTP 요청을 처리합니다. Route와 Cluster를 이용해 백엔드를 선택하고, 로드 밸런싱, TLS, timeout, retry, access log와 tracing을 수행합니다.

AI Gateway External Processor

Envoy Proxy Pod에 sidecar로 배치되는 AI 전용 처리기입니다. Envoy와 로컬 Unix Domain Socket으로 통신하므로 별도 네트워크 홉을 줄이고, 각 Envoy 인스턴스와 처리 상태를 함께 유지할 수 있습니다.

Rate Limit Service

요청 횟수와 토큰 사용량을 기준으로 정책을 평가합니다. External Processor가 응답에서 추출한 사용량을 Envoy의 동적 메타데이터로 남기면, 이후 quota와 rate limit 판단에 활용할 수 있습니다.

요청 하나가 처리되는 과정

요청 경로는 다음 순서로 이해할 수 있습니다.

1. 에이전트나 애플리케이션이 OpenAI 호환 API로 요청합니다.
2. Envoy가 경로, 헤더와 요청 본문의 모델 이름을 이용해 라우팅 후보를 계산합니다.
3. External Processor가 모델을 검증하고 공급자 형식에 맞게 경로·헤더·본문을 변환합니다.
4. 백엔드에 필요한 API key 또는 인증 토큰을 추가합니다.
5. Rate Limit Service가 요청 수와 토큰 budget 정책을 검사합니다.
6. Envoy가 선택한 외부 공급자나 자체 호스팅 모델 서버로 요청을 전달합니다.
7. External Processor가 스트리밍 또는 일반 응답을 공통 형식으로 변환하고 토큰 사용량을 추출합니다.
8. Envoy가 access log, metrics와 trace를 남기고 응답을 클라이언트에 돌려줍니다.

Agent Router는 router 단계와 upstream 단계에서 AI 처리를 나눠 수행합니다. Envoy의 retry와 failover는 Router filter 이후의 upstream 단계에서 일어나므로, 대체 공급자로 전환할 때는 그 공급자에 맞는 본문 변환과 인증을 다시 적용해야 하기 때문입니다.

Agent Router의 핵심 사용 사례

하나의 API로 여러 모델 공급자 사용하기

애플리케이션은 하나의 endpoint와 OpenAI 호환 형식만 사용합니다. 플랫폼 팀은 논리적 모델 이름을 실제 공급자 모델에 매핑하고, 필요하면 가중치나 우선순위에 따라 트래픽을 분배합니다. 애플리케이션 코드를 바꾸지 않고 공급자를 교체하거나 자체 호스팅 모델을 추가할 수 있습니다.

자격 증명을 애플리케이션에서 분리하기

공급자 API key를 각 애플리케이션 Pod에 배포하지 않고 Gateway 경계에서 관리합니다. 요청이 선택한 백엔드로 전달될 때만 적절한 인증 정보를 추가하므로, 자격 증명의 배포 범위와 교체 지점을 줄일 수 있습니다.

Token-aware Rate Limiting과 사용량 귀속

같은 요청 한 건이라도 100개 토큰을 생성하는 요청과 10,000개 토큰을 처리하는 요청의 비용은 다릅니다. Agent Router는 스트리밍·비스트리밍 응답의 토큰 사용량을 추적하고, 이를 이용해 토큰 budget과 quota를 적용할 수 있습니다. 모델, 사용자, 팀 또는 에이전트별 비용과 사용량을 공통 지점에서 기록하는 기반도 됩니다.

Provider Failover

주 공급자가 오류를 반환하거나 사용할 수 없을 때 다른 공급자 또는 모델로 전환할 수 있습니다. 단순히 목적지만 바꾸는 것이 아니라 대체 공급자의 API 형식과 인증에 맞게 요청을 다시 처리해야 하므로 External Processor가 upstream 단계에도 관여합니다.

MCP Gateway

에이전트는 모델 호출뿐 아니라 MCP 서버에서 도구를 찾고 실행합니다. Agent Router를 MCP의 공통 진입점으로 사용하면 어떤 사용자나 에이전트가 어느 MCP 서버와 도구를 발견하고 호출할 수 있는지 중앙에서 제어할 수 있습니다. 모델과 도구 트래픽을 같은 정책·관측성 경계에서 다룬다는 점이 AI Gateway보다 Agent Router라는 이름이 현재 범위를 더 잘 설명하는 이유이기도 합니다.

실행 형태

로컬에서 빠르게 확인하기

aigw CLI는 로컬에서 OpenAI 호환 Router를 실행할 수 있습니다.

OPENAI_API_KEY=sk-your-key aigw run

기본 endpoint는 http://localhost:1975/v1입니다. OpenAI 호환 클라이언트의 base URL만 이 주소로 바꾸면 공급자 자동 설정과 기본 라우팅을 빠르게 확인할 수 있습니다.

Kubernetes 운영 환경

운영 환경에서는 Agent Router가 Envoy Gateway 위의 Control Plane으로 동작하고, Envoy Proxy와 External Processor가 Data Plane을 구성합니다. 로컬에서 확인한 것과 같은 Agent Router 설정 모델을 Kubernetes 리소스로 옮겨 여러 Gateway와 팀에 적용할 수 있습니다.

Agent Router와 llm-d의 경계

Agent Router와 다음 글에서 다룰 llm-d는 모두 LLM 요청을 라우팅하지만 보는 범위가 다릅니다.

두 프로젝트는 경쟁 관계로만 볼 필요가 없습니다. 중앙 Agent Router가 인증, 최상위 라우팅과 전역 rate limit을 맡고, 자체 호스팅 모델 클러스터 앞의 두 번째 Gateway가 llm-d의 Endpoint Picker와 연결되어 세밀한 추론 라우팅을 수행하는 2계층 구조를 만들 수 있습니다.

마치며

Agent Router를 이해하기 위해 Envoy의 모든 기능과 Istio의 세부 설정을 먼저 익힐 필요는 없습니다. 핵심은 다음 흐름입니다.

Envoy의 L7 프록시와 필터 체인 → External Processing으로 AI 의미 해석 → Envoy Gateway와 xDS로 동적 설정 → Agent Router의 통합 모델·도구 정책

Envoy는 검증된 데이터 플레인으로 연결, 라우팅, 복원력과 관측성을 담당합니다. Agent Router는 그 위에 모델 이름, 공급자 API, 토큰, 자격 증명과 MCP 도구라는 AI 전용 의미를 더합니다. 애플리케이션은 모델과 도구를 사용하는 본연의 로직에 집중하고, 플랫폼 팀은 공통 Gateway에서 보안, 비용과 운영 정책을 일관되게 적용할 수 있습니다.

다음 글에서는 자체 호스팅 모델 서버 풀 안으로 들어가, llm-d가 KV 캐시와 워커 상태를 이용해 어떤 Endpoint로 요청을 보낼지 결정하는 과정을 살펴봅니다.

참고 자료

• Agent Router Overview
• Agent Router Architecture
• Agent Router Control Plane
• Agent Router Data Plane and Traffic Flow
• Agent Router API Reference
• Envoy AI Gateway is becoming Agent Router
• Envoy: What is Envoy
• Envoy: Life of a Request
• CNCF: Envoy Project Journey Report