WebMCP, 공식 문서 5가지로 직접 따져봤습니다

구글이 조용히 내놓은 것처럼 보이지만, 실제로는 Microsoft와 W3C에서 공동 개발한 표준입니다. 그리고 출시 한 달도 안 돼 실제 보안 취약점(CVE)이 등록됐습니다. 공식 문서를 직접 읽고 정리했습니다.

WebMCP가 생겨난 이유 — 지금 에이전트는 웹을 너무 비싸게 읽습니다

AI 에이전트가 웹사이트 하나를 방문하면 무슨 일이 벌어지는지 잠깐 생각해보면, 꽤 기이합니다. 에이전트는 사람이 보는 것과 똑같은 HTML 페이지를 받아서 거기서 “검색 버튼이 어디 있지?”를 추론합니다. 화면 캡처를 찍고 멀티모달 모델에 던지거나, DOM 전체를 파싱하면서 필요 없는 스크립트·CSS·광고 코드까지 토큰으로 소비합니다.

VentureBeat 분석(2026.02.12)에 따르면, 간단한 상품 검색 하나를 에이전트가 스크린샷 방식으로 처리하면 수천 토큰이 소비됩니다. (출처: VentureBeat, 2026.02.12) 에이전트가 같은 작업을 하루에 수만 번 반복하면 비용이 기하급수적으로 불어납니다.

WebMCP는 이 문제를 다르게 접근합니다. 에이전트가 사람 흉내를 내는 게 아니라, 웹사이트가 에이전트를 위한 별도 인터페이스를 직접 제공하는 방식입니다. `navigator.modelContext`라는 새 브라우저 API를 통해, 사이트가 “나는 이런 기능을 제공합니다, 파라미터는 이렇습니다”를 구조화된 형태로 에이전트에게 알려줍니다.

▲ 목차로 돌아가기

구글 단독 표준이 아닙니다 — MS와 W3C가 함께 만들었습니다

많은 분들이 WebMCP를 “구글이 만든 것”으로 인식하고 있는데, 공식 문서를 읽으면 전혀 다른 그림이 나옵니다. Microsoft Edge 팀의 Patrick Brosset이 자신의 블로그(2026.02.23)에서 직접 적은 내용이 있습니다.

Google이 크롬에 먼저 탑재했으니 구글 제품처럼 보이지만, 실제 스펙 초안 작업은 W3C 웹 머신러닝 워킹그룹에서 구글·MS 엔지니어들이 공동으로 진행했습니다. Edge의 WebMCP 지원이 “가능성이 높다”는 정도가 아니라 사실상 예정된 수순인 이유가 바로 여기 있습니다.

이 구조가 중요한 이유는 한 가지입니다. WebMCP가 크롬 전용 기능으로 영구히 남을 가능성이 낮다는 뜻이기 때문입니다. 과거에 구글이 단독으로 밀어붙인 AMP나 FLoC 같은 제안들은 업계 반발과 함께 흐지부지됐지만, WebMCP는 처음부터 경쟁사(MS)를 공동 저자로 앉혔습니다. 표준화 궤도에 오를 가능성이 그만큼 높습니다.

▲ 목차로 돌아가기

두 가지 API, 어떻게 다른지 직접 확인했습니다

Declarative API — HTML 속성 2개로 끝납니다

이미 HTML 폼이 있는 사이트라면 `toolname`과 `tooldescription` 두 속성만 추가하면 됩니다. (출처: Chrome Developers Blog, 2026.02.10) 브라우저가 폼 필드 이름·타입·유효성 검사 규칙을 읽어 자동으로 툴 스키마를 생성합니다. 자바스크립트 한 줄 없이 에이전트 친화적 인터페이스가 만들어집니다.

<form toolname="searchFlights"
tooldescription="항공편을 출발지·목적지·날짜로 검색합니다">
<input name="origin" type="text" required />
<input name="destination" type="text" required />
<input name="date" type="date" required />
<button type="submit">검색</button>
</form>

기본 동작은 에이전트가 폼을 채운 뒤 사용자가 직접 제출 버튼을 누르도록 대기합니다. 자동 제출을 허용하려면 `toolautosubmit=”true”`를 추가하면 되지만, 아래 보안 섹션에서 다루듯 이 선택은 신중해야 합니다.

Imperative API — 복잡한 동작은 JS로 직접 등록합니다

다단계 워크플로우나 상태 관리가 필요한 경우 `navigator.modelContext.registerTool()`을 씁니다. JSON 스키마로 파라미터를 정의하고, execute 콜백에 기존 비즈니스 로직을 그대로 넣으면 됩니다. 새 API를 배우는 게 아니라 이미 있는 JS 함수를 에이전트에게 노출하는 개념입니다.

※ 두 API는 같은 페이지에 동시 사용 가능합니다. (Chrome Developers Blog, 2026.02.10)

▲ 목차로 돌아가기

출시 1달 만에 CVE 취약점이 나왔습니다

WebMCP 조기 출시 소식에 흥분하기 전에 확인해야 할 사실이 있습니다. Chrome 개발자 블로그 발표(2026.02.10) 이후 약 한 달 만인 2026년 3월 11일, WebMCP 컴포넌트에서 Use-After-Free 취약점이 공식 CVE로 등록됐습니다.

Use-After-Free는 메모리가 해제된 뒤에도 해당 메모리에 계속 접근하는 오류입니다. 공격자가 악성 페이지를 만들어 피해자가 방문하도록 유도하면, WebMCP 컴포넌트가 이 페이지를 처리하는 과정에서 힙 메모리 오염이 발생하고, 최악의 경우 크롬 렌더러 프로세스 내에서 임의 코드가 실행될 수 있습니다.

이 취약점이 의미하는 바는 명확합니다 — WebMCP는 아직 프로덕션에 투입할 수 있는 기술이 아닙니다. 현재 Chrome 버전을 확인하고, 146.0.7680.71 이상인지 먼저 점검해야 합니다.

# 크롬 버전 확인 (터미널)
google-chrome --version
# 146.0.7680.71 이상이어야 CVE-2026-3918 패치 적용됨
# 주소창에서 확인
chrome://settings/help

▲ 목차로 돌아가기

MCP와 무엇이 다른가 — 백엔드 vs 프론트엔드 에이전트 레이어

WebMCP라는 이름 때문에 Anthropic의 MCP(Model Context Protocol)를 대체하거나 확장한 것으로 오해하는 경우가 많습니다. 크롬 개발자 블로그(2026.03.11)에서 이 관계를 직접 정리했습니다 — MCP와 WebMCP는 대체 관계가 아니라 서로 다른 레이어를 담당합니다.

WebMCP의 결정적인 특징은 브라우저가 MCP의 데이터 레이어·전송 레이어를 대신 처리해준다는 점입니다. 개발자는 그냥 JavaScript 함수를 하나 등록하면 됩니다. 뒤에서 브라우저가 MCP 형식으로 변환해 에이전트와 통신합니다. (출처: patrickbrosset.com, 2026.02.23) 백엔드 MCP 서버를 별도로 세울 필요가 없다는 뜻이고, 기존 JS 로직을 재활용할 수 있습니다.

예를 들어 여행 플랫폼은 ChatGPT·Claude 같은 AI 클라이언트와 직접 연동하는 백엔드 MCP 서버를 유지하면서, 동시에 웹사이트 예약 플로우에는 WebMCP를 붙여두는 식으로 두 가지를 병행할 수 있습니다. 서로 충돌하지 않습니다.

▲ 목차로 돌아가기

SEO 역사가 그대로 반복되고 있습니다

1990년대 중반, 검색엔진 크롤러가 등장했을 때 웹사이트들은 사람을 위해 만들어진 HTML 페이지를 크롤러가 읽도록 그냥 내버려뒀습니다. 결과는 엉망이었습니다. 그래서 robots.txt, 사이트맵, 구조화 데이터, 메타태그가 생겼습니다. 기계용 신호를 별도로 제공하기 시작했고, 그것이 SEO라는 분야가 됐습니다.

WebMCP 스펙 문서에도 비슷한 맥락이 담겨 있습니다 — 현재 에이전트는 어떤 사이트에 툴이 있는지 방문하기 전에는 알 수가 없습니다. 스펙은 이를 해결하기 위해 `.well-known/webmcp` 같은 매니페스트 기반 탐색 레이어를 제안하고 있지만, 아직 구체적인 스펙은 없습니다. (출처: ivanturkovic.com, 2026.02.15)

이 탐색 레이어가 생기는 순간 새 패러다임이 열립니다. 툴 이름·설명·파라미터 설계가 검색 메타 디스크립션처럼 작동하게 됩니다. 에이전트가 “항공편 검색”을 처리할 때 A 사이트 툴을 선택할지 B 사이트 툴을 선택할지는 툴 설명 품질에 달리게 됩니다. 일부에서는 이를 “에이전트 CRO(Conversion Rate Optimization)”라고 부르기 시작했습니다.

솔직히 말하면, 아직 그 날이 언제 올지는 모릅니다. 탐색 레이어 스펙조차 나오지 않았고, 크롬 외 브라우저 지원 일정도 공개되지 않았습니다. 하지만 구조 자체는 너무 선명합니다. SEO를 늦게 시작한 사이트들이 치렀던 비용을 기억한다면, 이 흐름을 그냥 흘려보내기는 어렵습니다.

▲ 목차로 돌아가기

Q&A — 5가지 실전 질문

▲ 목차로 돌아가기

마치며

WebMCP를 공식 문서 다섯 곳에서 직접 읽어보고 정리하면서 느낀 점은, 기술 자체보다 타이밍이 흥미롭다는 겁니다. 발표(2026.02.10)에서 CVE 등록(2026.03.11)까지 딱 한 달. Canary 플래그 뒤에 숨겨진 기능인데도 취약점이 나왔습니다. 실험적 기술이 얼마나 빠르게 실제 공격 표면이 되는지를 보여주는 사례입니다.

그러면서도 방향 자체는 선명합니다. 에이전트가 웹을 소비하는 방식이 바뀌고 있고, WebMCP는 그 변화에 표준 경로를 만들려는 시도입니다. 구글 단독이 아니라 MS와 W3C가 함께 만들고 있다는 점이 이 표준의 생존 가능성을 높여줍니다.

지금 당장 코드를 바꿀 필요는 없습니다. 하지만 Chrome EPP에 참여해서 흐름을 따라가고, 기존 폼을 시맨틱하게 정리해두는 정도는 지금 해도 손해가 없습니다. 탐색 레이어 스펙이 나오는 시점에 그 준비가 얼마나 빨리 효과를 낼지를 결정할 겁니다.

본 포스팅 참고 자료

1. Chrome Developers Blog — WebMCP vs MCP 비교 (2026.03.11)
2. Chrome Developers Blog — WebMCP 조기 출시 프로그램 공지 (2026.02.10)
3. Patrick Brosset (MS Edge팀) — WebMCP 업데이트·정정·다음 단계 (2026.02.23)
4. SentinelOne — CVE-2026-3918 취약점 상세 (2026.03.11)
5. Ivan Turkovic — WebMCP가 웹을 바꾸는 방법 (2026.02.15)
6. VentureBeat — Chrome WebMCP 조기 출시 분석 (2026.02.12)