---
type: research
tags: [research, orchestration, browser-automation, cdp, playwright, skill-publish]
status: closed
research_target: Browser Use CLI 2.0의 CDP direct 접근이 robeing 브라우저 자동화에 주는 의미와 적용 가능 범위 판단
closed_date: 2026-03-22
closed_reason: 현재 skill-publish 운영 이슈와 연결해 Playwright 유지, CDP direct는 별도 탐색 후보로 정리 완료
---

# Browser Use CLI 2.0 CDP direct 적용판단 리서치

## 정의

- 이 문서는 사용자 제공 이미지 요약을 출발점으로 삼아, `robeing/skill-publish`의 현재 Playwright 구조와 비교해 적용 가능성을 판단한다.
- Browser Use CLI 2.0의 세부 성능 수치와 구현 방식은 이 문서에서 공식 문서로 재검증하지 않았다.
- 따라서 아래의 "2배 빠름", "비용 절반"은 이미지 기반 참고 정보이며, 워크스페이스 적용 판단은 로컬 코드와 기존 트러블슈팅 기록을 기준으로 한다.

## 기준

### 현재 워크스페이스에서 확인된 사실

- `skill-publish`는 Playwright Chromium 런타임으로 Squarespace 로그인과 편집을 수행한다.
- [`skill-publish/app/services/publisher_service.py`](../../../../skill-publish/app/services/publisher_service.py)는 `async_playwright().start()` 후 `chromium.launch()`와 `browser.new_context()`를 사용한다.
- [`skill-publish/app/services/squarespace_login.py`](../../../../skill-publish/app/services/squarespace_login.py)는 Squarespace 로그인 흐름을 페이지 선택자 중심으로 제어한다.
- 기존 트러블슈팅 문서 [`../../troubleshooting/250918_claude_skill-publish_reCAPTCHA_login_failure.md`](../../troubleshooting/250918_claude_skill-publish_reCAPTCHA_login_failure.md)에는 Headless Playwright가 reCAPTCHA 탐지에 걸렸고, `Xvfb + HEADLESS_BROWSER=false`에서 성공했다고 기록돼 있다.

### 이미지 기준 참고 정보

- Browser Use CLI 2.0은 브라우저 자동화 CLI로 소개됐다.
- 실행 중인 Chrome에 바로 연결한다는 메시지가 있다.
- CDP(Chrome DevTools Protocol)를 직접 사용한다고 소개됐다.
- Playwright/Puppeteer 같은 상위 레이어보다 더 가볍고 빠른 방향을 시사한다.

## 적용

### 구조 차이

| 항목 | 현재 skill-publish | Browser Use류 CDP direct |
|------|--------------------|--------------------------|
| 제어 계층 | Playwright API | Chrome DevTools Protocol 직접 호출 |
| 대상 브라우저 | Playwright가 띄운 Chromium 중심 | 이미 실행 중인 Chrome 또는 원격 CDP 엔드포인트 |
| 추상화 수준 | 높음, selector/wait/context API 풍부 | 낮음, 세션/타깃/이벤트 직접 관리 필요 |
| 유지보수성 | 현재 코드와 연속성 높음 | 재작성 비용 큼 |
| anti-bot 대응 | headless 한계 있으나 headed/Xvfb 우회 경험 있음 | "실사용 Chrome 세션 재사용"이 가능하면 유리할 수 있음 |

### 우리 워크스페이스에 도움이 되는 지점

1. `실행 중인 Chrome 재사용`이라는 아이디어는 유효하다.
   - 현재 Squarespace 로그인 실패의 핵심은 선택자 자체보다 봇 탐지였다.
   - 실제 사용자 Chrome 세션이나 headed Chrome에 붙는 구조는 이 문제를 줄일 가능성이 있다.

2. `Playwright 대체`보다 `부착형 보조 경로`로 보는 것이 맞다.
   - 현재 퍼블리싱 로직은 로그인, 편집 진입, 섹션 복제, iframe 편집, 저장까지 Playwright API에 강하게 결합돼 있다.
   - 전면 교체는 Minimal Change 원칙에 맞지 않는다.

3. `CLI 기반 브라우저 조작`은 에이전트 운영 모델과 잘 맞는다.
   - 터미널 에이전트가 브라우저 상태를 직접 확인하고 조작하는 패턴은 로빙의 운영 방식과 결이 맞다.
   - 특히 디버깅, 로그인 세션 점검, 사람이 켜 둔 브라우저에 붙는 반자동 운영에서 가치가 있다.

### 당장 도움이 안 되는 지점

1. 현재 게시 자동화의 근본 문제를 자동으로 해결해 주지는 않는다.
   - CDP direct라도 Squarespace의 bot detection, 인증 정책, DOM 변동 문제는 그대로 남는다.

2. 현재 코드베이스에는 CDP direct 추상화가 없다.
   - Playwright 기반 서비스 계층을 바로 재사용하기 어렵다.
   - 도입 시 새 런타임, 세션 관리, 오류 처리 기준을 다시 잡아야 한다.

3. "속도 2배, 비용 절반"은 현 시점에서 운영 의사결정 근거로 부족하다.
   - 우리 병목은 대체로 로그인 성공률, anti-bot, 페이지 안정성이다.
   - 순수 실행 속도는 1차 병목이 아니다.

## 판단

### 결론

- 현재 `skill-publish`의 주 경로는 Playwright를 유지하는 것이 맞다.
- Browser Use류 CDP direct 접근은 `운영 보조 경로` 또는 `반자동 디버그 경로`로는 검토 가치가 있다.
- 즉, 지금 필요한 것은 "Playwright를 버리고 CDP로 갈아타기"가 아니라, "실사용 Chrome 세션에 붙는 대안 경로를 별도 탐색"하는 것이다.

### 우선순위

1. 주 경로 유지: Playwright + headed/Xvfb + 세션 안정화
2. 탐색 후보: 기존 Chrome/CDP attach 방식으로 로그인 성공률과 디버그 편의성 비교
3. 보류: skill-publish 전체를 CDP direct 런타임으로 재작성

### 후속 액션

- `skill-publish`에 "기존 Chrome/CDP attach 가능 여부"를 따로 조사하는 연구를 열면 의미가 있다.
- 평가 기준은 속도보다 아래 세 가지가 먼저다.
  - Squarespace 로그인 성공률
  - 세션 재사용 안정성
  - 편집 DOM 변경 대응 비용

## 검증

- 문서 위치가 research SSOT인 `journey/research/orchestration_tools/`인지 확인했다.
- 로컬 코드 확인:
  - `publisher_service.py`의 Playwright 브라우저 초기화
  - `squarespace_login.py`의 로그인 흐름
- 기존 실패 원인 확인:
  - `250918_claude_skill-publish_reCAPTCHA_login_failure.md`
