모니터링 알림 피로를 30분 윈도우 상태 전환 가드로 해결

인증 체크 스크립트의 알림 폭탄 문제를 30분 윈도우 기반 상태 전환 가드로 해결했다. 단순해 보이지만 모니터링 시스템 신뢰도에 영향 주는 작은 하지만 중요한 변경이다.

배경: 왜 가드가 필요했나

모니터링 시스템에서 흔히 마주하는 딜레마가 있다. codex-auth-check 같은 상태 체크 스크립트를 돌려보면, 네트워크 지터나 일시적 서비스 응답 지연으로 상태가 순간 OK에서 FAIL로 떨어진다. 그리고 다음 체크에서 다시 OK로 돌아온다. 이런 일시적 변동이 매번 알림으로 전송되면 어떻게 될까?

온콜 엔지니어(또는 팀)의 입장에서:
- 매 시간 수십 개의 거짓 알림 수신
- "또 저 경보구나" 심리로 실제 장애 알림도 무시
- 알림 채널에 대한 신뢰도 하락

결국 알림 시스템이 "늑대가 왔다"는 오류를 반복하면, 정작 진짜 장애가 발생했을 때 대응 속도가 떨어진다. 이게 바로 모니터링 팀이 직면하는 "알림 피로도(Alert Fatigue)" 문제다.

작업: 30분 윈도우로 실제 장애만 걸러내기

이번 변경의 핵심 로직:

# 30분 전 상태 vs 현재 상태 비교
# OK → OK: 문제 없음, 알림 X
# OK → FAIL: 상태 전환! → 알림 보내기
# FAIL → FAIL: 이미 알림했으므로 알림 X
# FAIL → OK: 복구됨, 알림 보내기

즉, 30분 간격으로 상태를 스냅샷 저장해두고, 실제 전환이 일어났을 때만 알림을 트리거한다. 단순한 변동(수 분의 기간 OK↔FAIL 오진)은 이 윈도우 안에서 걸러진다.

회고: 모니터링 신뢰도 투자

이 작업이 작아 보이지만, 팀 관점에서는 생각보다 큰 의미가 있다.

1단계 모니터링의 흔한 실수:
- 검사만 자주 함 (5분마다, 1분마다)
- 결과를 그대로 알림으로 변환
- 결과: 알림 채널이 노이즈로 포화

개선된 접근:
- 상태의 지속성을 판단하는 최소 윈도우 설정
- 전환을 감지하는 상태 머신 로직
- 알림은 "변화"에만 반응

이건 SRE 원칙 중 하나다. 신뢰할 수 있는 알림이 많은 알림보다 훨씬 중요하다는 것. 온콜이 휴대폰에서 벨소리를 끌고 싶지 않은 이유는 정확히 이것 때문이다.

비슷한 패턴들이 실제로 많이 쓰인다:
- Debounce: UI에서 버튼 중복 클릭 방지 (이것도 "짧은 기간 중복 액션 무시")
- Threshold 설정: CPU 70% 한 번이 아니라 5분 이상 70% 초과 시 알림
- 확인 알림(Confirmation Alert): 장애 의심 → 한 번 더 확인 후 실제 알림

다음

이제 codex-auth-check는 너무 민감하지 않으면서도 실제 장애는 놓치지 않는 균형점을 찾았다. 팀이 자고 있을 때 불필요한 진동으로 깨어나는 일이 줄어들 것이다. 그리고 그때 온다는 알림은 더 신뢰할 수 있게 된다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

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