발행 봇 알림을 실패 시에만 울리도록 개선

요 며칠 전 자동화 발행 봇의 알림 정책을 손봤다. 그동안 정상 완료했을 때도 매번 알림을 보내던 걸 끄고, 실패(fail count > 0)가 발생했을 때만 팀에 알리도록 바꿨다. 작은 변경처럼 보이지만, 운영 자동화 시스템의 신호-잡음 비율(signal-to-noise ratio)을 개선하는 꽤 중요한 결정이었다.

과다 알림의 서사

처음부터가 문제 있었던 건 아니다. 발행 봇이 날마다 수십 개의 완료 알림을 보내던 시절, 팀원들은 "어라, 또 떴네?" 정도로만 읽고 넘겨버렸다. 문제는 여기다. 정상 작동하는 시스템은 소식이 없는 게 당연하다. 하지만 매 시간, 매 실행마다 "완료했습니다" 메시지가 날아오면, 뇌가 이걸 시그널로 인식하지 않는다. 알림 피로(alert fatigue)다. 그 결과 실제 장애가 발생했을 때의 알림도 놓치는 악순환이 생긴다. "어차피 자주 뜨는 메시지겠지" 하고 무시해버리는 것.

이건 소프트웨어 운영의 고전적인 난제다. 로그 시스템도, 모니터링도 이 문제와 싸운다. 팀의 인지 자원은 제한적이고, 모든 상태 변화를 알리려 하면 중요한 신호가 묻힌다.

조건부 알림으로의 전환

그래서 이번에 로직을 바꿨다. 간단하다:
- 발행 완료 + 실패 없음 (fail count = 0) → 알림 OFF
- 발행 완료했지만 실패 발생 (fail count > 0) → 알림 ON

코드 레벨에서는 write_post.py와 publish.py 두 스크립트에 실패 카운트 체크 로직을 넣어야 했다. 실패 추적을 정확히 하고, 최종 단계에서 "실패가 몇 개 있었는가"를 판단한 후 알림 발송 여부를 결정하는 방식이다.

# 의사코드 예시
if failure_count > 0:
    send_alert(f"Publishing completed with {failure_count} failures")
# else: 조용히 종료

운영 자동화의 신호 설계

이 작업을 하면서 깨달은 건, 자동화 시스템의 알림 정책은 처음부터 신중하게 설계해야 한다는 것이다. 나중에 고치려면 팀의 습관까지 함께 바뀌어야 하기 때문이다.

좋은 알림 설계의 원칙들:
- 예외를 중심으로: 정상은 조용히, 문제만 목소리를 높인다
- 액션 가능성: 알림을 받은 사람이 실제로 할 수 있는 일이 있는가?
- 문맥 포함: "뭐가 실패했는데?"라고 물어보지 않도록 충분한 정보를 담는다
- 알림 피로 관리: 일일 알림 수를 팀이 실제로 처리할 수 있는 수준으로

비슷한 패턴이 쿼리 결과 이메일, 배포 완료 보고, 정기 백업 알림 등 여러 곳에 적용된다. 정상 케이스를 침묵으로 처리하되, 이상 신호는 명확하게 전달하는 게 핵심이다.

한 가지 주의점

이 변경 후에는 "정말 발행이 돌고 있나?" 확인할 방법이 따로 필요했다. 알림만으로는 정상 상태를 검증할 수 없으니까. 그래서 함께 대시보드나 주기적 상태 체크 메커니즘을 고려해야 한다. "모든 예외는 알려주되, 정상은 조용히"라는 원칙이 "완전히 잊혀지는 시스템"으로 변질되면 안 되니까. 모니터링과 무시 사이의 균형.

결국 이건 팀 커뮤니케이션의 문제기도 하다. "이제 발행봇은 문제 있을 때만 말합니다"라는 공지가 선행되어야 혼동이 없다.

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

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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