WebMCP, AI가 웹을 누비는 방식이 달라졌습니다

구글 크롬 146이 WebMCP 얼리 프리뷰를 공개한 건 2026년 2월 10일입니다. AI 에이전트가 웹을 쓰는 방식을 완전히 뒤집는 표준인데, 한국어로 제대로 정리된 글이 아직 없습니다. MCP랑 헷갈리기 쉽고 “그냥 MCP 웹 버전 아냐?”라고 넘기기 쉬운데, 막상 공식 문서를 뜯어보면 전혀 다른 이야기가 나옵니다.

AI 에이전트가 지금 웹을 쓰는 방식의 한계

지금 AI 에이전트가 웹사이트를 ‘사용’하는 방식을 한마디로 정리하면, 사람인 척 연기입니다. 화면을 스크린샷으로 찍고, 어느 파란 박스가 “제출” 버튼인지 픽셀 단위로 추측하고, DOM을 긁어서 버튼처럼 생긴 걸 찾아 클릭합니다. 비전 모델에 수천 개의 토큰을 쏟아부으면서도 결과는 불안정합니다.

Imperva의 최신 보고서에 따르면 현재 웹 트래픽의 51%가 이미 봇입니다. (출처: Forbes, 2026.02.19) 그 절반이 화면을 스크린샷 찍으며 돌아다니고 있다는 뜻이니, 지금 웹 인프라가 얼마나 비효율적으로 소모되는지 실감됩니다.

웹사이트 디자인을 한 번 바꾸면 AI 에이전트 워크플로가 통째로 깨집니다. 버튼 위치 하나 바꿨을 뿐인데 에이전트가 멍하니 다른 곳을 클릭하는 일이 실무에서 반복됩니다. WebMCP는 이 문제를 근본부터 다르게 접근합니다.

WebMCP가 해결하는 것 — 두 가지 API

WebMCP(Web Model Context Protocol)는 웹사이트가 구조화된 도구를 브라우저 내 AI 에이전트에 직접 노출하는 제안된 웹 표준입니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10) 핵심은 에이전트가 “버튼을 찾아 클릭”하는 대신 book_flight({ origin, destination, date }) 형태의 명시적 함수를 호출한다는 점입니다. 구현 방식은 두 가지로 나뉩니다.

선언형 API (Declarative API)

기존 HTML 폼에 속성 몇 줄만 추가하면 됩니다. toolname과 tooldescription 속성을 붙이면 브라우저가 알아서 MCP 형식 도구로 변환합니다. 고객지원 티켓 제출, 항공권 검색 폼, 이커머스 체크아웃처럼 정형화된 작업에 적합합니다.

<form toolname="search_flights"
tooldescription="항공편 검색">
<input name="origin" />
<input name="destination" />
<button type="submit">검색</button>
</form>

명령형 API (Imperative API)

동적이거나 복잡한 상호작용은 JavaScript로 도구를 직접 등록합니다. navigator.modelContext.registerTool()로 함수, 입력 스키마, 설명을 등록하면 브라우저가 에이전트와의 통신을 맡습니다. SPA(단일 페이지 앱)에서 사용자 흐름에 따라 도구를 동적으로 활성화·비활성화할 수도 있습니다.

navigator.modelContext.registerTool({
name: "add_to_cart",
description: "장바구니에 상품 추가",
inputSchema: { /* JSON Schema */ },
execute: async (params) => { /* 로직 */ }
});

MCP와 완전히 다른 이유 — 레이어가 다릅니다

가장 많이 오해하는 부분입니다. WebMCP는 MCP를 대체하거나 확장한 게 아닙니다. (출처: Chrome for Developers, 2026.03.11) MCP는 세 개 레이어로 구성됩니다 — 프리미티브(도구·리소스·프롬프트), 데이터 레이어(클라이언트-서버 통신), 전송 레이어(메시지 이동). WebMCP는 이 중 첫 번째 레이어, 즉 프리미티브만 다룹니다. 나머지 두 레이어는 브라우저가 대신 처리합니다.

실제로 MCP는 백엔드 프로토콜입니다. 데스크탑, 모바일, 클라우드 어디서든 외부 시스템에 접근하는 에이전트를 위한 범용 표준이고 JSON-RPC를 쓰며 Rust, Python, TypeScript SDK로 구현됩니다. 반면 WebMCP는 브라우저 탭 안에서만 동작합니다. 탭을 닫으면 도구가 사라집니다. (출처: Chrome for Developers, 2026.03.11) 이걸 공식 용어로 “에페메럴(ephemeral)”, 즉 일시적이라고 표현합니다.

Microsoft Edge 팀의 Patrick Brosset는 이 차이를 명확하게 정리했습니다. “WebMCP는 웹페이지에서 도구를 노출하는 API이며, 브라우저가 그 도구를 에이전트와 통신할 때 MCP 형식으로 번역해 준다.” (출처: patrickbrosset.com, 2026.02.23) 개발자는 MCP를 직접 구현할 필요 없이 JavaScript 함수만 작성하면 됩니다.

Computer Use 대비 67% 감소, 수치로 보면

Forbes의 2026년 2월 19일 보도에 따르면, WebMCP는 시각적 에이전트-브라우저 상호작용 대비 연산 오버헤드를 67% 줄입니다. (출처: Forbes, 2026.02.19) 이게 어디서 나오는지 구체적으로 따져볼 수 있습니다.

Computer Use 방식에서 에이전트가 항공권 하나를 예약하려면 이 흐름을 반복합니다: 페이지 스크린샷 캡처 → 비전 모델에 업로드 → 좌표 추론 → 클릭 실행 → 결과 확인 → 반복. 단계마다 멀티모달 모델 호출이 들어가고 수천 토큰이 소모됩니다. 반면 WebMCP에서는 book_flight({ origin: "ICN", destination: "NRT", date: "2026-04-10" }) 한 번이면 끝입니다. 왕복 통신도 없습니다. 브라우저 내부 시스템이 직접 처리하기 때문입니다.

또 하나 중요한 부분은 인증입니다. Computer Use나 외부 MCP 서버는 사용자 로그인 세션을 따로 처리해야 합니다. WebMCP는 브라우저 탭 안에서 동작하기 때문에 기존 세션·쿠키를 자동으로 상속합니다. 추가 인증 구현 없이 로그인된 사용자 맥락에서 그대로 작동합니다.

지금 당장 쓸 수 없는 조건들

솔직히 말하면, WebMCP는 아직 초기입니다. Chrome 공식 발표(2026.02.10)에 “얼리 프리뷰 프로그램”이라고 명시돼 있고, W3C 스펙의 보안 섹션은 “TODO”로 남아 있습니다. (출처: GitHub webmachinelearning/webmcp, 2026.03.01) 지금 쓸 수 없거나 설계 상 지원하지 않는 조건들이 있습니다.

헤드리스 모드 없음. WebMCP는 브라우저 탭이 열려 있어야 동작합니다. 완전 자율 백그라운드 실행은 설계 목표에 없습니다. 공식 문서에 “headless and fully autonomous scenarios are non-goals”라고 직접 나옵니다. (출처: Forbes, 2026.02.19)

탭 닫으면 도구 사라짐. 도구는 페이지가 열려 있을 때만 존재합니다. 탭을 이동하거나 닫는 순간 에이전트 접근이 끊깁니다.

디스커버빌리티 미해결. 에이전트가 어느 사이트에 WebMCP 도구가 있는지 미리 알 방법이 표준화돼 있지 않습니다. Dev.to 가이드(2026.02.14)에서도 “Discoverability unsolved”를 현재 한계로 명시했습니다.

Chrome에서만 (현재). 구글과 마이크로소프트가 공동으로 W3C 드래프트를 작성 중이라 Edge 지원 가능성이 높지만, 아직 공식 일정이 없습니다. Firefox·Safari 지원은 더 불투명합니다.

보안 쪽은 아직 공백입니다 — W3C 이슈

W3C GitHub에 올라온 보안 제안서(Shrike Security, 2026.03.01)를 보면 현재 스펙에 없는 것들이 꽤 많습니다. 에이전트가 보내는 입력값을 브라우저가 inputSchema 기준으로 검증하는 것조차 현재 스펙에는 강제 조항이 없습니다. 이게 의미하는 건 간단합니다. 도구를 개발한 사람 각자가 검증 로직을 직접 짜야 한다는 뜻이고, 대부분은 안 짭니다.

같은 제안서에서 세 가지 공격자 유형을 정의하고 있습니다. “나쁜 에이전트” — 도구에 프롬프트 인젝션을 숨겨 호출, “나쁜 도구” — 다른 동작을 하도록 설명을 위장한 도구, “나쁜 입력” — 에이전트가 처리하는 콘텐츠 안에 악의적 지시를 숨기는 방식. 이 세 가지 모두 현재 스펙에 방어 메커니즘이 없습니다.

제안된 해결책 중 흥미로운 건 도구 저자가 securityPolicy 필드로 위험 수준을 선언하는 방식입니다. 은행 도구라면 requireConsent: true, dataClassification: "restricted"를 달고, 검색 도구라면 rateLimit: 60만 설정하는 식입니다. 이 부분은 아직 정식 스펙이 아니고 커뮤니티 제안 단계입니다. 이유는 아직 공개되지 않았습니다.

웹 개발자 입장에서 지금 해야 할 것

Forbes는 이를 “structured data 이후 기술 SEO 최대의 전환점”이라고 표현했습니다. (출처: Forbes, 2026.02.19) 좀 과장된 표현이지만, 방향성은 맞습니다. B2AI, 즉 사람이 아닌 AI 에이전트가 사이트를 방문해 트랜잭션을 실행하는 세상이 이미 오고 있고, WebMCP를 먼저 도입한 사이트는 에이전트 트래픽에서 유리한 위치를 점할 수 있습니다.

당장 프로덕션에 적용할 순 없지만, 지금 할 수 있는 건 있습니다. Chrome 146 Canary를 설치하고 chrome://flags에서 “WebMCP for testing”을 켜면 공식 데모(travel-demo.bandarra.me)를 직접 돌려볼 수 있습니다. 얼리 프리뷰 프로그램에 신청하면 공식 문서와 데모에 접근할 수 있습니다.

기존 폼이 있는 사이트라면 선언형 API 도입 비용이 매우 낮습니다. HTML 속성 두 줄만 추가하는 수준입니다. 대신 복잡한 SPA 환경은 명령형 API를 써야 하고, 도구 등록·해제 로직을 앱 상태와 연동해야 합니다. 이 부분은 설계가 필요합니다.

자주 나오는 질문

마치며

WebMCP에서 생각보다 중요한 부분은 “탭이 열려 있는 동안만 동작한다”는 설계 원칙입니다. 이게 제약처럼 보이지만, 실은 사용자가 완전히 통제권을 갖는다는 의미이기도 합니다. 에이전트는 사용자 탭 안의 게스트이고, 탭을 닫으면 에이전트 접근도 끊깁니다. 이 구조는 프라이버시 논쟁이 많은 에이전틱 AI 생태계에서 나름 합리적인 선택입니다.

다만 보안 섹션이 아직 TODO인 채로 얼리 프리뷰가 나온 건 솔직히 아쉽습니다. 오픈뱅킹이 스크린 스크레이핑을 API로 대체했을 때처럼, 전환 과정에서 보안 공백이 생기는 건 역사가 반복하는 패턴입니다. WebMCP가 그 전철을 밟지 않으려면 표준이 확정되기 전에 커뮤니티의 보안 제안들이 충분히 반영돼야 합니다.

구글·마이크로소프트가 공동으로 W3C 드래프트를 작성 중이고 Chrome이 이미 Canary에 탑재한 상태입니다. 빠르게 확산될 가능성이 있는 표준인 만큼, 지금 얼리 프리뷰에서 감을 잡아두는 게 나중에 서두르는 것보다 낫습니다.

📎 본 포스팅 참고 자료

1. WebMCP 얼리 프리뷰 발표 — Chrome for Developers (2026.02.10)
2. WebMCP와 MCP 사용 시기 — Chrome for Developers (2026.03.11)
3. WebMCP 업데이트 및 명확화 — Patrick Brosset, Microsoft Edge (2026.02.23)
4. Google Ships WebMCP — Forbes (2026.02.19)
5. WebMCP Security Considerations — W3C GitHub Issue #121 (2026.03.01)