WebMCP: 웹사이트를 AI 에이전트에게 열어주는 브라우저 표준

AI 에이전트가 웹사이트에서 항공권을 검색하거나 장바구니에 상품을 담는 모습을 상상해보신 적 있나요? 지금까지 AI 에이전트가 웹사이트를 다루려면 사람처럼 DOM 요소를 찾아서 클릭하고 텍스트를 입력해야 했습니다. Playwright MCP처럼 브라우저 자동화 도구를 쓰는 방법도 있었지만 웹 페이지 구조가 바뀌면 에이전트가 길을 잃기 십상이었죠.

2026년 2월, 구글과 마이크로소프트가 함께 완전히 다른 접근법을 내놓았습니다. 웹사이트가 직접 “나한테는 이런 도구들이 있어”라고 AI 에이전트에게 알려주게 하자는 건데요. 이게 바로 WebMCP입니다.

이 글에서는 WebMCP가 왜 필요한지, 어떻게 작동하는지, 실제 코드는 어떻게 생겼는지 살펴보겠습니다.

WebMCP란?

WebMCP는 웹사이트가 AI 에이전트에게 도구(tool)를 직접 내보낼 수 있게 해주는 브라우저 API입니다. W3C Web Machine Learning 커뮤니티 그룹에서 관리하고 있으며 구글의 David Bokan, Khushal Sagar, Hannah Van Opstal과 마이크로소프트의 Brandon Walderman, Leo Lee, Andrew Nolan이 함께 만들었습니다.

이름에서 눈치채셨겠지만 MCP(Model Context Protocol)와 밀접한 관련이 있습니다. MCP가 AI 모델과 백엔드 서비스를 잇는 표준이라면 WebMCP는 AI 에이전트와 브라우저 속 웹사이트를 잇는 표준입니다. WebMCP 도구의 구조도 MCP 도구와 같은 형태(name, description, inputSchema)를 따르고요. 브라우저가 중간에서 WebMCP 도구를 MCP 포맷으로 바꿔서 에이전트한테 넘겨주는 식입니다.

그래서 뭐가 좋은 걸까요?

에이전트가 더 이상 화면의 버튼을 더듬어 클릭하지 않아도 됩니다. 웹사이트가 “상품 검색”, “장바구니 담기” 같은 도구를 선언해두면 에이전트는 DOM을 뒤지지 않고 바로 도구를 호출할 수 있거든요.

UI가 바뀌어도 끄떡없다는 것도 큰 장점입니다. WebMCP 도구는 HTML 구조가 아니라 애플리케이션 로직에 묶여 있기 때문에 사이트를 리디자인해도 에이전트 동작에는 영향이 없어요. 게다가 브라우저 내부 시스템을 직접 쓰기 때문에 원격 서버 왕복이 없어 응답도 빠릅니다.

무엇보다 통제권이 운영자한테 있다는 점이 다릅니다. 에이전트가 제멋대로 클릭하는 게 아니라 사이트 측에서 “에이전트는 이렇게 상호작용해라”를 명확하게 정의하는 거예요.

선언적 API

WebMCP는 두 가지 API를 제공하는데요. 먼저 HTML 폼 기반의 선언적(Declarative) API부터 살펴보겠습니다.

기존 HTML <form> 요소에 몇 가지 속성만 추가하면 자바스크립트 한 줄 없이도 AI 에이전트가 사용할 수 있는 도구로 만들 수 있습니다.

<form
  action="/search"
  method="GET"
  toolname="search_products"
  tooldescription="키워드, 카테고리, 가격으로 상품 카탈로그를 검색합니다"
>
  <input
    name="query"
    type="text"
    required
    toolparamdescription="상품명이나 설명에 대한 검색 키워드"
  />
  <select
    name="category"
    toolparamdescription="검색 결과를 필터링할 상품 카테고리"
  >
    <option value="all">전체</option>
    <option value="electronics">전자제품</option>
    <option value="clothing">의류</option>
  </select>
  <input name="max_price" type="number" toolparamdescription="최대 가격 필터" />
  <button type="submit">검색</button>
</form>

새로 등장한 속성을 하나씩 뜯어보겠습니다.

toolname은 에이전트가 이 도구를 식별할 때 쓰는 이름입니다. MCP 도구의 name 필드와 같은 역할이에요.

tooldescription은 도구가 뭘 하는지 자연어로 적어둔 설명입니다. AI 모델이 이 문장을 읽고 “아, 이 도구는 상품 검색용이구나” 하고 판단하게 되죠.

각 입력 필드에 붙는 toolparamdescription은 파라미터별 설명입니다. 에이전트가 어떤 값을 넣어야 할지 이해하는 데 도움을 줍니다.

선택 속성인 toolautosubmit도 있는데요. 이걸 붙이면 에이전트가 폼을 채운 뒤 알아서 제출까지 합니다. 안 붙이면 사용자가 직접 제출 버튼을 눌러야 해요.

브라우저는 폼의 필드 정보를 자동으로 JSON Schema로 변환해서 에이전트에게 넘깁니다. 웹 개발자 입장에서는 기존 HTML 폼에 속성 몇 개만 추가하면 끝이고 스키마 변환이니 API 설계니 하는 건 브라우저가 다 처리해줍니다.

명령적 API

단순한 폼 제출로는 처리하기 어려운 복잡한 상호작용도 있겠죠. SPA(Single Page Application)에서 동적으로 변하는 UI를 다루거나 장바구니 담기처럼 페이지 이동 없이 처리해야 하는 작업이 대표적입니다.

이런 경우에는 자바스크립트 기반의 명령적(Imperative) API를 사용합니다. navigator.modelContext 객체를 통해 도구를 등록하고 관리할 수 있습니다.

navigator.modelContext.registerTool({
  name: "addToCart",
  description: "상품을 장바구니에 추가합니다",
  inputSchema: {
    type: "object",
    properties: {
      product_id: {
        type: "string",
        description: "추가할 상품의 ID",
      },
      quantity: {
        type: "number",
        description: "수량 (기본값: 1)",
      },
    },
    required: ["product_id"],
  },
  execute: ({ product_id, quantity = 1 }) => {
    // 장바구니 로직 실행
    cart.add(product_id, quantity);
    return {
      content: [
        {
          type: "text",
          text: `${product_id} ${quantity}개를 장바구니에 담았습니다`,
        },
      ],
    };
  },
});

registerTool()로 등록한 도구는 MCP 도구와 구조가 같습니다. name, description, inputSchema로 도구를 정의하고 execute 콜백에서 로직을 수행한 뒤 { content: [{ type: "text", text: "..." }] } 형태로 결과를 돌려줍니다. MCP를 써본 분이라면 낯익은 형태일 거예요.

navigator.modelContext에는 다른 메서드도 있습니다. unregisterTool()로 특정 도구를 이름으로 빼거나 provideContext()로 전체 도구셋을 한꺼번에 갈아치울 수 있죠. SPA에서 페이지가 바뀔 때 그 페이지에 맞는 도구셋으로 교체할 때 딱입니다. 전부 치우고 싶으면 clearContext()를 쓰면 됩니다.

활용 시나리오

실제로 어디에 쓸 수 있을까요? 기존 방식과 비교하면 차이가 확 느껴집니다.

고객 지원부터 보죠. 지금까지 AI 에이전트가 고객 지원 사이트에서 문의를 접수하려면 카테고리 드롭다운을 찾고 텍스트 필드를 채우고 제출 버튼을 클릭하는 과정을 UI에서 하나씩 추론해야 했습니다. WebMCP를 적용하면 사용자가 “네트워크 연결이 안 됩니다”라고 에이전트에게 말하면 에이전트가 create_ticket 도구를 호출해서 카테고리, 심각도, 설명을 한 번에 채워 넣습니다. UI를 추측하는 게 아니라 명시적으로 정의된 도구를 호출하니까 사이트 디자인이 바뀌어도 깨지지 않죠.

이커머스 쇼핑도 재밌는 사례입니다. “예산 50만원 이내에서 4K 모니터 추천해줘”라고 하면 에이전트가 search_products 도구로 조건에 맞는 상품을 찾고 비교한 뒤 addToCart 도구로 골라진 상품을 장바구니에 넣을 수 있어요. 이때 에이전트는 사용자가 지금 보고 있는 페이지 맥락(로그인 세션, 이전 검색 기록 등)을 브라우저를 통해 자연스럽게 활용할 수 있습니다.

여행 예약 쪽은 좀 더 직관적입니다. “다음 주 금요일 서울에서 제주 가는 오전 비행기 알아봐줘”라고 하면 에이전트가 항공사 사이트의 search_flights 도구를 써서 조건에 맞는 편을 정리해주고 가격 비교까지 해줄 수 있어요. 호텔 사이트에서도 비슷한 도구가 있다면 항공편과 숙소를 한 번에 잡는 시나리오도 가능하겠죠.

보안 모델

웹사이트에서 AI 에이전트가 마음대로 뭔가를 한다고 하면 보안이 신경 쓰일 수밖에 없습니다. WebMCP는 이 부분을 꽤 신경 써서 설계했습니다.

기본적으로 동일 출처 정책(Same-Origin Policy)을 따릅니다. WebMCP 도구는 해당 웹사이트의 출처(origin) 보안 경계를 그대로 물려받고 HTTPS가 필수이며 CSP(Content Security Policy)도 존중합니다.

사람이 중간에서 확인하는 것도 빠질 수 없죠. 브라우저가 카메라나 위치 권한을 요청하듯이 민감한 작업 전에 사용자 동의를 구합니다. 도구 안에서 agent.requestUserInteraction()을 불러서 “이거 진짜 실행해도 될까요?”라고 확인을 받을 수도 있고요.

서버 쪽에서도 에이전트 요청을 구분할 수 있습니다. 폼 제출 시 SubmitEvent에 agentInvoked 플래그가 붙어서 사람이 보낸 건지 에이전트가 보낸 건지 알 수 있거든요.

다만 아직 풀어야 할 숙제도 있습니다. 프롬프트 인젝션(도구 설명에 악의적인 지시를 숨기는 공격)이나 출력 인젝션(오염된 반환값으로 에이전트를 속이는 공격) 같은 위협은 스펙에서도 인정하고 있습니다. 여러 탭에서 민감한 정보에 동시에 접근하는 시나리오도 아직 주의가 필요합니다.

MCP와의 관계

MCP를 알고 계신 분이라면 “WebMCP가 MCP를 대체하는 건가?”라는 의문이 들 수 있습니다. Chrome 팀의 공식 블로그에서도 이 질문을 정면으로 다루는데요, 결론부터 말하면 둘은 경쟁이 아니라 보완 관계입니다.

좋은 비유가 있어요. MCP는 어디서든 전화 한 통이면 연결되는 콜센터에 가깝습니다. 플랫폼에 상관없이 항상 접근할 수 있고 데이터를 끌어오거나 핵심 작업을 처리하죠. 반면 WebMCP는 매장에 직접 방문했을 때만 만날 수 있는 매장 전문가입니다. 사용자가 웹사이트를 열어둔 그 순간에만 존재하지만 현장 맥락을 정확히 파악하고 있어요.

기술적으로 보면 MCP는 JSON-RPC 기반으로 AI 에이전트와 백엔드 서비스를 연결하고 WebMCP는 브라우저 안에서 postMessage를 통해 웹 페이지와 에이전트가 소통합니다. MCP에서 직접 자바스크립트 구현을 가져온 게 아니라 브라우저 환경에 맞게 새로 설계한 “MCP에서 영감을 받은(MCP-inspired)” API라서 MCP의 리소스(resources) 같은 서버 측 개념은 WebMCP에 없어요.

둘의 차이를 한눈에 정리하면 이렇습니다.

여기서 눈여겨볼 점은 UI 소유권입니다. MCP 앱은 에이전트의 UI 안에서 애플리케이션 인터페이스를 렌더링합니다. 반면 WebMCP에서는 에이전트가 여러분의 웹사이트에 “손님”으로 들어옵니다. 라이브 세션 데이터, 쿠키, DOM 요소에 접근할 수 있지만 탭을 닫거나 사이트를 떠나면 에이전트도 더 이상 접근할 수 없죠.

재밌는 건 도구 형태가 똑같다는 점입니다. 둘 다 name, description, inputSchema로 정의하고 응답 포맷도 같아요. MCP 생태계에 이미 발을 담근 개발자라면 WebMCP도 무리 없이 시작할 수 있을 겁니다.

함께 쓰면 더 강력하다

Chrome 팀은 가장 효과적인 에이전트 애플리케이션은 MCP와 WebMCP를 함께 사용하는 것이라고 강조합니다.

예를 들어 이커머스 서비스를 만든다고 해보죠. MCP 서버는 뒤에서 돌아가는 주요 로직, 그러니까 상품 조회, 재고 확인, 결제 처리 같은 걸 플랫폼에 관계없이 제공합니다.

그 위에 WebMCP가 브라우저 맥락을 입힙니다. 사용자가 쇼핑몰에 접속해 있는 그 순간, 에이전트가 현재 페이지 정보를 읽고 장바구니에 담고 위시리스트에 추가하는 일을 할 수 있게 되는 거죠.

MCP가 기반을 깔고 WebMCP가 현장 연결 고리를 만들면 에이전트 입장에서는 백엔드도 프론트엔드도 다 열리는 겁니다.

도구 발견 메커니즘

WebMCP 도구는 본질적으로 일시적(ephemeral)입니다. 웹 페이지가 브라우저 탭에 열려 있을 때만 존재하고 사용자가 사이트를 떠나거나 탭을 닫으면 에이전트도 더 이상 접근할 수 없어요. 보안 관점에서는 장점이지만 도구 발견 측면에서는 제약이기도 합니다. 에이전트가 어떤 사이트에 어떤 도구가 있는지 미리 알 수 없고 직접 방문해야 발견할 수 있거든요.

좀 불편하죠? 그래서 더 나은 방법이 준비되고 있습니다. .well-known/webmcp 경로에 JSON 매니페스트를 두는 방식이 논의 중인데 사이트맵이 검색 엔진한테 페이지 목록을 알려주는 것처럼 이 파일이 AI 에이전트한테 도구 목록을 알려주게 됩니다.

PWA(Progressive Web App)와의 연동도 검토되고 있습니다. 앱 매니페스트에 도구를 적어두면 PWA가 꺼져 있을 때도 도구 호출이 들어오면 시스템이 PWA를 자동으로 띄우는 방안입니다.

2027년 후반 목표인 W3C v2.0 로드맵에는 DHT(분산 해시 테이블) 기반 탈중앙 도구 레지스트리까지 들어 있다고 합니다. MCP Registry가 서버 측 MCP 도구의 검색과 배포를 맡는 것처럼 WebMCP 쪽도 발견 체계를 갖춰나가는 중이죠.

현재 상태와 로드맵

아직은 초기 단계입니다. 2025년 9월에 W3C 커뮤니티 그룹 정식 결과물로 채택되었고 2026년 2월 10일 Chrome 146 Canary에서 첫 브라우저 구현이 나왔습니다. chrome://flags에서 “WebMCP for testing” 플래그를 켜야 써볼 수 있어요.

Firefox, Safari, Edge도 W3C 그룹에는 참여하고 있지만 아직 자체 구현은 없습니다. 2026년 중후반에 정식 지원이 발표될 가능성이 높고 Google I/O나 Google Cloud Next에서 소식이 나올 수도 있겠죠.

W3C v2.0 로드맵(2027년 후반 목표)에는 스트리밍 도구 응답, 도구 조합(composition), 버전 관리된 도구 정의 같은 기능이 예정되어 있습니다.

마치며

지금까지 웹사이트는 사람이 보고 클릭하는 걸 전제로 만들어졌습니다. WebMCP가 자리를 잡으면 AI 에이전트도 웹의 일급 사용자가 되는 셈이죠.

물론 아직 Chrome Canary에서 플래그를 켜야만 쓸 수 있는 실험 단계이고 보안 과제도 남아 있습니다. 그래도 구글과 마이크로소프트가 같이 밀고 있고 W3C 표준 트랙을 밟는 중이라는 건 의미가 크다고 봅니다.

MCP가 AI 에이전트의 백엔드 통신을 표준화했다면 WebMCP는 프론트엔드 상호작용 쪽 퍼즐 조각입니다. 웹 개발자라면 지금부터 관심을 갖고 지켜볼 만합니다.

더 자세한 내용이 궁금하다면 아래 자료를 참고해보세요.

• WebMCP 공식 W3C 스펙
• WebMCP GitHub 저장소
• Chrome for Developers 블로그 공지