Playwright 웹개발 테스트 자동화 실사용 가이드

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

배포 직전 버튼 하나가 안 눌리거나, 로그인 후 이동 경로가 깨지는 문제를 한 번이라도 겪어봤다면 웹개발 테스트 자동화는 선택이 아니라 작업 시간을 지키는 장치에 가깝습니다. 저는 2026년 기준으로 개인 프로젝트와 소규모 팀 프로젝트에서 Playwright를 계속 사용해 보면서, 단순한 테스트 도구가 아니라 반복 확인을 줄여 주는 개발 루틴으로 받아들이게 됐습니다.

특히 프론트엔드 화면이 자주 바뀌는 서비스에서는 사람이 매번 회원가입, 로그인, 검색, 결제 전 단계까지 클릭해 보는 방식이 오래 버티기 어렵습니다. 이 글은 공식 문서 요약이 아니라 실제로 써 보며 느낀 장단점, 설정 팁, 초보자가 막히는 지점을 중심으로 정리한 후기입니다.

Playwright를 고른 이유와 첫인상

설치보다 중요한 것은 테스트 범위였습니다

처음에는 Jest나 Vitest처럼 코드 단위 테스트만으로 충분하다고 생각했습니다. 하지만 실제 사용자는 함수 하나를 호출하지 않고 브라우저에서 버튼을 누르고, 폼을 작성하고, 페이지를 이동합니다. 그래서 브라우저 기준의 E2E 테스트가 필요했고, 그때 가장 현실적인 선택지가 Playwright였습니다.

코딩을 처음 배우는 분이라면 자동화 테스트라는 말이 조금 거창하게 들릴 수 있습니다. 하지만 핵심은 간단합니다. 사람이 하던 클릭과 입력을 코드로 저장해 두고, 수정할 때마다 같은 동작을 빠르게 반복하는 것입니다. 코딩의 기본 개념은 지식백과의 코딩 설명처럼 문제 해결 절차를 컴퓨터가 이해할 수 있게 만드는 일인데, 테스트 자동화도 그 연장선에 있습니다.

• 좋았던 점: Chromium, Firefox, WebKit을 한 번에 다뤄 크로스 브라우저 확인이 편했습니다.
• 아쉬웠던 점: 처음에는 locator 문법과 비동기 대기 방식이 낯설어 테스트가 왜 실패했는지 헷갈렸습니다.
• 가장 큰 장점: 실패 시 스크린샷, 비디오, trace가 남아 원인 추적이 생각보다 빠릅니다.

처음부터 모든 화면을 자동화하려고 하면 지칩니다. 저는 로그인, 핵심 폼 제출, 결제 전 확인처럼 서비스가 깨지면 바로 문제가 되는 흐름부터 테스트했습니다.

실제 프로젝트에 붙였을 때 체감한 장점

리팩터링할 때 마음이 훨씬 가벼워졌습니다

제가 가장 크게 체감한 순간은 CSS 구조와 컴포넌트 파일을 정리하던 때였습니다. 화면은 그대로 보여도 내부 코드는 꽤 많이 바뀌었고, 이전 같았으면 모든 페이지를 수동으로 클릭해 봤을 겁니다. 하지만 Playwright 테스트를 먼저 돌리니 로그인, 목록 조회, 검색 필터, 상세 페이지 이동이 정상인지 빠르게 확인할 수 있었습니다.

특히 웹개발에서는 눈으로 보이는 UI와 실제 동작이 다를 때가 많습니다. 버튼은 보이지만 disabled 상태가 잘못됐거나, 모바일 뷰에서 메뉴가 열리지 않거나, API 응답 이후 로딩 상태가 사라지지 않는 문제가 대표적입니다. Playwright는 이런 흐름을 사용자의 행동에 가깝게 검사할 수 있어 실무 감각과 잘 맞았습니다.

테스트 결과가 팀 대화의 기준이 됐습니다

작은 팀에서는 버그 제보가 대개 말로 오갑니다. "이거 안 되는 것 같아요"라는 표현만으로는 어떤 브라우저, 어떤 계정, 어떤 순서에서 실패했는지 파악하기 어렵습니다. Playwright의 trace 파일을 공유하면 클릭 순서와 화면 상태가 남기 때문에 대화가 훨씬 구체적으로 바뀝니다.

1. PR 전에 테스트 실행: 기능 추가 후 핵심 사용자 흐름이 깨졌는지 확인했습니다.
2. 버그 재현 코드 작성: 발견된 버그를 먼저 테스트로 만들고 수정했습니다.
3. 배포 전 스모크 테스트: 로그인, 주요 페이지 접근, 폼 제출만 빠르게 점검했습니다.

프로그래밍은 단순히 코드를 많이 쓰는 일이 아니라 의도한 동작을 재현 가능하게 만드는 과정입니다. 관련 개념을 더 넓게 보고 싶다면 프로그래밍의 기본 의미를 함께 읽어 보면 테스트 자동화가 왜 개발 과정의 일부인지 이해하기 쉽습니다.

초보자가 막히기 쉬운 설정과 해결 팁

locator를 대충 잡으면 유지보수가 힘들었습니다

처음에는 CSS 선택자처럼 .button-primary 같은 클래스를 자주 사용했습니다. 그런데 디자인 수정으로 클래스명이 바뀌자 테스트가 줄줄이 실패했습니다. 이후에는 버튼의 역할과 접근성 이름을 기준으로 찾는 방식, 예를 들어 getByRole을 우선 사용했습니다. 이 방식은 테스트 코드가 실제 사용자 경험에 더 가까워지고, 마크업 품질도 같이 좋아지는 효과가 있었습니다.

예를 들어 로그인 버튼을 찾을 때 단순히 class를 지정하기보다 role과 name을 활용하면 화면 구조가 조금 바뀌어도 테스트가 오래 살아남습니다. 테스트 자동화는 한 번 작성하고 끝나는 코드가 아니라 제품과 함께 유지되는 코드라서, 처음 선택자를 잘 잡는 것이 생각보다 중요했습니다.

• 추천: getByRole, getByLabel, getByText 순서로 검토합니다.
• 주의: nth 선택자는 화면 순서가 바뀌면 쉽게 깨질 수 있습니다.
• 팁: 테스트용 data-testid는 마지막 수단으로 쓰되, 복잡한 컴포넌트에는 꽤 유용합니다.

대기 처리를 직접 sleep으로 해결하지 않았습니다

자동화 테스트가 불안정해지는 가장 흔한 이유는 타이밍입니다. API 응답이 늦거나 애니메이션이 끝나기 전에 검증하면 테스트가 가끔 실패합니다. 초반에는 timeout을 길게 주는 방식으로 해결하려 했지만, 실행 시간만 늘고 원인은 그대로였습니다.

제가 정착한 방식은 명확한 상태를 기다리는 것입니다. URL 변경, 특정 텍스트 표시, 버튼 활성화, 네트워크 응답 이후 DOM 변화처럼 사용자가 실제로 확인할 수 있는 기준을 잡았습니다. 이렇게 바꾸니 테스트가 훨씬 안정적이었습니다.

테스트가 가끔만 실패한다면 도구 문제가 아니라 대기 조건이 모호한 경우가 많습니다. "몇 초 기다리기"보다 "무엇이 보일 때까지 기다리기"가 유지보수에 강했습니다.

실사용 기준 장단점 비교

장점은 빠른 피드백, 단점은 관리 비용입니다

Playwright를 쓰면 확실히 안심되는 구간이 생깁니다. 하지만 테스트 코드도 코드이기 때문에 방치하면 짐이 됩니다. 화면 문구를 자주 바꾸는 서비스라면 getByText 기반 테스트가 자주 깨질 수 있고, 테스트 데이터 관리가 부실하면 로컬에서는 통과하지만 CI에서는 실패하는 일이 생깁니다.

그래서 저는 모든 것을 E2E로 검증하지 않았습니다. 계산 로직은 단위 테스트, 컴포넌트 상태는 컴포넌트 테스트, 핵심 사용자 흐름만 Playwright로 검증했습니다. 이 균형을 잡아야 테스트 시간이 과하게 늘지 않고, 개발 속도도 유지됩니다.

가격과 도입 비용은 생각보다 낮았습니다

Playwright 자체는 오픈소스로 사용할 수 있어 도구 비용 부담은 크지 않았습니다. 실제 비용은 개발자의 시간에서 발생합니다. 처음 테스트 구조를 잡고, CI에서 브라우저를 설치하고, 테스트 계정을 준비하는 데 시간이 듭니다. 개인 프로젝트 기준으로는 반나절에서 하루 정도면 기본 흐름을 만들 수 있었고, 팀 프로젝트에서는 테스트 정책을 정하는 시간이 더 필요했습니다.

• 개인 프로젝트: 로그인과 핵심 CRUD만 자동화해도 충분히 효과를 봤습니다.
• 스타트업 프로젝트: 배포 전 스모크 테스트 중심으로 시작하는 것이 현실적이었습니다.
• 운영 서비스: 테스트 데이터 초기화, 계정 권한, 결제 모킹 전략까지 함께 설계해야 했습니다.

요즘 개발 환경에서는 AI와 자동화가 함께 쓰이는 흐름도 강해졌습니다. 다만 AI가 테스트 코드를 만들어 주더라도 검증 기준은 개발자가 결정해야 합니다. AI 시대의 학습과 판단에 관한 논의처럼, 도구가 좋아질수록 무엇을 확인해야 하는지 아는 능력이 더 중요해집니다.

제가 쓰는 Playwright 테스트 작성 루틴

기능 개발 직후 바로 테스트를 붙였습니다

처음에는 기능을 모두 만든 뒤 테스트를 작성했습니다. 그런데 시간이 지나면 어떤 예외 상황을 고려했는지 기억이 흐려지고, 테스트 작성이 숙제처럼 느껴졌습니다. 지금은 핵심 기능이 동작하는 순간 바로 최소 테스트를 붙입니다. 완벽한 테스트가 아니라도 주요 경로를 먼저 잠그는 느낌으로 접근합니다.

예를 들어 게시글 작성 기능을 만들었다면 제목 입력, 본문 입력, 저장 버튼 클릭, 작성 완료 메시지 확인까지를 하나의 흐름으로 테스트합니다. 이후 수정, 삭제, 유효성 검사는 필요에 따라 추가합니다. 이렇게 나누면 테스트가 길어지지 않고 실패 지점도 명확해집니다.

1. 핵심 사용자 시나리오 작성: 사용자가 실제로 어떤 순서로 움직이는지 먼저 적습니다.
2. 성공 케이스 자동화: 가장 정상적인 흐름을 먼저 테스트합니다.
3. 실패 케이스 추가: 빈 값, 권한 없음, 잘못된 입력을 점검합니다.
4. CI 연결: main 브랜치 병합 전 자동 실행되도록 설정합니다.

테스트 파일 이름도 검색하기 쉽게 정했습니다

작은 습관이지만 파일 이름이 중요했습니다. login.spec.ts, post-create.spec.ts, checkout-smoke.spec.ts처럼 기능과 목적을 함께 드러내면 실패 로그를 볼 때 바로 감이 옵니다. 반대로 test1.spec.ts처럼 만든 파일은 몇 주만 지나도 의미를 잃습니다.

또한 테스트 안의 describe와 test 제목도 한국어와 영어 중 팀이 읽기 쉬운 방식으로 통일했습니다. 중요한 것은 멋진 이름이 아니라 실패했을 때 바로 행동할 수 있는 이름입니다. 검색 가능한 제목은 디버깅 시간을 줄이는 작은 SEO 같은 역할을 합니다.

이것만은 꼭 기억하세요

처음 도입할 때의 체크리스트

Playwright는 강력하지만 처음부터 대규모 테스트 전략을 세우려고 하면 부담스럽습니다. 저는 깨지면 매출, 가입, 문의, 운영에 바로 영향을 주는 흐름부터 자동화하는 방식을 추천합니다. 블로그라면 글 작성과 검색, 쇼핑몰이라면 장바구니와 주문 전 단계, SaaS라면 로그인과 대시보드 접근이 먼저입니다.

또한 테스트가 실패했을 때 팀이 어떻게 처리할지도 정해야 합니다. 실패를 무시하면 테스트는 금방 신뢰를 잃습니다. 반대로 모든 실패를 배포 차단으로 걸면 작은 문구 변경에도 흐름이 멈출 수 있습니다. 핵심 테스트와 참고용 테스트를 분리하면 이 균형을 잡기 좋았습니다.

• 필수 자동화: 로그인, 핵심 페이지 접근, 데이터 생성과 저장
• 선택 자동화: 자주 바뀌는 문구, 마케팅 배너, 실험성 UI
• CI 설정: 실패 시 스크린샷과 trace를 저장하도록 구성
• 데이터 관리: 테스트 전후 상태가 일정하도록 초기화 전략 마련
• 리뷰 기준: 테스트 코드도 일반 코드처럼 PR에서 읽고 다듬기

자주 묻는 질문

Q. 초보 개발자도 바로 써도 될까요? 가능합니다. 다만 처음부터 복잡한 인증, 결제, 외부 API까지 자동화하려 하지 말고 로컬에서 보이는 단순한 버튼 클릭과 폼 제출부터 시작하는 편이 좋습니다. 작은 성공 경험이 쌓여야 테스트 코드가 부담이 아니라 개발 습관이 됩니다.

Q. Cypress 대신 Playwright를 써야 하나요? 무조건은 아닙니다. 이미 팀이 Cypress를 잘 쓰고 있다면 바꿀 이유가 약할 수 있습니다. 다만 여러 브라우저 확인, trace 기반 디버깅, 빠른 병렬 실행을 중요하게 본다면 Playwright가 꽤 매력적입니다.

Q. 테스트가 너무 느려지면 어떻게 하나요? 모든 흐름을 E2E로 넣지 말고 핵심 흐름만 남기는 것이 먼저입니다. 그다음 병렬 실행, 프로젝트 분리, 스모크 테스트와 전체 테스트 분리를 적용하면 됩니다. 실제 사용해 보니 좋은 테스트 자동화는 많이 작성하는 것이 아니라 깨지면 곤란한 부분을 정확히 지키는 것에 가까웠습니다.