요약: Cloudflare Browser Run은 headless browser를 Cloudflare 글로벌 네트워크에서 실행해 스크린샷, 콘텐츠 추출, E2E 테스트, 의심 URL 분석, AI 에이전트의 웹 조작을 처리하는 서비스다. 2026년 5월 업데이트로 Containers 기반으로 재구축되며 분당 60개 브라우저 생성, 최대 120개 동시 실행, Quick Action 응답 시간 50% 이상 감소를 발표했다. 실무에서는 확장성보다 상태 관리와 실패 처리 설계가 핵심이다.
AI 에이전트가 실제 업무를 하려면 웹을 봐야 한다. API만으로는 부족한 경우가 많다. 관리자 콘솔에서 값을 확인하고, 로그인된 페이지의 표를 읽고, 폼을 제출하고, 렌더링 결과를 캡처하고, 여러 페이지를 따라가며 정보를 추출해야 한다. 이때 필요한 것이 안정적인 브라우저 자동화 인프라다.
로컬 Playwright나 Puppeteer로 시작할 수는 있다. 하지만 동시 실행 수가 늘고, 지역 지연 시간이 중요해지고, 보안 격리가 필요해지면 직접 운영 비용이 커진다. 브라우저는 무겁고, 크롬 버전 업그레이드도 잦고, 세션 상태와 리소스 누수도 관리해야 한다.
Cloudflare Browser Run은 이 문제를 Workers binding과 Quick Actions 형태로 추상화한다. 스크린샷, 콘텐츠 추출, PDF 렌더링, crawl endpoint 같은 작업을 글로벌 인프라에서 실행할 수 있다. 특히 AI agent가 웹을 안전하게 조작해야 하는 제품에서는 브라우저 실행 환경을 따로 설계하는 비용을 줄일 수 있다.
Cloudflare는 Browser Run을 Cloudflare Containers 위로 옮기며 사용 한도와 성능을 올렸다고 밝혔다. Workers binding 기준으로 분당 60개 브라우저를 생성하고, 최대 120개를 동시에 실행할 수 있으며, Quick Action 응답 시간이 50% 이상 줄었다. 기존보다 4배 높은 한도라는 설명도 포함됐다.
숫자보다 중요한 것은 구조 변화다. 이전에는 Browser Isolation 인프라와 공유하는 부분이 있었고, Browser Run의 짧고 급격한 사용 패턴과 맞지 않는 병목이 있었다. Containers 기반 전환은 브라우저 실행 환경을 더 독립적으로 튜닝하고, Chrome 업그레이드와 기능 플래그를 더 빠르게 적용할 수 있게 한다.
AI 에이전트 제품을 만드는 팀 입장에서는 “브라우저 자동화가 이제 더 싸고 빨라졌다”보다 “브라우저 자동화를 제품 기능으로 넣을 때 운영 기준을 어디까지 외부 플랫폼에 맡길 수 있는가”를 봐야 한다. 동시성, 지역성, 상태 관리, 실패 재시도, 데이터 보안이 핵심이다.
Cloudflare 글에서 가장 실무적인 부분은 상태 관리 이야기다. 브라우저 컨테이너의 availability를 KV에 저장했을 때 eventual consistency와 cache TTL이 병목이 됐다. 어떤 컨테이너가 available로 보였지만 실제로는 이미 다른 요청이 가져간 상태일 수 있다. AI agent 트래픽처럼 짧고 spiky한 요청에서는 이런 stale state가 race condition으로 이어진다.
Cloudflare는 D1의 transactional 특성을 이용해 브라우저 할당을 원자적으로 처리하고, Queues로 컨테이너 상태 업데이트를 batch 처리했다. 각 컨테이너가 5초마다 상태를 큐에 넣고, worker consumer가 최대 100개 batch size와 1초 timeout으로 처리하는 식이다. 글에서는 batch write P95 0.1ms, 지역별 최대 500,000 컨테이너 수준의 headroom을 언급한다.
이 설계는 Browser Run 사용자에게도 힌트를 준다. 브라우저 자동화 워크플로우를 만들 때 단순히 “요청 보내고 결과 받기”로 끝내면 안 된다. 세션 상태, 작업 큐, 타임아웃, 재시도, idempotency key를 둬야 한다. 특히 crawl이나 여러 페이지 탐색은 중간 실패가 정상 상황이다.
Browser Run은 네 가지 작업군에 잘 맞는다. 첫째, AI 에이전트의 웹 조작이다. 로그인된 SaaS 화면에서 정보를 읽거나, 폼을 채우거나, 스크린샷을 기반으로 판단하는 작업이다. 둘째, E2E 테스트다. CI에서 실제 브라우저 렌더링을 확인하고, 지역별 지연이나 브라우저 차이를 줄일 수 있다.
셋째, 콘텐츠 추출과 크롤링이다. Quick Actions나 crawl endpoint를 통해 페이지를 렌더링한 뒤 텍스트와 링크를 추출할 수 있다. 정적 HTML fetch로는 부족한 SPA, lazy-loading 페이지에서 유용하다. 넷째, 보안 분석이다. 의심 URL을 사용자의 로컬 브라우저가 아니라 격리된 원격 브라우저에서 열어 캡처하거나 동작을 관찰할 수 있다.
다만 로그인 자동화에는 주의가 필요하다. 사용자 계정으로 제3자 사이트를 조작하는 기능은 약관, 개인정보, 보안 책임이 얽힌다. 가능하면 API 또는 공식 integration을 먼저 검토하고, 브라우저 조작은 대안이 없을 때 제한적으로 써야 한다.
브라우저 자동화는 실패가 많다. 페이지가 느리게 뜨고, 셀렉터가 바뀌고, bot detection에 걸리고, 네트워크가 끊기고, 로그인 세션이 만료된다. 그래서 성공 케이스보다 실패 케이스 설계가 먼저다.
작업 단위마다 timeout을 나눠야 한다. 브라우저 할당 timeout, 페이지 이동 timeout, selector 대기 timeout, 전체 작업 timeout을 분리한다. 로그에는 URL, 단계, 실패 원인, 스크린샷 또는 trace id, 재시도 횟수를 남긴다. 사용자에게는 “실패”만 보여주지 말고 “로그인 만료”, “페이지 구조 변경”, “네트워크 timeout”처럼 재시도 가능한 원인을 구분해줘야 한다.
비용도 관리해야 한다. 브라우저 인스턴스는 LLM 호출보다 눈에 덜 띄지만 비용과 리소스를 먹는다. agent가 무한 탐색하거나 같은 페이지를 반복 캡처하지 않게 depth, page count, domain allowlist, rate limit을 둔다.
