Playwright냐 Cypress냐…같은 E2E 테스트도 실행 시간은 두 배 갈렸다

Angular 앱 E2E 비교 연구에서 같은 타자 학습 시나리오의 Chrome 평균 실행 시간은 Playwright 16.03초, Cypress 52.47초로 두 배 이상 벌어졌다. 이 차이는 속도를 우선하는 팀에 Playwright를 검토할 근거지만, 한 앱의 단일 시나리오를 모든 프로젝트의 성능 차이로 확대할 수는 없다.

선택을 가르는 것은 브라우저별 실행 범위, 테스트 파일을 나누는 방식, CI 머신과 Cloud 기록량이다. Playwright는 파일 단위 병렬 실행을 기본으로 제공하고, Cypress는 브라우저별 CI 그룹과 Cloud 병렬화를 구성할 수 있다. 로컬에서 실패를 추적하는 경험까지 포함하면 어느 도구가 유리한지는 실제 테스트 묶음의 구조에 따라 바뀐다.

두 배 이상 벌어진 측정의 조건

실험 대상은 속독·타자·기억력 훈련 기능을 갖춘 Angular 웹 앱이었다. 사용자 등록과 타자 학습, 숫자 정렬, 관리자 문제 처리 등 서로 다른 흐름을 양쪽 도구로 구현했다. 앱과 데이터베이스를 로컬에서 실행하고 테스트도 화면 없이 진행했으므로, 수치는 원격 서비스 지연이나 CI 대기 시간까지 더한 전체 빌드 시간이 아니다.

가장 눈에 띄는 타자 학습 시나리오에서 브라우저별 평균 실행 시간은 다음과 같았다. 앞쪽이 Playwright, 뒤쪽이 Cypress이며 단위는 초다. 각 시나리오는 브라우저마다 반복 실행해 평균을 냈다.

• Chrome: 16.03초 / 52.47초
• Firefox: 16.20초 / 33.74초
• WebKit: 15.93초 / 39.31초

Chrome에서는 Cypress가 Playwright보다 세 배 넘게 걸렸고, Firefox와 WebKit에서도 두 배를 넘었다. 그러나 격차의 크기는 브라우저마다 달랐다. 한 브라우저의 시간만으로 여러 브라우저를 함께 돌리는 CI 완료 시간을 계산하면, 각 브라우저에 배정한 테스트 파일과 머신 수가 빠진다.

같은 실험에서 Playwright의 RAM 사용량은 모든 시나리오에서 더 낮았고, CPU 사용량은 약간 높게 나타났다. 메모리가 작은 CI 머신이라면 RAM 수치가 중요하지만, 워커를 많이 늘릴 때는 CPU와 브라우저 프로세스의 경쟁도 살펴야 한다. 이 결과는 로컬 Windows 장비와 해당 앱의 테스트 코드가 만든 조합이며, 다른 서비스의 응답 지연이나 테스트 데이터 준비 비용까지 대표하지 않는다.

브라우저 범위는 이름보다 실행 조건이 중요하다

Playwright는 Chromium, Firefox, WebKit을 대상으로 실행할 수 있고 Cypress도 Chrome 계열, Firefox, WebKit을 지원한다. 다만 Cypress의 브라우저 실행 문서에서 WebKit은 실험 기능으로 분류되며, 별도 설정과 playwright-webkit 설치가 필요하다. Safari와 동일한 브라우저를 Windows CI에서 그대로 띄운다는 뜻도 아니므로, Apple 기기에서의 동작이 핵심인 서비스는 목표 환경을 분명히 정해야 한다.

또한 Cypress는 실행할 브라우저가 로컬 또는 CI 환경에 준비돼 있어야 한다. Playwright는 지원 브라우저 바이너리를 명령으로 설치하는 방식이다. 이 차이는 새 CI 이미지를 구성하거나 버전을 올릴 때 필요한 작업을 바꾼다. 어느 쪽이든 브라우저 이름을 설정에 적는 것만으로 배포 환경의 설치와 종속성이 자동으로 해결되지는 않는다.

모든 시나리오를 모든 브라우저에 복제하면 탐지 범위는 넓어지지만 빌드 시간과 실행량도 늘어난다. 로그인이나 결제처럼 브라우저 차이가 서비스 이용에 직접 영향을 주는 흐름은 폭넓게 확인하고, 나머지는 주력 브라우저에 집중하는 식의 분배가 가능하다. 이는 팀이 어떤 실패를 배포 전에 잡으려는지에 따른 테스트 설계다.

병렬 실행의 단위가 다르다

Playwright 병렬 실행 문서에 따르면 테스트 파일은 기본적으로 여러 워커에서 동시에 실행되고, 같은 파일 안의 테스트는 기본적으로 순서대로 실행된다. 워커는 별도 프로세스이며 BrowserContext가 분리돼 쿠키와 브라우저 저장 상태가 격리된다. 팀은 워커 수를 제한하거나 여러 CI 머신에 테스트 묶음을 샤딩할 수 있다.

파일이 잘게 나뉘어 있으면 한 머신 안에서도 동시 처리할 일이 많아진다. 반대로 오래 걸리는 테스트를 큰 파일 하나에 몰아두면 기본 설정의 파일 병렬화만으로는 그 파일 내부의 대기 시간을 줄이기 어렵다. 워커를 늘려도 브라우저와 앱 서버가 같은 CPU와 메모리를 쓰면 이득이 줄어든다. 브라우저 상태가 분리되더라도 공유 데이터베이스의 같은 사용자나 레코드를 수정하는 테스트는 서로 충돌할 수 있다.

Cypress의 브라우저별 CI 구성 예시는 Chrome 그룹에 머신 네 대를 배정해 전체 테스트를 돌리고, Firefox 그룹에는 머신 두 대로 일부 핵심 파일만 실행한다. 각 그룹 안에서 Cypress Cloud가 스펙 파일을 머신에 나누는 방식이다. 브라우저별 테스트 범위와 머신 수를 따로 조정할 수 있지만, 그만큼 CI 자원 사용량과 Cloud에 기록되는 결과 수도 함께 달라진다.

따라서 단일 테스트의 실행 시간과 전체 파이프라인이 끝나는 시간은 다른 지표다. 후자에는 파일 분할, 시작 준비, 브라우저 조합, 머신 배정, 가장 늦게 끝나는 그룹이 모두 영향을 준다. 앞의 Angular 실험은 도구별 개별 실행 차이를 보여주지만, 특정 CI 구성에서의 병렬화 효과를 직접 측정한 것은 아니다.

무료 CI와 Cypress Cloud의 비용 경계

Cypress App은 무료이며 Cypress Cloud 요금표의 무료 Starter에도 병렬화가 포함된다. 다만 Cloud에 기록할 수 있는 테스트 결과는 월 500개다. 이 한도는 스펙 파일 수나 빌드 수가 아니라, --record로 전송된 개별 it() 테스트의 실행 결과를 기준으로 잡힌다.

예를 들어 한 빌드에서 테스트 100개를 기록하고 한 달에 빌드 10회를 실행한다고 가정하면 결과는 1000개다. 무료 한도보다 많아지므로 Cloud의 기록과 자동 분배를 계속 같은 규모로 쓰려면 요금제를 검토해야 한다. 재시도한 테스트는 결과 하나로 집계되고, 로컬 개발 중 Cloud에 기록하지 않은 실행은 이 수치에 들어가지 않는다.

Cloud를 사용하지 않아도 CI 설정에서 스펙 파일을 작업별로 직접 나누어 여러 머신에서 실행할 수 있다. 이때는 Cloud의 자동 분배와 기록 기능을 사용하지 않는 대신, 파일 배분과 결과 취합을 팀이 관리한다. Playwright의 기본 워커 실행과 머신별 샤딩에도 별도 Cloud 구독은 필요하지 않지만, 어느 방식이든 추가 CI 머신에는 제공자의 실행 요금이 붙을 수 있다.

비용 비교의 단위는 도구 가격 하나가 아니라 월간 기록 결과량과 CI 머신 시간이다. 브라우저를 추가하면 같은 테스트가 여러 번 실행되어 Cloud 사용량이 커질 수 있고, 파일을 지나치게 크게 묶으면 머신을 늘려도 대기 시간이 남는다. 무료 범위에 들어오는 작은 테스트 묶음과 매 배포마다 여러 브라우저를 돌리는 큰 묶음은 같은 요금표를 보더라도 결론이 달라진다.

실패를 고칠 때 남는 정보와 코드 구조

Playwright는 Trace Viewer에 동작 순서, 요소 선택자와 DOM 상태를 남겨 실패 순간을 되짚을 수 있다. CI에서는 재시도 시 추적 기록을 남기거나 실패한 실행의 기록을 보존하도록 설정할 수 있다. 로컬에서 재현되지 않는 오류라면 해당 실행의 상태가 남아 있는지가 원인 분석 시간을 좌우한다.

Cypress는 로컬 실행에서 명령 로그를 따라가며 앱의 반응을 살피고, 필요한 지점에서 실행을 멈춰 DOM과 네트워크 상태를 확인할 수 있다. 개발 중 선택자나 입력 순서가 어긋난 이유를 찾아가는 작업에는 이런 즉시성이 도움이 된다. CI에서만 발생하는 실패는 로컬 화면의 편의와 별개로, Cloud 기록이나 스크린샷·동영상 등 어떤 증거를 저장했는지가 중요하다.

유지보수성도 실행 시간처럼 특정 코드의 맥락을 봐야 한다. Angular 실험에서는 대부분의 시나리오에서 Playwright 테스트 파일의 코드 줄 수가 적었지만, 일반 사용자와 관리자가 함께 등장하는 흐름에서는 브라우저 컨텍스트가 추가돼 예외가 생겼다. 짧은 코드가 항상 손쉬운 변경을 뜻하지는 않는다. 테스트 데이터 초기화, 공유 계정의 분리, 실패 기록을 읽는 팀의 익숙함이 장기 유지 비용에 영향을 준다.

도입 판단은 테스트 묶음의 형태에서 나온다

브라우저별 검증을 자주 실행하고, 파일을 나눠 한 CI 머신에서 병렬 처리하려는 팀에는 Playwright의 기본 구조가 잘 맞는다. Angular 실험에서 나온 실행 시간과 RAM 차이도 같은 방향의 근거다. 특히 공유 상태를 통제할 수 있고 CI 실패 기록을 보관하는 팀이라면 병렬화와 추적 기능을 함께 활용할 여지가 크다.

Cypress를 이미 안정적으로 쓰는 팀에는 로컬 명령 로그와 기존 테스트 코드의 가치가 있다. 무료 Cloud의 기록량 안에서 충분히 운영하거나 브라우저 그룹을 직접 설계할 수 있다면, 한 시나리오의 속도 차이만으로 전환 비용을 정당화하기 어렵다. 실제 결정을 위해서는 목표 브라우저에서 핵심 흐름을 같은 범위로 실행하고, 월간 기록 결과량과 CI 완료 시간, 실패를 고치는 데 필요한 기록을 함께 비교하는 편이 정확하다.

함께 읽기:

• UiPath 테스트가 수동 절차를 읽고 실행한다…최종 판단은 사람이 맡는다
• 유튜브 A/B 테스트는 클릭률보다 시청시간을 본다
• pgvector와 Pinecone, 480만 문서에서 비용은 3.4배 갈렸다