용어집 · 테스트 기초
플래키 테스트(Flaky Test)
영어: Flaky test
다른 이름: 플레이키 테스트, 불안정한 테스트, 간헐적 실패 테스트, flakiness
정의
코드 변경이 없는데도 같은 코드에서 통과와 실패를 오가는 테스트로, 주로 타이밍, 공유 상태, 테스트 순서, 불안정한 환경 때문에 발생합니다.
플래키 테스트(Flaky test)는 같은 커밋에서 다른 결과를 냅니다. 바뀌지 않은 코드로 열 번 실행하면 몇 번은 통과하고 몇 번은 실패합니다. 핵심은 제품에는 아무 변화가 없다는 점입니다. 결과의 차이는 테스트 자체, 테스트 데이터, 또는 환경에서 옵니다.
왜 중요한가
플래키 테스트가 몇 개만 있어도 팀은 초록색이 될 때까지 실패를 재실행하는 습관이 듭니다. 그 습관이 자리 잡으면 진짜 회귀도 재실행으로 묻혀 버립니다. 재시도가 실행 시간을 곱절로 늘리니 파이프라인도 느려지고, 커버리지 부족보다 더 빠르게 자동화에 대한 신뢰를 무너뜨립니다.
흔한 원인
- 타이밍. 페이지나 API가 준비되기 전에 테스트가 동작합니다. 고정
sleep, 재시도 없이 값을 한 번만 읽는 검사, 아직 진행 중인 애니메이션 등이 원인입니다. - 공유 상태. 두 테스트가 같은 사용자, 장바구니, 데이터베이스 행에 씁니다. 단독으로는 통과하지만 병렬로 실행하거나 순서가 바뀌면 실패합니다.
- 테스트 순서 의존성. 앞선 테스트가 만든 데이터에 의존합니다.
- 환경. 느리거나 공유된 테스트 환경, 서드파티 서비스, 요청 한도(rate limit), 시간대, 시계 변경.
- 비결정적 데이터. 시드를 기록하지 않은 랜덤 입력, “현재 시각”에 대한 어설션.
대처 방법
- 재현합니다. 해당 테스트 하나를 반복 실행하고(Playwright:
npx playwright test my.spec.ts --repeat-each=20), 실패한 실행의 트레이스나 비디오를 수집합니다. - 재시도를 추가하지 말고 원인을 찾습니다. sleep을 조건 기반 대기로 바꾸세요. Playwright의 웹 퍼스트 어설션이나 Selenium의
WebDriverWait같은 방식입니다. 각 테스트가 자기 데이터를 갖게 하세요. - 오늘 고칠 수 없다면 격리(quarantine)합니다. 차단 게이트에서 빼서 담당자가 있는 별도의 비차단 잡으로 옮기면 메인 신호의 신뢰성이 유지됩니다.
- 플래키 비율을 시간에 따라 추적합니다. 재시도로 통과한 테스트는 리포트에 드러나지 않으면 문제를 숨깁니다.
CI에서 재시도(playwright.config.ts의 retries: 2)는 합리적인 안전망이지만, 재시도에서만 통과하는 테스트는 여전히 플래키합니다. Playwright는 이런 테스트를 “flaky”로 보고하므로 확인할 수 있습니다.