WebMCP란 무엇인가 — 왜 갑자기 화제인가

2026년 2월 10일, 구글과 마이크로소프트의 엔지니어들이 공동 개발한 새로운 웹 표준이 W3C Draft Community Group Report로 공개됐습니다. 이름은 WebMCP(Web Model Context Protocol)입니다. 그리고 3월 11일 구글 크롬 공식 블로그에서 정식 활용 가이드가 발표되면서 글로벌 개발자 커뮤니티가 들썩이기 시작했습니다. (출처: Chrome for Developers 공식 블로그, 2026.03.11)

지금까지 AI 에이전트가 웹을 탐색하는 방식은 사람과 똑같았습니다. 화면을 스크린샷으로 찍고, 어디에 버튼이 있는지 시각적으로 추론하고, 마우스 좌표를 계산해서 클릭하는 방식입니다. Playwright나 Puppeteer 같은 브라우저 자동화 도구가 바로 이 방식을 씁니다. 문제는 웹사이트 디자인이 조금만 바뀌어도 자동화 파이프라인 전체가 깨진다는 점입니다. AI가 ‘보고 추측’하는 방식이기 때문에 구조적으로 불안정합니다.

WebMCP는 이 구조 자체를 뒤집습니다. 웹사이트가 먼저 AI 에이전트에게 “나한테는 이런 기능들이 있어”라고 구조화된 형태로 알려주는 방식입니다. AI가 화면을 해석할 필요가 없어지고, 웹사이트가 자신의 기능을 ‘도구(Tool)’로 직접 노출합니다. Chrome 146 버전에서 이미 실험 플래그를 통해 테스트할 수 있으며, 이것이 2026년 AI 에이전트 개발의 판도를 바꿀 가장 조용하면서도 강력한 변화입니다.

▲ 목차로 돌아가기

MCP와 WebMCP는 무엇이 다른가 — 헷갈리면 구조가 무너진다

가장 많이 묻는 질문이자 가장 많이 오해하는 부분이 바로 이것입니다. “WebMCP가 나왔으니 MCP는 이제 필요 없는 거 아닌가?” 구글 크롬팀은 이 질문을 공식 블로그에서 정면으로 다루며 명확하게 답했습니다. “WebMCP는 MCP의 확장 프로그램이나 대체 프로그램이 아닙니다. 둘은 서로 다른 요구사항을 해결합니다.” (출처: Chrome for Developers, 2026.03.11)

차이를 이해하려면 UI 소유권 개념이 핵심입니다. MCP에서는 에이전트의 UI 안에서 외부 서비스의 인터페이스가 렌더링됩니다. 에이전트가 주인이고 외부 서비스는 손님입니다. WebMCP는 정반대입니다. 에이전트가 웹사이트에 방문자로 들어갑니다. 웹사이트가 주인이고 에이전트가 손님입니다. 그래서 에이전트는 웹사이트의 라이브 세션, 쿠키, DOM 요소에 접근할 수 있지만 탭을 닫으면 접근 권한도 사라집니다.

기술적으로도 분명히 다릅니다. MCP는 JSON-RPC 2.0 기반으로 AI 에이전트와 백엔드 서비스를 연결하며 Python·TypeScript·Rust SDK를 지원합니다. WebMCP는 브라우저의 postMessage를 통해 웹페이지와 에이전트가 소통하는 구조로, MCP의 리소스(resources) 같은 서버 측 개념을 의도적으로 빼고 설계됐습니다. 이를 두 기술을 혼동하면 “MCP 서버를 잘 구축했으니 WebMCP는 자동으로 되겠지”라는 착각으로 이어지고, 브라우저 에이전트 연동 구조 전체를 처음부터 다시 설계해야 하는 상황을 맞게 됩니다.

출처: Chrome for Developers 공식 블로그 (2026.03.11), daleseo.com 교차 분석

▲ 목차로 돌아가기

Chrome 146에서 직접 켜는 법 — 선언적·명령적 API 실제 코드

WebMCP는 현재 Chrome 146 버전의 실험 플래그 뒤에서 활성화됩니다. 주소창에 chrome://flags를 입력한 뒤 “WebMCP for testing”을 검색해 Enable로 설정하고 브라우저를 재시작하면 됩니다. (출처: Chrome for Developers, 2026.03.11)

선언적 API — HTML 폼 3개 속성만 추가하면 끝

이미 운영 중인 HTML 폼이 있다면 속성 3개(toolname, tooldescription, toolparamdescription)만 추가하면 WebMCP 지원 도구로 전환됩니다. 자바스크립트 수정 없이도 브라우저가 폼 필드를 자동으로 JSON Schema로 변환해 에이전트에게 전달합니다. 이것이 “기존 웹사이트라도 최소 작업으로 AI 에이전트를 지원할 수 있다”는 구글의 주장이 근거로 삼는 핵심 메커니즘입니다.

<!-- 선언적 API: 기존 폼에 속성 3개 추가 -->
<form
action="/search"
method="GET"
toolname="search_products"
tooldescription="키워드, 카테고리, 가격으로 상품을 검색합니다"
>
<input
name="query"
type="text"
required
toolparamdescription="상품명이나 설명에 대한 검색 키워드"
/>
<select name="category"
toolparamdescription="검색 결과를 필터링할 카테고리">
<option value="all">전체</option>
<option value="electronics">전자제품</option>
</select>
<button type="submit">검색</button>
</form>

명령적 API — navigator.modelContext로 동적 도구 등록

SPA(싱글 페이지 앱)나 페이지 이동 없이 처리하는 로직에는 JavaScript 기반의 명령적 API를 사용합니다. navigator.modelContext.registerTool()로 도구를 등록하면 에이전트가 해당 함수를 직접 호출할 수 있습니다. 도구 구조는 기존 MCP 도구와 동일한 형태(name, description, inputSchema)를 따르기 때문에, MCP 개발 경험이 있다면 학습 비용이 거의 없습니다.

// 명령적 API: navigator.modelContext 사용
navigator.modelContext.registerTool({
name: "addToCart",
description: "상품을 장바구니에 추가합니다",
inputSchema: {
type: "object",
properties: {
product_id: {
type: "string",
description: "추가할 상품의 ID",
},
quantity: {
type: "number",
description: "수량 (기본값: 1)",
},
},
required: ["product_id"],
},
execute: ({ product_id, quantity = 1 }) => {
cart.add(product_id, quantity);
return {
content: [
{ type: "text", text: `${product_id} ${quantity}개를 장바구니에 담았습니다` },
],
};
},
});

페이지 전환 시 도구셋을 교체하려면 provideContext()를 쓰면 됩니다. 전체 제거는 clearContext()입니다. SPA에서 라우트가 바뀔 때 해당 페이지에 맞는 도구만 노출하는 패턴을 권장합니다.

▲ 목차로 돌아가기

98% 정확도의 이면 — 성능 수치가 숨긴 3가지 보안 함정

연산 오버헤드 67% 감소, 작업 정확도 98%. 이 숫자는 기존 시각 기반 스크래핑 방식과의 비교 수치입니다. (출처: blog.kwt.co.kr WebMCP 비교 분석, 2026.02.14) 이것이 의미하는 바는 단순합니다. 에이전트가 이미지를 처리하고 LLM으로 추론하는 연산 단계가 사라졌기 때문에 컴퓨팅 비용이 줄고 정확도가 올라간 것입니다. 그러나 이 인상적인 수치가 오히려 보안 취약점을 감추는 효과를 냅니다. 구글 공식 블로그조차 “아직 풀어야 할 숙제가 있다”고 인정한 3가지 보안 문제가 있습니다.

▲ 목차로 돌아가기

웹 개발자가 지금 당장 알아야 할 전략 전환점

VentureBeat는 WebMCP를 “Schema.org 이후 가장 중요한 웹 표준 모멘트”라고 평가했습니다. Schema.org가 검색 엔진에게 콘텐츠의 의미를 알려줬다면, WebMCP는 AI 에이전트에게 웹사이트의 기능을 알려주는 역할을 합니다. Schema.org 도입 초기에 빠르게 적용한 사이트들이 구글 리치 스니펫 혜택을 누렸던 것처럼, WebMCP를 먼저 도입한 사이트가 AI 에이전트 트래픽을 선점할 가능성이 높습니다.

그러나 단순히 “빨리 도입하면 유리하다”는 논리가 모든 상황에 적용되지는 않습니다. 구글 크롬팀의 공식 가이드라인은 두 가지 상황을 명확히 구분합니다. 첫째, 에이전트가 사이트를 ‘방문 중’일 때 즉각적인 상호작용이 필요한 경우는 WebMCP가 적합합니다. 둘째, 사용자가 사이트를 열지 않은 상태에서 백그라운드 작업을 처리해야 하는 경우는 MCP 서버가 필요합니다. 최고 효율을 위해서는 두 기술을 조합하는 설계가 권장됩니다. (출처: Chrome for Developers, 2026.03.11)

이미 화면 스크래핑을 적극적으로 차단하던 사이트들은 전략을 재검토할 시점입니다. 기존에는 스크래핑 자체를 막는 것이 목표였지만, WebMCP 시대에는 “어떤 기능을 에이전트에게 허용하고 어떤 기능을 차단할 것인가”를 명시적으로 설계해야 합니다. WebMCP를 도입하지 않아도 기존 스크래핑 방어는 여전히 유효합니다. WebMCP는 강제 표준이 아닌 선택적 도입이기 때문입니다. 하지만 대형 e-커머스나 여행 예약 플랫폼 등 AI 에이전트 트래픽이 집중될 서비스라면 2026년 하반기 전에 WebMCP 지원 여부를 검토하는 것이 전략적으로 맞습니다.

▲ 목차로 돌아가기

WebMCP 로드맵 — 2027년까지 무슨 일이 벌어지나

WebMCP의 현재 상태는 W3C Draft Community Group Report 단계입니다. 정식 표준이 되기까지는 수개월에서 최대 수년이 걸릴 수 있습니다. 현재 Firefox, Safari, Edge는 W3C 그룹에는 참여 중이나 자체 구현은 없습니다. Chrome만 Chrome 146 Canary에서 실험 플래그로 제공 중이며, 2026년 하반기 Google I/O 또는 Google Cloud Next에서 더 넓은 지원 범위가 발표될 가능성이 높습니다. (출처: daleseo.com 공식 스펙 분석, 2026.03.11)

2026년 중 가장 핵심적인 변화는 도구 발견 메커니즘의 도입입니다. 현재 WebMCP 도구는 사용자가 해당 사이트를 실제로 방문해야만 에이전트가 발견할 수 있습니다. 이 문제를 해결하기 위해 .well-known/webmcp 경로에 JSON 매니페스트를 두는 방식이 논의 중입니다. 사이트맵이 검색 엔진에게 페이지 목록을 알려주듯, 이 매니페스트가 AI 에이전트에게 도구 목록을 사전에 알려주는 역할을 하게 됩니다. 이것이 도입되는 순간 WebMCP 기반 사이트의 경쟁 구도가 SEO와 유사한 형태로 재편됩니다.

W3C v2.0 로드맵(2027년 후반 목표)에는 스트리밍 도구 응답, 도구 조합(composition), 버전 관리된 도구 정의, 그리고 DHT(분산 해시 테이블) 기반 탈중앙 도구 레지스트리가 포함되어 있습니다. PWA와의 연동도 검토 중으로, 앱이 꺼져 있어도 도구 호출 시 시스템이 자동으로 PWA를 실행하는 기능이 추가될 예정입니다. Schema.org가 검색 생태계를 바꿨듯 WebMCP가 AI 에이전트 생태계를 바꾸는 기반이 될지, 앞으로 12개월이 그 분기점이 될 것입니다.

▲ 목차로 돌아가기

Q&A — 자주 묻는 질문 5가지

▲ 목차로 돌아가기

마치며

WebMCP가 등장하기 전까지 AI 에이전트는 웹을 ‘보는’ 존재였습니다. 화면을 찍고 추론하고 클릭하는 방식으로 웹을 탐색했습니다. WebMCP는 에이전트가 웹을 ‘이해하는’ 방식으로의 전환을 시작합니다. 웹사이트가 자신의 기능을 AI에게 직접 설명하는 구조, 이것은 단순한 API 추가가 아니라 웹의 역할이 재정의되는 변화입니다.

개인적으로 가장 주목하는 포인트는 도구 발견 메커니즘의 도입입니다. .well-known/webmcp 매니페스트가 도입되는 순간, 웹사이트들은 또 한 번 새로운 최적화 경쟁을 시작하게 됩니다. SEO가 검색 엔진을 위한 최적화였다면, 이제 AEO(AI 엔진 최적화)를 넘어 “AI 에이전트를 위한 기능 설계”라는 새로운 개발 원칙이 자리 잡을 것입니다. 지금은 Chrome Canary의 실험 플래그 뒤에 숨겨진 기술이지만, 2026년 하반기를 지나면서 빠르게 현실이 될 변화입니다. 웹 개발자라면 지금 바로 Chrome 146 Canary를 켜고 직접 확인해보는 것을 권합니다.

▲ 목차로 돌아가기

📌 본 포스팅 참고 자료

1. WebMCP 및 MCP 사용 시기 — Chrome for Developers 공식 블로그 (2026.03.11)
2. WebMCP를 사전 체험판으로 이용할 수 있습니다 — Chrome for Developers (2026.02.10)
3. WebMCP, 웹브라우저 AI 에이전트의 판을 바꾸는 핵심 쟁점 3가지 — blog.kwt.co.kr (2026.02.14)
4. WebMCP: 웹사이트를 AI 에이전트에게 열어주는 브라우저 표준 — daleseo.com (2026.03.11)
5. Risks in turning AI chatbots into AI agents and using MCP — Privacy International