REST API를 MCP 도구로 열기 전: API Gateway의 발견·호출 경계

이미 REST API와 게이트웨이를 운영한다면 에이전트용 MCP 서버를 하나 더 세워야 할까요? Google Cloud는 API Gateway가 기존 REST 작업을 MCP 도구로 노출하는 기능을 Public Preview로 발표했습니다. 핵심 이점은 단순히 서버 수를 줄이는 것이 아닙니다. 기존 API의 정책 경로를 재사용하면서도, 도구 목록을 볼 수 있는 사람과 실제 작업을 실행할 수 있는 사람을 별도로 설계해야 한다는 점입니다. 무심코 tools/list와 tools/call을 같은 인증 문제로 다루면 노출 범위를 잘못 이해할 수 있습니다.

Google Developers Blog의 2026년 9월 24일 발표와 API Gateway의 「Model Context Protocol overview」를 기준으로 살펴봅니다. 두 문서 모두 제품의 현재 범위와 구성 방식을 설명하는 1차 자료입니다. 여기서 성능 개선률, 보안 시험 성공률, 별도 서버 대비 비용 절감 수치는 제시하지 않습니다. 이 글은 공식 발표와 문서를 대조한 설계 분석이며, 실제 게이트웨이를 배포하거나 인증·성능을 독립 실험한 결과가 아닙니다.

무엇을 재사용하고, 무엇이 새로 생기나

발표에 따르면 API Gateway는 단일 /mcp 경로에서 MCP JSON-RPC 요청을 받고, tools/call을 OpenAPI에 대응하는 REST 요청으로 변환한 뒤 응답을 MCP 결과로 돌려줍니다. 게이트웨이가 앞단에서 요청을 변환하므로 백엔드 서비스를 MCP 전용으로 다시 작성하지 않아도 되는 구조입니다. 다만 이는 Google Cloud API Gateway에 배포하는 OpenAPI 3.x 기반 REST 구성에 관한 기능이지, 임의의 REST URL을 등록하기만 하면 모든 MCP 기능이 생긴다는 뜻은 아닙니다.

설정은 문서 수준의 x-google-api-management.mcp 활성화에서 시작하고, 작업별 x-google-mcp-tool로 이름·설명을 조절하거나 제외할 수 있습니다. 발표 예제에서는 백엔드가 연결된 주문 조회 작업의 operationId와 도구 설명을 정의합니다. 설명은 반환 필드 나열만이 아니라 에이전트가 언제, 왜 이 도구를 선택할지를 알려주어야 합니다. 예를 들어 주문 상태를 묻는 요청에만 조회 도구를 쓰게 설명하는 편이 모든 질문에 '주문 도구'를 무차별 제공하는 것보다 목적이 분명합니다. 아래 흐름도는 공식 요청 경로를 다시 그린 개념도이며, 실제 운영망 캡처가 아닙니다.

MCP 호출은 게이트웨이에서 기존 REST 작업으로 변환된다. 공유 정책·할당량은 공식 설명이며 실제 배포 측정 결과가 아니다. 출처: developers.googleblog.com/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway.

작업 호출은 기존 REST 작업에 설정한 JWT 또는 API 키 인증, 할당량, 로깅 정책을 따른다고 발표는 설명합니다. REST와 MCP가 같은 작업의 할당량을 함께 사용하므로 에이전트 호출량을 별도 무한 용량처럼 계산하면 안 됩니다. 이는 정책 경로에 대한 제품 설명이지, 모든 배포 설정의 보안성을 이 글이 검증했다는 뜻은 아닙니다. 기존 작업의 권한과 할당량을 먼저 목록화하고, 호출 주체가 추가됐을 때 운영상 허용 가능한지 판단해야 합니다.

발견은 호출과 다른 권한 문제

가장 놓치기 쉬운 것은 tools/list입니다. 발표는 도구 목록 조회가 기본적으로 인증되지 않으며, 그 상태에서는 도구 이름과 입력 스키마를 요청자에게 드러낸다고 명시합니다. 실제 tools/call에서 기저 REST 작업 인증이 적용된다는 사실만으로 도구 발견까지 비공개가 되지는 않습니다. 공개 가능한 작업 목록인지 먼저 판단하세요. 비공개라면 문서가 안내한 발견용 JWT 구성을 별도로 적용해야 합니다. 발표에 따르면 API 키는 tools/list 자체를 보호하는 수단이 아닙니다. 키를 MCP 클라이언트 헤더에 넣은 예제는 작업 호출의 인증 예시이지 발견 경계를 해결한 증거가 아닙니다.

발견용 tools/list는 기본적으로 인증되지 않고 API 키로 보호할 수 없다. 호출은 기저 REST 작업의 인증을 적용한다. 출처: developers.googleblog.com/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway.

이를 실무에 옮기면 인증 설계에는 최소 두 줄이 필요합니다. 첫째, 누가 도구 이름과 스키마를 열람할 수 있는가. 둘째, 각 도구가 매핑하는 REST 작업을 누가 호출할 수 있는가. 두 줄의 결론이 같을 수도 있지만 설정 지점과 기본값이 같지는 않습니다. 발견이 공개여도 작업 호출은 보호할 수 있고, 발견을 잠가도 기저 작업의 권한이 과하게 넓다면 호출 위험은 남습니다. 이 구분은 보안 사고를 입증하는 실험 결과가 아니라 공식 기본값에서 도출한 설계 점검입니다.

도입 여부를 고르는 네 칸 표

아래 표는 공식 지원 범위와 한계를 실무 결정으로 바꾼 편집상 도구입니다. Google이 이 의사결정 표의 효과를 시험하거나 특정 조직에 적용을 승인한 것은 아닙니다.

검토 대상	도입 전 질문	이번 기능에서 확인된 경계	실무 결정
기존 API	Google Cloud API Gateway에 OpenAPI 3.x REST 백엔드가 있는가?	해당 게이트웨이가 MCP 요청을 REST로 변환한다	기존 구성이 맞으면 게이트웨이 경로 검토, 아니라면 이 기능의 직접 적용 대상 아님
도구 발견	도구 이름과 입력 스키마를 외부에 공개해도 되는가?	tools/list는 기본적으로 인증되지 않으며 API 키로 보호할 수 없다	비공개라면 발견용 JWT 설정을 따로 설계
도구 호출	각 REST 작업의 인증·할당량은 무엇인가?	tools/call은 기저 작업의 인증을 적용하고 REST와 할당량을 공유한다	기존 작업 권한과 혼합 트래픽 용량을 함께 점검
프로토콜 범위	리소스·프롬프트·스트리밍 또는 긴 작업이 필요한가?	Public Preview에서 지원되지 않는다	필요하면 별도 구현/다른 경로를 검토

공식 범위를 실무 질문으로 바꾼 편집상 판단 순서다. 효과나 제품 적합성을 실제 실험으로 검증한 것은 아니다. 출처: docs.cloud.google.com/api-gateway/docs/mcp-overview.

이미 API Gateway에서 관리하는 주문 조회 같은 읽기 작업이라면 도구 설명, 입력 스키마, 발견 권한, 호출 권한을 먼저 설계하고 작은 범위에서 확인할 수 있습니다. 반면 리소스 조회나 프롬프트 제공을 MCP의 필수 기능으로 쓰는 제품이라면 현재 게이트웨이 기능만으로 충족할 수 없습니다. Google 문서는 resources/*와 prompts/*가 지원되지 않으며 다른 MCP 메서드는 JSON-RPC 오류를 반환한다고 설명합니다. 도구 목록이 제공된다는 것과 범용 MCP 서버 기능 전체가 제공된다는 것은 다른 주장입니다.

명세·응답·구성의 반례

OpenAPI 2.0 명세는 지원되지 않아 3.0.x 또는 3.1.x로 옮겨야 합니다. 본문에 빈 응답을 돌려주는 HTTP 204 작업은 도구로 노출되지 않는다고 발표합니다. 따라서 '모든 REST 작업 자동 전환'이라는 해석은 틀립니다. 깊게 중첩된 객체 스키마는 tools/list에 온전히 표현되지 않을 수 있고, 게이트웨이당 도구 수에는 최대 1,000개 제한이 있습니다. 이 숫자는 처리량 벤치마크가 아니라 도구 개수 상한입니다.

또한 공식 문서에 따르면 스트리밍과 오래 걸리는 도구 호출은 지원하지 않습니다. MCP와 모델 라우팅은 동일 API 구성에서 동시에 활성화할 수 없습니다. 모델 라우팅이 이미 활성화된 구성을 유지해야 한다면 이 둘을 같은 구성에 붙이는 설계는 출발점부터 맞지 않습니다. 제한 그림은 공식 지원 범위를 분류한 자체 제작 도식이고 실제 요청 오류 화면이 아닙니다.

Public Preview의 제외 조건과 개수 상한이다. 1,000은 처리량 측정치가 아니라 게이트웨이당 도구 수 제한이다. 출처: developers.googleblog.com/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway.

실무에서는 도구 후보를 전부 노출하기보다, 반환 본문과 설명이 명확한 소수 작업을 고른 다음 공개 가능한 목록인지 판단하는 편이 낫습니다. 읽기/쓰기 작업의 권한을 원래 REST 정책과 나란히 확인하고, 같은 할당량을 공유하는 운영 지표도 살펴야 합니다. 이 순서는 편집상 제안이며 특정 배포에서 안전성이나 지연 시간을 보장하지 않습니다. 특히 Public Preview는 Pre-GA 약관 대상이며 제한적 지원 또는 변경 가능성이 있으므로 일반 출시(GA) 기능처럼 확정적으로 의존해서는 안 됩니다.

참고 자료와 검증 범위

• Google Developers Blog, 「Turn your REST APIs into MCP tools with Google Cloud API Gateway」(2026-09-24) - https://developers.googleblog.com/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway/
• Google Cloud, 「Model Context Protocol overview」(Public Preview, 확인 시점 기준) - https://docs.cloud.google.com/api-gateway/docs/mcp-overview

원문의 구성 설명과 지원 한계를 대조해 독자용 판단 표와 그림을 새로 만들었습니다. 게이트웨이 배포, 인증 실패/성공 호출, 지연 시간, 보안 강도는 측정하지 않았습니다. 예시에 등장하는 주문 작업은 공식 발표의 설명을 이해하기 위한 예시이지 실제 주문 데이터를 조회했다는 뜻이 아닙니다.