브라우저의 AI 에이전트에게 "이 사이트를 어떻게 조작할지"를 가르치는 방법은 오랫동안 단 하나뿐이었다. 화면의 픽셀과 DOM을 읽고, 버튼 같은 요소를 추측하며, 클릭 순서를 구성하고, 레이아웃이 어긋나지 않기를 기도하며, 폼 전송이 성공하기를 바라는 방식이었다. 디자이너가 CSS 클래스 이름을 하나만 바꿔도 망가진다. 느리고 취약하다.

이러한 "추측 게임"을 끝내게 할 메커니즘이 WebMCP다. Google I/O 2026에서 발표되었으며, Chrome 149의 Origin Trial(본방 도메인에서 한정적으로 신기능을 시험할 수 있는 메커니즘)로서 개발자들이 실제로 접할 수 있게 되었다. 발상은 심플하다. 사이트 측에서 "이 페이지에서 할 수 있는 조작"을 구조화된 도구(Tool)로서 미리 선언해 두면, 에이전트는 그것을 호출한다. 화면을 해석하는 것이 아니라, 메뉴에서 주문하는 방식이다.

최근 1년 사이 주류가 된 "컴퓨터 조작형(computer-use)" 에이전트는 스크린샷을 찍어 모델에게 보여주고 좌표를 클릭하게 하는 방식이었다. 범용적이지만, 이미지를 토큰(Token)으로 변환하는 비용이 무겁고 UI의 미세한 변경에 취약하다. 반면 기존의 오토필(Autofill)은 가볍지만 유연성이 부족하여, "성명"란과 "성·이름"이 나누어진 칸을 구별하지 못하는 등의 한계가 있었다.

WebMCP는 그 중간이 아니라 별개의 레이어 해결책이다. 사이트가 자신의 기능을 입력 스키마(Input Schema)가 포함된 함수로서 공개한다. 에이전트는 무엇을 클릭할지 고민할 필요 없이, add-todo와 같은 이름의 도구를 인자(Argument)와 함께 호출하기만 하면 된다.

InfoQ가 소개한 한 구현자의 벤치마크에 따르면, 스크린샷 방식과 비교했을 때 토큰 사용량이 약 9할 감소했다고 한다(InfoQ). 어디까지나 하나의 사례일 뿐이지만, 이미지를 모델에 계속 먹여야 하는 구조를 없앤다면 이 정도의 차이가 나는 것은 납득이 간다.

핵심이 되는 명령형(Imperative) API는 JavaScript로부터 도구를 등록한다. Anthropic의 Model Context Protocol (MCP)를 알고 있다면 정의 형태가 친숙할 것이다. 이름, 설명, JSON Schema 입력 정의, 그리고 실행 본체인 execute를 전달한다.

await document.modelContext.registerTool({
name: "add-todo",
description: "Add a new item to the user's active todo list",
...

두 번째 인자로 AbortController의 signal을 전달하여 도구의 등록 해제를 제어할 수 있다는 점에 주목할 필요가 있다. SPA와 같이 화면 전환에 따라 할 수 있는 조작이 변하는 앱에서는 상태에 따라 도구를 넣고 빼는 설계가 전제되어야 한다.

참고로 초기 해설에서는 진입점이 navigator.modelContext였으나, 공식 문서에는 "navigator.modelContext는 Chrome 150에서 비권장(Deprecated). document.modelContext를 사용할 것"이라는 주석이 있다. Origin Trial 단계의 사양이기 때문에 이러한 명칭은 아직 변동될 수 있다. 직접 코드를 작성할 때는 Imperative API 문서에서 최신 철자를 확인한 뒤 작성하는 것이 좋다.

또 다른 선언적(Declarative) API는 JavaScript를 작성하지 않고 기존의 <form>에 속성을 추가하는 것만으로 도구화하는 것이다. 브라우저가 폼으로부터 입력 스키마를 자동으로 생성해 준다.

<form toolname="supportRequestTool"
tooldescription="Submit a request for support."
action="/submit">
...

toolname과 tooldescription을 폼에, 필요하다면 각 항목에 toolparamdescription을 붙이기만 하면 된다. 기존의 고객 지원 접수 폼을 그대로 에이전트 대응형으로 만들 수 있다는 점은 현실적이며, 이 부분이 보급의 열쇠가 될 것으로 보인다.

사실 확인 과정에서 무시할 수 없는 차이점이 하나 발견되었다. 도구의 반환값(Return value) 형태가 참조한 소스마다 일치하지 않는다.

W3C Web Machine Learning Community Group의 explainer는 위 코드와 같이 { content: [{ type: "text", text: "..." }] }라는 MCP 유래의 구조를 반환한다. 반면, Chrome 공식 문서의 다른 샘플(피자 레이어 조작 예시)에서는 execute가 단순한 문자열을 반환하고 있었다.

'navigator.modelContext' is deprecated in Chrome 150. Use 'document.modelContext' instead.

이 버전 주석이 나타내듯, API는 아직 만들어지고 있는 과정이다. 반환값(Return value) 또한 마찬가지로 흔들리고 있을 가능성이 높다. 테스트할 때는 문자열과 콘텐츠 배열(Content array)이 모두 통하는지 직접 확인하고, explainer의 구조화된 형태에 맞춰 두는 것이 무난할 것이다. 사양이 확정되면 MCP 호환의 content 배열로 통일될 것이라는 게 필자의 견해다.

이름이 유사한 것처럼 WebMCP는 Anthropic의 MCP에서 영감을 얻었지만, 별개의 것이다. MCP가 서버 측에서 동작하는 반면, WebMCP는 브라우저 전용으로 설계되었으며 resources와 같은 서버 측 개념을 덜어냈다. 중요한 점은 도구가 페이지 내의 JS로서 로그인된 사용자 세션의 권한으로 동작한다는 것이다. 이는 강력하면서도 동시에 위험하다.

explainer 자체에서도 지적하고 있는 것이 간접 프롬프트 인젝션(Indirect Prompt Injection)이다. 페이지 내의 신뢰할 수 없는 텍스트(타인의 게시물이나 댓글)가 에이전트에 대한 지시로 읽혀, 멋대로 도구를 호출하게 만드는 공격이 성립될 수 있다. 이에 대한 대책으로 신뢰할 수 없는 콘텐츠를 untrustedContentHint로 명시하는 메커니즘이 마련되어 있다.

또 하나, 사소하지만 본질적인 지적이 있다. "환불 워크플로우를 호출할 수 있더라도, 환불 정책이 오래되었다면 에이전트는 아주 깔끔하게 잘못된 조작을 실행한다". 초기 도입자들은 도구를 만드는 것 자체보다 정책이나 고객 상태, 예외 상황, 에스컬레이션(Escalation) 경로와 같은 문맥(Context)을 에이전트에게 정확하게 전달하는 것이 더 어렵다고 보고하고 있다. 도구를 공개하기 전에, 해당 조작이 호출되어도 좋은 전제 조건을 누가 보장할 것인가를 설계에 포함해야 한다.

Chrome 149의 오리진 트라이얼(Origin Trial)에 자신의 오리진을 등록하면 실제 환경에서도 테스트할 수 있다. 사양 책정이 W3C 커뮤니티 그룹(Google과 Microsoft의 기여자들이 이름을 올리고 있음)에서 진행되고 있다는 것은, 이것이 한 회사의 브라우저 기능으로 끝나지 않고 에이전트를 위한 "페이지가 스스로 밝히는 조작 계약"이라는 Web의 관례가 될 수 있음을 의미한다. computer-use의 화면 해석 방식은 폴백(Fallback)으로 남더라도, 비용과 신뢰성 측면에서 경쟁할 수 없는 영역부터 WebMCP로 대체되어 갈 것이다. 자사 사이트에 이미 폼(Form)이나 버튼으로 제공하고 있는 주요 조작이 있다면, 선언적 API(Declarative API)로 도구 이름과 설명을 추가하는 것부터 시작하는 것이 가장 투자 대비 효과가 높다.

공식 입구는 여기다.