재시도 3회로 통과한 테스트는 정말 통과한 걸까?

결론부터: 아니다. blanket retry는 실패를 지우는 게 아니라 실패 신호를 감추는 쪽으로 작동했고, 우리 파이프라인에서는 이게 실제 회귀를 통과시켜 롤백까지 이어졌다. 재시도는 진단 도구가 아니라 차단 해제 도구로만 써야 한다는 걸 다시 확인한 사건이었다.

  • flaky pass를 clean pass로 집계하면 회귀 감지 타이밍이 늦어진다 출처: contextqa.com
  • blanket retry는 확인된 특정 테스트에만 거는 selective retry보다 비용·신호 보존 양쪽에서 불리하다 출처: mill-build.org
  • 재시도 기반 CI 비용은 조직 규모에 따라 테스트 관련 컴퓨트의 20~60%까지 올라갈 수 있다 출처: buildpulse.io
  • 격리 강도는 재시도 전 "같은 상태 복원"이 아니라 "재시도 간 상태 독립성"을 기준으로 설계해야 한다 출처: source.android.com

시간순으로는 이렇다. 특정 통합 테스트가 며칠 전부터 간헐 실패를 보였고, 파이프라인은 이미 걸려 있던 rerunFailingTestsCount=3 설정 덕에 재시도 2회차에서 항상 통과했다. 빌드는 계속 초록불이었고, 배포도 정상 진행됐다. 그런데 배포 이후 특정 엔드포인트에서 실제 응답 오류가 늘었고, 원인을 추적하니 그 "통과한" 테스트가 실은 새로 들어간 코드 변경의 실제 회귀를 잡아내고 있었다. 재시도가 그 신호를 세 번 중 한 번의 성공으로 덮어버린 것이다.

네트워크 지연 때문인가?

기각. 실패 로그의 타임아웃 값을 다 확인했지만 외부 호출 지연 패턴과 실패 시점이 일치하지 않았다. 네트워크 원인이었다면 재시도 사이 지연이 늘어나야 하는데 그런 흔적이 없었다.

테스트 순서에 따른 상태 오염인가?

부분 기각. 순서를 바꿔 단독 실행해도 실패가 재현됐다. 즉 이전 테스트가 남긴 상태 문제가 아니라, 코드 자체의 조건 분기가 특정 입력에서만 실패하는 구조였다. 재시도가 이걸 "일시 오류"로 오분류한 셈이다.

러너 리소스 경쟁 때문인가?

기각. 8-core 러너로 옮겨 재현을 시도했지만 실패율은 그대로였다. 리소스 경쟁이라면 스펙을 올리면 완화돼야 하는데 변화가 없었다.

원인은 무엇이었나?

원인은 재시도 정책과 실패 분류 기준이 분리되지 않았던 데 있다. Databricks 계열 CI 문서가 정의하듯 "같은 코드 버전에서 재시도 후 통과하면 flaky"로만 판단했고, 그 판단에는 "왜 처음 실패했는지"가 빠져 있었다 출처: mill-build.org. 재시도 성공이 곧 무결점 처리로 이어지는 구조였기 때문에, 조건부 회귀가 flaky의 탈을 쓰고 통과했다.

재발 방지로 무엇을 바꿨나?

전체 스위트 blanket retry를 걷어내고, 과거 30일 flake history가 있는 테스트만 selective retry 대상에 올렸다. 재시도로 통과한 케이스는 별도 태그로 남겨 clean pass와 분리 집계하도록 했고, 재시도 횟수·회복률·추가된 CI 분을 같은 대시보드에 묶었다. 격리가 필요한 테스트는 Android Tradefed의 FULLY_ISOLATED/REBOOT_ISOLATED 구분처럼 상태 초기화 수준을 원인별로 다르게 걸었다 출처: source.android.com.

일반화하면 어떤 교훈이 남나?

재시도 정책은 실패율을 낮추는 장치가 아니라 실패 신호를 어디까지 보존할지 정하는 정책이다. 2026년 기준 여러 CI 운영 자료가 공통적으로 권고하는 방향도 같다: rerun 결과는 항상 표기하고, flaky pass를 clean pass로 섞지 말며, 격리 강도는 재현성 확보 비용과 진단력 사이에서 조정하라는 것이다 출처: contextqa.com. 이 원칙은 특정 테스트 러너나 스택에 묶여 있지 않다.

핵심 정리

  • blanket retry는 실패 신호를 지우고, selective retry는 신호를 보존하면서 비용을 줄인다.
  • flaky 판정은 "재시도 후 통과"만으로 내리면 조건부 회귀를 놓칠 수 있다.
  • 격리는 상태 복원이 아니라 상태 독립성 보장이 기준이어야 한다.
  • 재시도 횟수·회복률·추가 CI 분을 같은 지표 세트로 묶어야 트레이드오프가 보인다.
  • 재시도는 차단 해제용 도구이고, 원인 진단은 별도 트랙에서 계속 추적해야 한다.

더 알아보기

CI/CD 파이프라인 신뢰성: 캐시·테스트·배포의 균형 — 이 주제의 종합 가이드