WebMCP가 뭔지 30초 안에 정리하면

지금 AI 에이전트가 웹사이트를 쓰는 방식은 솔직히 엉망입니다. 화면을 스크린샷으로 찍고, DOM을 파싱하고, “이 버튼이 결제 버튼인가?”를 추측합니다. 버튼 색깔이 바뀌거나, A/B 테스트로 레이아웃이 달라지면 에이전트는 바로 멈춥니다. WebMCP는 이 문제를 뿌리째 바꾸는 제안입니다.

웹사이트가 AI 에이전트에게 이렇게 말하는 구조입니다. “내가 할 수 있는 일은 이것이고, 입력값은 이렇게 생겼고, 결과는 이 형식으로 줄게.” 에이전트는 더 이상 화면을 추측하지 않아도 됩니다. 함수를 호출하면 끝입니다.

2026년 2월 10일, 구글 Chrome 팀이 Chrome 146에 사전 공개(Early Preview)로 탑재했고, W3C Web Machine Learning Working Group에서 구글과 마이크로소프트가 공동으로 표준화를 진행 중입니다. (출처: Chrome for Developers 공식 블로그, 2026.02.10)

▲ 목차로 돌아가기

MCP를 대체한다는 말이 틀린 이유

Chrome for Developers 공식 문서(2026.03.11)에는 딱 이렇게 나와 있습니다. “WebMCP is not an extension or a replacement of MCP. Instead, WebMCP and MCP address different needs.” — 대체가 아니라 다른 필요를 각각 해결한다는 겁니다.

MCP(Model Context Protocol)는 Anthropic이 만든 백엔드 표준입니다. 서버와 AI 플랫폼을 이어주고, 플랫폼 상관없이 어디서든 작동합니다. Python, TypeScript, Rust SDK로 구현하고, 서버가 상시 떠 있어야 합니다. WebMCP는 반대입니다. 브라우저 안에서만 작동하고, 탭이 살아있는 동안에만 존재하고, 추가 서버가 필요 없습니다.

둘은 역할이 다르기 때문에 가장 효과적인 활용은 두 가지를 함께 쓰는 겁니다. MCP로 백엔드 비즈니스 로직을 처리하고, WebMCP로 사용자가 열어둔 탭 위에서 실시간 인터랙션을 처리하는 방식입니다. (출처: Chrome for Developers 공식 블로그, 2026.03.11)

▲ 목차로 돌아가기

백엔드 서버 없이 되는 게 놀라운 이유

기존 MCP 통합에서는 Python이나 Node.js 서버를 별도로 운영하고, 인증을 따로 관리하고, 서버 간 통신을 설계해야 했습니다. WebMCP는 이 구조가 아예 필요 없습니다. 웹사이트가 이미 갖고 있는 HTML 폼에 속성 두 개만 추가하면 에이전트가 바로 읽을 수 있습니다.

<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>

브라우저가 프로토콜 처리를 대신 해주기 때문입니다. WebMCP 공식 제안서(W3C Web Machine Learning Working Group)에 이렇게 명시됩니다. “Implementation of the data layer to arbitrate access to these primitives for an Agent is left to the browser.” — 개발자는 도구 로직만 작성하면 되고, 브라우저가 MCP 포맷으로 변환해 에이전트에 전달합니다. (출처: Patrick Brosset — WebMCP updates and clarifications, 2026.02.23)

더 복잡한 작업은 JavaScript로 처리합니다. navigator.modelContext.registerTool()로 도구를 직접 등록하면 됩니다. 핵심은 execute 함수가 기존 비즈니스 로직을 그대로 씁니다. 새 API를 따로 만들 필요가 없습니다. 이미 서비스 중인 로직이 그대로 에이전트용 도구가 됩니다.

▲ 목차로 돌아가기

탭 닫으면 사라지는 게 오히려 이점인 상황

WebMCP 도구는 탭이 열려 있는 동안에만 존재합니다. 사용자가 탭을 닫거나 다른 페이지로 이동하면 도구 자체가 사라집니다. 이걸 단점으로 보는 시선이 많은데, 실제로는 다른 면이 있습니다.

기존 MCP 생태계에서 실제로 발생한 사고를 보면 이유가 명확해집니다. 깃허브 MCP 서버에 대한 프롬프트 인젝션 공격으로 비공개 저장소 내용이 유출됐고, WhatsApp MCP 서버는 도구 포이즈닝 공격으로 전체 메시지 히스토리가 탈취됐습니다. 공통점은 서버가 상시 연결돼 있고 세션이 끊기지 않는다는 점입니다. (출처: Ivan Turkovic, WebMCP Is Coming, 2026.02.15)

WebMCP는 도구 수명이 탭에 묶여 있어서, 탭이 닫히면 세션과 함께 도구도 소멸합니다. 추가로 사용자 동의 없이 에이전트가 민감한 작업을 자동 실행하지 못하도록 agent.requestUserInteraction() API가 명세에 포함됐습니다. 이건 결제나 예약처럼 되돌리기 어려운 작업에서 인간이 최종 확인을 하도록 강제하는 구조입니다.

▲ 목차로 돌아가기

지금 당장 쓰면 안 되는 이유

Chrome 146에서 사전 공개됐지만, 이걸 프로덕션에 바로 올리면 안 되는 이유가 몇 가지 있습니다. 첫째, navigator.modelContext라는 API 이름은 이미 이전 버전의 window.agent에서 한 번 바뀐 이름입니다. 이번이 마지막 이름이라는 보장이 없습니다.

둘째, 보안 모델이 아직 완성되지 않았습니다. 공식 문서가 열린 채로 남겨둔 질문들이 있습니다. 프롬프트 인젝션을 도구 설명 안에서 어떻게 막을 것인지, 두 에이전트가 같은 탭에서 동시에 작동하면 어떻게 충돌을 처리할 것인지, 개별적으로는 무해한 도구 호출이 연쇄적으로 이어져 민감 정보를 조합해낼 때 어떻게 탐지할 것인지 — 이 부분들에 대해 아직 공식 답변이 없습니다.

셋째, Chrome 한정 기능입니다. Firefox·Safari·Edge는 W3C 워킹그룹에 참여 중이지만 구현 일정을 공개하지 않았습니다. 지금 WebMCP 도구를 구현해도 Chrome 이외의 브라우저에서는 에이전트가 이를 인식하지 못합니다. 프로토타입과 피드백은 지금 해도 좋지만, 로드맵에 깊게 의존하는 결정은 표준이 안정화된 이후가 맞습니다.

▲ 목차로 돌아가기

SEO 다음 판이 여기서 열린다는 근거

1990년대 중반, 검색 엔진 크롤러가 등장했을 때 웹사이트는 사람만을 위해 만들어져 있었습니다. 그 뒤로 robots.txt, 사이트맵, 구조화 데이터, 메타 태그가 차례로 나왔고, 이 기계 가독성 레이어를 먼저 챙긴 사이트가 검색 트래픽을 가져갔습니다. WebMCP가 제시하는 구조는 정확히 이 흐름의 다음 단계입니다.

차이가 있다면 이번에는 ‘발견되는 것’을 넘어 ‘실행되는 것’이 기준입니다. 에이전트가 여행 예약을 할 때, WebMCP 도구가 없는 항공사 사이트는 에이전트의 선택지에 처음부터 없습니다. WebMCP 명세 문서에는 미래에 .well-known/webmcp와 같은 형태의 도구 발견(discovery) 레이어가 생길 가능성을 시사합니다. 이게 현실화되면, 도구 이름·설명·스키마 품질이 지금의 메타 디스크립션이나 타이틀 태그처럼 최적화 대상이 됩니다.

가장 먼저 고민할 것은 서비스 중인 HTML 폼 중에서 에이전트가 쓸 만한 것이 무엇인지 파악하는 일입니다. 제품 검색, 예약 폼, 문의 양식처럼 반복성 높은 작업이 1순위 후보입니다. 구현 비용이 낮고(HTML 속성 2개), 에이전트가 실제로 쓸 가능성이 높은 도구부터 시작하면 됩니다. 표준이 완성되기 전에 어떤 도구를 노출할지 먼저 설계해두면, 경쟁사보다 한 주기 앞서게 됩니다.

▲ 목차로 돌아가기

자주 묻는 질문

▲ 목차로 돌아가기

마치며

WebMCP를 처음 접했을 때 솔직히 “또 새로운 프로토콜이네” 싶었습니다. 그런데 공식 문서를 파고들면서 느낌이 달라졌습니다. 이건 기술 스택에 새 레이어를 얹는 게 아니라, 웹사이트가 누구를 위해 만들어지는지에 대한 전제가 바뀌는 신호입니다.

지금 당장 프로덕션에 올릴 것인지를 고민할 단계는 아닙니다. 보안 모델이 완성되지 않았고, API 이름도 한 번 바뀐 전례가 있고, Chrome 밖에서는 아직 아무것도 되지 않습니다. 그러나 어떤 도구를 내 서비스에서 에이전트에 노출할지 지금 생각해두는 건 공짜입니다. 표준이 굳기 전에 설계를 마쳐두면 그 순간 체감 속도는 꽤 다릅니다.

MCP가 죽는다는 말은 틀렸고, WebMCP가 만능이라는 말도 아직 이릅니다. 둘이 어떻게 나뉘고, 어디서 겹치는지를 지금 파악해두는 것으로 충분합니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Chrome for Developers — WebMCP Early Preview Program (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. Search Engine Land — WebMCP explained: Inside Chrome 146’s agent-ready web preview (2026.03.04)
5. Ivan Turkovic — WebMCP Is Coming: How AI Agents Will Reshape the Web (2026.02.15)
6. W3C Web Machine Learning Working Group — WebMCP Proposal (GitHub, 2026)