이 글은 기존 REST 서비스를 Agent 도구로 연결하려는 API 개발자, 인증·할당량·로그 정책을 점검하는 플랫폼 엔지니어, 읽기와 쓰기 권한을 나눠야 하는 AI 제품팀을 위한 안내입니다.
마지막 업데이트: 2026년 9월 25일. 출시 상태와 설정은 Google의 2026년 9월 24일 발표와 API Gateway MCP 공식 개요를 기준으로 확인했습니다.
1시범 연결은 가능하지만, 완성된 Agent 플랫폼은 아닙니다
Google은 2026년 9월 24일 Google Cloud API Gateway의 원격 MCP 기능을 공개 미리보기로 발표했습니다. 공식 개요에는 OpenAPI 3.x 명세를 사용하고 initialize, tools/list, tools/call 메서드로 연결하는 흐름이 설명되어 있습니다. 기존 REST API를 재사용하려는 팀은 별도 MCP 서버를 만들기 전에 제한된 시험을 검토할 수 있습니다.
다만 Gateway가 제공하는 것은 REST 작업을 MCP 도구로 노출하는 연결 경로입니다. 백엔드의 업무 규칙이나 입력 검증이 Agent에 맞게 자동 변경되는 것은 아닙니다. MCP 설정 안내에서 명세와 확장 설정을 확인하고, 노출할 작업의 의미와 위험은 팀이 직접 정리해야 합니다.
| 현재 조건 | 먼저 확인할 점 | 선택 |
|---|---|---|
| OpenAPI 3.x 명세가 실제 API 동작을 설명함 | 작업별 입력, 응답, 인증 설정이 명세와 일치하는지 확인 | 제한된 미리보기 시험 |
| API를 Agent 도구로 호출하면 충분함 | 필요한 메서드와 클라이언트 호환성 확인 | Gateway 구성을 배포해 검증 |
| 리소스, 프롬프트, 스트리밍 또는 장시간 작업이 필수임 | 공식 미리보기 제한과 요구사항 대조 | 지원이 확인될 때까지 기존 구현 유지 |
| 도구 발견과 호출을 하나의 인증으로 처리하려 함 | tools/list와 tools/call의 인증 경계 분리 |
운영 투입 전 각각 검증 |
공개 미리보기는 정식 제공과 같지 않습니다. 지원 범위와 동작이 바뀔 수 있으므로 배포 시점의 공식 문서를 다시 확인하세요.
2도구 발견과 실제 호출은 서로 다른 인증 단계입니다
tools/list는 Agent가 사용할 수 있는 도구를 알아보는 요청이고, tools/call은 선택한 도구를 실행하는 요청입니다. 공식 안내에 따르면 도구 발견은 기본적으로 공개될 수 있습니다. 운영 환경에서 도구 이름이나 설명을 외부에 노출하면 안 된다면, 발견 요청에도 인증이 요구되도록 구성하고 실제 클라이언트에서 확인해야 합니다.
도구 호출은 대응하는 REST 작업으로 변환됩니다. Google은 기존 작업에 설정된 인증과 관련 정책을 적용하는 흐름을 설명합니다. 그렇더라도 기존 API 인증이 호출자의 신원을 충분히 구분한다고 단정해서는 안 됩니다. Agent가 어떤 자격 증명을 제공하는지, 그 자격 증명이 어떤 작업에 유효한지 검증해야 합니다.
| 점검 항목 | Gateway에서 확인할 내용 | 별도 판단이 필요한 부분 |
|---|---|---|
| 도구 발견 | tools/list 인증 요구 여부와 공개되는 도구 설명 |
도구 목록 노출 자체가 허용되는지 |
| 도구 실행 | MCP 호출이 연결된 REST 작업의 인증으로 이어지는지 | Agent 자격 증명과 사용자별 권한 |
| 할당량 | API Gateway 할당량 안내에 따른 적용 범위 | Agent별 사용량 통제와 작업 우선순위 |
| 로그 | 플랫폼 로그 안내에 따른 요청 기록 | 로그에서 호출 주체를 식별할 수 있는지 |
기존 할당량과 로그는 운영 점검에 도움이 되지만 Agent 권한을 완전히 통제하는 체계는 아닙니다. 쓰기, 삭제, 외부 전송처럼 결과를 되돌리기 어려운 작업은 읽기 작업과 같은 기준으로 묶지 마세요.
3읽기 작업부터 공개하고 쓰기 작업은 별도 승인합니다
도구를 많이 노출한다고 Agent가 업무를 더 정확하게 수행하는 것은 아닙니다. 각 OpenAPI 작업의 용도와 입력값을 구체적으로 적고, 조회와 변경 작업을 구분하세요. operationId와 설명이 모호하면 Agent가 비슷한 이름의 작업을 잘못 선택할 가능성을 줄이기 어렵습니다. 확장 필드와 명세 제한은 OpenAPI 3.x 지원 범위 안내와 대조하세요.
조건별 선택
- 명세가 정확하고 조회 작업만 필요하다면, 해당 작업만 노출해 미리보기 시험을 진행하세요.
- 쓰기 작업이 필요하다면 입력 검증과 승인 절차를 추가하고, 시험 환경에서 실제 호출 결과를 확인하세요.
- 도구 발견이 인증되지 않거나 목록 노출을 허용할 수 없다면 운영 트래픽을 연결하지 말고 접근 통제부터 해결하세요.
- 서비스가 스트리밍, MCP 리소스·프롬프트, 장시간 호출에 의존한다면 공식 제한을 확인하세요. 필수 기능이 지원되지 않으면 기존 구현을 유지하거나 제품 업데이트를 기다리세요.
4첫 배포는 명세 검증부터 호출자 확인까지 진행합니다
- 명세와 백엔드를 대조합니다. 배포 대상의 OpenAPI 3.x 명세가 실제 경로, 입력, 응답을 표현하는지 확인하세요. 필수 기능이 지원 제한에 걸리는지도 살펴봅니다.
- 노출할 작업을 고릅니다. Agent가 필요한 작업만 남기고 읽기와 데이터 변경 작업을 구분하세요. 용도와 입력 필드 설명이 불명확한 작업은 먼저 정리합니다.
- MCP 설정을 추가합니다. 공식 구성 안내에 맞춰 OpenAPI 명세에 필요한 설정을 적용합니다. 문서에 없는 확장 필드나 클라이언트 동작을 가정하지 마세요.
- API 구성을 만들고 배포합니다. API 구성 생성 단계에 따라 시험용 구성을 배포한 다음, MCP 진입점과 연결된 백엔드를 확인합니다.
- 도구 발견을 시험합니다. 클라이언트에서
tools/list를 요청하고 인증 없이도 목록이 반환되는지 확인하세요. 공개가 의도되지 않았다면 운영 배포를 멈추고 접근 통제를 수정합니다. - 호출 인증과 기존 정책을 시험합니다.
tools/call로 REST 작업을 호출해 자격 증명, 거부 동작, 할당량, 로그가 기대대로 작동하는지 점검하세요. 성공 응답뿐 아니라 권한이 없는 요청도 확인해야 합니다. - 필수 기능과 클라이언트 호환성을 판정합니다. 사용하는 Agent 개발 키트나 MCP 클라이언트가 이 연결 방식과 필요한 기능을 지원하는지 확인하세요. 모든 클라이언트가 똑같이 동작한다고 가정하지 마세요.
5REST 연결과 macOS 실행 환경은 서로 다른 문제입니다
API Gateway는 원격 API 도구 호출을 연결합니다. macOS 앱의 빌드와 테스트, Apple 도구 체인을 실행할 환경을 제공하는 역할은 아닙니다. Agent가 백엔드 API만 호출한다면 Gateway 연결과 인증 경계를 먼저 검증하세요. iOS 또는 macOS 앱 빌드가 업무에 포함될 때는 Apple의 Xcode 시스템 요구사항을 확인하고 Mac 실행 환경을 별도로 선정해야 합니다.
MCP 접근 통제와 배포 항목을 더 검토하려면 vpstix의 관련 가이드를 참고할 수 있습니다. Apple 도구 체인이 필요한 경우에도 클라우드 맥이 API 인증 문제를 해결해 주는 것은 아닙니다. vpstix의 원격 실행 환경 정보를 확인해 빌드 환경 요구사항과 API 연결 요구사항을 분리하세요.
6자주 묻는 질문
기존 REST API를 MCP 도구로 제공하려면 무엇부터 준비해야 하나요?
먼저 API의 OpenAPI 3.x 명세가 실제 동작과 일치하는지 확인하고, Agent에 노출할 작업만 고릅니다. 명세에 MCP 설정을 추가해 API Gateway 구성을 배포하면 MCP 진입점을 마련할 수 있습니다. 이 과정은 백엔드 업무 로직을 Agent에 맞게 바꾸지 않습니다. 입력값 설명과 읽기·쓰기 작업의 위험도는 팀이 별도로 검토해야 합니다.
도구 목록을 보여 주는 요청에도 인증이 필요한가요?
기본 설정의 tools/list는 공개될 수 있으므로 도구 이름과 설명이 노출되어도 되는지 먼저 판단해야 합니다. 운영 환경에서 도구 발견을 보호해야 한다면 해당 요청의 인증 요구사항을 구성하고 검증하세요. 도구 목록을 보호하는 조치와 도구 실행 권한은 같은 통제가 아닙니다. 두 경계를 각각 시험해야 합니다.
Agent가 도구를 실행할 때 기존 API 인증 정책을 계속 사용하나요?
공식 안내에 따르면 MCP 도구 호출은 REST 요청으로 이어지며 기존 작업의 인증 정책을 적용할 수 있습니다. 그렇더라도 호출 주체와 전달되는 자격 증명을 시험하지 않으면 권한 경계를 확인한 것이 아닙니다. API Gateway의 인증, 할당량, 로그는 운영 통제에 도움이 되지만 Agent의 전체 권한 관리 체계를 대신하지 않습니다.
미리보기 기능으로 모든 MCP 클라이언트와 작업을 처리할 수 있나요?
그렇게 가정하면 안 됩니다. 연결하려는 클라이언트가 요구하는 기능과 Google 문서에 적힌 미리보기 지원 범위를 대조하세요. 특히 리소스, 프롬프트, 스트리밍 응답, 오래 걸리는 도구 호출이 핵심 요건이라면 각각 지원 여부를 확인해야 합니다. 필수 기능이 확인되지 않으면 자체 MCP 구현을 유지하거나 제품 업데이트를 기다리는 편이 안전합니다.
7미리보기로 충분한지, 기존 구현을 남길지 결정하세요
REST API를 Agent에 연결하는 것이 목표라면 Gateway 미리보기는 시험해 볼 수 있지만, 도구 발견이 열려 있을 수 있고 기능 범위가 정식 제품과 같다고 보장되지 않으며 Agent별 권한 정책까지 대신하지도 않습니다. 우선 필요한 작업과 인증 경계를 검증하고, 스트리밍이나 장시간 실행이 필수라면 기존 구현을 성급히 대체하지 마세요.
Apple 도구 체인까지 필요한 프로젝트는 API Gateway와 Mac 빌드 환경을 별도 항목으로 평가해야 합니다. 상시 사용하며 물리 장비 접근이 필요한 팀은 자체 Mac이 더 적합할 수 있습니다. 반대로 시험이나 앱 빌드 기간에만 Mac이 필요하다면 vpstix의 원격 Mac 이용 정보를 확인한 뒤 필요한 실행 환경을 검토하세요.
8자주 묻는 질문
기존 REST API를 MCP 도구로 제공하려면 무엇부터 준비해야 하나요?
먼저 API의 OpenAPI 3.x 명세가 실제 동작과 일치하는지 확인하고, Agent에 노출할 작업만 고릅니다. 그 명세에 MCP 설정을 추가해 API Gateway 구성을 배포하면 MCP 진입점을 마련할 수 있습니다. 다만 이 과정은 백엔드 업무 로직을 Agent에 맞게 바꾸지 않습니다. 입력값 설명과 읽기·쓰기 작업의 위험도는 팀이 별도로 검토해야 합니다.
도구 목록을 보여 주는 요청에도 인증이 필요한가요?
기본 설정의 tools/list는 공개될 수 있으므로 실제 도구 이름과 설명이 노출되어도 되는지 먼저 판단해야 합니다. 운영 환경에서 도구 발견을 보호해야 한다면 해당 경로의 인증 요구사항을 별도로 구성하고 검증하세요. 도구 목록을 숨기는 조치와 도구 실행 권한은 같은 통제가 아닙니다. 두 경계를 각각 시험해야 합니다.
Agent가 도구를 실행할 때 기존 API 인증 정책을 계속 사용하나요?
공식 안내에 따르면 MCP 도구 호출은 REST 요청으로 이어지며 기존 작업의 인증 정책을 적용할 수 있습니다. 기존 인증이 남아 있더라도 호출 주체와 전달되는 자격 증명을 테스트하지 않으면 권한 경계를 확인한 것이 아닙니다. API Gateway의 인증, 할당량, 로그는 유용한 운영 통제지만 Agent의 전체 권한 관리 체계를 대신하지는 않습니다.
미리보기 기능으로 모든 MCP 클라이언트와 작업을 처리할 수 있나요?
그렇게 가정하면 안 됩니다. 연결하려는 클라이언트가 요구하는 기능과 Google 문서에 적힌 미리보기 지원 범위를 대조하세요. 특히 리소스, 프롬프트, 스트리밍 응답, 오래 걸리는 도구 호출이 핵심 요건이라면 각각 지원 여부를 확인해야 합니다. 필수 기능이 확인되지 않으면 자체 MCP 구현을 유지하거나 제품 업데이트를 기다리는 편이 안전합니다.
9더 읽기
vpstix M4 원격 노드
AI 도구 연동을 원격 맥에서 검증해 보세요
vpstix에서 실제 맥 미니를 단독으로 대여해 에이전트와 API 연동 작업을 진행할 수 있습니다.