AI 에이전트에게 “다음 주 월요일 뉴욕행 가장 저렴한 항공권 예약해줘”라고 말하면 어떻게 될까요? 에이전트는 항공사 웹사이트에 접속해서 날짜 선택기를 찾고, 각 입력 필드가 무엇을 의미하는지 추측하고, 날짜 형식이 맞기를 바라며 폼을 채웁니다. 마치 화면을 보면서 버튼을 찾아 클릭하는 것처럼요. 하지만 이제 웹사이트가 에이전트에게 직접 “이 폼은 항공권 예약용이고, 출발지·목적지·날짜·승객 수가 필요해”라고 말할 수 있게 됐습니다.
구글 크롬팀이 2월 10일 WebMCP(Web Model Context Protocol)를 얼리 프리뷰 프로그램으로 공개했습니다. WebMCP는 웹사이트가 AI 에이전트에게 자신의 기능을 구조화된 “도구”로 노출하는 새로운 웹 표준입니다. 기존 HTML 폼에 몇 가지 속성만 추가하면 에이전트가 이해하고 실행할 수 있는 도구로 자동 변환됩니다.
출처: WebMCP is available for early preview – Chrome for Developers
화면 스크래핑에서 구조화된 대화로
현재 AI 에이전트가 웹사이트와 상호작용하는 방식은 비효율적입니다. DOM을 분석하고 버튼이 무엇을 하는지 추측하고, 폼 필드의 용도를 유추해야 하죠. WebMCP는 이런 모호함을 제거합니다.
WebMCP는 두 가지 API를 제안합니다:
Declarative API는 기존 HTML 폼을 활용합니다. toolname, tooldescription, toolparamdescription 같은 속성을 추가하면 브라우저가 자동으로 폼을 구조화된 도구로 변환합니다. 에이전트가 도구를 호출하면 브라우저는 폼을 화면에 띄우고, 필드를 채우고, 사용자 확인을 기다립니다(자동 제출 활성화 시 제외). 시각적으로 무슨 일이 일어나는지 볼 수 있고, CSS 가상 클래스(:tool-form-active)로 스타일링도 가능합니다.
Imperative API는 JavaScript를 사용합니다. navigator.modelContext.registerTool()로 도구를 등록하고, 이름·설명·JSON 입력 스키마·실행 콜백을 정의하면 됩니다. 복잡하고 동적인 상호작용이 필요한 경우에 적합합니다.
항공권 예약을 예로 들면, 웹사이트는 book_flight라는 도구를 정의하고 “출발지, 목적지, 날짜, 승객 수를 주세요. 받을 수 있는 형식은 이렇습니다”라고 명시합니다. 에이전트는 더 이상 캘린더 피커가 어떻게 작동하는지 알아낼 필요가 없습니다.
구글만의 기능이 아닌 오픈 웹 표준
WebMCP는 모델에 구애받지 않습니다. Gemini Nano의 온디바이스 기능과는 별개이며, 데모 확장 프로그램은 실제로 API를 통해 Gemini 2.5 Flash를 사용합니다. Gemini든, Claude든, GPT든, 오픈소스 모델이든 브라우저를 통해 작동하는 모든 에이전트가 이 도구를 발견하고 사용할 수 있도록 설계됐습니다.
이건 브라우저 레벨의 표준이지, 특정 모델의 기능이 아닙니다. GitHub의 WebMCP 저장소를 보면 Web Machine Learning Community Group이 개발 중이며, 오픈 웹 표준으로 진행되고 있음을 알 수 있습니다.
웹사이트에서 에이전트로, 새로운 방향의 표준
에이전트 UI 생태계에는 최근 여러 표준이 등장했습니다. Google의 A2UI, Anthropic과 OpenAI가 지원하는 MCP Apps 같은 것들이죠. 하지만 이들은 모두 “에이전트가 사용자에게 UI를 보여주는” 방향입니다. 에이전트가 대화 중 필요한 폼이나 위젯을 동적으로 생성하는 거죠.
WebMCP는 정반대 방향입니다. 웹사이트가 에이전트에게 “내가 할 수 있는 일”을 알려주는 겁니다. 항공사 사이트가 이미 가지고 있는 예약 기능을, 에이전트가 발견하고 사용할 수 있게 만드는 거예요. 기존 웹을 에이전트가 읽고 쓸 수 있는 공간으로 바꾸는 겁니다.
에이전트 최적화, 새로운 기술 SEO의 탄생
SEO는 검색 엔진이 웹사이트를 이해할 수 있도록 구조화된 신호를 제공하면서 생겨났습니다. 사이트맵, robots.txt, 캐노니컬 태그, schema.org, 메타 설명. 이런 것들은 크롤러가 웹사이트를 “읽을 수 있게” 만들었고, 이를 최적화하는 전문 분야가 형성됐습니다.
WebMCP는 같은 패러다임 전환의 시작입니다. 다만 이번엔 검색 크롤러가 아니라 AI 에이전트를 대상으로 합니다.
도구 발견 가능성(Tool Discoverability)은 새로운 인덱싱 문제입니다. 공식 문서도 이를 미해결 한계로 명시하고 있습니다. 현재로선 에이전트가 사이트를 직접 방문하기 전까지는 어떤 사이트에 도구가 있는지 알 수 없습니다. 검색 엔진이나 디렉토리가 이 격차를 메울 것으로 예상되며, 그때가 오면 도구를 발견 가능하고 선호되도록 만드는 것 자체가 하나의 분야가 될 겁니다.
도구 설명(Tool Description)은 새로운 메타 설명입니다. 도구의 name, description, 스키마 품질이 에이전트가 그 도구를 선택할지 결정합니다. 공식 문서의 모범 사례 섹션을 보면 전환율 카피라이팅 가이드처럼 읽힙니다. 명확한 동사를 사용하고, 옵션의 “이유”를 설명하고, 긍정적 표현을 선호하라고요. 다만 독자는 검색 결과를 훑어보는 사람이 아니라 어떤 도구를 호출할지 결정하는 언어 모델입니다.
만약 거래가 에이전트를 통해 이뤄지기 시작한다면, 잘 구조화된 WebMCP 도구를 가진 웹사이트가 그 트래픽을 가져갈 겁니다. 도구가 없는 사이트는 에이전트의 선택지에조차 들지 못할 테고요. 이런 압박은 낯설지 않습니다. SEO 산업을 만든 것과 똑같은 압박이니까요.
WebMCP는 현재 Chrome 146에서 플래그 뒤에서 사용 가능하며, 얼리 프리뷰 프로그램 참가자들에게 프로토타입 제작용으로 공개됐습니다.
참고자료:
답글 남기기