콘텐츠로 이동

Playwright

단위 테스트가 함수 하나를 확인해 주는 건 좋은데, 사용자가 실제로 버튼을 누르고 폼을 채우고 페이지를 넘기는 흐름은 코드 안에서 재현되지 않아요. 웹빌더처럼 문서를 만들고 결제로 이어지는 제품은 그 '사용자 여정'이 한 번이라도 어긋나면 바로 장애가 되죠. Playwright는 진짜 브라우저를 직접 조작해서 사용자 흐름 그대로를 재현하는 E2E 테스트 도구예요. 클릭·입력·탭 이동을 코드로 짜서, 사람이 눈으로 확인하던 일을 밤마다 자동으로 돌려요.

한눈에 보면 이렇게 쓸 수 있어요. E2E 테스트 전략의 중심이 Playwright이고, 대안(또는 보완)으로는 테스트 층위에서 더 아래인 API 테스트·단위 테스트가 있어요. 규모가 크고 상호작용이 많은 화면일수록 Playwright의 가치가 커져요.

핵심 개념

  • 테스트 파일 구조 — 테스트를 test 코드로 작성하고, 그룹(describe)과 개별 케이스(test)로 구성합니다. 선택·입력·검증 같은 단계를 순서대로 기술해서 사용자 흐름을 재현해요.
  • Browser Context 자동화 — Chromium·Firefox·WebKit 등 실제 브라우저를 코드로 제어합니다. 화면에 보이는 요소를 클릭하거나 텍스트를 입력하는 것을 그대로 시뮬레이션해요.
  • 사용자 시나리오 중심 — '로그인 → 문서 작성 → 저장 → 결제'처럼 사용자가 하는 일 전체를 하나의 흐름으로 재현합니다. 단위 테스트가 함수의 안을 보는 것과 달리, E2E는 사용자가 만지는 바깥을 봐요.
  • 자동 대기(Auto-wait) — 요소가 준비될 때까지 기다렸다가 동작하는데, 이 덕분에 '화면이 아직 안 떴는데 클릭해서 실패하는' 타이밍 문제를 코드가 대신 다뤄줘요.
  • 회귀 감지의 주축 — 이전에 멀쩡했던 흐름이 배포 후 깨졌는지를 반복 실행으로 잡아냅니다. 밤마다 돌리는 회귀 테스트의 표준 도구예요.
  • 테스트 층위에서의 위치 — Unit(함수) → Integration(모듈 협력) → E2E(사용자 시나리오)로 범위가 커지는 테스트 피라미드의 가장 바깥층이에요. 범위가 넓은 만큼 속도는 가장 느리지만, 사용자가 실제로 겪는 문제를 가장 정확히 잡아요.

사용 사례 / 실제 적용

웹빌더에서 처음 자동화를 시작하는 지점은 '가장 자주 깨지고 눈으로만 확인하던 문서 보존'이에요. HWP·PDF를 웹으로 변환하는 흐름을 Playwright로 재현해서, 표의 경계선이 어긋나지 않았는지를 반복 검사하죠. 도구의 숫자가 곧 품질 기준이 되기 시작하면 나머지 흐름은 그 위에 붙이면 돼요.

프론트엔드 품질의 일부로도 쓰여요. 캔버스에서 노드를 옮기거나 웹빌더에서 요소 순서를 바꾸는 인터랙션이 깨졌는지 Playwright가 밤마다 확인합니다. 자세한 프론트엔드 조합은 프론트엔드 페이지에서, 지표의 우선순위는 테스트·품질 허브에서 이어져요.

처음 접할 때 놓치기 쉬운 점은 선택자 짓기예요. 화면 텍스트나 역할(role)처럼 사용자가 보는 기준으로 요소를 고르면, 클래스명이 바뀌어도 테스트가 덜 깨집니다. 내부 구현에 붙은 셀렉터는 리팩터링 때마다 함께 고쳐야 해서 유지비가 커져요.

처음 자동화를 도입할 때 이 점을 기억하면 좋아요. 앞서 말한 선택자와 별개로, 실제로 만져볼 몇 가지가 있어요.

  • 신뢰할 수 있는 선택자 — 텍스트·role처럼 사용자가 보는 기준으로 고르면 리팩터링에 덜 깨집니다. 클래스명에 의존하면 유지비가 커져요.
  • 테스트 격리 — 각 테스트가 독립된 상태에서 시작하도록 준비하면, 순서에 따라 결과가 달라지는 문제를 피할 수 있어요.
  • 회귀 중심으로 시작 — 제일 자주 깨지고 눈으로만 확인하던 흐름부터 재현하는 게 효율적이에요. 많고 얕은 것보다 적고 중요한 것부터 안정화하죠.
  • 속도와 범위의 균형 — E2E는 범위가 넓은 만큼 느려요. 전부 E2E로 만들기보다, 단위·API 테스트로 아래를 채우고 E2E는 핵심 여정에 씁니다.

심화 챕터

Playwright를 실제로 다루며 필요한 세부 동작은 아래 챕터에서 공식 문서를 기준으로 더 깊게 다뤄요.

  • 셀렉터 — 요소를 어떤 기준으로 고르고, 유지보수 잘 되는 셀렉터 고르기
  • 자동 대기 — actionability 검사와 타이밍 문제 해결
  • 에뮬레이션 — 모바일·로케일·네트워크 조건 재현

더 알아보기