Michael Johnson페이지를 읽거나 스크린샷을 찍는 것이 목적이라면 모든 AI 에이전트가 완전한 Chromium을 실행해야 할까요? 2026년 11월 12일, Cloudflare는 이런 자동화 작업을 위한 실험적 브라우저 엔진 Kitesurf의 소스 코드를 공개했습니다. 로컬에서 실행하거나 자신의 Cloudflare 계정에 배포할 수 있습니다. 핵심적인 절충점은 CPU와 메모리 사용량을 줄이는 대신 실행 시간이 길고 웹사이트 호환성이 제한적이라는 것입니다.
브라우저 자동화 개발자는 익숙한 Chrome DevTools Protocol(CDP) 인터페이스를 유지하면서 엔진을 살펴보고 수정할 수 있습니다. 하지만 필요한 페이지를 확인한 뒤에야 모든 작업을 Kitesurf로 옮기는 편이 좋습니다. Cloudflare가 공개한 비교에서 Chromium은 테스트 작업을 더 빠르게 마쳤고, Kitesurf는 아직 웹의 일부 주요 기능을 지원하지 않습니다.
11월 12일 달라진 점
Kitesurf는 2026년 10월 6일 베타 버전으로 제공되는 Browser Run의 구성 요소로 처음 소개됐습니다. 당시 Cloudflare는 아키텍처와 자체 테스트 결과를 설명했고, 11월 12일에는 Apache 2.0 라이선스로 코드를 공개했습니다. 이제 엔진을 살펴보고 로컬에서 빌드하거나 자신의 계정 인프라에 배포할 수 있습니다. 구현에 대한 접근성이 넓어졌지만, 이것만으로 실험적 브라우저가 Chromium을 대체하는 것은 아닙니다.
실행 방법은 두 가지입니다. 로컬 개발에는 Node.js 22 이상, pnpm 9.15.4, Bazelisk가 필요합니다. 프로젝트 안내에 따라 저장소를 복제하고 종속성을 설치한 다음 pnpm run dev로 빌드할 수 있습니다. Cloudflare에 배포하려면 Workers 유료 요금제가 필요합니다. 엔진이 페이지 격리에 Dynamic Workers를 사용하기 때문입니다. 직접 호스팅할 경우에는 별도로 인증을 설정해야 합니다. Kitesurf에는 인증 기능이 내장되어 있지 않으며, Worker의 공개 주소가 노출되면 다른 사람이 계정의 컴퓨팅 자원과 아웃바운드 요청을 사용할 수 있습니다.
Chromium 없이 브라우저를 구현하는 방식
일반적인 헤드리스 브라우저는 웹사이트와 사용자 인터페이스를 대상으로 설계된 대형 엔진을 실행합니다. Kitesurf는 자동화에 필요한 기능을 여러 Workers 구성 요소로 나눕니다. 한 구성 요소가 CDP 연결과 세션 상태를 관리하고, 별도의 격리 프로세스가 페이지를 처리하며, 또 다른 구성 요소가 렌더링을 담당합니다. 개발자 도구와 연동하기 위해 CDP를 지원하므로 Puppeteer와 같은 호환 클라이언트를 연결할 수 있습니다.
HTML과 CSS는 Rust 구성 요소가 처리하고, 페이지의 JavaScript는 격리된 Workers 환경에서 실행되며, 별도의 렌더러가 이미지를 만듭니다. Cloudflare는 네트워크 요청이 전용 구성 요소를 거치도록 설계했다고 설명합니다. 이 구성 요소는 사이트 리소스를 불러오고 네트워크 정책을 적용하며 각 페이지의 쿠키를 따로 보관합니다. 격리는 브라우저 구조의 일부입니다. 에이전트는 신뢰할 수 없는 코드가 포함될 수 있는 임의의 사이트에 접속해야 하기 때문입니다.
이 아키텍처는 ‘작업을 시작하고, 페이지를 처리한 뒤, 종료하는’ 유형의 부하에 적합합니다. 렌더러가 멈추면 종료하고 새로 만들 수 있습니다. 렌더러에는 페이지 상태가 저장되지 않기 때문입니다. 이런 방식은 자동화 작업이 급증할 때 계속 실행되는 무거운 프로세스보다 유리할 수 있습니다. 다만 이는 프로젝트의 설계 동기이지, 모든 사용자 시스템에서 일정한 비용 절감을 보장하는 것은 아닙니다.
비용을 줄이는 방식
Cloudflare가 앞서 공개한 비교에서는 URL 14개를 대상으로 Browser Run을 5회 실행해 중앙값을 사용했습니다. 스크린샷 생성 시 Kitesurf의 메모리 사용량은 57.8MiB였고, 웜 Chromium 풀은 271MiB였습니다. HTML 추출에서는 각각 39.4MiB와 273.7MiB였습니다. 이 수치는 회사의 특정 구성과 페이지 집합에서 측정한 결과이므로, 모든 사이트에 적용되는 보편적인 절감률이 아니라 특정 유형의 부하에 대한 측정값으로 보는 것이 적절합니다.
같은 작업에서 Chromium은 실행 시간도 더 짧았습니다. 스크린샷은 Chromium이 637ms, Kitesurf가 1,148ms였고, HTML 추출은 각각 472ms와 820ms였습니다. 즉, Kitesurf의 장점은 응답 속도보다 리소스 사용량에 있습니다. 대량의 짧은 페이지 수집에서는 메모리 비용이 몇 초의 지연보다 중요할 수 있지만, 빠른 반응이 필요한 인터랙티브 에이전트에서는 실행 시간 차이가 더 큰 단점이 될 수 있습니다. Cloudflare는 측정 방법과 결과를 공개했습니다.
Kitesurf와 Chromium 중 무엇을 선택할까
Kitesurf는 호환되는 사이트에서 HTML을 가져오고, DOM을 만들고, 스크린샷을 찍거나 PDF를 생성하는 일회성 작업에 적합합니다. CDP 호환성 덕분에 기존 자동화 스택에서 대안을 시험할 수 있고, 공개된 소스 코드로 동작 방식과 배포 조건도 살펴볼 수 있습니다. 작은 실험은 로컬 빌드로 시작할 수 있습니다. Cloudflare에서 운영하려면 유료 요금제를 고려하고 인스턴스에 인증을 설정해야 합니다.
동영상이나 WebGL이 있는 사이트, 장시간 유지되는 인증 세션, 봇 방어를 안정적으로 처리해야 하는 경우, 또는 페이지를 정확하게 표시해야 하는 경우 Cloudflare 문서는 Chromium 기반 표준 Browser Run을 권장합니다. Kitesurf는 아직 동영상 재생, WebGL, 상태를 유지하는 장시간 세션을 지원하지 않습니다. 웹 표준 지원과 렌더링 품질은 계속 개선 중입니다.
웹 표준 준수와 실제 호환성은 서로 다르다는 점도 중요합니다. Web Platform Tests는 웹 표준의 개별 요구사항을 검사하지만, 특정한 복잡한 사이트가 실제로 열리는지 또는 에이전트가 그 사이트에서 일련의 작업을 제대로 수행하는지는 알려주지 않습니다. 실용적인 검증 방법은 필요한 페이지와 시나리오를 직접 실행하고 결과를 Chromium과 비교하는 것입니다. 통과한 테스트의 전체 개수만으로 호환성을 판단해서는 안 됩니다.
팀을 위한 실용적인 결론
Kitesurf를 브라우저 작업을 위한 특수한 실행 환경으로 고려하세요. 먼저 실제 페이지 몇 개를 골라 데이터 추출이나 스크린샷의 정확도, 실행 시간, 리소스 사용량을 측정합니다. 그런 다음 인증, 네트워크 제한, 세션 동작을 따로 점검하세요. 작업이 짧고 사이트가 호환되며 지연보다 메모리와 CPU 사용량이 중요하다면 Kitesurf를 시험해 볼 만합니다. 정확한 렌더링, 풍부한 웹 기능 또는 상태의 지속성이 중요하다면 Chromium을 출발점으로 삼는 편이 적절합니다.
소스 코드 공개로 달라진 것은 경량 특화 엔진과 완전한 브라우저 사이의 선택 자체가 아니라, 전자의 구현을 직접 확인하고 배포할 수 있게 된 점입니다. 이제 팀은 공급업체의 비교표에만 의존하지 않고 자체 페이지와 인프라에서 더 쉽게 평가할 수 있습니다.
