AI 에이전트가 웹을 읽고 화면을 확인하는 방식은 사람이 같은 브라우저를 오래 쓰는 것과 다르다. 짧고 병렬적인 작업을 격리해 실행하고, 실패하면 다시 시도하기 쉬워야 한다. Cloudflare의 Kitesurf 베타는 CPU와 메모리를 줄이는 대신 호환성과 장기 세션에는 분명한 한계를 둔다.
브라우저 비용은 모델 비용 밖에 있다
에이전트에 웹 도구를 붙이면 모델 호출 비용만 계산하기 쉽다. 하지만 실제 운영에서는 페이지를 열고, HTML을 추출하고, 화면을 캡처하는 브라우저 실행 비용과 실패 복구 비용이 빠르게 커진다. 특히 여러 URL을 동시에 확인하는 모니터링, 문서 수집, 화면 기반 검증은 작업 하나당 브라우저를 띄우는 구조가 흔하다.
Cloudflare는 2026년 8월 6일 Browser Run용 Kitesurf를 베타로 공개했다. Kitesurf는 Chromium을 컨테이너나 별도 프로세스로 실행하는 대신, Workers 위에서 동작하는 상태 비저장(stateless) 브라우저를 표방한다. 기존 CDP(Chrome DevTools Protocol) 및 Quick Actions 엔드포인트에 browser=kitesurf를 지정하는 방식이라, CDP를 쓰는 Playwright·Puppeteer 계열 클라이언트는 큰 인터페이스 변경 없이 선택할 수 있다는 것이 공식 설명이다.
내가 이번 발표에서 눈여겨본 건 새 브라우저 자체보다 실행 단위였다. 오래 유지되는 앱 세션 대신 짧은 입력, 제한된 권한, 결과 반환, 폐기를 기준으로 에이전트 작업을 설계한다. 개인 자동화나 팀의 AX 실험에서도 참고할 만한 방식이다.
Kitesurf가 바꾸려는 것은 렌더링보다 실행 단위다
사람을 위한 브라우저는 탭, 확장 프로그램, 동기화, 매끄러운 스크롤, 정밀한 화면 렌더링 같은 기능을 갖춘다. 반면 에이전트의 일회성 작업은 대개 DOM에서 텍스트를 얻거나, 페이지 상태를 확인하거나, PDF·스크린샷을 만드는 데 집중한다. Kitesurf는 사람이 필요로 하는 기능을 덜어내고, 이런 기계 중심 작업의 리소스 효율과 확장성을 우선한다.
공식 문서는 스크린샷과 HTML 추출을 대상으로 한 14개 URL 측정에서 Kitesurf가 워밍업된 Chromium보다 CPU는 3.1~3.8배, 메모리는 4.7~7.0배 적게 사용했다고 제시한다. 반대로 경과 시간은 스크린샷에서 1.8배, HTML 추출에서 1.7배 더 느렸다. 즉 ‘성능이 좋다’는 한 문장으로 묶으면 오해가 생긴다. 이 수치는 Cloudflare가 운영한 특정 측정 조건의 결과이며, 여기서의 강점은 지연시간이 아니라 병렬 실행 시의 CPU·메모리 예산이다.
구조도 이 선택을 뒷받침한다. Cloudflare 발표에 따르면 페이지 로드는 신뢰할 수 없는 입력으로 취급되고, 세션은 새로 시작하며, 네트워크 접근은 별도 구성요소를 통해 정책을 적용한다. 상태를 가능한 한 적게 두면 멈춘 작업을 버리고 다시 시작하기 쉬워진다. 에이전트가 웹의 임의 페이지를 다루는 환경에서는 빠른 재시작 자체가 운영 품질의 일부가 된다.
‘가벼움’이 곧 범용성은 아니다
베타 단계에서는 제한 사항부터 봐야 한다. Cloudflare 문서는 Kitesurf가 동영상 재생, WebGL, 실제 TLS 지문이 필요한 봇 챌린지, 지속 상태가 필요한 장기 인증 세션에는 적합하지 않다고 명시한다. 픽셀 단위로 정확한 렌더링도 목표가 아니다. 문서의 웹 표준 테스트 통과 수가 커지고 있어도, 특정 실제 사이트에서 상호작용이 된다는 보증과는 다르다.
그래서 ‘Chromium을 전부 교체한다’는 계획은 섣부르다. 예를 들어 사내 대시보드에 로그인해 여러 단계의 양식을 처리하거나, 결제·승인·개인정보가 있는 업무는 긴 세션과 사람의 검토가 필요한 경우가 많다. 이때는 익숙한 브라우저 자동화와 명시적 승인 경계를 유지하는 편이 낫다. 반면 공개 페이지에서 정해진 정보를 추출하거나, 대량 URL의 렌더링 여부를 확인하거나, 짧은 스크린샷 작업을 병렬로 돌리는 경우는 후보가 될 수 있다.
브라우저 선택도 운영 규칙이 필요하다
에이전트 도입의 병목은 ‘어떤 모델을 쓸까’만이 아니다. 브라우저 도구가 어떤 데이터와 권한에 닿는지, 실패했을 때 무엇을 재시도하는지, 비용과 지연시간 중 무엇을 우선할지까지 함께 정해야 한다. Kitesurf 같은 선택지가 생기면 그 기준을 코드나 운영 규칙으로 분리할 기회가 생긴다.
1. 작업을 두 종류로 먼저 나눈다
공개 페이지의 텍스트 추출·스크린샷·단발성 렌더링은 ‘단기·무상태’ 큐로 분류한다. 로그인 유지, 복잡한 상호작용, 동영상·WebGL, 높은 화면 충실도가 필요한 작업은 Chromium 계열로 보낸다. 이 분류는 벤더 이름이 아니라 작업 특성에 기반해야 다른 환경에서도 재사용할 수 있다.
2. 비용 지표와 성공 지표를 함께 기록한다
작은 표본으로 같은 URL 목록을 두 경로에 실행해 성공률, 추출 품질, CPU·메모리 사용량, 전체 경과 시간을 기록한다. Cloudflare의 벤치마크는 출발점일 뿐이다. 내 대상 사이트, 동시성, 재시도 규칙에서 얻은 수치가 실제 의사결정의 근거가 된다. 실패한 페이지의 URL·오류 유형·재시도 결과도 남겨야 호환성 경계를 확인할 수 있다.
3. 격리와 승인 경계를 별도로 둔다
세션이 격리되어 있어도, 에이전트가 어떤 URL을 방문하고 무엇을 외부에 제출할 수 있는지는 별도 문제다. 허용 도메인, 읽기 전용과 쓰기 작업의 분리, 민감한 액션 전 사람 승인, 실행 로그 보관을 기본값으로 둔다. ‘상태 비저장’은 유용한 복구 전략이지 프롬프트 인젝션이나 잘못된 도구 호출을 자동으로 해결하는 보안 완결책은 아니다.
작게 시험해 보는 방법
- 현재 자동화에서 브라우저를 쓰는 작업 10개를 적고, 공개·단발성 작업과 로그인·장기 세션 작업으로 나눠 본다.
- 공개 URL 5~10개로 HTML 추출 또는 스크린샷 실험을 만들고, 성공률·경과 시간·리소스 사용량·재시도 횟수를 같은 형식으로 기록한다.
- 브라우저 실행 요청에 허용 도메인, 최대 페이지 수, 시간 제한, 쓰기 작업 승인 여부를 명시하는 작은 정책 파일을 만든다.
어디까지 맡길지부터 정한다
Kitesurf가 나왔다고 모든 에이전트를 새 브라우저로 옮길 필요는 없다. 브라우저 자동화도 비용과 격리, 호환성을 따로 따져야 하는 인프라다. 우선 짧고 반복적인 공개 웹 작업부터 측정해 보고, 맞지 않는 작업은 Chromium으로 돌리는 방식이 지금 단계에서는 가장 현실적이다.
이 글의 제품 기능과 벤치마크는 2026년 8월 6일 기준 Cloudflare의 베타 발표 및 문서를 바탕으로 한다. 베타 제품의 호환성·한도·성능 수치는 변경될 수 있으므로 도입 전 최신 문서와 대상 사이트의 자체 테스트가 필요하다.