릴리스 후보 테스트 컷라인 설계
릴리스 직전이 되면 팀은 늘 같은 압박을 받습니다. “더 확인할까, 아니면 지금 내보낼까?” 이때 모든 테스트를 무조건 다 돌리는 방식은 느리고, 반대로 너무 적게 보면 위험합니다. 필요한 것은 테스트의 양이 아니라 출고 판단 기준, 즉 컷라인입니다.
컷라인은 테스트 목록이 아니라 위험 기준이다
좋은 릴리스 컷라인은 “무엇을 실행할지”보다 “어떤 위험을 반드시 막을지”를 먼저 정의합니다.
예를 들면:
- 결제 흐름 회귀
- 인증 실패
- 데이터 손실 가능성
- 주요 브라우저/디바이스 깨짐
이런 위험이 정의되면, 어떤 테스트가 컷라인에 포함되어야 하는지도 자연스럽게 정리됩니다.
모든 테스트를 같은 급으로 취급하면 안 된다
보통 릴리스 후보 테스트는 세 층으로 나누는 것이 좋습니다.
- 반드시 통과해야 하는 빠른 신뢰 세트
- 주요 사용자 여정 검증 세트
- 참고용 확장 검증 세트
첫 번째 세트는 컷라인 그 자체이고, 두 번째는 출고 판단 보강, 세 번째는 배포 후 추적용으로 보는 편이 현실적입니다.
플래키 테스트는 컷라인을 오염시킨다
컷라인에 신뢰할 수 없는 테스트가 들어가면 팀은 실패를 무시하는 습관을 갖게 됩니다. 그 순간 컷라인은 제 역할을 잃습니다.
그래서 컷라인 후보 테스트는:
- 재현성이 높고
- 실패 원인이 명확하며
- 실행 시간이 예측 가능해야 합니다
결과만이 아니라 미실행 위험도 남겨야 한다
시간 부족으로 일부 테스트를 생략했다면, 그것도 릴리스 판단 정보입니다. “통과한 것”만 적지 말고 “이번 배치에서 보지 못한 위험”도 남겨야 합니다.
결론
릴리스 후보 테스트 컷라인은 품질팀 문서가 아니라, 출고 순간에 무엇을 믿고 무엇을 아직 모르는지 명확히 하는 의사결정 장치입니다. 강한 팀은 테스트를 많이 돌리는 팀이 아니라, 컷라인을 분명히 아는 팀입니다.
Continue Reading
다음으로 읽기 좋은 글
플레이키 테스트 신호 예산 관리
불안정한 테스트를 단순 재시도로 덮지 않고 신뢰도, 소유권, 격리 기준으로 관리하는 방법을 정리합니다.
🧪 TestFlaky Test 분류와 대응 플레이북
Flaky test를 분류하고 격리하고 근본 원인을 해결해 CI 신뢰도를 지키는 실전 가이드입니다.
📱 Mobile모바일 Crash Budget 운영법
모바일 안정성은 단순히 크래시를 줄이는 것이 아니라, 어느 수준까지 허용하고 언제 출하를 멈출지 결정하는 운영 문제입니다.
🚀 DevOps배포 증거 게이트 설계
테스트 통과 여부를 넘어 변경 근거, 검증 결과, 롤백 준비 상태를 배포 승인 조건으로 다루는 방법을 정리합니다.
다음 탐색