WebMCP와 인용의 역설, 에이전트 레디 웹이 GEO에 의미하는 것

💡 요약 / TL;DR - WebMCP와 인용의 역설 핵심 요약 (BLUF)

• 기능과 한계: Chrome 149 origin trial로 도입된 WebMCP는 에이전트의 직접 호출을 지원하지만, 사용자 대상 인용 노출을 규범적으로 강제하지 않습니다.
• 비즈니스 전환: 가치가 ‘행동’인 트랜잭션 사이트에는 기회이나, ‘클릭’인 퍼블리셔에는 제로 클릭 위험을 높입니다.
• 하이브리드 전략: 정적 인용 레이어(비교표, JSON-LD)와 동작 중심의 도구 레이어를 병행 운영하는 것이 안전합니다.

“The User Agent MAY present tools to the model using Model Context Protocol (MCP), a proprietary function calling representation, or any other format.” — W3C Web Machine Learning CG Draft, Section 3.1

Chrome 149(Google I/O 2026)에서 origin trial로 개시된 WebMCP는 AI 에이전트의 직접적 도구 호출을 지원하나, 자연 검색 트래픽의 50% 급감 및 최상위 링크 CTR 34.5% 폭락이라는 제로 클릭(Zero-click) 인용 구조의 잠재적 위험을 증폭시킵니다. 특히 W3C 드래프트는 일반적 통념과 달리 에이전트 답변 시 출처 URL 인용 노출을 규범적으로 강제하지 않습니다. 본 WebMCP 분석 가이드는 Chrome for Developers WebMCP 공식 문서 등 1차 명세서 원본을 기반으로 기술 구조와 인용 메커니즘의 진실을 규명합니다.

이 글은 2차 설명글이 아니라 1차 출처를 직접 읽고 정리했습니다. W3C Web Machine Learning Community Group WebMCP 공식 초안과 Chrome 공식 origin trial 문서입니다. 통념과 스펙이 어긋나는 지점은 그대로 적었습니다. 수치와 스펙 디테일은 2026년 5월 기준이고, WebMCP는 완성 표준이 아니라 커뮤니티 그룹 드래프트라 세부는 바뀝니다.

왜 2026년 최신 W3C 초안에 근거한 기술 분석이 중요할까요?

WebMCP를 검색하면 글은 두 종류입니다. “이게 뭐냐” 설명글, 그리고 “이걸 깔면 에이전트가 네 사이트를 고른다"는 마케팅. 스펙이 규범으로 정의한 것과 벤더가 바라는 것을 갈라 보는 글은 거의 없습니다. 지금 도는 핵심 주장 몇 개 — 출처 인용을 강제한다, JSON-RPC로 말한다, “리소스"를 등록한다는 주장은 현재 드래프트에 없습니다. 이걸 전제로 콘텐츠·GEO 전략을 짜면 아직 존재하지 않는 토대 위에 짓게 됩니다.

Chrome 149 Origin Trial(Google I/O 2026)의 실무적 적용 규격은?

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 패키지)을 씁니다.

W3C 명세서가 규정한 WebMCP의 실제 Javascript API 구동 방식은?

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는 상인에겐 도움이 되면서 퍼블리셔에겐 제로클릭 문제를 키울 수 있습니다.

프레임은 단순합니다. 내 가치가 행동이면 기회, 인용 클릭이면 위험입니다.

WebMCP를 둘러싼 시장의 3대 거짓 과장과 명세서 대조

WebMCP가 헛것이라는 말이 아닙니다. 핵심 GEO 주장인 인용 보장이 사실이 아니라는 것이고, 전략을 거기에 기대면 안 된다는 것입니다.

WebMCP 연동이 실제 에이전트 노출 랭킹과 검색 유입에 끼치는 영향 3가지

진짜 변화는 세 가지인데, 어느 것도 자동 트래픽은 아닙니다.

도구 description이 새로운 랭킹 지점이 됩니다. 에이전트는 등록된 도구 중 무엇을 호출할지 name과 description을 보고 고릅니다. 그 문자열이 검색 스니펫에서 meta description이 하던 역할을 에이전트 선택에서 합니다. 잘 쓰는 건 그 자체로 하나의 기술입니다. 범위는 분명하게, 입력은 정직하게, 결과는 에이전트가 행동할 수 있게 씁니다.

오리진은 모델에 닿지만, 인용이 아니라 신뢰 신호입니다. 브라우저가 안전 판단용으로 오리진을 에이전트에 넘기므로, 신뢰할 만하고 일관된 오리진이 모델이 내 도구를 호출하고 믿을지를 좌우합니다. 이건 평판이지 레퍼럴 링크가 아닙니다.

상태와 단일 탭은 세션을 만들지, 방문을 보장하진 않습니다. 도구는 탭이 열려 있는 동안만 작동하고, 페이지 상태에 따라 나타나거나 사라집니다. 진짜 쓸모 있는 대시보드 도구는 탭을 살려두게 만듭니다. 그건 실질적인 사용자 관여지만, 사용자가 탭을 열어두게 강제할 수는 없고, 인용 클릭과 같지 않습니다.

WebMCP 등록 시 사이트가 겪게 될 주요 취약성과 설계 리스크는?

WebMCP는 브라우저의 오리진·HTTPS 보호를 물려받지만, 드래프트의 보안·프라이버시 섹션은 아직 비어 있고, 도구를 노출하려는 쪽이 신경 써야 할 미해결 이슈가 있습니다. 같은 페이지에 끼어든 제1자·제3자 스크립트가 등록된 도구를 덮어쓰고 에이전트 호출을 조용히 가로챌 수 있습니다. prompt injection과 도구 체이닝을 통한 데이터 유출도 인지됐을 뿐 해결되지 않았습니다. 도구 노출은 사이트에 새 공개 API 창구를 여는 일로 다루고, 파괴적 동작은 자동 실행하지 말고 확인 단계 뒤에 두시기 바랍니다.

인용 유도 클릭(GEO)과 동작 수행(WebMCP)을 조화시키는 하이브리드 전략이란?

실용적인 선택은 GEO 셋업을 WebMCP로 갈아치우는 게 아닙니다. 두 레이어를 같이 굴리는 것입니다. 정적이고 인용 가능한 콘텐츠(깔끔한 본문, 비교표, JSON-LD 구조화 데이터)는 그대로 둡니다. 그게 AI 답변에 인용되고 검색에 색인되며, 인용 클릭이 나오는 곳이 여전히 거기이기 때문입니다. 그 위에 에이전트가 직접 할 수 있어야 하는 동작을 WebMCP 도구로 얹습니다. 정적 레이어는 인용을, 도구 레이어는 행동을 두고 겨룹니다. 둘은 서로 다른 깔때기이고, 대부분의 사이트는 둘 다 필요합니다.

W3C 표준 드래프트를 따르는 최소 사양의 WebMCP Javascript 소스코드 예시

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 도입 의사결정 매트릭스

FAQ: WebMCP와 관련된 자주 묻는 질문

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 상태를 직접 확인하시기 바랍니다.

Last verified: May 2026