WebMCP: 웹이 작동하는 방식을 재정의할 Google I/O 2026의 조용한 발표

모두가 Gemini 3.5에 대해 이야기하고 있습니다. 모두가 Neural Expressive의 애니메이션 응답에 대해 이야기하고 있습니다. Antigravity 2.0조차 박수갈채를 받았습니다. 하지만 제가 생각을 멈출 수 없었던 발표는 헤드라인에 거의 오르지 못한 것이었습니다. 바로 WebMCP입니다. 그것은 더 화려한 데모들 사이에서 Developer Keynote(개발자 키노트)에 파묻혀 있었습니다. 극적인 공개도 없었습니다. 유명 인사의 등장도 없었습니다. 그저 제안된 웹 표준, Chrome origin trial flag(Chrome 오리진 트라이얼 플래그), 그리고 개발자 블로그의 한 단락뿐이었습니다. 저는 이것이 Google이 발표한 가장 중대한 사항이라고 생각합니다.

먼저, 우리가 실제로 해결하려는 문제는 무엇인가요?
현재 AI 에이전트(AI agent)가 여러분의 웹사이트와 상호작용하기를 원한다면, 두 가지 좋지 않은 선택지가 있습니다:

옵션 1: 스크래핑 (Scraping). 에이전트가 인간이 하는 것처럼 DOM을 시각적으로 읽습니다. 레이블을 읽어 버튼이 무엇을 하는지 추측합니다. 플레이스홀더(placeholder) 텍스트에서 필드의 의미를 추론하여 양식을 채웁니다. 클릭하고, 기다리고, 긁어옵니다. 끊임없이 망가집니다. 모든 UI 변경 사항이 이를 망가뜨립니다.

옵션 2: 커스텀 API 구축 (Build a custom API). 에이전트만을 위해 별도의 백엔드 레이어(backend layer)를 작성합니다. 더 많은 코드, 더 많은 유지보수, 더 많은 인프라가 필요합니다. 그리고 모든 에이전트는 각기 다른 통합(integration) 방식이 필요합니다.

WebMCP는 옵션 3입니다: 여러분의 기존 웹사이트가 무엇을 할 수 있는지 선언하게 하고, 권한이 있는 모든 에이전트가 이를 직접 사용할 수 있도록 하는 것입니다.

WebMCP란 정확히 무엇인가요?
WebMCP는 개발자가 JavaScript 함수나 HTML 양식과 같은 구조화된 도구(structured tools)를 노출할 수 있도록 하는 제안된 오픈 웹 표준(open web standard)입니다. 이를 통해 브라우저 기반의 AI 에이전트가 더 높은 속도, 신뢰성 및 정밀도로 복잡한 작업을 수행할 수 있습니다. 이를 브라우저 내부에 존재하며 페이지 자체에 부착된 MCP (Model Context Protocol)라고 생각하면 됩니다.

이를 사용하는 두 가지 방법이 있습니다:

1. 선언적 API (Declarative API) — 기존 HTML에 주석 달기: 새로운 코드가 필요하지 않습니다.

기존의 폼(form)과 버튼에 mcp-tool 속성을 추가하기만 하면 됩니다: <!-- Before: 일반적인 검색 폼 --> <form action= "/search" method= "GET" > <input type= "text" name= "q" placeholder= "Search products..." /> <button type= "submit" > Search </button> </form> <!-- After: WebMCP가 활성화된 검색 도구 --> <form mcp-tool= "search_products" mcp-description= "키워드로 제품 카탈로그 검색" action= "/search" method= "GET" > <input type= "text" name= "q" mcp-param-description= "검색 키워드 또는 문구" placeholder= "Search products..." /> <button type= "submit" > Search </button> </form> 이것이 전부입니다. 이제 페이지를 방문하는 권한이 있는 에이전트(agent)는 어떤 입력창에 타이핑해야 할지 추측하는 대신, search_products를 정밀하게 호출할 수 있습니다.

2. 명령형 API (Imperative API) — JavaScript로 도구 등록: HTML 폼으로 깔끔하게 매핑되지 않는 동적인 동작을 위한 방법입니다:

// 브라우저 내 에이전트가 호출할 수 있는 구조화된 도구 등록
navigator . modelContext . registerTool ({
name : "add_to_cart",
description : "사용자의 쇼핑 카트에 제품 추가",
parameters : {
type : "object",
properties : {
product_id : {
type : "string",
description : "고유 제품 식별자"
},
quantity : {
type : "number",
description : "추가할 수량",
default : 1
}
},
required : ["product_id"]
},
handler : async ({ product_id, quantity = 1 }) => {
const response = await fetch("/api/cart", {
method : "POST",
headers : {
"Content-Type" : "application/json"
},
body : JSON . stringify ({
product_id ,
quantity
})
});
const result = await response . json ();
return {
success : result . ok ,
cart_total : result . cart_total ,
message : Added ${ quantity } x ${ product_id } to cart
};
}
});

이제 에이전트가 "SKU-4821 제품 2개를 카트에 담아줘"라고 말하면 여러분의 핸들러(handler)가 실행됩니다. DOM 스크래핑(scraping), 취약한 CSS 선택자(selectors), 애니메이션이 끝날 때까지 기다리는 과정이 전혀 필요 없습니다.

이것이 단순히 API를 구축하는 것과 무엇이 다른가요?
여러분은 이렇게 생각할 수도 있습니다: "나는 이미 REST API를 가지고 있는데."

그냥 그것을 사용하면 안 되나요? 여러분은 이렇게 생각할 수도 있습니다: "나는 이미 REST API를 가지고 있는데. 그냥 그것을 사용하면 안 되나요?" 차이점은 다음과 같습니다: WebMCP 도구는 브라우저 세션 (browser session) 내에 존재합니다. 이들은 다음 사항에 접근할 수 있습니다:

• 사용자의 현재 인증 상태 (authentication state)
• 페이지의 현재 컨텍스트 (사용자가 어떤 제품을 보고 있는지, 장바구니에 무엇이 들어있는지 등)
• 서버는 알 수 없는 DOM 상태
• 브라우저 측 권한 및 저장소 (storage)

에이전트 (agent)로부터의 REST API 호출은 사용자의 세션을 완전히 우회합니다. 에이전트가 자체적인 자격 증명 (credentials)을 가지거나, 에이전트를 위한 별도의 인증된 API 접점 (API surface)을 구축해야 합니다. 반면 WebMCP 에이전트는 사용자의 기존 세션을 상속받습니다. 사용자가 에이전트에 한 번만 권한을 부여하면, 그 시점부터 에이전트는 서버 측 에이전트 인프라 없이도 브라우저 내에서 해당 사용자로서 여러분의 도구를 호출할 수 있습니다.

// 에이전트 측면에서 WebMCP 상호작용이 어떻게 이루어지는지 //
// (이것은 개념적인 설명입니다 — Chrome의 Gemini 에이전트가 이를 내부적으로 처리합니다) //

에이전트는 다음과 같이 취약한 스크래핑 (scraping)을 수행하지 않습니다:

const addToCartButton = document.querySelector('.add-to-cart-btn'); addToCartButton.click(); // UI가 변경되면 바로 깨짐

대신 다음과 같이 수행합니다:

const tools = await navigator.modelContext.getTools(); const cartTool = tools.find(t => t.name === 'add_to_cart'); await cartTool.call({ product_id: 'SKU-4821', quantity: 2 }); // 안정적인 계약 (stable contract)

이것이 왜 중요한지를 보여주는 실제 시나리오

한 사용자가 여행 사이트에서 쇼핑을 하고 있다고 가정해 봅시다. 사용자가 Chrome의 Gemini에게 다음과 같이 말합니다: "다음 주 금요일에 뭄바이로 가는 왕복 항공권을 8,000루피 미만으로 찾아보고 예약해 줘."

WebMCP가 없다면, 에이전트는 다음과 같이 동작합니다:

• 검색 양식을 시각적으로 읽습니다.
• "출발지" 도시 필드를 찾아 채우려고 시도합니다.
• 날짜 선택기 (클릭하기 전까지는 DOM에 아무것도 렌더링하지 않는 여러분의 커스텀 React 캘린더 위젯)를 찾으려고 시도합니다.
• 실패합니다. 혹은 잘못된 필드를 스크래핑하거나 잘못된 날짜를 제출합니다.

WebMCP가 있다면, 여러분의 사이트는 다음을 노출합니다:
navigator.modelContext.

registerTool ({
  name : " search_flights ",
  description : " 두 도시 간 이용 가능한 항공편 검색 ",
  parameters : {
    type : " object ",
    properties : {
      origin : { type : " string ", description : " 출발 도시 또는 공항 코드 " },
      destination : { type : " string ", description : " 도착 도시 또는 공항 코드 " },
      departure_date : { type : " string ", description : " ISO 8601 날짜 (YYYY-MM-DD) " },
      return_date : { type : " string ", description : " 귀국 항공편을 위한 ISO 8601 날짜 " },
      max_price_inr : { type : " number ", description : " 인도 루피 기준 최대 가격 " }
    },
    required : [ " origin " , " destination " , " departure_date " ]
  },
  handler : async ( params ) => {
    // 기존의 항공편 검색 로직
    return await flightSearch ( params );
  }
});

에이전트(Agent)는 구조화된 파라미터(Parameters)를 사용하여 여러분의 도구(Tool)를 호출합니다. DOM 추측도, 취약성도 없습니다. 여러분의 기존 비즈니스 로직이 그대로 실행됩니다.

정직한 한계점 (현실적인 이유)

이 기술을 과장하고 싶지는 않습니다. 대부분의 개발자에게 WebMCP는 더 넓은 브라우저 지원이 이루어질 때 추적하고 구현해야 할 기술이지, 2026년 5월 당장 프로덕션 워크플로우(Production workflows)를 구축할 대상은 아닙니다. 현재의 실제 제약 사항은 다음과 같습니다:

• Chrome 149+ 버전만 지원: 아직 Firefox, Safari, Edge는 지원하지 않습니다.
• Chrome 내의 Gemini가 유일한 에이전트 소비자: 여러분의 도구는 현재 Chrome의 Gemini에 의해서만 호출될 수 있습니다. 외부 AI 앱, Anthropic의 Claude, 또는 여러분이 직접 구축한 커스텀 에이전트(Custom agents)는 호출할 수 없습니다.
• 여전히 커뮤니티 그룹(Community Group) 초안 단계: 아직 W3C 표준 트랙(Standards Track)에 올라가지 않았습니다.

// 도구를 등록하기 전에 WebMCP 지원 여부를 확인하세요
if ( ' modelContext ' in navigator ) {
  // WebMCP를 사용할 수 있음 — 도구 등록
  navigator . modelContext . registerTool ({ ... });
} else {
  // 우아한 폴백 (Graceful fallback) — 사이트는 정상적으로 작동함
  console . log ( ' WebMCP not supported in this browser ' );
}

항상 기능 감지(Feature-detect)를 수행하세요. 여러분의 페이지는 WebMCP 없이도 완벽하게 작동해야 합니다. 도구는 점진적 향상(Progressive enhancement)을 위한 것이지, 의존성(Dependency)이 아닙니다.

이를 테스트하기 위해 실제로 구축한 것

오리진 트라이얼(Origin trial)을 위해서는 해당 플래그가 활성화된 Chrome 149 버전 이상이 필요하기 때문에, 저는 아직 실제 에이전트(Agent)를 대상으로 테스트할 수는 없었지만, 멘탈 모델(Mental model)을 이해하기 위해 최소한의 프로토타입(Prototype)을 구축했습니다. 다음은 가상의 이커머스 사이트를 위한 도구(Tools)를 노출하는 간단한 상품 페이지입니다:

<!DOCTYPE html> <html lang= "en" > <head> <title> WebMCP Demo — Product Page </title> </head> <body> <h1 id= "product-name" > Wireless Keyboard </h1> <p id= "product-price" > ₹3,499 </p> <p id= "stock-status" > In stock: 12 units </p> <!-- 선언적 도구(Declarative tool): JavaScript 없이 작동함 --> <form mcp-tool= "check_stock" mcp-description= "Check current stock levels for a product" method= "GET" action= "/api/stock" > <input type= "hidden" name= "product_id" value= "kb-wireless-01" mcp-param-description= "The product ID to check" /> </form> <script> // 페이지 로드 후 명령형 도구(Imperative tools) 등록 if ( ' modelContext ' in navigator ) { // 도구 1: 장바구니에 담기 navigator . modelContext . registerTool ({ name : " add_to_cart " , description : " Add the currently viewed product to the shopping cart " , parameters : { type : " object " , properties : { quantity : { type : " number " , description : " Number of units to add (default: 1) " , minimum : 1 , maximum : 10 } } }, handler : async ({ quantity = 1 }) => { const productId = document . querySelector ( ' [name="product_id"] ' ). value ; const productName = document . getElementById ( ' product-name ' ). textContent ; // 장바구니 API 호출 시뮬레이션 await new Promise ( resolve => setTimeout ( resolve , 300 )); return { success : true , product_id : productId , product_name : productName , quantity_added : quantity , message : `Added ${ quantity } x ${ productName } to your cart` }; } }); // 도구 2: 제품 상세 정보 가져오기 navigator . modelContext .

registerTool ({ name : " get_product_details " , description : " 현재 보고 있는 제품의 전체 상세 정보를 가져옵니다 " , parameters : { type : " object " , properties : {} }, handler : async () => { return { id : " kb-wireless-01 " , name : document . getElementById ( ' product-name ' ). textContent , price_inr : 3499 , stock : 12 , category : " Keyboards " , url : window . location . href }; } }); console . log ( ' WebMCP tools registered: ' , [ ' check_stock ' , ' add_to_cart ' , ' get_product_details ' ] ); } </script> </body> </html> 제가 인상 깊게 본 패턴은 이렇습니다. WebMCP 도구를 작성하는 것이 마치 동료에게 내부 API를 통해 노출할 함수를 작성하는 것과 정확히 비슷하게 느껴집니다. 에이전트에 대해 생각하기보다는, 내 페이지가 무엇을 할 수 있는지에 대해 생각하고 그것을 명확하게 설명하는 것입니다. 이는 놀라울 정도로 자연스러운 사고 모델입니다.

더 큰 그림: 웹의 에이전트 네이티브화 (Agent-Native)
WebMCP가 대표한다고 생각하는 변화는 이것입니다. 지난 30년 동안 웹은 하나의 소비자, 즉 브라우저를 통한 인간만이 있었습니다. 지난 몇 년 동안 우리는 두 번째 소비자인 AI 에이전트를 추가했습니다. (지저분하고, 취약하며, 추출적입니다.) WebMCP는 세 번째 관계를 제안합니다: 구조화된 동의(structured consent)를 통한 AI 에이전트입니다. 웹사이트가 무엇을 노출할지 결정합니다. 사용자가 에이전트가 할 수 있는 것을 승인합니다. 에이전트는 안정적인 계약(stable contract)을 호출합니다. 이는 웹사이트와 그것을 사용하는 소프트웨어 간의 근본적으로 다른 관계를 의미합니다. 단순히 시각적 데이터를 스크래핑하는 현재의 에이전트들과 달리, WebMCP는 개발자가 구조화된 JavaScript 함수와 HTML 폼을 브라우저 기반 에이전트에 직접 노출할 수 있게 합니다. 이를 통해 AI가 여행 API 조회나 금융 데이터 제출과 같은 복잡한 백엔드 작업을 기계적 정밀도(machine precision)와 사용자 승인 하에 수행할 수 있습니다.

'사용자 승인' 부분은 '기계적 정밀도'만큼이나 중요합니다. 지금 개발자들이 해야 할 일
사양 초안을 읽어보세요. WebMCP 커뮤니티 그룹의 초안이 GitHub에 올라와 있습니다. 지금 사고 모델을 이해하는 것은 비용이 들지 않으며, Chrome 149가 광범위하게 출시될 때 큰 도움이 될 것입니다.

당신의 사이트가 무엇을 "하는지" 감사하십시오. 사용자가 사이트에서 수행할 수 있는 가장 가치 있는 5~10가지 작업을 목록으로 만드십시오. 그것들이 바로 당신의 미래 WebMCP 도구들입니다. 당신은 아마 이미 비즈니스 로직 (business logic)을 가지고 있을 것입니다. 단지 그것을 노출하기만 하면 됩니다. 선언적 API (declarative API)부터 시작하십시오. 기존의 HTML 폼 (HTML forms)이 있다면, mcp-tool 및 mcp-description 속성을 사용하여 주석을 다는 것만으로 JavaScript가 전혀 필요 없고 리스크도 제로입니다. 이것은 순수한 점진적 향상 (progressive enhancement)입니다. 기능 감지 (Feature-detect)를 철저히 하십시오. 모든 WebMCP 등록은 if ('modelContext' in navigator)를 통해 제어되어야 합니다. 당신의 페이지는 WebMCP 없이도 100% 기능해야 합니다. 당신의 도구 계약 (tool contracts)을 공개 API (public APIs)처럼 생각하십시오. 좋은 도구 이름, 명확한 설명, 그리고 정확한 파라미터 (parameter) 문서화가 중요합니다. 도구를 올바르게 사용하는 에이전트 (agent)의 능력은 당신이 그것을 얼마나 잘 설명하느냐에 전적으로 달려 있습니다.

마지막 생각: AJAX, 반응형 디자인 (responsive design), PWA와 같은 모든 주요 웹 플랫폼의 변화는 동일한 패턴을 따랐습니다. 처음에는 틈새 개발자 실험처럼 보였으나, 이후 기본값이 되었습니다. WebMCP는 현재 실험 단계에 있습니다. 제약 사항은 실재합니다. 브라우저 지원은 좁습니다. 유일한 에이전트 소비자(agent consumer)는 하나의 Google 제품뿐입니다. 하지만 사고 모델 (mental model)은 깔끔합니다. 사용 사례 (use cases)는 명확합니다. 점진적 향상 (progressive enhancement)의 논리도 옳습니다. 그리고 대안은 — 에이전트가 스크래핑하는 웹...