WebMCP란 무엇인가: 웹사이트가 AI 에이전트에게 사용법을 알려주는 웹 표준 후보

여러분, 지금까지 웹사이트는 사람에게 화면을 보여주는 것을 목표로 만들어졌습니다. 그런데 앞으로는 AI 에이전트에게 이 사이트를 어떻게 쓰는지 알려줄 수 있느냐가 웹서비스의 경쟁력을 가를 수 있다고 봅니다. 그 역할을 맡는 기술이 WebMCP입니다.

결론부터 말하면, WebMCP는 웹페이지가 “나는 이런 일을 할 수 있고, 이렇게 요청하면 된다”는 사용법을 도구 형태로 미리 등록해두는 방식입니다. Google과 Microsoft 엔지니어들이 제안했고, 아직 확정된 웹 표준은 아니지만 방향성만큼은 분명해 보입니다. 저는 제 블로그인 devbrothers.ai에도 직접 붙여봤습니다.

WebMCP 핵심 요약

• WebMCP는 웹페이지가 도구 이름, 설명, 입력 스키마를 등록해 AI 에이전트에게 사이트 사용법을 직접 알려주는 기술입니다. 도구가 호출되면 함께 등록해둔 실행 함수가 페이지 안에서 기존 로직을 돌립니다.
• 기존 브라우저 에이전트도 웹을 쓸 수 있지만, 스크린샷과 DOM 분석을 반복하느라 토큰을 많이 쓰고 느립니다. WebMCP는 이 추측 단계를 건너뜁니다.
• MCP(Model Context Protocol)가 별도 서버를 호출하는 구조라면, WebMCP는 중간 서버 없이 지금 열린 페이지의 기존 로직을 쓰고 같은 화면을 갱신합니다.
• 적용 방법은 HTML 폼에 속성을 붙이는 선언형 API와 JavaScript로 도구를 등록하는 명령형 API 두 가지입니다.
• 2025년 8월 처음 제안됐고 아직 W3C 표준이 아닙니다. 호출할 수 있는 환경도 제한적이라 퍼스트 무버 구간에 가깝습니다.

브라우저 에이전트의 한계: 토큰과 속도

기존 웹은 사람이 버튼을 누르고, 폼을 채우고, 화면을 보면서 직접 통제하는 구조입니다. 웹사이트를 만들 때도 당연히 사람에게 잘 보이고 잘 눌리는 것을 기준으로 설계해왔죠.

그렇다고 에이전트가 지금 웹을 못 쓰는 건 아닙니다. 요즘은 브라우저 에이전트가 브라우저를 직접 통제하고, 화면의 시각 요소까지 확인할 수 있습니다. Playwright MCP나 Chrome DevTools MCP 같은 도구를 붙이면 에이전트가 DOM, 접근성 트리, 화면을 읽고 클릭하고 입력하면서 얼마든지 웹을 동작시킬 수 있습니다.

문제는 비용과 속도입니다.

1. 토큰을 많이 씁니다. 페이지 구조를 읽어 컨텍스트에 넣는 것 자체가 비쌉니다.
2. 느립니다. 스크린샷을 찍고, 코드를 살펴보고, 웹사이트 구조를 파악하고, 클릭한 뒤 다시 확인하는 왕복이 계속 반복됩니다.

에이전트 입장에서는 처음 보는 사이트에 들어갈 때마다 “이 버튼은 뭘 하는 거지?”, “이 입력창에는 뭘 넣어야 하지?”를 매번 추론해야 하는 셈입니다. 브라우저 에이전트가 페이지를 읽을 때 얼마나 많은 컨텍스트를 쓰는지는 Aside 브라우저로 Playwright MCP를 걷어낸 글에서 직접 재본 적이 있는데요, 도구를 바꿔도 화면을 해석해야 한다는 구조 자체는 그대로 남습니다.

WebMCP 동작 원리와 도구 구성 요소

WebMCP는 접근 방향을 뒤집습니다. 에이전트가 사이트를 더 잘 추측하게 만드는 게 아니라, 사이트가 에이전트에게 사용법을 먼저 알려주는 것입니다.

에이전트가 우리 웹사이트에 처음 들어왔을 때, 이 사이트가 어떻게 동작하고 어떤 기능을 쓰려면 무엇을 요청하면 되는지가 이미 정리되어 있습니다. 개발자는 페이지를 만들 때부터 코드에 도구를 구현해두고, 에이전트는 그 목록에서 필요한 도구를 골라 씁니다.

도구 하나는 이렇게 네 가지로 구성됩니다.

구성 요소	역할
이름	에이전트가 도구를 호출할 때 가리키는 고유 식별자
설명	도구가 하는 일과 언제, 어떻게 쓰면 되는지
입력 스키마	어떤 값을 넣어야 하는가 (JSON Schema)
실행 함수	호출되면 페이지 안에서 기존 앱 로직을 실행하고 결과를 돌려주는 부분

에이전트는 이름, 설명, 입력 스키마 같은 정의를 보고 도구를 고릅니다. 실행 함수는 에이전트에게 넘어가는 게 아니라 호출됐을 때 페이지 안에서 돌아가고, 그 결과만 에이전트에게 전달됩니다. 버튼이나 입력 필드가 무엇을 위한 것인지는 개발자가 선언하고, 페이지 상태도 개발자가 관리합니다.

항공권 검색 데모로 본 WebMCP 동작

말로만 들으면 감이 잘 안 오니까 실제 예제로 보겠습니다. Google Chrome Labs가 공개한 항공권 검색 데모(react-flightsearch)는 WebMCP가 적용된 가상의 항공권 검색·예약 페이지입니다. 테스트는 Chrome 확장 WebMCP - Model Context Tool Inspector로 했습니다. 이 확장은 페이지에 등록된 WebMCP 도구 목록을 보여주고, 내장된 Gemini 에이전트로 도구를 호출해볼 수 있게 해줍니다.

첫 화면과 결과 화면에 등록된 도구

Inspector를 열면 이 페이지에서 쓸 수 있는 WebMCP 도구가 목록으로 나옵니다. 처음 검색 화면에서는 도구가 하나 보입니다. 프롬프트를 보내면 에이전트가 이 도구로 검색을 끝내고 필터링 단계까지 굉장히 빠르게 넘어갑니다. 웹사이트 구조를 파악할 필요도, DOM이나 접근성 트리를 분석할 필요도, 스크린샷을 찍을 필요도 없습니다. 에이전트는 “이 사이트는 이 도구로 검색하면 되는구나”를 처음부터 알고 있으니까요.

검색 결과 화면으로 넘어가면 필터, 항공사 선택 같은 조작도 전부 도구로 올라와 있습니다. 등록된 도구는 네 개입니다.

도구	역할
searchFlights	항공편 검색
listFlights	현재 화면의 항공편 목록 확인
setFilters	가격, 항공사, 경유 같은 필터 설정
resetFilters	필터 초기화

조건을 붙인 재요청과 화면 반영

여기에 조건을 더 붙여서 다시 요청해봤습니다.

뉴욕 출발 런던행 왕복 항공편을 검색해줘. 출발일은 2026년 9월 15일, 귀국일은 9월 22일이고, $500 미만의 항공편과 직항편만 필터링해줘.

Inspector에 내장된 Gemini 에이전트가 도구를 조합해서 직항 조건과 500달러 미만 가격 필터를 빠르게 걸었습니다. 그리고 필터가 적용된 결과 목록을 읽어 항공편 목록까지 응답으로 정리해줬습니다.

속도만큼 눈여겨볼 점은 결과가 사람이 보고 있는 그 화면에 그대로 반영된다는 것입니다. 에이전트가 별도 창에서 따로 일하는 게 아니라, 사람이 보는 같은 검색 결과와 같은 필터 상태를 함께 바꿉니다.

MCP와 WebMCP의 차이: 도구 실행 위치

이름이 비슷해서 헷갈리기 쉬운데, 구조를 보면 차이가 분명합니다.

실행 경로 비교

기존 MCP 방식은 AI 에이전트가 MCP 서버를 호출하면 서버 쪽에서 기능이 실행되고, 그 결과를 에이전트가 받아오는 구조입니다.

WebMCP는 중간에 서버가 없습니다. 에이전트와 페이지 사이에 별도 MCP 서버를 두지 않는다는 뜻입니다. 웹페이지를 열었을 때 그 페이지 안에 도구가 이미 정의되어 있고, 도구가 호출되면 별도 서버로 요청이 넘어가는 게 아니라 우리가 연 그 웹사이트의 기존 기능을 그대로 씁니다. 기존 앱 로직이 실행되고, 사람이 보고 있던 같은 화면이 갱신됩니다. 실행 함수 안에서 사이트가 원래 쓰던 API를 호출하는 건 그대로 가능합니다.

구분	MCP	WebMCP
도구가 있는 곳	로컬 또는 원격 서버	지금 열린 웹페이지
실행 경로	에이전트 → 서버 → 결과	에이전트 → 페이지 안의 도구 → 기존 앱 로직
화면과의 관계	열린 페이지와 독립적으로 동작	사람이 보는 같은 화면을 갱신
잘 맞는 작업	페이지 없이 돌아가는 서버 작업	사람과 에이전트가 같은 화면을 보며 하는 작업

MCP와 WebMCP를 함께 쓰는 구조

OpenAI도 같은 기준으로 둘을 나눕니다. MCP는 AI 애플리케이션을 로컬이나 원격 서버에 연결하고, 열린 웹페이지와 상관없이 동작할 수 있습니다. WebMCP는 웹사이트가 자기 기능을 미리 정의된 도구로 에이전트에게 제공하므로, 사용자가 별도 MCP 서버를 설치하거나 연결을 따로 설정할 필요가 없습니다. 한 웹사이트가 둘 다 지원할 수도 있습니다.

둘 중 하나를 고르는 문제가 아닙니다. 서버에서 처리할 일은 MCP가, 지금 열린 화면에서 사람과 함께 처리할 일은 WebMCP가 맡습니다.

WebMCP를 쓰는 페이지는 백엔드가 아니라 클라이언트 쪽 스크립트에 도구를 구현한 MCP 서버라고 보면 이해가 쉽습니다. 페이지에 이미 있는 앱 로직과 로그인된 세션을 그대로 쓰기 때문에, 같은 기능을 에이전트에게 열어주려고 백엔드에 도구를 따로 구현하지 않아도 됩니다.

다만 이건 비유입니다. 도구를 이름, 설명, 입력 스키마로 정의하는 모델은 MCP와 닮았지만, WebMCP API 자체가 MCP 프로토콜로 통신하는 건 아닙니다.

WebMCP 제안 시점과 표준화 현황

제안부터 채택까지의 흐름

WebMCP는 생각보다 나온 지 꽤 된 기술입니다. 2025년 8월 Microsoft와 Google 엔지니어들이 공동으로 처음 제안했고, W3C 초안의 편집자 역시 두 회사 엔지니어들이 맡고 있습니다.

이후 흐름은 이렇습니다.

시점	일
2025년 8월	Microsoft·Google 엔지니어들의 첫 제안
2026년 6월	Chrome 149에서 WebMCP Origin Trial 참여 안내 공개
2026년 8월	코딩 에이전트 제품들이 하나둘 채택

W3C 초안 단계와 브라우저별 입장

2026년 10월 3일 기준으로 WebMCP는 W3C Web Machine Learning Community Group의 초안(Draft Community Group Report)입니다. 스펙 문서 스스로 W3C 표준이 아니고 표준 트랙에도 올라 있지 않다고 밝히고 있습니다.

그래서 저는 WebMCP를 “새로운 웹 표준”이라고 단정하기보다 웹 표준 후보라고 부르는 게 정확하다고 봅니다.

브라우저 진영의 입장도 갈립니다. WebKit은 공식 입장을 반대(oppose) 로 정했습니다. 에이전트가 다루기 어려운 부분은 HTML과 ARIA 같은 공용 계층에서 풀어야 하고, 에이전트용 도구 층을 따로 두는 건 맞는 해법이 아니라는 게 주된 이유입니다. Mozilla는 중립(neutral) 입니다. 잠재적 가치는 인정하지만 실제 사이트에서 어떻게 쓰일지 열린 질문이 많다고 봤고, 이름과 달리 MCP 프로토콜 자체가 들어 있는 건 아니라는 지적도 남겼습니다.

정리하면 아직은 굉장히 초기입니다. WebMCP를 지원하는 AI 서비스도 많지 않습니다. 다만 그만큼 먼저 적용하는 사람이 경험을 쌓을 수 있는 구간이기도 하죠.

ChatGPT Site tools로 블로그 검색 도구 호출하기

지원하는 제품이 많지 않은 가운데, OpenAI의 ChatGPT는 이미 WebMCP를 지원합니다. ChatGPT에서는 이 기능을 Site tools라고 부릅니다. 제안 단계의 WebMCP 표준을 ChatGPT가 구현한 기능으로, ChatGPT 데스크톱 앱의 내장 브라우저에서 ChatGPT Work와 Codex가 페이지가 제공하는 도구를 찾아 씁니다.

Codex의 블로그 검색 도구 호출

저는 devbrothers.ai 블로그에 WebMCP를 직접 적용해뒀습니다. 내장 브라우저로 블로그 목록 페이지(/blog/)를 열고 주소창의 Site tools를 누르면, 제가 등록한 블로그 검색 도구가 보입니다.

이 상태에서 “개발동생 블로그 글 중에서 Claude Code 관련 글 목록 확인해줘”라고 요청하면, Codex 에이전트가 이 블로그 검색 도구를 골라 제가 정의해둔 입력 스키마대로 호출합니다.

블로그 검색 도구(search_blog_posts) 구현

실제 구현은 이렇게 되어 있습니다.

• 도구 이름은 search_blog_posts, 표시 이름은 “개발동생 블로그 검색”입니다.
• 입력은 query(찾고 싶은 주제나 제품명, 여러 단어는 공백으로 구분), tag(좁힐 블로그 태그), limit(돌려받을 글 수, 1~3개이고 기본값 3개) 세 가지입니다.
• 결과로 글 제목, 설명, 태그, URL을 돌려줍니다.
• 읽기 전용 도구라서 readOnlyHint: true를 달아뒀습니다.
• 검색 대상은 블로그 목록 페이지에 이미 그려진 글 카드에서 모읍니다. 카드에 보이는 제목·설명과 카드에 심어둔 태그 데이터를 읽으니, 사람이 보는 목록을 그대로 재사용하는 셈입니다.

홈과 교육과정 페이지에는 같은 명령형 API로 교육 대상, 목표, 시간, 도구 조건으로 과정을 찾는 find_curriculum 도구도 등록해뒀습니다. 이쪽은 화면 카드를 읽지 않고, 교육과정 카드를 그리는 데 쓰는 과정 데이터를 페이지에 함께 실어두고 그 안에서 찾습니다. 핵심은 새 백엔드를 만든 게 아니라 이미 있는 화면과 데이터를 도구로 한 번 더 노출했다는 점입니다.

SEO·AEO 다음 단계: 에이전트가 작업을 끝내는 웹

저는 앞으로 나오는 웹사이트는 물론이고 기존 웹사이트도 WebMCP를 적용해야 한다고 생각하는 입장입니다. 웹사이트를 쓰는 주체 중에서 에이전트의 비율이 점점 높아지고 있기 때문입니다.

웹과 AI의 관계를 세 단계로 보면 이해가 쉽습니다.

단계	목표	대상
SEO (검색 엔진 최적화)	Google, 네이버 같은 검색 엔진에서 잘 발견되게 하기	검색하는 사람
AEO (답변 엔진 최적화)	ChatGPT, Claude 같은 AI가 답변에 우리 사이트 정보를 인용하게 하기	AI 답변 엔진
에이전트 실행 (WebMCP)	에이전트가 사이트에서 실제 작업을 끝내게 하기	AI 에이전트

SEO는 결국 사람에게 더 잘 발견되기 위한 작업이었습니다. ChatGPT나 Claude 같은 AI 서비스가 등장한 뒤로는 AI가 우리 웹사이트 정보를 대화 중에 인용할 수 있게 만드는 AEO도 다루게 됐고요.

그다음 단계가 WebMCP라고 봅니다. 에이전트가 우리 사이트를 찾고 인용하는 데서 끝나는 게 아닙니다.

앞으로는 에이전트가 사이트 안에서 실제 작업을 할 수 있는지, 그 작업을 끝낼 수 있는지가 웹사이트 설계의 중요한 기준이 될 거라고 생각합니다.

다만 이건 앞 단계를 대체하는 순서가 아닙니다. 같은 사이트가 검색 노출, AI 답변 인용, 에이전트 실행을 함께 갖춰 나가는 확장에 가깝습니다.

WebMCP를 적용하는 두 가지 방법

WebMCP를 적용하는 방식은 크게 두 가지입니다. 기존 HTML에 선언하는 선언형 API, JavaScript로 도구를 등록하는 명령형 API입니다.

선언형 API: HTML 폼 속성으로 도구 선언

이미 구축된 웹사이트의 HTML에 선언만 해주는 방식입니다. 폼을 만드는 것까지는 똑같고, 그 폼에 도구 이름과 도구 설명을 달아주면 브라우저가 그 폼을 WebMCP 도구로 인식합니다.

선언형 API에서 쓰는 속성은 네 가지입니다.

• toolname: 도구 이름
• tooldescription: 도구가 하는 일과 목적
• toolparamdescription: 개별 입력 필드의 설명 (선택)
• toolautosubmit: 에이전트가 도구를 호출했을 때 제출까지 진행 (선택)

예를 들어 항공편 검색 폼이라면 이렇게 됩니다.

<form
  toolname="searchFlights"
  tooldescription="출발지, 도착지, 출발일로 항공편을 검색합니다."
  action="/search"
>
  <label for="origin">출발지</label>
  <input type="text" id="origin" name="origin" required />

  <label for="destination">도착지</label>
  <input type="text" id="destination" name="destination" required />

  <input type="date" name="departureDate" required toolparamdescription="출발 날짜입니다." />

  <button type="submit">검색</button>
</form>

브라우저는 이 폼을 읽어서 이름, 설명, 입력 스키마를 가진 JSON 형태의 도구로 바꿉니다. 각 필드의 name, 타입, required, 라벨이 스키마의 재료가 됩니다. 에이전트가 이 도구를 호출하면 브라우저가 폼에 포커스를 주고 필드를 채우는데, 폼은 사용자에게 그대로 보입니다.

제출은 두 가지 중에서 고릅니다. 사용자가 직접 제출 버튼을 누르게 두거나, toolautosubmit을 붙여 에이전트 호출 시 바로 제출되게 하는 거죠. 검색처럼 되돌리기 쉬운 작업과 예약 확정이나 결제처럼 되돌리기 어려운 작업은 구분해서 판단해보면 좋겠습니다. 제출 이벤트에는 agentInvoked 속성이 있어 에이전트가 호출했는지 구분할 수 있고, respondWith()로 결과를 에이전트에게 돌려줄 수 있습니다.

명령형 API: JavaScript로 도구 등록

두 번째는 JavaScript를 쓰는 방식입니다. JSON Schema를 직접 정의해 여러 도구를 미리 등록해두고, 도구가 호출되면 기존 앱의 특정 함수가 실행되는 구조를 만듭니다. modelContext 인터페이스의 registerTool 메서드로 도구를 등록하는데, 일반적인 MCP 서버를 만들 때 도구를 등록하는 방식과 거의 같다고 보시면 됩니다.

앞에서 말한 devbrothers.ai 블로그 검색 도구를 줄이면 이런 모양입니다.

if (typeof document.modelContext?.registerTool === 'function') {
  await document.modelContext.registerTool({
    name: 'search_blog_posts',
    title: '개발동생 블로그 검색',
    description:
      '개발동생 블로그에서 AI 코딩, 에이전트, 개발 자동화 관련 글을 검색합니다. 제목, 설명, 태그와 글 URL을 반환합니다.',
    inputSchema: {
      type: 'object',
      properties: {
        query: { type: 'string', description: '찾고 싶은 주제나 제품명입니다.' },
        tag: { type: 'string', description: '결과를 좁힐 블로그 태그입니다.' },
        limit: { type: 'integer', minimum: 1, maximum: 3 }
      },
      additionalProperties: false
    },
    annotations: { readOnlyHint: true },
    execute: async ({ query, tag, limit }) => searchBlogPosts(posts, { query, tag, limit })
  });
}

맨 위의 조건문은 지원 여부 확인입니다. WebMCP를 지원하지 않는 브라우저에서는 아무 일도 일어나지 않고 기존 화면이 그대로 동작합니다. 사람용 인터페이스는 건드리지 않고 에이전트용 사용법을 한 겹 얹는 점진적 향상(progressive enhancement) 방식이라 기존 사이트에 붙이기 부담이 적습니다.

annotations에는 도구의 성격을 알리는 힌트를 넣습니다. readOnlyHint는 상태를 바꾸지 않는 읽기 전용 도구라는 뜻이고, 항공권 예약이나 송금처럼 되돌리기 어려운 작업에는 consequentialHint를 달아 사용자 확인이 필요하다는 신호를 줄 수 있습니다.

어느 쪽을 고를지는 이렇게 보면 됩니다.

구분	선언형 API	명령형 API
작성 위치	HTML 폼 속성	JavaScript
스키마	폼 필드에서 브라우저가 생성	JSON Schema로 직접 정의
잘 맞는 곳	기존 폼 제출 흐름	앱 상태, 필터, 복합 로직
ChatGPT 내장 브라우저	미지원	지원

WebMCP 적용 전 알아둘 제약

WebMCP를 만든다고 해서 모든 에이전트가 바로 쓰는 건 아닙니다. 호출할 수 있는 환경은 아직 굉장히 제한적입니다.

• 지원 환경이 적습니다. 내 Chrome에서 확인할 때는 chrome://flags에서 WebMCP for testing 플래그를 켜고 Inspector 확장을 씁니다. 실제 방문자의 Chrome에서 동작하게 하려면 플래그와 별개로 Chrome 149부터 열린 Origin Trial에 사이트를 등록해야 합니다. Inspector는 프로덕션 수준의 보안 경계를 제공하지 않으니 테스트 용도로만 쓰는 게 좋습니다.
• ChatGPT는 일부만 지원합니다. 2026년 10월 3일 기준 ChatGPT 내장 브라우저는 선언형 API와 iframe 안의 도구를 지원하지 않습니다. 최상위 페이지에서 JavaScript로 등록한 도구만 Site tools로 잡힙니다.
• 도구는 페이지에 속합니다. 페이지를 닫거나 다른 곳으로 이동하면 그 페이지의 도구도 사라집니다. 적당한 도구가 없으면 에이전트는 기존 브라우저 조작으로 돌아갈 수 있습니다.
• 도구 설명은 신뢰할 수 있는 데이터가 아닙니다. OpenAI는 웹사이트가 제공하는 도구 정의와 결과를 신뢰할 수 없는 콘텐츠로 취급하라고 안내합니다. 읽기 전용이라고 적혀 있다고 해서 실제로 그렇다는 증거는 아니라는 거죠. 만드는 쪽에서는 기존 인증, 권한, 입력 검증을 그대로 쓰는 게 기본입니다.

Chrome이 Origin Trial을 열고 ChatGPT가 제품에 넣었지만, WebKit은 반대하고 Mozilla는 중립이라 지금의 형태 그대로 완전한 표준이 될지는 아직 미정입니다. API 이름이나 세부 동작은 바뀔 수 있습니다. 다만 LLM과 외부 도구를 연결하는 표준이 MCP로 자리 잡았던 것처럼, 웹사이트와 에이전트를 연결하는 표준도 WebMCP가 될 가능성이 굉장히 높아진 것 같아요.

마무리

정리하면 WebMCP는 웹사이트가 사람에게 화면을 보여주는 데서 그치지 않고, AI 에이전트에게도 사용법을 알려주게 만드는 기술입니다. 에이전트가 화면을 해석하며 추측하던 단계를 사이트가 직접 선언한 도구로 대신합니다.

제가 말하고 싶은 건 이겁니다. 여러분이 만든 웹사이트, 앞으로 만들 웹사이트, 회사에서 운영하는 웹사이트를 에이전트 친화적인 인터페이스를 갖춘 사이트로 만들어가는 일은 아직 굉장히 이른 퍼스트 무버 단계입니다.

표준이 확정되기 전인 지금, 먼저 적용하는 쪽이 기회와 경쟁력을 가져갈 수 있다고 봅니다.

실무에서는 모든 기능을 한 번에 도구로 만들 필요가 없습니다. 검색처럼 부작용이 없는 읽기 전용 기능 하나부터 도구로 등록해보면 좋겠습니다. 에이전트에게 우리 사이트의 어떤 사용법을 알려줄지 정하는 것, 거기서부터 시작입니다.