WebMCP가 온다: 웹 UI는 이제 사람뿐 아니라 에이전트와도 계약해야 한다

테크

웹 애플리케이션이 AI 에이전트에게 읽히는 시대는 이미 시작됐다. 문제는 대부분의 에이전트가 아직 화면을 보고, DOM을 추정하고, 클릭을 흉내 내며 작업한다는 점이다. 사람에게는 자연스러운 버튼과 폼도 에이전트에게는 불안정한 퍼즐이 된다.

Chrome 팀이 공개한 WebMCP는 이 문제를 정면으로 다룬다. 사이트가 “이 화면에서는 검색, 예약, 제출 같은 도구를 이렇게 호출할 수 있다”는 구조화된 계약을 브라우저 안에서 노출하게 하자는 제안이다. Chrome 149 DevTools에는 실험적 WebMCP 디버깅 도구도 들어갔다.

Diagram showing how WebMCP connects a human web app, a structured tool layer, a browser agent, and DevTools verification.
WebMCP adds a structured tool contract on top of the visible web interface, then lets DevTools inspect and verify the contract.

무슨 일이 있었나

Chrome WebMCP 문서는 2026년 5월 18일 공개되고 6월 9일 업데이트됐다. 문서의 핵심은 JavaScript API와 HTML form annotation을 통해 페이지 기능을 AI agent가 호출 가능한 tool로 드러내는 것이다. Chrome 149 릴리스 노트는 Application panel 안에서 tool schema를 보고, 직접 실행하고, invocation 상태와 반환 payload를 추적하는 실험적 디버깅 기능을 소개했다.

왜 개발자에게 중요한가

지금까지 웹 자동화는 Playwright, Selenium, DevTools Protocol, 스크린샷 기반 추론에 기대왔다. WebMCP의 차이는 “에이전트가 UI를 해석한다”가 아니라 “웹 앱이 의도를 선언한다”에 있다. 복잡한 날짜 선택기, 다단계 고객 지원, 예약/구매 플로우처럼 클릭 순서가 의미를 잃기 쉬운 영역에서는 이 차이가 운영 안정성과 UX 책임 소재를 바꾼다.

커뮤니티 신호

Hacker News와 Reddit의 반응은 둘로 갈린다. 한쪽은 DOM scraping과 screenshot loop를 줄일 수 있다는 점에 기대한다. 다른 쪽은 별도 tool layer가 실제 UI와 drift를 만들 수 있고, 사이트마다 또 하나의 agent API를 유지해야 한다고 걱정한다. 이 논쟁 자체가 중요하다. WebMCP는 단순한 편의 기능이 아니라 웹 앱의 제품 표면을 하나 더 늘리는 결정이기 때문이다.

개발과 운영 영향

프론트엔드 팀은 이제 접근성 tree, 테스트 selector, analytics event처럼 agent-facing contract도 설계 자산으로 다뤄야 한다. 백엔드 API를 전부 공개하지 않고도 브라우저 context 안에서 사용자가 보는 작업을 visible execution으로 처리할 수 있지만, 권한 정책, origin isolation, 민감 작업 confirmation, schema validation을 빼면 새로운 자동화 취약점이 된다.

지금 할 수 있는 체크리스트

첫째, “에이전트가 자주 실패하는 사용자 작업”을 3개만 고른다. 둘째, 그 작업이 서버 API가 아니라 화면 상태와 강하게 결합돼 있는지 확인한다. 셋째, 입력 schema와 성공/실패 반환값을 먼저 문서화한다. 넷째, 구매·삭제·전송 같은 irreversible action은 사용자의 명시적 확인을 요구한다. 다섯째, DevTools for agents나 기존 E2E 테스트에서 tool 호출과 실제 UI 상태가 어긋나지 않는지 검증한다.

반론과 리스크

WebMCP는 아직 proposed standard이자 origin trial/early preview 성격이 강하다. 모든 브라우저와 모든 에이전트가 지원한다고 가정하면 안 된다. 또한 headless context가 아니라 열린 browser tab 또는 webview가 필요하다는 제약도 있다. 따라서 오늘 할 일은 전면 도입이 아니라, agent가 가치 있게 수행할 수 있는 좁은 플로우 하나를 실험하고 보안 경계를 검토하는 것이다.

실무 도입 기준

인간 UI가 먼저 정상 동작하고 접근성 이름이 명확한가

tool schema가 제품 용어와 실제 validation 규칙을 반영하는가

민감 작업은 confirmation과 audit log를 남기는가

agent가 실패했을 때 사용자가 흐름을 회복할 수 있는가

DevTools나 E2E 테스트로 UI와 tool 결과의 drift를 잡는가

결론

WebMCP의 핵심 메시지는 “AI agent를 위해 웹을 갈아엎자”가 아니다. 더 정확한 해석은 “사람이 보는 웹 경험을 유지하되, 에이전트가 추측하지 않아도 되는 최소 계약을 추가하자”다. 2026년의 웹 프론트엔드 품질은 화면 픽셀만이 아니라, 사람이 위임한 작업을 에이전트가 안전하게 수행할 수 있는지까지 포함하게 될 가능성이 크다.

출처