WebMCP, 구글 I/O 2026에서 가장 저평가된 발표.
Source: Dev.to
이 글은 Google I/O 2026 챌린지: Explore Google I/O 2026에 대한 제출물입니다.
모두가 Jules, Gemini Omni, 그리고 $100 AI Ultra 가격 인하에 대해 이야기하고 있습니다. 하지만 WebMCP에 대해서는 아무도 언급하지 않죠.
그것은 큰 실수입니다. WebMCP는 I/O 2026에서 구글이 발표한 가장 중대한 내용일 수도 있습니다—오늘날의 기능 때문이 아니라, 향후 10년간 웹 개발을 표준화할 것이기 때문이죠.
WebMCP는 브라우저 기반 AI 에이전트를 위한 제안된 오픈 웹 표준입니다. 간단히 말해, 개발자가 구조화된 도구(자바스크립트 함수, HTML 폼, 페이지 액션 등)를 노출하면 AI 에이전트가 DOM을 스크래핑하고 운에 맡기는 대신 신뢰할 수 있게 프로그래밍 방식으로 웹사이트와 상호작용할 수 있게 해줍니다.
실험적인 오리진 트라이얼이 Chrome 149에서 시작되며, 곧 Gemini가 Chrome 지원을 이어갈 예정입니다.
이름은 Anthropic이 AI와의 도구 사용을 위해 도입한 MCP(Model Context Protocol)를 떠올리게 합니다. WebMCP는 그 개념을 브라우저로 확장해, 웹 자체를 에이전트의 컨텍스트 레이어로 만듭니다.
현재 브라우저 AI 에이전트—구글의 Project Mariner도 포함—는 화면에 보이는 것을 관찰하고 클릭을 시뮬레이션합니다. 이는 인상적인 엔지니어링이지만, 예측 가능한 방식으로 취약합니다:
- 에이전트는 “Book Flight”(항공권 예약)처럼 보이는 버튼을 보지만, 그게 정확히 맞는 버튼인지 알 수 없습니다.
- UI 재디자인이 에이전트의 페이지 이해를 깨뜨립니다.
- 상호작용 후 동적으로 로드되는 콘텐츠가 에이전트의 정신 모델을 혼란스럽게 합니다.
- 모달 다이얼로그와 리다이렉트가 포함된 다단계 워크플로우는 에이전트가 상태를 잃게 합니다.
이는 화면 읽기 프로그램의 호환성 레이어와 진정한 API의 차이와 같습니다. 두 경우 모두 “페이지를 읽을” 수 있지만, 규모에 따라 신뢰할 수 있는 것은 하나뿐입니다.
WebMCP가 바로 그 진정한 API 레이어입니다.
개발자는 페이지에 구조화된 도구 정의를 주석으로 달아 “이 페이지가 수행할 수 있는 동작과 그 입력·출력 형태는 이렇다” 라고 선언합니다.
// WebMCP tool definition (simplified from the origin trial spec)
navigator.webmcp.registerTool({
name: "book_flight",
description: "Book a flight given origin, destination, and date",
parameters: {
origin: { type: "string", description: "IATA airport code" },
destination: { type: "string", description: "IATA airport code" },
date: { type: "string", format: "YYYY-MM-DD" },
},
handler: async ({ origin, destination, date }) => {
// Your existing booking logic
return await bookingApi.reserve({ origin, destination, date });
}
});WebMCP를 사용하는 AI 에이전트는 DOM을 파싱하거나 클릭을 흉내낼 필요가 없습니다. book_flight를 올바른 파라미터와 함께 호출하고, 타입이 지정된 응답을 받습니다. 신뢰성 차이는 정규식으로 HTML을 스크래핑하는 것과 REST 엔드포인트를 호출하는 것의 차이와 같습니다.
-
에이전트 신뢰성을 UI 안정성과 분리합니다.
오늘날 개발자가 결제 흐름을 재디자인하거나 버튼 위치를 바꿀 때마다, 기존 UI 레이아웃에 의존하던 에이전트는 모두 깨집니다. WebMCP를 사용하면 UI는 자유롭게 바뀔 수 있고, 에이전트는 시각 레이어와 별개로 유지되는 도구 인터페이스를 사용합니다. 즉, 에이전트가 UI에 독립하게 됩니다. -
개발자가 겨냥할 새로운 표면을 만듭니다.
현재 개발자는 두 가지 청중을 생각합니다: UI를 사용하는 인간, 그리고 API를 호출하는 다른 서비스. WebMCP는 세 번째 청중, 즉 인간을 대신해 행동하는 AI 에이전트를 추가합니다. 표준이 성숙하면, 모바일 반응형이나 REST API를 도입하던 것처럼 “WebMCP 지원”을 기능으로 내세우는 플랫폼이 늘어날 것입니다. -
오픈 표준이며 구글 독점이 아닙니다.
오리진 트라이얼은 Chrome 149에 포함되었지만, 구글은 WebMCP를 W3C 프로세스에 제출했습니다. 이는 Service Workers나 Fetch API가 표준화된 방식과 유사합니다. 충분한 관심을 얻으면 Firefox와 Safari도 구현할 것입니다. 에이전트와의 보편적인 상호작용 레이어가 있는 웹은 질적으로 다른 웹이 됩니다. -
에이전트형 앱을 위한 인프라 레이어입니다.
“웹을 탐색하는 AI 에이전트”를 구축하는 모든 기업은 현재 각각 DOM 파싱 문제를 독자적으로 해결하고 있습니다. WebMCP는 모두에게 공유되는 기반을 제공합니다. REST가 보편화되면서 맞춤형 XML‑RPC 프로토콜이 사라진 것과 같은 원리입니다. 표준이 있으면 툴링이 크게 향상됩니다.
WebMCP는 올바른 문제를 해결하지만, 작동하려면 개발자의 참여가 필요합니다. WebMCP 주석이 없는 사이트에 AI 에이전트가 접근하면 여전히 DOM 파싱에 의존하게 됩니다—표준은 개발자가 옵트인한 경우에만 효과가 있습니다.
웹 표준의 역사는 채택이 너무 늦어 사라진 좋은 아이디어들로 가득합니다. Schema.org 구조화 데이터가 기술적으로는 어디에나 있지만, 실제로는 대부분 절반만 구현하고 유지 관리도 하지 않죠.
WebMCP도 같은 채택 문제에 직면할 것입니다. 핵심은 구글이 충분히 많은 에이전트 가시 트래픽을 제공해, 개발자에게 “에이전트가 내 제품을 찾을 수 있게 하는 것”이 Google Search에 노출되는 것만큼 중요한 수익 동력이 되게 할 수 있느냐입니다. 그렇게 된다면 채택은 자동으로 따라올 것입니다.
오리진 트라이얼 덕분에 오늘 바로 Chrome 149에서 실험을 시작할 수 있습니다. 다음을 권장합니다:
- W3C 제안서를 팔로우하세요 — 공개되어 있고 논의가 활발합니다. 초기 단계에서 형성되는 표준은 여러분이 직접 영향을 미칠 수 있는 표준입니다.
- Project Mariner 데모를 살펴보세요 — DOM 기반 에이전트의 한계를 보여주며, 구조화된 레이어가 왜 중요한지 명확히 합니다.
- 제품의 “에이전트 표면”을 고민해 보세요 — 사용자를 대신해 AI 에이전트가 호출하길 원하는 행동은 무엇인가요? 그 목록이 바로 여러분의 WebMCP 도구 카탈로그가 됩니다.
웹은 두 번의 큰 변화를 겪었습니다: 정적 페이지, 그리고 API. WebMCP는 세 번째 시대, 즉 AI 에이전트가 인간만큼 자신 있게 웹을 활용할 수 있는 인프라입니다. 미리 대비하세요.
Links: