Kitesurf 오픈소스 공개: CDP 호환 범위와 자체 배포의 인증 조건

Cloudflare가 11월 13일 AI 에이전트용 브라우저 엔진 Kitesurf의 소스 코드를 공개했다. 8월에 제품을 소개하고 9월에 WebMCP 지원을 추가한 뒤, 이번에는 개발자가 코드를 수정해 자신의 Cloudflare 계정에 배포할 수 있게 했다. 공식 발표는 이 공개를 Apache 2.0 라이선스 배포로 설명한다.

브라우저 자동화를 운영하는 개발자라면 자체 배포 조건부터 살펴볼 만하다. Kitesurf는 실험적 엔진이며 Cloudflare에 배포하려면 Workers 유료 요금제가 필요하다. 공개 엔드포인트를 보호할 인증 계층도 따로 마련해야 한다.

CDP 연결과 Chrome 호환 범위

Kitesurf는 Cloudflare Workers에서 HTML과 CSS를 처리하고 페이지 JavaScript를 실행한다. Chrome이나 브라우저 컨테이너를 띄우지 않고 스크린샷도 만든다. Chrome DevTools Protocol(CDP)로 제어하므로 Puppeteer 같은 클라이언트를 연결할 수 있다.

다만 공식 README는 일부 Chrome DevTools 기능이 아직 동작하지 않는다고 밝힌다. 기존 자동화가 CDP에 연결된다는 사실만으로 전체 작업의 호환성이 보장되지는 않는다. 도입 전에는 사용하는 페이지와 자동화 흐름을 직접 시험해야 한다. 공식 README

내부에서는 Blitz가 HTML·DOM·레이아웃을 처리하고 Stylo가 CSS를 맡는다. Cloudflare는 Dynamic Workers에서 JavaScript를 실행할 수 없을 때 Boa의 WebAssembly 실행 경로를 쓴다고 설명한다. 엔진의 세 구성 요소는 세션과 연결을 관리하는 Engine, 페이지와 JavaScript를 실행하는 PageScript, 결과를 그리는 PageRenderer다. 구조 설명

로컬 실행과 자체 배포

공식 README의 로컬 개발 요건은 Node.js 22 이상, pnpm 9.15.4, bazel 명령으로 설치한 Bazelisk다. macOS에서는 GNU tar도 요구한다. Bazel이 고정된 빌드 도구와 Rust 도구 체인을 내려받는다.

준비를 마치면 저장소를 복제하고 의존성을 설치한 뒤 pnpm run dev로 실행한다. 첫 빌드에서 Rust 코어 등을 컴파일하므로 시간이 걸릴 수 있다. 로컬 서버의 기본 주소는 http://127.0.0.1:8787이며 /health로 상태를 확인한다. 빌드 요건과 실행 안내

Cloudflare 배포에서는 페이지와 렌더러마다 별도 Worker를 시작하는 Dynamic Workers를 사용한다. 이 기능 때문에 Workers 유료 요금제가 필요하다. 로컬 개발 경로와 Cloudflare 배포 조건을 구분해서 비용을 검토해야 한다.

외부 접근을 허용하기 전의 인증

저장소는 엔진 자체에 인증 기능이 없다고 경고한다. 기본 workers.dev 주소는 공개된다. 주소를 아는 사람이 CDP로 접속하면 해당 계정에서 외부 요청을 보내거나 유료 CPU 시간과 Dynamic Workers를 사용할 수 있다.

공식 안내는 Cloudflare Access나 다른 인증 계층으로 엔드포인트를 보호하도록 요구한다. 배포 직후 인증을 설정하는 사이에도 공개 구간이 생기므로 그 구간을 막으려면 배포 전에 계정 전체 Workers에 Access를 켜라고 설명한다. 배포된 Version URL도 보호 대상이다. 자체 배포의 인증 조건

Kitesurf 코드는 Apache 2.0이지만 함께 쓰는 의존성과 글꼴·데이터에는 각자의 라이선스가 적용된다. 재배포할 때는 LICENSE와 NOTICE를 함께 확인해야 한다.

Cloudflare는 Chromium보다 CPU와 메모리를 적게 쓰는 것을 목표로 제시한다. 이번 공개 발표 본문에는 그 차이를 수치로 비교한 측정 결과가 없다. 이 글에서도 엔진을 직접 빌드하거나 성능·보안을 독립 시험하지 않았다. 실제 전환 여부는 대상 페이지의 동작 결과와 자기 작업의 비용을 측정한 뒤 판단해야 한다.