F5, 엔터프라이즈 AI 트래픽 통제 노리며 AI Gateway 확장
- Sophie Larsen

- 7일 전
- 12분 분량
F5는 이미 기업들이 모델 라우터, 가드레일, 에이전트 보안 도구가 난립한 시장에 직면한 상황에서도 8월 18일 AI Gateway를 확장했다. Google News 헤드라인만 보면 또 하나의 제품 업데이트처럼 들린다. 그러나 그 이면에는 직원, 애플리케이션, AI 모델, 에이전트, 기업용 도구를 연결하는 모든 요청을 통제하려는 움직임이 있다.
업데이트된 게이트웨이는 세 가지 기능을 하나의 정책 계층 아래 결합한다. Model Gateway는 모델 접근, 라우팅, 토큰 사용량을 관리한다. MCP Gateway는 에이전트의 도구 접근 방식을 통제하고, AI Guardrails는 프롬프트와 응답에서 위협 또는 민감한 데이터를 검사한다.
이 조합이 실제 경쟁 구도를 만든다. 기업은 각 기능에 특화된 제품을 조합할 수도 있고, 여러 형태의 AI 트래픽을 하나의 인프라 제공업체 뒤에 둘 수도 있다. F5는 운영 일관성이 개별 도구가 제공하는 자유도와 전문성을 앞설 것이라고 보고 있다.
이 회사는 경쟁이 치열한 시장에 진입했다. Kong, Cloudflare, Citrix, Palo Alto Networks, 클라우드 제공업체, AI 네이티브 스타트업 모두 제어 영역 기회의 일부를 차지하려 하고 있다. 이들은 어떤 AI 요청이 실행되고, 무엇에 접근하며, 얼마의 비용이 드는지를 결정하는 중개자가 되려 한다.
F5는 이미 BIG-IP, NGINX 또는 자사의 분산 클라우드 서비스를 사용하는 조직 안에서 강점을 갖는다. 이러한 설치 기반은 정책 집행이 이미 이뤄지는 애플리케이션 및 API 트래픽 가까이에 자리한다. 다만 기존 트래픽 지위가 AI 거버넌스 리더십으로 자동 연결되지는 않는다.
따라서 중요한 질문은 기업에 더 나은 통제가 필요한지 여부가 아니다. 하나의 게이트웨이가 또 다른 집중 리스크가 되지 않으면서 모델, 에이전트, 데이터, 비용을 관리할 수 있느냐가 핵심이다.
F5가 실제로 바꾼 것
F5는 AI Gateway를 보안 검문소에서 더 폭넓은 운영 제어 영역으로 전환하고 있다.
회사는 2024년 11월 F5 AI Gateway를 처음 소개했다. 초기 포지셔닝은 애플리케이션, API, 대규모 언어 모델 사이의 트래픽 보호 및 관리에 초점을 맞췄다.
최신 릴리스는 그 범위를 확장한다. F5는 이제 세 개의 연결된 게이트웨이와 보안 계층을 서로 다른 정책을 가진 개별 제품이 아니라 하나의 시스템으로 제시한다.
Model Gateway는 AI 모델로 전송되는 요청을 처리한다. F5에 따르면 이 기능은 제공업체, 모델, 팀, 개별 사용자별 토큰 사용량을 기록한다. 관리자는 요청이 처리되는 동안 예산을 설정하고 집행할 수도 있다.
라우팅에는 경제적 기능도 추가된다. 게이트웨이는 간단한 작업을 비용이 더 낮은 모델로 보내고, 적합한 캐시 응답을 재사용하거나, 사용 가능한 GPU 용량에 따라 워크로드를 분산할 수 있다. 이로써 게이트웨이는 보안 제품이면서 트래픽 관리자이자 지출 통제 도구가 된다.
F5는 이러한 기능이 애플리케이션 변경 없이 토큰 지출을 30%에서 60%까지 줄일 수 있다고 말한다. 현재의 AI Gateway 개요에서도 중복된 에이전트 도구 호출을 제거하면 관련 토큰 낭비를 최대 90%까지 줄일 수 있다고 주장한다.
이 수치는 독립적인 벤치마크가 아닌 공급업체의 주장이다. 실제 절감 효과는 요청 패턴, 캐시 재사용, 모델 선택, 지연 시간 요구사항, 기존 최적화 작업에 따라 달라질 것이다. 이미 엄격한 라우팅 정책을 사용 중인 조직은 더 작은 효과를 볼 수 있다.
MCP Gateway는 다른 트래픽 경로를 다룬다. Model Context Protocol, 즉 MCP는 AI 애플리케이션이 도구 및 데이터 소스와 연결하는 표준 방식을 제공한다. 이러한 연결은 데이터베이스, 내부 API, 문서 저장소, 비즈니스 시스템으로 이어질 수 있다.
F5는 자사 레지스트리가 공개, 원격, 비공개 MCP 서버를 목록화할 수 있다고 말한다. 관리자는 개별 도구에 허용 목록, 차단 목록, 할당량, 예산, 역할 기반 접근 제어를 적용할 수 있다.
이 시스템은 각 도구 호출도 기록한다. 이 기록은 어떤 ID가 요청을 시작했는지, 에이전트가 어떤 리소스에 접근했는지, 어떤 작업이 발생했는지를 보여줄 수 있다. 자율 프로세스가 비즈니스 데이터를 수정하거나 규제 대상 정보에 접근할 때 이러한 증거는 중요하다.
AI Guardrails는 게이트웨이를 통과하는 콘텐츠를 검사한다. F5는 이 정책들이 개인 식별 정보의 마스킹, 프롬프트 인젝션 시도 차단, 탈옥 기법 저지를 수행할 수 있다고 말한다. Fail-closed 집행은 검사 계층이 트래픽을 안전하게 평가할 수 없을 때 해당 트래픽을 거부한다.
이들 구성 요소는 세 가지 별개 질문을 포괄한다. 어떤 모델이 요청을 처리해야 하는가? 에이전트는 어떤 도구를 사용할 수 있는가? 어떤 정보나 지시가 두 경계 중 어느 쪽을 넘어갈 수 있는가?
F5는 이 게이트웨이를 더 광범위한 AI Security Platform 안에도 배치했다. 이 플랫폼은 AI 트래픽을 전달하는 실시간 시스템을 중심으로 AI 거버넌스, 사용량 제어, 보안 테스트, 런타임 보호를 묶는다.
통합은 브랜딩보다 더 중요하다. 요청을 라우팅하기만 하는 게이트웨이는 AI 워크플로의 한 부분만 본다. 애플리케이션 보안, API 제어, 런타임 모니터링과 연결된 게이트웨이는 해당 요청을 둘러싼 더 많은 활동을 연계할 수 있다.
F5는 SaaS, 하이브리드 SaaS, 하이브리드 멀티클라우드 배포를 지원할 계획이다. 민감한 트래픽을 외부 서비스로 보낼 수 없는 규제 환경을 위한 에어갭 지원도 계획돼 있다.
이 배포 범위는 AI 시스템이 사설 인프라와 여러 클라우드 제공업체에 걸쳐 있는 조직을 겨냥한다. 동시에 F5의 핵심 주장을 강화한다. 제어 계층은 특정 모델 공급업체에 속하는 것이 아니라 환경 전반의 트래픽을 따라가야 한다는 것이다.
지금 Google News 헤드라인이 중요한 이유
Google News 항목은 AI 모델 실험에서 대규모 AI 추론 관리로 전환하는 더 큰 흐름을 반영한다.
F5의 2026 State of Application Strategy 연구에 따르면, 설문 대상 조직의 77%는 추론을 지배적인 AI 활동으로 봤다. 응답자들은 평균 7개의 AI 모델을 관리하고 있었으며, 이는 회사 측 발표에 따른 것이다.
추론은 학습된 모델이 실시간 요청을 처리하는 프로덕션 단계다. 여기에는 직원용 어시스턴트, 고객 지원 시스템, 코드 도구, 검색 애플리케이션, 비즈니스 작업을 수행하는 에이전트가 포함된다.
7개 모델을 관리한다는 것은 7개 이상의 기술적 관계를 만든다. 팀은 이들 시스템 전반에서 자격 증명, 리전, 요청 형식, 보존 규칙, 안전 필터, 폴백 동작, 성능, 사용량을 추적해야 한다.
에이전트는 또 다른 권한 구조를 도입한다. 모델은 외부 도구 호출을 결정할 수 있고, 그 도구는 데이터를 노출하거나 작업을 실행할 수 있다. 보안팀은 사용자, 에이전트, 모델, 도구, 대상 시스템을 함께 관리해야 한다.
MCP는 도구 통합을 쉽게 만들지만, 표준화는 확산도 가속한다. 개발자는 모든 AI 애플리케이션을 위해 맞춤형 인터페이스를 설계하지 않고도 새로운 도구를 연결할 수 있다. 중앙 팀은 어떤 서버가 존재하고 누가 접근할 수 있는지에 대한 가시성을 빠르게 잃을 수 있다.
보안 연구자들은 이미 이렇게 확대된 공격 표면을 설명했다. MCP 보안 제어에 관한 2025년 논문은 도구 오염, 데이터 유출, 공급망 침해, 시스템 간 권한 상승을 핵심 위험으로 지목했다.
연구자들은 범위가 지정된 권한 부여, 출처 추적, 샌드박싱, 인라인 데이터 제어, 중앙화된 게이트웨이 집행을 권고했다. F5의 아키텍처는 이 권고 가운데 여러 항목과 부합하지만, 제품 기능 목록이 효과적인 구현을 입증하는 것은 아니다.
보안 위험과 함께 경제적 압박도 커지고 있다. 모든 프롬프트, 응답, 검색된 문서, 도구 결과는 모델 요청에 토큰을 추가할 수 있다. 에이전트는 사용자에게 보이는 하나의 작업을 완료하는 동안 여러 차례 모델 호출을 생성할 수 있다.
이 때문에 지출 귀속은 어려워진다. 기업은 전체 제공업체 청구액은 알 수 있지만, 팀, 애플리케이션, 사용자, 자율 워크플로 전반에 걸친 신뢰할 수 있는 귀속 정보는 부족할 수 있다.
일부 AI 워크로드에는 기존 클라우드 예산 체계도 너무 늦게 도착한다. 에이전트는 월간 보고서가 패턴을 식별하기 전에 실패한 단계를 반복하거나 불필요한 도구 호출을 생성할 수 있다. 실시간 할당량과 라우팅 정책은 더 일찍 개입할 수 있다.
F5의 최고제품책임자 Kunal Anand는 이 문제를 경제적, 보안, 거버넌스 결과를 수반하는 요청에 대한 분산된 통제로 설명했다. 이 프레이밍은 F5의 플랫폼 전략에 부합하지만, 분산 문제 자체는 현실이다.
이 분야에는 상당한 투자도 유입되고 있다. Axios 보도에 따르면 WitnessAI는 엔터프라이즈 AI 보안 플랫폼 확장을 위해 5,800만 달러를 조달했다. PitchBook은 에이전틱 사이버보안 기업들이 2025년 동안 약 24건의 거래에서 거의 2억5,000만 달러를 조달한 것으로 추정했다.
다만 배포는 여전히 고르지 않다. 같은 Axios 보도는 응답자의 약 4분의 1만이 에이전틱 시스템을 의미 있는 수준으로 확장하고 있다는 McKinsey 연구를 인용했다.
이 격차는 공급업체들이 지금 움직이는 이유를 설명한다. 대다수 엔터프라이즈 에이전트가 프로덕션에 도달하기 전에 제어 지점을 확보하려는 것이지, 고객이 다른 곳에서 표준화한 뒤가 아니다.
따라서 Google News 보도는 단순한 F5 기능 출시 이상의 의미를 갖는다. 이는 지배적인 엔터프라이즈 아키텍처가 정착되기 전에 형성되고 있는 인프라 경쟁을 포착한다.
하나의 제어 영역 대 특화 AI 도구
F5의 주된 경쟁 상대는 한 곳의 공급업체가 아니다. 별도의 라우팅, 보안, 관측성, 에이전트 거버넌스 제품으로 구성된 특화 스택이다.
특화 아키텍처는 기업이 성능을 위한 모델 라우터, 콘텐츠 검사를 위한 가드레일 제공업체, MCP 권한 부여를 위한 별도 제품을 선택할 수 있게 한다. 팀은 전체 시스템을 옮기지 않고도 한 구성 요소를 교체할 수 있다.
이러한 유연성은 이 분야가 아직 초기 단계이기 때문에 중요하다. 보안 기법, 에이전트 프로토콜, 모델 인터페이스는 계속 변화하고 있다. 긴밀하게 결합된 플랫폼은 다른 곳에 더 강력한 구성 요소가 등장했을 때 조정하기 어려워질 수 있다.
전문 기업은 좁은 문제에 더 깊게 집중할 수도 있다. AI 네이티브 관측성 서비스는 더 풍부한 프롬프트 추적이나 평가 워크플로를 제공할 수 있다. 전용 보안 기업은 범용 애플리케이션 플랫폼이 놓치는 공격을 탐지할 수 있다.
그 대가는 운영 파편화다. 각 구성 요소는 또 다른 정책 언어, 대시보드, 에이전트, 데이터 저장소, ID 통합, 감사 형식을 도입할 수 있다. 두 제품이 같은 사용자나 요청을 다르게 해석할 때 공백이 생긴다.
F5는 공유 정책이 이러한 공백을 줄인다고 주장한다. 자사 시스템은 모델 트래픽과 에이전트 도구 호출 전반에 예산, 역할 기반 접근 제어, 감사 기록, 관측성을 적용한다.
가장 강력한 사례는 기존 F5 환경에서 나타난다. 이미 BIG-IP 또는 NGINX를 사용하는 기업은 일반 애플리케이션 및 API 트래픽을 처리하는 인프라 가까이에 AI 제어 기능을 배치할 수 있다.
F5는 2026년 3월 이 전략을 강화했다. ADSP 확장은 애플리케이션 딜리버리 포트폴리오 전반에 MCP 트래픽 가시성과 에이전트 중심 제어 기능을 추가했다.
발표에 따르면 NGINX는 트래픽 경로에서 MCP 메타데이터를 검사할 수 있다. 운영자는 알려진 또는 이전에 추적되지 않던 에이전트 활동 전반의 요청 패턴, 지연 시간, 처리량, 오류를 관찰할 수 있다.
이러한 위치는 배포 마찰을 줄일 수 있다. 팀은 또 다른 프록시를 삽입하고 별도의 운영 프로세스를 구축하는 대신 기존 트래픽 계층을 확장할 수 있다.
경쟁사들도 비슷한 주장을 펼치고 있다. Citrix는 기본 제품을 출시한 지 불과 몇 달 만인 7월 NetScaler AI Gateway에 MCP Gateway 기능을 추가했다.
NetScaler 업데이트는 모델 라우팅, 토큰 추적, 에이전트 도구 거버넌스를 결합한다. Citrix는 모델 및 MCP 트래픽 모두를 위한 단일 플랫폼과 대시보드도 강조한다.
Kong은 API 인프라 관점에서 이 범주에 접근한다. Cloudflare는 AI 라우팅을 대규모 엣지 네트워크와 연결할 수 있다. Palo Alto Networks는 AI 게이트웨이 기능을 더 광범위한 엔터프라이즈 보안 포트폴리오에 통합하고 있다.
클라우드 제공업체들도 또 다른 우위를 지닌다. Amazon, Microsoft, Google, Databricks는 각자의 ID, 데이터, AI 서비스에 가까운 위치에 모델 접근 제어를 배치할 수 있다.
이 경쟁은 독립형 AI 게이트웨이 공급업체에 압박을 가한다. 이들은 더 깊이 있는 AI 특화 기능이 트래픽 경로에 또 하나의 제품을 추가할 만큼의 가치를 제공한다는 점을 입증해야 한다.
F5에도 압박이 가해진다. 이 회사는 익숙한 애플리케이션 인프라가 일반적인 네트워크 요청을 넘어 거버넌스할 수 있을 만큼 에이전트의 행동을 깊이 이해한다는 점을 보여줘야 한다.
전통적인 게이트웨이는 ID, 대상, 요청 형태, 속도 제한을 확인한다. AI 게이트웨이는 프롬프트 내용, 모델 선택, 도구 의도, 데이터 민감도, 다단계 행동까지 판단해야 한다.
이러한 결정은 서로 다른 계층에서 이루어진다. 승인되지 않은 데이터베이스 도구를 차단하는 것은 명확한 접근 제어 조치다. 반면 승인된 에이전트가 검색된 콘텐츠에 의해 조작되고 있는지를 판단하려면 더 많은 맥락 분석이 필요하다.
공유된 ID와 텔레메트리가 이러한 결정을 개선한다면 플랫폼 전략은 성공한다. 통합이 주로 하나의 콘솔만 제공하고 특화된 제어 기능이 얕은 수준에 머문다면 그 전략은 약화된다.
조달 과정은 이러한 긴장을 증폭시킬 것이다. 보안 리더는 대체로 더 적은 공급업체와 일관된 증거를 선호하는 반면, 개발팀은 빠르게 발전하고 이식성이 유지되는 도구를 선호한다.
결과는 조직마다 다를 것이다. F5가 모든 새로운 AI 프로젝트에서 승리할 필요는 없다. 기존 고객이 자사의 게이트웨이를 프로덕션으로 들어가는 기본 경로로 여기게 만들면 된다.
게이트웨이는 정책을 집행할 수 있지만, 안전을 증명할 수는 없다
중앙 집행은 통제를 개선하지만, 모델 출력이나 에이전트 행동 자체를 본질적으로 신뢰할 수 있게 만들지는 않는다.
AI 게이트웨이는 경계를 통과하는 트래픽을 볼 수 있다. ID를 인증하고, 콘텐츠를 검사하며, 결정을 기록하고, 속도를 제한하고, 승인되지 않은 대상을 차단할 수 있다.
그러나 허용된 행동이 올바른지 항상 판단할 수는 없다. 직원이 에이전트에게 잘못된 업데이트를 수행하도록 요청하면서도 합법적으로 고객 기록에 접근할 수 있다. 이 요청은 모든 정책을 충족하면서도 피해를 초래할 수 있다.
프롬프트 인젝션도 유사한 문제를 제기한다. 악의적인 지침은 웹페이지, 문서, 메시지 또는 검색된 기록 안에 나타날 수 있다. 에이전트는 해당 콘텐츠를 신뢰할 수 없는 데이터가 아니라 명령으로 해석할 수 있다.
F5는 자사의 가드레일이 프롬프트 인젝션과 탈옥 시도를 차단한다고 말한다. 또한 위협 라이브러리가 매월 10,000개 이상의 공격 패턴을 수신한다고도 밝힌다. 이러한 주장은 각 고객의 애플리케이션과 데이터를 기준으로 신중하게 평가해야 한다.
패턴 적용 범위가 완전한 보호를 의미하지는 않는다. 공격자는 표현을 바꾸거나, 여러 입력에 지침을 분산하거나, 애플리케이션 로직을 악용하거나, 콘텐츠 검사를 통과한 뒤 승인된 도구를 표적으로 삼을 수 있다.
오탐은 또 다른 운영상 위험을 만든다. 엄격한 필터는 승인된 워크플로에 필요한 유효한 소스 코드, 의료 용어, 보안 연구 또는 고객 정보를 차단할 수 있다.
게이트웨이가 요청을 검사할 수 없을 때 실패 시 차단하는 동작은 노출을 제한한다. 하지만 정책 서비스 장애나 불확실한 분류 상황에서 핵심 애플리케이션을 중단시킬 수도 있다.
엔터프라이즈에는 명확한 예외 절차가 필요하다. 누가 결정을 재정의할 수 있는지, 해당 행동이 어떻게 기록되는지, 긴급 접근이 지속적인 정책 공백을 만드는지 알아야 한다.
지연 시간도 면밀히 살펴야 한다. 모든 라우팅 결정, 콘텐츠 검사, 데이터 분류, 감사 작업에는 시간이 든다. 여러 순차적 모델 및 도구 호출을 수행하는 에이전트에서는 작은 지연도 누적된다.
F5는 이 플랫폼이 고처리량 트래픽에 적합하다고 설명하지만, 모든 검사 모드에 대한 포괄적인 독립 벤치마크는 공개하지 않았다. 구매자는 현실적인 프롬프트, 스트리밍 응답, 긴 에이전트 세션을 테스트해야 한다.
제어 플레인 자체도 민감한 인프라가 된다. 모델 자격 증명, 사용자 ID, 프롬프트 내용, 도구 인벤토리, 예산 규칙, 내부 활동 기록을 포함할 수 있다.
침해가 발생하면 하나의 애플리케이션보다 훨씬 많은 것이 노출될 수 있다. 중앙화는 가시성과 집행을 집중시키지만, 운영 및 보안상의 결과도 집중시킨다.
따라서 배포 설계가 중요하다. 규제 대상 조직은 검사가 어디에서 발생하는지, 어떤 데이터가 F5 서비스에 도달하는지, 로그가 어떻게 보존되는지, 민감한 콘텐츠가 텔레메트리에 나타나는지를 확인해야 한다.
에어갭 지원은 제공되는 즉시 일부 데이터 레지던시 우려를 해소할 수 있다. 그때까지 구매자는 현재 제공되는 기능과 계획된 배포 옵션을 구분해야 한다.
컴플라이언스 관련 표현도 절제할 필요가 있다. SOC 2, ISO 표준 또는 HIPAA 관련 통제와의 정렬이 고객 배포 환경을 자동으로 규제 준수 상태로 만들지는 않는다.
규제 준수는 구성, 운영 절차, 계약, 접근 검토, 보존 정책, 주변 애플리케이션에 달려 있다. 게이트웨이는 통제와 증거를 제공할 뿐, 자동 인증을 제공하지는 않는다.
팀은 게이트웨이 외부에도 기록을 보존해야 한다. 인시던트 조사에는 애플리케이션 맥락, 모델 버전, 검색된 문서, 도구 결과, 사람의 승인 기록이 필요하다.
잘 관리된 기술 지식 베이스는 이러한 기록을 시스템 문서와 연결할 수 있다. 이 맥락은 조사자가 겉보기에는 유효한 요청이 예상치 못한 결과를 낳은 이유를 이해하는 데 도움이 된다.
마지막으로, 게이트웨이는 이를 통해 라우팅되는 트래픽만 거버넌스한다. 직원들은 여전히 승인되지 않은 채팅 서비스, 브라우저 확장 프로그램, 직접 발급된 제공업체 자격 증명 또는 로컬 모델을 사용할 수 있다.
F5는 섀도 AI를 위한 더 광범위한 통제와 통합할 수 있지만, 어떤 게이트웨이도 자체 집행 지점을 우회하는 트래픽을 포착할 수는 없다. 아키텍처 다이어그램은 관리되는 흐름과 단지 발견된 흐름을 구분해야 한다.
F5의 비용 절감 주장은 실제 워크로드 증거가 필요하다
토큰 지출을 30%에서 60%까지 낮출 수 있다는 약속은 일부 워크로드에서는 그럴듯하지만, 측정 기준선 없이는 이 범위가 거의 의미를 갖지 않는다.
시맨틱 캐싱은 반복되는 모델 호출을 피할 수 있다. 동일한 텍스트를 매칭하는 대신, 새 요청이 실질적으로 유사한 의미를 가질 때 답변을 재사용하려 한다.
이 방법은 안정적이고 반복적인 질의에서 가장 잘 작동한다. 고객 지원 답변, 내부 정책 질문, 일반적인 개발자 요청은 의미 있는 캐시 재사용을 만들어낼 수 있다.
답변이 최신 데이터, 사용자별 권한 또는 변화하는 대화 맥락에 의존할 때는 신뢰성이 떨어진다. 적합하지 않은 응답을 재사용하면 비용은 줄일 수 있지만 부정확한 정보를 초래할 수 있다.
스마트 라우팅은 또 다른 비용 절감 경로를 제공한다. 게이트웨이는 일상적인 분류 또는 추출 작업을 더 작은 모델로 보내고, 어려운 요청에는 더 큰 모델을 사용할 수 있다.
어려운 부분은 어떤 요청에 어떤 모델이 필요한지를 결정하는 것이다. 지나치게 공격적인 정책은 제공업체 청구액을 낮출 수 있지만 답변 품질을 떨어뜨리거나 재시도를 늘릴 수 있다.
모델 티어링에도 평가 데이터가 필요하다. 팀은 작업별 테스트를 통해 모델 간 정확도, 지연 시간, 안전성, 총비용을 비교해야 한다. 가격만으로 올바른 경로를 결정할 수는 없다.
GPU 인식 로드 밸런싱은 주로 조직이 프라이빗 또는 자체 호스팅 추론 인프라를 운영할 때 적용된다. 과부하된 가속기를 피해 요청을 전달함으로써 활용률을 개선할 수 있다.
하지만 인프라 절감과 토큰 절감은 동일하지 않다. 기업은 분석에서 제공업체 비용, GPU 활용률, 게이트웨이 비용, 엔지니어링 시간, 실패 요청 오버헤드를 구분해야 한다.
토큰 귀속은 여전히 즉각적인 가치를 제공할 수 있다. 많은 조직은 모델 사용량을 팀, 사용자, 애플리케이션과 연결하는 일관된 방법이 부족하다.
F5의 팀별 예산은 워크로드가 정의된 한도를 초과하기 전에 이를 중단할 수 있다. 이는 제공업체 청구서가 도착한 후 초과 지출을 발견하는 것보다 더 실행 가능하다.
하지만 예산은 행동을 왜곡하는 유인을 만들 수 있다. 팀은 임의의 한도 안에 머물기 위해 애플리케이션을 여러 계정에 분산하거나, 통제를 우회하거나, 성능이 낮은 모델을 선택할 수 있다.
따라서 비용 정책은 서비스 수준 목표와 연결되어야 한다. 사기 탐지 시스템과 내부 작성 지원 도구에 동일한 라우팅 또는 지출 규칙을 적용해서는 안 된다.
에이전트 도구 호출은 회계를 더욱 복잡하게 만든다. 직원 한 명의 요청이 계획 수립, 검색, 여러 도구 호출, 검증, 최종 모델 응답을 유발할 수 있다.
F5는 MCP Gateway가 중복 호출을 제거하고 관련 토큰 낭비를 최대 90%까지 줄일 수 있다고 말한다. 구매자는 제품이 중복을 어떻게 정의하는지, 그리고 이것이 에이전트의 실행 계획을 바꾸는지 물어봐야 한다.
정확히 반복된 호출을 막는 것은 비교적 안전하다. 그러나 기본 데이터가 그 사이에 바뀌었을 때 겉보기에 유사한 두 호출을 억제하는 것은 위험할 수 있다.
팀은 기록된 프로덕션 트레이스로 게이트웨이를 테스트해야 한다. 개별 요청당 소비된 토큰뿐 아니라 전체 작업 완료율을 비교해야 한다.
유용한 평가는 여러 차원을 포함해야 한다. 성공적인 결과, 재시도, 캐시 오류, 보안 차단, 지연 시간, 제공업체 지출, 인프라 사용량, 운영자 노력을 측정해야 한다.
기준선은 기존 통제도 반영해야 한다. F5를 전혀 최적화되지 않은 애플리케이션과 비교하면, 성숙한 라우팅 계층과 비교할 때보다 더 큰 겉보기 이득이 나타날 것이다.
그렇다고 비용 절감 주장이 무효가 되는 것은 아니다. 이는 이점이 게이트웨이라는 명칭 자체가 아니라 특정 워크로드와 정책 설계에 속한다는 뜻이다.
이 회사의 경제성 제안은 구매 대상층을 넓힌다. 보안팀은 정책 집행을, 플랫폼팀은 라우팅을, 재무팀은 귀속 기능을 얻는다.
이 연합은 도입을 가속할 수 있다. 하지만 낮은 지출, 더 강한 검사, 더 빠른 응답이 라우팅 결정을 서로 다른 방향으로 끌어갈 때 상충하는 목표를 만들 수도 있다.
F5 전략의 성과를 보여줄 세 가지 신호
다음 시험대는 또 다른 기능 발표가 아니다. 엔터프라이즈가 결합된 제어 플레인을 통해 의미 있는 프로덕션 트래픽을 라우팅하는지 여부다.
첫 번째 신호는 독립적으로 문서화된 고객 도입 사례다. F5는 Model Gateway, MCP Gateway, AI Guardrails를 함께 사용하는 프로덕션 배포 사례를 제시해야 한다.
이 사례에는 트래픽 규모, 배포 아키텍처, 정책 적용 범위, 측정 가능한 운영 결과가 포함되어야 한다. 대기업에 관한 익명 주장은 상세한 구현 사례보다 신뢰도가 낮다.
규제 산업의 증거는 특히 중요할 것이다. 금융 서비스, 의료, 정부 고객은 엄격한 ID, 레지던시, 감사, 가용성 요구사항에 직면한다.
해당 분야에서 성공적인 배포가 이루어진다면 F5의 통합 플랫폼 주장은 더 강해질 것이다. 실험적 애플리케이션에서의 제한적인 사용은 제품이 핵심 인프라가 아니라 추가 계층에 머물고 있음을 시사할 수 있다.
두 번째 신호는 비용 및 성능 주장에 대한 검증이다. 고객은 30%에서 60%에 이르는 토큰 절감 범위에 대해 재현 가능한 증거를 필요로 한다.
유용한 벤치마크는 워크로드 유형, 캐시 적중률, 모델 구성, 라우팅 규칙, 응답 품질, 게이트웨이 지연 시간을 공개해야 한다. 이러한 세부 정보가 없으면 백분율 절감 효과는 비교하기 어렵다.
독립 테스트는 부하 상태에서 가드레일도 평가해야 한다. 구매자는 콘텐츠 검사가 장애 상황에서 지연 시간, 처리량, 오탐, 가용성을 어떻게 변화시키는지 알아야 한다.
강력한 결과는 보안과 최적화가 하나의 요청 경로를 공유할 수 있다는 주장을 뒷받침할 것이다. 반대로 결과가 미약하다면 고속 라우팅과 심층 비동기 분석을 분리하는 아키텍처에 힘이 실릴 것이다.
세 번째 신호는 경쟁사의 대응이다. Citrix는 이미 모델과 MCP 거버넌스를 결합하고 있으며, Kong, 클라우드 플랫폼, 보안 업체들도 각자의 게이트웨이를 계속 확장하고 있다.
이들 업체가 F5의 공유 정책 모델, 배포 옵션, 애플리케이션 보안 통합 수준에 맞춰갈지 주시해야 한다. 기업들이 개별 게이트웨이 구성 요소를 교체할 수 있는 개방형 인터페이스를 요구하는지도 지켜볼 필요가 있다.
개방형 정책 형식으로의 전환은 강하게 묶인 플랫폼의 경쟁력을 약화할 것이다. 통합 보안 조달로의 변화는 F5와 다른 기존 인프라 제공업체를 강화할 것이다.
Google News는 통합 AI 거버넌스를 설명하는 발표를 계속 노출할 것이다. 더 중요한 일은 이런 헤드라인 이후에 벌어진다. 플랫폼 팀이 요청이 모델이나 도구에 도달하기 전에 반드시 거쳐야 할 지점을 결정할 때다.
엔터프라이즈 구매자는 게이트웨이를 선택하기 전에 실제 AI 트래픽을 파악해야 한다. 직접 모델 호출, 에이전트 도구, 민감한 데이터 경로, 승인되지 않은 서비스, 추가 지연을 감당할 수 없는 시스템을 식별해야 한다.
그다음 대표적인 프로덕션 워크플로 하나를 처음부터 끝까지 테스트해야 한다. 작업 품질, 차단된 요청, 데이터 노출, 응답 시간, 총비용, 그리고 각 의사결정을 설명하는 데 필요한 노력을 측정해야 한다.
F5는 AI 도구 확산에 대한 일관된 해답을 제시했다. 모델, 에이전트, 보안 전반을 아우르는 하나의 제어 평면이다. 향후 3개월은 고객이 이 제어 지점을 기반으로 볼지, 아니면 관리해야 할 또 하나의 제품으로 볼지를 보여줄 것이다.


