Envoy AI Gateway가 Agent Router로, AAIF 합류 후에도 CRD와 aigw CLI는 그대로

9bow · 9월 10, 2026, 7:30오전

Agent Router 소개

Agent Router는 애플리케이션과 에이전트가 하나의 OpenAI 호환 API로 모든 모델과 MCP(Model Context Protocol) 도구에 접근하게 해주는 오픈소스 컨트롤 플레인(Control Plane)이며, 실제 트래픽은 그 아래에서 Envoy가 처리합니다. 2026년 9월 9일, 이 프로젝트는 Envoy AI Gateway라는 기존 이름을 내려놓고 Agent Router로 개명하면서 Agentic AI Foundation(AAIF)의 프로젝트로 합류한다고 발표했습니다. 프로젝트 블로그가 적은 공식 합류일은 하루 뒤인 9월 10일입니다.

이 프로젝트의 출발점은 모델이 아니라 트래픽이었습니다. 2024년 여름 Bloomberg의 엔지니어들은 외부 모델과 자체 운영 모델에 연결하면서, 자신들이 마주한 문제가 모델의 문제가 아니라 업계가 이미 10년 동안 풀어 온 트래픽 문제라는 것을 알아차렸습니다. 프로바이더를 가로지르는 단일 API, 프로바이더 사이의 장애 전환(Failover), 토큰 집계와 속도 제한(Rate Limiting), 각 업스트림에 대한 인증이 필요했고, 이 목록을 Envoy 커뮤니티에 들고 갔습니다. 거기서 Envoy Proxy와 Envoy Gateway 양쪽에 메인테이너를 두고 있던 Tetrate가 합류하면서 두 회사의 공동 작업으로 시작됐습니다.

문제의 성격은 에이전트가 늘어날수록 더 분명해집니다. 하나의 작업을 수행하는 에이전트는 모델 호출과 도구 호출을 연달아 발생시키는데, 어떤 작업은 몇 번의 요청으로 끝나고 어떤 작업은 200번에 이릅니다. 응답은 몇 분씩 스트리밍되고, 프로바이더마다 요청 형식과 자격 증명(Credential)과 실패 모드가 제각각입니다. 도구 서버도 마찬가지여서 엔드포인트가 다르고 누가 무엇을 호출해도 되는지에 대한 기준도 다릅니다. 이 모든 것을 애플리케이션 코드가 떠안으면 프로바이더를 하나 추가할 때마다 통합 코드를 다시 써야 합니다.

Agent Router가 제안하는 답은 그 다섯 가지 질문을 코드에서 게이트웨이 설정으로 옮기는 것입니다. 플랫폼 팀이 프로바이더, 자격 증명, 할당량(Quota), 도구를 한 번 기술하면 Agent Router가 그 의도를 Envoy 설정으로 번역하고, Envoy가 모든 요청에 적용합니다. 애플리케이션이 아는 것은 엔드포인트 하나뿐입니다.

이 글은 같은 날 공개된 두 편의 글, 즉 AAIF 명의로 나온 공지 글과 프로젝트의 구조를 설명하는 기술 블로그를 함께 정리하고, 두 글이 언급만 하고 넘어간 저장소와 릴리즈 노트의 내용을 확인해 붙였습니다. 기술 블로그의 저자는 문서와 웹사이트, 커뮤니티를 맡고 있는 Erica Hughberg와 MCP 및 aigw CLI를 맡고 있는 Ignasi Barrera로, 둘 다 이 프로젝트의 메인테이너입니다.

이미 운영 중이라면: 이름과 거버넌스만 바뀌고 리소스는 그대로

이런 발표에서 기존 사용자가 가장 먼저 확인해야 할 것은 마이그레이션 여부입니다. 결론부터 적으면, 이번 개명은 배포된 것을 건드리지 않습니다. 저장소 README가 "어제 적용한 매니페스트가 내일도 적용됩니다" 라고 정리한 대로, 바뀌는 것은 프로젝트의 바깥 껍데기입니다.

구분	항목	상태
바뀜	프로젝트 이름	`Envoy AI Gateway` 에서 `Agent Router` 로
바뀜	거버넌스	CNCF 산하 Envoy 하위 프로젝트에서 AAIF 독립 프로젝트로
바뀜	커뮤니티 채팅	프로젝트 전용 Discord 서버로 이전 (주간 미팅은 그대로)
바뀜	저장소	`envoyproxy/ai-gateway` 에서 `theagentrouter/agent-router` 로 (기존 링크는 리다이렉트)
바뀜	웹사이트	`aigateway.envoyproxy.io` 에서 theagentrouter.ai 로 (동일 경로 리다이렉트)
그대로	커스텀 리소스 정의(CRD, Custom Resource Definition)와 API 그룹	`AIGatewayRoute`, `AIServiceBackend`, `BackendSecurityPolicy`, `aigateway.envoyproxy.io`
그대로	CLI와 네임스페이스	`aigw`, `envoy-ai-gateway-system`
그대로	컨테이너 이미지와 Helm 차트, Go 모듈 경로	`docker.io/envoyproxy/ai-gateway-*`, `github.com/envoyproxy/ai-gateway`
그대로	라이선스와 데이터 플레인(Data Plane)	Apache License 2.0, Envoy

공지 글은 저장소 이전을 "이 발표 이후에 진행된다" 고 예고했지만, 이 글을 쓰는 시점에는 이미 이전이 끝나 github.com/envoyproxy/ai-gateway 요청이 theagentrouter/agent-router 로 301 리다이렉트됩니다. 다만 이전 직후라 잔재도 남아 있습니다. 저장소의 MAINTAINERS.md는 여전히 "Envoy AI Gateway 프로젝트를 유지보수하는 사람들" 이라는 문장으로 시작합니다.

Envoy와의 관계가 끊어지는 것도 아닙니다. 데이터 플레인 문제는 계속 Envoy 자체에서 풀고, Agent Router는 AI 트래픽을 위해 Envoy를 관리하는 컨트롤 플레인 역할을 맡습니다. 기술 블로그는 이 관계가 한 방향이 아니라고 덧붙입니다. Agent Router 위에서 도는 에이전트 하나하나가 새로운 트래픽 패턴이자 새로운 실패 사례이고, 그중에 데이터 플레인이 아직 제공하지 못하는 것이 나오면 두 커뮤니티가 Envoy 쪽 개선을 함께 진행한다는 것입니다. 재단을 옮긴 이유는 프로젝트를 에이전트 생태계 가까이에 두어 MCP나 A2A 같은 프로토콜 프로젝트와 같은 지붕 아래에서 협업하기 위해서입니다.

에이전트가 신경 쓰지 않아도 되는 다섯 가지

기술 블로그의 뼈대는 "모든 에이전트 코드베이스가 어딘가에서 답하고 있는 다섯 가지 질문" 입니다. 어느 프로바이더 API로 말할 것인가, 키는 어디에 두는가, 호출이 실패하면 어떻게 되는가, 어떤 도구가 연결돼 있는가, 얼마나 쓰고 있는가. 이 다섯 가지의 답이 어떤 팀에서는 직접 짠 코드이고, 어떤 팀에서는 의존성이며, 어떤 팀에서는 빈칸입니다. Agent Router는 다섯 가지를 모두 게이트웨이 설정으로 옮깁니다.

프로바이더 API의 차이: 에이전트에게는 OpenAI 호환 엔드포인트 하나만 보입니다. Agent Router가 각 요청을 업스트림의 형식으로 번역하므로, 모델을 바꾸는 일이 모델 이름을 바꾸는 일이 됩니다. 이 동작은 모델 이름 가상화(Model Name Virtualization) 문서에 정리돼 있습니다.

프로바이더 자격 증명: 에이전트가 인증하는 대상은 게이트웨이뿐입니다. 프로바이더 API 키와 수명이 짧은 클라우드 자격 증명은 Agent Router에 남고, 게이트웨이가 에이전트를 대신해 업스트림에 인증합니다 (업스트림 인증).

장애 전환 전략: 에이전트는 요청 하나를 보내고 응답 하나를 받습니다. 그 뒤에서 Agent Router가 실패한 호출을 다음 프로바이더로, 그 프로바이더의 형식과 자격 증명으로 재시도합니다 (프로바이더 폴백).

MCP 서버 다중화(Multiplexing): 에이전트가 받는 것은 자기 크기에 맞춰 재단된 도구 카탈로그 하나입니다. Agent Router가 여러 MCP 서버에서 고른 도구로 카탈로그를 구성하고, 도구 목록을 조회할 때와 실제로 호출할 때 두 번에 걸쳐 신원 기준으로 걸러냅니다. 고객 지원 에이전트가 작은 카탈로그를 받으면 컨텍스트가 작게 유지되고 엉뚱한 도구를 부르는 일이 줄어듭니다 (MCP 가이드).

요청 수를 넘어서는 사용량 제어: 에이전트는 토큰을 세지 않습니다. Agent Router가 세고, 팀이나 애플리케이션, 모델 단위로 입력 토큰과 출력 토큰, 총 토큰에 제한을 겁니다 (사용량 기반 속도 제한).

원문은 이 구도를 Unix에 빗대어 설명합니다. 개인용 컴퓨터를 보급시킨 것은 Unix를 다루는 터미널이 아니라 다른 사용자층을 위해 만들어진 다른 인터페이스였고, 그렇다고 아래에 깔린 운영체제가 덜 강력해지지는 않았다는 것입니다. 강력함과 쓰기 좋음은 같은 말도 아니지만 서로 배타적이지도 않으며, Envoy가 트래픽 처리에서 지금 그 지점에 있고 Agent Router는 그 위에 얹는 설정 인터페이스라는 주장입니다.

노트북에서 한 줄로 시작해 같은 설정으로 클러스터까지

시작하는 방법은 명령 한 줄입니다. aigw run은 Envoy 데이터 플레인을 포함한 게이트웨이를 로컬에서 띄우고, 에이전트 쪽에서 바꿀 것은 환경 변수 하나입니다.

# 1 - 라우터를 로컬에서 실행
OPENAI_API_KEY=sk-your-key aigw run

# 2 - 에이전트가 바꿔야 하는 유일한 값
export OPENAI_BASE_URL=http://localhost:1975/v1

OPENAI_BASE_URL을 읽는 클라이언트라면 그대로 붙고, MCP 클라이언트는 게이트웨이의 MCP 엔드포인트로 연결합니다. aigw run은 Claude Desktop이나 Cursor, VS Code가 이미 쓰고 있는 mcpServers 파일을 그대로 받습니다.

# MCP 도구를 함께 붙이기
aigw run --mcp-config mcp-servers.json

CLI의 자동 설정은 OpenAI SDK와 같은 환경 변수를 읽습니다. 저장소의 cmd/aigw/main.go를 보면 설정 파일 경로 인자는 OPENAI_API_KEY, AZURE_OPENAI_API_KEY, ANTHROPIC_API_KEY 중 하나만 설정돼 있어도 생략할 수 있게 돼 있고, --mcp-config 외에 JSON 문자열을 직접 넘기는 --mcp-json도 있습니다. 게이트웨이는 localhost:1975에서 응답하므로 곧바로 호출해 볼 수 있습니다.

curl -H "Content-Type: application/json" -XPOST http://localhost:1975/v1/chat/completions \
  -d '{"model": "qwen2.5:0.5b","messages": [{"role": "user", "content": "Say this is a test!"}]}'

Ollama를 로컬에서 실행 중이라면 OPENAI_BASE_URL=http://localhost:11434/v1 OPENAI_API_KEY=unused aigw run 으로 연결하고, 같은 방식으로 Azure OpenAI나 Tetrate Agent Router Service를 업스트림으로 지정할 수 있습니다. 로컬에서 쓴 설정 파일은 전용 게이트웨이나 쿠버네티스 클러스터에 그대로 올라가고, 달라지는 것은 포장 방식뿐이라는 것이 프로젝트의 설명입니다.

여기에 한 가지 단서를 붙여 둘 필요가 있습니다. 두 편의 블로그가 모두 "명령 한 줄" 을 앞세우지만, 공식 문서의 CLI 페이지는 aigw CLI를 아직 실험적(experimental)이며 활발히 개발 중이라고 표시하고 있고, aigw run은 현재 Linux와 macOS에서만 동작합니다. 프로젝트가 안정성을 보장하는 것은 CLI가 아니라 컨트롤 플레인 API입니다.

모델 라우팅 위에 얹은 MCP 게이트웨이

Agent Router가 다른 LLM 게이트웨이와 갈라지는 지점은 MCP를 LLM 트래픽과 같은 층에서 다룬다는 것입니다. MCPRoute 리소스로 여러 MCP 서버를 하나의 엔드포인트로 모으고, 그 위에 인증과 도구 필터링을 겁니다.

apiVersion: aigateway.envoyproxy.io/v1beta1
kind: MCPRoute
metadata:
  name: mcp-route
  namespace: default
spec:
  parentRefs:
    - name: aigw-run
      kind: Gateway
      group: gateway.networking.k8s.io
  path: "/mcp" # Clients connect to http://gateway-address/mcp
  backendRefs:
    - name: github
      kind: Backend
      group: gateway.envoyproxy.io
      path: "/mcp/x/issues/readonly"
      securityPolicy:
        apiKey:
          secretRef:
            name: github-token

여러 서버를 묶으면 도구 이름 앞에 백엔드 이름이 붙어 github__issue_read, context7__query-docs 처럼 노출되고, 게이트웨이는 이 접두사로 호출을 올바른 업스트림에 보냅니다. 어떤 도구를 노출할지는 toolSelector로 고릅니다. 정규식으로 묶어 잡거나 이름을 하나씩 지정할 수 있습니다.

  backendRefs:
    # GitHub: only expose issue-related tools
    - name: github
      kind: Backend
      group: gateway.envoyproxy.io
      path: "/mcp/x/issues/readonly"
      toolSelector:
        includeRegex:
          - .*issues?.* # Matches issue_read, list_issues, etc.
      securityPolicy:
        apiKey:
          secretRef:
            name: github-token

    # Context7: expose specific tools by exact name
    - name: context7
      kind: Backend
      group: gateway.envoyproxy.io
      path: "/mcp"
      toolSelector:
        include:
          - resolve-library-id
          - query-docs

도구를 걸러내는 일이 왜 게이트웨이의 몫인지는 컨텍스트 예산으로 설명됩니다. MCP 서버를 여러 개 붙이면 도구 정의가 그대로 시스템 프롬프트에 쌓이고, 에이전트는 쓰지도 않을 도구 수십 개의 스키마를 매 턴 읽게 됩니다. 서버 쪽에서 카탈로그를 재단하면 클라이언트를 고치지 않고도 각 에이전트가 필요한 만큼만 보게 됩니다.

인증도 같은 층에서 처리합니다. MCP 명세의 권한 부여 흐름에 따른 OAuth를 securityPolicy.oauth로 걸 수 있고, JWT(JSON Web Token)의 스코프와 클레임, CEL(Common Expression Language) 표현식으로 도구 접근을 세분화합니다. OAuth 인프라를 세우기 전이라면 클라이언트 요청의 특정 헤더만 골라 백엔드로 넘기는 forwardHeaders로 사용자별 개인 토큰을 통과시키는 방법도 있습니다. 전송 방식은 2025년 6월 MCP 명세의 Streamable HTTP를 지원하며, 여러 MCP 서버에서 오는 SSE(Server-Sent Events) 스트림을 하나로 합쳐 클라이언트에 전달합니다.

프로바이더가 죽었을 때 무슨 일이 일어나는가

장애 전환은 AIGatewayRoute의 backendRefs에 우선순위를 매기는 것으로 표현합니다. 첫 번째 백엔드가 기본이고 뒤따르는 백엔드가 폴백이며, 실제 전환을 유발하는 조건은 BackendTrafficPolicy의 재시도 정책이 정합니다.

apiVersion: aigateway.envoyproxy.io/v1beta1
kind: AIGatewayRoute
metadata:
  name: provider-fallback
  namespace: default
spec:
  parentRefs:
    - name: provider-fallback
      kind: Gateway
      group: gateway.networking.k8s.io
  rules:
    - matches:
        - headers:
            - type: Exact
              name: x-ai-eg-model
              value: us.meta.llama3-2-1b-instruct-v1:0
      backendRefs:
        - name: provider-fallback-always-failing-upstream # Primary backend (expected to fail)
          priority: 0
        - name: provider-fallback-aws # Fallback backend
          priority: 1

재시도 정책에서 눈여겨볼 값은 numAttemptsPerPriority입니다. 이 값을 1로 두면 같은 우선순위에서 재시도하지 않고 곧바로 다음 프로바이더로 넘어갑니다. 죽은 프로바이더에 같은 요청을 반복해 보내며 시간을 쓰지 않습니다.

  retry:
    # This ensures that only one attempt is made per priority.
    numAttemptsPerPriority: 1
    numRetries: 5
    perRetry:
      backOff:
        baseInterval: 100ms
        maxInterval: 10s
      timeout: 30s
    retryOn:
      httpStatusCodes:
        - 500
      triggers:
        - connect-failure
        - retriable-status-codes

그 아래에서 동작하는 것들은 Agent Router가 새로 만든 기능이 아닙니다. 타임아웃, 재시도, 상태 검사(Health Check), 이상 감지(Outlier Detection), 회로 차단기(Circuit Breaker)는 Envoy가 대규모 운영 환경의 요구로 이미 갖춘 기능이고, 에이전트 트래픽은 그 처리를 그대로 물려받습니다. 응답이 멈춘 프로바이더는 감지돼 우회되고, 동시에 몰린 작업 무리는 백엔드를 무너뜨리는 대신 연결 상한에 걸립니다. 보안 측면에서도 Envoy는 CNCF(Cloud Native Computing Foundation) 졸업 프로젝트로 위협 모델을 문서로 두고 있고, Google Patch Reward Program을 통한 버그 바운티도 운영합니다.

관측(Observability) 역시 에이전트 코드에 계측을 넣지 않고 얻습니다. 모든 모델 호출과 도구 호출이 게이트웨이를 지나므로 어떤 모델이 답했는지, 토큰을 몇 개 썼는지, 첫 토큰까지 얼마가 걸렸는지, 어디서 폴백이 발동했는지, 어떤 도구가 불렸는지가 로그와 트레이스에 남습니다. 원문은 이 효용을 "200건 중 1건이 잘못됐을 때 트레이스가 그게 어느 건인지 보여준다" 로 표현합니다. 신호는 OpenTelemetry의 GenAI 시맨틱 규약을 따르므로 이미 운영 중인 도구로 흘러갑니다.

게이트웨이가 못 하는 일이 필요해지는 순간을 위한 통로도 열려 있습니다. 원문이 든 예는 특정 테넌트에만 적용할 헤더 재작성, 사내 승인 서비스 호출, 프롬프트가 프로바이더에 닿기 전에 민감 정보를 지우는 단계, 도구 호출 인자에 대한 자체 검사입니다. Agent Router의 라우트는 Envoy 라우트이므로 Envoy Gateway의 확장 기능을 그대로 씁니다. 작은 변경은 Lua로, Rust나 Go로 작성한 동적 모듈로, 그리고 그 로직이 이미 운영 중인 서비스에 속한다면 외부 프로세서로 붙입니다. 클라이언트 인증도 같은 방식이어서 JWT 검증이든 OIDC(OpenID Connect) 흐름이든 자체 인가 서비스 호출이든 동일한 지점에 걸립니다. 트래픽을 처리하는 그 메커니즘이 사용자 정의 단계도 실행하므로, 유지보수할 시스템이 하나 더 늘지 않는다는 것이 원문의 설명입니다.

자체 운영 모델도 같은 층에서 다룹니다. Agent Router는 Gateway API와 Gateway API Inference Extension 위에 올라가 있어, InferencePool을 대상으로 실시간 지표에 따라 엔드포인트를 고르는 추론(Inference) 최적화 기능을 제공합니다 (문서). 호스팅 프로바이더와 자체 서빙 클러스터를 같은 라우팅 규칙 아래 두고 싶을 때 쓰는 경로입니다.

성숙한 소프트웨어라는 주장을 뒷받침하는 것: 1.0과 1.1

공지 글은 Agent Router가 "성숙한 소프트웨어로 AAIF에 도착한다" 고 표현합니다. 이 표현의 근거는 릴리즈 이력에 있습니다.

v1.0.0은 2026년 6월 23일에 정식 출시(General Availability)됐고, 이 릴리즈에서 AIGatewayRoute, AIServiceBackend, BackendSecurityPolicy, GatewayConfig, MCPRoute 다섯 개 CRD가 v1beta1에서 안정 API로 선언됐습니다. 1.x 계열 안에서는 치명적 보안 문제가 아닌 한 호환성을 깨지 않고, 불가피한 경우에도 마이그레이션 경로를 릴리즈 노트에 함께 싣겠다는 약속입니다. 이 시점에 프로바이더는 16개였습니다. OpenAI, Azure OpenAI, Google Gemini, Vertex AI, AWS Bedrock, Anthropic, Mistral, Cohere, Groq, Together AI, DeepInfra, DeepSeek, Hunyuan, SambaNova, Grok, 그리고 Tetrate Agent Router Service입니다.

v1.1.0은 8월 21일에 나왔고, 안정 API 위에 올라온 첫 마이너 릴리즈입니다. 주요 변경은 다음과 같습니다.

프로바이더를 가로지르는 토큰 계산: vLLM의 /tokenize 요청 형식을 vLLM과 Vertex AI Gemini, GCP Anthropic, AWS Bedrock Converse, AWS Anthropic에 대해 지원합니다. 생성 없이 프롬프트의 토큰 수만 세는 용도이며, Anthropic 네이티브 클라이언트는 /anthropic/v1/messages/count_tokens를 쓸 수 있습니다.
요청 단위 업스트림 자격 증명: credentialOverride로 정적 키 하나를 공유하는 대신 신뢰된 필터가 요청마다 백엔드 자격 증명을 공급합니다. API 키와 Anthropic, Azure, GCP, AWS SigV4를 지원합니다.
스트림 유휴 타임아웃과 폴백 연동: streamIdleTimeout이 스트리밍 응답에서 업스트림 바이트가 오지 않는 시간을 제한합니다. 첫 토큰 전에 발동하면 재시도 정책이 다음 백엔드로 넘길 수 있고, 스트림 중간이면 504를 반환합니다.
MCP 호스트명 라우팅과 백엔드 선택: MCPRoute.spec.hostnames로 MCP 엔드포인트를 특정 호스트에 한정하고, backendSelector가 초기화 시점에 평가되는 CEL 규칙으로 세션이 접근할 백엔드를 제한합니다. 기본값은 거부입니다.
OpenTelemetry GenAI 규약과 대시보드: ext-proc에 AI_GATEWAY_TRACING_SEMCONV=gen_ai를 설정하면 gen_ai.* 스팬 속성을 내보내고, gen_ai_* 지표용 Grafana 대시보드 예제가 저장소에 포함됩니다.
HTTP CONNECT 포워드 프록시: GatewayConfig.spec.forwardProxy로 업스트림 LLM 연결을 HTTP CONNECT 프록시로 터널링합니다. PrivateLink를 통한 Bedrock 요청이 실제 업스트림 호스트로 서명되도록 고쳐, VPC 엔드포인트가 조용히 403으로 실패하던 문제가 해소됐습니다.

v1.0에서 v1.1로 올릴 때 CRD 마이그레이션은 필요 없고, 운영자가 알아야 할 변경은 Helm의 컨트롤러 보안 컨텍스트가 제한된 것 하나뿐입니다.

누가 만들고 누가 쓰고 있는가

공지 글이 제시한 숫자는 다음과 같습니다. 개발은 2024년 10월에 공개적으로 시작됐고 첫 릴리즈는 2025년 2월이었습니다. 저장소에서 확인하면 v0.1.0이 2025년 2월 25일에 나왔고, 프리릴리즈를 뺀 안정 릴리즈는 정확히 15개입니다. 현재 공개적으로 이름을 올린 채택 기업이 11곳, 메인테이너 자리가 9석, 기여자가 21개 조직에서 132명, 안정 릴리즈가 15회입니다. 메인테이너 9석은 Bloomberg, Nutanix, AMD, Tetrate, Netflix가 나눠 갖고 있어 어느 회사도 과반을 차지하지 않습니다.

저장소에서 확인되는 값은 대체로 이 숫자와 맞습니다. 저장소 생성일은 2024년 10월 21일이고, 이 글을 쓰는 시점의 GitHub 기여자 목록은 141명으로 공지 글의 132명보다 조금 늘어 있습니다. MAINTAINERS.md에 이름을 올린 메인테이너는 정확히 9명이며, Envoy Proxy 메인테이너와 KServe 메인테이너, Envoy Gateway 메인테이너, Kubeflow 운영위원이 섞여 있습니다.

프로젝트 홈페이지의 채택 기업 목록에는 Bloomberg, Tetrate, Tencent Cloud, Nutanix, LY Corporation, National Research Platform, Stacklok, Simplifai, Unwrap, Paper Compute, Alan by Comma Soft가 올라와 있습니다. 이 가운데 LY Corporation은 네이버와 소프트뱅크가 절반씩 출자한 A홀딩스를 모회사로 두고 LINE과 야후 재팬을 운영하는 회사여서, 국내 독자에게는 이 게이트웨이가 어느 규모의 서비스에서 쓰이고 있는지 가늠하는 참고점이 됩니다.

두 창립 주체의 발언도 공지 글에 실렸습니다. Varun Talwar는 이어지는 문장에서 에이전트 SDK와 코딩 에이전트, 모델 제공자, MCP와 도구 제공자, 가드레일 엔진, 관측 플랫폼과 함께 일하고 싶다는 협업 대상을 구체적으로 나열했습니다.

"열린 에이전틱 생태계를 만들려면 개발자에게 선택권을 주고 조직에는 자신이 배포한 것에 대한 확신을 주는 공유 인프라가 필요합니다. Agent Router는 자리 잡은 커뮤니티와 프로덕션 사용에 대한 약속으로 그 기반에 기여합니다. AAIF는 그 커뮤니티가 프로젝트와 회사를 가로질러 일하면서 인프라가 더 넓은 생태계의 필요에 맞춰 진화하도록 보장할 수 있는 중립적인 터전을 제공합니다."

"Building an open agentic ecosystem requires shared infrastructure that gives developers choice and organizations confidence in what they deploy. Agent Router contributes to that foundation, with an established community and a commitment to production use. AAIF provides a neutral home where that community can work across projects and companies to ensure the infrastructure evolves with the needs of the broader ecosystem." (Manik Surtani, AAIF 공동 창립자 겸 CTO)

"에이전트를 만드는 사람들이 검증된 AI 트래픽 계층을 쓸 수 있도록, Envoy로 구동되는 Agent Router를 AAIF에 가져오게 되어 기쁩니다."

"I am excited to bring Agent Router, powered by Envoy, to AAIF to enable agent builders to work with a proven traffic layer for AI." (Varun Talwar, Tetrate 공동 창립자 겸 CTO)

한 가지 구분해 둘 것이 있습니다. Tetrate는 이 오픈소스 프로젝트의 공동 개발사이면서, 동시에 Tetrate Agent Router Service라는 이름의 상용 서비스도 운영합니다. 이름이 비슷하지만 별개이며, 상용 서비스는 Agent Router가 라우팅할 수 있는 16개 프로바이더 중 하나로도 등록돼 있습니다.

AAIF 안에서 겹치는 게이트웨이들

이번 합류로 AAIF가 호스팅하는 프로젝트는 MCP, goose, AGENTS.md, agentgateway, A2A, 그리고 Agent Router까지 여섯 개가 됐습니다. 프로토콜(MCP, A2A, AGENTS.md)과 에이전트 구현체(goose), 인프라(agentgateway, Agent Router)가 한 재단 아래 모인 구성입니다.

여기서 자연스럽게 떠오르는 질문은 같은 재단에 에이전트용 게이트웨이가 왜 둘이냐는 것입니다. PyTorchKR에서도 이미 다룬 agentgateway는 프록시 자체를 Rust로 새로 구현하고 쿠버네티스 컨트롤러까지 함께 제공하는 프로젝트로, LLM 게이트웨이와 MCP 게이트웨이에 더해 A2A 게이트웨이와 가드레일까지 범위에 넣고 있습니다. Agent Router는 반대로 데이터 플레인을 새로 만들지 않고 Envoy에 위임한 뒤 컨트롤 플레인만 담당합니다. 겹치는 영역은 적지 않아서, 자체 서빙 모델에 대한 추론 인식 라우팅은 양쪽 모두가 내세우는 기능입니다.

다만 재단이 두 프로젝트를 같은 자리에 놓고 있지는 않습니다. AAIF 기술 위원회(Technical Committee) 저장소의 프로젝트 표를 보면 MCP와 goose, AGENTS.md가 Impact 단계, agentgateway와 A2A가 Growth 단계로 올라 있고, 이 글을 쓰는 시점에 Agent Router는 아직 표에 반영되지 않았습니다. 공지 글이 언급한 "프로젝트를 가로지르는 협업 기회" 가 실제로 어떻게 전개될지는 지켜볼 부분입니다.

더 가벼운 선택지도 있습니다. 개인 개발 환경에서 여러 프로바이더를 하나의 엔드포인트로 묶는 것이 목적이라면 OmniRoute 같은 로컬 게이트웨이가, 코딩 하네스를 자체 호스팅하는 것이 목적이라면 HarnessRouter가 더 맞을 수 있습니다. Agent Router는 쿠버네티스와 Envoy 운영을 전제로 한 플랫폼 팀 쪽에 무게가 실려 있습니다.

정리하며

이번 발표에서 실제로 달라지는 것은 프로젝트의 이름과 소속이고, 배포된 리소스는 그대로입니다. 이미 Envoy AI Gateway를 운영 중이라면 지금 할 일은 마이그레이션이 아니라 북마크와 문서 링크를 theagentrouter.ai로 옮기는 것, 그리고 사내 문서에 적힌 저장소 주소를 새 조직으로 바꾸는 것 정도입니다. 컨테이너 이미지와 Helm 차트, Go 모듈 경로가 그대로이므로 CI 설정은 건드릴 필요가 없습니다.

아직 도입 전이라면 판단 기준은 조금 다릅니다. 프로바이더 두세 곳을 코드에서 직접 호출하는 정도라면 게이트웨이 한 겹을 더 얹을 이유가 크지 않습니다. 반면 여러 팀이 각자의 키로 각자의 모델을 부르고 있고, 누가 얼마를 쓰는지 집계가 필요하며, MCP 서버가 늘어나면서 에이전트마다 다른 도구 조합을 줘야 하는 상황이라면 이 문제들이 이미 게이트웨이의 문제입니다. 그때 Envoy를 데이터 플레인으로 쓴다는 선택은 새 프록시를 하나 더 운영하지 않아도 된다는 실질적인 이점이 됩니다.

프로젝트가 스스로 다음 과제로 꼽은 것도 기능이 아니라 사용성입니다. 기존 에이전트를 붙이는 일, 트래픽 정책을 표현하는 일, 설정 오류를 이해하는 일에 프록시 내부 지식이 지금보다 덜 필요해야 한다는 것입니다. 기여를 시작하는 통로로는 매주 월요일에 열리는 공개 커뮤니티 미팅과 Discord가 안내돼 있고, 재현 가능한 실패 사례를 들고 오는 것을 가장 유용한 기여로 꼽고 있습니다.

라이선스

Agent Router는 Apache License 2.0으로 배포되고 있어, 연구 목적은 물론 상업적 용도로도 자유롭게 사용 및 수정이 가능합니다. 개명과 재단 이전 이후에도 라이선스는 변경되지 않았습니다.

Envoy AI Gateway becomes Agent Router and joins AAIF 공지 블로그

Agent Router: Powerful traffic handling for agent builders 기술 블로그

Agent Router 프로젝트 홈페이지

Agent Router GitHub 저장소

Agent Router 공식 문서

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~