# WebMCP (Web Model Context Protocol) 공개

> Clean Markdown view of GeekNews topic #26597. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26597](https://news.hada.io/topic?id=26597)
- GeekNews Markdown: [https://news.hada.io/topic/26597.md](https://news.hada.io/topic/26597.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-02-11T10:31:02+09:00
- Updated: 2026-02-11T10:31:02+09:00
- Original source: [developer.chrome.com](https://developer.chrome.com/blog/webmcp-epp?hl=ko)
- Points: 42
- Comments: 3

## Summary

웹사이트가 **AI 에이전트에게 구조화된 도구를 명시적으로 노출**하도록 하는 접근으로, 버튼 의미나 폼 구조를 추론하던 기존 방식보다 더 직접적인 상호작용을 가능하게 합니다. **WebMCP**는 사이트가 수행 가능한 작업과 입력·출력을 **명시적 계약(contract)** 형태로 정의해 에이전트가 이를 직접 호출할 수 있도록 설계되었습니다. 이를 활용하면 스크린샷이나 DOM 분석에 의존하는 방식보다 **토큰 사용량을 약 10% 수준**으로 줄일 수 있어 비용과 지연을 크게 낮출 수 있습니다. **토큰 비용을 절약해주는 소프트웨어가 진화론적인 압력으로 살아남을 것**이라던 [Steve Yegge의 소프트웨어 서바이벌 3.0](https://news.hada.io/topic?id=26413)이 생각나네요.

## Topic Body

- WebMCP는 **웹사이트가 브라우저 내 AI 에이전트에게 구조화된 도구를 직접 노출**하도록 설계된 제안 표준  
- 기존의 화면 스크래핑이나 DOM 추론 대신, 웹이 스스로 **“이 페이지에서 무엇을 할 수 있는지”** 기능과 입력·출력을 **명시적 계약 형태**로 제공   
- 선언적 API와 명령형 API를 통해 **HTML 폼 기반 작업부터 복잡한 JavaScript 상호작용**까지 지원  
- 에이전트가 페이지의 도구를 **탐색(Discovery)** 하고, **JSON Schema**로 입출력을 명시하며, 현재 **페이지 상태(State)를 공유**하는 계약(contract) 구조  
- 크롬 146 버전에 얼리 프리뷰 버전으로 포함됨. 사전 체험을 위해서는 [Chrome built-in AI Early Preview Program](https://developer.chrome.com/docs/ai/join-epp?hl=ko) 에 가입 필요  
- 기존 MCP가 서버 사이드 프로토콜인 반면 WebMCP는 **클라이언트 사이드 브라우저 내 AI 에이전트**를 위한 프로토콜이라는 점에서 차별화됨  
  
---  
스펙 드래프트 문서: [WebMCP Early Preview](https://docs.google.com/document/d/1rtU1fRPS0bMqd9abMG_hc6K9OAI6soUy3Kh00toAgyk/edit?tab=t.0#heading=h.ori4k6xcfwho)  
  
### WebMCP의 등장 배경  
  
- 에이전트 웹 환경에서는 AI가 사용자를 대신해 **예약, 제출, 설정 변경, 탐색** 같은 실제 작업을 수행하는 비중이 증가 중  
- 기존 웹은 인간 사용자를 전제로 설계되어 있어, 에이전트는 버튼 의미나 폼 구조를 **추론**해야 했음  
- 이로 인해 입력 오류, 잘못된 필드 매핑, UI 변경에 따른 **취약성**이 반복적으로 발생  
- WebMCP는 이러한 문제를 해결하기 위해 웹과 에이전트 사이에 **명시적 상호작용 계약(contract)** 을 도입함   
- 에이전트가 버튼의 목적이나 폼의 구조를 추측하는 대신, 웹사이트가 자체 인터페이스를 **명시적으로 공개**하는 방식  
- 이 계약은 세 가지 핵심 요소로 구성:  
  - **Discovery**: 페이지가 지원하는 도구(예: checkout, filter_results)를 에이전트가 표준화된 방식으로 조회  
  - **JSON Schema**: 입력과 예상 출력의 명시적 정의로 환각(hallucination)이나 오해 감소  
  - **State**: 현재 페이지 컨텍스트에 대한 공유된 이해로, 에이전트가 실시간으로 사용 가능한 리소스 파악  
  
### WebMCP의 핵심 개념  
- ## 구조화된 도구 노출  
  - 웹사이트는 자신이 제공하는 기능을 **도구(tool)** 형태로 선언  
  - 각 도구는 이름, 설명, 입력 스키마(JSON Schema), 실행 결과를 명확히 정의  
  - 에이전트는 DOM을 해석하지 않고도 “무엇을 호출해야 하는지”를 정확히 인지 가능  
- ## 추론 대신 계약  
  - 버튼 의미 추측이나 캘린더 UI 분석 대신, 웹이 직접 **의도와 규칙을 공개**  
  - 입력·출력 형식이 고정되어 있어 **환각(hallucination)과 오작동 감소**  
  - UI 변경에도 도구 계약이 유지되면 에이전트 동작은 안정적으로 유지됨   
  
### 두 가지 API 모델  
- ## 선언적 API (Declarative API)  
  - HTML `<form>` 요소에 속성만 추가해 도구로 변환  
  - `toolname`, `tooldescription` 속성으로 도구의 의미를 선언  
  - 폼 필드가 곧 도구의 입력 파라미터가 됨  
  - 브라우저가 이를 자동으로 JSON Schema로 변환  
  - 단순하고 반복적인 작업, 기존 폼 기반 UI에 적합  
- ## 명령형 API (Imperative API)  
  - JavaScript로 직접 도구를 등록  
  - `registerTool`, `provideContext`, `unregisterTool` 등의 API 제공  
  - 복잡한 로직, 조건 분기, 비동기 처리, 상태 기반 동작에 적합  
  - SPA나 고급 웹 애플리케이션에서 활용도 높음  
  
### 브라우저와 에이전트의 상호작용 방식  
- 에이전트가 도구를 호출하면 브라우저는 해당 UI를 **자동으로 포커스 및 입력**  
- 폼이 에이전트에 의해 호출되었는지 여부를 `agentInvoked` 플래그로 구분  
- 성공·취소 시 `toolactivated`, `toolcancel` 이벤트 발생  
- CSS pseudo-class(`:tool-form-active`, `:tool-submit-active`)를 통해 시각적 피드백 제공  
- 인간 사용자와 에이전트 사용 흐름을 **동일한 UI 상태 모델**로 통합 가능  
  
### 대표적인 활용 시나리오  
- 항공사 사이트에서 `book_flight` 도구 제공 시, 에이전트가 캘린더 UI를 해석하지 않고 **구조화된 승객 정보 직접 제출**  
- 의료·법률 포털에서 `submit_application` 도구를 통해 필드 의미를 명확히 전달  
- 개발자 설정 페이지에서 `run_diagnostics` 같은 도구를 노출해 **숨겨진 메뉴 자동 실행**  
- 고객 지원, 전자상거래, 여행 서비스 등 **고신뢰 입력이 필요한 영역**에서 특히 효과적  
  
### WebMCP와 MCP의 차이  
- MCP(Model Context Protocol)는 **서버 측 프로토콜**로, 별도의 서버 배포 필요  
- WebMCP는 **브라우저 내부**에서 동작하며 기존 웹 애플리케이션에 직접 통합  
- 서버 없이도 클라이언트 사이드 기능을 에이전트에게 제공 가능  
- 에이전트 브라우저를 전제로 한 **프런트엔드 중심 접근**이라는 점이 핵심 차이점  
  
### 현재 상태와 한계  
- Chrome 146 이상에서 플래그 활성화 시 사용 가능  
- 헤드리스 환경에서는 동작하지 않으며 **가시적인 브라우징 컨텍스트 필요**  
- 도구를 제공하는 사이트를 자동으로 발견하는 메커니즘은 아직 없음  
- UI 상태 동기화를 개발자가 책임져야 하는 구조  
- 초기 프리뷰 단계로, API 변경 가능성과 구현 마찰 존재

## Comments



### Comment 50982

- Author: xguru
- Created: 2026-02-11T11:14:11+09:00
- Points: 2

[@firt](https://xcom/firt/status/2020903127428313461) 가 X에서 얘기하고 나서 꽤 많이 이슈가 되고 있는데요. 링크는 구글 것으로 했습니다.   
  
[웹사이트 자동화 하는데 스크린샷/DOM 분석보다 10%의 토큰만으로도 가능](https://x.com/markus_hogne/status/2021176530807005316)해진다고 하는데요.   
[토큰 비용을 절약해주는 소프트웨어가 진화론적인 압력으로 살아남을 거라는 예상](https://news.hada.io/topic?id=26413)과도 일치합니다.

### Comment 50983

- Author: crawler
- Created: 2026-02-11T11:23:51+09:00
- Points: 1
- Parent comment: 50982
- Depth: 1

크롬이 주도하면 다른 브라우저에도 금방 들어 오겠군요

### Comment 51008

- Author: parkindani
- Created: 2026-02-11T17:19:42+09:00
- Points: 1

agent 를 위한 swagger 느낌이군요