Kitesurf 소개: Cloudflare Workers의 V8 격리 환경에서 실행되는 에이전트 우선 브라우저 (새 탭에서 열림)
Cloudflare는 인간이 아닌 AI 에이전트에 최적화된 브라우저가 필요하다고 판단해, Workers 위에서 동작하는 헤드리스 브라우저 **Kitesurf**를 개발했다. Chromium이 제공하는 탭·확장 기능·정밀한 시각 렌더링보다 토큰 수, 확장성, 성능, 비용, 구조화된 콘텐츠 추출을 우선하며, 일반적인 에이전트 작업에서 CPU와 메모리 사용량을 크게 줄이는 것이 목표다. Kitesurf는 Browser Run에서 베타 서비스로 무료 제공된다. ## AI 에이전트에 기존 브라우저가 과한 이유 - Chromium 같은 브라우저 엔진은 인간 사용자를 중심으로 설계됐다. - AI 에이전트에는 다음 기능의 가치가 낮다. - 탭, 테마, 브라우저 확장 기능 - 여러 기기 간 동기화 - 픽셀 단위로 정확한 렌더링 - 부드러운 60fps 스크롤 - 반대로 에이전트에는 다음 요소가 중요하다. - 적은 토큰 수와 효율적인 컨텍스트 사용 - HTML 등 구조화된 콘텐츠 - 높은 처리량과 확장성 - 낮은 CPU·메모리 사용량과 비용 - AI 브라우저의 위협 모델도 인간용 브라우저와 다르다. - 임의의 웹사이트를 방문하는 에이전트는 모든 페이지를 신뢰할 수 없는 입력으로 다뤄야 한다. - 프롬프트 인젝션과 도구 사용 안전성이 핵심 보안 문제가 된다. ## Cloudflare 플랫폼이 가능하게 한 전환점 - Kitesurf는 Cloudflare Workers 위에서 전체적으로 실행된다. - 다음 기술 발전이 복잡한 브라우저 구현을 가능하게 했다. - Workers에서의 성숙한 WebAssembly 지원 - 동적 워커 - SQLite 기반 Durable Objects - 워커 간 RPC - 서비스 바인딩 - 향상된 Node.js 호환성 - 더 높은 실행 한도 - AI 에이전트용 브라우저 자동화 수요가 커지면서, 기존 Chromium 인스턴스를 에이전트마다 제공하는 방식의 비용 문제가 부각됐다. - Kitesurf는 이러한 환경에서 더 작고 저렴한 브라우저 실행 모델을 제공하려는 시도다. ## 초기 구현과 AI 활용 - 출발점은 Rust로 작성된 AI 자동화용 헤드리스 엔진 **obscura**였다. - Cloudflare 팀은 AI 에이전트의 도움을 받아 이를 Workers로 포팅했다. - 초기 결과는 불완전했지만, 명확한 실행 계획과 성공 조건을 제공하자 AI가 반복적으로 구현·검증하며 작동하는 프로토타입을 만들 수 있었다. - 이후 프로토타입을 기반으로 실제 대규모 서비스에 필요한 구조와 품질 기준을 마련했다. ## 테스트를 중심으로 한 개발 방식 - 복잡한 브라우저를 AI의 도움으로 빠르게 개발하려면, 구현 속도뿐 아니라 결과 품질을 통제해야 했다. - 이를 위해 가능한 많은 테스트를 성공 기준으로 제공했다. - **Web Platform Tests(WPT)**를 활용해 다음을 검증했다. - 웹 표준에 대한 기능 준수 여부 - 각 브라우저 기능의 구현 상태 - AI 에이전트가 작업을 완료했는지 판단할 수 있는 명확한 기준 - WPT만으로는 실제 웹사이트에서의 동작을 충분히 검증할 수 없기 때문에 추가 테스트도 도입했다. - Chromium과 Kitesurf 양쪽에서 실제 사이트를 대상으로 Puppeteer 통합 테스트 실행 - 여러 단계의 사용자 작업과 assertion 비교 - 각 단계의 렌더링 결과를 비교하는 시각적 회귀 테스트 - 예상하지 못한 렌더링 차이를 자동으로 표시 - AI 에이전트는 기능 구현을 담당하고, 사람은 아키텍처 설계와 구현 방식 검토에 집중하는 방식이다. ## Rust와 WebAssembly 선택 - Cloudflare는 C, C++, Rust 코드를 WebAssembly로 컴파일해 Workers에서 실행할 수 있다. - Emscripten을 사용하면 많은 의존성과 모의 계층이 추가되어 결과 바이너리가 커지고 실행이 느려질 수 있다. - Kitesurf는 가능한 한 네이티브 Rust로 구현하고 `wasm-bindgen`을 통해 WebAssembly로 직접 컴파일했다. - 이를 통해 불필요한 에뮬레이션 계층을 피하고, 성능과 안정성을 높였다. ## 예외 처리와 장애 격리 - 웹페이지는 잘못된 HTML, 예상 밖의 입력, 악의적인 콘텐츠를 포함할 수 있으므로 브라우저는 일부 기능이 실패해도 세션 전체를 중단해서는 안 된다. - Kitesurf의 원칙은 다음과 같다. - 오류가 발생하면 죽은 세션 대신 빈 프레임이나 누락된 요소로 처리 - 모든 경계에서 예외를 포착 - 안전하고 비어 있는 기본값 사용 - 문제를 진단할 수 있을 만큼 충분한 로그 기록 - 목표는 페이지 일부가 손상되더라도 브라우저 요청 자체는 계속 유지하는 것이다. ## 페이지와 컴포넌트의 격리 - AI 에이전트는 작업에 따라 임의의 출처에서 코드를 실행하거나 페이지를 방문할 수 있다. - 따라서 모든 페이지 로드를 신뢰할 수 없는 입력으로 취급하고, 모든 세션을 새로 시작한다. - 각 컴포넌트는 필요한 리소스에만 접근하도록 제한한다. - Workers의 격리 모델이 기본적인 보안 경계를 제공하지만, 그것만으로 충분하지 않다. - 애플리케이션 수준에서도 컴포넌트별 접근 권한을 정의해야 한다. - 한 페이지의 데이터나 리소스가 다른 페이지로 유출되지 않도록 별도로 보장해야 한다. ## 가능한 한 무상태로 설계 - 상태가 많을수록 장애 발생 후 복구 비용이 커진다. - 무상태 컴포넌트는 다음 장점을 가진다. - 실패하면 새 인스턴스를 만들고 요청을 다시 재생하면 됨 - 필요할 때 병렬로 대량 실행 가능 - 멈춘 인스턴스를 즉시 폐기 가능 - 트래픽이 급증하는 자동화 작업에 맞춰 수요 기반으로 확장 가능 - 사용한 만큼만 비용을 지불하고 작업 종료 후 리소스를 제거 가능 - 따라서 상태가 꼭 필요하지 않은 컴포넌트는 가능한 한 무상태로 구현한다. ## 실용적인 결론 AI 브라우저는 인간용 브라우저를 그대로 축소하는 것이 아니라, 구조화된 데이터 처리·낮은 비용·높은 확장성·강한 격리를 중심으로 다시 설계해야 한다. 브라우저 자동화 서비스를 구축할 때는 표준 테스트뿐 아니라 실제 사이트 통합 테스트와 시각적 회귀 테스트를 병행하고, Rust/WebAssembly·무상태 설계·방어적인 예외 처리를 활용하는 것이 효과적이다.
