[Claude] 브라우저 자동화 — CDP·Playwright·Browser Harness·cua
목차
📚 Claude Code 정리 노트 (2026-07) — 4부작
1. 제품 명세 문서 2. 멀티 에이전트와 Ralph 3. 자율 연구·개발 자동화 4. 브라우저 자동화 ← 지금 읽는 글
1. CDP (Chrome DevTools Protocol)란?
그림: 제어 측(헤들리스 Chrome·Puppeteer 등) ⇄ WebSocket(JSON-RPC) ⇄ Chromium 브라우저의 도메인(Page·DOM·Network·Runtime·Performance·스크린샷). AI 생성 UI → CDP로 캡처 → visual-verdict 판정으로 이어지는 시각 QA의 캡처 엔진.
개념 한 줄
Chromium 계열 브라우저를 프로그램으로 제어·계측하는 프로토콜. WebSocket 위에서 JSON(JSON-RPC) 메시지를 주고받으며, 브라우저에 명령을 보내고 이벤트를 받는다.
주요 도메인(기능 영역)
| 도메인 | 역할 |
|---|---|
| Page | 페이지 이동·로드 제어 |
| DOM | 요소 조회·조작 |
| Network | 네트워크 요청 가로채기·관찰 |
| Runtime | 페이지 안에서 JS 실행 |
| Performance | 성능 지표 측정 |
| 스크린샷 캡처 | 현재 화면을 이미지로 저장 |
이를 활용하는 도구
헤드리스 Chrome, Puppeteer, Lighthouse 등이 CDP 위에서 동작한다. (Playwright는 자체 프로토콜을 위주로 쓰되, Chromium 대상 작업에서는 CDP도 일부 활용하는 것으로 알려져 있음 — 도구별 채택 정도는 버전에 따라 달라질 수 있어 단정하지 않음.)
이 노트에서의 위치
visual-verdict·QA 자동화 파이프라인에서 “스크린샷을 어떻게 얻는가”의 하부 엔진에 해당한다. AI가 만든 UI를 브라우저로 열어 캡처하고, 그 결과를 verdict로 판정하는 흐름의 기반 기술.
(참고: 이 노트에 들어간 이미지들도 헤드리스 Chrome으로 렌더링·캡처했는데, 그 캡처 과정이 CDP 계열 메커니즘에 해당한다.)
※ CDP는 널리 쓰이는 안정적 표준이지만, 특정 도구의 채택 정도·구현 방식은 버전에 따라 달라질 수 있다.
한 줄 요약: CDP = WebSocket 기반 JSON 메시지로 Chromium 브라우저를 원격 제어·계측하는 프로토콜. 헤드리스 Chrome·Puppeteer·Lighthouse 등이 이를 활용하며, visual-verdict·QA 파이프라인에서는 스크린샷 캡처의 하부 엔진 역할을 한다.
2. CDP MCP의 단점
CDP를 MCP 서버로 감싸 브라우저를 LLM에 붙이는 방식(CDP + MCP)에는 뚜렷한 단점이 있다.
그림: ①브라우저 별도 프로세스로 리소스 차지 ②MCP 호출이 일회성이라 동작을 재실행 가능한 코드로 남기기 어려움 ③접근성 스냅샷·스키마로 토큰 비용 큼 — 같은 10단계 작업이 MCP ~114k vs CLI ~27k(보도된 예시).
개념 한 줄
“그냥 CDP를 MCP로 붙이면 되지 않나”가 편리한 만큼, 리소스·재현성·토큰 세 가지에서 대가를 치른다.
핵심 단점
| 단점 | 내용 |
|---|---|
| 별도 프로세스 리소스 | 브라우저를 별도 프로세스로 띄워야 해 메모리·CPU 등 리소스를 차지한다 |
| 동작을 코드로 남기기 어려움 | MCP 도구 호출은 일회성이라, 브라우저 상태가 LLM 컨텍스트에만 머문다 — 나중에 재실행 가능한 코드·스크립트로 저장·재현하기 어렵다 |
| 토큰 비용 | 접근성 스냅샷이 페이지당 대략 3,800~4,000 토큰, 도구 스키마 부담은 별도로 큼. 매 액션마다 스냅샷을 받으면 10단계 작업이 약 114,000 토큰까지 갈 수 있음(같은 작업을 CLI로 하면 약 27,000 토큰, 약 4배 차이 — 보도된 예시 수치) |
정리
“그냥 CDP를 MCP로 붙이면” 편하지만 리소스·재현성·토큰에서 아쉬움이 남는다. 그래서 대안(Playwright, CLI, Browser Harness)이 이어진다.
🔗 CDP·MCP(2026-06-27 노트)·컨텍스트 엔지니어링(2026-06-27 노트 6번)과 연결.
한 줄 요약: CDP를 MCP로 감싸는 방식은 별도 브라우저 프로세스의 리소스 부담, 재실행 가능한 코드로 남기기 어려운 일회성 도구 호출, 그리고 접근성 스냅샷·도구 스키마로 인한 큰 토큰 비용이라는 세 가지 단점을 가진다.
참고: https://playwright.dev/docs/getting-started-mcp (공식 MCP 문서) · 토큰 비교 수치(114k/27k)는 커뮤니티 보도 예시로, 버전·환경에 따라 다를 수 있다.
3. Playwright란?
Microsoft가 만든 브라우저 자동화 프레임워크. Claude Code native 기능도 OMC 플러그인도 아닌, 외부 도구다.
그림: 다중 브라우저(Chromium·Firefox·WebKit)를 하나의 API로 제어. auto-wait·네트워크 가로채기·스크린샷·codegen에 크로스 언어(JS/TS·Python·Java·.NET) 지원 — 접근성 트리 기반이라 AI 에이전트 자동화의 사실상 기본값.
개념 한 줄
코드로 브라우저를 열고·클릭하고·확인하는, AI 에이전트 브라우저 자동화의 사실상 기본값.
특징
| 특징 | 내용 |
|---|---|
| 다중 브라우저 | Chromium·Firefox·WebKit 지원 |
| auto-wait | 요소가 준비될 때까지 자동 대기 |
| 네트워크 가로채기 | 요청·응답을 가로채 관찰·조작 |
| 스크린샷 | 화면 캡처 |
| codegen | 사람의 동작을 녹화해 코드로 변환 |
| 크로스 언어 | JS/TS·Python·Java·.NET 지원 |
AI 에이전트와의 접점
접근성 우선 로케이터(getByRole 등)와 auto-wait 같은 AI 친화적 API 덕에 에이전트 브라우저 자동화에 자주 채택된다. 원래는 “사람이 테스트 코드를 작성”하는 도구였지만, AI 시대엔 에이전트가 쓰는 브라우저 제어 계층으로도 활용된다. (참고: 페이지를 접근성 스냅샷으로 다루는 방식은 주로 Playwright MCP 형태의 특징이다.)
🔗 CDP(그 위 계층/대안), QA 자동화·visual-verdict의 “브라우저 조작·캡처” 축과 연결.
한 줄 요약: Playwright = Microsoft의 브라우저 자동화 프레임워크. 다중 브라우저·auto-wait·네트워크 가로채기·codegen을 갖췄고, 접근성 우선 로케이터 등 AI 친화적 API 덕에 AI 에이전트의 브라우저 제어 계층으로도 널리 쓰인다.
4. Playwright vs Playwright-MCP vs Playwright-CLI
같은 Playwright 코어를 세 가지 형태로 감싼 것. 셋 다 Microsoft Playwright 계열의 외부 도구이며, Claude Code native 기능이나 OMC 플러그인이 아니다.
그림: 라이브러리(상태=코드·파일, 재사용 스크립트) vs MCP(상태=LLM 컨텍스트, 접근성 스냅샷, 토큰 ~114k) vs CLI(상태=디스크 YAML, 셸 명령, ~27k·약 1/4로 절감). 핵심 축은 “상태가 어디 사는가”와 토큰 효율.
개념 한 줄
같은 자동화 엔진이라도, 상태(state)가 코드·LLM 컨텍스트·디스크 중 어디에 사는가에 따라 토큰 효율과 쓰임새가 갈린다.
대비표
| 형태 | 무엇 | 상태가 사는 곳 | 특징 |
|---|---|---|---|
| Playwright (라이브러리) | 코드로 스크립트 작성 | 코드·파일 | 사람이 작성 → 반복 실행 가능한 재사용 자산 |
| Playwright MCP | MCP 서버로 브라우저 도구 노출(@playwright/mcp) | LLM 컨텍스트 | 접근성 스냅샷 기반(스크린샷·비전 모델 불필요). 상태·도구 스키마가 컨텍스트에 남아 토큰 부담이 큼(예: 10단계 작업 ~114,000 토큰). 탐색적·자기치유형 루프에 유리 |
| Playwright CLI | 셸 명령(@playwright/cli, 2026년 초 등장) | 디스크(YAML 파일 경로만 컨텍스트에 남음) | 명령 기반, 토큰 효율적(예: ~27,000 토큰 — MCP 대비 약 1/4). 고처리량 코딩 에이전트에 적합 |
핵심 축과 선택 가이드
핵심 축은 두 가지 — ① 상태가 어디 사는가(코드 / LLM 컨텍스트 / 디스크) ② 토큰 효율. 최근엔 “MCP → CLI로 무게중심이 옮겨간다”는 흐름도 언급된다.
| 상황 | 추천 |
|---|---|
| 재사용 가능한 스크립트가 필요할 때 | Playwright 라이브러리 |
| 탐색적 에이전트 루프·풍부한 introspection이 필요할 때 | Playwright MCP |
| 고처리량·토큰 절약이 중요할 때 | Playwright CLI(+SKILL 조합) |
🔗 CDP MCP의 단점(프로세스·토큰), Built-in 스킬(CLI+SKILL 조합), QA 자동화와 연결.
한 줄 요약: Playwright(코드) vs MCP(LLM 컨텍스트, 토큰 큼) vs CLI(디스크, 토큰 절약) — 같은 엔진을 상태 위치와 토큰 효율에 따라 다르게 감싼 세 형태이며, 재사용 스크립트=라이브러리, 탐색적 루프=MCP, 고처리량=CLI로 나눠 쓴다.
출처: https://github.com/microsoft/playwright-mcp , https://playwright.dev/docs/getting-started-mcp
※ CLI는 2026년 초 등장한 신생 도구라 세부는 버전에 따라 다를 수 있다.
5. Browser Harness란?
Browser Use가 공개한, AI 에이전트와 실제 브라우저 사이의 가장 얇은 연결 계층. Claude Code native 기능이나 OMC 플러그인이 아닌 외부 오픈소스 도구다.
그림: 에이전트 ⇄ Browser Harness ⇄ Chrome(CDP 직결). 페이지 스냅샷 → “다음 액션?” → 실행을 완료까지 반복하며, 헬퍼가 없으면 에이전트가 raw CDP로 직접 작성하는 자기치유(~600줄) 구조. Playwright(사람이 스크립트)와 달리 에이전트가 스스로 판단해 행동 — 하네스 엔지니어링의 브라우저 버전.
개념 한 줄
에이전트가 페이지를 보고 스스로 판단해 한 스텝씩 행동하도록, CDP로 Chrome에 직접 접근하는 최소한의 실행 골격.
동작 루프
에이전트가 작업 설명으로 harness 호출
│
▼
harness가 페이지를 열고 스냅샷
│
▼
모델에게 "다음에 뭐 할까?" 질의
│
▼
모델이 액션(클릭·입력·스크롤)으로 응답
│
▼
harness가 액션 실행 ── (완료까지 반복)자기치유(self-healing)
약 600줄 규모의 harness로, 필요한 헬퍼 함수가 없으면 에이전트가 헬퍼 모듈(예: helpers.py)을 읽고 raw CDP로 그 함수를 직접 작성해 이어간다 — 실행 도중 스스로 부족한 부분을 채우는 자기치유 구조.
Playwright와의 차이
| 구분 | Playwright | Browser Harness |
|---|---|---|
| 각본 | 사람이 스크립트를 미리 작성 | 에이전트가 매 스텝 스스로 판단 |
| 실행 방식 | 정해진 대로 실행 | 페이지를 보고 관찰→결정→행동을 반복 |
🔗 하네스 엔지니어링의 브라우저 버전 — “모델을 감싸 행동→관찰→반복시키는 실행 골격”을 브라우저 제어에 적용한 사례. 루프 엔지니어링·visual-verdict·CDP와도 연결.
한 줄 요약: Browser Harness = CDP로 Chrome에 직접 접근해, 에이전트가 스냅샷을 보고 다음 액션을 스스로 결정·실행하게 하는 얇은 연결 계층. 헬퍼 함수가 없으면 raw CDP로 직접 작성하는 자기치유 구조를 갖췄으며, 사람이 각본을 짜는 Playwright와 대비된다.
출처: https://github.com/browser-use/browser-use
※ browser-use / Browser Harness는 빠르게 변하는 신생 도구라 세부는 버전에 따라 다를 수 있다.
6. cua-driver란?
trycua가 만든 오픈소스 백그라운드 “컴퓨터-사용(computer-use)” 드라이버. Browser Harness가 브라우저(CDP)에 국한되는 것과 달리, 네이티브 데스크톱 앱 전반을 대상으로 한다. Claude Code native 기능도 OMC 플러그인도 아닌 외부 오픈소스 도구다.
그림: 코딩 에이전트 → MCP/CLI(동일 표면) → cua-driver → 네이티브 데스크톱 앱. 핵심은 커서·포커스를 빼앗지 않고 백그라운드로 클릭·입력·스크롤·접근성 트리 조회·창 캡처. macOS·Windows·Linux·Android를 지원하며 Cua 인프라(driver·agent·sandbox·bench)의 일부. 제어 표면이 CDP→Playwright→Browser Harness→cua-driver(데스크톱 전체)로 넓어진다.
개념 한 줄
커서·포커스를 빼앗지 않고 백그라운드에서, 네이티브 데스크톱 앱을 클릭·입력·스크롤·조회하게 해주는 드라이버.
기능
| 기능 | 내용 |
|---|---|
| 조작 | 클릭·입력·스크롤 |
| 조회 | 접근성 트리(accessibility tree) 조회 |
| 캡처 | 창(window) 상태 캡처(스크린샷) |
| 표면 | 위 기능을 MCP/CLI 동일 표면으로 제공 |
핵심 차별점 — 백그라운드 동작
Browser Harness나 Playwright류가 브라우저 안에서 동작하는 것과 달리, cua-driver는 커서·포커스를 가로채지 않고 백그라운드에서 동작한다. 즉 사람이 컴퓨터를 그대로 쓰는 동안에도, 에이전트가 별도로 다른 앱을 조작할 수 있다.
크로스 플랫폼
| 대상 | 지원 |
|---|---|
| macOS | O |
| Windows | O |
| Linux | O |
| Android | O |
| 스케일 | 컴퓨터 “플릿(fleet)” 단위로 확장 |
사용 방식 — CLI + MCP
CLI 도구이자 MCP 서버, 양쪽으로 동작한다. Claude Code·Cursor·Codex·OpenClaw 등의 MCP 설정에 추가하면, 코딩 에이전트에 “스크린샷·클릭·입력” 도구가 생겨 실제 네이티브 앱을 조작하게 할 수 있다 — 단, 이는 Claude Code 자체 기능이 아니라 외부 MCP 서버로서 붙는 것이다.
Cua 인프라 안에서의 위치
| 구성 | 역할 |
|---|---|
| cua-driver | 백그라운드 컴퓨터-사용 드라이버(이 절의 주제) |
| cua-agent | 컴퓨터-사용 에이전트 프레임워크 |
| cua-sandbox | 샌드박스 생성·제어 SDK |
| cua-bench | 벤치마크·RL 환경 |
→ “컴퓨터-사용 에이전트 인프라를 주말 해킹이 아니라 진짜 인프라로 취급”한다는 지향.
🔗 Browser Harness(브라우저 한정·CDP)와 대비 — cua-driver는 데스크톱 전체 + 백그라운드 + MCP/CLI 표면. 브라우저 자동화·CDP·MCP/CLI, 하네스 엔지니어링과도 이어진다. MCP/CLI 두 표면을 다 제공하는 점은 Playwright MCP vs CLI의 구도와 닮았다.
한 줄 요약: cua-driver = 커서·포커스를 뺏지 않고 백그라운드에서 네이티브 데스크톱 앱을 클릭·입력·스크롤·캡처하는 오픈소스 컴퓨터-사용 드라이버. MCP/CLI 두 표면으로 Claude Code 등 코딩 에이전트에 붙여 쓸 수 있으며, cua-agent·cua-sandbox·cua-bench와 함께 더 큰 Cua 인프라를 이룬다.
출처: https://github.com/trycua/cua , https://cua.ai
※ 신생·빠르게 변하는 프로젝트라 세부는 버전에 따라 다를 수 있다.
맺음말 — 이 글 전체를 관통하는 흐름
CDP → Playwright → MCP/CLI 대비(CDP MCP의 단점·Playwright 세 형태) → Browser Harness → cua-driver로 이어지며, “AI 에이전트에게 브라우저·컴퓨터를 어떻게 쥐여줄 것인가”라는 질문에 대한 제어 표면이 브라우저 한정에서 데스크톱 전체로 점점 넓어진다.
참고: AutoResearch·AlphaEvolve 관련 일정·수치는 공개된 발표·보도 기준이며, 향후 업데이트될 수 있다. 실제 적용 전에는 각 프로젝트의 최신 저장소·공식 발표를 함께 확인할 것. LLM Wiki·Ralph vs Goal·UltraQA 등 OMC(oh-my-claudecode) 관련 스킬·에이전트명은 플러그인 버전에 따라 달라질 수 있으니 실제 사용 전 해당 플러그인 문서를 확인할 것. 이 편에서 다룬 Playwright(Microsoft)·Browser Use·cua-driver(trycua)는 Claude Code native 기능도 OMC 플러그인도 아닌 외부 도구이며, 토큰 수치·CLI 등장 시점·browser-use/cua 세부는 예시/보도 수치이자 버전에 따라 달라질 수 있으니 실제 사용 전 각 프로젝트의 최신 문서를 확인할 것.