구글 I/O 2026에서 발표한 WebMCP, 가장 중요한 발표지만 거의 알려지지 않는다

출처: Dev.to

이 글은 Google I/O Writing Challenge에 제출된 작품입니다.
현재 웹사이트를 사용하려는 모든 AI 에이전트는 기본적으로 다음과 같은 과정을 거칩니다:

• 스크린샷을 찍는다
• 화면에 무엇이 있는지 추측한다
• 무언가를 클릭하고 운을 시험한다
• 또 다시 스크린샷을 찍는다
• 작동하거나 포기할 때까지 반복한다

이는 마치 서리 낀 유리창을 통해 누군가의 입술을 읽는 디지털 버전과 같습니다. 어느 정도 동작은 하지만 느리고 비용이 많이 들며, 약간이라도 동적인 요소—모달, 레이지 로드된 폼, JS 로드된 버튼—가 있으면 금방 깨집니다.

Google이 제시한 해결책은 WebMCP(Web Model Context Protocol)입니다. 2026년 5월 19일 Chrome 149의 퍼블릭 오리진 트라이얼에 I/O 개발자 키노트 중에 공개되었으며, 저는 이 발표가 전체 행사 중 가장 중대한 발표라고 생각합니다. 오늘 당장 할 수 있는 일과 앞으로 웹이 나아갈 방향을 시사하기 때문이죠.

WebMCP가 실제로 무엇인지, 지금 바로 어떻게 쓰는지, 그리고 성공 여부에 대해 제가 갖고 있는 진짜 의문점을 보여드리겠습니다.

아이디어는 단순합니다. AI 에이전트가 웹사이트를 눈으로 바라보며 스스로 동작을 파악하도록 하는 대신, 명시적으로 알려주는 것입니다.

WebMCP를 사용하면 구조화된 도구—JavaScript 함수와 주석이 달린 HTML 폼—를 브라우저 기반 AI 에이전트에 직접 노출할 수 있습니다. 에이전트는 스크래핑을 하지 않고, API처럼 여러분의 도구를 호출합니다.

구현 방법은 두 가지가 있습니다.

1. 기존 HTML 폼에 data-mcp-tool 속성과 설명을 추가한다. 에이전트는 이 주석을 읽고 폼이 정확히 무엇을 하는지 알게 됩니다.

   <select data-mcp-tool="category" description="상품 카테고리 선택">
     <option>All categories</option>
     <option>Electronics</option>
     <option>Clothing</option>
   </select>
   
   <input type="search" data-mcp-tool="search" description="검색어 입력">

   이렇게 하면 에이전트는 더 이상 필드가 의미하는 바나 폼의 동작을 추측할 필요가 없습니다. 여러분이 직접 알려준 것이니까요.

2. 프로그래밍 방식으로 도구를 등록한다.

   navigator.mcp.registerTool({
     name: "add_to_cart",
     description: "상품 ID와 수량을 지정해 장바구니에 추가합니다",
     parameters: {
       productId: {
         type: "string",
         description: "고유 상품 식별자"
       },
       quantity: {
         type: "number",
         description: "추가할 수량",
         minimum: 1
       }
     },
     handler: async ({ productId, quantity }) => {
       const result = await cartService.add(productId, quantity);
       return { success: true, cartTotal: result.total };
     }
   });

   에이전트가 { productId: "ABC123", quantity: 2 }와 함께 add_to_cart를 호출하면, 스크린샷 추측, DOM 파싱, 재시도 없이 신뢰할 수 있는 결과를 바로 얻습니다.

이 한 가지가 채택을 가속화하는 핵심 포인트입니다. WebMCP는 Google과 Microsoft가 W3C Web Machine Learning Community Group에서 공동으로 개발하고 있습니다. 이는 단순히 구글만의 표준이 아니라, 두 거대 브라우저 벤더가 처음부터 사양에 동의한 신흥 웹 표준이라는 뜻입니다. 이런 단계에서의 크로스 벤더 합의는 드물고 의미가 큽니다. 웹 플랫폼의 영구적인 일부가 될 가능성을 크게 높여줍니다.

브라우저 에이전트—사용자를 대신해 웹사이트를 탐색하는 AI 시스템—는 빠르게 성장하고 있습니다. WebMCP API를 지원할 예정인 Chrome의 Gemini가 그 한 예이며, 앞으로 더 많은 에이전트가 등장할 것입니다. 현재 이들 에이전트는 모두 동일한 깨지기 쉬운 DOM 스크래핑 전쟁을 벌이고 있습니다. WebMCP는 웹이 그들과 “절반씩 맞춰” 나갈 수 있는 방법을 제공합니다.

오늘 여러분의 사이트에 WebMCP를 구현하는 일은 2015년 적절한 aria-label을 추가하거나 2012년 og:title 메타 태그를 넣는 일과 같은 투자 범주에 속합니다. 당시엔 선택 사항처럼 느껴졌지만, 결국 필수 요소가 되었습니다.

선언형 API는 새로운 JavaScript 코드를 전혀 필요로 하지 않습니다—HTML 주석만 있으면 됩니다. 가장 흔히 쓰이는 사용자 흐름을 오후만에 에이전트에게 노출할 수 있습니다. 장벽이 충분히 낮아 “스프린트 계획 회의에서 바로 시도해보자”는 말이 합리적입니다.

하지만 저는 단순히 과대광고 기계가 되고 싶지는 않습니다. 여기엔 진짜 열려 있는 질문들이 있습니다.

방 안의 코끼리

Mozilla와 Apple은 아직 WebMCP에 참여하지 않았습니다. 표준이 웹에서 진정으로 성공하려면 Chrome만으로는 부족합니다. 현재 WebMCP를 구현하면 Chrome 전용이 됩니다.

이는 치명적인 문제는 아니지만—많은 의미 있는 기능이 처음엔 Chrome 전용 실험으로 시작해 나중에 폭넓게 채택된 사례가 있듯—실제 제약입니다. 사용자 기반이 Safari(모바일 웹, Apple 사용자) 중심이라면, Safari에서 브라우징하는 에이전트는 WebMCP 도구를 사용할 수 없습니다.

공식 Chrome 문서는 명확히 밝히고 있습니다: WebMCP는 브라우저 탭이 열려 있어야 합니다. 헤드리스 상태에서 도구를 호출하는 것은 지원되지 않습니다.

즉, WebMCP는 브라우저 내 에이전트 상호작용을 위한 것이며, 많은 기업 워크플로우가 의존하는 서버‑사이드 자동화 파이프라인에는 적합하지 않습니다. 그런 경우엔 여전히 백엔드 MCP 서버가 필요합니다. WebMCP와 서버‑사이드 MCP는 서로 보완적인 관계이며, 대체 관계는 아닙니다.

현재 WebMCP는 W3C Web Machine Learning Community Group이라는 인큐베이션 공간에 머물고 있습니다. 정식 웹 표준으로 가는 길은 길고 불확실합니다. Service Workers가 “제안 → 표준 → 보편화”의 과정을 밟았듯, WebMCP도 그런 길을 갈 수도 있고, 혹은 수많은 오리진 트라이얼 중 사라지는 경우도 있을 수 있습니다.

지금 바로 할 수 있는 실천 가이드

웹 앱에 폼이나 사용자 흐름이 있다면, 이번 주에 제가 할 일을 정리해 보았습니다.

1. Chrome 플래그 활성화
   chrome://flags에 접속해 “WebMCP”를 검색하고 Enabled로 설정한 뒤 재시작합니다. Chrome 149를 기다리지 않아도 바로 테스트할 수 있습니다.

2. 가장 중요한 사용자 흐름 하나 선택

3. 오리진 트라이얼에 등록

4. Chrome Gemini가 지원할 때 변화 관찰

제 개인적인 생각

I/O 2026을