브라우저 에이전트가 웹페이지에서 일을 시키는 장면을 떠올리면 보통 화면을 읽고, 버튼과 입력창을 찾고, 클릭하는 흐름을 생각하게 된다. 사람에게는 자연스럽지만 자동화에는 불안정한 방식이다. 레이아웃이 바뀌면 선택 기준이 흔들리고, 여러 단계의 폼에서는 모델이 각 요소의 의미를 다시 추측해야 한다.
최근 WebMCP가 다시 눈에 들어오는 이유는 이 추측 구간을 줄이려 하기 때문이다. WebMCP는 웹 애플리케이션이 검색, 목록 조회, 예약 요청처럼 할 수 있는 일을 구조화된 도구로 등록하는 자바스크립트 인터페이스다. 8월 25일 ChatGPT 데스크톱 내장 브라우저에도 Site tools라는 이름으로 이 방식의 지원이 추가됐다. 페이지가 제공한 도구를 ChatGPT Work와 Codex가 발견하고 호출할 수 있다는 변화다.
이 글은 WebMCP가 곧바로 모든 웹 자동화를 대체한다는 이야기가 아니다. 아직 제안 단계인 API를 실제 서비스에 붙일지 판단할 때, 무엇을 작게 시험하고 어디에서 멈춰야 하는지 정리한 기록이다.
화면을 읽는 자동화와 기능을 호출하는 자동화의 차이
기존 브라우저 자동화는 사람이 하듯 화면 요소를 찾아 행동한다. DOM 선택자나 스크린샷, 접근성 트리, 비전 모델을 쓸 수 있지만, 에이전트 입장에서는 “이 버튼이 정확히 무엇을 하는가”를 문맥으로 해석해야 하는 순간이 남는다.
WebMCP에서는 사이트가 그 의미를 먼저 선언한다. 도구에는 이름, 설명, 입력값을 정의한 JSON Schema, 실행 함수가 들어간다. 예를 들어 고객지원 화면이라면 search_ticket이나 get_ticket_status 같은 읽기 도구를 제공할 수 있다. 에이전트는 화면의 모양 대신 이 계약을 보고 필요한 인수와 예상 결과를 판단한다.
Chrome 개발자 문서는 이런 방식이 에이전트의 작업 수행 정확도와 신뢰성을 높일 수 있다고 설명한다. 웹페이지가 버튼과 필드의 목적을 명시하므로, 여러 클릭을 거치며 의미를 추측하는 것보다 해석 여지가 줄어든다는 뜻이다. 도구 실행은 페이지 안에서 보이게 이뤄지는 것을 목표로 하므로, 사용자가 같은 화면에서 진행 상황을 확인하는 설계도 가능하다.
여기서 중요한 것은 WebMCP가 별도 백엔드 MCP 서버를 자동으로 만드는 기능이 아니라는 점이다. W3C Web Machine Learning Community Group의 초안은 웹페이지의 클라이언트 측 자바스크립트가 도구를 등록하고, 에이전트가 이를 호출하는 구조를 설명한다. 기존 화면 로직과 상태를 재사용할 수 있지만, 그만큼 프런트엔드에 공개하는 기능의 범위도 다시 설계해야 한다.
이번 변화가 실무에 주는 신호
8월 27일 공개된 독립 구현 사례에서는 TODO 웹앱이 목록 조회, 추가, 완료, 삭제를 각각 도구로 등록했다. Codex는 먼저 읽기 전용 목록 조회 도구를 호출해 대상의 ID를 확인한 뒤 완료 처리 도구를 실행했다. 삭제처럼 상태를 바꾸는 작업 전에는 사용자 확인이 요구됐다.
이 사례에서 배울 점은 모델이 더 똑똑해졌다는 데 있지 않다. 애플리케이션이 작업을 작은 동사로 나누고, 입력과 결과를 정해 두면 검토 지점도 선명해진다는 데 있다. 사내 운영 화면, 개인 NAS 관리 도구, 고객 문의 정리처럼 사람이 이미 같은 UI를 쓰는 서비스라면 특히 현실적인 방향이다. 에이전트용 별도 API를 처음부터 크게 만들지 않고, 사람이 쓰는 기능 중 일부를 제한된 도구로 드러내는 실험이 가능하다.
다만 기존 글에서 다뤘던 ‘에이전트가 웹을 읽을 수 있는가’와는 다른 문제다. 발견 가능성이나 문서 구조를 점검하는 단계 다음에는, 실제로 어떤 동작을 어떤 인수로 실행하도록 허용할지 결정해야 한다. WebMCP는 웹사이트의 가독성을 높이는 체크리스트가 아니라 행동 계약을 추가하는 선택에 가깝다.
읽기 전용 표시는 권한 통제가 아니다
도구를 도입할 때 가장 조심할 부분도 분명하다. WebMCP 초안에는 읽기 전용 힌트와 신뢰할 수 없는 콘텐츠 힌트 같은 주석이 있다. 하지만 이는 에이전트가 판단할 때 참고하는 힌트이지, 실행 함수가 실제로 상태를 바꾸지 못하게 막는 권한 장치가 아니다. 독립 사례도 악성 페이지가 읽기 전용으로 표시한 도구에서 상태 변경 코드를 실행할 수 있다고 지적한다.
따라서 도구 이름, 설명, JSON Schema만 보고 안전하다고 판단하면 안 된다. 상태 변경 함수는 서버 쪽 권한 검사와 감사 로그를 그대로 거쳐야 한다. 금액 결제, 데이터 삭제, 메시지 발송, 권한 변경처럼 되돌리기 어려운 일은 페이지 내부의 확인 창 하나로 끝내지 말고 대상과 변경 내용을 다시 보여 주고 별도 승인을 받는 편이 낫다.
호환성도 아직 제한적이다. Chrome 문서는 WebMCP를 제안 표준으로 소개하며 Chrome 149부터 Origin Trial 참여 경로를 안내한다. 로컬 개발에서는 플래그를 켜서 시험할 수 있지만, 헤드리스 환경보다 사람과 함께 쓰는 로컬 브라우저 흐름을 주된 대상으로 설명한다. 원본 초안도 W3C 표준 트랙의 확정 사양이 아니며 변경될 수 있다. 운영 기능의 유일한 자동화 경로로 삼기에는 이르다.
작게 검증하려면 이렇게 시작한다
- 조회 기능 하나만 고른다. 먼저 장애 현황 조회, 티켓 목록 검색, 배포 상태 확인처럼 결과가 읽기 전용인 기능을 하나 고른다. 사람 UI와 도구 호출이 같은 결과를 내는지 테스트 케이스로 비교한다.
- 도구 계약을 좁힌다. 이름은 동사와 대상을 드러내고, 입력 JSON Schema에는 허용값과 필수값을 구체적으로 둔다. 자유 텍스트 하나로 여러 작업을 처리하는 만능 도구보다
get_deployment_status처럼 좁은 도구가 검토하기 쉽다. - 변경 작업은 별도 경계로 둔다. 변경 전 현재 상태를 다시 조회하고, 대상 식별자와 예상 변경을 사용자에게 보여 준다. 서버 권한 검사, 감사 로그, 재시도 시 중복 실행 방지까지 기존 API 수준으로 확인한다.
도구가 생겨도 책임은 페이지에 남는다
WebMCP가 널리 자리 잡는다면 브라우저 에이전트는 화면을 더 적게 추측하고, 사이트가 제공하는 기능 계약을 더 많이 읽게 될 수 있다. 이는 반복 클릭을 줄일 기회다. 동시에 웹 애플리케이션 운영자에게는 어떤 기능을 에이전트에게 발견시키고 실행시키는지 더 명확하게 설계하라는 요구이기도 하다.
지금 할 수 있는 가장 현실적인 선택은 실험 기능을 하나 정해 사람의 UI, 도구 호출, 서버 로그를 나란히 비교해 보는 것이다. 성공률만 보지 말고 잘못된 인수, 세션 만료, 권한 부족, 취소 요청에서 어떤 결과가 남는지도 확인해야 한다. 화면 자동화의 불확실성을 줄이는 일은 가능하지만, 작업의 책임과 승인까지 자동으로 줄어들지는 않는다.