W3C 커뮤니티 그룹 초안
WebMCP, MCP 대신한다고요? 다릅니다
“WebMCP가 나왔으니 MCP 서버는 이제 구시대?” — 구글 크롬 공식 문서에는 이 질문이 잘못된 전제에서 출발한다고 직접 적혀 있습니다. 결론부터 말하면, 두 기술은 경쟁하지 않습니다. 하지만 WebMCP에 대해 블로그에서 말하지 않는 보안 함정과 지금 당장 프로덕션 배포를 해선 안 되는 이유가 따로 있습니다.
WebMCP가 뭔지, 딱 세 문장으로
WebMCP(Web Model Context Protocol)는 구글과 마이크로소프트 엔지니어들이 함께 만들고 W3C 웹 머신러닝 커뮤니티 그룹에서 초안으로 공개한 브라우저 표준 제안입니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10) 핵심은 웹사이트가 navigator.modelContext라는 새 브라우저 API를 통해 AI 에이전트에게 “우리 사이트에서 할 수 있는 일”을 구조적으로 알려준다는 겁니다. 크롬 146 카나리 채널에서 실험 플래그(chrome://flags → Experimental Web Platform Features)를 켜면 지금 당장 테스트해 볼 수 있습니다.
AI 에이전트가 웹사이트를 다루는 기존 방식에는 두 가지가 있었습니다. 스크린샷을 찍어 비전 모델에 넘기거나, 원시 HTML을 긁어서 버튼이 어디 있는지 추측하는 방식입니다. 둘 다 느리고, 비싸고, 디자인이 조금만 바뀌어도 깨집니다. WebMCP는 이 추측 게임을 없애고 사이트가 직접 “이렇게 하면 됩니다”라고 에이전트에게 계약서를 건네주는 구조입니다.
💡 공식 발표문과 실제 구현 방식을 같이 놓고 보니, 이 기술의 등장이 갖는 의미가 단순히 “새 API 하나 추가”가 아님을 알 수 있었습니다. 아래에서 설명하겠습니다.
MCP는 백엔드, WebMCP는 브라우저 탭 — 둘이 사는 곳이 다릅니다
가장 많이 받는 질문이 “둘 중 뭘 써야 하나요?”입니다. 구글 크롬 공식 문서(2026.03.11 업데이트)는 이 질문 자체가 잘못된 전제에서 출발한다고 명시하고 있습니다. MCP는 플랫폼에 구애받지 않는 백엔드 프로토콜입니다. Python, TypeScript, Rust SDK로 서버를 따로 띄워야 하고, 데이터베이스·API·파일시스템에 접근할 때 씁니다. 항상 켜져 있고, 특정 브라우저 탭이 열려 있지 않아도 동작합니다.
WebMCP가 MCP와 다른 결정적인 점
WebMCP는 탭이 닫히는 순간 사라집니다. 공식 문서 표현을 그대로 옮기면 “ephemeral(일시적)”입니다. 사용자가 사이트에 접속해 있는 동안에만 등록된 도구가 살아있고, 탭을 닫으면 에이전트는 더 이상 그 사이트에 접근하거나 액션을 취할 수 없습니다. (출처: Chrome for Developers, developer.chrome.com/blog/webmcp-mcp-usage, 2026.03.11) 즉, 배경에서 돌아가는 자동화나 스케줄 작업에는 WebMCP가 아예 적합하지 않습니다.
| 항목 | 서버 MCP | WebMCP |
|---|---|---|
| 실행 환경 | 백엔드 서버·데몬 | 브라우저 탭(탭 종료 시 소멸) |
| 인증 | 서비스 자격증명 별도 필요 | 사용자 기존 세션 공유(쿠키 포함) |
| 접근 가능한 것 | DB·API·파일시스템 | DOM·브라우저 API·라이브 세션 |
| 백그라운드 실행 | ✅ 가능 | ❌ 불가 (탭 필수) |
| 배포 방식 | 별도 서버 프로세스·컨테이너 | 페이지 JavaScript에 직접 등록 |
| 지원 브라우저 | 모든 플랫폼 | 크롬 146만 (Firefox·Safari 미지원) |
구글이 두 기술의 관계를 설명할 때 쓴 비유가 인상적이었습니다. MCP는 전국 어디서든 연결 가능한 고객센터 콜센터, WebMCP는 매장 안에서만 도와주는 전문 직원이라는 겁니다. 같은 회사 서비스인데 역할이 다른 것처럼, 둘을 함께 쓸 때 제값을 냅니다.
67%·89%·98% 수치, 이게 진짜 의미하는 것
WebMCP 관련 글마다 등장하는 수치 세 개가 있습니다. 연산 오버헤드 67% 절감, 토큰 사용량 89% 절감, 구조화 툴 정확도 98%. 출처는 Kassebaum Engineering이 집계한 초기 벤치마크(출처: kassebaumengineering.com/insights/webmcp-ai-agents-browser-interaction, 2026.02.14)로, 구글 엔지니어 Khushal Sagar가 인용한 수치를 종합한 것입니다. “초기 벤치마크”이므로 프로덕션 환경에서 동일한 결과가 보장되지 않는다는 점은 먼저 짚고 넘어가야 합니다.
수치를 직접 따져보면 어떤 의미인가
기존 스크린샷 방식에서 AI 에이전트가 상품 검색 하나를 처리할 때 소요하는 토큰이 약 1,000~3,000개라고 할 때, 89% 절감이 적용되면 110~330개로 줄어드는 계산이 나옵니다. GPT-4o 기준 입력 토큰 단가는 $0.0025/1K(2026.02 기준)이므로, 하루 1만 번 에이전트 인터랙션이 발생하는 서비스에서는 월 비용이 약 $675에서 $74 수준으로 떨어집니다. 이 절감 효과는 서비스 규모가 클수록 기하급수적으로 벌어집니다.
98% 정확도 수치 역시 맥락이 중요합니다. “구조화된 툴 호출 기준”이라는 조건이 붙어 있고, DOM 파싱 방식 대비 비교치입니다. 웹사이트가 WebMCP 도구를 제대로 등록해 두지 않으면 에이전트는 여전히 DOM 스크래핑에 의존하게 됩니다. 다시 말해 98%는 WebMCP를 구현한 사이트 기준이고, 구현 안 된 사이트에서는 이 수치가 적용되지 않습니다.
💡 “구글 엔지니어가 USB-C 비유를 썼다”는 맥락과 수치를 같이 보니, 이 기술이 웹사이트 구현 여부에 따라 격차가 생기는 구조임이 드러났습니다.
안전하다고요? 공식 스펙에 구멍이 있습니다
대부분의 WebMCP 소개 글은 “브라우저가 사용자 승인을 요구한다”, “동일 출처 정책을 따른다”는 내용을 근거로 보안이 잘 설계됐다고 마무리합니다. 공식 스펙 원문을 직접 보면 얘기가 달라집니다. (출처: bug0.com/blog/webmcp-chrome-146-guide, 2026.02.11 — W3C 스펙 분석 기반)
스펙이 직접 인정한 “치명적 삼각 관계”
공식 명칭은 “lethal trifecta(치명적 삼각 관계)”입니다. 에이전트가 이메일을 읽고(개인 데이터), 그 안에 심어진 악성 프롬프트를 파싱하고(신뢰할 수 없는 외부 콘텐츠), 또 다른 도구를 통해 그 데이터를 외부로 내보낼 때(외부 통신), 각 단계 자체는 정상적인 동작이지만 연결하면 데이터 탈취 체인이 완성됩니다. 프롬프트 인젝션이 이 체인의 방아쇠가 됩니다.
destructiveHint는 강제력이 없습니다
도구를 등록할 때 “이 도구는 파괴적 동작을 할 수 있다”고 표시하는 destructiveHint 속성이 있습니다. 그런데 이건 권고(advisory)일 뿐, 강제 실행을 막는 하드 샌드박스가 아닙니다. 클라이언트(브라우저 또는 에이전트)가 이 힌트를 무시하기로 결정하면, 핸들러가 데이터를 삭제하거나 외부로 전송하는 것을 기술적으로 막을 수 없습니다. 스펙 자체에 “mitigations exist but don’t eliminate the risk”라는 표현이 그대로 들어가 있습니다.
⚠️ 민감 데이터를 다루는 프로덕션 환경에서 WebMCP를 지금 배포하는 것은 보안 리스크를 감수하는 결정입니다. 스펙 자체가 아직 초안이고, 위 문제들에 대한 공식 해결책이 나오지 않았습니다.
사용자 동의 프롬프트 문제도 있습니다. 브라우저가 “Gmail + Claude”를 한 번 승인하면 이후 해당 조합은 매번 확인 없이 실행됩니다. 쿠키 배너처럼 습관적으로 “허용”을 누르게 되면 이 보안 레이어의 의미가 사실상 무력화됩니다.
지금 당장 쓰면 안 되는 세 가지 이유
WebMCP 관련 글 대부분이 “빨리 적용해서 에이전트 친화 사이트를 만들자”는 방향으로 마무리됩니다. Kassebaum Engineering 분석(2026.02.14)과 bug0.com 기술 분석(2026.02.11)을 교차 검토하면 지금 프로덕션 배포를 보류해야 할 이유가 명확합니다.
API 인터페이스가 바뀝니다
navigator.modelContext 인터페이스 이름, 메서드 시그니처, 파라미터 구조 모두 크롬 버전 사이에서 바뀔 수 있는 상태입니다. DevTrial 단계에서 배포하면 다음 크롬 업데이트에서 사이트가 깨질 수 있습니다.
크롬 외 브라우저 사용자는 아무것도 안 됩니다
Firefox는 지원 계획이 없고, Safari는 발표조차 없습니다. (출처: vydera.com/en/lab/webmcp-site-agent-ready-visibility, 2026.03.22) Edge는 Microsoft가 공동 개발자이므로 지원 가능성이 높지만 일정이 미정입니다. WebMCP 도구에 핵심 기능을 넣으면 비크롬 사용자는 에이전트 없이 수동으로 써야 합니다.
React·Redux 등 SPA 구조는 리팩토링 없이 연동 불가
도구 핸들러는 컴포넌트 상태(State)에 마법처럼 접근하지 못합니다. UI와 비즈니스 로직이 긴밀하게 결합된 SPA는 공유 서비스 레이어를 먼저 분리해야 WebMCP 도구가 의미 있는 액션을 취할 수 있습니다. 기존 코드가 복잡할수록 연동 비용이 더 올라갑니다.
스펙 원문도 “도구는 페이지당 50개 이하로 유지할 것”을 권고합니다. 에이전트 디스커버리 과부하를 막기 위한 실용적 제한인데, 이 말은 WebMCP가 전체 앱 API 표면을 대체하는 게 아니라 핵심 사용자 흐름 몇 가지에 집중하도록 설계됐다는 뜻입니다.
웹 표준의 계보로 보면 이게 왜 중요한가
WebMCP를 단순한 “API 하나 추가”로 보면 중요성을 놓칩니다. 웹이 크롤러와 소통하는 방식이 30년에 걸쳐 진화해 온 계보 위에 올라앉혀서 보면 다른 그림이 나옵니다.
💡 robots.txt부터 WebMCP까지의 흐름을 같이 놓고 보니, 각 표준이 ‘어떤 존재에게 웹을 설명하는가’라는 문제를 한 계층씩 쌓아온 구조였습니다.
| 표준 | 목적 | 등장 연도 |
|---|---|---|
| robots.txt | 크롤러에게 색인 범위 알림 | 1994년 |
| sitemap.xml | 크롤러에게 콘텐츠 위치 알림 | 2005년 |
| Schema.org JSON-LD | 기계에게 엔티티 의미 알림 | 2011년 |
| llms.txt | AI 모델에게 사이트 개요 알림 | 2025년(부상) |
| WebMCP | AI 에이전트에게 상호작용 방법 알림 | 2026년(초안) |
각 표준은 새로운 유형의 방문자가 등장할 때마다 “당신에게 우리 사이트를 이렇게 설명합니다”라는 계층을 쌓아왔습니다. WebMCP는 그 계보에서 가장 최신 레이어입니다. 동시에 이전 레이어들과 달리, 처음으로 “읽기”가 아닌 “행동”까지 에이전트에게 위임하는 표준입니다. 그게 기술적으로도, 보안 측면에서도 이전 표준과 질적으로 다른 이유입니다.
지금 당장 할 수 있는 준비는 WebMCP 배포가 아닙니다. 시맨틱 HTML 폼 구조를 정비하고, llms.txt를 먼저 도입하고, Schema.org 마크업을 갖춰두는 것이 스펙이 안정화된 뒤 WebMCP를 최소 비용으로 얹을 수 있는 실질적인 준비입니다.
자주 묻는 질문 5개
마치며 — 지금은 구경하고 준비할 때
WebMCP는 분명히 중요한 기술입니다. 30년 웹 역사에서 처음으로 AI 에이전트가 웹사이트와 “추측 없이” 대화하는 공식 통로를 만들려는 시도이고, 구글·마이크로소프트가 공동으로 W3C 표준화 트랙에 올린 만큼 결국 현실이 될 가능성이 높습니다.
솔직히 말하면, 지금 단계에서 가장 현명한 판단은 빠른 적용이 아닙니다. 스펙이 안정화될 때까지 API 변경 추적 비용을 감당하면서 프로덕션에 올리는 건 리스크가 이점을 초과합니다. 반면 HTML 시맨틱 폼 정비, llms.txt 도입, Schema.org 마크업은 WebMCP와 무관하게 지금도 유효한 투자입니다. 이 기반을 갖춰두는 것이 WebMCP가 크롬 안정 채널에 올라오는 날 가장 빠르게 올라탈 수 있는 방법입니다.
이 글 기준: 2026.03.28 / Chrome 146 Canary DevTrial / W3C Draft Community Group Report (2026.02.10)
본 포스팅 참고 자료
- Chrome for Developers — WebMCP 조기 프리뷰 발표 (developer.chrome.com/blog/webmcp-epp), 2026.02.10
- Chrome for Developers — WebMCP vs MCP 공식 비교 (developer.chrome.com/blog/webmcp-mcp-usage), 2026.03.11
- Kassebaum Engineering — WebMCP 기술 분석 및 벤치마크 (kassebaumengineering.com), 2026.02.14
- bug0.com — Chrome 146 WebMCP 스펙 상세 분석 (bug0.com/blog/webmcp-chrome-146-guide), 2026.02.11
- Forbes — WebMCP 산업 분석 (forbes.com), 2026.02.19
- Vydera — 브라우저별 WebMCP 지원 현황 (vydera.com), 2026.03.22
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. WebMCP는 현재 W3C 초안 단계로, API 명세·보안 정책·브라우저 지원 범위가 추후 변경될 수 있습니다. 최신 정보는 Chrome for Developers 공식 블로그와 W3C 스펙 페이지에서 직접 확인해 주세요.
댓글 남기기