Playwright + AI: CLI vs MCP

AI가 브라우저를 조작하는 두 가지 방법

E2E 테스트를 작성할 때 가장 번거로운 것은 올바른 Locator를 찾는 것과 실패 원인을 파악하는 것이다. 브라우저를 열고, DevTools로 요소를 찾고, 테스트를 실행하고, 실패하면 다시 돌아가서 확인하는 반복.

AI 코딩 어시스턴트(Claude Code 등)가 실제 브라우저를 직접 조작하면서 이 과정을 도와줄 수 있는데, 방법이 두 가지나 있다. Playwright MCP(MCP Server)와 playwright-cli(Skill)다.

처음에는 MCP만 사용했는데, CLI 방식이 대부분의 경우 더 효율적이라는 걸 알게 되었다. 그 차이를 정리했다.

세 가지 도구, 각자의 역할

AI 어시스턴트에서 Playwright를 활용하는 방법은 정확히 3가지다:

playwright-cli: CLI가 MCP보다 나은 이유

playwright-cli는 Bash 명령어를 통해 브라우저를 제어한다. MCP 서버 설정이 필요 없고, Skill만 추가하면 바로 사용 가능하다.

핵심 장점: 매 액션마다 코드가 나온다

playwright-cli의 가장 강력한 기능은 모든 액션이 대응하는 Playwright 코드로 변환되어 출력된다는 점이다:

playwright-cli fill e1 "user@example.com"
# 출력: await page.getByRole('textbox', { name: 'Email' }).fill('user@example.com');

playwright-cli click e3
# 출력: await page.getByRole('button', { name: 'Sign In' }).click();

이 출력을 수집하면 바로 테스트 파일로 옮길 수 있다. MCP에서는 --codegen 옵션을 별도로 설정해야 하고, 코드 출력 형태도 다르다.

스냅샷이 파일로 남는다

매 명령 결과가 YAML 파일로 자동 저장된다. 이전 상태와 현재 상태를 비교하기 좋고, 스냅샷 파일을 참조하면서 테스트를 작성할 수 있다.

playwright-cli open http://localhost:3000
playwright-cli snapshot
# → .playwright-cli/page-2026-02-24T10-30-00.yml 자동 저장

playwright-cli click e5
# → 클릭 후 새 스냅샷 자동 저장

Request Mocking이 한 줄이면 된다

E2E 테스트에서 CUD(Create/Update/Delete) 작업이 실제 서버에 영향을 주는 것을 방지할 때:

# 간단한 응답 모킹
playwright-cli route "**/api/users" --body='[{"id":1}]' --content-type=application/json

# 조건부 응답
playwright-cli run-code "async page => {
  await page.route('**/api/invoices', route => {
    if (route.request().method() === 'POST') {
      route.fulfill({ body: JSON.stringify({ success: true }) });
    } else {
      route.continue();
    }
  });
}"

# 모킹 해제
playwright-cli unroute

MCP에서는 browser_evaluate로 JavaScript를 직접 작성해야 한다.

Storage 관리가 편하다

쿠키, localStorage, sessionStorage를 CLI 명령어로 직접 조작할 수 있다:

# 인증 쿠키 주입
playwright-cli cookie-set auth_token my-token-value

# 저장된 인증 상태 로드
playwright-cli state-load ./e2e/.auth/user.json

# localStorage 확인
playwright-cli localstorage-list

MCP가 여전히 필요한 경우

playwright-cli가 대부분의 경우 더 효율적이지만, MCP만의 강점이 있다.

Vision 모드

Canvas, 복잡한 SVG, 커스텀 렌더링 요소처럼 접근성 트리에 잡히지 않는 시각적 요소를 다룰 때는 MCP의 Vision 모드가 필요하다. 스크린샷을 촬영하고 좌표 기반으로 인터랙션한다.

{
  "args": ["-y", "@playwright/mcp@latest", "--caps", "vision"]
}

Testing 전용 도구

browser_generate_locator, browser_verify_element_visible 같은 전용 검증 도구는 MCP에서만 제공한다.

결론 테이블, 폼, 네비게이션 같은 일반적인 웹 UI는 CLI의 접근성 스냅샷만으로 충분하다. Vision 모드가 필요한 차트/Canvas UI에서만 MCP를 꺼내자.

상황별 선택 가이드

실전 워크플로우: CLI로 테스트 작성하기

Step 1. 브라우저 열고 인증

playwright-cli open http://localhost:3000
playwright-cli cookie-set auth_token my-token
playwright-cli goto http://localhost:3000/dashboard

Step 2. 스냅샷으로 페이지 구조 파악

playwright-cli snapshot
# 접근성 트리가 YAML로 저장됨
# heading "대시보드" [level=1]
# navigation "Main Menu"
#   link "매출 관리" [ref=e3]
#   link "설정" [ref=e5]

Step 3. 액션 수행하며 코드 수집

playwright-cli click e3
# 출력: await page.getByRole('link', { name: '매출 관리' }).click();

playwright-cli snapshot
# 이동 후 페이지 구조 확인

Step 4. 수집한 코드로 테스트 파일 작성

import { test, expect } from '@playwright/test';

test('사이드바에서 매출 관리 페이지로 이동', async ({ page }) => {
  await page.goto('/dashboard');
  await page.getByRole('link', { name: '매출 관리' }).click();
  await expect(page).toHaveURL(/.*revenue/);
});

배운 점

참고 자료