클라우드플레어 카이트서핑, 메모리 7배 아끼고 속도는 느려

클라우드플레어(Cloudflare)가 인간이 아니라 AI 에이전트를 위한 새 브라우저 “카이트서핑(Kitesurf)”를 공개했다. 크롬(Chrome)의 대안을 노리는 여러 스타트업과 달리, 클라우드플레어는 일반 소비자용 브라우저가 아니라 AI 에이전트가 웹사이트를 탐색하고 양식을 채우는 등 작업을 대신 수행하도록 돕는 클라우드 기반 브라우저를 내놨다.

카이트서핑는 크로미움(Chromium) 엔진을 전혀 쓰지 않는다. 클라우드플레어의 서버리스 플랫폼 워커스(Workers) 위에서 V8 아이솔레이트(격리된 자바스크립트 실행 환경)만으로 완전히 동작한다. 회사는 개발에 착수한 지 12주 만에 이를 완성했다고 밝혔다. 현재 베타 기간에는 무료로, 헤드리스 브라우저 인스턴스를 프로그래밍 방식으로 제어할 수 있게 해주는 브라우저 런(Browser Run) 서비스를 통해 제공된다.

AI는 탭도 테마도 필요 없다

클라우드플레어는 공식 블로그에서 “브라우저를 직접 만들어야 하는가”라는 질문이 사내에서 몇 년째 반복돼 왔다고 밝혔다. 그동안은 기술적 난이도와 실익 사이 균형을 찾지 못해 계속 미뤄졌지만, 워커스 플랫폼의 기술적 진전과 AI 에이전트 수요 증가가 동시에 맞물리면서 12주 전 다시 이 질문을 던졌고 이번엔 “그렇다”는 답이 나왔다고 설명했다.

회사가 강조하는 핵심은 인간용 브라우저와 AI 에이전트용 브라우저의 요구사항이 근본적으로 다르다는 점이다. AI는 탭이나 테마, 브라우저 확장 기능, 기기 간 동기화에 관심이 없다. 대신 토큰 수, 컨텍스트 윈도(모델이 한 번에 처리하는 입력 범위), 확장성, 비용을 신경 쓴다. 시각적으로 완벽한 렌더링이나 60fps의 매끄러운 스크롤도 필요하지 않다. 클라우드플레어는 “구조화된, 기계가 읽을 수 있는 콘텐츠가 중요하지만 픽셀 단위의 완벽함은 그렇지 않다”고 설명했다. 위협 모델도 다르다. 프롬프트 인젝션 공격 같은, 인간용 브라우저에는 없던 새로운 보안 문제가 최우선 과제로 떠올랐다는 것이다.

크롬보다 CPU 최대 3.8배, 메모리 최대 7배 절감

클라우드플레어는 “카이트서핑는 스크린샷 촬영이나 HTML 추출 같은 일반적인 에이전트 작업에서 크로미움보다 CPU와 메모리 소비 측면에서 훨씬 효율적”이라고 밝혔다. 실제 벤치마크 수치도 공개됐다. 클라우드플레어의 14개 URL로 구성된 테스트 세트에서 다섯 차례 실행한 값의 중간값을 기준으로, 스크린샷 작업의 CPU 사용량은 카이트서핑가 380밀리초, 크로미움이 1,173밀리초로 약 3.1배 차이가 났다. HTML 추출 작업에서는 카이트서핑 229밀리초, 크로미움 877밀리초로 약 3.8배 차이였다.

메모리 사용량 차이는 더 컸다. 스크린샷 작업 시 메모리는 크로미움이 271.0MiB, 카이트서핑는 57.8MiB로 약 4.7배 적었다. HTML 추출 작업에서는 크로미움 273.7MiB 대비 카이트서핑 39.4MiB로 약 7.0배 적은 수준이었다. 다만 실제 처리 속도(월타임)에서는 크로미움이 여전히 빠르다. 카이트서핑는 스크린샷 작업에서 약 1.8배, HTML 추출에서 약 1.7배 더 느린데, 주로 래스터화(그림으로 변환)와 이미지 인코딩 단계에서 시간이 더 걸린다. 다만 비용을 좌우하는 요소는 CPU와 메모리이기 때문에, 짧고 폭발적으로 몰리는 에이전트 작업량에는 카이트서핑가 유리하다는 게 회사 설명이다. 참고로 카이트서핑는 게임 ‘둠(Doom)’을 구동할 수 있을 정도의 완성도도 갖췄다고 소개됐다.

Blitz·Stylo·Boa JS로 조립한 초경량 엔진

카이트서핑는 여러 오픈소스 구성 요소를 조합해 만들어졌다. HTML·CSS 렌더링에는 모듈형 러스트(Rust) 렌더링 엔진인 Blitz와, 파이어폭스(Firefox)의 CSS 파서인 Stylo를 사용했다. 워커스가 네이티브 eval을 지원하지 않기 때문에 이따금 필요한 eval 호출은 러스트 기반 ECMAScript 엔진인 Boa JS를 통해 처리한다.

전체 구조는 여러 개의 독립된 워커스 컴포넌트로 나뉜다. 외부에 노출되는 유일한 요소인 ‘엔진(Engine)’은 크롬 개발자도구 프로토콜(CDP)을 웹소켓과 HTTP REST로 지원하며 세션 상태를 저장한다. ‘페이지스크립트(PageScript)’는 다이내믹 워커스를 기반으로, 페이지나 프로세스 외부 iframe마다 별도의 격리 실행 환경을 부여받는다. 화면을 실제 이미지나 PDF로 변환하는 ‘페이지렌더러(PageRenderer)’는 blitz-paint와 텍스트 배치 라이브러리 Parley를 활용한다. 네트워크에 접근할 수 있는 유일한 컴포넌트인 ‘샌드박스아웃바운드(SandboxOutbound)’ 워커는 CORS 정책을 강제하고 브라우저처럼 보이는 헤더를 주입하며, 정책을 위반하는 요청에는 403 오류를 돌려준다.

클라우드플레어는 카이트서핑가 러스트 기반 오픈소스 헤드리스 엔진 오브스쿠라(Obscura)에서 영감을 받았다고 밝혔다. 최초의 개념 증명은 오브스쿠라를 워커스로 옮기는 작업이었다고 설명했다. 현재 카이트서핑는 21만5000건 이상의 웹 플랫폼 테스트(W3C 표준 준수 여부를 확인하는 테스트 모음)를 통과했으며 매주 새로운 테스트가 추가되고 있다. 실제 렌더링 성능도 입증됐는데, TodoMVC(자바스크립트 프레임워크 비교용 벤치마크 앱)의 바닐라·리액트·뷰·앵귤러·프리액트 버전은 물론 위키피디아, 해커뉴스, 클라우드플레어 블로그와 대시보드 대부분을 정상적으로 렌더링한다.

기존 도구와 호환되지만 아직 한계도 뚜렷

개발자 입장에서 도입 장벽은 낮은 편이다. 기존에 쓰던 퍼피티어(Puppeteer), 플레이라이트(Playwright), chrome-remote-interface, MCP 클라이언트를 그대로 두고 브라우저 런 CDP 엔드포인트나 퀵액션 API에 browser=kitesurf라는 파라미터 하나만 추가하면 카이트서핑를 쓸 수 있다. 웹 데이터 추출, SaaS 자동화, 경쟁사 모니터링, PDF·문서 생성, 검색·RAG(검색 증강 생성) 인입 파이프라인 등이 대표적인 활용 사례로 꼽힌다.

다만 아직 제공되지 않는 기능도 있다. 동영상 재생, WebGL, TLS 지문 기반 봇 차단 우회, 오래 유지되는 로그인 상태의 세션 등은 지원하지 않으며 이런 작업은 여전히 크로미움 기반 기본 브라우저로 처리해야 한다. 클라우드플레어는 향후 카이트서핑를 오픈소스로 공개해 고객이 자체 인스턴스를 직접 구축할 수 있도록 할 계획이라고 밝혔다. 챗봇 중심이던 AI 소프트웨어가 실제 웹 작업을 대신 수행하는 에이전트로 진화하는 흐름 속에서, 브라우저 인프라를 둘러싼 경쟁도 본격화하는 양상이다.