속도가 느릴 때
- 증상
- 대기 시간이 길어 PR 피드백이 늦다.
- 설정
- Jest 병렬 실행, npm 캐시, 변경분 테스트를 검토한다.
- 주의
- 병렬화 후에도 테스트 격리가 깨지지 않아야 한다.
Optimization Checklist
CI 최적화는 빠르게 끝내는 것보다 신뢰도를 잃지 않는 선택이다
테스트 시간, 재현성, 비밀 관리, 실패 신호를 함께 조정해야 파이프라인이 빨라져도 믿을 수 있습니다.
E2E가 불안정할 때
- 증상
- 로컬은 통과하지만 CI에서 간헐 실패한다.
- 설정
- SQLite, Docker Compose, Testcontainers로 실행 환경을 고정한다.
- 주의
- 테스트마다 데이터 초기화 기준을 명확히 둔다.
환경 값이 필요할 때
- 증상
- API 키, DB URL이 테스트 실행에 필요하다.
- 설정
- GitHub Secrets와 테스트 전용 값을 분리한다.
- 주의
- 로그와 아티팩트에 비밀 값이 찍히지 않게 한다.
실패 대응이 늦을 때
- 증상
- 실패 원인과 담당자가 늦게 드러난다.
- 설정
- Slack 알림, coverage artifact, 테스트 리포트를 묶는다.
- 주의
- 알림은 실패 위치와 다음 행동을 포함해야 한다.
코드 품질 기준을 자동화할 때
- 증상
- 테스트는 통과하지만 스타일, 정적 분석, 취약점 기준이 사람 손에 남는다.
- 설정
- ESLint, Prettier, SonarQube 같은 품질 도구를 테스트 앞뒤의 명시적 단계로 둔다.
- 주의
- 품질 단계 실패도 테스트 실패와 같은 병합 차단 신호로 취급한다.
먼저 반복 시간을 줄인다
동시에 실행 환경을 고정한다
마지막에 실패 증거와 알림을 정돈한다