에이전트를 위해 덜어낸 브라우저
Kitesurf는 Cloudflare가 AI 에이전트용으로 만든 헤드리스 브라우저 엔진이다. 사람이 화면을 보며 탭과 확장 프로그램을 사용하는 데스크톱 브라우저가 아니라, 에이전트가 웹페이지를 읽고 상호작용하는 작업에 초점을 맞춘다. Cloudflare Workers의 V8 격리 환경에서 완전히 실행되며 Browser Run을 통해 제공된다.
출발점은 Chromium 같은 기존 브라우저 엔진이 사람을 위해 설계됐다는 문제의식이다. 탭, 테마, 기기 간 동기화, 확장 프로그램과 부드러운 화면 스크롤은 사람에게 유용하지만 에이전트 작업에서는 우선순위가 낮다. 에이전트에는 토큰 수, 컨텍스트 크기, 확장성, 처리 성능과 비용이 더 중요하며, 시각적으로 완벽한 화면보다 구조화된 기계 판독 가능 콘텐츠가 더 유용할 수 있다.
Cloudflare는 HTML 추출과 스크린샷 생성 같은 일반적인 에이전트 작업에서 Kitesurf가 Chromium보다 CPU와 메모리를 더 효율적으로 사용한다고 주장한다. 다만 원문에는 작업별 측정값이나 동일 조건의 상세 벤치마크가 없다. 따라서 이를 입증된 성능 배수로 받아들이기보다는 제품의 설계 목표로 이해해야 한다. 실제 도입 판단에는 대상 사이트와 요청 패턴을 사용한 직접 비교가 필요하다.
Chromium의 범용 대체재는 아니다
Kitesurf의 우선 목표는 픽셀 단위로 정확한 화면을 재현하는 것이 아니다. CSS 해석이 다소 어긋나거나 렌더링이 완벽하지 않더라도 에이전트가 작업을 수행하는 데 필요한 콘텐츠와 인터페이스를 효율적으로 제공한다는 관점이다.
이 차이를 고려하면 디자인 검수, 광고 노출 확인, 반응형 레이아웃 점검과 브라우저별 시각 차이 확인처럼 화면 재현성이 중요한 업무에는 Chromium 기반 자동화가 더 적합할 수 있다. 반대로 문서 수집, HTML 추출과 반복적인 웹 탐색처럼 결과의 구조와 처리 효율이 중요한 작업에서는 Kitesurf를 비교 후보로 둘 만하다. 스크린샷도 생성할 수 있지만 데이터 수집용인지 정확한 시각 재현용인지에 따라 평가 기준을 달리해야 한다.
| 작업 | 평가할 사항 |
|---|---|
| HTML·문서 추출 | 필요한 본문, 링크와 문서 구조가 빠지지 않는지 확인 |
| 반복적인 웹 탐색 | 페이지 이동과 상호작용이 안정적으로 이어지는지 확인 |
| 스크린샷 생성 | 처리 효율과 화면 재현 정확도를 목적에 맞게 비교 |
| 디자인 회귀 테스트 | Chromium 결과와 허용하기 어려운 시각 차이가 생기는지 확인 |
| 확장 프로그램 기반 자동화 | 기존 작업이 Kitesurf가 중시하지 않는 기능에 의존하는지 점검 |
Workers 위에서 실행되는 구조
Cloudflare는 Workers의 WebAssembly 실행 기반이 성숙했고 동적 Worker, SQLite 기반 Durable Objects, Worker 간 RPC, 서비스 바인딩, 향상된 Node.js 호환성과 실행 한도가 복잡한 애플리케이션을 가능하게 했다고 설명한다. Kitesurf는 이러한 플랫폼 발전과 에이전트용 브라우저 수요가 맞물린 결과다.
설계 원칙 가운데 하나는 가능한 구성 요소를 상태 비저장으로 만드는 것이다. 보존할 상태가 없다면 장애 때 구성 요소를 재구축하는 대신 새 인스턴스를 시작하고 요청을 다시 실행할 수 있다. 작업이 몰릴 때 병렬로 늘리고 사용이 끝나면 사라지는 방식도 간헐적으로 집중되는 자동화 부하와 맞는다.
그렇다고 모든 브라우징 상태가 자동으로 사라져도 된다는 뜻은 아니다. 실제 자동화에는 로그인 세션, 쿠키와 작업 중간 결과처럼 이어서 사용해야 할 정보가 생길 수 있다. 도입 전에는 어떤 상태를 보존해야 하는지, 요청 재실행으로 복구할 수 있는 범위와 애플리케이션이 별도로 관리할 정보를 구분해야 한다.
구현과 품질 관리
표준 테스트와 실제 사이트 테스트의 결합
Cloudflare는 Web Platform Tests로 웹 표준 기능의 적합성을 검증했다. 기능과 구현 순서를 정리해 AI 에이전트에 성공 조건을 제공하고, 사람은 구조 설계와 에이전트가 제안한 접근 방식의 검토에 집중했다. Kitesurf는 에이전트용 도구인 동시에 개발 과정에서도 AI 에이전트를 활용한 프로젝트다.
웹 표준 테스트만으로 실제 사이트의 렌더링과 상호작용을 보장할 수는 없다. 이를 보완하기 위해 실제 웹사이트에서 여러 단계의 Puppeteer 테스트를 Chromium과 Kitesurf에 실행했다. 단언 결과뿐 아니라 각 단계의 렌더링 출력도 비교해 원하지 않는 차이를 찾는 통합 테스트와 시각 회귀 테스트를 적용했다.
이 방식은 품질 관리의 방향을 보여주지만 모든 사이트와 기능의 호환성을 보장하지 않는다. 기존 Puppeteer 작업이 수정 없이 이전된다고 단정할 수도 없다. 사용자는 자동화 대상 페이지와 핵심 동작을 별도의 회귀 시험 목록에 넣고 엔진 변경 후에도 결과가 유지되는지 확인해야 한다.
Rust와 WebAssembly
구현에서는 가능한 부분에 네이티브 Rust를 사용하고 wasm-bindgen을 통해 WebAssembly로 직접 컴파일했다. Cloudflare는 Emscripten의 여러 모의 의존성 계층을 거치면 컴파일된 바이너리가 커지고 느려질 수 있어 불필요한 에뮬레이션 계층을 피했다고 설명한다. 이는 Workers 환경에서 가볍고 안정적으로 실행하려는 목표와 연결된다.
부분 실패를 세션 종료로 확대하지 않는다
브라우저는 잘못된 입력과 예상하지 못한 마크업을 포함한 웹 콘텐츠를 처리해야 한다. Kitesurf는 경계마다 오류를 처리하고 실패한 부분을 빈 프레임이나 누락된 요소로 낮춰 표현하며 진단에 필요한 로그를 남긴다는 원칙을 세웠다. 하나의 오류가 전체 세션 종료로 번지는 상황을 줄이기 위한 설계다.
이 접근은 작업 지속성에 도움이 되지만 성공한 것처럼 보이는 응답에 데이터 누락이 포함될 수 있다는 뜻이기도 하다. 운영 단계에서는 요청 완료 여부만 보지 말고 필수 요소의 존재, 빈 결과의 비정상적 증가와 경고 로그를 함께 검사해야 한다.
격리 구조와 애플리케이션의 책임
Cloudflare는 에이전트가 임의 출처의 코드와 콘텐츠를 접한다는 전제에서 모든 페이지 로드를 신뢰할 수 없는 입력으로 취급하고 각 세션을 새로 시작하도록 설계했다. 각 구성 요소에는 기능 수행에 꼭 필요한 자원만 허용한다. 이미지, 글꼴, CSS, JavaScript와 WebAssembly 파일을 가져오는 네트워크 접근은 단일 SandboxOutbound Worker를 통하며, 다른 구성 요소는 네트워크에 직접 접근하지 못하는 구조다.
Workers가 격리 경계를 제공하더라도 애플리케이션 계층의 권한 문제까지 자동으로 해결하지는 않는다. Cloudflare도 구성 요소별 접근 범위를 결정하고 페이지 사이에서 정보가 새지 않도록 애플리케이션이 원칙을 집행해야 한다고 설명한다. 에이전트 브라우징에서는 프롬프트 인젝션과 도구 안전성 역시 중요한 위협으로 제시된다.
실제 서비스에서는 에이전트에 허용할 도메인과 동작을 좁히고, 민감한 인증 정보와 페이지 내용이 구성 요소 사이에서 불필요하게 공유되지 않는지 점검해야 한다. 페이지에 적힌 문구와 애플리케이션이 부여한 지시를 구분하고 영향이 큰 동작에 별도의 권한 통제를 두는 것도 필요하다.
도입 전에 확인할 기준
제공 조건
Cloudflare는 발표 시점에 Kitesurf를 Browser Run 베타 기간 동안 무료로 제공한다고 밝혔다. 이는 정식 제공 이후에도 무료라는 의미가 아니다. 원문에는 이후 가격이나 구체적인 사용량 한도가 없으므로 장기 운영을 결정하기 전에 최신 공식 조건을 다시 확인해야 한다.
대상 사이트의 호환성
현재 자동화가 의존하는 페이지 기능과 상호작용을 목록으로 만든 뒤 실제 사이트에서 시험해야 한다. 렌더링 정확도가 필요한 단계와 구조화된 데이터만 필요한 단계를 분리하면 어느 작업을 Kitesurf로 옮길지 판단하기 쉽다.
관측 가능성과 전환 비용
빈 프레임이나 누락된 요소로 저하되는 오류 처리 방식에 맞춰 필수 필드 누락, 빈 페이지 비율, 재시도 결과와 경고 로그를 기록해야 한다. Chromium과 비교할 때도 CPU와 메모리만이 아니라 결과 정확도, 코드 수정 범위, 테스트 및 운영 절차의 변화를 함께 살펴야 한다. JavaScript 실행이나 브라우저 상호작용이 필요하지 않은 페이지라면 단순한 HTTP 요청과 HTML 처리 방식도 비교 대상이 될 수 있다.
작게 검증하는 방법
- 실제 업무를 대표하는 페이지와 핵심 동작을 관리 가능한 범위로 선정한다.
- 기존 도구와 Kitesurf에서 같은 이동, 추출과 스크린샷 작업을 수행한다.
- 필수 데이터 누락, 처리 시간, 재시도 결과와 경고 로그를 기록한다.
- 시각적 정확성이 필요한 작업은 Chromium의 렌더링 결과와 별도로 비교한다.
- 잘못된 입력이나 요소 오류가 빈 결과로 저하되는지, 세션이 복구되는지 확인한다.
- 페이지와 세션 사이에서 인증 정보나 민감한 데이터가 불필요하게 공유되지 않는지 점검한다.
- 베타 이후 제공 조건이 달라질 가능성을 고려해 운영 판단에 필요한 사용량을 측정한다.
첫 검증의 목표는 전체 브라우저 자동화를 한꺼번에 이전하는 것이 아니라 반복 작업 하나에서 자원 부담을 줄이면서 필요한 결과 품질을 유지하는지 확인하는 것이다. 구조화된 콘텐츠 추출이 충분히 정확하고 장애 복구가 단순하다면 적용 범위를 넓힐 수 있다. 반대로 렌더링 차이나 누락을 보정하는 비용이 크다면 시각 정확성이 중요한 작업은 Chromium에 남기고 다른 작업에만 Kitesurf를 적용하는 구성이 적절할 수 있다.
출처와 검증
이 글은 2026년 8월 6일 공개된 Cloudflare의 Kitesurf 소개를 바탕으로 설계 방향과 도입 시 확인할 사항을 정리했다. CPU·메모리 효율 주장에는 원문에 정량 벤치마크가 없으며, 무료 제공은 Browser Run 베타 기간에 한정된다. 호환성, 제공 조건, 사용 한도와 비용은 도입 시점의 공식 문서에서 다시 확인해야 한다.