브라우저 기반 AI 에이전트를 써본 개발자라면 같은 문제를 겪습니다. 사람에게는 명확한 버튼과 폼이 에이전트에게는 애매합니다. “다음” 버튼이 여러 개 있고, 날짜 선택기가 복잡하고, hidden state가 많고, 한 단계가 실패해도 에이전트는 그럴듯하게 다음 행동을 시도합니다.
Chrome 팀은 2026년 5월 18일 WebMCP를 공개했습니다. 공식 문서에 따르면 WebMCP는 AI agents를 위해 웹 애플리케이션이 structured tools를 만들고 노출할 수 있게 하는 proposed web standard입니다. JavaScript와 HTML form annotation을 통해 에이전트가 페이지 기능을 정확히 이해하고 사용할 수 있도록 돕습니다. Chrome 149에서 origin trial이 예정되어 있고, 현재는 Chrome flag로 로컬 개발 테스트를 할 수 있습니다.
이 글은 WebMCP를 새 표준 뉴스로만 다루지 않습니다. 웹앱 개발자가 브라우저 에이전트 시대에 UI를 어떻게 설계해야 하는지, 어떤 기능부터 tool로 노출해야 하는지를 실무 관점에서 정리합니다.
현재 브라우저 에이전트는 페이지를 보고 행동합니다. 버튼 텍스트, aria label, DOM 구조, 좌표, 스크린샷, 접근성 트리 같은 단서를 조합합니다. 이 방식은 간단한 페이지에서는 잘 작동할 수 있습니다. 하지만 실제 서비스는 복잡합니다.
예를 들어 여행 예약 페이지를 생각해보면 출발지, 도착지, 날짜, 탑승객, 좌석, 결제, 약관 확인이 얽혀 있습니다. 사람은 화면 흐름과 서비스 관습을 이해하지만, 에이전트는 각 단계를 추론해야 합니다. 추론 단계가 많을수록 실패 가능성도 늘어납니다.
WebMCP의 문제의식은 여기 있습니다. 페이지가 “이 버튼은 검색 실행이다”, “이 폼은 지원서 제출 도구다”, “이 입력은 full name이 아니라 first name과 last name을 분리해야 한다” 같은 의도를 구조화해 노출하면 에이전트가 덜 추측하게 됩니다.
즉 WebMCP는 에이전트에게 화면을 더 잘 보게 하는 기술이 아니라, 웹앱이 자신의 기능을 도구로 설명하게 하는 접근입니다.
공식 문서에 따르면 WebMCP는 discovery, JSON Schema, state를 지원합니다.
Discovery는 페이지가 checkout, filter_results 같은 tool을 등록하는 표준 방식입니다. 에이전트는 페이지를 직접 방문했을 때 어떤 tool을 호출할 수 있는지 알 수 있습니다.
JSON Schema는 입력과 기대 출력의 명시적 정의를 제공합니다. 예를 들어 submit_application tool이 name, email, resumeUrl을 필요로 한다면 각 필드의 형식과 필수 여부를 정할 수 있습니다. 이 구조는 환각이나 오해를 줄이는 데 도움이 됩니다.
State는 현재 페이지 맥락을 공유합니다. 에이전트는 지금 어떤 리소스가 사용 가능한지, 어떤 상태에서 어떤 tool을 호출할 수 있는지 이해할 수 있습니다.
이 세 가지를 합치면 웹앱은 에이전트에게 “화면을 보고 알아서 해석하라”고 맡기지 않고, 의도·입력·상태를 명시적으로 제공합니다.
모든 UI를 tool로 만들 필요는 없습니다. 오히려 처음부터 너무 많이 노출하면 유지보수와 보안 검토가 어려워집니다. 우선순위는 에이전트가 자주 실패하거나 사용자에게 비용이 큰 흐름입니다.
추천 후보는 다음과 같습니다.
반대로 결제 실행, 계정 삭제, 외부 전송처럼 되돌리기 어려운 작업은 바로 자동 tool로 열면 안 됩니다. 공식 문서도 구매처럼 민감한 action에는 사용자 확인 dialog를 요청하는 command를 포함할 수 있다고 설명합니다.
실무 기준은 단순합니다. 읽기와 준비 작업은 먼저 열고, 쓰기와 결제 작업은 확인 단계를 둡니다.
WebMCP는 두 가지 API 방식을 제시합니다. Imperative API는 JavaScript로 form input, navigation tool, state management, function 같은 도구를 정의하는 방식입니다. Declarative API는 표준 HTML form에 annotation을 추가해 WebMCP tool을 만드는 방식입니다.
선택 기준은 UI 복잡도입니다.
Declarative API는 정형 폼에 적합합니다. 문의하기, 뉴스레터 신청, 간단한 검색처럼 입력 필드와 제출 결과가 명확한 경우 HTML annotation으로 시작하기 좋습니다. 접근성 개선과도 방향이 맞습니다. 사람이 이해하기 쉬운 폼은 에이전트에게도 설명하기 쉽습니다.
Imperative API는 상태가 복잡한 앱에 적합합니다. 날짜 선택기, 다단계 예약, 장바구니 옵션, 관리자 진단 도구처럼 단순 form submit으로 표현하기 어려운 기능은 JavaScript tool로 명시하는 편이 낫습니다. 이때는 tool이 내부 상태를 어떻게 읽고, 어떤 오류를 반환하고, 사용자 확인을 언제 요구하는지 명확히 해야 합니다.
공식 문서는 WebMCP의 제한사항도 명확히 설명합니다. tool call은 JavaScript에서 처리되므로 브라우저 탭이나 webview가 열려 있어야 합니다. 즉 headless 상태에서 agent나 assistive tool이 호출하는 구조는 지원하지 않습니다. 또한 복잡한 인터페이스에서는 상태 처리를 위해 refactor나 JavaScript 추가가 필요할 수 있습니다. tool discoverability도 페이지를 직접 방문해야 알 수 있다는 제약이 있습니다.
Permissions Policy도 중요합니다. 문서에 따르면 WebMCP API는 tools Permissions Policy로 gate되며, 기본값은 self입니다. top-level과 same-origin context에서는 tool registration을 허용하고, cross-origin iframe에서는 비활성화됩니다. cross-origin iframe에서 tool을 허용하려면 iframe에 allow="tools" 속성을 추가해야 합니다.
이 정책은 보안 기준으로 봐야 합니다. 외부 iframe에 tool 권한을 열면 해당 컨텍스트가 어떤 행동을 노출하는지 검토해야 합니다. 특히 결제, 인증, 개인정보 입력이 있는 페이지에서는 같은 출처 정책과 사용자 확인 흐름을 엄격히 유지해야 합니다.
WebMCP 문서는 Model Context Tool Inspector Extension으로 등록된 tool을 확인하고, 수동 호출하고, JSON Schema가 올바른지 검증할 수 있다고 설명합니다. 이 접근은 앞으로 웹 QA의 한 항목이 될 가능성이 큽니다.
기존 QA가 “사람이 클릭했을 때 동작하는가”를 봤다면, 에이전트 시대의 QA는 다음 질문을 추가해야 합니다.
이 검증을 자동화하면 브라우저 에이전트가 잘못된 행동을 하는 빈도를 줄일 수 있습니다.
WebMCP를 검토하는 웹앱 팀은 다음 순서로 시작하세요.
WebMCP의 핵심은 에이전트에게 더 많은 권한을 주는 것이 아닙니다. 웹앱의 의도를 구조화해 에이전트가 덜 추측하게 만드는 것입니다. 다음 스프린트에서 점검할 질문은 이것입니다. 우리 서비스의 가장 중요한 폼과 버튼은 사람뿐 아니라 에이전트에게도 의도가 명확하게 드러나고 있나요?
출처: Chrome for Developers, “WebMCP”, 2026-05-18. Chrome for Developers, “Chrome DevTools for agents”.
