배포 실패 시에만 팀 알림 보내도록 개선

publish.sh 배포 스크립트의 알림 정책을 손질했다. 성공했을 때는 조용히 지나가고, 실패했을 때만 팀에 소식이 가도록 변경한 작업이다.

일어난 일

처음엔 배포 스크립트가 성공하든 실패하든 매번 알림을 보냈다. 일반적으로 "배포가 끝났다"는 사실 자체를 전달해야 한다는 심사로 만들어진 로직인데, 일일이 확인해보니 실제로는 문제가 생겼을 때만 빠르게 대응이 필요했다. 성공은 예상대로 진행된 것이고, 그걸 매번 공지할 필요는 없었던 거다.

알림 피로와 신호-노이즈 비율

이런 패턴은 운영 팀이 직면하는 흔한 딜레마다. 배포/빌드 파이프라인은 하루에 수십 번 돌아간다. 매번 "배포 완료" 메시지가 울리면:

• 팀원들이 문제 신호를 과도한 노이즈 속에서 찾아야 한다
• 슬랙이나 모니터링 대시보드가 초록불로 가득 차서, 실제 빨간불이 눈에 띄지 않는다
• 알림 자체를 무시하는 습관이 생긴다 (경각심 저하)

이걸 Alert Fatigue라고 부른다. 신호대잡음비(signal-to-noise ratio)가 나쁘면 정작 중요한 실패를 놓친다.

성공은 조용하고, 실패는 크게

좋은 모니터링 설계의 원칙:

publish.sh 수정은 이 원칙을 배포 자동화에 반영한 것이다. 대부분의 경우 배포가 성공한다. 그 성공을 매번 알릴 필요는 없고, 예외 상황(빌드 실패, 네트워크 오류, 스크립트 런타임 오류)이 발생할 때만 팀의 주의를 끌어야 한다.

구현 관점

일반적인 배포 스크립트에서 이런 조건부 알림은 다음처럼 구현된다:

#!/bin/bash

if build_and_deploy; then
  # 성공: 로그만 기록
  echo "$(date): Deploy succeeded" >> deploy.log
  exit 0
else
  # 실패: 팀에 알림
  notify_team "Deploy failed: $?"
  echo "$(date): Deploy failed with code $?" >> deploy.log
  exit 1
fi

명확한 분기점: 종료 코드(exit code)에 따라 알림 여부를 결정한다. 이렇게 하면 자동화 파이프라인(CI/CD)이 같은 논리를 따를 수 있다.

팀 운영 관점에서의 반향

이 작은 변경이 실제로는 꽤 중요한 이유:

• 온콜 엔지니어의 피로 감소: 밤에 배포가 자동으로 돌 때, 성공 알림 수십 개가 울리지 않아도 된다
• Slack 채널의 신호 품질 개선: 배포 채널을 주시하는 팀원이 중요한 메시지를 놓칠 확률이 줄어든다
• 문제 발생 시 반응 속도 향상: 실패 알림이 나오면 모두가 주목한다

이건 단순한 스크립트 수정을 넘어 팀의 의사소통 효율성을 다시 설계하는 작업이다.

비슷한 개선 사례

같은 논리를 적용할 수 있는 다른 영역들:

• DB 백업 완료 알림: 매일 성공만 울리는 대신, 실패나 지연(타임아웃)만 알림
• 헬스체크 엔드포인트: 모든 체크 결과를 로깅하되, "정상" 상태는 침묵, "이상" 상태만 알림
• 배치 작업 완료: 스케줄대로 돌면 조용하고, 누락되거나 지연되면 울린다

결국 "자동화 시스템이 예상대로 작동하는 것"을 매번 공지할 필요는 없다는 인식이 핵심이다.

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

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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