요약: WebMCP는 브라우저 기반 AI 에이전트가 버튼과 폼을 눈치로 해석하지 않고, 웹사이트가 제공한 구조화된 도구를 호출하도록 만드는 제안 표준이다. Chrome 149 origin trial 예정이며, JavaScript imperative API와 HTML form annotation 방식이 제공된다. 웹 서비스를 운영하는 팀이라면 “AI가 우리 사이트를 잘 클릭하길 바라는 것”보다 “AI가 호출할 수 있는 명확한 작업 계약을 제공하는 것”이 더 중요해진다.
검색 의도: WebMCP, AI 에이전트 웹사이트 연동, 브라우저 AI 에이전트, 웹 폼 자동화 표준
현재 AI 에이전트가 웹사이트를 조작하는 방식은 대부분 사람 화면을 흉내 내는 방식이다. 버튼 텍스트를 읽고, DOM 구조를 추측하고, 입력 필드를 찾아서 값을 넣고, 다음 화면으로 넘어간다. 간단한 페이지에서는 그럭저럭 동작하지만 복잡한 웹앱에서는 쉽게 실패한다.
예를 들어 여행 예약 사이트에서 출발지, 도착지, 날짜, 승객 수, 좌석 등급, 경유 조건을 입력해야 한다고 하자. 사람은 UI의 맥락을 이해하지만 에이전트는 필드의 의미를 헷갈릴 수 있다. name이 성인지 전체 이름인지, date picker가 어떤 포맷을 받는지, 결제 버튼이 실제 구매인지 견적 조회인지 명확하지 않으면 실패한다.
WebMCP는 이 문제를 줄이기 위한 제안이다. 웹사이트가 에이전트에게 “이 페이지에는 이런 도구가 있고, 입력은 이런 JSON Schema를 따르며, 결과는 이렇게 반환된다”고 알려준다. 에이전트는 화면을 추측하지 않고 등록된 도구를 호출한다.
이 접근은 SEO의 구조화 데이터와 비슷하다. 사람에게 보이는 화면은 그대로 두되, 기계가 이해할 수 있는 계약을 추가한다. 차이는 검색 엔진이 아니라 사용자 에이전트가 실제 작업을 수행한다는 점이다.
첫 번째 문제는 정확도다. 에이전트가 UI 요소를 해석하는 단계가 많을수록 실패 지점도 늘어난다. “이 버튼이 검색인지 제출인지”, “이 select가 필수인지 선택인지”, “이 input이 전화번호인지 인증번호인지”를 매번 추측하면 안정성이 낮다. WebMCP는 도구 이름과 schema로 목적을 명시한다.
두 번째 문제는 사용자 신뢰다. 웹사이트 밖에서 headless 자동화가 몰래 실행되는 것보다, 사용자가 보고 있는 브라우저 탭 안에서 도구가 실행되는 편이 더 투명하다. Chrome 문서도 WebMCP 도구가 웹페이지에서 visible하게 실행되어 사용자가 작업을 확인할 수 있다는 점을 강조한다.
세 번째 문제는 민감 작업 승인이다. 구매, 예약, 신청서 제출 같은 작업은 자동으로 끝내면 위험하다. WebMCP는 confirmation dialog 같은 사용자 상호작용을 설계할 수 있게 한다. 에이전트가 폼을 채우는 것과 최종 제출은 다르게 다뤄야 한다.
네 번째 문제는 브랜드와 UX 유지다. 에이전트가 외부 API를 직접 호출하면 서비스가 설계한 화면 흐름을 우회할 수 있다. WebMCP는 기존 human-first interface 안에서 도구를 노출하기 때문에 사용자 경험과 정책을 유지하기 쉽다.
처음부터 결제나 계정 삭제 같은 위험한 기능을 노출하지 않는 편이 좋다. WebMCP의 초기 적용 대상은 반복적이고 구조화되어 있으며 실패 비용이 낮은 작업이 적합하다.
좋은 후보는 다음과 같다.
반대로 조심해야 할 후보는 다음과 같다.
이런 작업은 WebMCP로 노출하더라도 최종 단계에 명시적 사용자 확인을 둬야 한다. 에이전트가 할 일은 “대신 결정”이 아니라 “정확히 준비하고, 사용자가 확인하게 만드는 것”이다.
WebMCP 도구를 만들 때 가장 중요한 것은 이름이다. submit 같은 이름은 약하다. search_available_flights, fill_support_ticket, run_workspace_diagnostics처럼 대상과 행동이 드러나는 이름이 좋다. 에이전트는 도구 이름에서 많은 힌트를 얻는다.
입력 schema는 더 구체적이어야 한다. 예를 들어 지원 문의 도구라면 다음 정보를 명확히 나눈다.
날짜와 시간은 특히 조심해야 한다. date라고만 두면 지역, 포함 여부, 포맷이 애매하다. YYYY-MM-DD, timezone, start/end 포함 여부를 써야 한다. 가격, 수량, 좌석 수처럼 단위가 있는 값도 마찬가지다.
출력도 구조화한다. 단순 문자열보다 status, warnings, next_required_action, visible_confirmation_required 같은 필드를 두면 에이전트가 후속 응답을 안정적으로 만들 수 있다.
WebMCP는 progressive enhancement로 접근하는 것이 좋다. 기존 화면을 갈아엎지 말고, 에이전트가 자주 실패하는 흐름부터 도구를 붙인다.
1단계는 관찰이다. 사용자가 AI 에이전트로 어떤 작업을 시도할지 가정하고, 현재 UI에서 헷갈릴 지점을 찾는다. 복잡한 date picker, multi-step form, nested menu, 숨겨진 diagnostics 버튼이 후보가 된다.
2단계는 읽기 전용 도구다. 예를 들어 get_available_filters, get_current_booking_state, get_form_requirements처럼 현재 상태를 설명하는 도구를 먼저 만든다. 쓰기 작업보다 위험이 낮고, 에이전트의 이해도를 높인다.
3단계는 초안 작성 도구다. 폼 값을 채우되 최종 제출은 하지 않는다. 사용자가 화면에서 확인하고 직접 제출하게 한다.
4단계는 제한된 실행이다. 실패 비용이 낮고 rollback이 쉬운 작업만 실행까지 허용한다. 이때 audit log와 confirmation UI가 필요하다.
WebMCP는 API 테스트만으로 충분하지 않다. 도구가 정상 응답을 해도 에이전트가 올바른 상황에서 호출하지 않으면 실패다. 따라서 자연어 프롬프트 기반 테스트가 필요하다.
예시는 다음과 같다.
각 테스트에는 기대 행동을 적는다. 어떤 도구를 호출해야 하는지, 어떤 파라미터가 들어가야 하는지, 어떤 도구를 호출하면 안 되는지, 사용자 확인이 필요한지 명확히 둔다.
Chrome의 WebMCP inspector extension 같은 도구를 사용하면 등록된 도구와 JSON Schema를 확인하고, 도구 호출 결과가 에이전트에게 이해 가능한지 점검할 수 있다.
WebMCP의 핵심은 AI 에이전트에게 웹을 마음대로 클릭하게 하는 것이 아니다. 웹앱이 “안전하게 호출 가능한 작업 계약”을 제공하는 것이다. 이 차이를 이해하고 설계하면 에이전트 자동화는 불안정한 스크래핑이 아니라 제품 기능의 일부가 된다.
