Playwright 사용을 중단했습니다. 대신 사용한 것은 이것입니다.

발행: 2시간 전 (2026년 4월 24일 PM 05:13 GMT+9)

8 분 소요

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, code blocks, URLs, and technical terms.

Playwright가 놓치는 점

Playwright는 단일 사용자, 결정론적 UI 흐름을 위해 설계되었습니다. 선택자를 작성하고, 인증 픽스처를 설정하고, 상태를 모킹하며, 고정된 순서를 클릭하는 스크립트를 실행합니다. 간단한 로그인‑및‑결제 흐름에는 문제가 없습니다.

대부분의 실제 애플리케이션은 공유 상태와 상호작용하는 여러 역할을 가지고 있습니다. 고객이 요청을 제출하고, 운영자가 이를 검토해 전문가를 배정하고, 전문가가 작업을 수행하며, 고객이 결제하고, 운영자가 배송합니다. 각 단계는 이전 단계에 의존하며, 각 행위자는 서로 다른 인증된 사용자입니다.

Playwright에서는 이것이 다음을 의미합니다:

역할당 하나씩 여러 인증 상태 파일
각 테스트 전에 데이터베이스를 시드하는 픽스처
UI가 바뀔 때마다 깨지는 선택자
실제 상호작용 하나를 테스트하기 전에 수백 줄의 보일러플레이트

사용자가 이미 자연스럽게 수행하는 일을 설명하기 위해 별도의 병렬 코드베이스를 유지하게 됩니다.

agent‑browser가 대신 하는 일

agent‑browser 는 AI 에이전트가 접근성 트리를 통해 브라우저를 제어할 수 있게 해 주는 CLI 입니다.

page.locator('[data-testid="submit"]').click()

와 같이 코드를 작성하는 대신, 원하는 동작을 자연어로 설명하면 에이전트가 방법을 찾아 실행합니다.

선택자가 필요 없습니다.
깨지기 쉬운 CSS 경로가 없습니다. 버튼에 라벨이 있으면 에이전트가 찾아 클릭합니다.
UI가 변경되어도 테스트가 깨지지 않습니다 — 에이전트가 자동으로 적응합니다.

역할 격리

역할당 Chrome 프로필 디렉터리를 하나씩 만들고, 한 번 로그인해 둡니다.

mkdir -p ~/.config/google-chrome/app-customer
mkdir -p ~/.config/google-chrome/app-operator
mkdir -p ~/.config/google-chrome/app-specialist

npx agent-browser \
  --profile ~/.config/google-chrome/app-operator \
  --headed \
  open https://yourapp.com/sign-in

세션이 지속됩니다. --profile 옵션을 사용해 실행할 때마다 자동으로 해당 프로필을 불러옵니다.

매직 링크

테스트 계정으로는 yopmail 을 사용합니다 — 일회용 인박스이며 별도 회원가입 없이 매직 링크를 바로 사용할 수 있습니다. 이메일 전송 제한에 걸리면, 관리 API를 통해 매직‑링크 URL을 직접 생성하고 브라우저에서 열면 됩니다. (이 경우 이메일이 전송되지 않습니다.)

curl -X POST https://.supabase.co/auth/v1/admin/generate_link \
  -H "Authorization: Bearer $SERVICE_ROLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type":"magiclink","email":"test@example.com"}' \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['action_link'])"

Source: …

오케스트레이터 패턴

멀티‑역할 골든‑패스 테스트를 위해, 하나의 Claude 세션이 오케스트레이터 역할을 합니다. 이 세션은 한 번에 하나씩 서브‑에이전트를 생성하며, 각각은 특정 역할을 수행합니다. 상태는 공유된 JSON 파일을 통해 앞으로 흐릅니다.

Orchestrator (main Claude session)
  ├── spawn Agent(customer)    → submits request  → writes request_id
  ├── spawn Agent(operator)    → assigns handler  → writes handler_id
  ├── spawn Agent(specialist)  → does work
  ├── spawn Agent(operator)    → reviews + approves
  ├── spawn Agent(customer)    → pays or confirms
  └── spawn Agent(customer)    → leaves feedback

상태 파일

{
  "run_id": "run-2026-04-24",
  "current_request_id": null,
  "confirmation_token": null,
  "steps_completed": []
}

각 서브‑에이전트는 현재 상태가 주입된 자체 포함 프롬프트를 받습니다. 에이전트는 새로운 값—예를 들어 URL에 표시되는 ID나 토큰—을 보고하고, 오케스트레이터는 다음 에이전트를 생성하기 전에 이를 파일에 기록합니다.

결과는 로그 파일에 추가되며, 실패가 발생해도 중단하지 않고 log‑and‑continue 방식으로 진행됩니다.

[operator] 전문가 지정 — 통과

[specialist] 작업 제출 — 통과

[operator] 작업 승인 — 실패: 승인 버튼을 찾을 수 없음

[customer] 수령 확인 — 통과

The cost argument is dead

AI 기반 테스트에 대한 주요 반론은 항상 비용이었다. Claude API 호출은 무료가 아니지만 Playwright는 무료다.

Claude Code를 구독으로 실행한다면 그 논거는 사라진다. 서브‑에이전트는 토큰당 청구가 아니라 구독에 따라 실행된다. 전체 10‑단계 골든‑패스 실행은 추가 비용이 들지 않는다.

Playwright가 남는 유일한 경우는 순수 속도 — 테스트당 밀리초 vs. 에이전트 실행당 분. 이는 빡빡한 CI 루프에서 매 커밋마다 테스트가 필요할 때만 의미가 있다. 배포 전 검사, QA 실행, 혹은 서브‑초 CI 파이프라인이 아닌 경우 Playwright를 선택할 실질적인 이유가 없다.

실제 의미

나는 몇 달 동안 Playwright 테스트를 작성하지 않았다. 에이전트 테스트는 더 넓은 범위를 커버하고, 덜 자주 깨지며, 설정하는 데 걸리는 시간도 훨씬 적다. 내가 포기한 유일한 것은 매 커밋마다 테스트를 실행할 수 있었던 점이다 — 6‑role 흐름을 다루는 통합 테스트의 경우, 어쨌든 현실적이지 않았다.

아직도 다중 역할 통합 흐름을 위한 Playwright 테스트를 작성하고 있다면, 이 설정을 한 번 시도해 보라. 다시 돌아가지 않을 가능성이 크다.