WebMCP, MCP 대신 쓰면 된다는 말이 절반만 맞습니다

구글이 Chrome 146에 WebMCP를 올렸습니다. “이제 백엔드 MCP 서버 없어도 된다”는 말이 빠르게 퍼졌는데, 공식 스펙을 직접 보면 얘기가 다릅니다. MCP를 대체하는 게 아니고, 작동하는 레이어 자체가 다릅니다. 그리고 지금 당장 쓰면 안 되는 이유가 W3C 스펙 문서에 그대로 나와 있습니다.

WebMCP가 뭔지, 한 줄로 정리하면

결론부터 말씀드리면, WebMCP는 “웹 페이지가 AI 에이전트에게 직접 자신의 기능 목록을 건네주는 브라우저 API”입니다. 지금까지 AI 에이전트가 웹사이트를 이용하는 방식은 크게 두 가지였습니다. 화면을 스크린샷으로 읽거나 DOM을 파싱해서 버튼 위치를 추정하는 자동화 방식, 그리고 별도의 백엔드 API를 호출하는 방식입니다. 전자는 CSS 클래스 이름 하나 바뀌면 바로 깨지고, 후자는 공개 API가 없는 사이트에서는 아예 쓸 수 없습니다.

WebMCP는 이 둘의 중간을 노립니다. 웹 개발자가 navigator.modelContext.registerTool()로 “내 사이트에서 AI가 할 수 있는 일”을 등록하면, 브라우저가 그 정보를 에이전트에게 전달합니다. AI는 DOM을 읽는 대신 JSON Schema 기반의 함수를 직접 호출합니다. 구글 Chrome 공식 블로그가 2026년 2월 10일 공개한 Early Preview 발표문에는 “AI 에이전트가 더 빠른 속도, 안정성, 정확성으로 작업을 실행할 수 있도록 지원”한다고 나와 있습니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10)

핵심은 브라우저가 중간에 있다는 점입니다. 페이지가 에이전트와 직접 통신하는 게 아니라, 브라우저가 중재자 역할을 합니다. 이 구조가 나중에 나올 보안 문제와도 직결됩니다.

▲ 목차로 돌아가기

MCP 대체제가 아닌 이유 — 공식 스펙에서 직접 확인

MCP(Model Context Protocol)는 3개 레이어로 구성됩니다. ① 도구·리소스·프롬프트 등을 정의하는 Primitives 레이어, ② MCP 클라이언트와 서버 간 통신 방식을 규정하는 Data 레이어, ③ 메시지 전송 방식인 Transport 레이어입니다. Microsoft Edge 팀 소속으로 WebMCP 스펙을 공동 작성한 Patrick Brosset은 2026년 2월 23일 블로그에 이렇게 명시했습니다. “WebMCP는 이 세 레이어 중 첫 번째만 처리합니다. 나머지 두 레이어는 브라우저가 대신 처리합니다.” (출처: patrickbrosset.com, 2026.02.23)

이게 무슨 의미냐면, WebMCP 도구를 만들 때 개발자는 MCP 프로토콜을 직접 구현할 필요가 없습니다. JSON Schema와 JavaScript 함수만 작성하면 브라우저가 나머지를 처리해줍니다. 편리한 건 맞습니다. 하지만 이 때문에 WebMCP는 MCP로 할 수 있는 영역의 일부만 커버합니다.

Chrome 공식 문서(2026.03.11)는 이 점을 명확히 합니다. “WebMCP는 MCP의 확장도, 대체도 아닙니다. 두 기술은 서로 다른 필요를 해결합니다.” 둘을 같이 쓰는 게 가장 효과적이라는 게 공식 권장 방식입니다. 사용자가 사이트를 열어 있는 동안은 WebMCP로 UI에 즉각 반응하고, 백그라운드에서 지속적으로 처리해야 하는 작업은 MCP 서버가 담당합니다.

▲ 목차로 돌아가기

Chrome 146에서 실제로 되는 것과 안 되는 것

WebMCP를 지금 직접 테스트하려면 Chrome 146.0.7672.0 이상이 필요합니다. chrome://flags/#enable-webmcp-testing에서 “WebMCP for testing” 플래그를 활성화하고 브라우저를 재시작하면 됩니다. 그러면 navigator.modelContext를 콘솔에서 직접 확인할 수 있습니다. (출처: Search Engine Land, 2026.03.04)

실제로 동작하는 부분

registerTool()로 도구를 등록하면 DevTools에서 Model Context Tool Inspector 확장 프로그램으로 확인 가능합니다. Declarative API는 기존 HTML 폼에 toolname, tooldescription 속성 두 개만 추가하면 브라우저가 자동으로 JSON Schema를 생성합니다. 기존 HTML 폼을 거의 손대지 않고 에이전트가 읽을 수 있는 도구로 전환할 수 있다는 건 사실입니다.

또한 도구 실행은 페이지가 이미 로그인된 세션을 그대로 활용합니다. AI 에이전트가 따로 인증 절차를 거칠 필요가 없고, 이미 사용자가 접근 가능한 데이터만 건드릴 수 있습니다. 이 부분은 전통적인 MCP 서버 설정보다 훨씬 가볍습니다.

막상 해보면 다른 부분

React나 Redux 같은 상태 관리 라이브러리에 UI 로직이 묶여 있는 SPA는 작업이 훨씬 복잡합니다. 도구 핸들러가 컴포넌트 내부 상태에 자동으로 접근하지 못합니다. UI와 비즈니스 로직이 분리된 클린 아키텍처가 아니라면 리팩토링 없이 WebMCP 도구를 등록하기가 어렵습니다. bug0.com의 Chrome 146 테스트 기록에도 “tightly coupled SPA는 리팩토링이 먼저”라고 명시되어 있습니다. (출처: bug0.com, 2026.02.11)

그리고 스펙 자체에 “페이지당 50개 이하 도구”를 권장한다는 제약이 있습니다. 에이전트가 도구 목록을 발견하는 과정에서 과부하가 생기지 않도록 설계된 상한입니다. 사이트 전체 기능을 커버하려면 50개 이하로 추려야 한다는 건데, 기능이 많은 SaaS라면 이 숫자가 꽤 빡빡합니다.

▲ 목차로 돌아가기

보안 섹션이 아직 비어 있다는 사실

솔직히 이 부분이 가장 신경 쓰입니다. W3C WebMCP 스펙 초안(2026년 2월 12일 기준)의 보안 섹션은 현재 “TODO”로 마킹되어 있습니다. 이 공백을 메우기 위해 2026년 3월 GitHub Issue #121에 Shrike Security가 5가지 보안 제안을 올렸는데, 이게 제안 단계라는 건 아직 스펙에 반영되지 않았다는 뜻입니다. (출처: webmachinelearning/webmcp GitHub Issue #121, 2026.03)

bug0.com 분석 글이 지적한 “치명적 트리플”이 핵심입니다. AI 에이전트가 이메일을 읽고(개인 데이터 접근) → 그 안의 피싱 메시지를 처리하고(신뢰할 수 없는 콘텐츠 파싱) → 다른 도구를 호출해 데이터를 외부로 전송하는(외부 통신) 세 단계를 연결하면, 각 단계는 정상이지만 전체 흐름이 데이터 유출 경로가 됩니다. 프롬프트 인젝션이 여기에 더해지면 완화책이 있지만 리스크를 완전히 제거하지는 못합니다.

destructiveHint 어노테이션도 마찬가지입니다. 삭제나 결제 같은 파괴적 작업에 이 플래그를 붙일 수 있지만, 어디까지나 권고 사항입니다. 브라우저나 에이전트가 이 힌트를 무시해도 도구 실행이 막히지 않습니다.

Shrike Security의 제안 중에는 도구를 호출하는 에이전트의 신원을 검증하는 방법도 포함되어 있습니다. 에이전트 벤더가 .well-known/agent-identity에 공개키를 게시하고, 브라우저가 서명을 검증해 verified: true/false 값을 돌려주는 방식입니다. 하지만 이것도 아직 커뮤니티 검토 단계입니다.

▲ 목차로 돌아가기

지금 바로 쓰면 안 되는 조건 3가지

Search Engine Land의 WebMCP 분석(2026.03.04)과 bug0.com 가이드(2026.02.11)를 교차해서 정리한 내용입니다. 아래 세 가지 중 하나라도 해당하면 프로덕션 배포는 시기상조입니다.

▲ 목차로 돌아가기

그래도 지금 실험해야 하는 이유

W3C Web Machine Learning Working Group에서 이 스펙을 공동 작성한 저자 목록에는 Google 엔지니어 외에도 Microsoft 소속 Brandon Walderman, Leo Lee, Andrew Nolan이 포함되어 있습니다. (출처: bug0.com, 2026.02.11) 브라우저 벤더 두 곳이 동시에 스펙을 작성한다는 건 결국 출시된다는 뜻입니다. 역사적으로 CSS Grid, Fetch API도 비슷한 경로를 밟았습니다.

벤치마크 수치도 있습니다. bug0.com이 인용한 초기 데이터에 따르면 WebMCP 방식이 기존 에이전트-브라우저 상호작용(DOM 파싱, 스크린샷 분석) 대비 연산 오버헤드를 약 67% 줄이고, 작업 정확도를 약 98% 수준으로 유지하는 것으로 나타났습니다. (출처: bug0.com, 2026.02.11) 단순 벤치마크라 일반화에는 주의가 필요하지만, 방향은 명확합니다. AI가 DOM을 읽지 않아도 되면 오류가 줄어듭니다.

지금 실험해야 하는 실질적 이유는 하나입니다. 스펙이 안정화되는 시점에 이미 “어떤 도구를 어떻게 설계해야 에이전트가 잘 활용하는지”에 대한 노하우를 갖고 있는 팀이 훨씬 유리합니다. Search Engine Land는 이를 2000년대 SEO 초기 타이밍에 비유했습니다. 지금은 “도구 이름을 button_1이 아닌 create_appointment로 지어야 AI가 찾는다”는 수준의 실험을 하는 단계입니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

WebMCP는 분명 방향이 맞습니다. AI 에이전트가 웹을 쓰는 방식이 DOM 스크레이핑에서 구조화된 도구 호출로 넘어가는 흐름은 되돌리기 어렵고, Google과 Microsoft가 함께 W3C에서 밀고 있다는 건 무시하기 어려운 신호입니다.

다만 지금 당장 “MCP 대신 WebMCP 쓰면 끝”이라는 접근은 무리입니다. 보안 스펙이 TODO인 상태이고, API 인터페이스가 버전 사이에 바뀔 수 있으며, Chrome 외 브라우저 지원이 없습니다. 프로덕션 배포가 아닌 프로토타입 수준에서 “어떤 도구 이름이 AI에게 잘 해석되는지”, “SPA 구조에서 WebMCP 도구를 어떻게 깔끔하게 분리할 수 있는지”를 실험해 두는 게 현실적인 활용법입니다.

개인적으로는 MCP와 WebMCP가 경쟁 관계로 보도되는 게 조금 아쉽습니다. 공식 문서가 명확하게 “파트너”라고 표현한 두 기술이 대체제처럼 소비되면, 실제 설계에서 잘못된 선택이 생길 수 있습니다. 백엔드는 MCP, 프런트엔드 UI 상호작용은 WebMCP라는 구조가 결국 가장 자연스럽습니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Chrome for Developers — WebMCP Early Preview 공식 발표 (2026.02.10)
2. Chrome for Developers — When to use WebMCP and MCP (2026.03.11)
3. Patrick Brosset (Microsoft Edge) — WebMCP updates, clarifications, and next steps (2026.02.23)
4. bug0.com — WebMCP just landed in Chrome 146 (2026.02.11)
5. Search Engine Land — WebMCP explained: Inside Chrome 146’s agent-ready web preview (2026.03.04)
6. W3C WebMCP GitHub — Security Considerations Proposal, Issue #121 (2026.03)