배포 실패 시에만 알림 전송하도록 배포 스크립트 개선

배포 스크립트의 알림 전략을 손봤다. 정상완료일 땐 입을 다물고, 문제가 터졌을 때만 신호를 보내도록 변경한 것이다.

배포 알림의 신호대잡음 비율

자동화된 배포 시스템을 운영하다 보면 자연스럽게 생기는 문제가 하나 있다. 매번 성공할 때마다 "배포 완료됨" 알림이 날아온다는 것이다. 하루에 여러 번 배포되는 환경이라면 Slack이나 모니터링 채널이 녹색 체크 마크로 도배된다. 처음엔 든든하게 느껴지지만, 시간이 지나면 알림은 배경음이 되고, 팀원들은 점점 그걸 무시하게 된다.

이게 위험한 이유는 진짜 중요한 신호—배포 실패, 타임아웃, 권한 에러—까지 같은 빈도의 노이즈 속에 파묻힌다는 것이다. 결과적으로 운영 팀이 반응해야 할 문제를 놓치는 상황이 생기곤 한다. 심리학에선 이를 "알림 피로도(notification fatigue)"라고 부른다.

Before: 배포 성공 → notify → 배포 실패 → notify (구분 어려움)
After:  배포 성공 → 조용함  → 배포 실패 → notify (신호 명확함)

변경 전략

이번 수정은 간단하지만 효과적이다. publish.sh 스크립트의 종료 로직을 다시 설계했다.

스크립트 수정의 핵심은 exit code 분기와 알림 호출의 조건화다. 성공(exit 0)일 때는 notify 함수를 호출하지 않고, non-zero 상태에서만 알림을 트리거한다. 대신 success case도 로그 파일에 남겨둬야 한다—나중에 "어제는 언제 배포됐지?" 같은 질문에 답할 수 있도록.

# 대략적인 패턴
if [ $? -eq 0 ]; then
  echo "배포 성공: $(date)" >> deploy.log
else
  notify_failure "배포 실패"
  exit 1
fi

팀 영향과 회고

이런 종류의 변경은 기술 리더 관점에서 중요한 의사결정 포인트를 담고 있다. 모든 정보를 전달하는 것이 좋다는 가정은 틀렸다는 걸 깨달았다. 오히려 필요한 정보만 신속하게 전달하는 시스템이 팀의 반응성을 높인다.

또 다른 배움은 이런 수정이 작지만, 누적되면 팀의 생산성에 실질적 영향을 미친다는 것이다. 알림 하나하나는 몇 초지만, 하루에 수십 개가 오면 집중력 전환 비용이 무시할 수 없다. 특히 야간 대기(on-call) 엔지니어는 이런 노이즈 때문에 수면 방해를 받기도 한다.

앞으로도 유사한 자동화 도구들을 검토할 때 "이 알림이 정말 필요한가?"를 한 번 더 물어봐야겠다는 생각이 들었다.

🛒 이 글과 어울리는 추천 상품

• 노이즈캔슬 헤드폰 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.