2026년 8월 6일, Cloudflare는 사람을 위한 것이 아니라 에이전트를 위한 브라우저인 Kitesurf를 발표했습니다. 내부에는 Chromium이 없으며, 엔진은 Rust로 작성되어 WebAssembly로 컴파일되고 Workers의 V8 격리 환경에서 완전히 작동합니다. 회사는 일반적인 에이전트 작업에서 CPU와 메모리를 Chromium보다 3~7배 적게 사용한다고 주장합니다. 이보다 4개월 전, 오픈소스 Obscura가 GitHub에서 22,000개 이상의 별을 모았으며, Cloudflare는 Kitesurf의 첫 번째 프로토타입이 Workers에 대한 Obscura의 포트였다고 직접 인정했습니다.
자동화 엔진 시장은 두 가지로 나뉘었습니다: 한쪽은 자원을 절약하는 경량 에이전트 런타임이고, 다른 쪽은 모든 것을 처리할 수 있는 무거운 Chromium 빌드입니다. 각 클래스가 실제로 제공하는 것과 절약이 끝나는 지점을 사실에 기반하여 분석해 보겠습니다.
어떤 기준으로 비교할 것인가
엔진의 벤치마크는 속도와 메모리로 경쟁하는 것을 좋아하지만, 전투 스크래핑과 에이전트에게는 네 가지 독립적인 축이 중요하며, 첫 번째 축에서의 이익이 나머지에 대해 아무것도 말하지 않습니다:
- 시작 비용 — 페이지당 CPU와 메모리. 이는 수천 개의 병렬 세션에서 인프라 비용으로 직접 변환됩니다.
- 웹 플랫폼의 완전성 — 얼마나 많은 현대 웹사이트가 올바르게 렌더링되는지. 여기서는 Web Platform Tests (WPT)로 커버리지를 측정합니다.
- 안티봇 통과율 — 세션이 TLS 핸드셰이크, JS 챌린지 및 행동 검사를 통과할 수 있을지 여부.
- 네트워크 출구 제어 — 요청을 사이트가 어떤 IP와 ASN으로 보는지 제어할 수 있는지 여부.
Kitesurf: 절약 대 완전성
Kitesurf는 모듈로 구성되어 있습니다: Blitz에서 HTML/CSS 렌더링 및 파싱, Firefox의 CSS 엔진 Stylo, Rust로 작성된 JS 런타임 Boa, Parley를 통한 텍스트 쉐이핑. 회사에 따르면 개발은 12주가 소요되었습니다.
Cloudflare의 자체 벤치마크 수치와 Chromium의 비교:
- 스크린샷당 CPU — 380 ms 대 1173 ms (3.1배 적음);
- HTML 추출당 CPU — 229 ms 대 877 ms (3.8배 적음);
- 스크린샷당 메모리 — 57.8 MiB 대 271 MiB (4.7배 적음);
- HTML 추출당 메모리 — 39.4 MiB 대 273.7 MiB (7배 적음);
- 하지만 Kitesurf의 실행 시간은 느립니다: 스크린샷에서 1148 ms 대 637 ms, HTML에서 820 ms 대 472 ms로 1.7~1.8배 느립니다.
이는 정직한 교환입니다: 지연을 감수하지만 한 대의 머신에서 훨씬 더 많은 병렬 세션을 유지할 수 있는 가능성을 얻습니다. 웹 표준에 따르면 엔진은 나이에 비해 나쁘지 않으며, 발표 당시 약 215,000개의 WPT 서브 테스트를 통과했으며, 현재 문서에서는 235,000개 이상으로 보고되고 있습니다. 섹션별 커버리지: DOM 97%, HTML 96%, Selection 99%, SVG 97%, Encoding 99%, CORS 95%, XHR 95%, URL 83%. 위키피디아, 해커 뉴스 및 일반적인 SPA가 렌더링됩니다.
Kitesurf는 일반적으로 연결됩니다: CDP 엔드포인트 (즉, Puppeteer 및 Playwright), 에이전트를 위한 MCP, 스크린샷 및 HTML 추출을 위한 Quick Actions의 REST 엔드포인트. browser=kitesurf 매개변수만 추가하면 됩니다. 베타는 무료지만 계정에 제한이 있으며, 소스 코드는 공개할 예정입니다.
Kitesurf가 할 수 없는 것 — 그리고 이는 그의 문서에도 명시되어 있습니다
제한 목록은 짧지만 현대 사이트의 모든 방어선을 통과합니다. Kitesurf는 다음을 지원하지 않습니다:
- 비디오 재생;
- WebGL 렌더링;
- 실제 TLS 지문으로 봇 챌린지 핸드셰이크;
- 지속적인 상태가 필요한 긴 인증 세션.
세 번째 항목은 핵심입니다. Cloudflare는 스스로 이렇게 씁니다: 만약 작업이 봇 챌린지에 부딪힌다면, 일반 Chromium을 Browser Run에서 사용하세요. 즉, 수백만 개의 사이트에서 이러한 챌린지를 설정하는 회사가 자신의 경량 브라우저가 이를 통과하지 못한다고 솔직하게 경고합니다. 이는 베타의 미비가 아니라 아키텍처의 결과입니다: TLS 지문 (JA3/JA4)은 네트워크 스택에서 생성되며, 렌더러가 아닌 Workers의 격리된 Rust 엔진은 실제 Chrome과 물리적으로 다르게 핸드셰이크됩니다.
비표준 엔진의 부수적 효과는 독창성입니다. 안티봇 스크립트는 수년간 Chromium의 아티팩트에 맞춰 조정되었습니다: 속성의 순서, 오류의 특성, API의 타이밍. 이러한 아티팩트가 없는 엔진은 "더 깨끗하게" 보이지 않으며, 다르게 보입니다. 그리고 "다르게"는 안티봇 점수에서 "모두와 같음"보다 더 비쌉니다. 우리는 이미 2026년 스텔스 브라우저 리뷰에서 이 효과를 분석했습니다: JS 지문 청결도에 대한 벤치마크와 실제 목표에서의 결과가 다릅니다. 왜냐하면 실제 목표는 신호의 집합을 고려하기 때문입니다.
Obscura: 같은 클래스지만 서버에서
Obscura는 이 클래스의 주요 오픈소스 대표입니다. 리포지토리는 2026년 4월 13일에 생성되었으며, Apache-2.0 라이센스를 가지고 있으며, 8월 말 기준으로 22,000개 이상의 별을 보유하고 있습니다. 내부에는 실제 V8이 있으며, 외부에는 CDP가 있어 Puppeteer 및 Playwright의 헤드리스 Chrome에 대한 드롭인 대체품입니다.
핵심 아키텍처 결정: Obscura는 렌더링 및 그리기 파이프라인이 없으며, 이미지를 전혀 그리지 않습니다. 따라서 저자의 벤치마크 수치는 33개 시나리오의 중앙값이 헤드리스 Chrome에 비해 약 21배의 속도와 약 1/7의 메모리를 제공합니다. React 페이지를 네 개의 워커에서 지속적으로 로드할 경우, 이는 112MB의 메모리로 초당 40페이지를 처리하며, Chrome에서는 초당 3페이지를 처리합니다. WPT의 "코어" 커버리지는 83.3%로, 382,891개 중 318,916개의 서브 테스트를 통과했습니다.
Kitesurf와의 실제 차이는 속도가 아니라 모든 것이 실행되는 위치입니다. Obscura는 직접 배포하며, 어떤 네트워크 출구를 통해 이동할지 스스로 결정합니다. Kitesurf는 타인의 네트워크에서 작동하며, 이는 우리의 주요 포인트로 이어집니다.
누가 당신의 아웃바운드 IP를 소유하는가
CPU 절약에 대한 이야기는 모두가 했지만, 네트워크 출구에 대한 이야기는 거의 없습니다. Kitesurf는 Workers에서 실행되므로 요청은 Cloudflare의 네트워크에서 나가며, 그 ASN을 사용합니다. Kitesurf 문서에는 아웃바운드 IP를 제어하거나 자체 프록시를 연결하는 방법이 없습니다. 인근의 Browser Rendering에서도 개발자들은 같은 문제에 직면합니다: proxyServer를 통해 업스트림 프록시를 설정하려고 하면 net::ERR_PROXY_CONNECTION_FAILED 오류가 발생하며, Workers에 대한 고정된 전용 egress 주소는 기본적으로 제공되지 않습니다.
Cloudflare의 목표 시나리오에서는 이는 괜찮습니다: 에이전트는 공개 페이지를 탐색하고 스크린샷을 찍고 HTML을 추출합니다. 그러나 목표가 조금이라도 보호받고 있다면, 당신은 가능한 신호 조합 중 최악의 조합을 얻게 됩니다:
- IP는 대형 클라우드 ASN에 속하므로 서버로 분류됩니다;
- TLS 지문은 어떤 실제 브라우저와도 일치하지 않습니다;
- 둘 다 변경할 수 없으며, 네트워크 스택이나 출구를 소유하지 않기 때문입니다.
이러한 상황은 2026년 에이전트에 대한 논의가 런타임 최적화가 아니라 합법적이고 유료 접근에 대한 질문으로 점점 더 많이 이동하는 이유를 설명합니다 — 서명된 에이전트에서 유료 요청에 이르기까지, 우리는 봇과 HTTP 402에 대한 지갑 분석에서 이를 다루었습니다. 사이트가 당신을 차단한다면, 세계에서 가장 경제적인 엔진도 도움이 되지 않습니다: 당신은 단순히 페이지를 받지 못했기 때문에 더 저렴하게 만들 수 없습니다.
작업에 따라 선택하기
Kitesurf — 목표가 공개적이고 많을 때: 공개 페이지 모니터링, RAG 인덱스를 위한 HTML 추출, 대량 스크린샷, 저렴한 에이전트 문서 우회. 또한 무료 베타와 인프라에 대한 번거로움이 없습니다. 로그인, 안티봇 또는 특정 지리적 요구가 있는 곳에는 사용하지 마세요.
Obscura — 같은 부하 프로필이지만 제어가 필요할 때: 자체 호스팅, 자체 네트워크 출구, 자체 패치. 페이지 가격이 중요하고 페이지의 외관은 전혀 중요하지 않은 파싱 파크의 작업 말뚝으로 적합합니다. 프로시와의 호환성이 기본적으로 좋습니다. 왜냐하면 전체 프로세스를 관리하기 때문입니다.
Playwright 또는 Puppeteer의 일반 Chromium — 비디오, WebGL, 복잡한 인증 세션 및 실제 렌더링이 필요할 때. 자원 소모는 크지만 예측 가능성이 있습니다.
스텔스 Chromium 빌드 (Camoufox, nodriver, patchright, 그리고 최근에는 2026년 2월부터 30,000개 이상의 별을 받은 CloakBrowser) — 목표가 보호받고 다른 옵션이 없을 때. 자원 소모는 일반 Chromium보다 약간 높지만, 가장 중요한 점은 실제 네트워크 스택이 유지되어 필요한 출구를 삽입할 수 있다는 것입니다.
세 가지 마지막 옵션의 공통점: 엔진은 브라우저 수준에서 당신이 어떻게 보이는지를 결정하고, 레지던셜 프록시는 네트워크 수준에서 당신이 어떻게 보이는지를 결정합니다. 공개 목표와 내부 작업에는 서버 주소로 충분합니다 — 이들은 더 저렴하고 빠릅니다. 실제 보호가 있는 사이트에서는 페이지 가격이 메가바이트 메모리가 아니라 성공적인 응답 비율에 따라 결정됩니다.
결론
Kitesurf와 Obscura는 실제 문제에 대한 정직하고 성공적인 답변입니다: HTML 추출을 위해 Chromium을 사용하는 것은 정말로 낭비이며, Apify와 The Web Scraping Club의 보고서가 이를 확인합니다 — 2025년에는 65.8%의 전문가가 이전 해보다 더 많은 프록시를 사용했으며, 58.3%는 예산을 늘렸습니다. 자동화 비용이 증가하고 있으며, 메모리에서 3~7배의 절약은 중대한 논거입니다.
하지만 절약은 첫 번째 보호된 목표까지 작동합니다. 경량 엔진은 봇 챌린지를 통과하지 못합니다 — 이는 Cloudflare의 문서에 명시되어 있습니다. 클라우드 런타임은 아웃바운드 IP를 제어할 수 없습니다. 따라서 2026년 에이전트 스택은 두 개의 독립적인 층으로 구성됩니다: 공개 페이지에 대한 저렴한 엔진과 모든 나머지에 대한 완전한 브라우저와 관리 가능한 네트워크 출구. 두 층을 하나의 도구로 통합하려는 시도는 Rust로 충분한 곳에서 Chromium에 대해 과도한 비용을 지불하거나 IP가 부족한 곳에서 파서의 제로 전환으로 끝납니다.
```