🌐 WebMCP란 무엇인가 — AI가 웹을 ‘읽는’ 방식이 달라진다

WebMCP(Web Model Context Protocol)는 2026년 2월 구글과 마이크로소프트가 공동으로 발표한 브라우저 내장형 AI 에이전트 표준입니다. 핵심 아이디어는 간단합니다. 웹사이트가 AI 에이전트에게 “나는 이런 기능이 있어요”라고 직접 알려주는 것이죠. 개발자는 기존 HTML 폼이나 JavaScript에 몇 줄만 추가하면, 웹사이트가 AI가 이해할 수 있는 ‘도구 계약서(Tool Contract)’를 발행하게 됩니다.

기술적으로는 navigator.modelContext라는 새로운 브라우저 API를 통해 구현됩니다. AI 에이전트(예: Gemini 기반 크롬 확장, Claude Code 등)가 페이지를 방문하면 이 API를 통해 해당 사이트가 제공하는 도구 목록을 즉시 쿼리할 수 있습니다.

구글 Chrome 엔지니어 Khushal Sagar는 WebMCP를 “AI 에이전트 상호작용의 USB-C”라고 표현했습니다. USB-C 이전에 라이트닝, 마이크로USB, 프로프리에터리 케이블이 난립했듯, 지금 AI 에이전트들은 각기 다른 스크래핑 방식으로 웹을 이해하려 합니다. WebMCP는 그 혼란을 하나의 표준으로 통일합니다.

▲ 목차로 돌아가기

💸 왜 지금 WebMCP인가 — 스크래핑의 숨겨진 비용

현재 AI 에이전트가 웹사이트에서 작업을 수행하는 방식은 크게 두 가지입니다. 하나는 스크린샷을 캡처해 멀티모달 모델(Claude, Gemini 등)에 전달하는 방식, 다른 하나는 원시 HTML과 JavaScript를 파싱해 의미를 추론하는 방식입니다. 두 방법 모두 근본적인 비효율을 안고 있습니다.

사람이 2초면 끝낼 상품 검색 하나에, AI 에이전트는 스크롤, 스크린샷 업로드, 이미지 분석, 클릭 시도를 수십 번 반복합니다. 이미지 한 장당 수천 개의 토큰이 소모되고, 웹사이트 UI가 조금만 바뀌어도 전체 자동화 워크플로우가 무너집니다. 실제로 복잡한 이커머스 결제 플로우를 처리할 때 시각 기반 에이전트는 도구 기반 접근 대비 67% 더 많은 연산 오버헤드를 발생시킨다는 초기 벤치마크가 보고되었습니다.

여기서 제 개인적인 관점을 덧붙이자면, 이 문제는 단순한 효율 문제가 아닙니다. AI 에이전트 서비스를 실제로 배포하는 기업에게는 직접적인 운영 비용 문제입니다. 하루에 수만 건의 상담이나 예약을 처리하는 서비스라면, 스크린샷 기반 에이전트와 WebMCP 기반 에이전트 간의 비용 차이는 월 수천만 원 수준이 될 수도 있습니다.

▲ 목차로 돌아가기

🔧 작동 원리 — 선언형 API vs 명령형 API

WebMCP는 개발자에게 두 가지 통합 경로를 제공합니다. 자신의 사이트 구조와 복잡도에 따라 선택할 수 있으며, 두 방식을 혼합해서 사용하는 것도 가능합니다.

① 선언형 API (Declarative API) — 코드 거의 없이 연결

기존 HTML <form> 요소에 toolname, tooldescription, toolautosubmit 속성만 추가하면 됩니다. 이미 잘 구조화된 HTML 폼이 있다면 전체 작업의 80%는 완료된 것이나 다름없습니다. 브라우저가 자동으로 해당 폼을 AI 에이전트가 호출할 수 있는 도구로 변환합니다.

② 명령형 API (Imperative API) — 복잡한 동적 상호작용까지

실시간 대시보드나 다단계 필터링처럼 복잡한 상호작용이 필요한 경우 navigator.modelContext.registerTool() API를 사용합니다. OpenAI나 Anthropic API의 도구 정의와 개념적으로 유사하지만, 별도의 백엔드 서버 없이 브라우저 클라이언트 사이드에서만 실행된다는 점이 핵심 차별점입니다.

예를 들어 항공권 예약 사이트라면 searchFlights(origin, destination, date) 또는 buyTicket(flightId, passengerInfo) 같은 함수를 JSON 스키마와 자연어 설명을 포함해 등록할 수 있습니다. AI 에이전트는 이 도구를 발견하는 순간, 화면을 추측하지 않고 구조화된 함수를 직접 호출합니다.

▲ 목차로 돌아가기

🔄 기존 MCP와 뭐가 다른가 — 백엔드 vs 브라우저

이름이 비슷해서 헷갈리기 쉽지만, WebMCP와 Anthropic의 MCP(Model Context Protocol)는 전혀 다른 레이어에서 작동합니다. 두 기술은 경쟁이 아니라 보완 관계입니다. 이 차이를 이해하는 것이 WebMCP를 제대로 활용하는 첫 걸음입니다.

Anthropic MCP는 백엔드 프로토콜입니다. Python이나 Node.js로 별도의 MCP 서버를 구축해 AI 플랫폼(ChatGPT, Claude 등)과 기업 내부 시스템·API를 서버-투-서버로 연결합니다. 사용자가 브라우저 앞에 없어도 작동하는 서비스 자동화에 적합합니다.

반면 WebMCP는 브라우저 클라이언트 프로토콜입니다. 사용자가 브라우저 앞에 앉아 있고, 에이전트와 함께 페이지를 탐색하는 상황을 위해 설계되었습니다. JSON-RPC 스펙을 따르는 MCP와 달리, WebMCP는 브라우저의 navigator.modelContext API를 통해 페이지 내에서 완전히 실행됩니다.

실제 비즈니스 사례로 설명하면, 항공사는 백엔드 MCP 서버로 ChatGPT·Claude 같은 AI 플랫폼과 직접 예약 시스템을 연동하고, 동시에 소비자용 예약 웹사이트에 WebMCP를 구현해 사용자가 브라우저로 방문할 때 AI 어시스턴트가 자연스럽게 검색·필터·결제 흐름을 보조하도록 할 수 있습니다. 두 표준이 서로 충돌 없이 공존합니다.

▲ 목차로 돌아가기

⚙️ 지금 바로 써보는 법 — Chrome 146 Canary 설정 가이드

2026년 3월 현재 WebMCP는 Chrome 146 Canary 버전에서 실험적 플래그 뒤에 숨겨진 채 제공됩니다. 일반 Chrome 안정 버전에서는 아직 사용할 수 없으니, 아래 절차를 따라야 합니다. Canary는 개발자·얼리어댑터용 빌드로, 일반 Chrome과 별도로 설치해도 충돌 없이 사용할 수 있습니다.

아직 일반 사용자에게 공개된 WebMCP 지원 사이트가 많지 않은 것이 현실입니다. 그러나 바로 이 시점이 기회입니다. 구글은 2026년 중반~후반(구글 클라우드 넥스트, 구글 I/O)을 공식 롤아웃 시점으로 예고하고 있으며, 그때까지 얼리어댑터로 적용을 마친 사이트는 AI 에이전트 트래픽에서 선점 우위를 가져갈 수 있습니다.

▲ 목차로 돌아가기

🛒 내 블로그·쇼핑몰에 적용하면 뭐가 달라지나

WebMCP가 본격 확산되면 웹사이트 운영자에게는 사실상 “기술 SEO의 다음 시대”가 열립니다. 일부 전문가들은 이미 WebMCP를 “구조화 데이터(Structured Data) 이후 가장 큰 기술 SEO 전환점”으로 평가하고 있습니다. 10여 년 전 모바일 퍼스트 인덱싱이 도입됐을 때와 비슷한 충격이 예고됩니다.

이커머스 쇼핑몰이라면 searchProducts(query, category, priceRange), addToCart(productId, quantity), checkout(cartId) 같은 도구를 등록하면, AI 쇼핑 어시스턴트가 화면을 읽는 대신 이 함수들을 직접 호출해 상품을 찾고 구매까지 완료할 수 있습니다. 고객 지원 센터라면 submitTicket(issue, deviceModel) 도구 하나로 기술 문의를 받을 때 에이전트가 자동으로 기기 정보를 채우고 티켓을 생성할 수 있습니다.

개인 블로그 운영자에게도 의미가 있습니다. 콘텐츠 검색 기능에 WebMCP를 적용하면, AI 에이전트가 독자를 대신해 블로그 내 특정 주제의 글을 구조적으로 탐색하고 요약하는 것이 훨씬 자연스럽게 이루어집니다. B2AI(Business to AI) 시대에 AI에게 잘 보이는 사이트가 사람에게도 잘 보이는 사이트보다 더 많은 에이전트 트래픽을 유치할 수 있다는 것이 제 핵심 전망입니다.

▲ 목차로 돌아가기

🔒 보안 설계 — AI가 내 계정을 멋대로 건드리지 않는 이유

WebMCP를 처음 접한 사람들이 가장 많이 묻는 질문은 단연 “AI가 내 계정에서 멋대로 결제하거나 정보를 삭제하면 어떡하나요?”입니다. 그 우려는 정당하지만, WebMCP 명세서는 이 문제를 설계 단계에서 명확히 다루고 있습니다.

WebMCP 명세의 핵심 철학은 “사람 동석 설계(Human-in-the-Loop by Design)”입니다. 헤드리스(headless) 완전 자율 브라우징은 WebMCP의 설계 목표가 아닙니다. 명세서에는 완전 자율 시나리오는 비목표(non-goal)로 명시되어 있으며, 그런 사용 사례에는 구글의 별도 Agent-to-Agent(A2A) 프로토콜을 사용하도록 안내합니다.

구체적인 보안 장치는 세 가지입니다. 첫째, 세션 상속(Session Inheritance) — 에이전트는 현재 로그인된 사용자의 권한만 갖습니다. 에이전트 자체에게 별도의 슈퍼 권한이 부여되지 않습니다. 둘째, 명시적 상호작용(Explicit Interaction) — 결제나 삭제 같은 민감한 작업은 agent.requestUserInteraction()을 통해 반드시 브라우저 팝업으로 사용자 확인을 받아야 합니다. 셋째, 클라이언트 사이드 실행 — 모든 처리가 브라우저 내에서 완결되므로 민감한 토큰이나 세션 정보가 외부 백엔드 서버로 유출될 위험이 없습니다.

▲ 목차로 돌아가기

❓ Q&A — 가장 많이 묻는 5가지

▲ 목차로 돌아가기

✍️ 마치며 — 에이전틱 웹 시대, 지금 준비해야 할 것

WebMCP는 아직 실험적 플래그 뒤에 숨겨진 신기술입니다. 그러나 구글과 마이크로소프트가 공동으로 코드를 짜고, W3C가 제도적 뒷받침을 하고, Chrome 146에서 이미 작동하는 소프트웨어를 출시했다는 사실은 이 기술이 단순한 제안이나 개념 증명을 넘어섰음을 의미합니다.

과거 모바일 퍼스트 인덱싱이 도입됐을 때, 대응이 빨랐던 사이트는 초기 트래픽 급등의 혜택을 누렸고 늦은 곳은 몇 년치 SEO 노력을 한순간에 잃었습니다. WebMCP의 확산 속도는 그보다 더 빠를 수 있습니다. AI 에이전트 트래픽이 폭발적으로 증가하는 2026~2027년을 앞두고, WebMCP를 준비한 사이트와 그렇지 않은 사이트의 에이전트 가시성 격차는 점점 벌어질 것입니다.

지금 당장 운영 사이트에 전면 적용할 필요는 없습니다. 하지만 Chrome Canary를 설치해 인스펙터로 도구 계약서가 어떻게 보이는지 직접 확인하고, 자신의 사이트에서 가장 핵심적인 폼 한두 개에 선언형 API를 실험해 보는 것은 지금 당장 할 수 있는 일입니다. 표준이 정착되기 전에 손에 익혀두는 것이 2026년 이후 에이전틱 웹 시대를 앞서가는 가장 현실적인 방법입니다.

▲ 목차로 돌아가기