Kitesurf 브라우저: AI 에이전트용 Browser Run 통합

Cloudflare가 새 브라우저를 만들겠다고 나선 이유는 단순한 호기심이 아니었다.

웹 브라우저는 우리가 매일 쓰는 가장 중요한 소프트웨어이자, 인터넷의 운영체제에 가깝다.

Kitesurf 브라우저가 AI 에이전트 작업을 위해 웹 페이지를 렌더링하고 결과 이미지를 생성하는 장면

Cloudflare 내부에서는 “우리만의 브라우저를 만들어야 하는가?”라는 질문이 몇 달마다 반복돼 왔다. 하지만 기술적 난이도와 실제로 해결할 문제 사이의 균형을 찾지 못해 아이디어는 여러 번 미뤄졌다. 그러다 이번에는 상황이 달라졌다.

몇 가지 기술적 변화가 동시에 성숙했다.

Workers에서 WebAssembly를 안정적으로 실행할 수 있게 되었고, dynamic workers, SQLite 기반 Durable Objects, worker-to-worker RPC, service bindings, 향상된 NodeJS

호환성, 더 넓어진 limits가 더 복잡한 애플리케이션을 가능하게 했다.

여기에 AI 에이전트의 확산과 새로운 형태의 브라우저 수요가 겹치면서, 마침내 Kitesurf가 현실이 됐다.

핵심은 방향성이다. Kitesurf는 범용 소비자용 브라우저가 아니라, 에이전트가 웹 작업을 수행하는 데 필요한 기능에 초점을 맞춘다.

그래서 탭, 테마, 확장 프로그램, 기기 간 동기화 같은 요소보다 토큰 수, 컨텍스트 윈도우, 확장성, 성능, 비용이 더 중요하다.

Browser Run에서의 역할과 설계 의도

Kitesurf는 Cloudflare의 헤드리스 브라우저 자동화 제품인 Browser Run에서 무료 베타로 제공된다.

Browser Run의 성장 배경도 AI와 맞닿아 있다.

에이전트는 많은 작업을 수행하기 위해 브라우저가 필요하고, 어떤 경우에는 브라우저 없이는 성공할 수 없다.

문제는 기존 브라우저 엔진이 기본적으로 인간 사용자를 위해 만들어졌다는 점이다.

Chromium 같은 엔진은 시각적 완성도와 폭넓은 호환성을 위해 많은 메모리와 계산 자원을 사용한다.

하지만 AI 모델은 그런 요소가 항상 필요하지 않다.

화면이 완벽하게 픽셀 단위로 맞아야 하거나 60fps로 부드럽게 스크롤되어야 하는 상황은 에이전트의 핵심 요구가 아니다.

Kitesurf 브라우저는 바로 이 차이를 파고든다.

구조화된 콘텐츠를 읽고, 페이지를 렌더링하고, 스크린샷을 만들고, HTML을 추출하는 작업에 더 적합하도록 설계됐다.

이 때문에 Browser Run에서의 실제 사용 맥락도 분명하다.

범용 브라우저처럼 모든 것을 다 하려는 대신, 자동화와 에이전트 중심 작업을 더 가볍고 효율적으로 처리하는 방향이다.

AI 에이전트용 브라우저로서 중요한 기준

AI 에이전트용 브라우저를 설계할 때는 인간용 브라우저와 기준이 다르다.

Kitesurf에서 특히 강조한 포인트는 다음과 같다.

메모리와 CPU 효율성: 에이전트마다 브라우저 인스턴스를 주는 방식은 비용이 커질 수 있다.
구조화된 출력: HTML, DOM, 스크린샷, PDF 같은 결과물이 중요하다.
보안 모델: prompt injection과 tool safety가 핵심 위험 요소다.
상태 관리 방식: 세션을 오래 유지하기보다, 필요한 작업만 수행하고 사라지는 구조가 유리하다.

즉, Kitesurf 브라우저는 “예쁜 화면을 보여주는 브라우저”보다 “기계가 일을 끝내는 브라우저”에 가깝다.

이것이 Browser Run에서의 존재 이유이기도 하다.

Kitesurf 브라우저의 핵심 설계 원칙

Cloudflare는 Kitesurf를 만들기 전에 몇 가지 원칙을 명확히 했다.

이 원칙들은 단순한 구현 세부 사항이 아니라, 에이전트 환경에서 브라우저가 살아남기 위한 조건에 가깝다.

테스트를 먼저 세운다

대규모 브라우저를 AI로 보조해 개발하려면 품질 관리가 중요하다.

그래서 Web Platform Tests(WPT)를 적극 활용했다.

WPT는 기능 적합성을 판단할 수 있는 폭넓은 기준을 제공했고, 에이전트에게도 명확한 목표를 줄 수 있었다.

다만 WPT만으로는 충분하지 않았다.

실제 웹사이트의 렌더링과 상호작용까지 보려면 통합 테스트와 시각 회귀 테스트가 필요했다.

Chromium과 Kitesurf를 대상으로 Puppeteer 기반의 멀티스텝 테스트를 수행하고, 각 단계의 렌더링 결과까지 비교해 의도하지 않은 차이를 찾도록 했다.

Rust와 Wasm을 최대한 활용한다

Cloudflare는 Workers에서 Wasm을 잘 지원하도록 오랫동안 준비해 왔다.

Kitesurf는 그 기반 위에서 고성능 Rust 패키지를 Wasm으로 직접 컴파일하는 방식을 선호했다.

Emscripten처럼 여러 계층의 가짜 의존성을 얹는 방식은 바이너리를 무겁고 느리게 만들 수 있기 때문이다.

가능하면 native Rust를 쓰고, wasm-bindgen으로 직접 WebAssembly에 연결해 불필요한 에뮬레이션 층을 줄였다.

이런 접근은 성능뿐 아니라 실행의 단순성과 신뢰성에도 도움이 된다.

실패는 세션 전체를 무너뜨리지 않게 한다

브라우저는 불안정하거나 적대적인 웹을 끝까지 견뎌야 한다.

그래서 예외 처리의 목표는 단순한 정리가 아니라 생존이다.

Kitesurf는 실패를 빈 프레임이나 누락된 요소 수준으로 흡수하고, 세션이 완전히 죽지 않도록 설계했다.

이 원칙은 AI 에이전트 환경에서 특히 중요하다.

한 번의 잘못된 응답이나 예외 때문에 작업 전체가 무너져서는 안 되기 때문이다.

격리와 무상태를 기본값으로 둔다

에이전트는 신뢰할 수 없는 임의의 사이트를 대상으로 작동한다.

따라서 페이지 로드는 모두 신뢰하지 않는 입력으로 보고, 세션은 매번 새로 시작하는 것이 기본이다.

각 구성 요소는 필요한 자원만 접근할 수 있도록 격리된다.

또한 가능한 한 무상태로 만든다.

상태가 적을수록 복구가 쉽고, 병렬 처리도 간단해진다.

중단되면 다시 시작하고, 막히면 버리고, 요청이 끝나면 사라지는 구조가 자동화에 더 맞는다.

Kitesurf 브라우저는 이런 방향을 일관되게 따른다.

Kitesurf 브라우저는 어떻게 동작하나

Kitesurf는 크게 Engine, PageScript, PageRenderer라는 세 가지 주요 구성 요소로 나뉜다.

전체 흐름은 간단하게 말하면, Engine이 세션을 관리하고, PageScript가 페이지 로직을 다루고, PageRenderer가 실제 픽셀을 만든다.

외부 리소스는 SandboxOutbound만 통과한다

웹 페이지를 렌더링하려면 이미지, 폰트, CSS, JavaScript, Wasm 파일 등 다양한 외부 자산을 가져와야 한다.

이 과정은 브라우저가 수행할 수 있는 가장 위험한 작업 중 하나다.

Kitesurf는 SandboxOutbound worker 하나를 통해서만 네트워크 접근을 허용한다.

Engine은 이를 사용해 메인 문서와 스크립트를 불러오고, PageScript는 스타일시트, 이미지, 폰트, 페이지의 fetch 호출 등을 처리한다.

CORS 적용, 브라우저 형태의 헤더 주입, 응답 필터링, 쿠키 분리도 이 계층에서 이뤄진다.

정책을 벗어나는 요청은 403으로 차단된다.

Engine은 세션의 중심이다

Engine은 Kitesurf의 유일한 공개 진입점이다.

Chrome DevTools Protocol(CDP) WebSocket과 HTTP REST API를 처리하고, 내부 테스트용 랜딩 페이지를 제공하며, 무엇보다 세션 상태를 보관한다.

다른 구성 요소들은 모두 무상태다.

이 구조의 장점은 호환성이다.

Puppeteer, Playwright, chrome-remote-interface, 그리고 실제 Chrome DevTools 프런트엔드까지 CDP를 지원하는 도구라면 Kitesurf에 연결해 사용할 수 있다.

Browser Run이 이 방식으로 동작하기 때문에, 기존 자동화 도구와의 연결 장벽도 낮다.

PageScript는 페이지 단위 실행을 맡는다

PageScript는 Dynamic Workers의 활용 사례를 잘 보여준다.

각 페이지나 OOPIF마다 장수하는 isolate를 새로 띄워, 깨끗한 globalThis와 DOM 문서를 가진 세션을 담당하게 한다.

HTML과 CSS 파싱에는 Blitz의 일부 모듈과 Firefox의 CSS 파서인 Stylo를 사용한다.

그리고 발견된 script 태그나 .wasm 파일은 같은 isolate 안에서 실행된다.

JavaScript와 WebAssembly를 한 세션 맥락에서 다루는 방식이다.

eval 처리 방식도 따로 준비했다

Workers는 보안 이유로 eval을 네이티브 지원하지 않는다.

그렇다고 별도 isolate를 또 띄우면 globalThis에 접근할 수 없다는 문제가 생긴다.

그래서 Kitesurf는 Rust로 작성된 ECMAScript 엔진 Boa JS를 사용해 필요한 경우 eval을 처리한다.

이 방식이 이상적인 것은 아니지만, 실제 코드에서 마주치는 제한적인 eval을 다루는 데는 충분하다.

나중에 Workers에 네이티브 eval 지원이 들어오면 이 부분은 바뀔 수 있다.

PageRenderer가 최종 이미지를 만든다

PageRenderer는 계산된 페이지 객체를 실제 픽셀로 바꾸는 역할을 한다.

Engine이 프레임이 필요할 때마다 PageScript에서 scene을 받아오고, 내부 폰트와 이미지를 Static Assets에서 불러온 뒤, 이미지 버퍼로 래스터화해 반환한다.

결과는 JPEG, PNG, PDF처럼 클라이언트가 표시할 수 있는 형식으로 전달된다.

이 과정에는 blitz-paint와 Parley가 관여해 글리프 구성, 폰트 선택, 줄바꿈 처리를 돕는다.

다시 말해, Kitesurf 브라우저는 웹 페이지를 “보는” 것이 아니라, 에이전트가 다룰 수 있는 형태로 “계산”해 내보낸다.

RPC로 구성 요소를 가볍게 연결한다

Cloudflare Workers의 내장 RPC 시스템은 Kitesurf 구조와 잘 맞는다.

다른 Worker의 메서드를 호출하고 객체를 넘기고, 같은 방식으로 다시 메서드를 부를 수 있다.

스키마나 인증을 복잡하게 설계하지 않아도 된다.

Kitesurf는 이 RPC를 이용해 Engine Worker가 PageRenderer Worker의 renderFrame()을 호출하고 PNG를 받아오도록 구성한다.

렌더러는 페이지 상태를 들고 있지 않기 때문에, 실패하거나 멈춘 호출이 생기면 엔진이 안전하게 새로 띄울 수 있다.

이 덕분에 각 렌더 요청은 독립적이고 재시도 가능하며, 비용도 낮아진다.

성능과 호환성은 어디까지 왔나

Kitesurf는 이미 215,000개가 넘는 WPT 테스트를 통과했고, 지금도 매주 수백 개의 통과 테스트가 늘고 있다.

에이전트에게 중요한 CSS, DOM, HTML, selection, SVG, XHR 같은 영역은 이미 꽤 좋은 커버리지를 갖췄다.

streams 같은 항목도 이제는 어느 정도 지원된다.

성능 비교에서는 관점이 중요하다.

동일한 14개 URL 코퍼스에서 Browser Run의 quick action을 비교했을 때, Chromium은 이미 해당 페이지를 본 JIT의 이점 때문에 stopwatch 기준으로 약 1.7배 빠르다.

다만 그 차이의 상당 부분은 rasterization과 JPEG/PNG 인코딩에서 나온다.

반면 Kitesurf는 메모리와 CPU 측면에서 3~7배 더 효율적이다.

이는 단순한 수치가 아니라 운영 비용과 확장성에 직접 연결된다.

더 적은 메모리로 더 많은 세션을 운영할 수 있고, bursty한 AI 워크로드에도 훨씬 잘 맞는다.

실제로 써볼 수 있는 방법

Kitesurf는 Browser Run에서 지금 바로 시험해 볼 수 있다.

베타 기간에는 무료로 제공되지만, 계정별 제한은 존재한다.

CDP endpoint는 이미 Kitesurf 옵션을 지원하므로, Puppeteer나 Playwright, chrome-remote-interface 같은 기존 클라이언트를 그대로 활용할 수 있다.

사용 포인트는 단순하다.

엔드포인트에서 browser=kitesurf 파라미터를 추가하면 된다.

Quick Actions에서도 같은 방식으로 지정할 수 있다.

예를 들어 특정 페이지의 스크린샷을 빠르게 얻거나, 호환되는 사이트에서 콘텐츠를 추출하거나, PDF를 생성하는 작업에 적합하다.

플레이그라운드에서 확인할 수 있는 것

공개 플레이그라운드에서는 URL을 입력해 Kitesurf가 페이지를 어떻게 렌더링하는지 직접 볼 수 있다.

Chrome DevTools가 UI에 통합되어 있어 확장된 DOM 요소를 확인한다.

콘솔 메시지를 읽고, 네트워크 활동도 추적할 수 있다.

또한 Memory 패널 관련 CDP 명령도 구현돼 있어, 각 isolate와 frame의 WebAssembly footprint를 확인할 수 있다.

에이전트 자동화에서 어떤 페이지가 자원을 얼마나 쓰는지 살피는 데 유용한 정보다.

언제 Kitesurf 브라우저가 더 적합한가

Kitesurf는 TodoMVC, Wikipedia, Hacker News, Cloudflare Blog, 그리고 Cloudflare dashboard의 상당 부분을 올바르게 렌더링한다.

다만 모든 사이트에 최적은 아니다.

브라우저의 특성과 작업의 요구가 맞아떨어질 때 가장 강하다.

다음과 같은 상황에서는 특히 잘 맞는다.

페이지 렌더링이 필요하지만 픽셀 완전성이 절대적이지 않은 경우
스크린샷이나 HTML 추출 같은 one-shot 작업이 필요한 경우
세션을 오래 유지하지 않고 빠르게 끝나는 자동화 작업
비용과 메모리 효율이 중요한 대규모 에이전트 워크로드

반대로 다음 작업은 아직 Chromium이 기본인 Browser Run 쪽이 더 적합하다.

비디오 재생
WebGL 렌더링
실제 TLS fingerprint가 중요한 봇 차단 우회 시도
10분 이상 지속되는 인증 세션과 강한 상태 유지

즉, Kitesurf 브라우저는 범용 대체재가 아니라, 에이전트 중심의 특정 작업에서 더 좋은 선택지다.

앞으로의 방향

Kitesurf는 아직 초기 단계다. 시작한 지 12주 정도밖에 되지 않았고, 첫 커밋은 5월에 있었다.

지금도 더 많은 CDP 범위, 더 나은 렌더링 충실도, 더 넓은 WPT 커버리지, 더 높은 효율성을 목표로 개선 중이다.

특히 스크린샷과 PDF의 품질은 계속 다듬는 중이다.

LLM은 종종 원본 텍스트보다 이미지를 더 잘 활용하기 때문에, 시각적 품질의 개선은 실사용성과 직결된다.

동시에 CPU, 메모리, wall time 벤치마크를 지속적으로 돌리며 효율도 함께 끌어올리고 있다.

Cloudflare는 Kitesurf를 머지않아 오픈소스로 공개할 계획도 가지고 있다.

목표는 사용자가 원하면 자신의 계정에 자신만의 Kitesurf 버전을 배포할 수 있게 하는 것이다.

핵심 정리

Kitesurf 브라우저는 인간 중심의 범용 브라우저가 아니라, AI 에이전트와 자동화 작업에 맞춰 다시 설계된 브라우저다.

Browser Run 안에서 동작하며, Chromium보다 일반적인 에이전트 작업에서 CPU와 메모리 효율이 높다는 점이 핵심이다.

완벽한 호환성을 대신하는 것이 아니라, 스크린샷·HTML 추출·PDF 생성 같은 작업에서 더 가볍고 안전한 선택지를 제공한다.

AI 에이전트용 브라우저를 찾고 있다면, Kitesurf는 지금 확인해 볼 가치가 있는 옵션이다.

Kitesurf 브라우저를 이해할 때는 개별 요소보다 전체 맥락과 연결 구조를 함께 보는 것이 중요합니다.

Kitesurf 브라우저의 효과는 실제 사례와 적용 조건을 함께 비교할 때 더 분명하게 확인할 수 있습니다.

Kitesurf 브라우저 관점에서는 주제 간 연관성과 반복되는 신호를 함께 살펴보는 것이 핵심입니다.