이 글의 목차

WebMCP는 AI에게 화면의 버튼 위치를 추측하게 하는 대신, 웹사이트가 제공하는 동작을 도구로 알려주는 실험적 웹 API입니다. 검색창을 찾고 클릭 순서를 해석하는 과정 일부를 명시적인 입력 계약으로 바꾸려는 접근입니다. 그렇다고 웹사이트를 만들자마자 모든 AI가 자동으로 방문하거나 Google 검색 순위가 올라가는 것은 아닙니다.

2026년 10월 7일 갱신된 Chrome 문서는 Chrome 149부터의 origin trial, 로컬 테스트용 플래그, 두 종류의 API를 안내합니다. 아직 변경 가능한 실험 단계라는 점을 확인하고 시작하세요. Chrome WebMCP 현재 문서

WebMCP와 MCP 서버의 차이

이름이 비슷하지만 도입 위치가 다릅니다. 일반적인 원격 MCP 서버는 AI 애플리케이션이 외부 서비스의 도구에 연결하는 구조입니다. WebMCP는 사용자가 방문한 페이지의 브라우저 환경에서 웹 앱의 동작을 노출하는 접근입니다.

질문원격 MCPWebMCP
도구를 어디에 연결하나외부 도구 서버방문 중인 웹페이지
중요한 운영 조건클라이언트·서버 명세 호환브라우저 지원·trial·페이지 상태
인증은 없어도 되나서버 인증·인가 필요기존 앱 서버의 인증·인가 필요
UI는 없어도 되나사용 방식에 따라 다름사람의 기존 UI와 함께 설계

원격 MCP의 최근 변화는 MCP 2026 무상태 전환을 함께 읽으면 구분하기 쉽습니다. WebMCP를 기존 백엔드 API의 권한 검사를 대체하는 기능으로 받아들이면 안 됩니다.

지금 무엇이 바뀌고 있나요?

Chrome은 HTML 폼을 활용하는 declarative API와 JavaScript로 동작을 등록하는 imperative API를 제공합니다. 최신 imperative 문서의 도구 등록 인터페이스는 **document.modelContext**입니다. 오래된 예제의 객체 이름을 그대로 복사하기 전에 해당 브라우저와 문서 버전을 맞추세요. WebMCP Imperative API

이 점이 초기 기술을 다룰 때 가장 자주 생기는 함정입니다. 개념은 맞아도 몇 달 전 코드가 지금의 실험 버전에서는 동작하지 않을 수 있습니다. API 등록이 성공했는지, 도구 입력이 검증되는지, 사용자 UI와 같은 결과를 만드는지 따로 확인해야 합니다.

첫 도구는 읽기 전용 검색으로 시작

처음부터 결제·삭제를 도구로 노출하기보다, 기존 검색이나 상태 조회를 좁게 연결하면 결과를 비교하기 쉽습니다. 예를 들어 쇼핑몰의 search_products에는 검색어, 페이지, 허용된 정렬 기준만 받도록 할 수 있습니다.

아래는 입력 계약 설계 예시입니다. WebMCP에 등록하는 완성 코드가 아니라, 도구의 입력 범위를 생각하기 위한 JSON Schema입니다.

{
  "type": "object",
  "properties": {
    "query": { "type": "string", "minLength": 1, "maxLength": 100 },
    "page": { "type": "integer", "minimum": 1, "maximum": 20 },
    "sort": { "type": "string", "enum": ["relevance", "price_asc"] }
  },
  "required": ["query"],
  "additionalProperties": false
}

입력 필드가 명확하면 성공과 실패를 평가할 기준도 명확해집니다. ‘가격이 싼 상품을 찾아줘’라는 요청을 받았을 때 정렬 옵션이 어떤 값으로 전달됐는지 기록하고, 일반 UI 검색과 같은 결과인지 비교할 수 있습니다. 모델이 서버 주소나 임의 SQL을 입력하도록 넓힐 이유는 없습니다.

예약 도구에서는 실행 단계를 나누세요

예약 기능을 도구로 만든다면 다음 네 단계가 서로 다릅니다.

  1. 가능한 시간과 조건을 조회합니다.
  2. 사용자가 선택한 조건으로 예약 초안을 만듭니다.
  3. 대상·시간·비용·취소 조건을 확인합니다.
  4. 서버가 권한과 현재 재고를 검사한 뒤 확정합니다.

조회가 성공했다고 예약까지 끝난 것으로 응답하면 안 됩니다. 페이지에서 보던 시간이 다른 사용자에 의해 예약될 수도 있습니다. 확정 단계의 경쟁 조건, 중복 요청, 최종 상태는 백엔드가 관리해야 합니다. API 멱등성 가이드를 참고하면 중복 요청을 별도의 문제로 이해할 수 있습니다.

도구 등록과 사용자 권한은 별개

도구 이름과 설명이 있다는 사실은 호출자가 그 작업을 할 권한이 있다는 뜻이 아닙니다. Chrome의 보안 안내는 비신뢰 콘텐츠와 중대한 작업을 annotation hint로 구분하도록 설명합니다. WebMCP 도구 보안 이러한 힌트와 별개로 애플리케이션은 로그인 세션·서버 인가·실행 결과를 검증하도록 설계해야 합니다.

예를 들어 화면에 숨긴 관리자 메뉴를 도구가 호출할 수 있다면, 화면의 숨김 처리보다 서버가 관리자 권한을 확인하는지가 중요합니다. 툴에 userId를 입력받더라도 그 값만 믿고 다른 계정의 자료를 반환해서는 안 됩니다.

도입 전 확인할 테스트 세트

테스트확인할 결과
지원하지 않는 브라우저기존 검색·폼 UI가 정상 동작
잘못된 정렬값·긴 입력일관된 검증 오류
로그아웃·권한 없음서버가 허용되지 않은 자료를 반환하지 않음
도구 실행 뒤 UI사용자가 결과와 다음 동작을 이해 가능
새로고침·뒤로 가기등록·페이지 상태가 올바르게 복구
같은 동작 재호출중복 변경과 결과 상태 확인

성능 평가는 클릭 수보다 작업 성공률을 먼저 봅니다. 동일한 작업에서 입력 해석 오류, 결과 검증 실패, 사용자 확인 필요성을 기록하세요. ‘한 번 도구를 호출했다’와 ‘사용자가 원하는 일을 정확히 마쳤다’는 다른 지표입니다.

자주 묻는 질문

WebMCP를 넣으면 Google SEO가 좋아지나요?

그 자체로 순위가 올라간다는 근거는 없습니다. 사람이 읽을 수 있는 본문, 링크, 메타데이터와 기존 검색 접근성을 유지하고, 에이전트 도구는 별도로 평가하세요.

모든 브라우저에서 바로 사용할 수 있나요?

현재 Chrome 문서는 origin trial과 로컬 플래그를 안내합니다. 전체 브라우저의 기본 지원으로 가정하지 말고 적용 환경과 기능 탐지, UI fallback을 확인하세요.

기존 백엔드 API를 모두 새로 만들어야 하나요?

기존 안전한 애플리케이션 동작을 좁은 도구로 연결하는 방식부터 검토할 수 있습니다. 서버의 인증·인가·입력 검증을 유지하고, 도구와 UI가 같은 규칙을 사용하도록 설계하세요.

참고 자료

2026년 10월 8일 확인. 실제 브라우저 지원과 실험 API는 변경될 수 있으므로 적용 시점의 문서와 브라우저 버전을 대조하세요.

#웹개발#AI#브라우저#WebMCP
← 전체 글로 돌아가기