Google Cloud API Gateway MCP 공개 프리뷰: REST API를 에이전트 도구로 노출하는 방식이 바뀐다

Google Cloud가 API Gateway에서 MCP(Model Context Protocol) 서버 역할을 지원하는 공개 프리뷰를 내놨다. 핵심은 새 MCP 서버를 따로 만들지 않고, 이미 배포 중인 OpenAPI 3.x 스펙에 주석을 추가해 기존 REST API를 에이전트가 호출할 수 있는 도구로 노출한다는 점이다.

이 업데이트는 단순한 Google Cloud 기능 추가로 보기 어렵다. 기업의 실제 업무 기능은 대부분 REST API 뒤에 있다. 주문 조회, 재고 확인, 결제 취소, 티켓 생성, 내부 승인 같은 기능은 이미 API Gateway, 인증, quota, 로그 체계 안에서 운영된다. 지금까지 AI 에이전트가 이런 기능을 쓰려면 별도 MCP 서버를 세우고, 기존 API 라우팅과 인증 로직을 다시 구현해야 했다. Google의 새 방식은 이 중복을 줄이는 방향이다.

검색 의도 관점에서도 중요한 키워드는 “MCP 서버 구축”, “REST API MCP 변환”, “AI 에이전트 API Gateway”다. 개발팀이 궁금해하는 것은 발표 자체보다 “기존 API를 얼마나 안전하게 에이전트에게 열 수 있나”다.

무엇이 달라졌나

기존에는 REST API와 MCP 서버가 분리되어 있었다. REST API는 사람이 만든 앱이나 백엔드 서비스가 호출하고, MCP 서버는 AI 에이전트가 호출했다. 기능은 같은데 운영 경로가 두 개가 되는 문제가 생겼다. 인증 정책도 따로 붙고, rate limit도 따로 세고, 로그도 분리됐다.

이번 API Gateway MCP 지원은 MCP 요청을 게이트웨이에서 받아 REST 호출로 변환한다. MCP 클라이언트는 tools/call을 보내고, 게이트웨이는 이를 OpenAPI 스펙에 정의된 path, query, body, header로 매핑한다. 백엔드 입장에서는 일반 REST 요청과 구분되지 않는다. 따라서 기존 JWT, API key, quota, logging 정책이 그대로 적용된다.

실무에서 이 차이는 크다. AI 에이전트용 API를 따로 만들면 보안팀과 플랫폼팀은 두 개의 경로를 감사해야 한다. 반대로 게이트웨이에서 변환하면 “사람이 쓰는 API”와 “에이전트가 쓰는 API”가 같은 정책 경로를 탄다. 운영 복잡도가 줄어든다.

OpenAPI 스펙이 에이전트 인터페이스가 된다

Google 문서에 따르면 MCP 노출에는 OpenAPI 3.0.x 또는 3.1.x가 필요하다. OpenAPI 2.0은 지원하지 않는다. 문서 레벨에서 x-google-api-management.mcp를 켜고, 개별 operation에는 x-google-mcp-tool로 도구 이름과 설명을 붙인다.

여기서 중요한 것은 description이다. 사람용 API 문서에서는 “주문 상태를 반환한다” 정도로 충분할 수 있다. 하지만 LLM이 도구를 고를 때는 “언제, 왜 이 도구를 써야 하는지”가 더 중요하다. 예를 들어 get_order_status라면 “사용자가 주문 위치나 도착 예정일을 묻는 경우 사용한다”처럼 의도 기반 설명이 필요하다.

이제 API 문서 작성은 백엔드 개발자만의 일이 아니다. 에이전트가 어떤 상황에서 어떤 도구를 호출할지 결정하는 검색 색인에 가깝다. 도구 설명이 모호하면 모델은 엉뚱한 API를 호출하거나, 호출해야 할 때 호출하지 않는다.

프로덕션에서 바로 조심해야 할 지점

가장 먼저 볼 것은 tools/list 공개 범위다. Google 설명에 따르면 기본적으로 도구 목록 조회가 인증 없이 가능할 수 있다. 개발 중에는 편하지만, 운영에서는 도구 이름과 입력 스키마 자체가 내부 시스템 구조를 드러낼 수 있다. Google은 운영 환경에서 JWT로 discovery를 보호하라고 안내한다. API key는 tools/list 보안에 쓸 수 없다는 점도 주의해야 한다.

두 번째는 노출 범위다. 게이트웨이가 최대 1,000개 도구를 서빙할 수 있다고 해서 내부 API 전체를 한 번에 열면 안 된다. 에이전트는 필요한 도구가 적을수록 선택 오류가 줄어든다. 고객지원 에이전트라면 주문 조회, 배송 상태, 반품 요청 정도부터 시작하는 편이 낫다.

세 번째는 응답 형태다. HTTP 204처럼 빈 body를 반환하는 operation은 노출되지 않는 제한이 있다. 깊게 중첩된 object schema도 tools/list에서 완전히 보이지 않을 수 있다. 에이전트용 API는 사람용 REST API와 달리 “모델이 이해하기 쉬운 응답”이 중요하다.

기존 MCP 서버를 모두 버리라는 뜻은 아니다

이 발표는 “이제 모든 MCP 서버를 API Gateway로 바꾸라”는 뜻이 아니다. 파일 시스템 접근, 로컬 개발도구, 브라우저 자동화처럼 게이트웨이 뒤 REST API가 아닌 기능은 여전히 별도 MCP 서버가 필요하다. 다만 이미 REST API로 운영 중인 엔터프라이즈 기능은 게이트웨이에서 MCP를 제공하는 편이 더 단순할 수 있다.

Apigee는 더 큰 API 플랫폼, Agent Gateway는 에이전트가 외부 MCP 서버를 호출할 때의 통제 지점, API Gateway는 가볍게 REST API를 에이전트 도구로 여는 진입점으로 보면 된다. 팀 규모와 보안 요구에 따라 선택지가 달라진다.

개발팀이 오늘 확인할 체크리스트

• 현재 OpenAPI 스펙이 3.0.x 이상인지 확인한다.
• 에이전트에게 열 API를 전체가 아니라 5~10개 후보로 줄인다.
• 각 operation description을 “무엇을 반환하나”가 아니라 “언제 사용하나”로 다시 쓴다.
• tools/list 인증을 운영 환경에서 JWT로 보호할 수 있는지 확인한다.
• REST 호출과 MCP 호출이 같은 quota·로그 정책을 타는지 점검한다.
• 빈 body 응답, 깊은 nested schema, 대량 도구 노출 같은 제한에 걸리는 API를 분리한다.
• 도구 호출 로그에서 사용자 요청, tool name, backend status, latency를 남긴다.
• 처음부터 쓰기 API를 열지 말고 읽기 API로 파일럿을 시작한다.

출처: Google Developers Blog, “Turn your REST APIs into MCP tools with Google Cloud API Gateway”, 2026년 9월 24일.