AI 기반 E2E 테스트의 진화: Playwright MCP에서 CLI로

Playwright MCP가 열어준 가능성, 그리고 그 다음 단계

---

들어가며

AI 코딩 에이전트가 일상적인 개발 도구가 되면서, 테스트 자동화 방식도 빠르게 바뀌고 있다. 그 변화의 중심에는 브라우저를 에이전트가 직접 다루게 만드는 도구들이 있다.

이 글에서는 세 가지 접근 방식을 비교한다.

• Playwright MCP — AI 에이전트와 브라우저를 연결하는 프로토콜 서버
• playwright-cli — Microsoft가 새롭게 출시한 코딩 에이전트 전용 CLI
• agent-browser — Vercel Labs가 만든 범용 브라우저 자동화 CLI

단순히 성능을 비교하는 글이 아니다. 각각이 어떤 문제를 풀기 위해 만들어졌는지, 그리고 실제 프로젝트에서 어떤 상황에 어떤 도구를 써야 하는지를 짚어보려 한다.

---

1. Playwright MCP가 열어준 가능성

MCP란 무엇인가

MCP(Model Context Protocol)는 AI 모델이 외부 도구와 상호작용하는 표준 인터페이스다. Playwright MCP는 이 인터페이스를 통해 Claude, Cursor, Copilot 같은 AI 에이전트가 Playwright가 제어하는 브라우저와 직접 통신할 수 있게 해준다.

에이전트 입장에서 보면 강력한 도구다. 브라우저 위에서 일어나는 모든 일 — 클릭, 입력, 네비게이션, DOM 상태 — 을 실시간으로 파악하면서 다음 행동을 결정할 수 있다.

MCP 기반 테스트의 실제 워크플로

1. 에이전트: "로그인 플로우를 테스트해줘"
2. Playwright MCP: 브라우저 열기 → 페이지 접근성 트리 전송
3. 에이전트: 트리 분석 → 로그인 폼 탐지 → fill/click 명령
4. Playwright MCP: 실행 결과 + 변경된 DOM 트리 전송
5. 에이전트: 결과 판단 → 다음 액션 결정
6. ...반복

이 루프는 직관적이다. 에이전트가 사람처럼 브라우저를 보면서 판단하고 행동한다. 코드를 먼저 작성하지 않아도 되고, 셀렉터를 직접 찾지 않아도 된다.

MCP가 실제로 빛나는 순간

Playwright MCP는 다음 상황에서 특히 효과적이다.

탐색적 테스트(Exploratory Testing)
테스트 케이스가 사전에 정의되어 있지 않은 상황. 에이전트에게 "이 페이지에서 문제가 있는 부분을 찾아봐"라고 요청하면, 에이전트는 DOM 상태를 계속 갱신해 받으면서 다양한 인터랙션을 시도해볼 수 있다.

Self-healing 테스트
UI가 자주 바뀌는 프로젝트에서 CSS 셀렉터나 XPath 기반 테스트는 깨지기 쉽다. MCP 방식에서는 에이전트가 접근성 트리를 매번 새로 읽기 때문에, 요소의 위치나 속성이 바뀌어도 "버튼의 역할"을 기준으로 찾아낼 수 있다.

장기 실행 자율 워크플로
여러 페이지를 오가며 복잡한 시나리오를 탐색하는 작업. 에이전트가 현재 브라우저 상태를 계속 인식할 수 있어야 하는 경우다.

---

2. Playwright MCP의 구조적 한계

그런데 MCP 방식에는 근본적인 비용이 있다.

토큰 비용: 모든 스텝이 비싸다

MCP 방식에서 AI 에이전트는 매 인터랙션마다 전체 페이지 상태를 컨텍스트로 받는다. 접근성 트리는 예상보다 훨씬 크다. 간단한 로그인 페이지조차 수백 줄의 트리가 될 수 있고, 복잡한 대시보드라면 수천 줄도 넘는다.

# 한 번의 클릭이 이런 비용을 만든다
에이전트 → click 명령 전송
Playwright MCP → 클릭 실행 + 변경된 전체 DOM 트리 반환 (수천 토큰)
에이전트 → 트리 분석 후 다음 명령 결정

5~10번의 인터랙션으로 이루어진 단순한 테스트 하나가 수만 토큰을 소비한다. 이를 CI 파이프라인에서 매일 수십 번 돌린다면, 비용이 빠르게 쌓인다.

컨텍스트 윈도우 포화

더 심각한 문제는 컨텍스트 포화다. 긴 세션에서 에이전트의 작업 메모리가 브라우저 상태 데이터로 가득 차면, 실제 코드베이스와 테스트 의도에 대한 정보가 밀려난다.

이것은 단순히 느려지는 문제가 아니다. 에이전트가 "지금 무엇을 테스트하려 했는지"를 잊어버리거나, 이전에 탐색한 페이지 상태와 현재를 혼동하는 오류로 이어진다.

비결정론적 실행

MCP 기반 에이전트 테스트는 실행할 때마다 결과가 달라질 수 있다. 에이전트가 매번 DOM을 새로 해석하고 액션을 결정하기 때문이다. 같은 테스트 시나리오가 어떤 날은 5번의 클릭으로, 어떤 날은 7번의 클릭으로 완료될 수 있다.

이는 CI에서 치명적이다. 파이프라인에서 필요한 것은 "이 테스트가 오늘도 어제와 같은 방식으로 실행됐는가"라는 확신이다.

재사용 불가능한 결과물

MCP를 통해 에이전트가 테스트를 수행하고 나면, 그 과정은 기록으로 남지 않는다. 다음번에 같은 시나리오를 테스트하려면 처음부터 다시 에이전트가 탐색해야 한다. 수동 QA와 구조적으로 크게 다르지 않다.

---

3. CLI가 대안이 되는 이유

MCP의 문제는 "브라우저 상태 전체를 항상 모델 컨텍스트에 밀어넣는다"는 설계에서 온다. CLI 기반 도구들은 이 문제를 근본적으로 다르게 접근한다.

핵심 원리: 필요한 것만 읽는다

CLI 방식에서는 에이전트가 먼저 snapshot 명령으로 페이지를 탐색하고, 필요한 요소의 참조(ref)를 얻은 뒤, 그 ref로만 이후 명령을 실행한다.

# agent-browser 방식
agent-browser snapshot -i          # 인터랙티브 요소만 접근성 트리로 반환
# → @e1 [input type="email"], @e2 [input type="password"], @e3 [button] "Submit"

agent-browser fill @e1 "user@example.com"
agent-browser fill @e2 "password123"
agent-browser click @e3

# playwright-cli 방식
playwright-cli snapshot             # 요소 ref 반환
playwright-cli fill e15 "user@example.com"
playwright-cli click e21

두 방식 모두, 에이전트는 snapshot 결과를 한 번 받은 뒤 명령만 보낸다. 매 스텝마다 전체 DOM을 받지 않는다.

---

4. playwright-cli: 테스트 코드 생성까지의 원스톱

playwright-cli는 단순한 브라우저 제어 CLI가 아니다. AI 에이전트가 브라우저를 조작하는 과정이 그대로 Playwright 테스트 코드가 된다는 점이 핵심이다.

탐색 → 코드 생성 → CI 실행의 흐름

# 1단계: 에이전트가 사이트 탐색
playwright-cli open https://my-app.com/login
playwright-cli snapshot
playwright-cli fill e3 "user@example.com"
playwright-cli fill e4 "password123"
playwright-cli click e5

# 2단계: 위 인터랙션이 자동으로 .spec.ts로 변환
# → login.spec.ts 생성

# 3단계: 이후 CI에서는 에이전트 없이 실행
npx playwright test login.spec.ts

에이전트가 "한 번 탐색"하는 비용으로 이후 수백 번 실행 가능한 결정론적 테스트가 만들어진다.

YAML flow → spec 변환

playwright-cli는 테스트 시나리오를 YAML 형태로 표현하고, 이를 .spec.ts로 변환하는 파이프라인도 지원한다. 사람이 읽을 수 있는 테스트 명세를 에이전트가 실행 가능한 코드로 바꾸는 방식이다.

# checkout-flow.yaml
flow:
  - open: https://shop.example.com/cart
  - click: "결제하기 버튼"
  - fill:
      label: "이메일"
      value: "test@example.com"
  - assert: "주문 완료" 페이지 도달

크로스 브라우저 지원

playwright-cli는 Playwright 위에서 동작하므로, Chrome/Firefox/WebKit/Edge 전체를 지원한다. Safari 렌더링 이슈를 잡아야 하는 경우, MCP나 agent-browser로는 할 수 없는 테스트를 커버한다.

---

5. agent-browser: 서버리스 환경의 브라우저 자동화

agent-browser는 테스트 코드 생성보다는 범용 브라우저 자동화에 초점을 맞춘다. Vercel의 서버리스·엣지 환경과의 통합이 특히 자연스럽다.

Daemon 아키텍처의 실질적 이점

agent-browser는 백그라운드 daemon을 통해 브라우저 세션을 유지한다. 각 명령이 별도의 프로세스를 시작하지 않아도 된다.

# 명령 체이닝 — daemon이 세션을 유지하므로 브라우저 재시작 없음
agent-browser open https://example.com \
  && agent-browser wait --load networkidle \
  && agent-browser snapshot -i \
  && agent-browser fill @e1 "test@example.com" \
  && agent-browser click @e3

annotate 스크린샷

에이전트가 요소를 "보면서" 작업하는 경우, --annotate 플래그로 인터랙티브 요소에 번호 레이블을 오버레이한 스크린샷을 찍을 수 있다. 번호는 @eN ref와 1:1 대응되어, 시각적 확인과 코드 실행을 동시에 처리한다.

agent-browser screenshot --annotate
# 출력:
# [1] @e1 button "로그인"
# [2] @e2 input "이메일"
# [3] @e3 link "회원가입"

agent-browser click @e1  # 번호 보고 바로 클릭

Vercel Sandbox에서의 활용

import { Sandbox } from "@vercel/sandbox";

const sandbox = await Sandbox.create({ runtime: "node24" });
await sandbox.runCommand("agent-browser", ["open", "https://my-app.vercel.app"]);
const result = await sandbox.runCommand("agent-browser", ["snapshot", "-i"]);
// → 배포된 프리뷰 URL을 에이전트가 자동으로 탐색·검증
await sandbox.stop();

각 PR의 프리뷰 배포를 에이전트가 자동으로 탐색하고 이상 여부를 보고하는 파이프라인을 구성하기에 적합하다.

iOS Simulator 지원

agent-browser는 최근 iOS Simulator와 실제 기기에서의 모바일 Safari 테스트도 지원하기 시작했다. 모바일 웹 자동화까지 하나의 CLI로 커버하려는 방향성이 보인다.

---

6. 세 도구의 실질적 비교

토큰 소비 관점

도구	매 인터랙션 비용	세션 길이에 따른 변화
Playwright MCP	높음 (전체 DOM 전송)	길수록 컨텍스트 포화 위험
playwright-cli	낮음 (snapshot 후 ref만)	일정하게 낮음
agent-browser	낮음 (snapshot 필터링 가능)	일정하게 낮음

테스트 생명주기 관점

Playwright MCP는 테스트를 "실행"하는 도구다. playwright-cli는 테스트를 "만들고 실행하는" 도구다. agent-browser는 브라우저를 "조작하는" 도구다.

이 차이가 CI 통합에서 결정적으로 갈린다. playwright-cli로 한 번 생성한 spec 파일은 이후 에이전트 없이도 반복 실행된다. MCP 방식은 매번 에이전트가 필요하다.

실행 환경 관점

• 로컬 개발 + CI: playwright-cli가 가장 자연스럽다. Playwright 생태계와 완전히 통합된다.
• 서버리스 / 컨테이너: agent-browser가 적합하다. Node.js 없이 Rust 바이너리로 동작하고 Vercel Sandbox와 바로 통합된다.
• 장기 자율 탐색: Playwright MCP가 여전히 강점을 가진다. 에이전트가 계속 브라우저 상태를 인식해야 하는 워크플로에서는 MCP의 rich introspection이 필요하다.

---

7. 어떤 상황에 무엇을 쓸 것인가

Playwright MCP를 선택할 때

• 테스트 시나리오가 사전에 정의되어 있지 않고, 에이전트가 자율적으로 버그를 찾아야 하는 경우
• UI가 매우 복잡하고 동적이어서 self-healing이 반드시 필요한 경우
• 장기 실행 자율 워크플로에서 에이전트가 지속적으로 브라우저 상태를 인식해야 하는 경우
• 토큰 비용보다 탐색의 유연성이 더 중요한 프로젝트

playwright-cli를 선택할 때

• 반복 실행 가능한 E2E 테스트를 CI에 통합하는 것이 목표인 경우
• AI 에이전트가 탐색한 결과를 .spec.ts로 변환해 코드베이스에 추가하고 싶은 경우
• Chrome/Firefox/Safari/Edge 크로스브라우저 테스트가 필요한 경우
• 기존 Playwright 프로젝트에 AI 워크플로를 점진적으로 도입하는 경우

agent-browser를 선택할 때

• Vercel, AWS Lambda 등 서버리스 환경에서 브라우저 자동화가 필요한 경우
• PR 프리뷰 배포를 에이전트가 자동으로 탐색·검증하는 파이프라인을 구성하는 경우
• 테스트 코드 생성보다는 자동화·스크래핑·모니터링이 주 목적인 경우
• 모바일 Safari(iOS Simulator)를 포함한 멀티 플랫폼 자동화가 필요한 경우

현실적인 조합 전략

세 도구는 경쟁 관계가 아니라 역할이 다르다. 실제 프로젝트에서는 이렇게 조합하는 것이 자연스럽다.

[개발 중]
Playwright MCP → 에이전트가 새 기능 탐색, 버그 발견

[테스트 코드화]
playwright-cli → 발견한 시나리오를 spec 파일로 변환

[CI 실행]
npx playwright test → 에이전트 없이 결정론적으로 반복 실행

[배포 후 모니터링]
agent-browser (Vercel Sandbox) → 프리뷰 URL 자동 검증

---

마치며

Playwright MCP는 AI 에이전트가 브라우저를 직접 다룰 수 있다는 가능성을 보여줬다. 그러나 "가능하다"와 "효율적이다"는 다른 이야기다.

CLI 기반 도구들은 MCP가 가진 토큰 비용과 비결정론적 실행이라는 문제를 구조적으로 해결한다. playwright-cli는 AI 탐색과 결정론적 테스트 실행 사이의 간극을 메우는 도구이고, agent-browser는 서버리스 환경에서 브라우저 자동화를 가능하게 하는 도구다.

E2E 테스트 자동화에서 AI의 역할은 점점 커지고 있다. 중요한 것은 에이전트를 매번 브라우저 앞에 앉히는 것이 아니라, 에이전트가 한 번 탐색한 결과를 수백 번 재사용할 수 있는 구조를 만드는 것이다.

---

참고: agent-browser는 https://github.com/vercel-labs/agent-browser 에서, playwright-cli는 npm install @playwright/cli 로 설치할 수 있다.