브라우저 에이전트 직접 만들 때 CDP vs Playwright, DOM/접근성 트리 vs 스크린샷+비전 중 뭘 골라야 하나요?

답변 1개

• 채택된 답변에디터 검증

  결론: 기본값은 "CDP 직접 + 접근성 트리(텍스트) 표현"이고, 스크린샷+비전은 트리로 안 풀리는 케이스에만 폴백으로 붙이세요. 한글·비용 제약이면 더더욱.

  1) 제어 레이어: 왜 CDP인가

  Playwright/Puppeteer는 CDP 위의 래퍼입니다. 둘의 본질 차이는 에이전트가 태스크당 CDP 호출을 수천 번 날린다는 점에서 드러납니다. element 위치·opacity·paint order·JS 상태를 매 스텝 확인하니까요. Playwright는 Python 호출이 Node.js 릴레이 서버를 거쳐 CDP로 번역되는 2차 hop이 있어, 고빈도 마이크로 체크에서 이 더블 hop이 누적 지연을 만듭니다. browser-use가 2025년 Playwright를 버리고 raw CDP로 간 이유가 정확히 이것입니다(browser-use: Leaving Playwright for CDP).

  트레이드오프(Y 대신 X 택, Z 포기):

  • CDP 직접 택 → 레이턴시·페이로드 최소. browser-use는 전환 후 element 추출·스크린샷 속도가 크게 올랐다고 보고합니다. 포기: Playwright의 auto-wait·셀렉터 안정성·크로스브라우저를 직접 구현해야 함.
  • Playwright 택 → 신뢰성·DX. 프로토타입·소규모면 이게 빠름. 포기: 고빈도 루프에서 지연·페이로드 낭비.

  실용 절충: MCP 서버를 끼우는 경우 초기 컨텍스트 토큰 오버헤드를 먼저 재보세요. 서드파티 측정에서 Playwright MCP/Chrome DevTools MCP의 도구 정의만으로 1만 수천 토큰이 빠지는데(webfuse, MCP 비교), 정확한 수치는 버전마다 바뀌니 직접 토큰 카운트해서 확인하세요. Chrome DevTools MCP는 Google 공식이라 디버깅엔 좋지만 에이전트 구동축으론 무겁습니다.

  2) 페이지 표현: 접근성 트리 우선

  접근성 트리는 스크린리더용으로 브라우저가 이미 유지하는 구조입니다. 장식 마크업을 걷어내고 role·label·focus·상호작용 요소만 남긴 의미 구조라, 에이전트가 클릭할 대상을 ref로 지정하기에 맞습니다. 전형적 출력:

  button "로그인" [ref=e1]
  textbox "이메일" [ref=e2]
  textbox "비밀번호" [ref=e3]
  

  같은 페이지를 스크린샷+비전으로 보내면 이미지 토큰이 수천 단위로 깨지고, 좌표 기반 클릭은 레이아웃이 흔들리면 어긋납니다.

  트레이드오프:

  • 접근성 트리 택: 텍스트라 토큰 적고, ref 기반이라 클릭 안정. 포기: canvas/WebGL·접근성 라벨 없는 div onclick·이미지 안 텍스트는 트리에 안 잡힘.
  • 스크린샷+비전 폴백: 트리에 없는 시각 요소(차트, aria 없는 커스텀 위젯) 처리. 비용: 토큰·지연 급증, 그리고 보안 표면 추가 — 스크린샷 OCR 경로가 "눈에 안 보이는 글씨" 인젝션의 진입점입니다(Brave). 비전 폴백을 켜면 인젝션 표면도 같이 켜진다는 걸 설계에 반영하세요.

  권장 아키텍처: 접근성 트리로 1차 → 필요한 요소가 트리에 없을 때만 해당 영역 스크린샷을 비전에 던지는 하이브리드. browser-use 류가 이 패턴입니다.

  한글/국내 함정 (꼭 측정할 것)

  • 한글 토큰은 영어 대비 1.5~2배. 접근성 트리 label이 한글이면 토큰 추정이 영어 기준 그대로 안 맞습니다. 실제 타깃 사이트(예: 네이버·쿠팡·정부24)로 직접 토큰 카운트하세요. 추정 금지.
  • 국내 사이트는 aria-label 빈약이 흔합니다. 접근성 트리에 button ""처럼 라벨 없는 노드가 자주 나와서 ref만 있고 의미가 없습니다. 이 경우 nearby 텍스트나 title/이미지 alt를 트리 추출 단계에서 보강하지 않으면 LLM이 뭘 클릭할지 못 정합니다.
  • 금융·공공 사이트의 키보드 보안 모듈(가상키보드)·iframe 중첩은 CDP로도 입력 dispatch가 막히는 경우가 있어, 이 도메인은 에이전트 자동화 자체가 비추입니다.

  When NOT to use

  SPA가 무거운 캔버스 렌더링(지도·에디터)이면 접근성 트리가 비어서 트리 우선 전략이 무의미합니다. 처음부터 비전 위주로 설계하거나 해당 도메인을 제외하세요. 그리고 신뢰 못 할 사이트를 도는 에이전트엔 비전 폴백을 끄거나 OCR 텍스트를 untrusted로 격리하세요(앞 질문의 인젝션 방어와 연결).

  4주 전도움돼요 20

  신고