위키트리
•
클라우드플레어 AI 엔진 Kitesurf 소스 공개
파워링크 AD 
클라우드플레어(Cloudflare)가 AI 에이전트 전용 브라우저 엔진 Kitesurf의 소스 코드를 공개했다. 11월 13일(현지시각) 블로그를 통해 Apache 2.0 라이선스로 깃허브에 올렸다고 밝혔다. 개발자는 코드를 읽고 로컬에서 실행하거나 수정할 수 있다. 자신의 클라우드플레어 계정에 직접 배포하는 것도 가능하다.
Kitesurf는 크롬이나 브라우저 컨테이너 없이 웹페이지를 처리하는 엔진이다. 클라우드플레어는 AI 에이전트에 가벼운 브라우저를 주는 것이 목표라고 설명했다. 다만 프로젝트는 아직 실험 단계이고 개발도 한창 진행 중이다.
클라우드플레어는 8월 6일 Kitesurf를 처음 소개했다. 9월 28일에는 WebMCP 지원과 새 API 추가, 호환성 개선을 담은 후속 업데이트를 내놨다. 유니트AI에 따르면 이 업데이트에는 터미널 렌더링 도입도 포함됐다. 회사는 두 차례 모두 개발자가 자기 클라우드플레어 계정에서 브라우저 엔진을 직접 돌릴 수 있도록 오픈소스로 공개하겠다고 약속했다.
클라우드플레어는 블로그에서 “그 약속이 이제 현실이 됐다”는 취지로 공개 사실을 알렸다. 이전에는 회사가 제공하는 관리형 서비스 Browser Run의 API를 쓰는 방식이었다. 이제는 이를 대신해 직접 운영하는 선택지가 생겼다.
MLQ는 이 소식을 전하며 프로젝트의 깃허브 페이지가 Kitesurf를 ‘실험적인 브라우저 엔진’으로 설명한다고 짚었다. 소스 공개가 곧 완성품 출시를 뜻하는 것은 아니라는 이야기다.
Kitesurf는 클라우드플레어 워커스(Workers) 위에서 전부 돌아간다. HTML을 분석하고 CSS를 적용하고 페이지의 자바스크립트를 실행한 뒤 스크린샷까지 만든다. 이 모든 과정에 브라우저 컨테이너가 필요 없다. 크롬 개발자 도구 프로토콜(CDP·브라우저를 외부에서 제어하는 인터페이스)도 지원한다. 퍼핏티어(Puppeteer) 같은 기존 자동화 클라이언트를 그대로 붙일 수 있다.
내부는 크게 세 부분이다. 엔진(Engine)이 브라우저 세션과 클라이언트 연결을 관리한다. 페이지스크립트(PageScript)는 페이지와 자바스크립트를 실행한다. 페이지렌더러(PageRenderer)는 결과 화면을 그린다. 웹어셈블리로 컴파일한 러스트 오픈소스 패키지도 활용한다. Blitz는 HTML 파싱과 DOM, 레이아웃, 페인팅을 맡는다. Stylo는 CSS 파싱과 계산된 스타일을 담당한다. 텍스트 레이아웃과 2D 그래픽은 Linebender 라이브러리가, PDF 출력은 Krilla가 처리한다. Boa는 다이내믹 워커스에서 자바스크립트를 돌릴 수 없을 때 마지막 수단으로 웹어셈블리 안에서 이를 실행한다.
유니트AI에 따르면 설계는 모든 페이지 로드를 신뢰할 수 없는 입력으로 취급한다. 외부 요청은 전용 SandboxOutbound 워커가 전담한다. 이 워커가 네트워크 정책을 적용하고 페이지별 쿠키를 분리한다. 다른 구성 요소는 네트워크에 직접 접근할 수 없다. 세션 상태는 엔진만 갖고 나머지는 가능한 한 일회용으로 설계됐다. 페이지렌더러가 멈추거나 실패하면 엔진이 바꿔 끼울 수 있다.
토큰포스트는 스크린샷과 HTML 추출 작업에서 Kitesurf가 크로미엄보다 CPU와 메모리를 적게 쓴다고 전했다. 메모리 사용량이 낮은 만큼 더 많은 세션을 동시에 돌릴 수 있다는 설명이다. 클라우드플레어는 워커스 글로벌 네트워크에서 수요에 맞춰 확장할 수 있다는 점도 내세웠다.
설계 우선순위는 사람이 아니라 에이전트에 맞춰져 있다. 토큰포스트에 따르면 토큰 소비량, 컨텍스트 윈도우, 확장성, 성능, 비용을 중시한다. 탭, 테마, 확장 프로그램, 픽셀 단위로 완벽한 렌더링 같은 사람용 기능은 비중이 낮다.
한계도 분명하다. 유니트AI에 따르면 클라우드플레어는 8월 출시 당시 Kitesurf가 아직 다음 용도에는 맞지 않는다고 밝혔다.
- 동영상 - WebGL - 실제 TLS 핑거프린트가 필요한 봇 차단 확인 절차 - 지속적인 상태에 의존하는 장시간 인증 세션
깃허브 저장소도 CDP 엔드포인트일 뿐 완전한 크롬 구현은 아니라고 설명한다. 일부 크롬 개발자 도구 기능은 아직 지원하지 않는다.
로컬 실행은 저장소를 복제한 뒤 의존성을 설치하고 개발 명령을 실행하는 순서다. 개발 서버는 로컬 주소 127.0.0.1:8787에서 열린다. 유니트AI에 따르면 로컬 개발에는 Bazelisk, 노드JS 22 이상, pnpm 9.15.4가 필요하다. 첫 빌드는 러스트 코어를 컴파일하느라 시간이 걸린다. 이후에는 빌드 캐시를 재사용한다. 클라우드플레어는 퍼핏티어로 연결하는 예시 코드도 제시했고, AI 하니스(harness·에이전트 실행 환경)를 로컬 CDP 포트에 연결해도 된다고 안내했다.
자기 계정에 배포하려면 워커스 유료 플랜이 있어야 한다. 페이지마다 격리된 워커를 만드는 다이내믹 워커스를 쓰기 때문이다. 유니트AI는 보안 책임이 운영자에게 넘어간다는 점을 짚었다. 엔진에는 자체 인증 기능이 없고 workers.dev 주소가 기본으로 공개된다. 클라우드플레어 액세스 같은 인증 계층이 없으면 URL을 아는 누구나 엔진을 통해 웹을 탐색할 수 있다. CDP 클라이언트를 연결하고 운영자 계정에서 나가는 요청을 보내 유료 CPU 시간을 소모할 수도 있다. 저장소는 배포 전에 계정 전반에 액세스를 켜서 공개 구간이 생기지 않게 하라고 안내한다.
기여 절차도 정해져 있다. 클라우드플레어는 최소한의 재현 방법이나 해결 방안을 담아 이슈를 먼저 열고 메인테이너의 보증을 받은 뒤 풀 리퀘스트를 올리라고 요청했다. 테스트를 갖춘 범위가 명확한 수정을 선호한다. 렌더링 버그를 재현하는 작은 페이지, 실패하는 자동화 워크플로, 문서 오류 수정도 환영한다.
블로그는 웹 플랫폼 테스트 호환성 현황과 벤치마크를 공식 랜딩 페이지에서 확인할 수 있다고 안내했다. 엔진의 호환성과 안정성, 효율을 높이는 것이 당장의 개발 초점이다.
