Google Cloud API Gateway MCP 공개: REST API를 에이전트 도구로 여는 변화

구글이 2026년 9월 24일 Google Cloud API Gateway의 MCP 지원을 Public Preview로 공개했다. 핵심은 단순하다. 이미 운영 중인 REST API와 OpenAPI 스펙을 별도 MCP 서버 없이 에이전트가 호출할 수 있는 도구로 노출할 수 있다.

개발팀 입장에서는 꽤 현실적인 변화다. 지금까지 에이전트에게 사내 기능을 붙이려면 보통 MCP 서버를 따로 만들었다. 기존 API Gateway가 이미 라우팅, 인증, quota, logging을 처리하고 있는데도 MCP용 서버에서 같은 로직을 다시 구현하는 경우가 많았다. 새 기능은 이 중복을 줄인다. OpenAPI 3.x 스펙에 MCP 관련 확장을 붙이고 배포하면, 게이트웨이가 /mcp 엔드포인트에서 JSON-RPC 요청을 받아 REST 호출로 변환한다.

이 글은 발표 요약이 아니라, 실무 개발자가 무엇을 바꿔야 하는지에 초점을 둔다. “우리도 MCP를 붙여야 하나?”보다 먼저 봐야 할 질문은 세 가지다. 이미 외부에 안정적으로 공개된 REST API가 있는가. 도구 호출 권한을 기존 인증 체계로 통제할 수 있는가. LLM이 잘못 호출했을 때 영향 범위를 제한할 수 있는가.

무엇이 새로 공개됐나

Google Cloud API Gateway는 Public Preview에서 MCP 서버처럼 동작할 수 있다. OpenAPI 3.0.x 또는 3.1.x 문서에 x-google-api-management.mcp 옵션을 켜고, 개별 operation에 x-google-mcp-tool 정보를 추가하면 된다. 그러면 에이전트는 tools/list로 도구 목록을 보고 tools/call로 특정 작업을 호출할 수 있다.

중요한 점은 “MCP 트래픽과 REST 트래픽이 같은 정책 경로를 탄다”는 것이다. 기존 operation에 설정한 JWT, API key, quota, logging이 그대로 적용된다. 게이트웨이는 tools/call을 받아 path, query, body, header에 인자를 매핑하고 백엔드 응답을 MCP result로 돌려준다.

구글 예시는 주문 조회 API다. getOrderStatus라는 REST operation을 get_order_status라는 MCP tool로 노출한다. 설명에는 “고객이 주문 위치나 도착 시간을 물을 때 사용하라”처럼 사용 조건을 적는다. 이 부분이 핵심이다. 에이전트는 함수 이름보다 description을 보고 호출 여부를 판단한다. “Returns status”보다 “배송 위치와 ETA를 묻는 경우에만 사용”이 훨씬 운영 친화적이다.

왜 개발팀에 중요한가

첫 번째 의미는 중복 인프라 감소다. 이미 API Gateway에 보안, 인증, 제한, 로그가 들어가 있다면 MCP 서버를 별도로 띄우는 것은 운영 표면을 하나 더 늘리는 일이다. 장애 지점도 늘고, 정책 불일치도 생긴다. MCP를 게이트웨이에서 처리하면 기존 API 운영 모델을 크게 바꾸지 않고 에이전트 채널만 추가할 수 있다.

두 번째 의미는 API가 “문서”에서 “행동 가능한 도구”로 바뀐다는 점이다. 지금까지 OpenAPI 문서는 사람이 읽거나 SDK 생성에 쓰였다. 이제는 LLM이 도구 목록을 읽고 직접 호출한다. 따라서 스펙의 품질이 런타임 품질이 된다. operationId, description, parameter schema가 부실하면 에이전트 호출 정확도도 떨어진다.

세 번째 의미는 보안 검토 위치가 앞당겨진다는 것이다. 예전에는 챗봇이 답변만 잘하면 됐다. 이제는 챗봇이 환불, 주문 변경, 계정 조회 같은 실제 작업을 건드릴 수 있다. API를 MCP로 노출하는 순간 “이 API를 사람 UI 뒤에 숨겨두면 괜찮다”는 전제가 깨진다. 도구 discovery, 호출 권한, 감사 로그를 별도 체크리스트로 봐야 한다.

실무 적용 전 확인할 제한사항

Public Preview라서 제한도 분명하다. 구글 문서 기준으로 OpenAPI 2.0은 지원하지 않는다. 2.0 스펙을 쓰는 팀은 먼저 3.x로 옮겨야 한다. HTTP 204처럼 빈 body를 반환하는 operation은 노출되지 않는다. deeply nested object schema는 tools/list에서 완전히 렌더링되지 않을 수 있다. 게이트웨이 하나가 제공할 수 있는 도구는 최대 1,000개다.

또 하나 놓치기 쉬운 제한이 있다. tools/list는 기본적으로 인증 없이 열릴 수 있다. 개발 중에는 편하지만, 프로덕션에서는 도구 이름과 입력 스키마가 외부에 드러난다. 구글은 production에서는 JWT로 discovery를 잠그라고 안내한다. API key는 tools/list 보안에는 사용할 수 없다는 점도 체크해야 한다.

MCP resources, prompts, response streaming, Model Armor payload inspection은 로드맵 항목이다. 즉, 당장 모든 MCP 기능을 완전하게 대체한다고 보면 안 된다. “REST operation을 agent-callable tool로 바꾸는 빠른 길”로 이해하는 게 정확하다.

어떤 API부터 노출해야 하나

처음부터 결제 취소, 권한 변경, 데이터 삭제 같은 쓰기 API를 열면 위험하다. 시작점은 read-only API가 맞다. 주문 상태 조회, 티켓 상태 조회, 문서 검색, 계정 사용량 조회처럼 실패해도 피해가 제한적인 작업이 좋다.

그다음은 idempotent한 쓰기 작업이다. 예를 들어 알림 재전송, draft 생성, 임시 리포트 생성처럼 여러 번 실행돼도 결과가 망가지지 않는 작업이다. 결제, 삭제, 권한 변경은 마지막 단계로 미뤄야 한다. 이 단계에서는 human confirmation, 별도 policy, request signing, rate limit을 같이 설계해야 한다.

도구 이름도 중요하다. get_user는 너무 넓다. get_customer_subscription_status처럼 목적이 드러나는 이름이 낫다. description에는 “언제 쓰면 안 되는지”도 적어야 한다. 예를 들어 “개인정보 전체 조회 용도로 사용하지 말 것. 구독 상태 확인 질문에만 사용”처럼 금지 조건을 넣으면 오호출을 줄일 수 있다.

운영팀이 봐야 할 관찰 지표

MCP 도구를 붙이면 API 관찰 기준도 바뀐다. 기존에는 endpoint latency, status code, error rate를 봤다. 이제는 agent가 어떤 질문에서 어떤 tool을 골랐는지, tool call이 성공했지만 사용자 문제를 해결했는지까지 봐야 한다.

최소한 다음 로그는 남기는 것이 좋다. session id, user intent 요약, selected tool, arguments, auth principal, backend status, latency, result size, human confirmation 여부, rollback 여부. 특히 arguments는 마스킹 정책이 필요하다. 주민번호, access token, 결제 정보가 로그에 남으면 MCP 도입이 보안 사고로 이어진다.

실패도 두 종류로 나눠야 한다. API 실패와 에이전트 판단 실패다. API 실패는 401, 403, 429, 5xx처럼 기존 방식으로 볼 수 있다. 판단 실패는 호출하지 말아야 할 도구를 호출했거나, 필요한 도구를 호출하지 않은 경우다. 후자는 테스트 케이스와 샘플 대화셋으로 잡아야 한다.

Aibase 관점에서 보는 체크포인트

이 발표의 방향은 명확하다. 에이전트 개발은 “새로운 백엔드 만들기”보다 “기존 시스템을 안전하게 도구화하기”로 이동하고 있다. 대기업일수록 REST API 자산이 많다. 그 API를 MCP로 감싸는 표준 경로가 생기면, 에이전트 PoC가 운영 시스템으로 넘어가는 속도는 빨라진다.

다만 빠른 연결이 곧 안전한 연결은 아니다. API Gateway가 MCP를 제공해도, 도구 설명 품질과 권한 설계는 개발팀 책임이다. 특히 tools/list 공개 범위, 쓰기 operation 보호, 로그 마스킹은 제품 출시 전 QA 항목으로 넣어야 한다.

참고한 공식 발표는 Google Developers Blog의 “Turn your REST APIs into MCP tools with Google Cloud API Gateway”다. Public Preview 기능이므로 실제 운영 적용 전에는 문서의 최신 제한사항을 확인해야 한다.

실행 체크리스트

• OpenAPI 스펙이 3.0.x 또는 3.1.x인지 확인한다.
• read-only operation 3개 이하로 첫 MCP 노출 대상을 제한한다.
• operation description에 사용 조건과 금지 조건을 모두 적는다.
• tools/list를 프로덕션에서 JWT로 잠근다.
• API key만으로 discovery 보안을 처리하려 하지 않는다.
• 204 응답, deeply nested schema, 1,000 tool 제한을 사전 점검한다.
• tool call 로그에서 민감정보 마스킹을 적용한다.
• API 실패와 에이전트 판단 실패를 분리해 측정한다.
• 결제, 삭제, 권한 변경 API는 human confirmation 없이는 열지 않는다.
• Public Preview 기능이므로 변경 가능성을 릴리즈 노트로 추적한다.