WebMCP 실전 적용, AI 에이전트가 내 웹사이트를 직접 쓸 수 있게 만드는 전략

WebMCP는 AI 에이전트가 웹사이트를 다루는 방식을 바꾸는 브라우저 표준이다. 구글과 MS가 Chrome 146 Canary에 미리보기를 공개했고, 지금 당장 폴리필로 적용할 수 있다. 도입 방법과 현실적인 판단 기준을 정리해봤다.

결론부터 말하면, WebMCP는 지금 당장 도입할 수 있고 도입해두는 게 맞다. 아직 Chrome Canary 한정이라 아쉽지만, 준비해두지 않으면 나중에 따라잡기 바빠진다. AI 에이전트가 내 웹사이트를 어떻게 다루게 할 건지 — 이걸 이제는 개발자가 직접 정의할 수 있게 됐다.

AI 에이전트가 웹을 다루는 기존 방식의 문제

AI 에이전트가 웹사이트에서 뭔가 하려면 지금까지는 꽤 무식한 방식으로 작동했다. 버튼을 찾아서 클릭하고, 화면을 캡처해서 멀티모달 모델에 던지고, 결과를 추론하는 과정을 반복하는 거다. Playwright MCP 같은 도구를 써봤다면 알겠지만, HTML 구조가 조금만 바뀌어도 에이전트가 길을 잃는다. 리디자인 한 번 하고 나면 자동화가 통째로 깨지는 경험, 한 번쯤은 해봤을 거다.

더 큰 문제는 비용이다. 스크린샷을 멀티모달 모델로 분석하는 건 텍스트 처리보다 토큰을 훨씬 많이 쓴다. 상품 하나 검색하는 데 에이전트가 수십 번 클릭하고 스크롤하면서 수천 토큰을 소모하는 게 지금의 현실이다. MCP를 붙여서 자동화를 고도화하면 이 비용이 눈에 띄게 올라간다는 걸 체감했다.

WebMCP가 MCP랑 다른 점 — 브라우저 안에서 작동한다

올해 초에 Chrome 146 Canary에서 WebMCP 미리보기를 처음 봤을 때 MCP 관련 프로젝트인 줄 알았다. 구글이랑 MS 개발자들이 W3C에서 같이 만든 건 맞는데, 서버 프로토콜인 MCP랑은 작동 계층 자체가 다르다.

MCP를 이미 알고 있다면 이름 때문에 헷갈릴 수 있는데, 둘은 작동하는 계층이 다르다. MCP는 AI 에이전트와 백엔드 서버 사이의 프로토콜이다. 반면 WebMCP는 브라우저 클라이언트 사이드에서 작동한다. 별도 서버를 구축할 필요 없이 프론트엔드 코드만으로 에이전트 연동 기능을 만들 수 있다는 게 핵심이다.

구조는 navigator.modelContext라는 브라우저 API를 통해 웹사이트가 도구(tool)를 직접 등록하는 방식이다. 에이전트가 DOM을 뒤지는 대신, 웹사이트가 "나한테는 이런 도구들이 있어"라고 먼저 알려주는 거다. 도구 이름과 설명, 파라미터 구조가 MCP 도구 형태와 동일해서, 브라우저가 중간에서 변환해 에이전트에 넘겨준다.

실제로 어떻게 구현하나 — 선언형과 명령형

선언형: HTML 폼에 속성 3개

간단한 폼이라면 JavaScript 한 줄 없이 HTML 속성만 추가하면 된다.

<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>
  </select>
  <button type="submit">검색</button>
</form>

toolname은 에이전트가 이 도구를 식별할 이름, tooldescription은 AI 모델이 읽고 판단하는 설명, toolparamdescription은 파라미터별 설명이다. 기존 폼에 속성 몇 개만 추가하면 에이전트가 쓸 수 있는 도구가 된다. 레거시 코드에도 그냥 얹을 수 있다는 게 장점이다.

명령형: registerTool()로 복잡한 로직까지

더 복잡하고 동적인 기능이 필요하면 JavaScript로 직접 등록한다.

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'add_to_cart',
    description: '상품을 장바구니에 추가합니다',
    inputSchema: {
      type: 'object',
      properties: {
        productId: { type: 'string', description: '상품 ID' },
        quantity:  { type: 'number', description: '수량' }
      },
      required: ['productId', 'quantity']
    },
    async execute(input) {
      const res = await fetch('/api/cart', {
        method: 'POST',
        body: JSON.stringify(input)
      });
      return { content: [{ type: 'text', text: await res.text() }] };
    }
  });
}

직접 써봤는데, MCP 서버를 따로 띄워본 경험이 있다면 스키마 구조가 익숙하다. execute 함수 안에 기존 API 호출 로직을 그대로 넣을 수 있어서 이식이 생각보다 간단하다. 브라우저 네이티브에서 돌아가니 응답도 빠르다. UI 리디자인을 해도 registerTool 로직은 건드릴 필요가 없다.

지금 적용할 만한가 — 솔직한 판단

솔직히 말하면 아직 운영 환경에 그냥 올리기엔 이르다. Chrome 146 Canary에서만 작동하고, 표준이 확정된 것도 아니다. API가 다음 버전에서 바뀔 수 있다는 경고가 공식 문서에 명시되어 있다. 다른 브라우저 지원 일정도 발표된 게 없다. MS가 공동 개발에 참여했으니 Edge는 빠를 것 같긴 하지만 보장이 없다.

그래도 지금 준비해두는 게 맞다고 생각하는 이유는 두 가지다. 첫째, MCP-B 폴리필 한 줄이면 네이티브 미지원 브라우저에서도 작동한다. navigator.modelContext가 없는 환경에서 자동으로 폴백되는 구조라 코드는 그대로 둬도 된다. 둘째, Google I/O 2026 전후로 정식 발표가 예정되어 있어서 올 하반기 안에 상황이 달라질 거다.

내가 지금 하고 있는 건 신규 기능 개발할 때 navigator.modelContext 코드를 미리 얹어두는 거다. 사용자 화면에 아무 변화 없고, 나중에 에이전트 연동이 필요할 때 그냥 켜면 된다. 선언형은 기존 폼에 속성 추가만 하면 되니까 비용도 거의 없다. 준비 안 하고 나중에 급하게 붙이는 것보다는 훨씬 낫다.

---

📎 참고 자료

• WebMCP is available for early preview | Chrome for Developers (2026.02.10)
• WebMCP: 웹사이트를 AI 에이전트에게 열어주는 브라우저 표준 | DaleSeo
• WebMCP Documentation - First Native Preview | mcp-b.ai

---

📌 함께 보면 좋은 글

• MCP 에이전트 자동화, Claude Opus 4.7이 GPT-5.4보다 나은 딱 한 가지
• Claude Code에 OpenAI Codex 박기: codex-plugin-cc 실사용 장단점 정리
• Google Antigravity 써봤는데, 무료라는 말과 실제 할당량이 달랐다