도구 최대 1,000개, 공개 프리뷰

회사 안에 이미 있는 API를 AI 에이전트가 쓰게 하려면 보통 중간 서버를 하나 더 짠다. Google Cloud는 9월 24일 이 단계를 없앴다. API Gateway가 원격 MCP 서버 역할을 직접 하는 기능을 공개 프리뷰로 냈다. 게이트웨이 하나에 최대 1,000개 도구를 올릴 수 있다.

한 줄 정리

기존 REST API에 설명과 설정 한 줄만 붙이면 에이전트가 부를 수 있는 도구가 되고, 인증과 호출 제한은 지금 쓰는 규칙이 그대로 따라간다.

한눈에 보기

어떻게 굴러가나

에이전트가 도구를 부르면 게이트웨이가 그 요청을 평범한 REST 호출로 바꿔서 백엔드에 보낸다. 응답은 다시 MCP 형식으로 돌려준다. 백엔드 입장에서는 앱이 부른 것과 에이전트가 부른 것이 구분되지 않는다. 그래서 이미 설정해 둔 인증, 호출량 상한, 로그가 한 번에 적용된다.

제약도 분명하다. 본문이 없는 응답(HTTP 204)은 노출되지 않고, 깊게 중첩된 데이터 구조는 도구 설명에 온전히 안 담길 수 있다. 각 동작에는 백엔드와 비어 있지 않은 설명이 있어야 한다. 마지막 조건이 은근히 중요하다. 에이전트는 설명을 보고 도구를 고른다. 설명이 부실하면 호출도 엉뚱해진다.

코드를 모르는 팀장이 챙길 것

구현은 개발자나 외주가 한다. 정하는 일은 따로 있다.

• 어떤 기능을 에이전트에게 열 것인가. 주문 조회와 재고 확인은 열어도 환불 처리는 닫아 두는 식이다.
• 도구 목록 조회가 기본 무인증이라는 점. 어떤 기능이 있는지 목록 자체가 새어 나가도 되는지 판단해야 한다.
• 읽기와 쓰기를 갈라서 연다. 에이전트가 조회로 시작해 변경으로 넘어가는 순서가 안전하다.

커머스나 에이전시처럼 사내 시스템이 여럿 흩어진 팀이면 이 구조가 반갑다. 별도 연결 코드를 시스템마다 짜는 대신 이미 문서화된 API 목록이 곧 에이전트의 도구 목록이 된다.

위시클레이 관점

1,000개라는 상한은 용량 이야기가 아니라 설계 이야기다. 도구가 수백 개 달린 에이전트는 매번 맞는 걸 고르기 어렵고 고르는 데 토큰도 쓴다. 열 수 있다고 전부 열 이유는 없다.

이 기능이 실제로 바꾸는 건 접속 비용이다. 연결 코드를 짜는 몇 주가 설명 필드를 다듬는 며칠로 줄어든다. 그러면 병목은 코드에서 설명으로 옮겨 간다. "주문 상태를 조회한다"라는 한 줄과 "고객 주문번호로 현재 배송 단계와 예상 도착일을 돌려준다"라는 한 줄은 에이전트에게 전혀 다른 도구다. 사내 API 문서를 가장 정확하게 읽을 수 있는 사람은 개발자가 아니라 그 업무를 매일 하는 운영 담당이다.

그래서 이 프리뷰를 써 볼 팀은 개발 일정보다 먼저 사내 API 설명을 한 번 점검한다. 에이전트가 읽을 문장을 업무 담당이 직접 쓰는 팀이 앞서 간다.

참고

• Google Cloud API Gateway를 MCP 서버로 쓰기 (Google Developers Blog)
• Google 개발자 블로그 전체 목록, 같은 시기 발표 확인용 (Google Developers Blog)