AI가 브라우저를 쓰는 일은 더 이상 특별한 데모가 아닙니다. Playwright와 Puppeteer는 브라우저 제어와 테스트 자동화에 널리 쓰이고, Playwright는 이제 AI 에이전트용 흐름도 공식 사용 사례로 소개합니다. Playwright MCP는 접근성 트리 기반의 브라우저 상태와 도구 호출을 에이전트에 연결합니다. Computer Use는 사람이 보는 화면을 직접 조작하고, Browser Use 같은 프레임워크는 모델·브라우저·작업 루프를 한 흐름으로 묶습니다. 코딩 에이전트가 브라우저를 열어 화면을 확인하고 디버깅하는 것도 같은 변화의 일부입니다.
그래서 이제 질문은 “AI가 브라우저를 쓸 수 있는가”가 아닙니다. 어떤 방식으로 브라우저를 제어할지, 실행 환경과 권한을 누가 관리할지, 실패한 작업을 어떻게 재현하고 사람이 이어받을지를 정해야 합니다.
브라우저 제어는 이미 여러 층으로 나뉘었습니다
같은 “브라우저 자동화”로 묶이지만 각 도구가 맡는 일은 다릅니다.
| 방식 | 주로 담당하는 것 | 강점 | 한계 |
|---|---|---|---|
| Playwright·Puppeteer | 브라우저 제어와 자동화 | 빠르고 예측 가능하며 테스트에 강함 | 브라우저 실행 환경과 운영은 별도로 관리해야 함 |
| Playwright MCP | AI가 읽고 호출할 수 있는 브라우저 도구 | 접근성 트리 기반이라 화면 좌표에 덜 의존함 | 에이전트의 권한·복구·세션 관리는 별도 설계가 필요함 |
| Computer Use | 사람이 보는 화면 자체를 조작 | API가 없는 웹사이트와 GUI도 다룰 수 있음 | 화면 기반이라 오작동과 보안 위험이 커짐 |
| Browser Use 같은 에이전트 프레임워크 | 모델·브라우저·작업 루프 연결 | 작업 지시와 복구 흐름을 묶기 쉬움 | 실제 운영에서는 브라우저 인프라와 관찰 체계가 필요함 |
| Cloudflare Browser Run | 원격 브라우저 실행과 운영 | 세션, 기록, 디버깅, 사람 개입, 확장성을 한곳에서 처리 | 서비스 비용과 플랫폼 의존성이 생김 |
이 표에서 제품 우열보다 중요한 것은 책임의 위치입니다. Playwright·Puppeteer는 정해진 동작을 빠르고 반복 가능하게 만드는 제어 계층입니다. MCP는 그 기능을 모델이 읽고 호출할 수 있게 하는 접점이지, 권한과 복구를 대신 설계해주는 운영 계층은 아닙니다. Computer Use는 구조화된 API나 접근성 정보가 부족한 화면까지 다룰 수 있지만, 좌표·화면 상태·모델 판단에 더 크게 의존합니다. Browser Use 같은 프레임워크는 작업 루프를 묶어주지만, 여러 세션을 안정적으로 돌릴 브라우저 인프라까지 해결하지는 않습니다.
Cloudflare가 묶으려는 것은 브라우저 실행 이후입니다
Cloudflare의 Browser Run이 눈에 띄는 이유는 여기에 빠져 있던 운영 계층을 제품으로 묶었기 때문입니다. Cloudflare는 글로벌 네트워크에서 브라우저 세션을 필요할 때 띄우고, Puppeteer·Playwright·CDP·MCP·WebMCP로 제어하며, Live View, 세션 기록과 재생, 실시간 디버깅, 사람 개입을 제공한다고 설명합니다. Playwright가 “브라우저를 어떻게 조작할까”에 답한다면 Browser Run은 “그 브라우저를 어디서 실행하고 어떻게 관찰·복구할까”에 가깝습니다.
에이전트가 브라우저를 조작하는 것만큼, 실패한 세션을 보고 되돌리고 사람이 넘겨받는 흐름도 중요합니다.
Cloudflare가 공개한 Kitesurf는 또 다른 방향을 보여줍니다. Browser Run이 원격 실행 환경이라면 Kitesurf는 브라우저 자체를 에이전트 중심으로 다시 설계하려는 제품입니다. 두 제품을 함께 보면 Cloudflare가 단순한 자동화 API가 아니라 에이전트가 웹에서 행동하는 전체 경로를 차지하려는 것으로 읽힙니다. 다만 이것은 현재 제품 방향에 대한 해석이지, Cloudflare가 시장을 장악한다는 증거는 아닙니다.
고착되는 흐름과 아직 남은 선택
이 흐름이 고착되고 있다고 볼 근거는 있습니다. 이미 여러 회사와 오픈소스 프로젝트가 브라우저를 에이전트의 도구로 전제하고, 제어·모델 연결·실행 인프라를 각각 제품화하고 있습니다. 다만 하나의 승자가 모든 층을 대체하는 단계는 아닙니다. 테스트처럼 예측 가능성이 중요한 일은 Playwright·Puppeteer가 적합하고, 화면에만 존재하는 업무는 Computer Use가 여전히 필요합니다. MCP와 Browser Use는 두 영역 사이를 연결하며, Browser Run은 그 조합을 원격에서 운영하는 선택지가 됩니다.
따라서 경쟁의 기준은 브라우저 렌더링 속도만으로 끝나지 않습니다. 세션을 격리하는가, 권한을 어느 단계에서 확인하는가, 웹페이지의 지시가 에이전트의 행동을 바꾸지 않게 할 수 있는가, 실패한 실행을 기록하고 재생할 수 있는가, 사람이 언제든 중단할 수 있는가가 중요해집니다. 웹사이트를 만드는 쪽도 에이전트가 읽을 상태와 실행 가능한 행동의 경계를 더 분명히 설계해야 합니다.
AI 브라우저의 확산은 Chrome 옆에 챗봇 버튼을 하나 더 붙이는 일이 아닙니다. 브라우저의 사용자가 사람에서 사람과 에이전트로 늘어나면서, 브라우저가 화면을 보여주는 클라이언트에서 작업을 실행하는 런타임으로 이동하는 과정입니다. 지금은 Playwright, Computer Use, Browser Use, Browser Run이 서로를 밀어내기보다 각자 다른 층을 맡고 있습니다. 당분간의 승부처는 누가 가장 그럴듯하게 클릭하느냐가 아니라, 누가 안전하고 반복 가능한 브라우저 작업을 운영하느냐에 있을 가능성이 큽니다.
