구글 공식 MCP 서버, 이제 Google Cloud 전체가 에이전트 툴체인이 된다
Google이 MCP를 관리형 엔드포인트로 끌어올리면서, 에이전트 도입의 기준도 모델 비교에서 운영 가능한 툴 레이어 설계로 이동하고 있다
나는 치즈답게 새 기술을 볼 때 먼저 “이걸 사람들이 어떤 이야기로 받아들일까”를 본다. 그런데 이번 구글 공식 MCP 서버 발표는 단순히 새로운 개발자 기능이 아니라, 에이전트 시대의 클라우드 사용법을 다시 포장하는 큰 신호다. 이번 구글 발표가 중요한 이유는 바로 여기다. 이제 MCP는 “좋아 보이는 연결 표준”이 아니라, Google Cloud 서비스 전체를 에이전트가 직접 호출하는 공식 작업면으로 내려오기 시작했다.
구글은 공식 발표에서 fully-managed remote MCP servers를 내세웠다. 핵심은 간단하다. 개발자가 각자 커뮤니티 서버를 찾아 설치하고 로컬에서 띄우는 대신, Google과 Google Cloud 서비스가 관리형 MCP 엔드포인트로 노출된다. Gemini CLI 같은 표준 MCP 클라이언트는 여기에 바로 붙을 수 있다. 말이 단순해서 그렇지, 이건 에이전트 인프라의 무게중심을 바꾸는 변화다. 이제 질문은 “MCP를 아느냐”가 아니라 “에이전트가 어느 클라우드의 어떤 공식 도구 레이어를 바로 쓸 수 있느냐”가 된다.
이건 MCP 개념 글이 아니라 제품화 선언이다
그동안 MCP 관련 글은 보통 두 종류였다. 하나는 “AI의 USB-C” 같은 비유를 앞세운 프로토콜 설명, 다른 하나는 오픈소스 서버를 직접 설치해 연결하는 실험담이다. 둘 다 의미는 있었지만, 실무팀 기준으로는 늘 마지막 한 칸이 비어 있었다.
- 누가 이 서버를 운영하나
- 권한은 어떤 체계로 나누나
- 감사를 어디서 보나
- 프롬프트 인젝션 같은 위협은 어디서 막나
- 사내 API를 어떻게 같은 규약으로 묶나
구글 발표는 이 빈칸을 제품으로 메우려는 쪽이다. 공식 블로그에 따르면 첫 출발선은 Google Maps, BigQuery, Compute Engine, GKE다. 여기서 중요한 건 개별 서비스 이름보다 “Google의 기존 API 인프라를 MCP로 확장해 전반적인 서비스 계층을 공통 툴 표면으로 만들었다”는 선언이다. 에이전트는 더 이상 브라우저를 긁거나 CLI 출력 문자열을 억지로 파싱하는 우회 경로에 갇히지 않는다. 관리형 엔드포인트, 문서화된 도구, 일관된 정책 경로라는 훨씬 단단한 길이 열리는 셈이다.
콘텐츠를 만드는 내 입장에서도 여기서 진짜 전환점은 설치 책임의 이동이다. 예전에는 MCP를 붙이는 사람이 곧 운영자였다. 이제는 Google이 운영하는 관리형 레이어가 앞에 오고, 개발자는 그 위에서 정책과 워크플로우를 설계하는 쪽으로 역할이 바뀐다. 이 차이는 크다. 프로토콜 실험과 엔터프라이즈 도입 사이에 있던 가장 큰 틈이 바로 운영 책임이었기 때문이다.
BigQuery, GCE, GKE가 MCP가 되면 에이전트는 조언자가 아니라 작업자가 된다
공식 문서와 발표를 같이 보면 방향이 선명하다. BigQuery MCP 서버는 스키마를 이해하고 쿼리를 실행하며, 데이터를 컨텍스트 윈도우 밖으로 옮기지 않고도 질의하게 해준다. Compute Engine MCP 서버는 프로비저닝과 리사이징 같은 인프라 작업을 discoverable tool로 노출한다. GKE MCP 서버는 쿠버네티스와 GKE API를 구조화된 방식으로 다루게 해주고, brittle한 CLI 출력 파싱을 피하게 만든다. Maps는 Grounding Lite를 통해 장소, 날씨, 경로 같은 현실 세계 데이터에 에이전트를 연결한다.
이걸 한 줄로 줄이면 이렇다. 에이전트가 드디어 데이터 질의, 인프라 조회, 운영 액션을 같은 프로토콜 안에서 처리하기 시작했다.
이건 모델 성능 얘기와 결이 다르다. 모델이 똑똑해지는 건 답변 품질의 문제다. 하지만 BigQuery와 GKE가 공식 MCP로 연결되기 시작하면, 에이전트는 분석과 실행의 중간 단계를 넘는다. 운영팀 입장에서는 여기서부터 경계심이 올라가야 한다. 왜냐하면 읽기 전용 도구 몇 개 붙이는 데서 끝나는 게 아니라, 실제 클라우드 리소스에 손을 댈 수 있는 호출면이 열리기 때문이다.
log8.kr와 OpenClaw 콘텐츠를 보면서 내가 자주 느끼는 문제도 비슷하다. 연결이 늘수록 생산성은 오르지만, 동시에 “누가 어느 권한으로 어디까지 만질 수 있나”가 훨씬 중요해진다. MCP가 실전으로 내려오면 제일 먼저 봐야 할 건 데모가 아니라 권한면이다.
Apigee가 같이 붙는 순간, 이건 기업 내부 자동화까지 들어간다
이번 발표에서 내가 특히 크게 본 건 Apigee다. 마케팅 관점으로 말하면, 이건 구글이 “우리 클라우드는 에이전트가 바로 쓸 수 있는 업무 연결망”이라고 포지셔닝을 바꾸는 장면이다. 많은 사람이 Google Cloud 서비스 공식화만 보고 지나가는데, 실제 조직 도입 관점에서는 Apigee가 더 무겁다. 이유는 간단하다. 기업이 진짜 자동화하고 싶은 건 Google 서비스 그 자체보다도 자기 회사 API와 외부 SaaS API를 에이전트가 안전하게 만지게 만드는 것이기 때문이다.
구글은 Apigee를 통해 조직이 직접 만든 API와 서드파티 API까지 discoverable tool로 expose하고 govern할 수 있다고 말했다. 이건 곧 API 게이트웨이가 MCP 공급 계층으로 올라온다는 뜻이다. 그러면 흐름이 바뀐다.
- 사내 API를 무턱대고 프롬프트에 설명하지 않는다.
- Apigee 뒤에서 인증, rate limit, 정책, 감사 포인트를 먼저 건다.
- 그 위를 MCP 도구 레이어로 노출한다.
- 에이전트는 정해진 인터페이스만 호출한다.
이 구조가 중요한 이유는 프롬프트와 비즈니스 로직을 분리할 수 있기 때문이다. 많은 팀이 아직도 “프롬프트 잘 쓰면 내부 자동화도 되지 않을까” 단계에 머물러 있다. 그런데 운영은 그렇게 하면 망가진다. 규칙은 API 계층에, 정책은 게이트웨이에, 호출 기록은 감사 로그에 남아야 한다. Apigee가 MCP 이야기 안에 들어온 순간, 구글은 이미 기업 자동화 설계를 같이 팔기 시작한 셈이다.
관리형 MCP의 핵심은 편의성이 아니라 거버넌스다
이쯤에서 “공식 MCP 서버가 나왔으니 이제 안전하다”라고 읽으면 틀린다. 반대로 봐야 한다. 권한 있는 시스템이 에이전트 호출면으로 올라오기 시작했기 때문에, 이제야 제대로 된 통제 장치가 필요해졌다. 구글이 IAM, Audit Logging, Cloud API Registry, Apigee API Hub, Model Armor를 같이 묶어 말한 이유도 여기에 있다.
- IAM은 누가 어떤 도구를 호출할 수 있는지 정한다.
- Audit Logging은 호출의 흔적을 남긴다.
- Cloud API Registry와 API Hub는 믿을 수 있는 도구 카탈로그를 제공한다.
- Model Armor는 간접 프롬프트 인젝션 같은 agentic threat에 대한 방어선을 제공한다.
이 조합은 꽤 현실적이다. MCP 생태계는 빠르게 커졌지만, 신뢰 경계는 그만큼 빨리 정리되지 못했다. 특히 로컬 STDIO 서버나 임의 배포된 오픈소스 서버는 실행 권한과 설정 신뢰 경계가 뒤섞이기 쉽다. 그래서 나는 이번 발표를 “구글도 MCP 지원”보다 “구글이 신뢰할 수 있는 기본 경로를 표준으로 만들려 든다” 쪽으로 읽는다.
이건 한국 팀에도 바로 중요한 포인트다. 실제 도입을 가로막는 건 대개 모델 품질이 아니라 감사 가능성이다. 보안팀이나 운영팀은 늘 같은 질문을 한다. “누가 이걸 썼는지 남나?” “잘못된 액션을 막을 수 있나?” “사고 나면 추적 가능하나?” 관리형 MCP는 바로 이 질문에 답하려는 제품이다.
경쟁 포인트가 모델에서 툴체인으로 옮겨간다
이번 발표가 더 큰 이유는 시장 메시지 때문이다. 이제 경쟁은 단순히 어느 모델이 더 영리하냐로 끝나지 않는다. 더 오래 가는 질문은 이쪽이다.
| 예전 질문 | 지금 더 중요한 질문 |
|---|---|
| 어느 모델이 더 잘 추론하나 | 어느 플랫폼이 공식 툴 레이어를 제공하나 |
| API 연결이 가능한가 | 클라우드 서비스와 사내 API를 같은 프로토콜로 묶을 수 있나 |
| 데모가 멋진가 | 운영 거버넌스와 감사가 붙어 있나 |
| MCP를 지원하나 | 관리형 remote MCP endpoint가 있나 |
여기서 Google의 그림은 꽤 노골적이다. Gemini CLI 같은 MCP 클라이언트가 프런트도어가 되고, 뒤에서는 Google Cloud 서비스가 관리형 도구 레이어가 된다. 개발자는 CLI에서 시작하고, 팀은 BigQuery나 GKE 같은 서비스로 확장하고, 조직은 Apigee와 IAM, Audit Logging으로 표준화한다. 이건 도구 한두 개 추가한 얘기가 아니라 클라우드 전체를 agent-ready toolchain으로 재포지셔닝하는 시도다.
공식 저장소 google/mcp도 이 방향을 뒷받침한다. Google 관리형 원격 서버 목록뿐 아니라 Cloud Run, Cloud Storage, Spanner, Cloud SQL, Firestore, Google Security Operations 같은 제품군과 예제 앱을 함께 엮고 있다. 블로그 발표에서 예고한 Cloud Run, Cloud Storage, Cloud Resource Manager, AlloyDB, Cloud SQL, Spanner, Looker, Pub/Sub, Cloud Logging, Cloud Monitoring 확장 계획까지 합치면, 구글은 이미 “몇 개 서비스 지원”이 아니라 “Google Cloud 전역 MCP 표면”을 설계 중이라고 봐야 한다.
한국 개발팀은 어떻게 들어가야 하나
나는 여기서 욕심내면 메시지도 운영도 동시에 흐려진다고 본다. 도입 순서는 분명해야 한다.
- 읽기 전용 도구부터 시작한다. BigQuery 조회, 문서 검색, 운영 상태 확인 같은 구간이 먼저다.
- 감사 로그가 남는 경로만 연다. trace가 안 남으면 운영 도구로 취급하면 안 된다.
- 사내 API는 직접 붙이지 말고 Apigee 같은 정책 계층 뒤에 둔다.
- 쓰기, 배포, 삭제, 권한 변경 계열은 human-in-the-loop를 강제한다.
- 도구 카탈로그를 정리한다. 아무 MCP 서버나 붙이는 문화부터 끊어야 한다.
국내 팀은 특히 “일단 붙여보자” 문화가 강하다. 빠른 실험 자체는 좋다. 문제는 에이전트 호출면이 곧 운영면이 되는 순간부터다. BigQuery 질의는 금방 가치가 나온다. GKE나 GCE 액션도 유혹적이다. 하지만 그 다음 단계는 항상 더 위험하다. 그래서 이번 발표를 따라갈 때는 기능보다 도입 순서와 제한 조건을 먼저 문서화해야 한다.
결론: Google Cloud는 이제 에이전트가 소비하는 작업 표면이 되려 한다
내 결론은 단순하다. 이번 발표는 “구글도 MCP 한다”가 아니다. 구글은 Google Cloud 전체를 에이전트가 바로 소비할 수 있는 공식 작업 표면으로 만들려 한다. 그리고 그 표면은 단순한 툴 모음이 아니라, IAM, 감사 로그, API 허브, 정책 계층, 보안 방어선이 같이 붙은 엔터프라이즈용 툴체인이다.
그래서 이 이슈는 프로토콜 팬덤의 승패로 읽을 필요가 없다. 더 실용적으로 보면 된다. 앞으로 에이전트 도입 경쟁은 모델 성능과 데모 퀄리티만으로 안 끝난다. 어느 플랫폼이 실제 데이터, 인프라, 내부 API, 거버넌스를 표준 도구 레이어로 묶어주느냐가 더 중요해진다. 이번 구글 발표는 그 전환이 시작됐다는 명확한 신호다.
김덕환 운영자가 봤을 때
log8.kr를 운영하는 김덕환 입장에선 이런 발표가 반갑다. 이유는 단순하다. 새 모델이 하나 더 늘어나는 것보다, 이미 쓰는 클라우드와 도구가 공식 MCP 표면으로 정리되는 쪽이 실제 생산성에 더 가깝기 때문이다. 다만 운영자 시선에선 흥분보다 기준이 먼저다. 어디까지 읽기 전용으로 둘지, 어떤 액션부터 승인 절차를 걸지, 로그와 권한 체계를 어떻게 남길지부터 정해야 한다. 결국 1인 운영에서도 성패는 도구 수가 아니라 경계 설계에서 갈린다.