에이전트 AI 시대를 위한 Envoy 네트워킹의 필요성

* 본 아티클의 원문은 2026년 4월 4일 Google Cloud 블로그(영문)에 게재되었습니다.

오늘날의 에이전트 중심 AI(Agentic AI) 환경에서 네트워크는 새로운 책임을 맡게 되었습니다.

전통적인 애플리케이션 스택에서 네트워크는 주로 서비스 간에 요청을 이동시키는 역할을 했습니다. 하지만 최근 백서인 에이전트 네이티브 시대의 클라우드 인프라에서 논의된 것처럼, 에이전틱 시스템에서 네트워크는 모델 호출, 도구(tool) 호출, 에이전트 간 상호작용, 그리고 에이전트가 수행할 수 있는 작업을 결정하는 정책 결정의 중심에 위치합니다. 다양한 프레임워크로 구축된 에이전트가 급격히 확산됨에 따라, 대규모 환경에서도 모든 에이전틱 경로에 걸쳐 거버넌스와 보안을 일관되게 적용해야 할 필요성이 커졌습니다. 이를 달성하려면 적용 계층(enforcement layer)이 애플리케이션 수준에서 기반이 되는 인프라 수준으로 이동해야 합니다. 이러한 변화는 네트워크가 더 이상 단순한 '블라인드 전송 계층'으로 작동할 수 없음을 의미합니다. 네트워크는 더 많이 이해하고, 더 잘 적용하며, 더 빠르게 적응해야 합니다. 이러한 변화가 바로 Envoy가 필요한 이유입니다.

고성능 분산 프록시이자 범용 데이터 평면(universal data plane)인 Envoy는 대규모 환경을 위해 구축되었습니다. Google Cloud를 포함하여 까다로운 엔터프라이즈 환경에서 신뢰받는 Envoy는 단일 서비스 배포부터 Ingress, Egress, Sidecar 패턴을 사용하는 복잡한 서비스 메시에 이르기까지 모든 것을 지원합니다. 뛰어난 확장성, 강력한 정책 통합 및 운영 성숙도 덕분에 Envoy는 프로토콜의 급격한 진화와 통제 상실에 따른 리스크가 커진 오늘날, 변화를 유연하게 수용하면서도 강력한 거버넌스를 유지할 수 있는 가장 실용적이고 이상적인 솔루션입니다. 에이전틱 AI를 구축하는 팀에게 Envoy는 단순한 개념 그 이상이며, 실용적이고 운영 환경에 바로 적용할 수 있는 기반입니다.

에이전틱 워크로드의 특징과 과제

에이전틱 워크로드는 여전히 전송을 위해 HTTP를 자주 사용하지만, 전통적인 HTTP 중개자가 의존하는 몇 가지 가정을 깨뜨립니다. Model Context Protocol (MCP) 및 Agent2agent (A2A)와 같은 프로토콜은 HTTP를 통한 JSON-RPC 또는 gRPC를 사용하며, 표준 HTTP 요청/응답 의미 체계 위에 클라이언트와 서버가 기능을 교환하는 MCP 초기화와 같은 프로토콜 수준의 단계를 추가합니다. 중개자가 적응해야 하는 에이전틱 시스템의 주요 측면은 다음과 같습니다.

1. 다양한 엔터프라이즈 거버넌스 명령: 주된 과제는 안전, 보안, 데이터 프라이버시 및 규제 준수에 대한 광범위한 비협상적 기업 요구 사항을 충족하는 것입니다. 이러한 요구 사항은 종종 표준 네트워크 정책을 넘어서며, 내부 시스템과의 깊은 통합, 맞춤형 로직, 새로운 조직 규칙이나 외부 규정에 빠르게 적응하는 능력을 요구합니다. 이를 위해서는 기업이 특정 거버넌스 모델을 연결할 수 있는 확장성이 뛰어난 프레임워크가 필요합니다.

1. 정책 속성이 헤더가 아닌 메시지 본문(body)에 위치: 경로 및 헤더와 같은 정책 입력에 쉽게 액세스할 수 있는 기존 웹 트래픽과 달리, 에이전틱 프로토콜은 JSON-RPC 또는 gRPC 페이로드 깊숙이 중요한 속성(예: 모델 이름, 도구 호출, 리소스 ID)을 묻어두는 경우가 많습니다. 이러한 변화로 인해 중개자는 컨텍스트를 고려한 정책을 적용하기 위해 메시지 콘텐츠를 파싱하고 이해하는 능력을 갖춰야 합니다.

1. 다양하고 진화하는 프로토콜 특성 처리: 에이전틱 프로토콜은 균일하지 않습니다. Streamable HTTP를 사용하는 MCP와 같은 일부 프로토콜은 분산 프록시 간에 세션 관리가 필요한 상태 저장(stateful) 상호작용을 도입할 수 있습니다(예: Mcp-Session-Id 사용). 이러한 다양한 동작을 지원하고 미래의 프로토콜 혁신에 대응해야 할 필요성은 본질적으로 적응 가능하고 확장 가능한 네트워킹 기반의 필요성을 강화합니다.

이러한 요소들은 기업에 단순한 연결성 그 이상이 필요함을 의미합니다. 네트워크는 이제 앞서 언급한 중요한 거버넌스 요구 사항을 적용하기 위한 중심점 역할을 해야 합니다. 여기에는 프로토콜과 에이전트 동작의 급격한 진화에 발맞추면서 중앙 집중식 보안, 포괄적인 감사 가능성, 세부적인 정책 적용, 동적 가드레일과 같은 기능을 제공하는 것이 포함됩니다. 간단히 말해, 에이전틱 AI는 네트워크를 단순한 전송 경로에서 중요한 제어 지점으로 변환합니다.

Envoy가 적합한 3가지 이유

Envoy는 다음 세 가지 이유로 에이전틱 AI 네트워킹에 강력하게 부합합니다.

• 검증됨 (Battle-tested): 기업은 이미 대규모 보안에 민감한 환경에서 Envoy에 의존하고 있으므로 차세대 트래픽 관리 및 정책 적용을 고정할 수 있는 신뢰할 수 있는 플랫폼입니다.

• 확장 가능 (Extensible): Envoy는 네이티브 필터, Rust 모듈, WebAssembly(Wasm) 모듈 및 외부 처리(external processing) 패턴을 통해 확장될 수 있습니다. 이를 통해 플랫폼 팀은 생태계가 바뀔 때마다 네트워킹 계층을 다시 빌드할 필요 없이 새로운 프로토콜을 채택할 수 있습니다.

• 바로 운영에 유용함 (Operationally useful today): Envoy는 이미 게이트웨이, 적용 지점, 관찰 가능성 계층 및 제어 평면의 통합 표면 역할을 합니다. 따라서 표준이 정착될 때까지 기다리지 않고 지금 바로 움직여야 하는 조직에 실용적인 선택입니다.

이러한 핵심 강점을 바탕으로 Envoy는 에이전틱 네트워킹의 고유한 요구 사항을 충족하기 위해 특정 아키텍처 발전을 도입했습니다.

1. Envoy는 에이전트 트래픽을 이해합니다.

에이전틱 네트워킹의 첫 번째 요구 사항은 간단합니다. 게이트웨이가 에이전트가 실제로 수행하려는 작업을 이해해야 한다는 것입니다.

하지만 이는 말처럼 쉽지 않습니다. MCP, A2A 및 OpenAI 스타일의 API와 같은 프로토콜에서는 중요한 정책 신호가 요청 본문(body) 내에 있을 수 있습니다. 기존 HTTP 프록시는 본문을 불투명한 바이트 스트림으로 처리하도록 최적화되어 있습니다. 이 설계는 효율적이지만 프록시가 적용할 수 있는 범위를 제한합니다. JSON 메시지를 사용하는 프로토콜의 경우, 프록시는 정책 적용에 필요한 속성 값을 찾기 위해 전체 요청 본문을 버퍼링해야 할 수 있습니다. 특히 해당 속성이 JSON 메시지의 끝에 나타나는 경우 더욱 그렇습니다. 소비된 토큰을 기반으로 하는 속도 제한(rate limiting)과 같은 생성형 AI 프로토콜 고유의 비즈니스 로직도 서버 응답 파싱을 요구할 수 있습니다.

Envoy는 HTTP를 통해 전달되는 프로토콜 메시지를 **디프레이밍(deframing)**하고 유용한 속성을 나머지 필터 체인에 노출함으로써 이 문제를 해결합니다. 생성형 AI 프로토콜의 확장성 모델은 두 가지 목표에 의해 가이드되었습니다.

1. OAuth 또는 추적기(tracer)와 같이 기본적으로 생성형 AI 프로토콜과 함께 작동하는 기존 HTTP 확장의 손쉬운 재사용.

2. 생성형 AI 전용 확장을 위한 디프레이밍된 메시지에 대한 쉬운 액세스. 이를 통해 개발자는 HTTP나 JSON 봉투(envelope)를 처리할 필요 없이 생성형 AI 비즈니스 로직에 집중할 수 있습니다.

이러한 목표에 따라 생성형 AI 프로토콜용 새 확장은 여전히 HTTP 확장으로 빌드되고 HTTP 필터 체인에 구성됩니다. 이를 통해 OAuth 또는 mTLS 권한 부여와 같은 HTTP 네이티브 비즈니스 로직을 단일 체인에서 생성형 AI 프로토콜 로직과 혼합할 수 있는 유연성을 제공합니다. 디프레이밍 확장은 HTTP로 전달되는 프로토콜 메시지를 파싱하고, 추출된 속성이 포함된 앰비언트 컨텍스트(ambient context) 또는 파싱된 메시지 전체를 잘 알려진 필터 상태 및 메타데이터 값을 통해 다운스트림 확장에 제공합니다.

모든 정책 구성 요소가 자체적으로 JSON 봉투 또는 프로토콜별 메시지 형식을 파싱하도록 강제하는 대신, Envoy는 이러한 속성을 구조화된 메타데이터로 사용할 수 있도록 합니다. 게이트웨이가 프로토콜 메시지를 디프레이밍하면 ext_authz 또는 RBAC과 같은 기존 Envoy 확장이 프로토콜 속성을 읽어 MCP의 도구 이름, A2A의 메시지 속성 또는 OpenAI의 모델 이름과 같은 프로토콜별 속성을 사용하여 정책을 평가할 수 있습니다.

액세스 로그에는 향상된 모니터링 및 감사를 위해 메시지 속성이 포함될 수 있습니다. 프로토콜 속성은 Common Expression Language (CEL) 런타임에서도 사용할 수 있으므로 RBAC 또는 복합 확장에서 복잡한 정책 표현식을 간단하게 생성할 수 있습니다.

버퍼링 및 메모리 관리 Envoy는 HTTP 요청을 프록시할 때 가능한 한 적은 메모리를 사용하도록 설계되었습니다. 그러나 에이전틱 프로토콜을 파싱하려면 임의의 양의 버퍼 공간이 필요할 수 있으며, 특히 확장에 전체 메시지가 메모리에 있어야 하는 경우 더욱 그렇습니다. 확장이 더 큰 버퍼를 사용할 수 있도록 허용하는 유연성은 특히 신뢰할 수 없는 트래픽이 있는 경우 메모리 고갈로부터의 적절한 보호와 균형을 이루어야 합니다.

이를 달성하기 위해 Envoy는 이제 요청당 버퍼 크기 제한을 제공합니다. 요청 데이터를 보유하는 버퍼도 오버로드 관리자(overload manager)와 통합되어 메모리 부족 상황에서 유휴 타임아웃을 줄이거나 장시간 가장 많은 메모리를 소비하는 요청을 재설정하는 등 전방위적인 보호 조치를 취할 수 있습니다. 이러한 변경 사항은 Envoy가 리소스 효율성을 손상시키지 않으면서 생성형 AI 프로토콜의 게이트웨이 및 정책 적용 지점 역할을 할 수 있는 길을 열어줍니다.

2. Envoy는 중요한 요소에 정책을 적용합니다.

트래픽을 이해하는 것은 게이트웨이가 이에 따라 조치를 취할 수 있을 때만 유용합니다.

에이전틱 시스템에서 정책은 단지 에이전트가 도달할 수 있는 서비스에 관한 것이 아닙니다. 에이전트가 어떤 도구를 호출할 수 있는지, 어떤 모델을 사용할 수 있는지, 어떤 ID를 제시하는지, 얼마나 소비할 수 있는지, 어떤 종류의 출력이 추가 통제를 필요로 하는지에 관한 것입니다. 이는 단순한 레이어 4 또는 경로 기반 제어보다 가치가 높은 결정이며, 에이전트가 기업을 대신하여 조치를 취할 수 있도록 허용될 때 기업이 관심을 갖는 종류의 통제입니다.

Envoy는 전송 수준 보안을 애플리케이션 레벨의 정책 적용과 결합할 수 있기 때문에 이 분야에 매우 적합합니다. 팀은 mTLS 및 SPIFFE ID로 워크로드를 인증한 다음 RBAC, 외부 권한 부여, 외부 처리, 액세스 로깅 및 CEL 기반 정책 표현식을 사용하여 프로토콜별 규칙을 적용할 수 있습니다.

이 기능은 플랫폼 팀이 에이전트 개발과 적용을 분리할 수 있게 해주기 때문에 매우 중요합니다. 개발자는 유용한 에이전트를 구축하는 데 집중할 수 있고, 운영자는 도구, 모델 및 프로토콜이 계속 바뀌더라도 네트워크 계층에서 일관된 제로 트러스트 태세를 적용할 수 있습니다. 이러한 제로 트러스트 분리의 대표적인 예는 AI 에이전트가 인간 사용자를 대신하여 작업을 실행해야 하는 중요한 "사용자 위임(user-behind-agent)" 시나리오입니다. 전통적으로 애플리케이션에 사용자 자격 증명을 직접 전달하는 것은 심각한 보안 위험을 초래합니다. 프롬프트 주입을 통해 에이전트가 손상되거나 조작되면 공격자가 해당 자격 증명을 탈취하거나 오용할 수 있습니다. ID 관리를 Envoy로 오프로드함으로써 프록시는 인프라 계층의 아웃바운드 요청에 사용자 위임 토큰을 자동으로 삽입할 수 있습니다. 에이전트는 민감한 자격 증명을 직접 보유하지 않으므로 손상된 에이전트가 토큰을 오용하거나 유출할 위험이 완전히 차단되어 작업이 사용자의 실제 권한으로 엄격하게 제한됩니다.

사례 연구: 특정 GitHub MCP 도구로 에이전트 제한 GitHub 문제를 분류하는 에이전트를 가정해 보겠습니다. GitHub MCP 서버는 수십 개의 도구를 노출할 수 있지만, 에이전트는 list_issues, get_issue, get_issue_comments와 같이 읽기 전용의 작은 하위 집합만 필요할 수 있습니다. 대부분의 기업에서 이 차이는 중요합니다. 유용한 에이전트가 자동으로 제한 없는 에이전트가 되어서는 안 됩니다.

MCP 서버 앞에 Envoy가 있으면 게이트웨이는 mTLS 핸드셰이크 중에 SPIFFE를 사용하여 에이전트 ID를 확인하고, 디프레이밍 필터를 통해 MCP 메시지를 파싱하며, 요청된 메서드와 도구 이름을 추출하고, 해당 특정 에이전트 ID에 승인된 도구 호출만 허용하는 정책을 적용할 수 있습니다. RBAC은 MCP 디프레이밍 필터가 생성한 메타데이터를 사용하여 MCP 메시지의 메서드와 도구 이름을 확인합니다:

이것이 진정한 가치입니다. 정책은 트래픽과 가까운 곳에서 중앙 집중식으로, 에이전트의 실제 동작과 일치하는 방식으로 적용됩니다.

정적 규칙을 넘어서: 외부 권한 부여 (External Authorization) RBAC 규칙을 사용하여 표현할 수 없는 복잡한 규정 준수 정책은 ext_authz 프로토콜을 사용하여 외부 권한 부여 서비스에서 구현할 수 있습니다. Envoy는 ext_authz RPC의 컨텍스트에서 HTTP 헤더와 함께 MCP 메시지 속성을 제공합니다. 피어 인증서의 에이전트 SPIFFE ID를 전달할 수도 있습니다:

이를 통해 외부 서비스는 에이전트나 MCP 서버가 정책 계층을 신경 쓰지 않고도 에이전트 ID, MCP 메서드, 도구 이름 및 기타 프로토콜 속성의 전체 조합을 기반으로 권한 부여 결정을 내릴 수 있습니다.

프로토콜 네이티브 에러 응답 Envoy가 요청을 거부할 때 에러는 호출하는 에이전트에게 의미가 있어야 합니다. MCP 트래픽의 경우 Envoy는 local_reply_config를 사용하여 HTTP 에러 코드를 적절한 JSON-RPC 에러 응답에 매핑할 수 있습니다. 예를 들어, 403 Forbidden을 isError: true 및 사람이 읽을 수 있는 메시지가 포함된 JSON-RPC 응답으로 매핑하여 에이전트가 불투명한 HTTP 상태 코드 대신 프로토콜에 적합한 거부를 수신하도록 보장할 수 있습니다.

3. Envoy는 대규모로 상태 저장(stateful) 에이전트 상호작용을 지원합니다.

모든 에이전트 트래픽이 상태 비저장(stateless)은 아닙니다. MCP용 Streamable HTTP를 포함한 일부 프로토콜은 세션 지향 동작에 의존할 수 있습니다. 이는 특히 규모와 복원력을 달성하기 위해 트래픽이 여러 게이트웨이 인스턴스를 통해 흐를 때 중개자에게 새로운 과제를 안겨줍니다. MCP 세션은 효과적으로 에이전트를 세션을 설정한 서버에 바인딩하며, 모든 중개자는 들어오는 MCP 연결을 올바른 서버로 디렉팅하기 위해 이러한 정보를 알아야 합니다.

한 백엔드에서 세션이 설정되면 해당 대화의 나중 요청은 올바른 대상으로 도달해야 합니다. 이는 단일 프록시 배포에서는 간단해 보이지만, 여러 Envoy 인스턴스가 동일한 에이전트의 서로 다른 요청을 처리할 수 있는 수평 확장 시스템에서는 더 복잡해집니다.

패스스루 게이트웨이 (Passthrough gateway) 더 간단한 패스스루 모드에서 Envoy는 각 다운스트림 연결에 대해 하나의 업스트림 연결을 설정합니다. 이 모드의 주요 용도는 외부 MCP 서버에 대한 클라이언트 권한 부여, RBAC, 속도 제한 및 인증과 같은 중앙 집중식 정책을 적용하는 것입니다. 중개자 간에 전송되는 세션 상태에는 초기 HTTP 연결을 통해 세션을 설정한 서버의 주소만 포함하면 되므로 모든 세션 관련 요청이 해당 서버로 전달됩니다.

서로 다른 Envoy 인스턴스 간의 세션 상태 전송은 MCP 서버가 제공한 MCP 세션 ID에 인코딩된 세션 상태를 추가함으로써 달성됩니다. Envoy는 요청을 대상 MCP 서버로 전달하기 전에 세션 ID에서 세션 상태 접미사를 제거합니다. 이 세션 유지(session stickiness)는 Envoy의 envoy.http.stateful_session.envelope 확장을 구성하여 활성화됩니다.

통합 게이트웨이 (Aggregating gateway) 통합 모드에서 Envoy는 여러 백엔드 MCP 서버의 기능, 도구 및 리소스를 통합하여 단일 MCP 서버 역할을 합니다. 정책을 적용하는 것 외에도 이는 에이전트 구성을 단순화하고 여러 MCP 서버에 대한 정책 적용을 통합합니다.

이 모드에서의 세션 관리는 세션 상태에 도구 및 리소스를 이를 광고한 서버 주소 및 세션 ID에 매핑하는 것도 포함해야 하므로 더 복잡합니다. Envoy가 에이전트에게 제공하는 세션 ID는 도구나 리소스가 알려지기 전에 생성되며, 매핑은 나중에 Envoy와 백엔드 MCP 서버 간의 MCP 초기화 단계가 완료된 후에 설정되어야 합니다.

왜 Envoy가 이 변화에 적합한가 현재 Envoy에 구현된 한 가지 접근 방식은 도구 또는 리소스의 이름을 식별자 및 원래 서버의 세션 ID와 결합하는 것입니다. 정확한 도구 또는 리소스 이름은 일반적으로 에이전트에게 의미가 없으며 이 추가 출처 정보를 전달할 수 있습니다. 수정되지 않은 도구 또는 리소스 이름이 바람직한 경우, 또 다른 접근 방식은 매핑이 없는 Envoy 인스턴스를 사용한 다음 특정 도구를 호출하기 전에 tools/list 명령을 실행하여 매핑을 다시 생성하는 것입니다. 이는 MCP 세션의 외부 전역 저장소를 배포하는 복잡성 대신 대기 시간(latency)을 절충하는 방식이며, 현재 사용자 피드백을 기반으로 계획 중입니다.

이것이 중요한 이유는 Envoy를 단순한 트래픽 포워딩 이상으로 발전시키기 때문입니다. 이를 통해 Envoy는 여러 요청, 도구 및 백엔드에 걸친 에이전트 워크플로우를 위한 신뢰할 수 있는 중개자 역할을 수행할 수 있습니다.

4. Envoy는 에이전트 탐색(discovery)을 지원합니다.

Envoy는 잘 알려진 AgentCard 엔드포인트를 통한 A2A 프로토콜 및 에이전트 탐색에 대한 지원을 추가하고 있습니다. 에이전트 기능을 담은 JSON 문서인 AgentCard는 기술, 인증 요구 사항 및 서비스 엔드포인트를 광고하여 탐색 및 다중 에이전트 조정을 가능하게 합니다. AgentCard는 직접 응답 구성을 통해 정적으로 프로비저닝하거나 xDS 또는 ext_proc API를 통해 중앙 집중식 에이전트 레지스트리 서버에서 얻을 수 있습니다. A2A 구현 및 에이전트 탐색에 대한 자세한 설명은 향후 블로그 게시물에서 발표될 예정입니다.

5. Envoy는 에이전틱 네트워킹 과제를 위한 완전한 솔루션입니다.

까다로운 배포 환경에서 MCP 프로토콜에 대한 정책 적용을 가능하게 한 동일한 기반 위에, Envoy는 OpenAI에 대한 지원과 에이전틱 프로토콜을 RESTful HTTP API로 변환하는 트랜스코딩(transcoding) 지원을 추가하고 있습니다. 이 트랜스코딩 기능은 생성형 AI 에이전트와 기존 RESTful 애플리케이션의 통합을 단순화하며, OpenAPI 기반 애플리케이션에 대한 즉각적인 지원과 동적 모듈 또는 Wasm 확장을 통한 맞춤형 옵션을 제공합니다. 트랜스코딩 외에도 Envoy는 쿼터 관리와 같은 고급 정책 적용, 생성형 AI 시스템을 위한 OpenTelemetry 의미 체계 규약을 준수하는 포괄적인 텔레메트리, 안전한 에이전트 운영을 위한 통합 가드레일 등 프로덕션 환경 적용 준비(Production Readiness)를 위한 핵심 영역에서 강화되고 있습니다.

안전한 에이전트를 위한 가드레일 다음으로 중요한 투자 영역은 모든 에이전틱 트래픽에 대한 가드레일의 중앙 집중식 관리 및 적용입니다. 정책 적용 지점을 외부 가드레일과 통합하려면 현재 맞춤형 구현이 필요하며, 이 문제 영역은 표준화가 시급합니다.

제어 평면(Control Plane)이 이를 운영 가능하게 만듭니다.

게이트웨이는 이야기의 일부일 뿐입니다. 이러한 정책 관리 및 롤아웃을 대규모로 달성하려면 유니버설 데이터 평면 API로도 알려진 xDS 프로토콜을 사용하여 데이터 평면을 동적으로 구성하는 별도의 제어 평면이 필요합니다.

여기서 제어 평면이 중요해집니다. Envoy AI Gateway 및 kube-agentic-networking과 같은 오픈 소스 프로젝트와 함께 Cloud Service Mesh는 Envoy를 데이터 평면으로 사용하는 한편, 운영자에게 에이전틱 워크로드에 대한 정책을 정의하고 관리하는 상위 수준의 방법을 제공합니다.

이러한 결합은 강력한 시너지를 냅니다. Envoy는 트래픽 경로에서 적용 및 확장성을 제공하는 반면, 제어 평면은 팀이 해당 기능을 일관되게 배포하는 데 필요한 운영 모델을 제공합니다.

이것이 지금 중요한 이유

에이전틱 시스템 및 MCP, A2A, OpenAI와 같은 생성형 AI 프로토콜로의 전환은 네트워크 중개자의 진화를 필요로 합니다. Envoy가 해결하는 주요 복잡성은 다음과 같습니다.

• 심층 프로토콜 분석: 프로토콜 디프레이밍 확장은 HTTP 요청 본문에서 정책 관련 속성(도구 이름, 모델 이름, 리소스 경로)을 추출하여 기존 프록시가 불투명한 바이트 스트림만 볼 수 있는 곳에서 정밀한 정책 적용을 가능하게 합니다.

• 세분화된 정책 적용: 이러한 내부 속성을 노출함으로써 RBAC 및 ext_authz와 같은 기존 Envoy 확장은 프로토콜별 기준에 따라 정책을 평가할 수 있습니다. 이를 통해 네트워크 운영자는 통합된 제로 트러스트 보안 태세를 적용하여 에이전트가 특정 도구 또는 리소스에 대한 액세스 정책을 준수하도록 보장할 수 있습니다.

• 상태 저장(stateful) 전송 관리: Envoy는 MCP에서 사용하는 Streamable HTTP 전송에 대한 세션 상태 관리를 지원하여 여러 중개자 플릿에서도 패스스루 및 통합 게이트웨이 모드 모두에서 강력한 배포를 가능하게 합니다.

에이전틱 AI 프로토콜은 아직 초기 단계에 있으며 프로토콜 환경은 계속 진화할 것입니다. 이것이 바로 네트워킹 계층이 적응 가능해야 하는 이유입니다. 기업은 새로운 에이전트 프레임워크, 전송 패턴 또는 도구 프로토콜이 주목받을 때마다 보안 및 트래픽 인프라를 다시 빌드할 필요가 없어야 합니다. 통제력을 희생하지 않으면서 변화를 흡수할 수 있는 기반이 필요합니다.

Envoy는 입증된 운영 성숙도, 뛰어난 확장성, 에이전틱 워크로드에 대한 한층 강화된 프로토콜 지원능력을 한 곳에서 모두 제공합니다. Envoy를 에이전트 게이트웨이로 활용함으로써 조직은 에이전트 개발 코드에서 보안 및 정책 적용을 분리할 수 있습니다.

이것이 Envoy를 단순한 AI 트래픽 처리 프록시 그 이상으로 만듭니다. Envoy는 에이전틱 AI 네트워킹을 위한 미래 지향적인 기반입니다.