AI 인프라의 세대교체, 당신의 게이트웨이는 준비되었습니까?
AI 도입 초기에는 모든 것이 장밋빛으로 보였습니다. 그러나 실제 현장의 분위기는 사뭇 다릅니다. 엔지니어링 팀은 급격히 증가하는 API 비용에 부담을 느끼고 있으며, 보안 팀은 정체가 불분명한 ‘에이전트’들이 내부 데이터에 접근하는 상황을 우려하고 있습니다.
실제로 Solo.io의 내부 사례를 보면, AI 사용량이 급증하면서 비용이 매달 3배씩 증가하는 통제하기 어려운 상황에 직면하기도 했습니다. 이 문제를 해결하기 위해 CFO와 VP of Engineering이 함께 논의 테이블에 앉았다는 점은 시사하는 바가 큽니다. 지출을 이해하지 못하면 효과적으로 관리할 수 없다는 단순한 원칙이, AI 시대에는 더욱 절실하게 다가옵니다.
그렇다면 기존에 사용하던 NGINX, HAProxy, Envoy와 같은 프록시들은 왜 이러한 문제를 해결하지 못할까요?
이유는 분명합니다. 기존 게이트웨이는 AI 이전 시대를 전제로 설계되었기 때문입니다. 에이전트가 도구와 상호작용하는 방식, 즉 에이전틱 워크로드(Agentic Workloads)를 전혀 고려하지 못한 구조입니다. 이제는 단순한 트래픽 전달을 넘어, 게이트웨이 자체가 문맥(Context)을 이해하고 이에 기반해 보안을 집행해야 하는 시대로 전환되고 있습니다.
전통적인 API 게이트웨이의 구조적 한계
지난 수년간 Envoy와 NGINX는 마이크로서비스 아키텍처의 표준으로 자리 잡았습니다. 약 18~20개월 전까지만 해도 Envoy 기반 게이트웨이에 AI 기능을 확장하는 접근은 초기 LLM API 환경에서 충분히 합리적인 선택이었습니다. 외부 프로세서, WASM 필터, 심지어 별도의 Python 프로세스를 활용해 토큰 기반 속도 제한이나 프롬프트 검증 기능을 구현하며 빠르게 프로덕션에 적용할 수 있었습니다.
그러나 AI 에이전트의 등장과 함께 MCP(Model Context Protocol) 가 확산되면서 상황은 근본적으로 달라졌습니다. 기존 프록시는 다음과 같은 구조적 한계에 직면하게 되었습니다.
첫째, 상태(State) 관리의 부재입니다. MCP는 본질적으로 상태 기반의 양방향 스트리밍을 요구합니다. 반면 Envoy는 상태가 없는(stateless) 단방향 구조에 기반하고 있어 이를 자연스럽게 수용하기 어렵습니다. 일부 업스트림 기여가 이루어졌지만, 실제 구현은 지연 시간과 복잡도를 증가시키는 외부 우회 방식에 의존하는 경우가 많습니다.
둘째, 요청 본문(Request Body)에 대한 제한적인 이해입니다. 전통적인 API 게이트웨이는 트래픽을 일종의 불투명한 봉투처럼 다루며 주로 헤더 정보만을 검사합니다. 이러한 접근은 REST API 환경에서는 충분했지만, LLM 기반 워크로드에서는 한계가 분명합니다. 토큰 수, 프롬프트 내용, 모델 이름, MCP 도구 호출 정보 등 핵심적인 판단 요소가 모두 JSON 페이로드 내부에 포함되어 있기 때문입니다. 이를 외부 프로세서를 통해 처리할 경우 지연 시간이 증가하는 것은 피할 수 없습니다.
결국 레거시 프록시에 AI 기능을 덧붙이는 방식은 점차 한계에 도달하고 있습니다. 특히 에이전트 루프처럼 짧은 요청이 반복되는 구조에서는 게이트웨이 지연이 사용자 경험에 직접적인 영향을 미치게 됩니다.
에이전틱 루프: AI 시대의 새로운 네트워크 패턴
AI와의 상호작용 방식은 지난 1년 사이 급격하게 변화했습니다. 현재의 LLM 시스템은 단일 서비스가 아니라, LLM, 에이전트, MCP 서버가 결합된 복합적인 구조로 이루어져 있습니다.
에이전트는 단순한 프론트엔드 역할을 넘어, LLM과 외부 도구를 연결하는 핵심 구성 요소입니다. 이러한 흐름은 에이전틱 루프(Agentic Loop) 라는 형태로 나타납니다.
이 과정에서 중요한 점은 명확합니다. 게이트웨이가 모델 호출과 도구 호출을 구분하지 못한다면, 실질적인 보안 정책을 적용하기 어렵습니다. 따라서 에이전틱 환경에서는 문맥을 이해할 수 있는 새로운 형태의 AI 네이티브 게이트웨이가 필요합니다.
오늘날 기업 환경에서는 이러한 에이전틱 시스템과 기존 마이크로서비스가 함께 운영되는 경우가 일반적입니다. 이 두 가지 흐름을 동시에 관리하는 것이 새로운 인프라 과제로 떠오르고 있습니다.
Rust 기반으로 재설계된 데이터 플레인
Solo.io의 agentgateway는 기존 프록시를 확장하는 접근이 아니라, Rust 기반으로 데이터 플레인을 처음부터 재설계한 사례입니다.
초기에는 Envoy를 기반으로 기능을 확장하려는 시도가 있었지만, MCP와 같은 프로토콜을 제대로 지원하기 위해서는 프록시 자체가 문맥 정보를 이해해야 한다는 한계에 부딪혔습니다. 결국 기존 구조로는 근본적인 해결이 어렵다는 결론에 도달했습니다.
Rust를 선택한 이유도 분명합니다. Rust는 가비지 컬렉션 없이 메모리 안전성을 보장하면서도 C++ 수준의 성능을 제공합니다. 이는 요청 처리 과정에서 예기치 않은 지연을 최소화하는 데 중요한 요소입니다.
이러한 기반 위에서 agentgateway는 다음과 같은 특징을 제공합니다.
- 본문 심층 검사(Deep Body Inspection): 플러그인이나 사후 추가 기능이 아닌, 핵심 기능으로서 OpenAI 호환 JSON 본문을 파싱하여 모델 이름, 토큰 수, 프롬프트, 도구 호출 정보를 추출하고 정책을 적용합니다.
- 네이티브 프로토콜 지원: MCP 페더레이션, 도구 탐색, A2A(Agent-to-Agent) 보안 및 라우팅이 프로세스 외부 사이드카 없이 코어에 내장되어 있습니다.
- 추론 인식 라우팅(Inference-aware Routing): GPU 큐 깊이, 메모리 사용률 등의 신호를 기반으로 온프레미스 모델에 트래픽을 지능적으로 라우팅하는 공식 Gateway API Inference Extension을 기본 지원합니다.
- 통합 아키텍처: 인그레스, 서비스 메시 웨이포인트, AI 이그레스를 단일 게이트웨이로 처리합니다.
이러한 설계는 기존 프록시가 제공하기 어려웠던 수준의 성능과 유연성을 동시에 가능하게 합니다.
에이전틱 보안과 AI 유스케이스
agentgateway는 AI 활용 시나리오를 크게 세 가지로 구분하여 지원합니다.
① LLM 소비(LLM Consumption): 내부 애플리케이션이 외부 LLM 제공자를 호출하는 시나리오입니다. agentgateway는 이그레스 게이트웨이로서 외부 LLM 호출을 중재하며, 자격증명 관리, 프롬프트 보강, 프롬프트 가드, 속도 제한, 모델 페일오버 등의 기능을 제공합니다.
② 추론 소비(Inference Consumption): 온프레미스에서 LLM을 자체 호스팅하며 요청을 적절한 모델로 지능적으로 라우팅하는 시나리오입니다. agentgateway는 문맥 인식 인그레스 게이트웨이로서 토큰 소비량, 세션 인식, 응답 시간, 모델 역량 등을 고려하여 라우팅 결정을 내립니다.
③ 에이전틱 시스템 개발: 에이전트, 에이전트 스킬, MCP 서버, LLM이 온프레미스와 외부 환경에 혼재하는 복합 시나리오입니다. agentgateway는 트래픽의 지능적 라우팅, 관측 가능성을 위한 텔레메트리 수집/발행, 보안을 위한 정책 집행 포인트 역할을 모두 수행합니다.
LLM 소비, 온프레미스 추론, 그리고 에이전틱 시스템 구성이라는 세 가지 유형 모두에서 공통적으로 중요한 것은 문맥 기반 제어입니다.
특히 MCP 인가 영역에서는 차별성이 뚜렷합니다. agentgateway는 CEL(Common Expression Language)을 활용하여 단순한 사용자 인증을 넘어, 실제 호출되는 도구 이름까지 포함한 정책을 구성할 수 있습니다. 이는 기존 프록시가 제공하지 못했던 수준의 정밀한 제어 방식입니다.
또한 서비스 메시와 결합할 경우, 모든 트래픽이 agentgateway를 반드시 통과하도록 강제할 수 있어 우회 경로를 원천적으로 차단할 수 있습니다.
실제 사례로 본 비용 최적화 효과
Solo.io는 자사 제품인 agentgateway를 직접 도입하여 내부 AI 컨트롤 플레인을 구축했습니다. 이는 단순한 마케팅 사례가 아닌, CFO와 VP of Engineering이 함께 주도한 실제 경영 의사결정이었습니다.
왜 문제가 발생했나? AI 사용량 급증의 배경은 다음과 같습니다. Claude 모델의 개선이 팀 전반의 사용량을 높였고, Cursor가 엔지니어링 워크플로우의 표준 도구가 되었으며, OpenAI 사용량은 내부 호스팅 애플리케이션 증가와 함께 꾸준히 늘었고, 각 부서의 내부 실험이 활발해졌습니다. 생산성 향상이라는 실질적인 성과가 동반된 비용 증가였지만, 문제는 가시성의 부재였습니다.
Claude 사용량의 상당 부분이 Vertex AI를 통해 라우팅되고 있었는데, Vertex AI의 기본 보고 기능으로는 "누가 어떤 모델을 어떤 워크플로우에 사용하는가", "인당 지출 추적", "프로덕션 트래픽과 실험 트래픽의 구분" 같은 운영 질문에 답할 수 없었습니다.
비용 문제에 더해 데이터 거버넌스 이슈도 있었습니다. 민감하거나 독점적인 데이터는 반드시 입력값을 학습에 사용하지 않는 제공자와의 엔터프라이즈 라이선스를 통해야 한다는 정책을 준수해야 했습니다.
해결책은 예산 협상이 아닌 인프라였습니다. Solo.io가 취한 조치는 다음과 같습니다.
agentgateway를 통해 단일 컨트롤 레이어를 구성하고, Vertex에 대한 직접 접근을 차단하여 agentgateway를 사용자와 모델 사이의 유일한 제어 지점으로 만들었습니다. 구축에 걸린 시간은 1주일 미만이었습니다. 전체 설정은 200줄 이하의 YAML로 완성되었으며, 게이트웨이 자체는 1 vCPU 미만, 100MB 이하의 RAM으로 운영되어 사용자가 지연을 전혀 체감하지 못했습니다.
최종 구성은 OpenAI, Vertex AI, Fireworks.ai 3개 제공자를 9개 부서에 기존 Google Workspace SSO를 통해 통합 제공하는 형태였습니다. 이전에는 IT팀이 100명 이상의 사용자를 AI 제공자별로 각기 다른 청구 모델과 속도 제한 속에서 관리해야 했지만, 이제는 모니터링과 프로비저닝을 위한 단 하나의 창구만 존재합니다.
가시성이 확보되자 구체적인 행동이 가능해졌습니다. 비용 지출이 소수의 사용자와 워크플로우에 집중되어 있음을 파악하고, 다음과 같은 타깃형 조정을 실행했습니다.
- 고사용량 사용자를 Claude Teams 같은 정액제 요금제로 전환하여 예측 불가능한 API 지출을 고정 비용으로 전환
- 순수 실험용 워크로드에 대한 무제한 API 접근 제한
- 출력 품질에 의미 있는 차이 없이 5~6배 저렴한 모델로 적합한 워크로드 라우팅
그 결과, Vertex AI 지출이 이전 대비 1/3 이하로 감소했으며 전체 AI 비용의 70%를 절감하는 성과를 달성했습니다. 동시에 개발자 생산성에는 측정 가능한 영향이 없었고, 전 직원은 SSO를 통해 여러 모델과 제공자에 접근할 수 있게 되었습니다.
유연한 배포 방식
agentgateway는 다양한 환경에 맞게 도입할 수 있습니다.
독립 실행형, Kubernetes 통합, 서비스 메시 연계 등 여러 방식으로 구성할 수 있으며, 각 조직의 인프라 전략에 맞게 선택이 가능합니다.
① 독립 실행형(Standalone): agentgateway.dev에서 바이너리를 다운로드하여 설치할 수 있습니다. 바이너리는 경량이며 빠른 실행 성능을 자랑하고, 내장 관리 UI와 클라이언트 인스펙터를 제공합니다.
② Kubernetes 통합: 오픈소스 CNCF 프로젝트인 kgateway.dev를 통해 통합할 수 있습니다. kgateway가 컨트롤 플레인 역할을 하며 Kubernetes Gateway API를 통해 프록시를 구성합니다. GatewayClass agentgateway를 통해 agentgateway 인스턴스를 프로비저닝하고 다양한 유스케이스에 맞게 프로그래밍할 수 있습니다.
③ 서비스 메시 통합: Solo.io의 제품들은 이제 Envoy 프록시 대신 agentgateway를 서비스 메시의 웨이포인트 구현체로 사용하는 것을 지원합니다. 이를 통해 지정된 서비스 앞에 Layer 7 프록시를 배치하는 형태로 활용할 수 있습니다.
AI 거버넌스는 결국 인프라의 문제입니다
AI 비용 구조는 기존 SaaS와 근본적으로 다릅니다. 사용량 기반 과금 구조와 빠르게 변화하는 사용 패턴은 기존 방식의 관리 접근으로는 대응하기 어렵습니다.
이 문제를 단순한 예산 관리로 접근하는 것은 한계가 있습니다. Solo.io 사례에서 확인할 수 있듯이, 근본적인 해결은 인프라 수준에서의 통제와 가시성 확보입니다.
AI 시대의 컨트롤 플레인은 가시성, 거버넌스, 그리고 유연한 라우팅이라는 세 가지 요소를 갖추어야 합니다. 핵심은 사용을 줄이는 것이 아니라, 효율적으로 사용하는 것입니다.
이제는 레거시 프록시를 보완하는 수준을 넘어, AI 워크로드를 이해하는 새로운 인프라가 필요한 시점입니다. 문맥을 인식하고 정책을 집행할 수 있는 게이트웨이를 통해서만 기업은 성능과 보안을 동시에 확보할 수 있습니다.
결국 중요한 것은 한 가지입니다. 무슨 일이 일어나고 있는지 명확히 볼 수 있어야, 올바른 대응이 가능하다는 점입니다. 지금 사용 중인 게이트웨이는 AI 시대에 맞는 준비가 되어 있습니까?
원문 출처:
Context-aware security for agentic AI gateways
Going all in on AI: how we used our own product to keep pace without losing contral
