Google-managed MCP 서버가 엔터프라이즈 AI Agent 운영에 던지는 질문

Google Cloud가 Google 서비스 전반에 managed MCP 서버 지원을 넓히면서, 기업 AI agent 운영의 질문은 “MCP 서버를 어디에 설치할 것인가”에서 “누가 어떤 도구를 어떤 권한과 감사 경계 안에서 호출하게 할 것인가”로 이동하고 있다.

이 변화는 단순한 connector 추가가 아니다. MCP가 AI 애플리케이션과 외부 데이터·도구를 연결하는 표준 인터페이스라면, managed MCP 서버는 그 인터페이스를 개별 개발자 노트북이나 임시 서버가 아니라 cloud provider의 governance plane으로 끌어올리는 방식이다.

왜 managed MCP가 운영 이슈인가

초기 MCP 도입은 대개 local MCP server 설치, JSON 설정, client 연결, tool 호출 성공 여부에 집중했다. 이 단계에서는 “연결된다”가 성과처럼 보인다. 하지만 enterprise 환경에서는 연결 성공보다 더 어려운 질문이 바로 다음에 온다.

• agent가 접근할 수 있는 데이터 범위는 어디까지인가?
• tool 호출은 어떤 identity와 OAuth scope로 실행되는가?
• 실패하거나 과도한 호출이 발생했을 때 audit trail은 남는가?
• prompt injection이나 data exfiltration 시도는 어디에서 차단하거나 조사할 수 있는가?
• 동일한 tool을 여러 agent runtime에서 재사용할 때 registry와 lifecycle은 어떻게 관리되는가?

Google Cloud의 managed MCP 발표는 이 질문들을 provider-managed endpoint, IAM, registry, audit log, safety layer의 문제로 재배치한다.

Google 발표에서 봐야 할 핵심

Google Cloud는 2025년 12월 Google services에 대한 official MCP support를 발표했고, 2026년 4월에는 50개 이상의 Google-managed MCP servers가 available 또는 preview 상태라고 설명했다. 대상은 Google Cloud 서비스뿐 아니라 Google ecosystem 전반으로 확장된다.

중요한 포인트는 “MCP server가 많아졌다”가 아니다. Google은 managed remote MCP server를 통해 AI agent와 standard MCP client가 Google/Google Cloud services에 연결할 수 있는 일관된 endpoint를 제공한다고 설명한다. 또한 Agent Registry, Cloud IAM, IAM Deny policies, Model Armor, OpenTelemetry tracing, Cloud Audit Logs 같은 운영 요소를 함께 강조한다.

즉 managed MCP는 connector catalog가 아니라 agent access plane에 가깝다.

BigQuery MCP 사례: 데이터는 context window 밖에 둔다

BigQuery MCP server 문서가 보여주는 운영 관점은 명확하다. agent가 enterprise data를 다룬다고 해서 원천 데이터를 prompt context로 옮기는 방식만 있는 것은 아니다. BigQuery remote MCP server는 AI application이나 agent가 BigQuery metadata를 읽고 SQL query를 실행하는 흐름을 MCP tool로 제공한다.

문서상 BigQuery MCP server는 OAuth 2.0과 IAM을 사용하며, API key를 받지 않는다. 또한 MCP tool call 권한, BigQuery job 생성 권한, BigQuery data 조회 권한이 각각 role과 permission으로 분리된다.

이 구조가 중요한 이유는 agent 운영자가 다음과 같은 경계를 설계할 수 있기 때문이다.

• agent runtime에는 전체 dataset을 주입하지 않는다.
• MCP tool call 권한과 실제 BigQuery data 권한을 별도로 본다.
• query 실행 주체와 audit log를 cloud control plane에서 추적한다.
• dataset/table metadata 접근과 실제 data read를 같은 권한으로 뭉개지 않는다.

AI agent가 데이터를 “알게 하는 것”보다, 데이터를 “어떤 권한으로 조회하게 할 것인가”가 더 중요한 운영 문제가 되는 지점이다.

MCP Authorization과 managed endpoint의 접점

MCP 2025-11-25 authorization specification은 HTTP-based transport에서 Protected Resource Metadata, authorization server discovery, OAuth role, `WWW-Authenticate` scope challenge를 다룬다. 여기서 중요한 것은 MCP server가 단순한 tool 목록 제공자가 아니라 protected resource로 취급된다는 점이다.

특히 scope challenge는 운영자에게 중요한 신호다. client는 현재 요청에 필요한 scope를 challenge에서 읽고, 이 scope를 임의로 확대하거나 일반화해서는 안 된다. 또한 이 authorization 흐름은 HTTP-based transport 기준이며, STDIO transport에는 그대로 일반화하면 안 된다.

Managed MCP server가 늘어날수록 기업의 checklist는 다음 순서로 바뀐다.

1. 어떤 MCP endpoint가 protected resource인가?
2. 해당 endpoint의 authorization server는 어디인가?
3. 어떤 scope가 어떤 tool 호출에 필요한가?
4. scope와 IAM role은 실제 데이터·인프라 권한과 어떻게 매핑되는가?
5. 실패한 401 challenge와 성공한 tool call은 audit log에서 어떻게 연결되는가?

운영자가 먼저 고쳐야 할 것

Google-managed MCP 서버를 바로 production agent에 붙이는 것보다 먼저 해야 할 일은 “agent access inventory”를 만드는 것이다. 최소한 다음 네 가지가 필요하다.

첫째, MCP server registry다. 어떤 agent가 어떤 MCP server를 쓰는지, server URL, transport, product owner, data domain, allowed tools를 기록해야 한다. Google의 Agent Registry 같은 개념은 이 작업을 provider plane에서 풀려는 시도다.

둘째, permission matrix다. BigQuery처럼 MCP tool call 권한과 실제 service 권한이 나뉘는 경우, agent별·tool별·dataset별 권한을 별도 행으로 관리해야 한다. “이 agent는 BigQuery MCP를 쓴다”는 설명만으로는 부족하다.

셋째, audit correlation이다. MCP client request, OAuth identity, cloud audit log, downstream service action을 하나의 incident timeline으로 묶을 수 있어야 한다. agent가 실행한 SQL, infrastructure action, file access는 “agent output”이 아니라 운영 event로 다뤄야 한다.

넷째, prompt-injection boundary다. Google은 Model Armor 같은 safety layer를 언급하지만, 이것이 모든 indirect prompt injection과 data exfiltration 위험을 제거한다는 뜻은 아니다. 운영자는 untrusted content가 tool instruction으로 승격되지 않도록 data source, prompt, tool call 사이의 정책을 분리해야 한다.

AWS AgentCore Gateway와의 연결점

이 블로그의 기존 글에서 다룬 AWS Bedrock AgentCore Gateway나 MCP Authorization 주제와도 연결된다. AWS 쪽 논점이 enterprise MCP deployment를 gateway 중심으로 묶는 방식이었다면, Google-managed MCP 서버는 provider-managed endpoint와 cloud-native governance stack을 전면에 둔다.

공통점은 분명하다. agent tool 운영은 더 이상 “LLM이 어떤 tool을 부를 수 있는가”만의 문제가 아니다. gateway, registry, IAM, OAuth, audit, observability, safety control이 결합된 운영면을 설계해야 한다.

차이점도 있다. 특정 provider의 managed MCP server는 그 provider의 IAM, audit, product boundary 안에서는 강하지만, multi-cloud·SaaS·internal API가 섞이는 환경에서는 별도의 cross-provider registry와 policy normalization이 필요하다.

실무 체크리스트

Google-managed MCP server를 검토하는 팀이라면 다음 순서로 작은 실험을 시작하는 편이 안전하다.

1. 읽기 전용 데이터 domain 하나를 고른다. 예: BigQuery sample dataset, 문서 검색, metadata lookup.
2. MCP server endpoint, required OAuth scope, IAM role을 문서화한다.
3. agent runtime에는 최소 권한 identity만 연결한다.
4. tool call log와 Cloud Audit Logs가 같은 사건으로 추적되는지 확인한다.
5. prompt에 들어온 외부 문서가 tool call instruction으로 오염되는 경로를 테스트한다.
6. 실패한 authorization challenge를 운영자가 해석할 수 있는 runbook으로 만든다.
7. write action, infrastructure action, payment/actionable workflow는 별도 승인 gate 뒤로 둔다.

이 순서를 지키면 managed MCP의 장점인 표준화와 governance를 살리면서도, agent가 cloud resource를 너무 빨리 직접 조작하는 위험을 줄일 수 있다.

결론

Google-managed MCP 서버의 핵심 의미는 MCP가 “개발자 편의 connector”에서 “enterprise agent access plane”으로 이동하고 있다는 점이다. 앞으로 AI agent 운영 역량은 모델 성능보다도 tool registry, identity, scope, audit, prompt-injection boundary를 얼마나 잘 설계하는지에서 갈릴 가능성이 크다.

기업이 지금 해야 할 일은 모든 MCP server를 한 번에 붙이는 것이 아니다. 하나의 읽기 전용 use case를 골라 managed MCP endpoint, IAM, OAuth scope, audit log, safety policy가 실제로 하나의 운영 흐름으로 닫히는지 검증하는 것이다. 그 검증이 끝난 뒤에야 agent에게 더 넓은 tool access를 맡길 수 있다.

---

참고한 공식 자료:

• Google Cloud Blog, “Announcing Model Context Protocol (MCP) support for Google services”
• Google Cloud Blog, “Google-managed MCP servers are available for everyone”
• Model Context Protocol Specification 2025-11-25
• Model Context Protocol Authorization Specification 2025-11-25
• Google Cloud Documentation, “Use the BigQuery MCP server”