Kitesurf WebMCP 브라우저 자동화: 설정부터 결과 검증까지

Kitesurf WebMCP로 브라우저 자동화를 시작하는 가장 짧은 답

Kitesurf WebMCP를 사용하려면 MCP 호환 에이전트를 Chrome DevTools MCP를 통해 Cloudflare Browser Run에 연결하고, WebSocket 엔드포인트를 browser=kitesurf로 지정한 다음, 실험용 WebMCP 툴 카테고리를 활성화합니다. 그러면 페이지 액션을 찾는 list_webmcp_tools와 액션을 실행하는 execute_webmcp_tool, 두 가지 핵심 명령을 에이전트가 사용할 수 있습니다.

첫 테스트는 읽기 전용이거나 되돌릴 수 있는 액션으로 시작해야 합니다. Cloudflare Radar는 navigate-to, set-location 같은 액션을 제공하므로 문서에 근거해 시험하기 좋은 대상입니다. Kitesurf가 반환한 스키마를 확인하고 그 스키마가 허용하는 인수만 전달한 뒤, 구조화된 결과와 화면에 보이는 페이지 상태를 대조합니다. 둘이 일치하기 전까지는 툴 호출이 성공했다고 판단하면 안 됩니다.

이 글은 문서에 근거한 테스트 계획이며, 실제 테스트를 성공했다고 주장하는 글이 아닙니다. 이번 작성 과정에서는 테스트용 Cloudflare 계정이나 Browser Run 토큰을 사용할 수 없었으므로, 아래에 꾸며낸 성공 결과는 없습니다.

Kitesurf WebMCP가 실제로 바꾸는 것

MCP와 WebMCP가 맡는 역할은 서로 다릅니다. MCP는 에이전트와 원격 브라우저를 연결합니다. WebMCP는 그 브라우저 안에서 웹사이트가 자체 액션을 이름과 함께 공개하도록 합니다. MCP가 전화선이라면 WebMCP는 전화 너머의 메뉴인 셈입니다. 전화선으로 접속하고, 메뉴를 통해 무엇을 요청할 수 있는지와 각 요청에 어떤 정보가 필요한지를 정확히 알 수 있습니다.

이 메뉴가 없으면 에이전트는 대개 페이지를 읽고, 컨트롤을 찾고, 클릭하고, 기다린 뒤 다시 읽습니다. WebMCP가 있으면 페이지가 타입이 지정된 입력을 받는 set-location 같은 함수를 공개할 수 있습니다. 에이전트는 여전히 알맞은 액션을 선택하고 출력을 검증해야 하지만, 모든 상호작용을 픽셀이나 페이지 구조에서 추론할 필요는 없어집니다.

Cloudflare의 WebMCP 문서에 따르면 Kitesurf에는 자체 구현이 있어 Chrome Lab 세션이 필요하지 않습니다. 페이지는 document.modelContext를 통해 프로그래밍 방식의 툴을 등록할 수 있으며, Kitesurf는 toolname과 tooldescription 속성으로 표시한 선언형 폼 툴도 인식합니다.

MCP 클라이언트를 Kitesurf에 연결하기

Node.js 20.19 이상, MCP 호환 클라이언트, Cloudflare 계정 ID, 그리고 Browser Rendering - Edit 권한이 있는 API 토큰이 필요합니다. Cloudflare의 MCP 클라이언트 설정 문서는 Claude Desktop, Claude Code, Cursor, OpenCode 설정을 다룹니다. MCP 연결이 처음이라면 로컬 서버의 역할을 이해하는 데 MCP 서버 비교 글이 도움이 됩니다.

Cloudflare가 Kitesurf 출시와 함께 제시한 로컬 클라이언트 설정은 다음과 같습니다.

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

클라이언트가 요구하는 설정 형식에 맞추되 명령 인수는 그대로 유지합니다. 실제 계정 ID와 토큰은 커밋되는 설정 파일이 아니라 환경 기반 시크릿에 보관해야 합니다. 이 URL에 Chrome Lab용 매개변수를 복사하지 마십시오. Kitesurf는 browser=kitesurf를 사용하고, lab=true가 필요하지 않으며, keep_alive를 받지 않습니다.

마지막 플래그가 중요합니다. --category-experimental-webmcp가 Chrome DevTools MCP에 list_webmcp_tools와 execute_webmcp_tool을 추가합니다. 이 플래그가 빠지면 연결 자체는 정상이어도 두 WebMCP 명령이 나타나지 않을 수 있습니다.

Cloudflare Radar에서 검증 가능한 작업 하나 실행하기

가장 작은 유효 테스트에서도 네 가지를 입증해야 합니다. 툴 검색이 작동하고, 스키마를 읽을 수 있으며, 실행 결과가 반환되고, 페이지가 그 결과를 반영해야 합니다.

1. 연결된 에이전트에 https://radar.cloudflare.com/을 열도록 요청합니다. 테스트 계정 안에서만 작업하고, 금전적·파괴적·계정 전체에 영향을 주는 액션은 피합니다.
2. list_webmcp_tools를 호출합니다. 반환된 모든 툴 이름, 설명, 입력 스키마를 저장합니다. 페이지를 이동하거나 다른 액션을 실행하면 사용 가능한 툴 집합이 바뀔 수 있으므로, 이 목록은 현재 페이지 상태에 귀속됩니다.
3. set-location처럼 위험하지 않은 액션이 있다면 이를 선택하고 반환된 스키마를 읽습니다. 이 글을 보고 인수 이름을 추측하지 마십시오. 라이브 스키마를 계약으로 삼아야 합니다.
4. 스키마에 맞는 위치 값을 넣어 execute_webmcp_tool을 호출합니다. 정확한 툴 이름, 인수, 구조화된 결과, 경과 시간, 화면에 보이는 페이지 상태를 기록합니다.
5. 응답과 Radar 화면을 대조합니다. 상태가 바뀐 뒤 list_webmcp_tools를 다시 실행하고, 추가되거나 사라진 액션이 있는지도 기록합니다.

에이전트 프롬프트는 다음처럼 명확하게 작성하는 편이 좋습니다.

증거는 채팅 기록이 아니라 작은 테스트 레코드로 다뤄야 합니다. 최소한 다음 필드는 남겨 두십시오.

이렇게 해야 데모를 엔지니어링 팀이 반복할 수 있는 테스트로 바꿀 수 있습니다. WebMCP의 실패와 에이전트 추론의 실패도 분리할 수 있습니다. 이름 있는 툴이 없다면 실행 전 인터페이스 단계에서 실패한 것입니다. 호출은 성공했는데 페이지가 다르다면 실행 후 구현이나 검증 단계에서 실패한 것입니다.

Kitesurf에 폴백이 필요한 경우

Kitesurf WebMCP는 모든 브라우저를 제어하는 범용 계층이 아닙니다. 현재의 경계 조건을 알아야 어떤 프로덕션 작업을 안전하게 맡길 수 있는지 판단할 수 있습니다.

• iframe이나 팝업 안에 등록된 툴은 CDP를 통해 노출되지 않습니다. 에이전트가 사용할 수 없는 것으로 간주하고, 일반 브라우저 경로나 사람의 작업 경로를 사용하십시오. 사이트를 직접 운영한다면 최상위 툴을 제공하는 방법도 있습니다.
• Kitesurf 세션은 wrangler browser list에 나타나지 않으며 라이브 뷰도 없습니다. 따라서 사람의 확인을 기다리며 멈추는 툴을 에이전트가 완료할 수 없습니다.
• 확인 절차가 있는 액션에 대해 Cloudflare가 문서화한 수동 경로는 Kitesurf 플레이그라운드의 Application 아래에 있는 WebMCP 패널입니다. 이는 무인 자동화가 아니라 사람에게 넘기는 핸드오프입니다.
• Kitesurf는 WebMCP의 tools 권한 정책이나 출처 기반 툴 필터링을 구현하지 않습니다. 툴을 발견했다는 사실이 실행 권한을 뜻하지는 않습니다. 도메인, 액션, 테스트 ID에 대해 별도의 허용 목록을 유지해야 합니다.
• 툴 목록은 상태에 따라 바뀝니다. 페이지를 이동하거나 상태를 바꾸는 액션을 수행한 뒤에는 다음 툴이 여전히 존재한다고 가정하지 말고 다시 목록을 조회하십시오.

프로덕션에서 솔직한 해법은 라우터입니다. 적절한 이름의 액션이 있으면 WebMCP를 먼저 사용하고, 없으면 일반 브라우저 자동화로 전환하며, 동의가 필요한 액션은 사람에게 넘깁니다. 이 분기를 낙관적인 프롬프트 하나로 감추면 안 됩니다.

비용보다 중요한 것은 유지보수 계산입니다

Kitesurf는 계정별 한도 안에서 베타 기간 동안 무료입니다. 그러나 Cloudflare는 일반 유료 Browser Run의 초과 사용 요금이 무료 베타에도 적용된다고 확정하지 않았습니다. 현재의 Kitesurf 가격과 사용 한도는 별도 글에서 다룹니다. 베타 혜택만 보고 영구적인 비용 모델을 세우면 안 되는 이유도 함께 설명합니다.

이 시장에는 이미 실질적인 브라우저 인프라 예산이 존재합니다. Browserbase의 유료 플랜은 월 $20와 $99이며, Browserless는 연간 결제 기준 월 $25와 $140 플랜을 제공합니다. 두 제품은 더 폭넓은 인프라 업무를 담당하므로, 이를 일대일 대체 관계라고 주장하는 것은 아닙니다. 다만 팀들이 이미 브라우저 에이전트 운영에 비용을 지불하고 있다는 근거는 됩니다.

WebMCP가 바꾸는 예산 항목은 따로 있습니다. 바로 셀렉터 유지보수, 재시도, 운영자 검토입니다. WebMCP가 브라우저나 모델, 보안 통제, 결과 검증, 폴백 경로를 없애 주지는 않습니다. 동일한 작업을 두 방식으로 측정해 경과 시간, 실패 횟수, 사람의 개입, 엔지니어링 수정 작업을 비교하십시오. 유지비 절감 효과가 통합 작업보다 큰 구간에서만 Kitesurf를 유지하는 것이 좋습니다.

효과가 큰 순서로 정리한 일곱 가지 활용 사례

아래의 모든 사례는 대상 페이지가 적절한 WebMCP 툴을 실제로 제공한다는 전제에서 출발합니다. Kitesurf는 사이트에 없는 액션을 만들어 낼 수 없습니다.

첫 번째 사례의 가치가 가장 넓습니다. 앞으로도 오랫동안 대부분의 팀은 구조화된 사이트와 그렇지 않은 사이트가 섞인 웹을 상대해야 하기 때문입니다. 준비된 페이지 하나에서 성공하는 데모보다 WebMCP를 사용하지 말아야 할 때를 아는 라우터가 더 유용합니다.

만들어 볼 만한 제품 세 가지

1. WebMCP 우선 폴백 라우터

페이지의 툴 목록을 조회하고, 사용자가 요청한 액션을 허용된 스키마와 연결한 뒤, 작업을 execute_webmcp_tool, 일반 브라우저 자동화, 사람의 작업 대기열 중 하나로 보내는 정책 계층을 에이전트 팀에 제공할 수 있습니다. 모든 사이트가 WebMCP를 구현할 때까지 기다리지 않고 도입 장벽 자체를 해결하므로 가장 강한 기회입니다.

관련 수요는 이미 드러나 있습니다. browser automation의 월간 검색량은 약 720이며, 상업적 검색어인 browser automation tools는 약 260, CPC는 $34.28입니다. 판매 가능한 최소 버전에는 MCP 클라이언트 커넥터 하나, 도메인 및 액션 허용 목록, 스키마 매처, 실행 로그, 폴백 어댑터 하나가 필요합니다.

문제는 도달 범위입니다. WebMCP를 지원하는 사이트는 아직 제한적이고, 툴 집합은 페이지 상태에 따라 달라지며, Kitesurf는 CDP를 통해 iframe이나 팝업 툴을 노출할 수 없습니다. 폴백 엔진은 나중에 붙이는 선택 기능이 아니라 제품의 일부입니다.

2. WebMCP 회귀 모니터

사이트 운영자에게 공개된 툴 이름과 스키마를 기록하고, 되돌릴 수 있는 픽스처 액션 하나를 실행하고, 결과와 화면을 비교한 뒤, 차이가 생기면 알리는 정기 점검 서비스를 판매할 수 있습니다. website automation의 월간 검색량은 약 590이고 CPC는 $33.88입니다. 연관된 단수형 검색어 browser automation tool은 추천 검색어 데이터에서 전년 대비 24% 증가했습니다.

MVP는 테스트 자격 증명으로 운영사가 소유한 소수의 경로를 모니터링하고, 액션 전후의 툴 목록을 저장하며, 인수, 결과, 시간, 페이지 상태가 담긴 간결한 실패 기록을 만들 수 있습니다. 문제는 상태입니다. 툴이 보이지 않는 이유가 릴리스 결함이 아니라 잘못된 경로나 세션 상태일 수 있으므로, 재현 가능한 탐색과 신중하게 설계한 픽스처가 필요합니다.

3. WebMCP 준비도 진단 도구

고객 여정 중 어떤 구간이 최상위 툴을 공개하는지, 어떤 액션이 iframe이나 팝업 뒤에 있는지, 어떤 액션에 사람의 승인이 필요한지 정리해 주는 사전 진단 서비스를 웹 팀에 제공할 수 있습니다. 수요를 보여 주는 실용적인 지표도 있습니다. playwright browser automation의 월간 검색량은 약 320이고 전년 대비 129% 증가했으며, website automation은 약 590입니다.

최소 버전은 운영사가 소유한 사이트의 경로와 테스트 ID를 받아, 사용 가능한 툴을 나열하고 분류한 뒤 우선순위가 있는 구현 보고서를 생성합니다. 다만 관찰 가능성에는 분명한 한계가 있습니다. Kitesurf는 CDP를 통해 중첩된 iframe이나 팝업 툴을 공개할 수 없으므로, Kitesurf만으로는 그 툴이 의도한 계약을 추론할 수 없습니다. 숨겨진 툴과 아예 없는 툴을 구분하려면 사이트 운영사의 정보나 두 번째 점검 방법이 필요합니다.

한계와 현실적인 판단

Kitesurf WebMCP는 구조화된 액션이 클릭 순서보다 분명히 나은, 범위가 제한되고 되돌릴 수 있는 작업에 지금 사용할 만합니다. 핵심 워크플로, 중첩된 결제 경험, 실시간 사람의 승인을 기다려야 하는 작업의 유일한 경로로는 사용하지 마십시오.

이 기능은 유용하지만, 출시 속도가 생태계의 준비 속도보다 앞서 있습니다. 이름 있는 액션 모델은 모호성을 줄이고 실패 원인을 더 쉽게 진단하게 해 줍니다. 그렇다고 모든 웹사이트가 에이전트에 준비된 것은 아니며, 페이로드가 반환됐다고 해서 페이지가 올바르게 작동했다는 증거가 되지도 않습니다. 가장 중요한 제품 경계는 검증 단계입니다.

이 연결 방식과 검증 테스트 시스템, 폴백 정책을 프로덕션 에이전트에 구현하려면 프로덕션 시스템 구축을 도와드릴 수 있습니다.