Flaky Test 분류와 대응 플레이북

Flaky test는 단순히 짜증나는 문제가 아닙니다. 팀이 실패를 더 이상 믿지 않게 되면 CI 파이프라인 전체가 프로덕션을 지키는 능력을 잃습니다.

먼저 실패 유형을 분류해야 한다

모든 flaky test가 같은 원인은 아닙니다. 보통 다음과 같이 나눌 수 있습니다.

• timing과 async race condition
• 공유 테스트 데이터 오염
• 환경 불안정성
• 약한 selector나 brittle assertion

분류가 중요한 이유는 해결 방식이 서로 다르기 때문입니다.

고치기 전에 triage부터 하자

Flaky test가 나타나면 먼저 다음을 물어야 합니다.

• 얼마나 자주 실패하는가
• 배포를 실제로 막고 있는가
• 제품 동작 자체도 불안정한가
• 특정 환경이나 브라우저에만 묶여 있는가

이렇게 해야 낮은 가치의 증상에 하루를 쓰면서 더 위험한 flaky 경로를 놓치지 않습니다.

먼저 blast radius를 줄여야 한다

신호는 약하고 소음은 큰 테스트라면 빠르게 격리해야 합니다.

• quarantine하되 가시성은 유지
• 일시적으로 release gate 비중 낮추기
• 담당자와 해결 기한 지정

가장 나쁜 패턴은 아무도 책임지지 않은 채 모두가 rerun 버튼만 누르는 상황입니다.

retry 횟수가 아니라 원인을 고쳐야 한다

Retry는 진단용으로는 쓸 수 있어도 영구 해결책이 되어서는 안 됩니다. 진짜 해결은 대개 다음에서 나옵니다.

• 결정적인 테스트 데이터
• 명시적 readiness check
• 더 좁고 의미 있는 assertion
• 테스트 간 숨은 공유 상태 제거

flaky는 운영 지표로 봐야 한다

• 가장 자주 실패하는 테스트
• rerun 빈도
• quarantine 유지 기간
• retry 때문에 낭비되는 빌드 시간

신뢰할 수 있는 파이프라인은 우연히 생기지 않습니다. 테스트 신뢰를 하나의 제품처럼 관리할 때 만들어집니다.

Continue Reading

다음으로 읽기 좋은 글

🧪 Test

플레이키 테스트 신호 예산 관리

불안정한 테스트를 단순 재시도로 덮지 않고 신뢰도, 소유권, 격리 기준으로 관리하는 방법을 정리합니다.

🧪 Test

릴리스 후보 테스트 컷라인 설계

모든 테스트를 다 돌리는 것과 안전하게 배포하는 것은 다릅니다. 릴리스 후보에서 어떤 테스트를 통과 기준으로 삼아야 할지 정리합니다.

📱 Mobile

모바일 Crash Budget 운영법

모바일 안정성은 단순히 크래시를 줄이는 것이 아니라, 어느 수준까지 허용하고 언제 출하를 멈출지 결정하는 운영 문제입니다.

🤖 AI / LLMOps

AI 평가 루브릭 실전 설계

프로덕션 AI 기능을 위해 품질 기준, 실패 유형, 릴리스 게이트를 어떻게 정의할지 정리한 실전 가이드입니다.