품질 보증(QA)과 Playwright
졸업 프로젝트로 진행하는 WYAD(Where you ad)는 대시보드·워크스페이스·인증 등 상태 변화가 많은 화면이 특징입니다.
현재는 ESLint·빌드·Storybook 수준의 검증만 있어, 실제 브라우저에서의 사용자 흐름은 배포·시연 전에 수동으로 확인해야 한다는 문제가 있었고 서비스가 복잡해질수록 수동으로 테스트를 해야한다는 불편함이 있었습니다.
이번 글에서는 Playwright 기반 E2E 테스트 환경을 도입하고 Cursor를 활용해 시나리오 작성을 자동화하는 프로젝트 초기 세팅 내용을 기록하고자 합니다!
1. 품질 보증(QA)과 Playwright
품질 보증(QA: Quality Assurance)이란 소프트웨어가 요구사항을 충족하고 결함없이 동작하도록 보장하는 체계적인 프로세스입니다.
그 중에서도 Playwright는 Microsoft에서 만든 오픈소스 브라우저 자동화 프레임워크로 웹 애플리케이션의 End-to-End(E2E) 테스트를 작성하고 실행하는 데 주로 사용됩니다.
2. QA가 필요한 이유는 무엇인가?
소프트웨어는 의도와 다르게 동작하기 쉽고 그 차이는 사용자 손해·비용·신뢰 손실로 이어집니다.
개발자는 기능 구현에 집중하지만 QA는 실제 사용자 시나리오에서 망가지지 않았는가에 집중합니다.
같은 제품을 보지만 검증하는 질문이 다르다는 점에서 실무에서 위험을 줄일 수 있기 때문에 QA가 필요하다고 생각합니다.
3. 핵심 아이디어
MCP로 AI가 실제 브라우저에서 시나리오를 한 번 수행하고, 그 결과를 바탕으로 실행 가능한 Playwright 코드를 만든 뒤,
같은 결과가 나오는지를 확인하는 2단계 워크플로우입니다.
직접 자동화 적용해보기
0. 목표 및 범위 정하기
자동화할 시나리오 MVP와 테스트 환경 정하기
- 로컬: pnpm dev(Vite 기본 포트)
- API: 실제 백엔드 API
- 인증: 테스트 계정
1. 환경 설정
Cursor에 Playwright MCP 연동 및 Playwright 패키지 설치를 해줍니다.
Cursor Setting -> Tools & MCPs -> installed MCP Servers -> New MCP Server
2. Playwright 기반 만들기
(1) 브라우저 바이너리 설치
pnpm exec playwright install
(2) playwright.config.ts를 앱에 맞게 수정
- playwright.config.ts는 Playwright가 E2E 테스트를 어떻게 돌릴지 정하는 설정 파일입니다.
- pnpm run test:e2e 할 때 이 파일을 읽습니다.
(3) smoke.spec.ts
- 이 파일은 Playwright E2E 테스트 중 가장 얇은 스모크 테스트 하나를 담고 있습니다.
- 앱이 아예 안 뜨는 수준의 큰 문제는 없는지를 빠르게 확인하는 용도입니다.
3. Cursor 채팅에 시나리오 입력하기 -> Playwright MCP로 시나리오 실행
WhereYouAd E2E 테스트를 수행해 주세요.
[대상]
- BASE_URL: {BASE_URL}
- 테스트 계정: .env의 E2E_USER_EMAIL / E2E_USER_PASSWORD 사용
[시나리오]
1. {BASE_URL}/login 으로 이동한다.
2. heading "로그인"이 보일 때까지 대기한다.
3. "이메일" 라벨이 있는 입력란(placeholder "이메일을 입력하세요")에 E2E 이메일을 입력한다.
4. "비밀번호" 라벨이 있는 입력란(placeholder "비밀번호를 입력하세요")에 E2E 비밀번호를 입력한다.
5. "로그인하기" 버튼을 클릭한다.
6. URL이 /dashboard 를 포함하는지 확인한다.
7. 사이드바에 "대시보드" 메뉴가 보이는지 확인한다.
8. (선택) 헤더에 "AI 요약하기" 버튼(aria-label)이 보이면 성공으로 본다.
[기대 결과]
- 로그인 성공 후 /dashboard 에 머문다.
- 로그인 실패 토스트("로그인에 실패했습니다.")가 뜨지 않는다.
WhereYouAd E2E 테스트를 수행해 주세요.
[대상]
- BASE_URL: {BASE_URL}
[시나리오]
1. /login 으로 이동한다.
2. 링크 "이메일/비밀번호를 잊어버렸어요" 를 클릭한다.
3. URL이 /find-email 인지 확인한다.
4. heading에 "이메일 찾기를 위해", "휴대폰 인증을 진행할게요" 문구가 보이는지 확인한다.
5. placeholder "전화번호를 입력하세요" 입력 필드가 보이는지 확인한다.
[기대 결과]
- 실제 휴대폰 인증·SMS는 진행하지 않는다 (UI 진입만 검증).
WhereYouAd E2E 테스트를 수행해 주세요.
[대상]
- BASE_URL: {BASE_URL}
- 시크릿/쿠키 없이 새 브라우저 컨텍스트(비로그인)로 실행
[시나리오]
1. 로그인하지 않은 상태에서 {BASE_URL}/dashboard 로 직접 이동한다.
2. URL이 /login 으로 바뀌는지 확인한다.
3. heading "로그인"이 보이는지 확인한다.
[기대 결과]
- AuthGuard에 의해 보호된 페이지는 /login 으로 리다이렉트된다.
WhereYouAd E2E 테스트를 수행해 주세요.
[전제]
로그인 완료, URL /dashboard (또는 로그인 후 자동 진입)
[조작]
(필요 시) 사이드바 펼치기 → 링크 "통합 대시보드" 클릭
[기대]
- URL: /dashboard
- 본문: "실시간 트래픽 변화" visible
- 헤더: "대시보드" / "통합 대시보드" breadcrumb
- (선택) button "AI 요약하기"
[비검증]
KPI 숫자, 차트 데이터 값, AI 스트리밍
6. 터미널에서 테스트 실행
run test:e2e
pnpm exec playwright show-report
현재는 테스트가 실패할 때만 스크린샷과 영상을 report에 첨부하게 되어 있으나, config에서 아래 코드를 적용하면 리포트 Attachments에 이미지와 mp4가 붙습니다!
trace: process.env.CI ? 'on-first-retry' : 'on',
대시보드 로딩이 오래 걸린 게 아니라 테스트로직과 사이드바 상태가 일치하지 않아서 누를 수 없는 하위메뉴 열기를 기다리다가 타임 아웃된 것입니다....즉 로그인 후 /dashboard로 이미 들어갔는데 이때는 사이드바에서 대시보드 메뉴가 이미 펼쳐진 상태. 테스트는 이미 펼쳐져 있는데 또 펼치려고 해서 실패한 상황!!!
이렇게!! UI 흐름을 잘 고려하여 테스트 코드를 작성해야 한다는 교훈을 또 얻었습니다 :)
7. 결과 일치 여부 확인
MCP로 AI가 본 결과와 생성된 스크립트 실행 결과가 같은지 검증합니다.
- 같은 URL·화면까지 도달하는가
- assertion이 MCP가 “성공”이라고 한 조건과 같은가
- 실패 시 스크린샷·trace·비디오(playwright.config.ts에 screenshot, video, trace 설정)로 원인 비교
회고
WYAD 프로젝트를 통해 Playwright E2E를 처음 도입해보았습니다!
Cursor MCP로 시나리오를 탐색 및 적용한 뒤 *.spec.ts로 옮기는 흐름을 시도했습니다. 인증 가드, 로그인, 네비게이션 등 초기 진입 테스트를 비교적 짧은 시간에 갖출 수 있었다는 장점이 있는 것 같습니다.
좋았던 점
MCP로 "로그인 → 대시보드", "비로그인 시 /dashboard 리다이렉트" 같은 실제 화면을 보면서 시나리오를 잡고, 그걸 바탕으로 spec 초안을 만드는 속도가 빨랐습니다.
처음부터 Playwright 문서만 읽으며 모든 selector를 손으로 찾는 것보다 진입 장벽이 낮았다고 생각됩니다!
단위 테스트·Storybook과 달리 E2E는 라우팅, 인증, 사이드바, API 연동이 맞물린 뒤 사용자가 보는 화면을 통째로 검증합니다. 로그인 후 URL이 /dashboard인지, 가드가 /login으로 보내는지처럼 "배포해도 최소 이건 된다!!"는 안전망을 만들 수 있어서 꽤나 가치 있게 느껴졌습니다.
playwright.config.ts에 스크린샷·비디오·trace를 설정해두니 실패 시 리포트로 그 순간 화면이 어땠는지를 볼 수 있었습니다. 테스트 실패 시 원인 추적이 수월하다는 장점이 있었습니다.
아쉬운 점
navigation.spec.ts에서 로그인 후 이미 /dashboard에 들어오면 사이드바 대시보드의 하위 메뉴가 펼쳐진 상태인데, spec는 "통합 대시보드가 안 보이면 하위 메뉴 열기를 눌러라"라고 가정했습니다. 화면에는 하위 메뉴 닫기만 있는데 열기를 기다리다 30초 타임아웃이 난 것입니다. 이건 테스트가 실제 UI 상태를 잘못 가정해서 깨진 경우였습니다. 하지만 스냅샷을 통해 빠르게 문제점을 파악할 수 있어서, 스냅샷·URL·assertion을 맞춰 두고 spec을 고쳐야 한다는 점이 와닿았습니다....
결과적으로 Cursor MCP는 초안 작성과 탐색에 매우 강하고, 유지보수 가능한 E2E로 만들기 위해서는 디테일을 보완해야 한다는 것을 느꼈습니다. Cursor MCP는 테스트를 빠르게 시작하게 해 주는 도구로 활용하는 것이 좋을 것 같습니다.
처음엔 "테스트 코드까지 써야 하나?" 싶었는데, 막상 해보니 배포 전 불안감이 확실히 줄었습니다. 다음 단계로는 CI 환경에서 자동 실행되도록 GitHub Actions와 연동해볼 예정입니다!
긴 글 읽어주셔서 감사합니다!!