WebMCP 오리진 트라이얼: 웹이 AI 에이전트에게 '행동 계층'을 연다

핵심 요약

• WebMCP는 W3C Web Machine Learning 커뮤니티 그룹에서 나와 마이크로소프트와 구글 엔지니어가 공동 저술했으며, 2026년 2월 10일 처음 공개된 오픈 웹 표준입니다(No Hacks).
• WebMCP는 플래그 뒤 프로토타입에서 크롬 149부터 156까지 실행되는 공개 오리진 트라이얼로 승격됐고, Chromium "Intent to Experiment"는 2026년 5월 15일 제출돼 3일 뒤 승인됐습니다(No Hacks).
• 한 초기 구현자가 Chrome DevTools용 WebMCP 폴리필로 클라이언트 측에서 도구를 실행한 결과, 초기 벤치마크에서 토큰 사용량이 약 90% 감소했다고 보고했습니다(InfoQ 인용).
• 현재 이 도구를 소비하는 유일한 에이전트는 크롬 내 Gemini이며, Expedia·Booking.com·Shopify·Etsy·Instacart·Target 등이 실험 중인 초기 채택사입니다(Developers Digest).
• 오리진 트라이얼은 프로덕션 배포용이 아니며, WebMCP 도구는 페이지가 브라우저 탭에 보일 때만 작동하고 헤드리스 지원이 없습니다(Developers Digest·InfoQ).

WebMCP란 무엇이고 왜 지금 주목받나?

WebMCP는 웹사이트가 자신의 기능을 구조화된 호출형 도구로 AI 에이전트에 노출하는 브라우저 표준입니다. 기존 브라우저 에이전트는 DOM을 스크래핑하거나 UI를 픽셀 단위로 추측해 클릭하는 불안정한 방식에 갇혀 있었고, 디자이너가 클래스명 하나만 바꿔도 깨졌습니다. WebMCP는 새로운 navigator.modelContext API를 통해 에이전트가 화면을 캡처해 추측하는 대신, 사이트가 할 수 있는 일과 각 작업에 필요한 정확한 매개변수 목록을 건네주는 방식으로 이 문제를 뒤집습니다(No Hacks).

주목할 점은 이름과 달리 WebMCP가 Anthropic의 MCP가 아니라는 것입니다. JSON-RPC 스펙을 따르지 않으며, MCP의 API 표면과 개념 모델(스키마를 가진 도구)만 공유하고 전적으로 클라이언트 측에서 실행됩니다. 이 경우 웹페이지 자체가 에이전트가 도달하면 시작되는 '서버'가 됩니다(Arcade.dev).

MCP와 어떻게 다르고, 어떻게 구현되나?

결론부터 말하면 MCP는 에이전트-서버 연결, WebMCP는 에이전트-브라우저 연결입니다. 두 표준의 관계와 구현 방식을 정리하면 다음과 같습니다.

구분	MCP	WebMCP
연결 대상	개발자가 통제하는 인프라(DB·API·파일시스템)	방문하는 웹사이트
통신 위상	에이전트-서버	에이전트-브라우저
도구 정의	타입 지정 매개변수	타입 지정 매개변수 (공유)

출처: Developers Digest.

WebMCP 스펙은 두 개의 API 표면을 정의합니다. 선언형(Declarative) API는 기존 HTML 폼에 toolname·tooldescription 같은 속성을 붙여 사용하고, 명령형(Imperative) API는 modelContext 인터페이스로 이름·설명·입력 스키마를 갖춘 도구를 등록합니다(InfoQ). WebMCP는 웹페이지 편집 권한을 가진 프런트엔드 개발자만 있으면 되어 웹의 롱테일에게 진입장벽이 낮다는 점이 특징입니다.

지금 실제로 작동하는 범위는 어디까지인가?

현재 실질 소비처는 크롬 내 Gemini 단일이며, 교차 브라우저 지원은 미확정으로 보는 것이 안전합니다. Gemini는 오리진 트라이얼 "직후" WebMCP를 지원할 예정입니다(Developers Digest). 교차 브라우저에 대해서는 출처 간 충돌이 있어, 한쪽은 Firefox Q3·Safari Q4 지원을 주장하지만(byteiota, 추정), 더 신중한 자료는 2026년 6월 기준 Edge 147 공식 릴리스 노트에 WebMCP가 없고 Mozilla·Apple의 공개 신호도 없다고 지적합니다(No Hacks).

한계도 분명합니다. 오리진 트라이얼은 프로토타입용이지 프로덕션 배포용이 아니며, WebMCP 도구는 페이지가 브라우저 탭에 보일 때만 작동합니다. 이는 사용자가 에이전트의 행동을 볼 수 있어야 한다는 보안 제약입니다. 또한 스펙 저자들은 LLM이 간접 프롬프트 인젝션에 취약하며 네이티브 사이트 API 노출이 관리해야 할 보안 위험을 도입한다고 경고합니다(Developers Digest·InfoQ). 참고로 마케팅에서 도는 "89% 토큰 효율"·"67% 오류 감소" 류 수치는 홍보성 페이지에 근거해 독립 검증되지 않았으므로 인용을 피해야 합니다.

TableFlip 관점

WebMCP는 GEO/AEO의 경쟁 축을 근본적으로 확장합니다. 지금까지 핵심 질문이 "AI 답변에 우리 브랜드가 인용되는가"였다면, 이제 "AI 에이전트가 우리 사이트에서 실제로 예약·주문·결제를 완료할 수 있는가"가 더해집니다. 'Buy' 버튼은 사람에겐 클릭 대상이자 에이전트에겐 도구 정의가 되는 셈입니다. 현재 유일 소비처가 크롬 내 Gemini라는 점에서 크롬 비중이 큰 국내 웹 환경은 조기 영향권에 있으며, 도구를 등록하지 않은 사이트는 취약한 스크래핑을 받거나 아예 건너뛰어질 수 있습니다.

다만 초기 채택사(Booking.com·Shopify·Etsy 등)가 모두 해외 플랫폼이라는 점은 국내 브랜드가 아직 이 표면에서 '보이지 않는' 상태임을 시사합니다. TableFlip의 실무 관점에서는 대규모 투입보다 (1) 현재 AI 답변 노출 상태를 진단하고, (2) 핵심 전환 플로우 소수를 도구로 노출하는 구조 개선 파일럿을 돌리며, (3) 프롬프트 인젝션 대비 권한 설계를 병행하고, (4) 월간 모니터링으로 실측하는 단계적 접근을 권합니다. TableFlip이 매주 실측하는 AI 노출 리포트와 GEO 진단 방법론은 이 전환기에 '노출→행동' 축의 현재 위치를 파악하는 출발점이 됩니다.

표준이 오리진 트라이얼 단계인 지금이 저비용 실험으로 선점 여지를 확인할 시점입니다 — 무료 AI Visibility 진단으로 우리 브랜드의 현재 위치부터 점검해 보세요.