WebMCP란 무엇인가: 웹사이트를 AI 에이전트를 위해 준비하는 방법

핵심

**WebMCP(웹 모델 컨텍스트 프로토콜)**는 구글과 마이크로소프트가 공동 개발한 제안된 개방형 웹 표준으로, 웹사이트가 AI 에이전트에게 "상품 검색", "테이블 예약", "결제 시작" 같은 구조화된 도구를 직접 호출할 수 있도록 해준다. 현재 웹사이트는 사람을 위해 설계되었지만, 에이전트는 시각적 레이아웃을 잘 처리하지 못해 상호작용 방식을 추측해야 하므로 느리고 오류가 발생하기 쉽다.

WebMCP란 무엇인가

• 도구의 정의: WebMCP 맥락에서 도구는 별도의 소프트웨어, 플러그인, 새로운 백엔드 데이터베이스가 아니다. 체크아웃 양식이나 검색 바 같은 웹페이지의 기존 요소에 직접 연결된 간단한 HTML 속성이나 몇 줄의 자바스크립트로 추가된 작은 지시문 집합이다.
• 프론트엔드 기반: 이 도구들은 사용자의 브라우저로 배포되는 프론트엔드 코드에만 존재하며, 해당 웹페이지가 열려있고 활성화된 동안에만 존재한다. 기본적으로 사이트의 기존 버튼과 양식에 보이지 않는 라벨을 추가하여 AI에게 무엇을 해야 하고 어떤 데이터가 필요한지 알려주는 것이다.
• 인프라 불필요: 도구가 이미 있는 사이트 위에 앉아있으므로 재구축이나 별도의 백엔드 유지가 필요하지 않다.

기존 에이전트 방식의 문제점

현재 대부분의 브라우저 에이전트는 사람이 하는 방식을 시뮬레이션하여 페이지를 읽는데, 스크린샷을 찍어 가능한 동작을 식별하고 문서 객체 모델(DOM)과 접근성 트리를 읽는다. 이는 시간이 많이 걸리고 결과가 일관성 없다.

WebMCP는 에이전트에게 더 빠르고 신뢰할 수 있는 경로를 제공한다. 도구가 존재하면 에이전트가 직접 호출할 수 있고, 없으면 여전히 기존 방법으로 돌아갈 수 있으므로 도구를 추가해도 특정 방식에 묶이지 않는다.

WebMCP와 전통적 MCP의 차이

• 전통적 MCP: 백엔드 데이터와 시스템에서 가치가 있을 때 최적화되어 있다(Moz 데이터, Salesforce, 내부 데이터베이스 같은). 그러나 서버를 구축하고 실행해야 하므로 실질적인 작업이 필요하다.
• WebMCP: 나머지 웹, 즉 사람들이 원시 데이터를 가져오는 대신 작업을 완료하는 곳에 맞추어진다. 항공사, 레스토랑, 전자상거래 스토어, SaaS 가입에 이르는 모든 것을 다룬다.
• 상호보완성: 두 표준을 경쟁 관계로 보는 경향이 있지만 서로 다른 문제를 해결하며 실제로는 서로 보완한다. 많은 조직이 둘 다 사용하게 될 것이다. MCP는 백엔드 작업을 처리하고 WebMCP는 페이지 내 작업을 처리한다. 둘 다 이름, 설명, 입력 스키마, 핸들러 같은 동일한 구성 요소를 공유한다.

SEO 담당자가 WebMCP를 주목해야 하는 이유

• 에이전트의 실제 사용: 에이전트는 이제 웹사이트를 읽을 뿐만 아니라 실제로 사용하고 있다. 테이블을 예약하거나 결제를 실행하며, WebMCP가 이러한 동작을 돕는 방법이다. 이는 이러한 동작이 SEO 담당자의 범위 내에 있음을 의미한다.
• 기존 SEO 기술의 연장: 깔끔한 구조, 견고한 마크업, 구조화된 데이터를 통해 사이트를 기계가 읽을 수 있게 유지하는 것은 이미 직무의 일부다. WebMCP는 이러한 동일한 기술을 적용하여 에이전트에게 페이지가 무엇을 할 수 있는지, 어떻게 트리거하는지 알려준다.
• AI 검색 최적화와의 구분: 이는 AI 생성 답변에 나타나는 것과는 별개다. 그것은 발견(discovery)이며 AI 검색 최적화가 다루는 것이다.
• 전환의 중요성: WebMCP는 에이전트가 페이지에 도착한 후에 작동한다. 에이전트가 예약 양식을 스크린샷으로 찍고 결제 과정에서 실수하면 마지막 단계에서 판매가 실패한다. 제대로 구현하면 양방향의 이득이 있다: 모든 웹사이트를 에이전트를 위한 고성능 API로 변환하면서 동시에 사이트 사용자를 위한 놀라운 사용자 경험을 만들 수 있다.

WebMCP 도구의 일반적 사용 사례

• 전자상거래: 상품 검색, 크기나 가격별 필터링, 장바구니에 추가, 결제 시작
• 여행 및 숙박: 한 번의 요청으로 테이블, 객실 또는 항공편 예약
• SaaS: 가입 시작, 요금제 선택, 앱 내 작업 실행
• 지역 및 전문 서비스: 견적 요청 또는 약속 예약
• 리드 생성 및 출판: 뉴스레터 가입 및 연락처 양식

WebMCP 작동 방식

에이전트는 웹사이트에 도착하여 제공되는 WebMCP 도구를 발견하고, 각각이 무엇을 하는지 읽고, 작업에 맞는 도구를 호출한다.

두 가지 설정 방법

선언적 API(HTML)

• 이미 양식에 있는 동작을 위한 가장 간단한 구현이다. 예: 예약, 가입, 연락처 요청
• 구현하려면 이미 있는 양식에 몇 가지 속성을 추가하면 된다:
  • toolname: 도구에 이름을 부여(예: toolname="search_products")
  • tooldescription: 에이전트에게 동작이 무엇을 하고 언제 사용하는지 설명하는 일반 언어 문장(예: tooldescription="Search the catalog by keyword")
  • toolparamdescription: 각 입력에 추가되어 에이전트에게 그 필드가 어떤 값을 예상하는지 알려줌(예: toolparamdescription="The search term, e.g. red shoes")
• 기본적으로 자신의 사이트만 사용할 수 있다.

예제 워크스루: 구글의 르 쁘띠 비스트로 데모를 모델 컨텍스트 도구 인스펙터(Model Context Tool Inspector) 열기와 함께 로드했다. 이는 페이지가 등록한 도구를 나열하고 프롬프트를 입력한 후 Gemini 기반 테스트 에이전트가 도구를 호출하는 것을 볼 수 있는 Chrome 확장 프로그램이다. Gemini API 키가 필요하다(무료 계층 사용 가능).

데모는 하나의 예약 양식을 가진 레스토랑 예약 페이지다. 필드에는 이름, 전화번호, 날짜 및 시간 등이 포함된다. 양식은 인스펙터에 스키마 전체와 함께 등록된 도구로 표시되었다. 패널은 에이전트가 사이트에서 볼 수 있는 정확히 어떤 WebMCP 도구를 보여준다.

도구는 데모의 기존 양식에 몇 가지 속성 때문에 인스펙터에 있으며, 이것이 선언적 API가 요구하는 모든 것이다.

프롬프트를 작성하고 도구를 실행한 후 양식이 페이지에서 필드별로 채워지는 것을 봤다. 프롬프트는: "2026년 6월 15일 오후 7시에 4명이 생일 파티를 위해 예약해 줘. 이름은 Matt Hollingshead이고 전화번호는 123-555-5555다."

"Request Reservation"을 수동으로 클릭했고 확인 페이지를 받았다.

양식의 기존 유효성 검사가 계속 적용된다. 비스트로 양식은 이미 이름, 10자리 전화번호, 미래 날짜 및 시간을 요구한다. 에이전트는 동일한 규칙을 충족해야 한다. 에이전트가 유효하지 않은 데이터를 보내면, 양식이 사람에게 하는 것과 동일한 방식으로 거부한다. 에이전트를 위한 별도의 보호 장치를 구축할 필요가 없다.

페이지를 새로고쳐서 다시 프롬프트를 입력했는데, 이번에는 전화번호를 제공하지 않았다. 에이전트는 누락된 정보를 인식했고 제공을 요청했다.

양식은 계속 보이고, 제출은 여전히 사용자의 책임이다. 이 기본값은 에이전트가 도구를 실행할 때도 이어진다. 사용자는 양식이 채워지는 것을 보고 무엇이든 진행되기 전에 검토하며, 설계와 브랜딩이 계속 보인다.

선언적 API 작동 방식의 특징:

• 에이전트가 사이트와 사용자 간의 연결을 제거할 필요는 없다. 대신 사이트를 더욱 유용하게 해줌으로써 그 연결을 강화할 수 있다.

필수 API(JavaScript)

• 동작이 양식이 아니거나 도구가 페이지의 내용에 따라 변경되어야 할 때 이 자바스크립트 접근 방식을 사용한다.
• SaaS 대시보드를 예로 들자. 사용자 계정 상태를 에이전트에게 다시 읽는 도구는 제출할 것이 없으므로 양식으로는 할 수 없다. "업그레이드 계획" 도구는 무료 계층 사용자에게만 의미가 있다.
• 각 도구를 document.modelContext.registerTool로 등록하고, 이름, 설명, 입력 스키마, 에이전트가 호출할 때 실행되는 함수를 제공한다.
• 자바스크립트를 작성하는 대신, 도구는 페이지의 상태에 따라 나타났다 사라질 수 있다. 결제 도구는 장바구니에 무언가가 있는 동안만 존재할 수 있다.

예제 워크스루: 구글의 여행 예약 데모를 열었는데, React로 구축된 항공편 검색 앱이다. 검색 페이지에서 인스펙터는 원점, 목적지, 날짜, 승객 같은 구조화된 입력을 사용하여 검색을 시작하는 단일 도구 searchFlights를 나열했다.

DevTools의 소스 패널에서 앱이 설명과 inputSchema로 searchFlights 도구를 등록한 것을 볼 수 있다.

인스펙터의 사용자 프롬프트 필드에 "2026년 7월 10일에 출발하고 7월 20일에 복귀하는 뉴욕에서 런던으로 가는 왕복 항공편 2명 승객용을 찾아줘"를 입력했다.

Gemini 에이전트가 요청을 읽고 searchFlights를 호출했다. 결과가 반환되었을 때, 페이지는 3개의 추가 도구를 등록했고 인스펙터는 searchFlights와 함께 화면에 있는 것을 다시 읽기 위한 listFlights, 가격, 항공사 또는 시간으로 결과를 좁히기 위한 setFilters, 필터를 초기화하기 위한 resetFilters를 보여줬다.

이 도구들은 검색이 데이터를 반환할 때까지 나열할 것이나 필터할 것이 없었으므로 결과 후에만 나타난다.

필수 API 작동 방식의 특징:

• 사이트는 도구를 제공하지만, 에이전트가 어느 것을 호출할지, 어떤 순서로 호출할지 결정한다. 한 번의 프롬프트에서, Gemini 테스트 에이전트는 이 도구들을 사용하여 요청을 처리했다:
  • searchFlights를 경로 및 날짜로 호출
  • 결과를 좁히기 위해 setFilters 호출
  • 결과를 다시 읽기 위해 listFlights 호출
• resetFilters를 사용하지 않았는데, 이번에 에이전트의 작업에는 필요하지 않았다. 누군가의 브라우저의 에이전트도 스크린샷을 찍거나 어느 드롭다운이 필터인지 추측할 필요 없이 단일 요청에서 동일한 작업을 수행할 것이다.
• 동일한 패턴이 단일 페이지 앱 흐름, 필터된 결과 목록, 다단계 예약 및 일반 양식이 아닌 모든 것을 다룬다.

웹사이트에 WebMCP 구현하는 방법

WebMCP를 구현하기 전에 구글의 WebMCP 데모를 시도해보기를 제안한다. 그런 다음 다음 단계를 따라 사이트에 도구를 추가한다.

1단계: 에이전트 친화적 동작 감사

• 서비스 예약, 제품 구매, 카탈로그 검색, 뉴스레터 구독처럼 사람들이 사이트에 방문하는 상위 3~5개 동작을 나열하는 것부터 시작한다.
• 가장 좋은 후보는 명확하게 정의할 수 있는 입력과 사용자가 에이전트에게 완료하도록 원하는 독립형 동작이다.
• 그 단축 목록에서, 검색 위젯, 연락처 양식 또는 뉴스레터 가입 같은 간단한 동작 하나부터 시작한다. 더 간단한 것이 먼저 작동할 때까지 결제처럼 복잡하고 위험이 높은 흐름은 저장해둔다.

2단계: 첫 도구 작성 및 테스트

• HTML 양식은 시작하기에 가장 쉬운 곳다. 양식을 다시 만들지 않고도 기존 양식을 수정할 수 있기 때문이다.
• 위의 데모 워크스루처럼, 다음 속성을 추가할 수 있다:
  • toolname — 에이전트가 동작을 호출하는 데 사용하는 식별자로, 공백 없이 짧게 유지(예: toolname="search_products")
  • tooldescription — 에이전트에게 동작이 무엇을 하는지, 언제 사용하는지 알려주는 평이한 언어 문장(예: tooldescription="Search the catalog by keyword")
  • toolparamdescription — 각 입력에 추가되어 에이전트에게 그 필드가 어떤 값을 예상하는지 알려줌(예: toolparamdescription="The search term, e.g. red shoes")
• 그 다음 테스트한다. Chrome에서 chrome://flags/#enable-webmcp-testing의 WebMCP 플래그를 켜고 테스트를 위해 WebMCP 활성화를 선택한다. 다음으로 모델 컨텍스트 도구 인스펙터를 설치하고, 프롬프트를 입력하여 에이전트가 도구를 선택하고 인수를 올바르게 채우는지 확인한다.
• 에이전트가 뭔가 잘못하면, 대부분 설명이나 스키마가 문제다. 인스펙터의 복사 추적 버튼은 전체 세션을 JSON으로 내보내므로 에이전트가 정확히 무엇을 호출했는지 볼 수 있다.
• 그곳에서 조정하고 안정적일 때까지 다시 테스트한다.

3단계: 노출하는 도구 보호

• 도구를 추가하는 것은 책임을 동반한다. 에이전트가 도구를 사용할 때 사용자 대신 행동하고 있으며, 표시하려는 콘텐츠와 행동하라는 지시를 안정적으로 구별할 수 없다.
• 이는 프롬프트 주입의 한 형태다. 악의적인 텍스트가 도구를 통해 에이전트에 도달하면(도구가 반환한 타사 콘텐츠, 예를 들어 리뷰나 댓글 내에서 가장 가능성이 높음), 사용자에게 해를 끼치도록 속을 수 있다.
• 추가할 수 있는 몇 가지 보호:
  • 자바스크립트에서 도구를 정의할 때, 검색이나 목록처럼 데이터만 읽는 도구에 readOnlyHint를 추가한다. 에이전트는 도구가 뭔가를 변경한다고 가정하므로, 읽기 전용 항목에 플래그를 지정하면 불필요한 확인 프롬프트를 제거한다.
  • 도구 정의에서, 리뷰나 댓글처럼 사용자 생성이나 외부 콘텐츠를 반환하는 도구에 untrustedContentHint를 추가하여 에이전트가 그 텍스트를 지시가 아닌 의심하는 대상으로 취급하도록 한다.
  • 양식에서, 예약, 구매 또는 계정 변경 같은 중요한 작업에 대해 toolautosubmit을 끔 상태로 둔다. 이를 켜면 에이전트가 사용자가 제출을 클릭할 필요 없이 제출할 수 있으며, 이는 인간의 확인을 제거한다. 끈 상태(기본값)에서는 사람이 항상 검토하고 확인한다.
  • 이를 처리하는 것은 에이전트에 도구를 노출하는 정상적인 부분이며, 사용자 입력을 살균하는 것이 양식을 구축하는 정상적인 부분이다.

4단계: 초기에 배포

• 도구가 인스펙터에서 작동하면 실제 방문자에게 배포할 수 있다. WebMCP는 아직 최종화되고 있으므로 Chrome은 이를 시간 제한 시험으로 롤아웃하는데, 이를 통해 도메인을 등록하고 자신의 기계에서만 테스트하는 대신 라이브 사이트에서 도구를 제공할 수 있다.
• 그 도구를 실제로 사용할 수 있는 에이전트는 여전히 오늘날 제한적이다. 지금은 이를 트래픽 소스 이상으로 취급하지 말고, 대중에게 선택되기 전에 초기 영역을 확보하는 것으로 생각하라.
• 먼저 구축한 저위험 도구부터 시작하고, Chrome의 WebMCP 문서에서 등록하는 현재 방법과 어떤 브라우저와 에이전트가 현재 지원하는지 확인한다.

결론: WebMCP가 긴급해 보일 때까지 기다리지 말라

모바일 전환 중에 SEO를 하고 있었다면, 그것이 어떻게 진행되었는지 기억할 것이다. 모바일 친화적이 되는 것이 수년 동안 선택 사항처럼 느껴졌고, Google이 랭킹 요소로 만들 때까지 였으며, 초기에 준비한 사이트들은 기뻤다.

WebMCP도 비슷한 순간에 있는데, 사이트들은 배포할 수 있지만 대부분 아직 움직이지 않았다.

초기에 움직이는 사이트가 누군가의 에이전트가 예약, 구매 또는 가입을 하러 나타났을 때 실제로 작동하는 사이트가 될 것이고, 다른 모든 사이트는 마지막 단계에서 실패할 것이다.