요약: Chrome 149부터 실험되는 WebMCP는 웹페이지가 AI 에이전트에게 “이 버튼은 검색”, “이 폼은 예약”, “이 함수는 진단 실행”처럼 구조화된 도구를 직접 노출하게 만드는 제안 표준입니다. 기존 브라우저 자동화가 화면을 보고 추측했다면, WebMCP는 웹앱이 의도를 선언합니다. 개발자 관점에서는 단순한 AI 기능 추가가 아니라, 앞으로 웹 UI를 에이전트 친화적으로 설계해야 한다는 신호에 가깝습니다.
AI 에이전트가 브라우저를 조작하는 데 실패하는 이유는 모델 성능만의 문제가 아닙니다. 현재 웹 UI는 대부분 사람의 시각과 맥락을 전제로 만들어졌습니다. “다음” 버튼, 날짜 선택기, 장바구니 옵션, 필터 패널은 사람에게는 자연스럽지만 에이전트에게는 매번 해석해야 하는 픽셀과 DOM 조각입니다.
예를 들어 여행 예약 화면에서 사람은 출발지, 도착지, 날짜, 인원, 경유 조건의 의미를 한눈에 파악합니다. 하지만 에이전트는 라벨과 입력창을 찾고, 각 필드의 의미를 추론하고, 클릭 순서를 결정해야 합니다. 중간에 모달이 뜨거나 반응형 레이아웃이 바뀌면 같은 작업도 다른 문제로 변합니다. 이 방식은 데모에서는 그럴듯하지만, 실제 서비스의 결제·예약·계정 설정처럼 실패 비용이 큰 흐름에서는 불안정합니다.
WebMCP가 겨냥하는 문제는 바로 이 불확실성입니다. 웹사이트가 에이전트에게 “추측하지 말고 이 도구를 호출하라”고 알려주는 구조를 만들자는 것입니다.
WebMCP는 브라우저 기반 AI 에이전트가 웹페이지 안의 기능을 더 정확히 호출할 수 있게 하는 제안 표준입니다. 핵심은 웹앱이 JavaScript API나 HTML 폼 annotation을 통해 도구를 등록한다는 점입니다. 도구에는 이름, 입력 스키마, 실행 결과, 현재 상태가 포함될 수 있습니다.
Google Chrome 문서 기준으로 WebMCP는 크게 세 가지 축을 가집니다. 첫째, discovery입니다. 페이지가 어떤 도구를 제공하는지 브라우저와 에이전트가 발견할 수 있어야 합니다. 둘째, JSON Schema입니다. 입력값의 타입과 필수 필드를 명시해 모델의 오해를 줄입니다. 셋째, state입니다. 현재 페이지 상태와 사용 가능한 리소스를 공유해 잘못된 시점의 호출을 줄입니다.
이 구조는 기존 MCP(Model Context Protocol)의 웹 버전처럼 보이지만 차이가 있습니다. 일반 MCP 서버는 대개 앱 밖에서 도구를 제공합니다. WebMCP는 사용자가 보고 있는 실제 웹페이지 안에서 도구를 노출합니다. 그래서 호출 결과가 화면에 보이고, 사용자는 에이전트가 무엇을 하고 있는지 확인할 수 있습니다.
WebMCP가 표준으로 자리 잡으면 웹앱 설계 체크리스트가 늘어납니다. 지금은 성능, 접근성, 반응형, SEO, 보안을 기본으로 봅니다. 여기에 “에이전트가 안전하게 호출할 수 있는 도구가 있는가”가 추가될 수 있습니다.
특히 반복 작업이 많은 SaaS 관리 화면에서 효과가 큽니다. 예를 들어 고객지원 제품은 티켓 검색, 환불 요청, 계정 상태 확인 같은 도구를 WebMCP로 노출할 수 있습니다. 커머스는 장바구니 수정, 배송 옵션 비교, 쿠폰 적용을 구조화할 수 있습니다. 개발자 도구는 run_diagnostics 같은 진단 도구를 제공해 에이전트가 숨겨진 메뉴를 헤매지 않게 만들 수 있습니다.
이 변화는 단순히 “AI가 잘 쓰는 UI”를 만드는 게 아닙니다. 사람이 쓰는 화면을 유지하면서 에이전트에게 별도의 명확한 조작 경로를 제공하는 것입니다. Google 문서는 WebMCP 도구가 페이지에서 visible하게 실행되어 사용자가 신뢰할 수 있다고 설명합니다. 숨은 백엔드 API를 모델에게 직접 열어주는 것보다, 사용자가 보는 흐름 안에서 실행되는 쪽이 제품 신뢰에 유리합니다.
WebMCP는 강력하지만, 잘못 열면 위험합니다. 결제, 예약, 계정 변경, 데이터 삭제 같은 동작을 도구로 노출하면 에이전트의 오판이 실제 변경으로 이어질 수 있습니다. 그래서 민감한 액션에는 반드시 사용자 확인 단계가 필요합니다.
Chrome 문서도 구매 같은 민감한 액션에는 confirmation dialog를 포함할 수 있다고 설명합니다. 개발팀은 도구를 만들 때 최소한 네 가지를 정해야 합니다. 어떤 액션이 읽기 전용인지, 어떤 액션이 쓰기 작업인지, 어떤 작업에 사람 확인이 필요한지, 실패했을 때 rollback이나 재시도 정책은 무엇인지입니다.
기술적으로도 제약이 있습니다. WebMCP는 origin-isolated 문서에서만 사용할 수 있고, Permissions Policy의 tools 정책을 따릅니다. cross-origin iframe에서 허용하려면 allow="tools" 같은 명시 설정이 필요합니다. 즉, 표준은 처음부터 보안 경계 안에서 설계되고 있습니다. 개발자는 이를 “귀찮은 제한”이 아니라 운영 사고를 줄이는 기본 장치로 봐야 합니다.
모든 웹앱에 WebMCP를 한 번에 넣을 필요는 없습니다. 효과가 큰 곳부터 실험하면 됩니다. 추천 순서는 폼 기반 업무, 복잡한 필터, 진단 도구, 관리자 작업입니다.
폼 기반 업무는 입력 스키마가 명확하므로 WebMCP와 잘 맞습니다. 예를 들어 submit_application 도구는 이름, 이메일, 회사명, 문의 유형처럼 필드를 명확히 받을 수 있습니다. 복잡한 필터도 좋습니다. 에이전트가 DOM을 해석해 체크박스를 찾는 대신 filter_results 도구에 가격 범위, 지역, 날짜를 넘기게 하면 실패율이 줄어듭니다.
관리자 화면은 더 조심해야 하지만 가치가 큽니다. 고객 계정 조회, 로그 검색, 상태 진단, 설정 추천처럼 읽기 중심 도구부터 열면 됩니다. 쓰기 작업은 초기에 제외하고, 충분한 로깅과 확인 UI가 준비된 뒤 제한적으로 추가하는 편이 안전합니다.
기존 SEO는 사용자가 검색 결과를 클릭해 페이지에 들어오는 흐름을 전제로 합니다. 하지만 에이전트 시대에는 사용자가 “내 환불 상태 확인해줘”, “다음 주 부산 출장 예약해줘”라고 요청하고, 에이전트가 여러 사이트를 조작하는 흐름이 커집니다. 이때 사이트가 에이전트에게 구조화된 도구를 제공하면 작업 완료율에서 앞설 수 있습니다.
이건 검색 순위와 별개로 중요한 경쟁력입니다. 같은 상품을 파는 두 사이트가 있을 때, 한쪽은 에이전트가 12단계 클릭을 추측해야 하고 다른 쪽은 checkout, apply_coupon, confirm_shipping 도구를 제공합니다. 사용자는 더 적게 실패하는 쪽을 선택하게 됩니다. 장기적으로는 에이전트 친화성이 전환율, 고객지원 비용, 재방문에 영향을 줄 수 있습니다.
출처: Chrome for Developers WebMCP 문서, Google I/O 2026 Developer keynote recap.
