AI 모델 및 플랫폼
Cloudflare, AI 에이전트를 위한 Kitesurf 브라우저 엔진 오픈 소스로 공개
Unite.AI를 Google의 선호 소스에 추가
핵심 포인트Kitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript…
더 보기
- Kitesurf replaces Chrome with a lighter engine that renders pages and runs JavaScript for AI agents.
- Self-hosting shifts security to operators because the engine ships without authentication and exposes a public URL.
- Kitesurf remains experimental with incomplete Chrome compatibility despite its efficiency gains for agent workloads.
Cloudflare는 2026년 11월 13일 Kitesurf를 Apache 2.0 라이선스에 따라 오픈 소스로 제공한다고 발표했다. Kitesurf는 AI 에이전트를 위한 실험용 브라우저 엔진이다. 개발자는 코드를 살펴보고 수정하거나, 로컬에서 실행하거나, Cloudflare Workers에 자체 인스턴스를 배포할 수 있다.
공개 저장소를 통해 개발자는 관리형 Browser Run API에만 의존하는 대신 자체 Cloudflare 계정에서 엔진을 실행하고 수정할 수 있습니다. Cloudflare는 2026년 8월 6일 Kitesurf를 처음 선보였을 때 이 조치를 약속했으며, WebMCP 지원을 추가하고 브라우저 API와 Browser Run의 지원 범위를 확대하고 터미널 렌더링 기능을 도입한 2026년 9월 28일 업데이트에서도 이를 다시 약속했습니다.
에이전트 중심으로 설계된 Kitesurf의 내부 구조
Kitesurf는 Chrome이나 브라우저 컨테이너 없이 HTML과 CSS를 렌더링된 페이지로 변환하고, 페이지 JavaScript를 실행하며, 스크린샷을 생성한다. Chrome DevTools와 호환 자동화 소프트웨어가 사용하는 제어 인터페이스인 Chrome DevTools Protocol (CDP) 엔드포인트를 제공하므로 Puppeteer 클라이언트와 AI 에이전트 하네스가 연결할 수 있다.
내부적으로 Engine은 브라우저 세션과 클라이언트 연결을 조정하고, PageScript는 페이지와 페이지의 JavaScript를 실행하며, PageRenderer는 시각적 결과물을 생성한다. Cloudflare Developer Platform에 WebAssembly로 컴파일된 Rust 구성 요소를 결합했다. Blitz는 HTML 파싱, DOM, 레이아웃 및 페인팅을 담당하고, Stylo는 CSS를 처리하며, Linebender 라이브러리는 텍스트와 2D 그래픽을 담당하고, Krilla는 PDF 출력을 생성한다. 페이지 코드를 Dynamic Workers에서 실행할 수 없는 경우에는 Boa가 WebAssembly 내부에서 대체 JavaScript 런타임을 제공한다.
Cloudflare에 따르면, 설계 목표는 전체 Chromium 브라우저보다 CPU와 메모리를 적게 사용하면서 에이전트가 필요한 웹 접근 기능을 제공하고, Workers 네트워크 전반에서 필요에 따라 규모를 확장하는 것이다. 최초 아키텍처는 모든 페이지 로드를 신뢰할 수 없는 입력으로 취급하고, 구성 요소를 필요한 리소스에 따라 격리한다. 전용 SandboxOutbound 워커가 모든 외부 데이터 가져오기를 처리해 네트워크 정책을 적용하고 페이지별 쿠키를 분리한다. 다른 구성 요소는 네트워크에 직접 접근할 수 없다.
무상태성도 설계의 한 부분이다. Engine은 세션 상태를 유지하지만, 가능한 경우 다른 구성 요소는 일회용으로 운용해 에이전트 활동이 급증할 때 용량을 그에 맞춰 조정할 수 있다. PageRenderer는 페이지 상태를 지속적으로 보유하지 않으므로, 렌더링 요청이 실패하거나 멈춘 뒤 Engine이 이를 교체할 수 있다.
자체 호스팅 요건과 보안
로컬 개발에는 Bazelisk, Node.js 22 이상, pnpm 9.15.4가 필요하다. 개발 명령은 WebAssembly 모듈과 페이지 및 렌더러 번들을 빌드한 다음, 127.0.0.1:8787에서 로컬 엔진을 시작한다. 최초 빌드에서는 Rust 코어와 벤더링된 의존성을 컴파일하고, 이후 빌드에서는 Bazel 캐시를 재사용한다. 그런 다음 개발자는 Chrome DevTools로 페이지를 살펴보거나 Puppeteer 및 다른 CDP 클라이언트를 연결할 수 있다.
Cloudflare에 배포하려면 Workers 유료 요금제가 필요하다. Dynamic Workers가 페이지와 렌더러에 사용할 격리된 워커를 생성하기 때문이다. 로컬에서 테스트한 뒤 운영자는 Browser Run의 관리형 API 대신 자체 계정에 엔진을 배포할 수 있다.
자체 호스팅을 하면 중요한 보안 책임도 운영자에게 넘어온다. 엔진 자체에는 인증 기능이 없으며, workers.dev 주소는 기본적으로 공개 상태다. Cloudflare Access나 다른 인증 계층을 사용하지 않으면 URL을 아는 누구나 엔진을 통해 웹을 탐색하고, CDP 클라이언트를 연결하고, 운영자의 Cloudflare 계정에서 요청을 보내고, 유료 CPU 시간과 Dynamic Workers를 소모할 수 있다. 저장소에서는 운영자에게 URL을 즉시 보호하라고 안내하며, 공개 상태가 되는 시간대를 피할 수 있도록 배포 전에 계정 전체에 Access를 활성화하는 방법을 설명한다.
실험 단계와 기여 절차
Kitesurf는 여전히 실험 단계이며 개발이 활발히 진행 중이다. 저장소는 Kitesurf를 완전한 Chrome 구현체가 아니라 CDP 엔드포인트로 설명하며, Chrome DevTools 기능 중 일부는 아직 지원되지 않는다. Cloudflare는 호환성, 안정성 및 효율성을 우선적으로 개선하고 있다.
Cloudflare는 8월 출시 당시 Kitesurf가 아직 동영상, WebGL, 실제 TLS 지문이 필요한 봇 차단 챌린지의 핸드셰이크, 지속적인 상태에 의존하는 장시간 인증 세션을 지원하기에 적합하지 않다고 밝혔다. 이러한 한계는 리소스 사용량이 적은 브라우저가 매력적인 선택지인 경우에도 에이전트 작업 부하에 맞는지 확인할 때 여전히 호환성을 점검해야 한다는 점을 보여준다.
기여 절차는 이러한 지속적인 개발 작업에 맞춰 구성되어 있다. Cloudflare는 기여 희망자에게 최소한의 재현 사례나 제안하는 접근 방식을 담은 이슈를 먼저 열고, 풀 리퀘스트를 제출하기 전에 관리자의 보증을 받도록 요청한다. 테스트를 포함하고 범위가 명확한 집중적인 변경을 선호하지만, 재현 가능한 렌더링 버그, 실패하는 자동화 워크플로, 문서 수정도 환영한다.
개발자는 브라우저 스택을 직접 제어하는 대신 배포 보안을 스스로 책임지고, Chrome 및 웹 플랫폼과의 호환성이 아직 완전하지 않은 엔진을 감안해야 한다.
