WebMCP 오리진 트라이얼에 참여하세요

Chrome 149가 WebMCP 오리진 트라이얼을 제공하기 시작한 후에는 웹 페이지와 프록시 사이의 관계가 더욱 직접화됩니다. 페이지는 더 이상 시스템이 추측할 수 있도록 DOM과 가시적 사본을 배치하는 것이 아니라 컨트롤 자체도 목적, 상태 및 실행 가능 경계를 선언할 수 있습니다. 이 변경은 API 시험처럼 보이지만 실제로는 "인터페이스 의도"를 암시적 정보에서 명시적 프로토콜로 끌어올리는 것과 비슷합니다.

WebMCP와 같은 것의 가치는 웹 페이지에 용어 계층을 추가하는 것이 아니라 에이전트가 가장 두려워하는 불확실성을 강화하는 것입니다. 버튼이 제출, 전환, 확인 또는 팝업 레이어 열기인지 여부 입력 상자가 날짜인지, 검색어인지, 특별한 형식이 필요한 약속 시간인지 여부. 과거에는 이러한 정보가 주로 텍스트, 구조, 맥락에서 추론되었습니다. 추론은 작동하지만 페이지가 복잡해지면 에이전트는 '~와 유사함’을 '같음’으로 착각하기 시작합니다.

인간에게 이러한 오해는 대개 단지 잘못된 클릭일 뿐입니다. 상담원의 경우 잘못된 판독은 꾸준한 오류 경로로 변합니다. 검증, 롤백 또는 부작용이 발생할 때까지 잘못된 이해를 따라 계속 실행되며, 이로 인해 이전 단계가 잘못된 것으로 드러납니다. WebMCP가 이 의미 체계 계층을 명시적으로 만든 후에 에이전트는 페이지를 순전히 시각적 맵으로 추측할 필요가 없으며 웹 페이지는 주요 상호 작용 표면의 책임을 명확하게 설명할 수도 있습니다.

이 문제는 달력, 예약, 권한 신청, 설정 패널, 일반적인 입력 상자처럼 보이지만 실제로는 다른 비즈니스 의미를 갖는 페이지 묶음 등 순수 HTML 카피라이팅으로 설명하기 어려운 인터페이스에 가장 적합합니다. 레이블과 자리 표시자에만 의존하는 경우 에이전트는 종종 페이지를 돌아다니며 계속해서 시도해야 합니다. 페이지에서 “날짜 선택은 여기에 있습니다” “확인 작업은 여기에 있습니다” 및 "여기의 상태는 이 방향으로만 변경될 수 있습니다"라고 선언할 수 있으면 통합 비용이 직접적으로 절감됩니다.

그러나 오리진 트라이얼은 또 다른 문제도 제기합니다. 즉, 이 의미 체계 계층을 유지해야 한다는 것입니다. 페이지 구조가 변경되고, 버튼 카피가 변경되며, 비즈니스 상태가 변경됩니다. 에이전트가 실제로 의존하는 의도 계층이 구성 요소와 함께 업데이트되지 않으면 곧 표류하게 됩니다. 이때 가장 위험한 상태는 '완전히 사용할 수 없는 상태’가 아니라 '아직 실행할 수는 있지만 가끔 실수를 하고 실수는 자연스러운 것’이다.

따라서 WebMCP는 에이전트에 게시되는 알림 카드라기보다는 웹 페이지 자체에 대한 계약과 비슷합니다. 구현, 테스트 및 회귀 검사에 상호 작용 경계를 작성하려면 프런트 엔드가 필요합니다. 이 계약 계층이 아직 데모 단계에 있는 한 에이전트가 이해할 수 있는 것은 성공 사례뿐입니다. 실제 페이지에 들어갈 때 실제로 처리해야 할 것은 버전 호환성, 다운그레이드 경로 및 선언이 무효화된 후의 해결 방법입니다.

나는 이 오리진 트라이얼을 방향 신호로 간주하는 것을 선호합니다. 브라우저는 에이전트가 웹 페이지를 읽는 방법을 진지하게 고려하기 시작했습니다. 이는 프런트 엔드가 사람을 위한 형식화뿐만 아니라 시스템의 동작도 정의한다는 것을 의미합니다. 페이지가 복잡할수록 이 정의 계층의 가치는 더욱 높아집니다. 페이지가 자주 변경될수록 이 정의 계층의 유지 관리 비용이 더 커집니다. WebMCP와 같은 기능의 최종 유산은 새로운 용어가 아니라 프런트 엔드와 에이전트 간의 지속적인 정렬을 나타내는 용어가 될 것입니다.