Playwright & 브라우저 자동화 활용 보고서

HomeBase 기술 노트 #1 · 2026-07-25 · 작성: Claude (Fable 5) + 명빈


1. Playwright란 무엇인가

Playwright는 Microsoft가 만든 오픈소스 브라우저 자동화 프레임워크다. 코드로 크롬·파이어폭스·사파리(WebKit)를 사람처럼 조작한다 — 페이지 열기, 클릭, 입력, 스크롤, 스크린샷, 네트워크 감시까지.

Selenium(2004~)의 후계 세대로, 원래 목적은 웹 서비스 E2E 테스트였지만 지금은 스크래핑·업무 자동화·AI 에이전트의 "손"으로 쓰임새가 훨씬 넓어졌다.

핵심 강점


2. 사례 연구 — 오늘 SAT 프로젝트에서 실제로 쓴 방법

오늘 작업이 Playwright 활용의 전형적인 패턴을 거의 다 보여줬다.

단계 쓴 기법 배운 것
로그인 CDP로 별도 프로필 크롬에 연결 → 폼 자동 입력 Chrome 136+는 기본 프로필 CDP를 차단 → 별도 프로필 크롬이 정석
구조 파악 DOM 셀렉터 조사, page.evaluate()로 페이지 내부 JS 실행 화면에 보이는 것보다 데이터가 어디서 오는지를 먼저 찾을 것
데이터 수집 네트워크 감시로 내부 API(exec_json) 발견 → 브라우저 안에서 직접 호출 스크래핑 최고의 형태는 스크래핑을 안 하는 것 — 내부 API가 주는 구조화 JSON이 화면 파싱보다 10배 깨끗함. CSRF 보호도 브라우저 안에서 호출하면 자동 해결
검증 빌드된 HTML을 실제 크롬으로 열어 전 문항 순회 — 깨진 이미지·JS 에러·필터 동작 기계 검증 jsdom보다 강력한 실브라우저 기능 테스트. "만들었다"와 "동작한다"의 간극을 없앰
육안 감수 page.screenshot() → AI가 이미지를 직접 읽고 판정 렌더링 문제(수식 안 보임 등)는 스크린샷 감수에서만 잡힘

info: 이 파이프라인은 learning/sat_test_prep/pipeline/에 재사용 가능한 형태로 저장되어 있다 (cdp.py = 연결, collect.py = 수집, audit·검증 스크립트).


3. 활용 분야 — 폭넓은 지도

① E2E 테스트 / QA (본업)

서비스의 사용자 흐름(로그인 → 결제 → 확인)을 코드로 반복 검증. CI에 붙여 배포 전 자동 실행. 시각 회귀 테스트(스크린샷 픽셀 비교)로 "디자인이 깨졌는지"도 잡는다.

② 웹 스크래핑 / 데이터 수집

로그인 뒤에 있는 데이터, JS로 렌더링되는 페이지(정적 크롤러가 못 읽는 것)를 수집. 오늘의 SAT 수집이 정확히 이 케이스. 포인트는 내부 API 발견 → 구조화 데이터 직접 확보.

③ RPA (반복 업무 자동화)

사람이 매일 하는 웹 작업을 대신: 관리자 페이지에서 리포트 다운로드, 폼 제출, 재고/가격 확인, 예약 확인. 사내 시스템에 API가 없을 때 특히 유용.

④ 모니터링 / 합성 트랜잭션

"우리 서비스 지금 실제로 되나?"를 주기적으로 사람처럼 검사 — 페이지 열림, 로그인 됨, 핵심 버튼 동작. 단순 ping보다 훨씬 신뢰도 높은 헬스체크.

⑤ 스크린샷 / PDF 생성

웹페이지를 이미지·PDF로 변환. HomeBase의 /pdf 유틸이 이미 같은 원리(Chrome headless)로 동작 중.

⑥ AI 에이전트의 브라우저 손 (2026 최전선)

Playwright MCP(Microsoft 공식)가 표준으로 자리잡음 — AI에게 스크린샷 대신 접근성 트리(구조화된 페이지 요약)를 주고, AI가 "체크아웃 완료하고 성공 모달 확인해줘" 같은 목표 단위로 브라우저를 조작한다. Claude Code에 붙이면 오늘 내가 한 일(파이썬 스크립트 작성)을 도구 호출로 바로 할 수 있다. 관련 생태계: Stagehand, Browser Use(AI 특화 래퍼).

⑦ 기타

접근성(a11y) 자동 검사, 성능 트레이싱, 크로스브라우저 호환성 확인, 웹게임/설문 자동화.


4. 유사·보완 도구 비교

도구 무엇 Playwright 대비
Selenium 원조 브라우저 자동화 레거시 호환 넓음, 그러나 느리고 flaky. 신규엔 비추
Puppeteer 구글제, 크롬 전용 가볍지만 크롬만. Playwright가 상위 호환
Cypress 프론트엔드 테스트 특화 개발자 DX 좋음, 테스트 외 용도(스크래핑 등) 불가
requests + BeautifulSoup 정적 HTML 파싱 (Python) 브라우저 불필요·초고속. JS 렌더링 페이지는 못 읽음 — 정적이면 이게 먼저
Playwright MCP AI 에이전트용 브라우저 도구 스크립트 작성 없이 Claude가 직접 조작. 다음 단계로 도입 추천
Browser Use / Stagehand AI 우선 브라우저 프레임워크 자연어 목표 → 자동 조작. 정밀 제어는 Playwright 직접이 위
n8n / Zapier 노코드 워크플로 API 있는 서비스 연결은 이쪽이 빠름. 브라우저 필요하면 Playwright
PyAutoGUI 데스크톱 GUI 자동화 웹 밖(네이티브 앱) 조작용. 좌표 기반이라 취약

선택 규칙: ① 공식 API 있으면 API → ② 정적 페이지면 requests/BS4 → ③ JS 렌더·로그인·조작 필요하면 Playwright → ④ AI가 즉석에서 판단하며 조작해야 하면 Playwright MCP.


5. HomeBase 기능별 발전 아이디어

현재 HomeBase: ReadFlow · Claude 작업 · 작업 보드 · 정연이 공부방 · 쇼츠 크리에이터 · AI 콜센터 아카이브 · AI 사주 사업 · 사주 만세력 앱. 브라우저 자동화로 각각 이렇게 발전시킬 수 있다.

정연이 공부방 ⭐ 즉시 효과 최대

쇼츠 크리에이터

AI 사주 / vox.ai

ReadFlow

HomeBase 자체 운영

tip: 추천 1순위는 "테스트센터 자동 동기화"다. 새로 만드는 게 아니라 오늘 완성한 파이프라인에 cron 감시만 얹는 것이라 반나절 작업이고, 정연이가 시험 칠 때마다 자동으로 복습 세트가 생긴다.


6. LLM 모델 선택 전략 — "오늘 왜 20%나 썼나"

오늘의 비용 구조 분석

오늘 서브에이전트를 26개 돌렸다 (해설 생성 23 + 감수 3). 문제는 Agent 호출 시 모델을 지정하지 않으면 메인 모델(Fable 5 = 최고가)을 그대로 상속한다는 것. 즉 "27문항 번역" 같은 대량 생산 작업이 전부 최고급 모델로 돌았다. 에이전트당 6만~18만 토큰 × 26개가 사용량의 주범이다.

원칙: 판단의 난이도에 모델을 맞춘다

작업 유형 권장 모델 이유
오케스트레이션·설계·디버깅·중요 결정 Fable / Opus (메인 세션) 실수 비용이 큼
대량 생성 — 번역·해설·요약·코드 보일러플레이트 Sonnet 품질 준수 + 가격 1/5 수준. 기계 검증 규칙(오늘의 "원문 재구성 100% 일치", "sympy 재검증")이 있으면 품질 격차가 사실상 사라짐
단순 추출·포맷 변환·개수 세기·상태 확인 Haiku 판단이 거의 불필요
최종 품질 감수 (표본 심사) Fable 또는 Sonnet 감수는 소량이므로 좋은 모델 유지 가치 있음

실행 방법 (Claude Code)

  1. 서브에이전트 모델 지정 — 가장 효과 큼: Agent 호출 시 model: "sonnet" / "haiku" 지정. 커스텀 에이전트는 .claude/agents/*.md의 frontmatter에 model: sonnet 고정
  2. 세션 기본 모델 전환: /model로 작업 성격에 따라 변경 (설계 세션 = Fable, 단순 반복 세션 = Sonnet)
  3. /fast: Opus 고속 모드 — 모델 급을 낮추지 않고 출력 속도만 올림 (Opus 4.7/4.8)
  4. 하이브리드 패턴 (추천): 메인 = Fable로 유지하되 ① 스펙·검증 규칙을 정교하게 작성(Fable) → ② 대량 생성은 Sonnet 에이전트 → ③ 기계 검증(무료) → ④ 표본 감수만 Fable

오늘 프롬프트 Before → After (실제 문구 수정 사례)

모델 지정은 프롬프트에 자연어로 한 문장 덧붙이면 끝이다 (키워드: sonnet / haiku / opus). Claude가 그 지시를 Agent 호출의 model 파라미터로 전달한다.

사례 1 — 해설 모드 신설 (RW 81문항 생성, 에이전트 3개가 Fable로 돌았음)

Before: "…해설 모드를 하나 더 만들어서, 왼쪽에 있는 문제 지문에 대해서는, English Chunk와 Korean Chunk가 1:1로 일대일 대응하여 직관적으로 들어맞도록 끊어 읽기 형태로 학습할 수 있는 모드를 만들면 어떨까? …"

After: 같은 문구 끝에 한 문장 추가 → "번역 생성 에이전트들은 sonnet으로 돌리고, 스펙 작성과 최종 감수만 네가(fable) 직접 해줘."

사례 2 — 5개 시험 병렬 확장 + Math 풀이 (에이전트 23개 = 오늘 사용량의 주범)

Before: "…다른 5개 시험 RW 해설들에 대해서도 동일하게 병렬작업으로 만들어줘. Math 풀이 해설도 단계별 풀이 형식으로 별도 설계로 진행해 줘."

After: → "…병렬작업으로 만들어줘. 생성 에이전트는 전부 sonnet으로 지정하고(기계 검증이 있으니), Math 풀이도 sonnet + sympy 검증으로. 설계와 독립 감수 에이전트만 fable을 유지해줘."

사례 3 — 구조 조사·탐색류 (첫 프롬프트의 HomeBase 구조 파악 등)

Before: "…먼저 구조를 상세하게 파악하고 어떻게 만들 수 있는지를 검토하고 알려줘. 필요하면 복수의 전문 에이전트들을 만들어서 진행하고…"

After: → "…필요하면 복수의 전문 에이전트들을 만들어서 진행하되, 단순 파일 탐색·구조 조사 에이전트는 haiku나 sonnet으로 써줘."

한 번에 해결하는 방법: 매번 쓰기 번거로우면 CLAUDE.md에 규칙 한 줄을 박아두면 된다 — "서브에이전트 기본 모델: 대량 생성·조사는 sonnet, 단순 탐색·확인은 haiku, 설계·감수만 메인 모델. 예외는 명시적으로 지시." 이후엔 프롬프트에 아무것도 안 붙여도 이 규칙이 적용된다.

이렇게 지정했어도 — 기계 검증(재구성 일치·정답 일치·sympy)과 독립 감수가 이미 품질을 보증하므로 — 결과 품질은 거의 동일했을 것이다. 예상 절감: 전체 사용량의 60~70% (20% 사용 → 6~8% 수준).

warning: 반대로 아끼면 안 되는 곳: 스펙 작성, 아키텍처 결정, 오류 원인 진단, 최종 감수. 여기서 작은 모델이 낸 실수는 대량 재작업으로 돌아와 더 비싸진다.


7. 요약

  1. Playwright는 "브라우저를 코드로 조작"하는 도구로, 테스트를 넘어 수집·자동화·모니터링·AI 에이전트의 손까지 확장된다. 오늘 세션이 그 대부분의 패턴(CDP 세션 활용, 내부 API 발견, 실브라우저 검증, 스크린샷 감수)을 실전으로 검증했다.
  2. 도구 선택은 API > 정적 파싱 > Playwright > Playwright MCP 순서로 가볍게 시작한다.
  3. HomeBase 발전 1순위는 테스트센터 자동 동기화 (기존 파이프라인 + 감시 루프), 그다음 아침 헬스체크와 vox E2E 테스트.
  4. LLM 비용의 핵심 레버는 서브에이전트 모델 지정 — "정교한 스펙(Fable) + 대량 생산(Sonnet) + 기계 검증 + 표본 감수(Fable)" 패턴으로 품질 손실 없이 60% 이상 절감 가능.

참고: Playwright 공식 · Playwright MCP · Playwright AI Ecosystem 2026 (TestDino) · Browser Automation for AI Agents 2026 (fastCRW)