클라우드플레어가 에이전트 전용 브라우저 카이트서프를 공개했다: 크로미움 대비 CPU 3.8배, 메모리 7배 적게 쓴다

클라우드플레어는 2026년 8월 6일 AI 에이전트 전용 브라우저 카이트서프(Kitesurf)를 베타로 공개했다. 공식 발표 글에 따르면 이 브라우저는 크로미움을 쓰지 않고 러스트 기반 렌더링 엔진 블리츠(Blitz)와 파이어폭스의 CSS 엔진 스타일로(Stylo), 러스트 자바스크립트 엔진 보아(Boa JS)를 조합해 클라우드플레어 워커스 위에서 통째로 돌아간다. 자체 측정에서 HTML 추출 작업의 CPU 시간은 229밀리초로 크로미움 웜풀의 877밀리초 대비 3.8배 적었고, 메모리는 39.4MiB로 273.7MiB 대비 7.0배 적었다. 대신 벽시계 시간은 1.7배에서 1.8배 느리다. ASAP은 클라우드플레어 공식 발표 글을 1차 출처로 이 브라우저가 실제로 무엇을 바꾸고 무엇을 바꾸지 않는지 구분한다.

크로미움을 걷어내고 러스트 엔진 세 개를 조립한 구조

카이트서프의 핵심 설계는 브라우저 엔진을 통째로 교체한 데 있다. 클라우드플레어는 HTML과 CSS 렌더링에 모듈형 러스트 렌더러 블리츠를 쓰고, CSS 파싱에는 파이어폭스가 쓰는 고성능 엔진 스타일로를 붙였으며, 자바스크립트 실행에는 러스트로 작성된 ECMAScript 엔진 보아를 사용한다고 밝혔다. 발표 글은 러스트 헤드리스 엔진 옵스큐라(Obscura)에서 초기 착상을 얻었다고 적었다. 이 조합 전체가 클라우드플레어 워커스라는 서버리스 런타임 위에서 상태 없이(stateless) 실행된다.

설계 의도는 발표 글에 직접 적혀 있다. 크로미움 같은 기존 브라우저가 "에이전트가 아니라 사람을 위해 만들어졌다"는 것이 출발점이며, 탭과 테마, 픽셀 단위로 정확한 렌더링 대신 토큰 수와 컨텍스트 창, 확장성, 성능, 비용을 우선했다는 서술이다. 웹 호환성 지표로는 웹 플랫폼 테스트(WPT) 21만 5천 건 이상을 통과하며 매주 수백 건씩 늘고 있다고 밝혔고, CSS와 DOM, HTML, 선택 영역, SVG, XHR, 스트림 영역에서 통과율이 높다고 적었다. 실제 렌더링 확인 사례로는 TodoMVC와 위키백과, 해커뉴스, 클라우드플레어 블로그와 대시보드를 들었다.

프로젝트 자체는 신생이다. 발표 글은 2026년 5월에 개발을 시작해 공개 시점 기준 12주가 됐다고 밝혔으며, 개발 과정에 AI 에이전트를 활용했다고 적었다. 접근 경로는 브라우저 런(Browser Run)의 CDP 엔드포인트와 퀵 액션 API, 공개 플레이그라운드 세 가지이고, 퍼피티어와 플레이라이트, chrome-remote-interface, MCP 클라이언트 같은 기존 도구가 그대로 붙는다. 호출에 browser=kitesurf 인자를 더하는 방식이며 베타 기간에는 무료다.

절감은 CPU와 메모리에서 나오고 대가는 벽시계 시간에서 치른다

카이트서프의 성능 수치는 한 방향으로만 좋지 않고 명확한 교환 관계를 이룬다. 클라우드플레어가 크로미움 웜풀과 비교해 제시한 값을 보면 스크린샷 작업의 CPU 시간은 380밀리초 대 1,173밀리초로 3.1배 적고, HTML 추출은 229밀리초 대 877밀리초로 3.8배 적다. 메모리는 격차가 더 크다. 스크린샷에서 57.8MiB 대 271.0MiB로 4.7배, HTML 추출에서 39.4MiB 대 273.7MiB로 7.0배 적다. 반대로 벽시계 시간은 1.7배에서 1.8배 느리며, 발표 글은 그 원인을 소프트웨어 렌더링으로 설명했다.

이 두 축이 갈리는 지점이 실무 판단의 핵심이다. CPU와 메모리는 서버리스 과금과 동시 실행 한도를 결정하는 자원이고, 벽시계 시간은 사용자가 체감하는 지연이다. 메모리를 7분의 1로 줄이면 같은 하드웨어에서 동시에 띄울 수 있는 브라우저 수가 늘어나므로, 수천 개 페이지를 병렬로 훑는 작업에서는 전체 처리량이 올라간다. 반면 사용자의 질문 하나에 대해 페이지 한 장을 열어 답하는 대화형 경로에서는 1.8배 지연이 그대로 응답 시간에 얹힌다.

따라서 이 브라우저의 도입 판단은 성능 비교가 아니라 작업 형태의 분류 문제가 된다. 야간 배치로 도는 대량 수집, 지표 모니터링, 문서 인덱싱처럼 지연에 둔감하고 건수가 많은 작업은 카이트서프 쪽 계산이 유리하다. 사람이 기다리는 실시간 에이전트 응답은 크로미움 쪽 지연 우위가 유지된다. 하나를 전면 교체하는 대신 작업 유형별로 두 엔진을 나눠 쓰는 구성이 이 수치에서 도출되는 결론이다.

지원하지 않는 기능 네 가지가 이 브라우저의 경계를 그린다

카이트서프가 아직 지원하지 않는 항목은 네 가지로 명시돼 있다. 발표 글은 영상 재생과 WebGL 렌더링, 봇 차단 TLS 지문 협상, 수 분 단위로 이어지는 인증 세션 유지를 미지원으로 적었다. 상태 없이 워커스 위에서 도는 구조를 고려하면 마지막 항목은 설계의 직접적 귀결이다.

이 목록은 단순한 미완성 기능 나열이 아니라 대상 작업의 경계선이다. 앞의 두 항목이 빠졌다는 것은 이 브라우저가 화면을 사람 눈에 보이게 재현하는 일보다 문서를 읽어 텍스트로 환원하는 일에 최적화됐다는 뜻이다. 뒤의 두 항목이 빠졌다는 것은 더 중요하다. 로그인 상태를 유지하며 여러 단계를 밟는 작업, 즉 사람 대신 계정에 들어가 무언가를 처리하는 유형의 에이전트는 현재 이 브라우저로 구현되지 않는다.

정리하면 카이트서프는 웹을 읽는 에이전트를 위한 도구이고, 웹에서 행동하는 에이전트를 위한 도구는 아직 아니다. 최근 에이전트 브라우저 경쟁이 예약과 결제, 양식 제출 같은 행동 자동화를 겨냥해 온 것과 비교하면 방향이 정반대다. 클라우드플레어는 사람이 쓰던 브라우저를 에이전트에게 넘기는 대신, 에이전트가 대량으로 반복하는 읽기 작업의 단가를 낮추는 쪽을 택했다.

브라우저가 제품이 아니라 인프라 원가 항목으로 재정의된다

이번 공개에서 읽어야 할 변화는 브라우저의 위치가 바뀌었다는 점이다. 클라우드플레어가 탭과 테마, 픽셀 정확도를 버리고 토큰 수와 컨텍스트 창, 비용을 우선순위로 명시한 것은 브라우저를 사용자 제품이 아니라 서버 원가 항목으로 다루겠다는 선언이다. 사람이 쓰는 브라우저에서는 렌더링 충실도가 품질이지만, 에이전트가 쓰는 브라우저에서는 페이지 한 장을 처리하는 데 드는 CPU 초와 메모리, 그리고 그 결과가 몇 토큰으로 요약되는지가 품질이다.

이 관점이 성립하면 경쟁의 기준선도 달라진다. 지금까지 브라우저 엔진의 우열은 웹 표준 준수도와 렌더링 정확도로 매겨졌고, 크로미움의 지배력은 그 축에서 나왔다. 반면 원가 항목으로서의 브라우저는 단가와 동시성으로 평가되며, 이 축에서는 21만 5천 건이라는 WPT 통과 수가 목표가 아니라 최소 요건이 된다. 클라우드플레어가 WPT 수치를 자랑하면서도 픽셀 정확도를 포기했다고 명시한 배치가 이 이중 기준을 그대로 드러낸다.

주목할 점은 이 회사가 그 원가를 낮출 위치에 있다는 사실이다. 클라우드플레어는 이미 대량의 웹 트래픽이 통과하는 엣지 네트워크를 운영하며, 카이트서프는 별도 인프라가 아니라 그 위의 워커스에서 돈다. 엔진을 가볍게 만드는 일과 그 엔진을 이미 깔린 네트워크에 얹는 일이 결합되면, 에이전트의 웹 접근 비용을 정하는 주체가 브라우저 벤더에서 네트워크 사업자로 옮겨간다. 이 이동이 이번 발표의 실질적 함의다.

국내 조직이 지금 시험해볼 지점과 미뤄야 할 지점

국내 조직에 이번 공개가 갖는 의미는 기존 코드를 고치지 않아도 시험이 가능하다는 데 있다. 퍼피티어와 플레이라이트, MCP 클라이언트가 그대로 붙고 호출에 browser=kitesurf 인자만 더하면 되므로, 이미 헤드리스 브라우저로 수집이나 검증 자동화를 돌리는 팀은 파이프라인 구조를 유지한 채 엔진만 바꿔 비교할 수 있다. 베타 기간 무료라는 조건까지 감안하면 시험 비용은 사실상 인건비뿐이다.

먼저 시험할 대상은 건수가 많고 지연에 둔감한 작업이다. 상품 정보 수집, 경쟁사 페이지 모니터링, 사내 문서 인덱싱, 배포 후 정적 페이지 회귀 검증처럼 밤사이 수천 건을 도는 작업이 여기 해당한다. 이런 작업에서 메모리 7분의 1은 동시 실행 수를 늘려 전체 소요 시간을 줄이는 방향으로 작용하므로, 개별 요청이 1.8배 느려지는 손해를 상쇄한다.

반대로 미뤄야 할 대상도 분명하다. 로그인이 필요한 내부 시스템 자동화, 결제나 예약처럼 여러 단계를 이어가는 흐름, 영상이나 WebGL이 포함된 페이지 검증은 현재 미지원 목록에 정면으로 걸린다. 봇 차단 TLS 지문 협상을 지원하지 않는다는 점도 실무에서는 큰 제약이다. 봇 차단이 걸린 외부 사이트를 대상으로 하는 수집 작업은 지금 단계에서 성립하지 않는다고 보고 계획을 세워야 한다.

한 가지 더 짚을 조건은 데이터 경로다. 카이트서프는 클라우드플레어 워커스에서 실행되므로 대상 페이지의 내용이 해당 네트워크를 통과한다. 내부망 문서나 개인정보가 포함된 페이지를 다루는 작업이라면 성능 수치보다 이 경로를 먼저 검토해야 한다. 자체 서버에서 돌리는 헤드리스 크로미움과 달리 선택지가 서비스 이용으로 고정되며, 오픈소스 공개 전까지는 자체 구축이라는 대안이 없다.

이 수치를 그대로 인용하기 어렵게 만드는 조건

성능 수치의 신뢰도를 제한하는 첫째 조건은 자체 측정이라는 점이다. CPU와 메모리 비교값은 모두 클라우드플레어가 자사 발표 글에 실은 값이며, 비교 대상인 크로미움 웜풀의 구성과 측정 방법을 외부에서 검증할 수 없다. 카이트서프는 아직 오픈소스가 아니고 발표 글은 "준비되는 대로 오픈소스로 공개하겠다"고만 적었으므로, 제3자가 같은 조건을 재현할 방법이 현재로서는 베타 API 이용뿐이다.

둘째 조건은 측정 대상 작업의 범위다. 제시된 수치는 스크린샷과 HTML 추출 두 가지 작업에서 나왔고, 발표 글도 이를 "일반적인 에이전트 작업"이라고 표현했다. 자바스크립트를 무겁게 쓰는 단일 페이지 애플리케이션이나 렌더링이 복잡한 문서에서 같은 배율이 유지되는지는 이 두 수치로 확정되지 않는다. 러스트 자바스크립트 엔진 보아가 V8과 동일한 실행 성능을 낸다는 근거도 발표 글에 제시되지 않았다.

셋째 조건은 호환성 지표의 성격이다. WPT 21만 5천 건 통과는 표준 적합성의 지표이지 실제 웹 호환성의 지표가 아니다. 상용 웹에는 특정 엔진의 동작에 맞춰 작성된 페이지가 다수 존재하며, 발표 글이 렌더링 확인 사례로 든 곳도 TodoMVC와 위키백과, 해커뉴스, 자사 블로그와 대시보드로 비교적 단순한 구조에 속한다. 실무 도입 판단은 이 목록이 아니라 각 조직이 실제로 훑는 대상 사이트에서 직접 확인해야 한다.

확정까지 남은 세 가지 관문

카이트서프의 실제 가치는 오픈소스 공개와 미지원 목록 축소, 베타 이후 과금 체계라는 세 가지 지점에서 확정된다. 첫째 관문은 오픈소스 공개다. 코드가 공개되면 자체 측정 수치를 제3자가 재현할 수 있고, 자체 구축이라는 선택지가 열려 데이터 경로 문제도 해소된다. 공개 시점과 라이선스 조건이 이 브라우저의 채택 폭을 사실상 결정한다.

둘째는 미지원 목록의 축소 여부다. 인증 세션 유지와 TLS 지문 협상이 지원되면 대상 작업이 읽기에서 행동으로 넓어지고, 그 순간 이 브라우저는 에이전트 브라우저 경쟁의 다른 진영과 정면으로 겹친다. 상태 없는 워커스 구조와 세션 유지가 어떻게 조화되는지가 기술적 관건이다.

셋째는 베타 이후 가격이다. 현재 무료라는 조건이 시험 진입 장벽을 없앴지만, 이 브라우저의 존재 이유가 원가 절감인 이상 정식 과금 체계가 나와야 크로미움 대비 실질 이득을 계산할 수 있다. CPU 3.8배와 메모리 7.0배라는 절감폭이 청구서에서 몇 배로 환산되는지가 마지막 관문이다.

출처: 클라우드플레어 공식 발표 글 blog.cloudflare.com/kitesurf/(2026년 8월 6일, 셀소 마르티뉴), 테크크런치 "Cloudflare launches Kitesurf, a browser built for AI agents"(2026년 8월 7일)