클라우드플레어의 '킷서프', 사람이 아닌 AI 에이전트를 위한 브라우저를 만들다

브라우저를 새로 만든다는 것은 대부분의 회사에게 무모한 도전에 가깝다. 렌더링 엔진, 자바스크립트 실행, 폰트 처리, 웹 표준 대응까지 수십 년간 쌓여 온 복잡성을 다시 구현해야 하기 때문이다. 클라우드플레어도 수년간 사내에서 '우리가 브라우저를 만들어야 하는가'라는 질문을 주기적으로 던졌지만, 기술적 난이도와 실제로 풀 수 있는 고유한 문제 사이의 균형을 찾지 못해 매번 아이디어를 접었다고 한다. 그러다 최근 두 가지 흐름이 맞물리면서 답이 달라졌다. 하나는 자사 개발자 플랫폼(Workers) 위에서 WebAssembly, 동적 워커, SQLite 기반 Durable Objects, 워커 간 RPC 같은 기능이 충분히 성숙했다는 점이고, 다른 하나는 AI 에이전트가 폭발적으로 늘면서 '사람이 아닌 모델을 위한 브라우저' 수요가 절실해졌다는 점이다. 그 결과물이 이번에 베타로 공개된 킷서프(Kitesurf)다.

왜 크로미움으로는 부족한가

클라우드플레어의 문제의식은 분명하다. 크로미움 같은 기존 브라우저 엔진은 사람이 쓰도록 설계됐다는 것이다. 사람에게는 유용하지만 AI 모델에게는 불필요한 기능과 오버헤드가 많고, 메모리와 연산 자원을 크게 소모한다. 에이전트마다 각자의 브라우저 인스턴스를 붙여 주려면 비용이 감당하기 어려운 수준으로 치솟는다. 이 비용 구조는 결국 파라메트릭 지식이 풍부한 고가의 정교한 모델만 웹 전체에 접근할 수 있게 만들고, 그보다 가벼운 에이전트 애플리케이션은 사실상 배제한다. 킷서프는 반대 방향을 택한다. 사람에게만 필요한 부분에서는 가볍게 가더라도, AI 모델에게 중요한 작업, 예컨대 스크린샷 생성이나 HTML 추출 같은 일반적인 에이전트 작업에서 CPU와 메모리 효율을 확보하겠다는 것이다. 실제로 이런 작업에서 크로미움보다 훨씬 효율적이라는 것이 회사의 설명이다.

스테이트리스와 격리를 전제로 한 설계

킷서프의 핵심 원칙은 무상태(stateless)와 격리다. 브라우저는 신뢰할 수 없고 때로는 적대적인 웹 전체를 렌더링해야 하므로, 회사는 '모든 페이지 로드는 신뢰할 수 없는 입력이고 모든 세션은 새로 시작한다'는 가정 위에 설계했다. 어떤 실패도 죽은 세션이 아니라 빈 프레임이나 누락된 요소로 안전하게 격하되도록, 경계마다 예외를 잡고 안전한 기본값으로 되돌린다는 규칙을 세웠다. 상태가 없으면 컴포넌트는 일회용이자 병렬 처리가 자연스러워진다. 멈추면 즉시 죽이고, 수천 개를 동시에 띄우고, 수요에 맞춰 크기를 조절하며, 끝나면 사라진다. 부하가 몰렸다 빠지는 자동화 트래픽에는 이 방식이 잘 맞는다. Workers의 아이솔레이트 격리 모델이 그 경계를 제공하지만, 각 컴포넌트가 무엇에 접근할 수 있는지는 애플리케이션 수준에서 다시 강제해야 한다는 점도 분명히 했다.

구조는 크게 엔진(Engine), 페이지스크립트(PageScript), 페이지렌더러(PageRenderer)로 나뉜다. 엔진은 유일하게 외부에 노출되는 공개 컴포넌트로, Chrome DevTools Protocol(CDP) 웹소켓과 HTTP REST API를 처리하고 세션 상태를 저장한다. CDP를 채택한 덕분에 Puppeteer, Playwright, chrome-remote-interface, 실제 Chrome DevTools 프런트엔드가 별도 수정 없이 그대로 붙는다. 페이지스크립트는 동적 워커로 페이지마다 장기 실행 아이솔레이트를 띄워 깨끗한 globalThis와 DOM을 구성한다. HTML과 CSS 파싱에는 Rust로 작성된 렌더링 엔진 Blitz의 일부와 파이어폭스의 CSS 파서 Stylo를 쓰고, 스크립트와 wasm은 같은 아이솔레이트 안에서 실행한다. 보안상 Workers가 아직 지원하지 않는 eval은 Rust로 작성된 ECMAScript 엔진 Boa JS를 얹어 처리하는데, 런타임 위에 런타임을 얹는 방식이라 최적은 아니지만 가끔 등장하는 eval을 감당하기에는 충분하다고 설명한다. 페이지렌더러는 계산된 페이지 객체(장면)를 받아 폰트와 이미지를 가져와 이미지 버퍼로 래스터화하고 JPEG·PNG·PDF 형태로 엔진에 돌려준다.

네트워크 접근은 SandboxOutbound라는 단일 워커로만 이뤄지고, 동적 워커로 그 외 어떤 컴포넌트도 직접 네트워크를 건드리지 못하게 막는다. 이 지점에서 CORS를 강제하고, 브라우저 형태의 헤더를 주입하며, 응답을 필터링하고, 각 페이지의 쿠키를 별도 항아리에 격리한다. 정책을 통과하지 못하면 403이다. 컴포넌트 간 호출은 Workers에 내장된 RPC로 처리해, 엔진이 renderFrame() 한 번으로 렌더러에서 PNG를 받아온다. 렌더러가 상태를 갖지 않기 때문에 RPC가 멈추거나 실패하면 엔진이 안전하게 죽이고 다시 띄울 수 있다.

AI로 브라우저를 만드는 방법론

주목할 부분은 개발 방식 자체다. 킷서프는 'Chrome도, Node.js도, 의존성도 없는' Rust 기반 헤드리스 엔진 obscura에서 영감을 받아, AI 에이전트로 이를 Workers에 포팅하는 시도에서 출발했다. 처음에는 잘 되지 않았지만, 에이전트에게 견고한 계획과 성공에 대한 명확한 정의를 충분히 상세하게 주자 스스로 반복하며 작동하는 개념 증명을 만들어 냈다. 복잡한 프로젝트에서 AI의 속도를 살리면서 코드와 결과 품질을 통제하는 열쇠로 회사가 꼽은 것은 '가능한 한 많은 테스트'였다. Web Platform Tests(WPT)는 기능 적합성을 판별할 명확한 골대를 제공했고, 사람은 아키텍처와 에이전트의 접근 방식 검토에 집중할 수 있었다. 다만 WPT는 W3C 표준 적합성만 측정할 뿐 실제 웹사이트를 렌더링하고 상호작용하는 능력은 보장하지 못하므로, 실제 사이트를 대상으로 크로미움과 킷서프를 나란히 돌려 단언과 렌더링 출력을 단계마다 비교하는 통합·시각 회귀 테스트를 함께 붙였다.

실무자가 읽어야 할 지점과 한계

한국의 실무자에게 킷서프가 시사하는 바는 두 가지다. 첫째, 에이전트 자동화 파이프라인의 병목이 점점 '브라우저 비용'으로 옮겨가고 있다는 신호다. CDP 호환을 유지한다는 점은 기존 Puppeteer·Playwright 코드를 크게 바꾸지 않고도 엔드포인트만 교체해 시험해 볼 여지를 준다는 뜻이기도 하다. 둘째, 무상태·격리·경계별 예외 처리라는 설계 원칙은 브라우저에 국한되지 않고, 신뢰할 수 없는 입력을 대량으로 처리하는 자동화 시스템 일반에 적용할 만한 패턴이다. 동시에 한계도 분명하다. 킷서프는 사람용 기능을 의도적으로 덜어낸 에이전트 전용 도구이므로, 복잡한 상호작용이나 사람이 직접 보는 렌더링 충실도가 필요한 작업에는 크로미움을 대체하지 못할 수 있다. 현재 약 21만 5,000개 이상의 WPT를 통과하고 매주 수백 개씩 추가된다지만 이는 표준 적합성 지표일 뿐 실제 웹 호환성과 동일하지 않다. 아직 eval을 네이티브로 지원하지 못해 별도 엔진을 얹은 점, 베타 단계라는 점을 감안하면, 지금은 프로덕션 전환보다 자사 에이전트 워크로드로 효율과 호환성을 실측해 보는 단계로 접근하는 것이 합리적이다.