파이프라인 운영과 문제 해결

5. 자주 하는 실수 (Tip)

❌ 실수 1. 원인 조사 없이 재시도 횟수만 늘림

재시도 3번을 5번으로 늘리는 식으로는 플레이키의 원인이 사라지지 않습니다. 재시도가 늘어난다는 것 자체를 원인 조사 신호로 삼아야 합니다.

❌ 실수 2. 로그를 위에서부터 끝까지 다 읽음

수백 줄을 눈으로 훑으면 시간이 오래 걸리고 첫 에러를 놓치기 쉽습니다. grep -n -m1 로 첫 에러 줄부터 찾는 습관이 필요합니다.

❌ 실수 3. 로컬 재현 없이 추측으로 수정 커밋을 반복함

"이러면 되겠지" 로 커밋하고 파이프라인 결과만 기다리면 확인 주기가 깁니다. 먼저 로컬에서 재현하고 수정 후 통과를 확인한 다음 커밋합니다.

❌ 실수 4. .env 파일을 통째로 커밋함

설정 파일 전체를 커밋하면 그 안의 키까지 같이 올라갑니다. .gitignore 에 등록하고 예시 파일(.env.example)만 커밋합니다.

❌ 실수 5. pre-commit 훅 없이 리뷰에만 의존함

리뷰어도 사람이라 긴 diff 속 시크릿 한 줄을 놓칠 수 있습니다. 훅으로 기계적인 1차 검사를 걸어두면 실수가 줄어듭니다.

❌ 실수 6. 유출된 키를 파일에서만 지우고 폐기하지 않음

파일을 지우고 커밋해도 과거 히스토리에는 키가 그대로 남아 있습니다. 발급 서비스에서 즉시 폐기하고 새 키로 교체하는 것이 우선입니다.

❌ 실수 7. self-hosted runner 등록 토큰을 스크립트에 하드코딩함

토큰이 저장소에 커밋되면 그 자체가 또 다른 시크릿 유출입니다. 등록은 1회성 명령으로만 실행하고 토큰은 저장소에 남기지 않습니다.

❌ 실수 8. 성공할 때도 알림을 보냄

매번 성공 알림까지 오면 채널을 꺼버리게 되고 정작 실패 알림도 놓칩니다. if: failure() 로 실패했을 때만 보냅니다.

❌ 실수 9. 캐시 키를 매번 바꿔 캐시가 항상 미스됨

빌드 시각이나 커밋 해시를 캐시 키에 넣으면 매번 새 키가 되어 캐시 효과가 없습니다. 의존성 파일(pom.xml 등)의 해시처럼 내용이 바뀔 때만 변하는 값을 키로 씁니다.

❌ 실수 10. RUNBOOK 없이 한 사람만 대응 절차를 알고 있음

담당자가 휴가거나 퇴사하면 같은 실패에도 대응이 늦어집니다. 대응 순서를 문서 한 곳에 남겨 누구나 볼 수 있게 합니다.