W3C 표준 초안 단계
프로덕션 적용 금지
WebMCP, 브라우저가 AI 에이전트 도구가 되는 게 함정입니다
Chrome 146에 조용히 들어온 WebMCP는 AI 에이전트가 웹을 쓰는 방식을 근본부터 바꿉니다. “편리해진다”는 말 뒤에 로그인 세션 권한 전체를 AI가 상속받는 구조가 숨어 있습니다. 기존 MCP와 뭐가 다른지, 실제로 어떤 리스크가 있는지 공식 문서 기준으로 직접 확인했습니다.
AI 에이전트는 지금 어떻게 웹을 씁니까
지금 AI 에이전트가 웹을 조작하는 방식은 솔직히 말하면 꽤 비효율적입니다. 화면을 스크린샷으로 캡처하고, DOM 트리를 파싱하고, “이게 제출 버튼인가?”를 추측하는 방식으로 작동합니다. Chrome의 Gemini 기반 자동 탐색 기능이 딱 이 방식인데, 단순한 검색 하나에 수천 토큰을 소모합니다. 사이트 UI가 조금만 바뀌어도 에이전트가 즉시 멈추는 게 이 구조 때문입니다.
요약하면 에이전트는 지금 “인간을 흉내 내는 방식”으로만 웹을 씁니다. WebMCP는 이 방식 자체를 바꾸겠다는 시도입니다. 인간용 인터페이스를 흉내 내는 대신, AI 에이전트만을 위한 별도의 인터페이스 레이어를 표준으로 만드는 것입니다.
WebMCP가 뭔지, 공식 문서 그대로 풀었습니다
2026년 2월 10일, 구글 크롬 팀이 블로그를 통해 WebMCP 사전 체험판을 공개했습니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10) 정식 명칭은 Web Model Context Protocol이고, W3C Web Machine Learning Working Group에서 Microsoft와 Google이 공동으로 제안 중인 표준 초안입니다. 즉, 단일 기업 제품이 아닙니다.
두 가지 방식으로 동작합니다
WebMCP에는 선언적 API와 명령형 API 두 가지가 있습니다. 선언적 API는 기존 HTML 폼에 속성 두 개(toolname, tooldescription)만 추가하면 됩니다. JavaScript를 한 줄도 안 써도 됩니다. 브라우저가 폼 구조를 읽어서 AI 에이전트가 이해할 수 있는 툴 스키마로 자동 변환합니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10) 명령형 API는 navigator.modelContext.registerTool()로 더 복잡한 동작을 직접 정의하는 방식입니다.
💡 공식 발표문과 실제 구현 방식을 같이 놓고 보면 이런 흐름이 보입니다 — 브라우저가 MCP 프로토콜의 데이터·전송 레이어를 대신 처리해주고, 개발자는 툴 이름과 설명만 작성하면 됩니다. 즉, 별도 서버 없이 프론트엔드만으로 AI 에이전트 인터페이스를 노출할 수 있는 구조입니다.
기존 MCP와 다른 점 — 프론트엔드로 온 이유
Anthropic이 만든 기존 MCP(Model Context Protocol)와 이름이 비슷해서 헷갈리기 쉬운데, 작동 위치가 완전히 다릅니다. 기존 MCP는 백엔드 서버(Python, Node.js)가 필요하고 서버 간 통신을 합니다. WebMCP는 브라우저 탭 안에서, 즉 클라이언트 사이드에서 실행됩니다. (출처: Chrome for Developers, “When to use WebMCP and MCP”, 2026.03.11)
| 구분 | 기존 MCP | WebMCP |
|---|---|---|
| 실행 위치 | 백엔드 서버 | 브라우저 탭 (클라이언트) |
| 인프라 | 별도 서버 필요 | 서버 불필요 |
| 인증 | 별도 인증 구현 | 현재 세션 자동 상속 |
| UI 접근 | 불가 | DOM 직접 접근 가능 |
| 현재 상태 | 프로덕션 사용 가능 | DevTrial (실험적) |
표에서 “세션 자동 상속” 부분이 핵심입니다. 편리한 것처럼 보이지만, 바로 이 부분이 보안 문제로 연결됩니다. 아래 섹션에서 이어 설명합니다.
세션 권한 상속, 편리함 뒤에 있는 구조
WebMCP 툴은 브라우저 탭 안의 JavaScript 컨텍스트에서 실행됩니다. 이 말은 툴이 실행될 때 현재 사용자의 로그인 세션, 쿠키, 접근 권한을 그대로 씁니다. 별도 인증이 필요 없는 이유가 바로 이 구조인데, 반대로 말하면 AI 에이전트가 현재 로그인된 모든 권한을 위임받는 것과 다름없습니다.
💡 보안 취약점 문서와 WebMCP 스펙 초안을 교차해서 읽으니 이런 흐름이 보였습니다 — 기존 MCP 백엔드 서버는 독립된 인증 단계가 있어 권한 범위를 명시적으로 제한할 수 있습니다. WebMCP는 세션 상속 구조라서 “최소 권한 원칙”을 적용하기 어렵습니다.
실제 보안 사고가 이미 일어났습니다
MCP 생태계에서는 이미 구체적인 사고가 발생했습니다. GitHub MCP 서버에 대한 프롬프트 인젝션 공격으로 AI 코딩 어시스턴트가 비공개 저장소 내용을 유출했습니다. WhatsApp MCP 서버는 “툴 포이즈닝” 공격으로 사용자 메시지 전체 기록이 외부로 빠져나갔습니다. (출처: Security Boulevard, “The Ultimate Guide to MCP Security Vulnerabilities”, 2026.03.19) 이 사고들은 WebMCP가 아닌 백엔드 MCP에서 발생했는데, 세션 권한까지 통째로 상속받는 WebMCP에서 같은 유형의 공격이 발생하면 피해 범위는 더 넓습니다.
공식 스펙 문서도 이 점을 직접 인정하고 있습니다. “툴 설명을 통한 프롬프트 인젝션을 어떻게 막을 것인가”, “두 에이전트가 같은 페이지에서 동시에 동작할 때 충돌을 어떻게 처리할 것인가”는 현재 열려 있는 미해결 문제로 명시되어 있습니다. (출처: W3C WebMCP 제안 문서, ivanturkovic.com 분석, 2026.02.15)
SEO가 AEO로 바뀌는 게 왜 지금 시작됩니까
WebMCP를 처음 봤을 때 “기술 표준 이야기”처럼 보이지만, 실제로는 검색 최적화 패러다임 전환을 예고합니다. 현재 사이트의 SEO 경쟁력은 검색 크롤러가 잘 읽을 수 있는 구조로 만드는 것에서 나옵니다. WebMCP 이후에는 AI 에이전트가 잘 호출할 수 있는 툴 구조를 만드는 것이 경쟁력이 됩니다. 이미 AEO(Agent Engine Optimization)라는 개념이 등장하고 있습니다.
💡 1990년대 robots.txt·사이트맵이 등장했을 때와 지금 상황을 겹쳐 보면 패턴이 보입니다 — 그때 기계 가독성 신호를 빨리 적용한 사이트가 검색 트래픽을 독점했습니다. WebMCP 툴을 먼저 설계하는 사이트가 에이전트 트래픽의 첫 선점자가 될 가능성이 높습니다.
툴 설명 문구가 클릭률을 결정합니다
WebMCP 공식 스펙에서는 툴의 name과 description 품질이 에이전트가 어떤 사이트의 툴을 선택할지를 결정한다고 명시합니다. 메타 디스크립션이 클릭률을 결정하는 것처럼, 툴 설명이 에이전트 호출률을 결정하는 시대가 오는 것입니다. 현재는 툴 검색 가능성(discoverability) 자체가 미해결 문제인데, 공식 문서는 향후 .well-known/webmcp 형태의 매니페스트 기반 탐색 레이어를 추가할 것을 시사합니다. (출처: ivanturkovic.com, 2026.02.15)
지금 당장 쓰면 안 되는 이유 3가지
WebMCP가 흥미롭다고 해서 지금 바로 프로덕션에 얹으면 안 됩니다. 공식 문서에서 직접 이유를 확인했습니다.
API 이름이 버전마다 바뀝니다
초기 버전은 window.agent라고 불렸고, 현재는 window.navigator.modelContext로 변경됐습니다. (출처: patrickbrosset.com, 2026.02.23) 스펙이 초안 상태인 만큼 메서드 이름·파라미터 구조 전체가 다음 버전에서 바뀔 수 있습니다. 지금 쓴 코드가 다음 Chrome 버전에서 깨질 가능성이 높습니다.
Chrome 외 브라우저는 아직 지원하지 않습니다
W3C 표준 제안에 Microsoft와 Google이 함께 참여하고 있지만, Firefox와 Safari는 구현을 시작하지 않았습니다. 현재 Chrome 146 Canary에서만 플래그를 켜야 동작합니다. 실서비스에 붙이면 Chrome 이외 사용자 전체에게 기능이 없는 것처럼 보입니다.
보안 모델이 아직 완성되지 않았습니다
프롬프트 인젝션 방어, 동시 에이전트 충돌 처리, 툴 체이닝을 통한 정보 유출 차단 방법이 모두 스펙 문서에서 “미해결 항목”으로 분류됩니다. 공식 문서가 “프로덕션 배포 금지”를 명시한 이유가 여기에 있습니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10)
지금 할 수 있는 가장 좋은 방법은 Chrome 146 Canary에 플래그를 활성화하고 로컬에서 테스트하는 것입니다. 공식 EPP(Early Preview Program)에 참여하면 Chrome 팀의 피드백 채널에 직접 연결됩니다.
Q&A — 자주 묻는 것들
마치며 — 총평
WebMCP는 아직 실험 단계이고 보안 모델도 완성되지 않았습니다. 그런데도 지금 알아야 하는 이유는 있습니다. Google과 Microsoft가 W3C에서 함께 표준을 밀고 있고, 브라우저 두 곳이 모두 참여한다는 건 “이 방향으로 간다”는 신호로 읽힙니다.
솔직히 말하면 지금 당장 흥분할 기술은 아닙니다. 프로덕션에 쓰면 안 되고, API는 바뀌고, 보안 구멍도 열려 있습니다. 그런데 1990년대 중반 robots.txt 나왔을 때도 “이게 뭐야”라고 했던 사람들이 나중에 검색 트래픽에서 뒤처졌다는 사실은 기억해둘 만합니다.
지금 할 수 있는 가장 실용적인 준비는 두 가지입니다. HTML 폼 구조를 시맨틱하게 정리해두는 것, 그리고 W3C WebMCP 제안 문서(github.com/webmachinelearning/webmcp)를 북마크해두고 변경사항을 추적하는 것입니다. 기술이 여물어졌을 때 빠르게 적용할 수 있는 사람이 먼저 움직이는 사람입니다.
본 포스팅 참고 자료
- 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)
- Patrick Brosset (Microsoft Edge 팀) — WebMCP 업데이트 및 다음 단계 (patrickbrosset.com, 2026.02.23)
- Security Boulevard — MCP 보안 취약점 완전 가이드 (securityboulevard.com, 2026.03.19)
- Ivan Turkovic — WebMCP가 AI 에이전트로 웹을 재편하는 방법 (ivanturkovic.com, 2026.02.15)
⚠️ 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. WebMCP는 현재 W3C 표준 초안(Draft Community Group Report) 단계로, 본문에 언급된 API 명칭·구조·동작 방식은 Chrome 버전 업데이트 또는 표준화 과정에서 달라질 수 있습니다. 본 내용은 Chrome 146 기준(2026.02.10 공개)으로 작성되었습니다.
댓글 남기기