서론

안녕하세요, ArcHack 주식회사의 대표 미야타입니다. 정보학(인공지능)을 전공하는 현역 대학원생으로서 연구를 지속하며, 교토에서 AI 시스템 수탁 개발을 진행하고 있습니다. 해외의 AI·개발 최신 정보를 일본 기업이나 지방 현장에서 사용할 수 있는 형태로 번역하여 발신하고 있습니다.

• 정보학(인공지능·AI) 전공 현역 대학원생 / ArcHack 주식회사 대표
• Mercari AI/LLM 해커톤 우수상, AIFUL 데이터 해커톤 특별심사위원상
• 오사카·간사이 만박 프로덕트 전시
• X: @miyataArcHack

이번에는 2026년 8월에 Cloudflare가 개발자 프리뷰(Developer Preview)를 공개한 WebMCP를 다룹니다.

웹사이트를 AI 에이전트(AI Agent)가 조작하게 할 때, 많은 메커니즘은 "화면을 읽는다 → 버튼을 찾는다 → 클릭한다"라는 인간을 위한 UI를 따릅니다. 하지만 화면 구성이 조금만 바뀌어도 쉽게 망가지며, 에이전트가 폼(Form)이나 버튼의 의도를 오해할 여지도 남습니다.

WebMCP는 웹사이트 측이 에이전트에게 "사용 가능한 기능"을 구조화된 도구(Tool)로서 공개하기 위한 제안 중인 웹 표준입니다. 에이전트는 화면의 외관을 추측하는 대신, search_products나 prepare_checkout과 같은 도구 이름, 설명, JSON Schema로 정의된 입력을 단서로 조작할 수 있습니다. 1 2

이 기사에서는 Cloudflare의 WebMCP 개발자 프리뷰를 입구로 하여, WebMCP가 해결하려는 과제, Cloudflare가 수행하는 가교 역할, 그리고 자체 사이트에서 도구를 설계할 때의 최소 구현 이미지를 해설합니다. 참고로 WebMCP는 실험·제안 단계입니다. API나 도입 절차는 변경될 수 있으므로, 공개 전에는 공식 정보를 다시 확인하시기 바랍니다. 2 3

WebMCP는 무엇을 바꾸는가

기존의 브라우저 조작에서는 에이전트가 DOM이나 스크린샷을 통해 "이 버튼은 검색일지도 모른다"라고 판단합니다. 반면 WebMCP에서는 사이트가 검색·예약·필터링 등의 목적을 도구로서 선언하고, 인자(Argument)를 JSON Schema로 나타냅니다. 이를 통해 에이전트는 조작의 의미와 입력 형식을 더욱 명확하게 다룰 수 있습니다. 1 3

WebMCP는 AI에게 사이트 내부의 모든 것을 개방하는 메커니즘이 아닙니다. 사이트 운영자가 에이전트에게 무엇을 하게 하고, 무엇을 하지 않게 할지를 명시하기 위한 인터페이스입니다.

예를 들어 EC 사이트라면 상품 검색이나 상품 상세 정보 취득은 도구로 만들기 쉽지만, 주문 확정은 별개의 문제입니다. 가격·재고·배송지를 서버 측에서 재검증하고, 이용자가 최종 확인할 수 있는 화면을 반드시 거치도록 설계해야 합니다. Chrome의 공식 문서도 구매와 같은 민감한 조작에서는 확인 다이얼로그를 포함할 수 있다고 명시하고 있으며, Cloudflare의 사례에서도 사람에 의한 확인을 거치는 플로우가 안내되고 있습니다. 1 3

Cloudflare WebMCP는 무엇을 하고 있는가

Cloudflare의 개발자 프리뷰에서는 Cloudflare Dashboard에서 WebMCP를 활성화하면, 에지(Edge)에서 HTML로 브릿지 스크립트(Bridge Script)를 주입합니다. 그 브릿지가 브라우저 상의 WebMCP API를 탐지하고, 선택한 도구 팩(Tool Pack)이나 동일 출처(Same-origin)의 MCP 엔드포인트가 공개하는 도구를 페이지 측에 등록합니다. Cloudflare의 설명에 따르면, 오리진(Origin)의 애플리케이션 코드를 변경하지 않고 도입을 시작할 수 있다는 점이 특징입니다. 2

중요한 것은 Cloudflare의 "스위치를 켜기만 하면 되는" 경험과, WebMCP라는 표준·API의 개념을 분리하여 이해하는 것입니다. Cloudflare의 프리뷰는 도입을 쉽게 만드는 구현이며, WebMCP 그 자체는 브라우저에서 도구를 공개·발견·실행하기 위한 API입니다. 2 3

Cloudflare의 프리뷰에서 기존 MCP 서버를 연결하는 경우, 브릿지는 도구 목록을 취득하여 브라우저의 document.modelContext.registerTool에 프록시(Proxy)로서 등록합니다. 실행 시에는 방문자의 세션을 사용하여 동일 출처의 MCP 엔드포인트로 요청을 보내는 구성이 설명되어 있습니다. 2

우선 익혀야 할 설계 원칙

WebMCP의 성패는 도구의 개수가 아니라 책임의 분리 방식에 달려 있습니다. UI의 상태를 읽거나, 스크롤하거나, 현재 열려 있는 탭의 정보를 반환하는 것과 같은 페이지 고유의 처리는 인페이지 도구(In-page tool)에 적합합니다. 반면, DB 업데이트, 개인정보, 비밀키를 사용하는 외부 API, 탭을 닫아도 남는 데이터는 권한이 부여된 서버 측 MCP·API로 넘겨야 합니다. Cloudflare Agents의 공식 샘플도 동일한 책임 분리를 보여줍니다.4

최소 모의 코드: 상품 검색을 도구로 공개하기

다음은 상품 페이지에서 WebMCP를 지원할 경우의 개념 이해를 위한 모의 코드입니다. 실제 타입이나 API는 변경될 수 있으므로, 프로덕션에 그대로 복사하여 사용하는 용도는 아닙니다. 여기서는 "보이는 상품을 검색하는" 기능만을 페이지 내 도구로 공개합니다.

// WebMCP API가 없는 브라우저에서는 일반적인 UI를 그대로 제공합니다.
// "WebMCP 지원이 없으면 사이트가 망가지는" 설계를 피하기 위해서입니다.
if (!document.modelContext) {
...

이 예시에서 search_visible_products는 읽기 전용이며, 상품 가격을 확정하거나 주문을 생성하지 않습니다. 가격·재고·주문과 같이 신뢰성과 권한 관리가 필요한 정보는 서버 측에 둔 get_product_detail이나 prepare_checkout과 같은 별도의 도구로 분리합니다. 기사와 동봉된 workspace/cloudflare-webmcp-introduction/code/product-search-mock.ts에는 해당 책임 분리와 확인 화면으로의 전환까지 포함된 더 자세한 모의 코드가 들어 있습니다.

Cloudflare에서 시도하는 최단 경로

Cloudflare의 프리뷰를 사용하는 경우, 대상 존(Zone)의 Dashboard에서 Agent Readiness > Labs를 열고, WebMCP와 사용하고자 하는 툴 팩(Tool pack)을 선택합니다. Cloudflare 공식 기사에서는 Content Credentials와 Site MCP Server 팩이 개발자 프리뷰로 제공되며, 기존 MCP 서버가 있는 경우 동일 출처(Same-origin)의 /mcp를 접속 대상으로 설정할 수 있다고 설명합니다.2

동작 확인에는 HTML에 브릿지(Bridge)가 주입되었는지 확인하는 방법과, WebMCP를 지원하는 브라우저 환경에서 도구 목록을 가져오는 방법이 있습니다. Cloudflare Browser Run 가이드에서는 실험용 Lab 세션에서 navigator.modelContextTesting.listTools()를 호출하여 등록된 도구를 확인하는 흐름을 안내합니다.1

# Cloudflare가 HTML에 브릿지를 주입하고 있는지 확인하는 간이 확인 예시
curl -s https://your-site.example | grep webmcp

단, WebMCP는 아직 안정화된 웹 플랫폼 기능이 아닙니다. Chrome 공식 문서에서는 Origin Trial, 로컬 개발용 플래그, 브라우징 컨텍스트(Browsing context) 필수, 오리진 분리(Origin isolation), Permissions Policy와 같은 전제 조건 및 제한 사항을 안내하고 있습니다.3 우선은 읽기 전용의 작은 도구부터 시작하여, 반드시 일반 UI를 남겨둔 상태에서 검증하는 것이 안전합니다.

공개 전 체크리스트

요약

WebMCP의 본질은 AI에게 "화면을 능숙하게 클릭하게 만드는 것"이 아닙니다. 사이트 측에서 기능의 의미, 입력, 실행 가능한 범위를 정의하고, 에이전트가 이를 올바르게 사용할 수 있도록 만드는 것입니다. Cloudflare의 개발자 프리뷰는 기존 사이트에서도 그 첫걸음을 쉽게 뗄 수 있도록 도와줍니다.2

첫 구현에서는 검색, 상품 상세, 현재 상태 가져오기 등 실패하더라도 되돌릴 수 없는 부작용을 일으키기 어려운 도구부터 시작하는 것을 추천합니다. 도구 설계와 서버 측 권한 관리가 갖춰진 후, 확인 절차가 포함된 예약이나 주문 플로우로 확장해 나가면 사용자의 주도권을 유지하면서 에이전트 대응을 진행할 수 있습니다.

References

Discussion