Google Maps 및 BigQuery '에이전트 준비 완료': MCP 혁명

“에이전트 미래”의 가장 큰 장벽은 모델의 지능이 아니었습니다. 그것은 연결의 어리 석음이었습니다.

지난 2년 동안 실제로 어떤 일(예: 데이터베이스 쿼리 또는 지도 확인)을 할 수 있는 AI 에이전트를 구축하려면 복잡한 “접착제 코드”가 필요했습니다. 개발자는 함수 정의를 수동으로 작성하고, 인증을 처리하고, JSON 스키마를 구문 분석하고, API가 변경될 때마다 “도구”를 지속적으로 업데이트해야 했습니다. 깨지기 쉽고 맞춤형이며 확장이 불가능했습니다.

설상가상으로 모든 플랫폼은 서로 다른 언어를 사용했습니다. OpenAI에는 “Actions”가 있고 Anthropic에는 “Tools”가 있으며 LangChain에는 “Toolkits”이 있습니다. GPT-4용 통합을 구축한 경우 재작성 없이는 Claude에서 작동하지 않았습니다.

그 시대는 막 끝났습니다.

표준을 오픈소스화한 Anthropic의 뒤를 이어 표준화를 향한 업계의 움직임에 맞춰 Google은 관리형 MCP(Model Context Protocol) 서버를 출시하고 있으며, Google Maps 및 BigQuery에서 완전 무료로 시작합니다.

이것은 단순한 기능 업데이트가 아닙니다. 이는 근본적인 아키텍처 변화입니다. Google은 인공 지능을 위한 USB 포트를 효과적으로 생성하여 “Agent-Ready by Design” 서비스를 만들고 있습니다.

후크: 이것이 지금 중요한 이유

지난 10년 동안 웹은 다음 두 가지 목적으로 최적화되었습니다.

1. 인간 (브라우저에서 HTML/CSS 제공)
2. 특정 애플리케이션(강한 프런트 엔드에서 사용되는 REST/GraphQL API)

범용 AI 에이전트용으로 설계되지 않았습니다. ChatGPT에 “내 근처 레스토랑을 찾아주세요”라고 요청하면 인간이 보는 방식으로 지도를 “볼” 수 없습니다. 훈련 데이터를 기반으로 추측하거나 도구가 장착된 경우 인간 엔지니어가 수동으로 연결한 특정 API 엔드포인트에 도달합니다.

이 “배선”이 병목 현상이었습니다. LLM을 Google 지도에 연결하려면 개발자는 다음을 수행해야 했습니다.

• Google Cloud 프로젝트를 프로비저닝합니다.
• Places API를 활성화합니다.
• API 키를 생성합니다.
• API를 호출하는 Python 함수를 작성합니다.
• 해당 기능을 LLM에 설명하기 위해 JSON 스키마를 작성합니다.
• LLM이 매개변수를 환각했을 때 오류 상태를 처리합니다.

관리형 MCP 서버를 제공하려는 Google의 움직임은 개발자가 더 이상 해당 배선을 구축할 필요가 없음을 의미합니다. 이제 개발자는 Maps MCP 서버를 간단히 “켜기”만 하면 에이전트가 지오코딩, 장소 검색 및 경로 계산 방법을 즉시 이해할 수 있습니다. 코드도 없고, 스키마 정의도 없고, 유지 관리도 없습니다.

이것이 램프를 벽에 고정하는 것과 단순히 소켓에 꽂는 것의 차이점입니다. Google에서 방금 소켓을 설치했습니다.

기술 심층 분석: “관리형 MCP 서버”란 무엇입니까?

이 규모를 이해하려면 MCP가 실제로 무엇인지, 그리고 Google의 구현이 개발 물리학을 어떻게 변화시키는지 살펴봐야 합니다.

1. 프로토콜(“USB 표준”)

**MCP(Model Context Protocol)**는 AI 모델이 데이터 및 도구와 상호 작용하는 방식을 표준화하는 개방형 표준입니다. MCP 이전에는 “통합 문제”가 N x M이었습니다. N 모델(Claude, Gemini, GPT)과 M 도구(Google Drive, Slack, Postgres)가 있는 경우 N*M 사용자 지정 통합이 필요했습니다.

MCP는 이를 N + M으로 줄입니다.

• 모델은 “클라이언트”(USB 포트)가 됩니다.
• 도구는 “서버”(USB 장치)가 됩니다.

프로토콜은 JSON-RPC 2.0을 기반으로 구축되었습니다. 이를 통해 클라이언트(AI 에이전트)는 서버에서 사용 가능한 도구, 리소스 및 프롬프트 목록을 요청할 수 있습니다. 서버는 표준화된 정의로 응답합니다. 에이전트가 도구를 사용하려고 하면 서버에 JSON-RPC 요청을 보내고 서버는 논리를 실행하고 결과를 반환합니다.

2. “관리되는” 부분(혁신)

이번 주까지 MCP 서버를 실행하는 것은 “로컬” 업무였습니다. 에이전트가 데이터베이스와 통신할 수 있도록 하려면 머신에서 로컬 Node.js 또는 Python 프로세스(예: npx -y @modelcontextprotocol/server-postgres)를 실행해야 했습니다.

이 아키텍처는 랩톱(Claude Desktop 사용)의 개발자에게는 작동하지만 프로덕션에서는 실패합니다. 웹 에이전트가 달력을 확인할 수 있도록 사용자에게 “로컬 터미널 명령 실행”을 요청할 수는 없습니다.

Google의 관리형 MCP는 개발자의 부담을 덜어줍니다.

• 관리할 Docker 컨테이너가 없습니다.
• 작성할 인증 핸드셰이크가 없습니다(자동으로 Google Cloud IAM을 사용합니다).
• 스키마 유지 관리 없음: Google이 BigQuery API를 업데이트하면 MCP 서버가 자동으로 업데이트됩니다.
• 프로토콜 전송: 로컬 MCP에 사용되는 stdio(표준 입력/출력) 대신 Google의 관리형 서버는 보안 채널을 통해 서버 전송 이벤트(SSE) 또는 HTTP POST를 사용하여 원격 에이전트가 안전하게 연결할 수 있도록 합니다.

3. BigQuery 및 지도 구현

BigQuery 구현은 특히 혁신적입니다.

• 스키마 검색: 클라이언트가 MCP 서버에 “사용 가능한 테이블은 무엇입니까?”라고 묻습니다. 서버는 테이블 이름뿐만 아니라 열 유형 및 설명도 포함하여 스키마를 반환합니다.
• 쿼리 생성: 에이전트는 열 유형과 관계를 기본적으로 이해합니다. transaction_date은(는) STRING이 아니라 TIMESTAMP임을 알고 있습니다.
• 실행: 에이전트는 SQL을 보내고, 서버는 모델이 예상하는 방식으로 형식화된 데이터를 반환합니다.

이는 BigQuery를 ‘데이터베이스 쿼리 도구’에서 사람이 라이브러리를 탐색하는 것처럼 쉽게 에이전트가 탐색할 수 있는 ‘지식 기반’으로 전환합니다. MCP 서버가 실측 스키마를 실시간으로 제공하므로 에이전트가 존재하지 않는 열(환각)을 만들어내는 위험을 제거합니다.

상황적 역사: “접착제 코드” 악몽

이를 이해하려면 흔히 “ReAct” 시대(추론 + 연기)라고 불리는 2023~2024년의 “최첨단 기술”을 살펴봐야 합니다.

획기적인 “ReAct” 논문에서 연구원들은 LLM이 “생각”, “행동”, “관찰”을 생성하여 도구를 사용할 수 있음을 보여주었습니다. 하지만 ‘액션’ 부분은 엉망이었습니다.

BigQuery에서 재고 재고를 확인한 다음 Google 지도에서 창고를 매핑할 수 있는 에이전트를 구축하려면 다음을 수행해야 했습니다.

1. 문서 읽기: BigQuery REST API 문서를 읽어보세요.
2. 코드 작성: Python 함수 check_inventory(sku)를 작성합니다.
3. 스키마 정의: 해당 함수를 LLM에 설명하는 JSON 스키마를 수동으로 정의합니다(예: “이 함수는 SKU 문자열을 사용합니다…”).
4. 인증 처리: API 인증(OAuth2 흐름)을 수동으로 처리합니다.
5. 반복: Google 지도에 대해 1~4단계를 반복합니다.
6. 출력 구문 분석: 지도의 이상한 JSON 출력을 LLM이 읽을 수 있는 것으로 구문 분석합니다.

브리틀이었습니다.

• API가 변경되면 에이전트가 중단됩니다.
• LLM이 잘못된 매개변수(예: int 대신 문자열 전송)를 인식한 경우 코드가 충돌합니다.
• OpenAI에서 Gemini로 전환하려면 도구 정의를 다시 작성해야 했습니다.

MCP는 “N+1” 문제를 해결합니다. 모든 에이전트가 모든 도구와 통신하는 방법을 배워야 하는 대신 모든 에이전트는 MCP를 말하고 모든 도구는 MCP를 말합니다.

”에이전트 웹”과 접지

이 업데이트의 가장 중요한 측면 중 하나는 접지입니다.

AI에서 “접지”는 환각을 방지하기 위해 모델의 반응을 검증 가능한 실제 데이터에 고정시키는 것을 의미합니다.

• Maps MCP가 없는 경우: “SFO까지 운전하는 데 얼마나 걸리나요?”라고 묻는 경우 모델은 2023년의 평균 교통 데이터를 기반으로 추측합니다.
• 지도 MCP 사용: 모델은 maps.get_route을 호출하고 실시간 교통 데이터, 도로 폐쇄 및 정확한 도착 시간을 수신합니다.

Google은 이를 지도용 “Grounding Lite”라고 부릅니다. 이를 통해 에이전트는 “공간을 인식”할 수 있습니다. 이는 물류, 배송, 여행사에 매우 중요합니다.

BigQuery의 경우에도 마찬가지로 ‘기업 기반 구축’이 가능합니다. “지난 달 매출은 얼마입니까?”라고 대답하는 상담원 추측하는 것이 아닙니다. 실제 원장에 대해 SELECT sum(sales) ... 쿼리를 실행하고 있습니다. MCP 서버는 실행 전에 쿼리가 구문적으로 올바른지 확인하여 보호 장치 역할을 합니다.

미래 예측 분석: “엔터프라이즈 OS”

Google의 MCP 채택은 업계가 표준으로 수렴하고 있다는 대규모 신호입니다. 이것이 에이전트의 “HTTP 순간”입니다.

1. “채팅” 인터페이스의 종말?

현재 대부분의 사용자는 채팅(ChatGPT, Gemini)을 통해 AI를 사용합니다. 관리형 MCP 서버를 사용하면 AI를 시스템 내부에 내장할 수 있습니다. 물류 대시보드에는 지도만 표시되는 것이 아닙니다. MCP 서버를 통해 매핑되는 자동 에이전트 모니터링이 있어 BigQuery 인벤토리 데이터에 영향을 미치는 트래픽 이상 현상을 감시하고 필요한 경우에만 경고합니다.

2. 다음 사람은 누구입니까?

Google(BigQuery/Maps)과 Anthropic(Claude)이 MCP를 지원함에 따라 이제 AWS 및 Microsoft에 압력이 가해지고 있습니다.

• AWS는 “DynamoDB용 관리형 MCP”를 출시할 예정입니까?
• Microsoft는 “Excel/그래프용 관리형 MCP”를 제공합니까?

그렇지 않으면 Google Cloud에서 에이전트를 구축하는 것이 Azure 또는 AWS에서보다 훨씬 빨라집니다. Google 서비스에 대한 ‘통합세’가 거의 0으로 떨어졌습니다.

3. 보안에 미치는 영향

물론 에이전트에게 데이터베이스에 대한 “신 모드” 액세스 권한을 부여하는 것이 위험합니다. 여기서 “로컬”과 “관리형”의 구별이 중요해집니다.

특정 “로컬” MCP 설정에서 에이전트는 사용자의 전체 권한으로 실행되는 경우가 많습니다. 하지만 Google의 구현은 Cloud IAM(ID 및 액세스 관리)에 의존합니다. MCP 서버는 서비스 계정에서 볼 수 있도록 허용한 것만 볼 수 있습니다.

• 특정 테이블에 대해 BigQuery Data Viewer 권한만 갖는 서비스 계정을 생성할 수 있습니다.
• MCP 서버는 해당 제한을 상속받습니다.
• 에이전트가 DROP TABLE을 시도하더라도 MCP 서버(IAM 지원)는 이를 거부합니다.

이는 CIO가 기다려 왔던 AI 에이전트의 서부 지역에 “엔터프라이즈급” 보안을 제공합니다.

결론

업계는 AI가 세상에 대해 단순히 ‘말’하는 시대에서 AI가 세상을 ‘만질’ 수 있는 시대로 옮겨가고 있습니다.

Google의 지도 및 BigQuery용 관리형 MCP 서버 출시는 이를 가능하게 하는 인프라입니다. 이는 융통성 없는 인간 중심 서비스를 유동적이고 상담사가 바로 사용할 수 있는 도구로 전환합니다.

개발자에게 메시지는 분명합니다. 글루 코드 작성을 중지하세요. openapi.yaml 파일 유지를 중지합니다. 새로운 표준이 여기에 있습니다. 소켓이 설치되어 있습니다. 이제 에이전트를 연결할 시간입니다.