웹사이트가 에이전트의 도구가 된다: 크롬 149 WebMCP 오리진 트라이얼, 스크린샷 루프 대신 함수 호출

구글이 WebMCP를 크롬 실험 플래그에서 꺼내 공개 오리진 트라이얼로 올렸다. 크롬 팀은 전환을 5월 19일 확정했고 문서는 하루 앞선 5월 18일 공개했다. 트라이얼 구간은 크롬 149부터 156까지다. 지금 개발자는 자기 사이트에서 이 기능을 켜고 브라우저 에이전트에게 실제 작업을 시켜볼 수 있다.

WebMCP는 사이트가 자기 자바스크립트 함수와 주석 단 HTML 폼을 도구로 선언하게 하는 제안 표준이다. 도구마다 입력, 출력, 부작용을 기술한 구조화 스키마가 붙는다. 페이지 안의 AI 에이전트는 그 선언을 읽고 함수를 호출한다.

차이를 실감하려면 지금 방식을 떠올리면 된다. 브라우저 에이전트는 화면을 스크린샷으로 찍고, 버튼이 어디 있는지 픽셀로 추측하고, 클릭하고, 다시 찍는 루프를 돈다. 느리고 자주 어긋난다. WebMCP에서는 함수 호출 한 번으로 끝난다. 픽셀 사냥이 사라진다. 게다가 에이전트는 사이트가 선언하지 않은 함수는 부를 수 없다. 속도, 신뢰성, 안전이 한꺼번에 올라간다.

한눈에 보기

공개	크롬 149 공개 오리진 트라이얼 (구간 149~156)
방식	사이트가 JS 함수, HTML 폼을 스키마와 함께 도구로 선언
이점	스크린샷 루프 대신 함수 호출 1회, 미선언 도구 호출 차단
초기 실험	Expedia, Booking.com, Shopify, Etsy, Instacart, Target 등
표준화	W3C Web Machine Learning 커뮤니티 그룹, 구글, 마이크로소프트 참여

스크린샷 루프가 함수 호출로 바뀐다

지금 브라우저 자동화의 병목은 인식이다. 에이전트가 화면을 보고, 요소를 찾고, 좌표를 추정하는 단계마다 오차가 쌓인다. 레이아웃이 조금만 바뀌어도 클릭이 빗나간다. 그래서 실제 상거래나 예약처럼 돈이 걸린 작업에는 못 맡겼다.

WebMCP는 이 인식 단계를 통째로 건너뛴다. 사이트가 "검색", "장바구니 담기", "결제 시작" 같은 동작을 스키마 붙은 함수로 미리 내놓으면, 에이전트는 화면을 해석할 필요 없이 그 함수를 호출한다. 한 번의 호출이 스크린샷 루프 수십 회를 대체한다. 실패 지점이 줄고, 같은 작업을 반복해도 결과가 일정하다.

안전 모델도 여기서 나온다. 에이전트가 실행할 수 있는 행동은 사이트가 선언한 도구 목록으로 제한된다. 선언하지 않은 기능은 존재조차 하지 않는 셈이라, 임의의 버튼을 눌러 예상 못 한 부작용을 일으킬 여지가 좁아진다.

도구 표면이 곧 에이전트용 API다

초기 실험 명단이 방향을 말해 준다. Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart, Target. 예약, 커머스, 세금, 부동산처럼 사용자의 행동이 곧 매출인 서비스들이다. 이들은 에이전트가 자기 사이트에서 정확히 행동하기를 원한다. 트래픽의 상당 부분이 사람이 아니라 대리 에이전트로 옮겨 갈 때, 그 에이전트가 실수 없이 예약을 완료하고 결제를 마치게 만드는 쪽이 이긴다.

표준화 경로는 아직 초입이다. 스펙은 W3C의 Web Machine Learning 커뮤니티 그룹에서 구글과 마이크로소프트가 함께 다듬고 있다. 정식 권고까지는 몇 달이 아니라 몇 년 단위로 봐야 한다. 지금은 확정된 규격이 아니라 실측 단계다. 그래도 오리진 트라이얼이 열렸다는 건, 프로덕션 코드에 붙여 실제 트래픽으로 검증할 창구가 생겼다는 뜻이다.

서버 쪽 도구 연결과 무엇이 다른가

혼동하기 쉬운 지점을 짚자. 그동안 에이전트가 외부 기능을 쓰는 통로는 주로 서버 쪽 커넥터였다. 별도 서버가 도구를 노출하고, 에이전트가 그 서버에 붙어 호출하는 구조다. WebMCP는 이걸 페이지 안으로 끌어들인다. 사용자가 이미 로그인해 열어 둔 그 웹페이지가, 자기 세션과 권한을 그대로 가진 채 도구를 내놓는다.

차이가 실무에서 크다. 별도 서버를 세우고 인증을 다시 붙일 필요 없이, 프런트엔드 코드에 함수를 선언하는 것만으로 에이전트가 접근할 도구가 생긴다. 사용자의 로그인 상태, 장바구니, 세션 컨텍스트가 페이지에 이미 있으니 에이전트는 그 위에서 바로 행동한다. 서버 커넥터가 백엔드 통합이라면, WebMCP는 사용자가 보고 있는 화면 그 자체를 도구로 바꾸는 접근이다.

물론 한계도 분명하다. 원본 사이트가 도구를 선언해야만 성립한다. 사이트가 아무것도 내놓지 않으면 에이전트는 여전히 스크린샷 루프로 돌아간다. 그래서 이 표준의 성패는 브라우저 기능이 아니라, 얼마나 많은 사이트가 자기 동작을 도구로 공개하느냐에 달려 있다. 초기 실험에 커머스와 예약 대기업이 몰린 것도 그래서다. 이들은 에이전트 트래픽을 놓칠 때 잃을 매출이 가장 크다.

anyAX 관점

에이전트는 사이트가 선언한 도구만 부를 수 있다. 이 한 문장이 이번 발표의 무게다. 앞으로 웹사이트에는 사람이 보는 화면과 별개로, 에이전트에게 내놓는 도구 표면이 생긴다. 그 표면을 어떻게 설계하느냐가 사이트가 에이전트 트래픽을 받을 수 있는지를 가른다.

여기서 1인 SaaS 개발자와 인디 메이커의 위치가 뒤집힌다. Expedia나 Target은 수백 개 화면과 레거시를 가진 채로 도구 표면을 정리해야 한다. 반면 페이지 몇 개짜리 서비스는 핵심 동작 서너 개, 이를테면 "예약 조회", "구독 생성", "리포트 내보내기"를 깨끗한 스키마로 지금 선언할 수 있다. 크롬 149~156이라는 트라이얼 창이 열려 있는 동안, 규모가 작을수록 오히려 먼저 에이전트 대응을 끝낼 수 있다.

그러니 이번 트라이얼은 구경거리가 아니라 설계 과제다. 내 제품에서 에이전트가 대신 해 주면 사용자가 가장 반길 동작이 무엇인지, 그중 부작용이 큰 것(결제, 삭제)은 어떻게 확인 절차를 붙일지, 이걸 지금 정해 두는 팀이 표준이 굳는 몇 년 뒤에 유리한 자리에 선다. 신뢰와 리스크를 먼저 설계한 도구 표면이 나중에 트래픽을 부른다.