Google Connected Apps Platform 프리뷰: MCP로 Search·Gemini에 서비스를 연결하기

하나의 서비스가 검색과 AI 대화에 연결되는 모습을 표현한 생성형 개념 이미지. 실제 Google 제품 화면이 아니다.

내 서비스의 기능을 Gemini나 Google 검색에서 실행하게 만들려면, 제품마다 별도 연동을 개발해야 할까. Google이 2026년 10월 28일 발표한 Connected Apps Platform 프리뷰는 MCP 서버와 Android AppFunctions를 연결 경로로 제시한다.

개발자에게 중요한 변화는 챗봇을 하나 더 만드는 것이 아니다. 기존 서비스의 조회·실행 기능을 AI가 호출할 수 있는 도구로 정리하고, 인증·검증·배포 절차를 마련하는 것이다. 다만 모든 개발자와 모든 지역에 정식 개방된 상태는 아니다. Google은 접근을 단계적으로 확대한다고 밝혔다. 공식 발표

서버 기능인가, 기기 안의 기능인가

먼저 실행 위치를 고른다.

• 서버 MCP: 웹 서비스의 데이터와 기능을 원격 MCP 서버로 제공한다. 기존 백엔드를 활용하려는 서비스에 적합한 경로다.

• Android MCP: AppFunctions로 Android 앱 기능을 노출한다. 기기 안에서 실행할 작업을 연결하는 경로다.

이는 서버용 MCP 엔드포인트가 곧 Android AppFunctions가 된다는 뜻은 아니다. AppFunctions는 플랫폼 API와 Jetpack 라이브러리를 사용하는 별도 구현이다. 공식 문서상 Android 16 이상에서 사용할 수 있고, 호출 앱에는 해당 실행 권한이 필요하다. 운영 대상 기기와 호출자 지원을 먼저 확인해야 한다. 플랫폼 개요 · AppFunctions 개요

이 글은 서버 MCP를 검토하는 개발자를 중심으로 정리한다. 실제 앱 등록, OAuth 연결, 배포나 유료 API 호출을 수행한 실험기는 아니다.

기존 REST API 앞에 이름만 붙이면 끝나지 않는다

원격 경로의 기본 조건은 공개 HTTPS 엔드포인트와 Streamable HTTP다. 기존 HTTP+SSE 전송 방식과 혼동하면 안 된다. Streamable HTTP 내부의 SSE 응답은 지원되지만, 예전의 분리된 SSE 전송 방식은 지원 대상이 아니다.

문서 확인 시점의 MCP 지원 상한은 2025-11-25 규격이다. SDK를 최신 버전으로 올렸다는 사실만으로 호환성을 단정하지 말고 초기화 협상과 도구 스키마를 함께 검증해야 한다. MCP 연동 표준

실무에서는 기존 API 전체를 노출하기보다 작은 조회 기능부터 시작하는 편이 낫다. 예를 들어 주문 서비스라면 다음처럼 범위를 나눌 수 있다.

위 내용은 API 규격이나 실행 코드가 아니라 도구 설계 예시다. 조회와 변경을 분리하면 권한 검사, 테스트, 사용자 확인이 필요한 지점을 구분하기 쉽다. 실제 소유권 검증은 서버에서 해야 하며, 모델이 올바른 주문 번호를 골랐다는 가정에 맡겨서는 안 된다.

인증과 도메인 검증을 별도 항목으로 둔다

Google의 안내는 OAuth 2.1과 PKCE를 권장하며, OAuth 2.1에서 PKCE를 필수로 설명한다. 지원하는 흐름은 authorization code 기반이다. 권한 범위와 토큰 갱신, 연결 해제 처리를 도구 구현과 함께 설계해야 한다. OAuth 구현 가이드

또한 콘솔 등록 전에는 MCP 도메인에 검증용 JSON 파일을 제공할 수 있어야 한다. 안내된 경로는 아래와 같으며, 리디렉션 없이 HTTP 200 응답이 요구된다. 등록 사전 조건

여기서 200이 나와도 MCP 도구 호출 성공이나 앱 심사 통과가 증명되는 것은 아니다. 도메인 검증 응답, OAuth 연결, MCP 초기화, 실제 도구 실행은 각각 다른 검증 단계다.

운영 로그에는 전체 토큰이나 인증 헤더를 남기지 않는다. 문제를 추적하려면 요청 식별자·단계·상태 코드·지연 시간을 먼저 기록하는 편이 안전하다.

Developer Mode에서 확인할 것은 답변 문장보다 호출 내용이다

Gemini Apps Developer Mode는 도구 실행과 스키마를 살펴보는 웹 기반 작업 공간이다. 콘솔에 등록한 앱뿐 아니라, 등록 전 배포된 HTTPS MCP 서버를 custom app으로 연결해 검토하는 경로도 문서에 제시되어 있다. 실제 이용 가능 여부는 계정과 프리뷰 접근 조건을 확인해야 한다.

공식 문서의 주요 검사 화면은 다음과 같다.

• Event Log: JSON-RPC 요청·응답, HTTP 상태, 지연 시간

• Tool Schemas: 매개변수·필수 항목·안전 관련 annotation

• Environment: 날짜·시간·언어에 따른 입력 차이

• Authentication: 연결과 인증 설정

이는 공식 문서 설명이며 이 글에서 해당 화면에 서비스를 연결해 시험한 결과는 아니다. Developer Mode 개요

검증 항목은 “답이 자연스럽다”보다 구체적이어야 한다. 아래는 도입 검토용 예시다.

테스트 계정과 비민감 데이터로 시작하고, 변경 기능은 실제 부작용을 고려해 별도로 시험한다. 읽기 전용이라는 annotation만으로 백엔드 접근 통제가 완성되는 것은 아니다.

프리뷰 테스트와 실제 배포를 구분한다

공식 서버 가이드는 구현·배포·Developer Mode 검증 후, 접근 신청과 Google Connected Console 등록을 거쳐 심사·공개하는 흐름을 안내한다. 테스트 화면에서 정상 호출됐다고 곧바로 모든 Search·Gemini 사용자에게 노출되는 것은 아니다. 서버 개발 가이드

배포 이후 스키마 변경도 주의해야 한다. 등록 시 도구·인자·서버 지침의 스냅샷이 사용되므로, 운영 서버의 스키마를 임의로 바꾸면 연동이 깨질 수 있다. 개발 중 스키마 동기화와 운영 앱 버전 관리를 같은 것으로 취급하지 않는 편이 안전하다.

지금 할 일은 대규모 전환보다 조회 도구 하나의 완성도 확인에 가깝다. 공개 HTTPS, 인증, 권한 검사, 이해하기 쉬운 반환값, 오류 처리까지 확인한 뒤 범위를 넓힌다. 새 배포 창구가 생겼다는 소식보다, 기존 API를 에이전트가 안전하게 사용할 수 있는 계약으로 정리하는 일이 먼저다.

확인 범위

2026년 10월 29일 한국 시간 기준으로 공식 발표와 개발 문서를 확인했다. 직접 서버를 등록하거나 인증 정보를 발급하지 않았으며, 서비스 호출·성능 측정·심사 통과를 시험하지 않았다. 프리뷰의 지원 지역과 계정별 접근, 프로토콜 지원 범위는 도입 시 최신 문서와 콘솔에서 다시 확인해야 한다.