Snowflake의 Cortex AI Gateway, 에이전트 제어권 경쟁에 불을 붙이다

Snowflake는 Cortex AI Gateway를 출시한 뒤 google news에 진입했다. 그동안 Model Context Protocol 연결은 엔터프라이즈 인프라라기보다 개발자 통합에 가까워 보였다. 7월 28일 발표된 이 게이트웨이는 접근 정책, 인증, 활동 기록, 모델 라우팅, 사용량 제어를 중앙화한다. Snowflake는 100개 이상의 MCP 서버를 지원한다고 밝혔다.

중요한 변화는 또 하나의 커넥터 카탈로그가 아니다. Snowflake는 AI 에이전트와 이들이 접근할 수 있는 모델, 도구, 데이터, 애플리케이션 사이에 제어 계층을 배치하고 있다. 이는 이전 엔터프라이즈 소프트웨어 도입 물결에서 API 게이트웨이와 ID 플랫폼이 차지했던 역할과 닮아 있다.

Snowflake만의 움직임은 아니다. Databricks, Cloudflare, 보안 업체, 전문 스타트업들도 유사한 제어 지점을 구축하고 있다. 이제 경쟁의 초점은 Model Context Protocol이 널리 지원될지 여부가 아니다. 에이전트가 중요한 작업을 수행하기 시작하면 누가 MCP 트래픽을 관리할 것인가에 있다.

Snowflake, Cortex AI Gateway를 에이전트 제어 지점으로 전환하다

Cortex AI Gateway는 Snowflake의 거버넌스 경계를 저장된 데이터에서 AI 에이전트가 수행하는 작업으로 확장한다.

Snowflake는 이 제품을 자사 및 타사 에이전트를 위한 중앙화된 게이트웨이로 설명한다. 전자에는 Snowflake CoWork와 Snowflake CoCo가 포함된다. 후자에는 Claude Code와 Cursor 같은 외부 코딩 에이전트가 포함된다.

Model Context Protocol, 즉 MCP는 AI 애플리케이션이 일관된 인터페이스를 통해 외부 도구를 발견하고 호출할 수 있도록 하는 개방형 프로토콜이다. MCP 서버는 데이터베이스 쿼리, 문서 검색, 메시징 작업 또는 비즈니스 애플리케이션을 호출 가능한 도구로 노출할 수 있다.

이 프로토콜은 에이전트가 이러한 리소스를 사용하기 위해 필요한 맞춤형 통합 작업을 줄여 준다. 하지만 모든 연결을 승인하고, 모든 작업을 모니터링하며, 모든 비용을 배정할 수 있는 단일 지점을 기업에 자동으로 제공하지는 않는다.

Cortex AI Gateway는 이러한 운영상 공백을 메우도록 설계됐다. 게이트웨이 발표에 따르면 조직은 이를 사용해 어떤 에이전트가 특정 모델, MCP 서버, 애플리케이션, 도구에 접근할 수 있는지 정의할 수 있다.

Snowflake는 이 게이트웨이가 엔드투엔드 활동 기록도 생성한다고 밝혔다. 이 기록은 에이전트가 무엇을 했는지, 어떤 시스템에 접촉했는지, 어떤 순서로 작업을 수행했는지를 보여주기 위한 것이다.

이는 에이전트 상호작용이 하나의 모델 응답으로 끝나는 경우가 드물기 때문에 중요하다. 코딩 에이전트는 리포지토리를 검사하고, 이슈를 가져오고, 파일을 수정하고, 테스트를 실행한 뒤 다른 서비스에 접촉할 수 있다. 각 단계는 서로 다른 보안 또는 소유권 경계를 넘을 수 있다.

게이트웨이는 이러한 단계에 공통 검사 지점을 제공할 수 있다. 호출자를 인증하고, 권한을 평가하고, 요청을 기록한 뒤 승인된 작업을 목적지로 전달할 수 있다.

Snowflake는 이 검사 지점에 재무 제어 기능도 추가하고 있다. 회사는 Cortex AI Gateway가 AI 사용량을 팀, 에이전트 또는 워크로드별로 배분할 수 있다고 밝혔다. 관리자는 에이전트가 통제되지 않은 모델 사용량을 발생시키는 것을 막기 위한 지출 한도도 설정할 수 있다.

게이트웨이는 승인된 모델 전반에 걸친 요청 라우팅도 제공한다고 약속한다. Snowflake는 라우팅 결정이 품질, 지연 시간, 가용성, 사용 비용을 고려할 수 있다고 밝혔다. 따라서 이 제품은 모델 트래픽도 관리한다는 점에서 MCP 프록시보다 범위가 넓다.

Snowflake가 100개 이상의 MCP 서버를 지원한다는 점은 초기 연결 범위를 보여주는 지표다. 다만 이 숫자가 프로덕션 도입, 신뢰성 또는 보안 품질을 입증하는 것은 아니다. 지원 여부는 중요한 워크플로에서 실제로 이러한 연결을 운영하는 고객 수를 드러내지 않은 채 기술적 호환성만을 설명할 수 있다.

그럼에도 이번 출시는 Snowflake의 입지를 바꾼다. Cortex AI는 이미 모델을 호출하고 데이터 에이전트를 구축하는 환경이었다. 이제 Cortex AI Gateway는 Snowflake 밖에 주 인터페이스가 있는 에이전트를 포함해, 다른 곳에서 개발된 에이전트에 대한 관리 권한을 확보하려 한다.

이것이 인프라 측면의 신호다. Snowflake는 자신이 에이전트를 만들지 않았더라도 에이전트의 요청과 기업 작업 사이의 경로를 제어하려 한다.

Cortex AI Gateway가 지금 Google News에 등장한 이유

Snowflake는 MCP가 통합 표준으로 성공하면서 생긴 거버넌스 문제에 대응하고 있다.

MCP는 도구 연결을 이식 가능하게 만드는 방법으로 시작됐다. 개발자는 기능을 한 번 노출하고 여러 호환 AI 클라이언트가 이를 사용하도록 할 수 있었다. 하지만 여러 팀에 걸쳐 수십 개의 에이전트가 수백 개의 도구에 연결되면 이 모델은 관리가 어려워진다.

프로토콜 자체는 메시지와 상호작용 패턴을 정의한다. 인증 사양은 제한된 원격 서버를 위해 OAuth 표준에 기반한 프레임워크를 제공한다. 그러나 엔터프라이즈 거버넌스는 전송 단계의 인증을 넘어선다.

보안팀은 에이전트가 어떤 사람 또는 서비스를 대표하는지 파악해야 한다. 또한 해당 ID가 특정 파라미터로 특정 도구를 호출할 수 있는지 결정해야 한다. 승인 규칙, 데이터 유출 통제, 감사 보존, 긴급 권한 철회도 필요할 수 있다.

재무팀도 이와 유사한 문제에 직면한다. 하나의 워크플로는 결과를 반환하기 전에 여러 모델과 도구를 호출할 수 있다. 기존 클라우드 청구 체계는 소비된 서비스를 식별하지만, 어떤 에이전트가 그 연쇄를 시작했는지 또는 어느 부서가 혜택을 받았는지는 설명하지 못할 수 있다.

이런 문제는 중개 계층에 대한 시장을 만든다. 게이트웨이는 트래픽이 모델이나 MCP 서버에 도달하기 전에 이를 확인한다. 이 가시성 덕분에 게이트웨이는 정책을 적용하고 작업 시점에 더 가까운 곳에서 비용을 기록할 수 있다.

Snowflake는 Natoma를 통해 이러한 움직임을 준비했다. 5월 27일, AI 에이전트를 위한 엔터프라이즈 MCP 플랫폼을 구축한 이 회사를 인수하는 최종 계약을 체결했다. Snowflake는 이 거래가 데이터 자산에 대한 거버넌스를 AI 작업과 상호작용으로 확장할 것이라고 밝혔다.

Natoma 인수는 검증된 MCP 서버 라이브러리도 약속했다. Snowflake는 특히 이메일, Slack 및 기타 연결된 애플리케이션을 자사 플랫폼에 이미 보유한 데이터를 보강할 수 있는 소스로 지목했다.

그 계약과 Cortex AI Gateway 발표 사이의 짧은 간격은 전략적 우선순위를 보여준다. Snowflake는 인수한 MCP 기능을 고립된 커넥터 제품으로 유지하기보다 더 넓은 플랫폼 전략에 통합하고 있다.

이 시점은 Snowflake의 이전 AI 거버넌스 작업과도 맞물린다. 회사는 2025년 서밋에서 모델 접근, 사용량 추적, 역할 기반 제어, 예산 집행을 위한 AI Governance Gateway를 소개했다. 또한 Cortex Analyst와 Cortex Search를 위한 MCP 서버 지원도 별도로 발표했다.

Cortex AI Gateway는 이전까지 인접해 있던 이러한 관심사를 결합한다. 하나의 제안된 제어 플레인을 통해 모델 선택, MCP 접근, 에이전트 활동, 사용량을 관리한다.

이러한 통합은 엔터프라이즈 에이전트의 변화상을 반영한다. 일반적인 챗봇은 사용자가 검토할 텍스트를 생성한다. 에이전트는 사용자가 결과를 보기 전에 비공개 정보를 가져오고, 비즈니스 시스템을 호출하거나, 변경을 시작할 수 있다.

이러한 기능은 모델 접근만큼 도구 접근도 중요하게 만든다. 기업은 LLM을 승인하면서도 범위가 부적절하게 설정된 커넥터를 통해 위험에 노출될 수 있다. 각 애플리케이션을 보호하면서도 에이전트 작업 전체 연쇄에 대한 가시성을 잃을 수 있다.

Snowflake의 보안 통합은 이러한 과제의 일부를 다룬다. 초기 그룹에는 1Password, Aembit, Linx Security, Okta, SailPoint, Saviynt가 포함된다. 이들의 참여는 에이전트 ID 및 접근 거버넌스가 공동 인프라의 관심사로 부상하고 있음을 시사한다.

따라서 이 게이트웨이가 google news 결과 전반에 등장한 것은 더 큰 변화와 연결돼 있다. MCP 연결성은 개발자 편의성의 영역에서 ID 팀, 보안 운영, 재무, 플랫폼 엔지니어링의 영역으로 이동하고 있다.

Snowflake와 Databricks는 동일한 제어 플레인을 놓고 경쟁한다

핵심 경쟁은 기존 데이터 플랫폼이 모든 모델 및 MCP 요청을 관리해야 하는지를 둘러싼 Snowflake와 Databricks의 대결이다.

Databricks는 Unity AI Gateway를 통해 매우 유사한 주장을 내세우고 있다. 해당 문서는 이 서비스를 에이전트, 모델 엔드포인트, MCP 서버, 코딩 도구를 위한 중앙 거버넌스 계층으로 설명한다.

유사점은 분명하다. 두 플랫폼 모두 AI 트래픽을 라우팅하고, 권한을 집행하며, 사용량을 관찰하고, 여러 제공업체에 걸친 소비를 관리하려 한다. 또한 둘 다 이 런타임 계층을 엔터프라이즈 데이터에 이미 사용되는 거버넌스 시스템과 연결한다.

Databricks는 Unity Catalog를 접근 방식의 중심에 둔다. 이 카탈로그는 모델, 함수, MCP 서버 같은 자산을 관리한다. Unity AI Gateway는 요청이 시스템을 통과하는 동안 해당 권한과 정책을 적용한다.

현재 AI 거버넌스 가이드에 따르면 게이트웨이는 Claude Code, Cursor, Codex, Gemini CLI를 포함한 외부 코딩 에이전트를 관리할 수 있다. 또한 속도 제한, 예산, 사용량 추적, 요청 수준 서비스 정책도 설명한다.

Snowflake 역시 자체 발표에서 Claude Code와 Cursor를 언급한다. 이 중복은 중요하다. 어느 회사도 게이트웨이를 자사 플랫폼 안에서 구축된 에이전트로 제한하지 않는다.

양사는 모두 다른 곳에서 만들어진 에이전트를 위한 중립적 제어 지점이 되려 한다. 다만 제어 계층이 주변 데이터 플랫폼을 강화한다는 점에서 중립성은 상대적이다.

고객에게 당장의 선택은 대개 기존 인프라를 따를 것이다. Snowflake 정책, 데이터, 운영 지식이 광범위한 기업은 Cortex AI Gateway를 통해 이러한 제어를 확장하는 방식을 선호할 수 있다. Databricks 고객은 Unity Catalog 기반 경로에서 마찰이 더 적다고 볼 수 있다.

장기 경쟁은 예측하기 어렵다. 에이전트는 데이터 웨어하우스, 소프트웨어 리포지토리, 메시징 시스템, 고객 플랫폼, 클라우드 서비스 전반에서 일상적으로 작업한다. 단일 데이터 플랫폼이 이 모든 목적지를 소유하지는 않는다.

따라서 게이트웨이는 모든 워크플로를 폐쇄형 스택으로 강제하지 않으면서도 자사 홈 플랫폼 밖의 리소스를 관리할 수 있음을 입증해야 한다. Snowflake의 보안 통합과 Natoma 커넥터는 이러한 주장을 뒷받침하기 위한 것이다.

Databricks도 외부 제공업체와 코딩 에이전트를 포괄함으로써 유사한 상호운용성 논리를 제시한다. 게이트웨이는 2026년 7월에 업데이트된 문서에서 여전히 베타로 표시돼 있어, 가용성과 구현 방식이 바뀔 여지는 남아 있다.

어느 업체도 공개 도입 데이터를 통해 결정적 우위를 입증하지는 못했다. 기능 목록은 전략적 수렴을 보여주지만, 어느 게이트웨이가 더 많은 프로덕션 트래픽을 처리하거나 더 많은 정책 위반을 막는지는 보여주지 않는다.

경쟁은 데이터 플랫폼 범주 밖에서도 이어진다. Cloudflare는 접근 계층 뒤에서 여러 서버를 집계하는 MCP 서버 포털을 도입했다. 포털 문서는 OAuth 지원과 개별 도구 요청에 대한 로그를 설명한다.

Cloudflare는 네트워크 및 접근 인프라 관점에서 이 문제에 접근한다. ID 공급업체는 자격 증명과 인증을 통해 접근한다. 전문 게이트웨이 업체는 MCP 발견, 검사, 정책 집행에 집중한다.

이러한 접근 방식은 하나의 기업 안에서 공존할 수 있지만, 제어 체계가 겹치면 운영 마찰이 발생한다. 팀은 어떤 곳에 권위 있는 정책을 둘지, 어떤 시스템이 완전한 감사 추적을 보관할지 결정해야 할 수 있다.

중복된 게이트웨이는 책임 소재도 흐릴 수 있다. 하나의 요청이 에이전트 플랫폼, 모델 게이트웨이, MCP 게이트웨이, 네트워크 프록시, 애플리케이션 인가 계층을 차례로 통과할 수 있다. 각 시스템은 서로 다른 ID나 의사결정을 기록할 수 있다.

Snowflake의 목표는 이러한 제어 체계를 통합해 분절을 줄이는 것이다. 위험은 고객이 서로 연결되지 않은 여러 도구를 특정 벤더와 긴밀히 결합된 하나의 제어 지점으로 대체하게 된다는 데 있다.

이러한 긴장은 구매 결정을 좌우할 것이다. 기업은 일관된 거버넌스를 원하지만, 동시에 모델, 에이전트, 데이터 시스템을 자유롭게 바꿀 수 있기를 바란다. 승리하는 게이트웨이는 상호운용성을 종속성으로 바꾸지 않으면서 중앙 집중식 제어를 제공해야 한다.

게이트웨이 메커니즘이 MCP를 인프라처럼 보이게 하는 이유

MCP 게이트웨이는 유용한 모든 에이전트 연결이 ID, 정책, 라우팅, 관측 가능성, 비용 귀속에 대한 반복적 요구를 만들어 내기 때문에 인프라로 자리 잡고 있다.

기본적인 MCP 연결은 기술적 질문에 답한다. 에이전트는 어떻게 도구를 발견하고 호출할 수 있는가? 엔터프라이즈 게이트웨이는 운영상 질문에 답한다. 어떤 조건에서 그러한 호출을 허용해야 하는가?

한 직원이 코딩 에이전트에게 프로덕션 장애를 조사해 달라고 요청한다고 가정해 보자. 에이전트는 기술 문서를 검색하고, 리포지토리를 살펴보고, 로그를 조회하고, 티켓을 열고, 변경안을 작성할 수 있다.

각 도구 호출은 이전 단계의 컨텍스트를 이어받는다. 에이전트는 직원의 ID, 권한, 의도를 일정한 형태로 함께 전달한다. 이 연결 고리에서 실수가 발생하면 데이터가 노출되거나, 직원이 요청하지 않은 작업이 승인될 수 있다.

게이트웨이는 실행 전에 호출을 평가할 수 있다. 사용자가 접근할 수 없는 도구를 거부하고, 파라미터를 제한하거나, 쓰기 작업에 승인을 요구할 수 있다. 또한 해당 작업을 요청을 시작한 사용자와 에이전트에 연결하는 기록을 보존할 수 있다.

이는 추상적인 규칙이 허용, 거부 또는 승인 결정으로 바뀌는 위치인 정책 집행 지점이다. 이 개념은 API 관리, 제로 트러스트 접근, 클라우드 ID 시스템에서 익숙하다.

에이전트 트래픽은 이 결정을 더 복잡하게 만든다. 요청은 종종 확률적으로 생성되며, 다음에 사용할 도구는 이전 단계에서 가져온 신뢰할 수 없는 콘텐츠에 따라 달라질 수 있다.

악성 지침이 포함된 문서는 에이전트가 다른 도구를 호출하도록 영향을 줄 수 있다. 침해된 MCP 서버는 이후 동작을 바꾸기 위한 콘텐츠를 반환할 수 있다. 범위가 지나치게 넓은 토큰은 에이전트가 원래 작업 범위를 넘어선 데이터에 접근하도록 만들 수 있다.

중앙화된 활동 기록은 조사자가 이러한 연결 고리를 재구성하는 데 도움이 된다. 하지만 모든 공격을 막지는 못한다. 예방에는 제한된 자격 증명, 안전한 도구 설계, 입력 검증, 격리, 신중한 승인 워크플로도 필요하다.

라우팅은 또 다른 인프라 기능을 더한다. 조직은 서로 다른 워크로드에 사용할 여러 언어 모델을 승인할 수 있다. 한 모델은 복잡한 추론에 적합하고, 다른 모델은 더 낮은 지연 시간으로 일상적인 추출 작업을 처리할 수 있다.

게이트웨이는 각 애플리케이션이 별도의 공급자 로직을 구현하지 않아도 승인된 옵션 중에서 선택할 수 있다. 엔드포인트를 사용할 수 없게 되면 트래픽을 다른 곳으로 우회할 수도 있다.

이러한 유연성은 애플리케이션 결합도를 낮출 수 있다. 다만 라우팅 품질은 평가 데이터와 명확한 워크로드 정책에 달려 있다. 조직이 수용 가능한 트레이드오프를 정의하지 않으면, 게이트웨이는 비즈니스 우선순위를 신뢰성 있게 추론할 수 없다.

비용 귀속도 마찬가지로 가치가 있지만 어렵다. 단일 요청의 토큰 수를 세는 일은 간단하다. 여러 단계로 이뤄진 워크플로의 전체 비용을 부서, 프로젝트 또는 사용자에게 배정하려면 모든 홉에서 일관된 ID가 필요하다.

Snowflake는 Cortex AI Gateway가 책임 있는 팀, 에이전트 또는 워크로드에 사용량을 귀속할 수 있다고 말한다. 구매자는 외부 에이전트가 분리된 시스템 전반에서 여러 도구와 모델을 호출할 때 이러한 귀속이 어떻게 작동하는지 살펴봐야 한다.

또한 예산 집행이 워크플로를 안전하게 중단하는지도 테스트해야 한다. 에이전트를 중간에 멈추면 부분 변경, 열린 트랜잭션 또는 미완성 기록이 남을 수 있다.

이러한 제어 기능이 개별 애플리케이션에서 사라질 때 인프라 비유는 가장 강력해진다. 개발자는 새로운 에이전트마다 인증, 로깅, 라우팅, 예산 로직을 다시 만들 필요가 없어야 한다.

이런 기능을 표준화하면 배포를 가속할 수 있다. 동시에 게이트웨이를 고가치 공격 대상이자 핵심 의존성으로 만들 수도 있다.

시장이 게이트웨이 아키텍처로 수렴하는 이유가 여기에 있다. MCP가 도구 접근성을 높일수록, 기업은 그 이식성을 제한할 일관된 계층을 더 필요로 한다.

보안 주장은 여전히 프로덕션 증거가 필요하다

중앙화된 게이트웨이는 제어를 개선하지만, MCP 연결을 기본적으로 안전하게 만들거나 도구 자체의 위험을 제거하지는 않는다.

Snowflake의 발표는 에이전트 상호운용성의 기반으로 보안과 신뢰를 제시한다. 이는 합리적인 목표이지만, 회사는 이 주장을 독립적으로 확립된 사실로 받아들이기에 충분한 증거를 공개하지 않았다.

발표에는 Cortex AI Gateway의 프로덕션 도입 고객 수가 제시되지 않았다. 차단한 공격, 정책 위반, 라우팅 정확도, 사용량 제어로 인한 절감 효과도 수치화하지 않았다.

100개가 넘는 MCP 서버 지원은 신뢰성이 아니라 호환성을 측정한다. 게이트웨이는 각 서버, 해당 도구, 버전, 필요한 권한에 대한 정확한 정보가 여전히 필요하다.

보안 과제는 게이트웨이 아래 계층까지 이어진다. 승인된 서버에도 취약한 코드가 있을 수 있다. 정상적인 도구가 위험한 파라미터를 노출할 수 있다. 에이전트는 악의적인 컨텍스트를 처리한 뒤 허용된 기능을 오용할 수도 있다.

정부 지침도 이러한 한계를 강조한다. NSA의 2026년 5월 MCP 보안 지침은 MCP를 사실상의 통신 표준으로 설명하지만, 보안 수준은 여전히 고르지 않다고 말한다.

이 보고서는 동적 도구 호출, 암묵적 신뢰, 컨텍스트 공유, 취약한 접근 제어, 프롬프트 인젝션, 토큰 수명주기 공백을 지적한다. 많은 보호 장치가 프로토콜 보장보다는 구현상의 규율에 의존한다고 설명한다.

이 구분은 Cortex AI Gateway를 평가할 때 중요하다. 게이트웨이는 인증과 인가를 중앙화할 수 있지만, 연결된 모든 서버를 사후적으로 안전하게 만들 수는 없다.

또한 에이전트가 사용자의 요청을 정확히 해석했다고 보장할 수도 없다. 어떤 작업을 수행할 권한이 있다고 해서 그 작업이 사용자의 의도와 일치한다는 증거는 아니다.

승인 워크플로는 이 간극을 줄일 수 있다. 고위험 변경은 사람이 정확한 제안 작업, 파라미터, 예상 효과를 검토하도록 해야 한다. 사용자가 에이전트가 무엇을 할지 볼 수 없다면, 일반적인 권한 프롬프트는 보호 효과가 거의 없다.

구매자는 Snowflake가 위임된 ID를 어떻게 처리하는지 물어야 한다. 직원을 대신해 행동하는 에이전트는 해당 작업에 필요한 권한만 받아야 한다. 워크플로가 여러 시스템을 넘나든다는 이유만으로 광범위한 서비스 자격 증명을 상속해서는 안 된다.

해지도 살펴봐야 한다. 사용자가 역할을 바꾸거나 토큰이 침해된 경우, 게이트웨이는 추가 접근을 신속히 중단해야 한다. 캐시된 자격 증명과 장시간 실행되는 에이전트 세션은 이러한 대응을 복잡하게 만들 수 있다.

로깅에는 자체적인 트레이드오프가 있다. 상세 기록은 감사와 사고 대응에 도움이 되지만, 프롬프트와 도구 파라미터에는 민감한 정보가 포함될 수 있다. 조직은 로그 자체에 대한 보존, 비식별화, 접근 규칙이 필요하다.

게이트웨이의 모델 라우팅도 같은 수준의 검토가 필요하다. 품질, 지연 시간, 가용성, 사용량 전반을 최적화하는 일은 유용해 보인다. 하지만 이러한 목표는 충돌할 수 있고, 자동화된 선택은 출력 품질이나 데이터 처리 의무에 영향을 줄 수 있다.

기업은 라우팅이 데이터를 승인된 리전과 공급자 내에 유지하는지 검증해야 한다. 또한 모델 변경 사항이 애플리케이션 소유자에게 표시되고 감사 중 재현 가능한지도 확인해야 한다.

벤더 집중은 또 다른 위험을 제시한다. 에이전트 트래픽, 도구 권한, 모델 라우팅, 비용 제어를 하나의 시스템에 배치하면 광범위한 운영 의존성이 생긴다. 해당 계층의 장애나 정책 오류는 많은 워크플로를 동시에 중단시킬 수 있다.

이것이 게이트웨이 모델을 무효화하는 것은 아니다. 게이트웨이는 편의 기능이 아니라 ID, 네트워크, API 인프라처럼 평가해야 한다는 뜻이다.

Snowflake의 입지는 이미 자사의 거버넌스 모델에 투자한 고객에게 도움이 될 수 있다. 하지만 구매자에게는 여전히 독립적인 테스트, 최소 권한 설계, 서버 인벤토리, 격리된 실행, 사고 대응 절차가 필요하다.

따라서 google news 헤드라인을 책임감 있게 해석하면 Snowflake의 마케팅 문구보다 더 좁은 결론에 이른다. Cortex AI Gateway는 시장의 방향을 보여주지만, 하나의 플랫폼이 전체 에이전트 수명주기를 보호할 수 있는지에 대한 답을 내리지는 못한다.

Google News 독자가 다음에 주목해야 할 점

게이트웨이 논지는 도입, 집행 증거, 크로스플랫폼 동작이 출시 주장을 넘어설 때에만 신뢰성을 갖게 될 것이다.

첫 번째 신호는 프로덕션 사용량이다. Snowflake는 단순히 지원하는 MCP 서버 수가 아니라, 얼마나 많은 고객이 Cortex AI Gateway를 통해 활성 상태의 타사 에이전트를 라우팅하는지 공개해야 한다.

유용한 증거에는 거버넌스가 적용된 도구 호출 수, 외부 시스템의 범위, 강제 정책을 사용하는 워크플로의 비중이 포함될 것이다. 고객 사례 연구는 신뢰에 관한 일반적인 표현을 반복하는 대신 구체적인 작업을 밝혀야 한다.

Meltwater는 Snowflake 발표에서 에이전트를 데이터와 도구에 안전하게 연결하는 데 관심이 있는 조직으로 등장했다. 해당 표현은 Cortex AI Gateway를 그 결과를 향한 한 단계로 묘사했다. 측정된 결과를 갖춘 완료된 배포를 입증하지는 않았다.

이 차이는 추적할 가치가 있다. 디자인 파트너는 제품 방향을 검증할 수 있지만, 지속적인 프로덕션 트래픽은 신뢰성, ID 매핑, 운영 비용을 시험한다.

두 번째 신호는 집행 품질이다. Snowflake는 사용자 ID나 작업 컨텍스트를 잃지 않으면서 자사 및 타사 에이전트 전반에 정책이 작동함을 보여줘야 한다.

구매자는 개별 도구와 파라미터에 대한 세분화된 제어를 찾아야 한다. 또한 승인 정책, 토큰 해지, 데이터 유출 방지, 기존 보안 모니터링 시스템과의 통합도 지켜봐야 한다.

공개된 사고 보고서는 가치 있는 증거를 제공할 수 있다. 신뢰할 수 있는 제어 플레인은 안전하지 않은 동작을 어떻게 탐지했는지, 무엇을 차단했는지, 관리자가 어떻게 사건을 재구성했는지를 설명할 수 있어야 한다.

세 번째 신호는 경쟁사의 대응이다. Databricks, Cloudflare, ID 벤더, 독립 게이트웨이 제공업체는 각자의 에이전트 제어 기능을 계속 확장할 것이다.

이들 제품이 이식 가능한 정책 형식과 공유된 감사 표준으로 수렴한다면, 기업은 모든 규칙을 다시 만들지 않고도 게이트웨이를 바꿀 수 있다. 그러한 결과는 MCP를 개방형 인프라로서 강화할 것이다.

각 플랫폼이 독점적인 ID, 정책 모델, 로그를 만든다면, MCP는 연결 계층에서는 개방적으로 남더라도 거버넌스는 분절될 수 있다. 이는 상호 교환 가능한 에이전트 도구라는 약속을 약화시킬 것이다.

개발자는 게이트웨이가 디버깅 정보를 어떻게 노출하는지 살펴봐야 한다. 거부된 요청에는 이해할 수 있는 이유가 필요하고, 라우팅된 요청에는 어떤 모델과 정책이 영향을 미쳤는지 보여 주는 추적 정보가 필요하다.

보안 팀은 하나의 게이트웨이가 전체 작업 체인을 볼 수 있는지 평가해야 한다. 에이전트가 모니터링되지 않는 시스템을 거칠 때 부분적인 가시성은 오해를 부르는 안도감을 만들 수 있다.

엔터프라이즈 구매자는 제어 플레인의 장애 모드도 비교해야 한다. 게이트웨이 장애 시 에이전트가 안전하게 중지되는지, 읽기와 쓰기 작업이 다르게 동작하는지, 긴급 접근은 어떻게 작동하는지 알아야 한다.

지식 근로자들은 이러한 선택에 이해관계가 있습니다. 게이트웨이 정책이 어시스턴트가 접근할 수 있는 정보의 범위를 결정하기 때문입니다. 더 나은 제어 기능은 모든 에이전트에 이메일, 문서, 메시징 시스템에 대한 영구적인 접근 권한을 부여하지 않으면서도 유용한 연결을 지원할 수 있습니다.

검색 가능한 기술 컨텍스트를 구축하는 팀은 권한을 원본 자료에 연결된 상태로 유지해야 합니다. 잘 설계된 engineering knowledge base는 에이전트가 일부 정보만 필요로 할 때 광범위한 리포지토리를 노출해야 할 필요를 줄여줍니다.

향후 1~3개월은 Cortex AI Gateway가 실질적으로 작동하는 제어 지점이 될지, 아니면 전략적 발표에 머물지를 분명히 보여줄 것입니다. 명시된 프로덕션 배포 사례, 측정 가능한 정책 집행 결과, 그리고 Snowflake 자체 환경을 넘어서는 더 깊은 통합을 주시해야 합니다.

Snowflake는 인프라에 대한 베팅을 분명히 했습니다. 기업들이 모델 라우팅, MCP 거버넌스, 활동 기록, 사용량 제어를 결합한 중앙화된 계층을 통해 에이전트를 관리하게 될 것이라고 보고 있습니다.

이러한 베팅은 이식 가능한 도구가 이식 가능한 제어 수단에 대한 필요를 만들어내기 때문에 방향성 측면에서 타당해 보입니다. 아직 해결되지 않은 질문은 누가 그 제어 플레인을 운영할 권리를 얻게 될 것인가입니다.

Google 뉴스 보도는 출시 순간을 포착했습니다. 더 중요한 시험은 기업들이 민감한 데이터를 읽고, 실제 리소스를 사용하며, 프로덕션 시스템을 변경할 수 있는 에이전트를 연결할 때 시작됩니다. 어떤 MCP 게이트웨이든 신뢰할 수 있는 인프라로 간주하기 전에, 조직이 모든 에이전트를 식별하고 모든 도구를 제한하며 모든 작업을 재구성할 수 있는지 자문해 보십시오.