AgentGateway란 무엇인가? 초보자와 전문가를 위한 AI-Native 게이트웨이 설명

AI 에이전트(AI agents)를 활용해 일주일 동안 개발하다 보면 저와 똑같은 벽에 부딪히게 됩니다. 에이전트, 모델, 또는 도구가 두 개 이상 관여하는 순간, 그 사이를 이동하는 트래픽을 실제로 관리하는 주체가 아무도 없다는 사실을 깨닫게 됩니다.

두 가지 프로토콜이 이 혼란을 해결하려 시도했습니다. MCP (Model Context Protocol)는 에이전트가 도구와 통신하는 방식을 표준화하며, 이를 도구를 위한 USB-C 포트라고 생각하면 됩니다. A2A (Agent-to-Agent)는 에이전트가 서로에게 작업을 넘겨주는 방식을 표준화합니다. 둘 다 진정으로 유용합니다. 문제는 이들이 메시지가 어떻게 extit{형성(shaped)} extit{되는지}만을 설명한다는 점입니다. 누가 무엇을 호출할 수 있는지, 비용이 얼마나 드는지, 또는 운영 환경(production)에서 이를 어떻게 디버깅할지에 대해서는 아무것도 말해주지 않습니다. 인증(authentication), 권한 부여(authorization), 지출 제어(spend control), 감사 추적(audit trail)이 전혀 없습니다.

AgentGateway는 그 간극을 메우는 계층입니다. 이 글은 시리즈의 첫 번째 포스트이므로, AgentGateway가 실제로 무엇인지, 작동하는 네 가지 모드, 그리고 어디에서나 마주치게 될 두 가지 전문 용어인 데이터 평면(data plane)과 제어 평면(control plane)에 대해 기본에 충실하게 설명하겠습니다.

요약 버전

AgentGateway는 여러분의 애플리케이션과 애플리케이션이 통신하는 모든 대상(LLM, 도구, 기타 에이전트) 사이에 위치하는 오픈 소스 기반의 Rust 프록시(proxy)로, 원시 프로토콜이 누락한 보안, 거버넌스(governance), 그리고 관찰 가능성(observability)을 추가합니다.

더 깊이 들어가기 전에 알아두어야 할 몇 가지 사항이 있습니다:

• Apache 2.0 라이선스 하의 오픈 소스이며, Rust로 작성되었습니다. 이는 매우 중요한데, 많은 에이전트 트래픽이 느린 프록시라면 과부하가 걸릴 수 있는 장기 연결(long-lived connections)을 기반으로 하기 때문입니다.

• Linux Foundation에서 호스팅하며, 최근 Agentic AI Foundation (AAIF)에 합류했습니다.

• MCP와 A2A를 네이티브로 지원하며, 일반적인 HTTP 및 gRPC도 처리합니다. 따라서 실제 인프라 옆에 붙어 있는 단순한

마지막 그 점이 바로 핵심적인 제안입니다. 두 개의 별개 시스템을 실행하고 보안을 유지하는 대신, AI 트래픽과 일반 API 트래픽을 위한 단 하나의 게이트웨이를 사용하는 것입니다.

네 가지 모드

AgentGateway를 이해하는 가장 쉬운 방법은 "세 가지 에이전트 패턴 (agentic patterns), 그리고 지루한 전통적인 패턴 (boring traditional one)"이라고 생각하는 것입니다. 하지만 작동하는 모습을 보기 전에, 이것이 없을 때의 삶이 어떤 모습인지 먼저 살펴보겠습니다.

게이트웨이가 없다면, 모든 앱은 모든 백엔드(backend)에 직접 연결됩니다. 각 앱은 자신만의 API 키, 인증 (auth), 재시도 로직 (retry logic), 로깅 (logging)을 개별적으로 가지고 있으며, 이 모든 것이 중복됩니다. 또한 무엇이 무엇을 호출하고 있는지에 대한 전체적인 관점을 어디에서도 가질 수 없습니다. _N_개의 앱과 _M_개의 백엔드가 있다면, 여러분은 스스로 N × M 형태의 엉킨 실타래를 만든 셈입니다:

[

]

AgentGateway는 그 망(mesh)을 관리되는 단일 출입구로 축소시킵니다. 동일한 프록시(proxy)와 동일한 정책(policies)을 사용하면서, 그 뒤에 네 가지 종류의 백엔드를 둡니다:

[

]

1. LLM 모드 (에이전트에서 LLM으로)

이것은 대부분의 팀이 가장 먼저 찾는 모드입니다. 앱을 하나의 OpenAI 호환 엔드포인트(endpoint)로 지정하면, AgentGateway가 그 뒤의 복잡한 작업을 처리합니다. 즉, 요청을 OpenAI, Anthropic, Gemini, Bedrock 또는 여러분이 자체 호스팅하는 모델 등으로 분산시키고, 그중 하나가 다운되었을 때 장애 조치 (failover)를 수행합니다.

로드 밸런싱은 라운드 로빈(round-robin)보다 똑똑합니다. **Power of Two Choices (P2C)**를 사용하는데, 두 개의 제공업체(provider)를 샘플링하여 지연 시간(latency)과 대기 부하(pending load) 측면에서 더 건강해 보이는 곳으로 요청을 보내므로, 어려움을 겪는 제공업체는 스스로 트래픽을 줄입니다. 게다가 사용자별, 팀별 또는 키별 토큰 기반 속도 제한(token-based rate limits)까지 얻을 수 있습니다. 이는 사람들이 '지갑 고갈(denial-of-wallet)'이라고 부르기 시작한 현상, 즉 당신이 자는 동안 예산을 소모하는 통제 불능의 에이전트 루프에 대한 방어책입니다.

여기에 OpenAI와 Gemini를 단일 라우트 뒤에 둔 최소한의 두 제공업체 구성(config)을 보여드립니다:

# yaml-language-server: $schema=https://agentgateway.dev/schema/config
binds:
-
  port: 3000
...

앱 코드는 절대 변경되지 않습니다. 그냥 일반적인 /chat/completions 엔드포인트를 계속 호출하며, 장애 조치(failover), 키 처리, 비용 할당은 모두 게이트웨이에서 이루어집니다.

2. MCP 모드 (에이전트 대 도구)

GitHub, 데이터베이스, 검색 API가 필요한 에이전트를 상상해 보세요. 당연한 방법은 이 세 가지 MCP 서버에 직접 연결하는 것입니다. 하지만 AgentGateway를 사용하면 하나의 MCP 엔드포인트와 통신하게 하고, 그 뒤에서 서버들을 연합(federate)시킬 수 있습니다.

보안상의 이점은 세션별 도구 필터링입니다. 특정 클라이언트는 자신이 사용할 수 있도록 허용된 도구만 볼 수 있으며, 여기서 RBAC(Role-Based Access Control)와 도구 오염 공격(tool-poisoning attacks) 방어책이 작동합니다.

# yaml-language-server: $schema=https://agentgateway.dev/schema/config
binds:
-
  port: 3000
...

게이트웨이를 운영해 본 적이 있는 사람이라면 주목할 만한 점이 있습니다. 바로 기존의 게이트웨이들이 실패하는 지점이 바로 여기이기 때문입니다. MCP는 상태 유지(stateful) 방식입니다. 클라이언트와 서버가 장기적인 세션(long-lived session)을 유지하며, 메시지는 양방향으로 이동하고, 단 한 번의 "도구 목록 조회(list tools)" 호출이 여러 백엔드로 확산(fan out)된 후 집계되어 돌아올 수 있습니다. AgentGateway는 각 세션을 특정 백엔드에 고정(pin)하고, 세션 상태를 Mcp-Session-Id(AES-256-GCM으로 암호화됨)에 담아 전달하므로, 모든 후속 호출이 동일한 서버로 전달되도록 합니다. 무상태(stateless) 요청/응답을 기반으로 설계된 게이트웨이는 이를 모델링할 수 없으며, 이것이 바로 많은 게이트웨이가 실제 MCP 트래픽을 마주하는 순간 무너지는 이유입니다.

3. A2A 모드 (agent to agent, 에이전트 간)

에이전트 A가 장기 실행 작업(long-running task)을 에이전트 B에게 넘깁니다. A2A는 해당 인계(handoff)의 형태를 정의하지만, 그에 따른 거버넌스(governance), 즉 누가 누구에게 위임할 수 있는지와 작업이 실행되는 동안 이를 어떻게 추적(trace)할지는 정의하지 않습니다. AgentGateway를 중간에 배치하면 해당 경계를 가로지르는 인증(authentication), 인가(authorization), 그리고 엔드 투 엔드 추적(end-to-end tracing)을 확보할 수 있습니다. 이 기능들은 공교롭게도 A2A가 전적으로 사용자에게 맡겨두는 부분들입니다.

4. HTTP/gRPC 모드 (통합된 부분)

사람들이 자주 잊어버리는 모드이며, 어쩌면 AgentGateway를 도입했을 때 보상을 얻을 수 있는 결정적인 이유이기도 합니다. 일반적인 REST 및 마이크로서비스(microservice) 트래픽이 기존에 설정해둔 것과 동일한 로드 밸런싱(load balancing), 타임아웃(timeouts), 재시도(retries), TLS, 인가(authorization)를 적용받으며 동일한 게이트웨이를 통해 실행됩니다. 심지어 기존의 REST API를 가져와 MCP 도구로 노출할 수도 있습니다. "실제" 게이트웨이 옆에 별도의 "AI 게이트웨이"를 구축할 필요가 없습니다. 하나의 프록시(proxy)와 하나의 정책 세트(policy set)로 두 가지를 모두 처리합니다.

데이터 평면(Data plane) vs. 제어 평면(Control plane)

이 두 용어는 모든 게이트웨이 및 서비스 메시(service-mesh) 문서에 등장하며, 사람들을 확실히 헷갈리게 만듭니다. 제가 마침내 이해하게 된 버전은 다음과 같습니다.

레스토랑을 상상해 보세요:

• 데이터 평면 (Data plane)은 홀 직원과 주방입니다. 이들은 모든 주문을 받고 모든 접시를 나르며, 각 테이블(각 요청)을 실시간으로 처리합니다.

• 제어 평면 (Control plane)은 사무실에 있는 매니저입니다. 이들은 직접 테이블에 서빙하지 않습니다. 대신 메뉴를 작성하고, 규칙을 설정하며, 각 서버가 담당할 구역을 결정하고, 오늘의 특선 메뉴를 업데이트한 다음, 그 모든 것을 홀로 전달합니다.

제품에 대입하면: AgentGateway 자체는 데이터 평면 (Data plane)이며, 라우팅 (Routing)부터 인증 (Auth), 속도 제한 (Rate limiting), 트레이싱 (Tracing)에 이르기까지 모든 요청에 대해 실시간 작업을 수행하는 Rust 프록시 (Proxy)입니다. 제어 평면 (Control plane)은 이러한 프록시들을 구성하는 모든 것을 의미합니다. AgentGateway는 다운타임 없이 xDS 인터페이스를 통해 설정을 동적으로 수락하며, Kubernetes Gateway API를 준수합니다. Kubernetes 환경에서 AgentGateway 프록시를 생성하고 관리하기 위해 권장되는 제어 평면은 kgateway입니다.

단 한 문장만 기억해야 한다면 이것입니다: 데이터 평면은 모든 요청을 실시간으로 처리하고 보안을 유지하며, 제어 평면은 규칙을 결정하고 이를 하위로 전달합니다. AgentGateway를 정적 config.yaml과 함께 단독으로 실행하거나 (위의 코드 스니펫이 바로 그것입니다), Kubernetes 내부에서 제어 평면이 이를 구동하도록 할 수 있습니다. 어떤 방식이든 내부의 프록시는 동일합니다.

주요 용어 정리

용어	여기서의 의미
MCP	Model Context Protocol. 에이전트가 도구와 데이터에 호출하는 방식. 상태 유지 (Stateful), JSON-RPC.
...

향후 방향

이것이 핵심 아이디어입니다. AgentGateway는 여러분의 에이전트, 모델, 도구, 그리고 일반 API에 대해 네 가지 모드 (LLM, MCP, A2A, HTTP/gRPC)로 작동하는 하나의 통제된 정문 (Front door)을 제공하며, 실제 작업을 수행하는 프록시와 규칙을 설정하는 제어 평면 사이의 깔끔한 분리를 실현합니다.

다음에는 직접 실습해 보겠습니다. 바이너리 (binary)를 설치하고, 위에서 설명한 LLM 설정을 실행한 뒤, 장애 조치 (failover)와 지출 한도 (spend limits)가 실제로 작동하는 것을 직접 확인해 보겠습니다. API 키를 몇 개 준비해 오세요.

추가 읽을거리

• AgentGateway 문서, 소개 (Introduction): https://agentgateway.dev/docs/standalone/main/about/introduction/

• 다중 LLM 제공업체 (P2C 로드 밸런싱 (load balancing)): https://agentgateway.dev/docs/standalone/main/llm/providers/multiple-llms/

• MCP 서버 연결 (스트리밍 가능한 HTTP (Streamable HTTP)): https://agentgateway.dev/docs/standalone/main/mcp/connect/http/

• GitHub: https://github.com/agentgateway/agentgateway

• Linux Foundation 발표: https://www.linuxfoundation.org/press/linux-foundation-welcomes-agentgateway-project-to-accelerate-ai-agent-adoption-while-maintaining-security-observability-and-governance