CI 장기 실패 — 감지·분류·대응 전략
개요
CI가 며칠씩 실패 상태로 방치되면 빠르게 원인 컨텍스트를 잃는다. "고쳐야 한다"는 인식만으론 부족하고, 실패의 종류를 먼저 분류(triage) 한 뒤 유형별 대응 전략을 정해두면 방치 기간을 줄일 수 있다.
실패 유형 분류
| 유형 | 예시 | 권장 대응 |
|---|---|---|
| 배포 실패 (인프라) | concurrency 충돌, NAS 연결 실패 | 워크플로우 로직 수정 |
| 테스트 실패 (코드) | 유닛 테스트·린트 오류 | 코드 또는 테스트 업데이트 |
| 방치형 실패 | 더 이상 유지보수 안 하는 레포 | 워크플로우 비활성화 |
| 외부 의존성 실패 | Docker Hub rate limit, 외부 API | 재시도·미러 |
장기 방치 방지 체크리스트
D+1 → 실패 확인, 로그 열람 (5분)
D+3 → 원인 파악 및 유형 분류
D+7 → 수정 또는 워크플로우 비활성화 결정
D+14 → 미해결 시 이슈 생성 또는 레포 아카이브 검토
방치형 실패: 워크플로우 비활성화
유지보수 중단된 레포는 실패를 계속 두는 것보다 명시적으로 비활성화하는 편이 깔끔하다.
# .github/workflows/deploy.yml
# 비활성화: 레포 유지보수 중단
on: []
# 기존 트리거 (주석 보존)
# on:
# push:
# branches: [main]
핵심 교훈
- CI 실패는 방치할수록 컨텍스트를 잃는다. 3일 안에 triage가 원칙.
- 사용하지 않는 레포의 CI는 빠르게 비활성화하는 게 기술 부채 감소에 유리.
- concurrency group 같은 워크플로우 설정은 CI 종류(테스트 vs 배포)에 따라 전략이 다르다.