WebMCP는 웹사이트가 자기 기능을 구조화된 도구로 노출하고, AI 에이전트가 DOM을 긁거나 스크린샷을 읽는 대신 그 도구를 직접 호출하게 한다. 2026년 5월 19일 Google I/O에서 Chrome이 이걸 실제 트래픽에서 시험할 수 있는 origin trial(Chrome 149)을 발표했다. 흔한 해석은 “이러면 내 사이트가 인용되고 레퍼럴 트래픽이 들어온다"는 것이다. W3C 드래프트엔 그런 말이 없다. 인용으로 먹고사는 사이트라면 WebMCP는 제로클릭 문제를 풀기는커녕 키울 수도 있다.
이 글은 2차 설명글이 아니라 1차 출처를 직접 읽고 정리했다. W3C Web Machine Learning 커뮤니티 그룹 드래프트와 Chrome 공식 origin trial 문서다. 통념과 스펙이 어긋나는 지점은 그대로 적었다. 수치와 스펙 디테일은 2026년 5월 기준이고, WebMCP는 완성 표준이 아니라 커뮤니티 그룹 드래프트라 세부는 바뀐다.
이 글이 필요한 이유
WebMCP를 검색하면 글은 두 종류다. “이게 뭐냐” 설명글, 그리고 “이걸 깔면 에이전트가 네 사이트를 고른다"는 마케팅. 스펙이 규범으로 정의한 것과 벤더가 바라는 것을 갈라 보는 글은 거의 없다. 지금 도는 핵심 주장 몇 개, 출처 인용을 강제한다, JSON-RPC로 말한다, “리소스"를 등록한다는 주장은 현재 드래프트에 없다. 이걸 전제로 콘텐츠·GEO 전략을 짜면 아직 존재하지 않는 토대 위에 짓게 된다.
무슨 일이 있었나
WebMCP는 2025년 말 Chrome 146에 플래그 뒤로 처음 들어왔다. 지금 중요한 변화는 이거다. 2026년 5월 19일 Google I/O에서 Chrome이 WebMCP를 Chrome 149 공개 origin trial로 넘긴다고 확정했고, 공식 문서는 5월 18일 공개됐다. origin trial은 개발자가 플래그를 켜는 수준이 아니라 실제 사이트가 운영 트래픽에서 켤 수 있다는 뜻이다. Chrome의 Gemini 연동은 “곧"이라고만 했고 날짜는 없다.
origin trial 문서에서 미리 알아둘 두 가지가 있다. 도구 호출은 탭이나 웹뷰가 열려 있어야 하고 헤드리스로는 안 된다. 그리고 교차 출처(cross-origin) iframe은 기본값으로 도구 접근이 막혀 있고, allow="tools" 권한을 명시해야 열린다. Safari·Firefox는 아직 입장이 없고, 현실적인 크로스 브라우저 지원은 빨라야 2027년 말이다. 그동안 다른 브라우저까지 닿으려면 폴리필(@mcp-b/global 패키지)을 쓴다.
WebMCP가 실제로 무엇인가
WebMCP를 쓰는 페이지는, 백엔드가 아니라 클라이언트 사이드 JavaScript로 도구를 구현하는 MCP 서버라고 보면 된다. 작성자는 Microsoft와 Google 엔지니어이고 W3C Web Machine Learning 커뮤니티 그룹에서 만든다. 드래프트는 Anthropic의 MCP와 정렬돼 있다.
규범 API는 작다. 페이지가 navigator.modelContext.registerTool()에 도구를 등록하는데, 도구엔 name, 자연어 description, JSON Schema inputSchema, 그리고 실제 일을 하고 구조화된 결과를 돌려주는 execute 콜백이 들어간다. 현재 드래프트가 정의한 핵심은 이게 전부다. 선택적 annotation으로 도구를 읽기 전용으로 표시하거나 출력이 신뢰할 수 없는 데이터임을 표시할 수 있고, 에이전트는 실행 도중 사용자 확인 단계를 요청할 수 있다. 전부 보안 컨텍스트(HTTPS)에서, 페이지 자신의 오리진 범위로 돌아간다.
에이전트가 그 도구를 어떤 형식으로 받는지는 일부러 열어뒀다. 스펙은 이름과 달리, 도구가 에이전트에 노출되는 형식을 규정하지 않는다고 못박는다. 브라우저는 MCP로, 독자적인 함수 호출 방식으로, 또는 다른 무엇으로든 노출할 수 있다. 브라우저는 페이지를 에이전트에 보여줄 “옵저베이션(observation)“을 만드는데, 거기엔 도구 목록뿐 아니라 스크린샷이 함께 담기는 경우가 많다. WebMCP는 에이전트가 픽셀과 DOM으로 추측하는 의존을 줄이지, 비전을 완전히 없애지는 않는다.
인용의 역설
과장이 건너뛰는 부분이 여기다. GEO가 작동하는 이유는 AI 답변이 출처를 인용하고 그중 일부가 클릭으로 넘어오기 때문이다. WebMCP는 다른 동선을 위해 만들어졌다. 에이전트가 도구를 호출하고, 구조화된 결과를 받고, 세션 안에서 작업을 끝낸다. 그 동선이 매끄러울수록 사용자가 에이전트를 떠나 내 페이지로 올 이유는 줄어든다.
예약·결제·견적·가입 같은 트랜잭션 사이트엔 좋은 소식이다. 에이전트가 그 동작을 끝내는 게 곧 전환이고, 그 동작이 내 오리진에서 일어난다. 주목을 수익으로 바꾸는 콘텐츠·레퍼런스 사이트엔 반대로 작용한다. 에이전트가 내 도구를 호출해 답을 바로 돌려주면, GEO가 기대는 그 클릭이 정확히 사라진다. WebMCP는 상인에겐 도움이 되면서 퍼블리셔에겐 제로클릭 문제를 키울 수 있다.
프레임은 단순하다. 내 가치가 행동이면 기회, 인용 클릭이면 위험이다.
과장된 주장, 어디가 틀렸나
| 도는 주장 | W3C 드래프트·Chrome 문서가 실제로 말하는 것 |
|---|---|
| WebMCP가 결과 출력 시 내 오리진 URL을 인용하도록 강제한다 | 그런 요구 없음. 브라우저는 출처 오리진을 보안 정보로서 에이전트에 전달한다(모델이 관련 당사자를 알도록). 사용자에게 보이는 인용이 아니다. 사용자가 출처 링크를 보는지는 스펙이 보장하지 않는다. |
| 도구를 JSON-RPC로 선언한다 | 스펙은 에이전트가 받는 전송 형식을 아예 규정하지 않는다. 입력은 JSON Schema로 기술하고, 나머지는 구현에 맡긴다. MCP 백엔드 전송이 JSON-RPC를 쓰는데, 그건 다른 층이다. |
도구와 함께 리소스(registerResource)도 등록한다 | 현재 드래프트의 ModelContext 인터페이스 메서드는 registerTool 하나다. 규범 스펙에 registerResource는 없다. |
| 스크린샷·비전을 완전히 없앤다 | 브라우저가 에이전트에 주는 “옵저베이션"엔 도구 목록과 함께 스크린샷이 들어가는 경우가 많다. 비전 의존을 줄이지, 지우지 않는다. |
| HTML 속성 두 개만 붙이면 끝 | 선언형(HTML form annotation) API는 드래프트에서 아직 TODO다. 지금 규정된 건 명령형 registerTool 경로다. |
WebMCP가 헛것이라는 말이 아니다. 핵심 GEO 주장인 인용 보장이 사실이 아니라는 것이고, 전략을 거기에 기대면 안 된다는 것이다.
GEO에 실제로 바뀌는 것
진짜 변화 세 가지, 어느 것도 자동 트래픽은 아니다.
도구 description이 새로운 랭킹 지점이 된다. 에이전트는 등록된 도구 중 무엇을 호출할지 name과 description을 보고 고른다. 그 문자열이 검색 스니펫에서 meta description이 하던 역할을 에이전트 선택에서 한다. 잘 쓰는 건 그 자체로 하나의 기술이다. 범위는 분명하게, 입력은 정직하게, 결과는 에이전트가 행동할 수 있게.
오리진은 모델에 닿지만, 인용이 아니라 신뢰 신호다. 브라우저가 안전 판단용으로 오리진을 에이전트에 넘기므로, 신뢰할 만하고 일관된 오리진이 모델이 내 도구를 호출하고 믿을지를 좌우한다. 이건 평판이지 레퍼럴 링크가 아니다.
상태와 단일 탭은 세션을 만들지, 방문을 보장하진 않는다. 도구는 탭이 열려 있는 동안만 작동하고, 페이지 상태에 따라 나타나거나 사라진다. 진짜 쓸모 있는 대시보드 도구는 탭을 살려두게 만든다. 그건 실질적인 사용자 관여지만, 사용자가 탭을 열어두게 강제할 수는 없고, 인용 클릭과 같지 않다.
보안 모델은 아직 미완이다
WebMCP는 브라우저의 오리진·HTTPS 보호를 물려받지만, 드래프트의 보안·프라이버시 섹션은 아직 비어 있고, 도구를 노출하려는 쪽이 신경 써야 할 미해결 이슈가 있다. 같은 페이지에 끼어든 1차·3차 스크립트가 등록된 도구를 덮어쓰고 에이전트 호출을 조용히 가로챌 수 있다. prompt injection과 도구 체이닝을 통한 데이터 유출도 인지됐을 뿐 해결되지 않았다. 도구 노출은 사이트에 새 공개 API 창구를 여는 일로 다루고, 파괴적 동작은 자동 실행하지 말고 확인 단계 뒤에 둬라.
빌더의 하이브리드, 정적 레이어를 지킨다
실용적인 선택은 GEO 셋업을 WebMCP로 갈아치우는 게 아니다. 두 레이어를 같이 굴리는 것이다. 정적이고 인용 가능한 콘텐츠(깔끔한 본문, 비교표, JSON-LD 구조화 데이터)는 그대로 둔다. 그게 AI 답변에 인용되고 검색에 색인되며, 인용 클릭이 나오는 곳이 여전히 거기이기 때문이다. 그 위에 에이전트가 직접 할 수 있어야 하는 동작을 WebMCP 도구로 얹는다. 정적 레이어는 인용을, 도구 레이어는 행동을 두고 겨룬다. 둘은 서로 다른 깔때기이고, 대부분의 사이트는 둘 다 필요하다.
최소한의, 정확한 예시
WebMCP 도구의 가장 작고 정직한 형태, 구조화된 데이터를 돌려주는 읽기 전용 조회다. 지금 규정된 명령형 API다.
// Register a read-only tool that an agent can call.
// Runs only while the tab is open; HTTPS (secure context) required.
navigator.modelContext.registerTool({
name: "get_plan_pricing",
description: "Return current plan names and monthly prices for this site.",
inputSchema: {
type: "object",
properties: {
currency: { type: "string", description: "ISO 4217 code, e.g. USD" }
}
},
annotations: { readOnlyHint: true }, // does not change state
execute: async (input) => {
const plans = await fetchPlans(input.currency ?? "USD");
// Include a next-step URL in the payload so the agent CAN surface it.
// The spec does not force the agent to show it — this is best practice, not a guarantee.
return { plans, source: location.origin + "/pricing/" };
}
});
source 주석을 보라. 응답 페이로드에 URL을 담는 게 내가 통제할 수 있는 “인용 얻기"에 가장 가깝다. 그조차도 그걸 보여줄지는 에이전트의 선택이지 프로토콜 규칙이 아니다.
누구에게 어떤 선택
| 내 사이트가… | WebMCP는… | 할 일 |
|---|---|---|
| 콘텐츠·레퍼런스 사이트(광고·어필리에이트) | 지켜봐야 할 위험 | 정적·인용 가능 레이어를 탄탄히. 읽기 전용 도구는 조심스럽게 추가. 에이전트 답변이 클릭을 잠식하는지 추적 |
| 트랜잭션 제품(예약·결제·SaaS 가입) | 진짜 기회 | 가장 가치 큰 동작을 도구로 노출. 도구 description을 랜딩 카피처럼 작성 |
| 일찍 실험하는 빌더 | 선점 우위, 단 변동 | Chrome 149 origin trial을 플래그 뒤에서 시험하되, 작업에 날짜를 박고 API 변경을 각오 |
FAQ
WebMCP가 내 사이트 인용이나 레퍼럴 트래픽을 보장하나?
아니다. 드래프트는 에이전트가 사용자에게 오리진 URL을 인용하도록 요구하지 않는다. 브라우저는 오리진을 보안 정보로 에이전트에 넘기고, 도구 출력에 URL을 담을 수는 있지만, 사용자가 링크를 보는지는 에이전트의 선택이다.
WebMCP는 완성된 W3C 표준인가?
아니다. 커뮤니티 그룹 드래프트(CG-DRAFT)이고, W3C 표준도 표준 트랙도 아니다. Microsoft·Google 엔지니어가 개발하며 Anthropic의 MCP와 정렬돼 있다.
모든 브라우저에서 되나?
아직 아니다. Chrome 146에서 플래그 뒤로 들어왔고 Google I/O 2026(2026년 5월 19일) 기준 Chrome 149 origin trial에 들어간다. Safari·Firefox는 입장이 없고, 폭넓은 지원은 빨라야 2027년 말이다. 그동안 다른 브라우저는 폴리필로 메운다.
JSON-RPC를 쓰나?
스펙은 에이전트가 받는 형식을 규정하지 않는다. 도구 입력은 JSON Schema로 기술하고, 브라우저가 도구를 에이전트에 노출하는 방식은 구현에 맡긴다.
WebMCP가 내 구조화 데이터(JSON-LD)를 대체하나?
아니다. 둘은 다른 깔때기다. 정적 구조화 콘텐츠는 인용을, WebMCP 도구는 행동을 두고 겨룬다. 둘 다 유지하라.
지금 사이트를 이걸 중심으로 다시 지어야 하나?
아직 아니다. 시험해볼 가치는 있지만 진화 중인 드래프트다. 작업에 날짜를 박고, 현재 API에 로드맵을 걸지 마라.
출처
- W3C Web Machine Learning 커뮤니티 그룹 — WebMCP 드래프트(CG-DRAFT): https://webmachinelearning.github.io/webmcp/
- Chrome for Developers — WebMCP(Chrome 149 origin trial): https://developer.chrome.com/docs/ai/webmcp
- WebMCP 이슈 트래커(보안 논의): https://github.com/webmachinelearning/webmcp/issues
업데이트 기록
- 2026-05-21 — 초기 게시. W3C Web Machine Learning 커뮤니티 그룹 WebMCP 드래프트(CG-DRAFT, 2026년 5월 19일)와 Chrome for Developers origin trial 문서(Chrome 149, Google I/O 2026) 기반. WebMCP는 진화 중인 드래프트다. 선언형 HTML API는 아직 미규정이고 명령형 API도 바뀔 수 있다. 구현 전 스펙 재확인 필요.
공개 명세와 문서를 2026년 5월 기준으로 분석. WebMCP는 완성 표준이 아니라 커뮤니티 그룹 드래프트다. 의존하기 전에 W3C 드래프트와 브라우저 origin trial 상태를 직접 확인할 것.