Playwright E2E 플래키 테스트를 격리하고 배포 리듬을 복구하는 실무 플레이북

1. 문제 정의: 테스트가 가끔 깨지는 게 아니라 배포 의사결정이 망가지는 상황

플래키 테스트는 보통 “가끔 실패하는 테스트”로 설명되지만, 운영 관점에서는 배포 판단 체계를 망가뜨리는 문제에 가깝습니다. 지난주 저희 팀은 로그인과 결제 경로를 묶은 Playwright 스위트에서 하루 평균 3~4건의 랜덤 실패가 났고, 실패 직후 rerun을 누르면 대부분 통과했습니다. 겉으로는 큰 문제가 없어 보였지만 실제로는 릴리스 승인 시간이 계속 밀렸고, QA와 개발자가 같은 로그를 서로 다르게 해석하면서 야간 배포 결정이 늦어졌습니다. 특히 금요일 저녁에는 실제 회귀 버그 하나가 플래키 잡음에 섞여 발견이 40분 지연됐습니다. 이 경험 이후 팀에서 합의한 첫 원칙은 단순했습니다. 플래키는 테스트 품질 문제가 아니라 배포 신뢰도 문제로 다룬다. 그래서 개인 감으로 rerun하는 습관을 금지하고, 실패를 “즉시 복구”보다 “재현 가능한 상태로 고정”하는 절차부터 만들었습니다.

2. 판단 기준: 실패 횟수보다 실패 형태를 먼저 고정한다

효과가 있었던 기준은 세 가지였습니다. 첫째, 케이스 단위 통과율보다 실패 시그니처 수를 본다. 같은 테스트가 10번 깨져도 스택트레이스가 하나면 원인 하나일 가능성이 높지만, 3번 깨졌는데 시그니처가 3종이면 환경 변동을 의심해야 합니다. 둘째, 테스트 타임아웃을 전역값으로만 두지 않고 액션 타임아웃, 내비게이션 타임아웃, 기대(assert) 타임아웃을 분리해 기록합니다. 저희는 한동안 전역 30초만 쓰다가 네트워크 지연인지 렌더 지연인지 구분을 못 해 시간을 버렸습니다. 셋째, 실패한 실행의 아티팩트(video, trace, console)를 무조건 남기되, 보존 기간을 짧게 가져갑니다. 팀이 실제로 보는 건 최근 48시간 데이터라 장기 보관보다 빠른 비교가 더 중요했습니다. 이 기준을 적용하고 나서 “다시 돌리면 되겠지”라는 반응이 줄었고, 원인 논의가 감정이 아니라 동일한 증거 위에서 진행됐습니다.

3. 실행 절차: 격리 라벨, 재현 시드, 환경 핀 고정으로 복구 속도를 만든다

실행은 4단계로 고정했습니다. 1단계는 격리입니다. 플래키 의심 케이스에 @quarantine 태그를 붙여 메인 게이트에서 분리하고, 릴리스 차단 대상과 관찰 대상을 즉시 나눕니다. 2단계는 재현입니다. CI에서 실패한 커밋을 동일 브라우저 버전, 동일 해상도, 동일 타임존으로 5회 재실행해 실패 확률과 패턴을 수집합니다. 이때 브라우저 자동 업데이트를 열어두면 결과가 떠서, playwright 버전과 OS 이미지를 함께 핀 고정하는 게 중요했습니다. 3단계는 수정입니다. 셀렉터 불안정, 비동기 대기 누락, 테스트 데이터 경합 중 어디에 해당하는지 분류한 뒤 한 번에 하나만 바꿉니다. 저희가 자주 실수한 부분은 waitForTimeout 임시 패치를 남겨두는 것이었는데, 이건 일시적으로 통과율은 올려도 다음 주에 더 큰 지연을 만들었습니다. 4단계는 복귀 판단입니다. 같은 커밋 기준 10회 실행에서 실패 0건, 평균 실행시간 변동폭 15% 이내, 동일 시그니처 재발 0건을 만족할 때만 격리 해제했습니다.

4. 운영 체크리스트: 복구 이후 재발을 막는 팀 규칙까지 문서화한다

복구가 끝난 뒤가 더 중요합니다. 저희 팀은 매주 수요일 20분 동안 플래키 리뷰를 열고, 새로 추가된 E2E 케이스에 대해 “네트워크 의존 외부 API를 직접 호출하는가”, “랜덤 데이터 충돌 가능성이 있는가”, “테스트 전용 계정 상태를 초기화하는가” 세 항목을 반드시 확인합니다. 또 PR 템플릿에 “실패 시 어떤 아티팩트를 남기는지”를 한 줄로 쓰게 했더니, 코드 리뷰에서 불안정 포인트를 훨씬 빨리 잡았습니다. 장애 대응 측면에서는 롤백 규칙도 숫자로 고정했습니다. 릴리스 직전 30분 동안 플래키 비율이 2%를 넘으면 기능 배포를 멈추고 테스트 안정화만 처리합니다. 이 규칙이 생긴 뒤에는 일정 압박 때문에 위험한 배포를 강행하는 일이 줄었습니다. 정리하면, Playwright 플래키 대응의 핵심은 테스트 한두 개를 고치는 기술이 아니라 팀의 판단 기준을 운영 규칙으로 고정하는 것입니다. 그래야 배포 리듬이 돌아오고, 진짜 회귀 버그를 제때 잡을 수 있습니다.