배경 및 맥락
지금의 브라우저 에이전트는 본질적으로 사람 흉내를 낸다. 버튼 텍스트와 DOM 구조를 읽고, 클릭과 입력을 시뮬레이션하며, 다음 행동을 추론한다. 이 방식은 데모에는 강하지만 실제 서비스에서는 작은 UI 변경, 모호한 필드 이름, 복잡한 폼 상태 때문에 실패율이 높다.
Chrome 팀이 제안한 WebMCP는 이 문제를 웹앱 쪽에서 풀자는 접근이다. 서버 측 MCP가 모델에게 외부 시스템 도구를 노출하는 규약이라면, WebMCP는 웹페이지 자체가 에이전트에게 "여기서는 이 작업을 이런 입력 형식으로 호출하라"고 명시하는 브라우저 계층 표준에 가깝다.
핵심 내용
공식 문서에 따르면 WebMCP는 웹페이지가 structured tools를 에이전트에 노출할 수 있게 한다. 개발자는 imperative API나 declarative HTML annotation을 통해 checkout, filter_results, submit_application, run_diagnostics 같은 tool을 등록할 수 있고, 에이전트는 JSON Schema로 입력/출력을 이해한다. Chrome은 이를 통해 agent actuation의 성능과 신뢰성이 크게 개선될 수 있다고 설명한다.
문서에서 강조하는 포인트도 실무적이다. WebMCP는 discovery, schema, shared state를 제공하며, 민감한 액션에는 confirmation dialog를 둘 수 있다. 또한 tools permissions policy를 기본 self로 두고, cross-origin iframe에는 명시적 allow="tools"가 필요하게 해 보안 경계도 설계에 포함했다. 로컬 개발에서는 Chrome flag로 쓸 수 있고, Chrome 149 origin trial이 예정돼 있다.
경쟁 구도 / 비교
기존 agent-browser 통합은 Playwright류 actuation, accessibility tree, DOM heuristics, 컴퓨터 사용 모델에 크게 의존했다. 이 방식은 범용성이 높지만 안정성과 비용 면에서 한계가 있다. WebMCP는 그 위에 선언적 tool layer를 추가해, 사람이 보는 UI와 에이전트가 호출하는 인터페이스를 분리하지 않으면서도 더 명확하게 만든다.
이 점에서 WebMCP는 단순 브라우저 기능이 아니라 웹 표준 차원의 메시지다. 앞으로 사이트가 agent-friendly surface를 직접 제공하면, 에이전트는 화면을 해석하는 대신 구조화된 작업을 수행하게 되고, 웹 제품의 경쟁력도 "사람 UX"만이 아니라 "agent UX"까지 확장될 수 있다.
의미
산업적으로는 브라우저가 agent runtime으로 진화하면서, 웹앱도 API와 UI 사이의 새로운 계층을 가져야 한다는 신호다. 검색, 예약, 지원, 전자상거래처럼 다단계 작업이 많은 서비스일수록 이 변화의 영향이 크다.
실무적으로는 프런트엔드 팀이 중요한 사용자 플로우를 WebMCP 같은 명시적 tool abstraction으로 재설계할 시점을 준비해야 한다. 장기적으로는 DOM이 아니라 schema와 policy를 중심으로 agent integration을 설계하는 조직이 더 낮은 실패율과 더 높은 자동화 전환율을 얻을 가능성이 높다.