개발 slecs

운영 모니터링 알림 과부하를 일일 요약 체계로 개선

목차

운영 모니터링 스크립트들의 알림 정책을 다시 정리했다. 정상 동작은 침묵하고, 문제가 실제로 발생했을 때만 알림을 보내는 방식으로 전환하면서, 동시에 일일 통합 요약을 추가해서 전체 상황을 한눈에 파악할 수 있게 만들었다.

왜 이런 변경이 필요했나

지난 몇 개월간 운영팀으로부터 계속 들었던 이야기가 하나 있었다. "알림이 너무 많다"는 것. 인증 체크, 헬스 모니터, 슬롯 점검, 토픽 보충 같은 정기적인 배치 작업들이 매번 "정상적으로 완료되었습니다"라는 식의 메시지를 보내고 있었다. 하루 종일 녹색 불이 계속 들어오니, 정작 실제 문제가 발생했을 때 신호가 묻혀버리는 악순환이 생겼다.

이게 바로 'alert fatigue'다. 신호가 너무 많으면 사람의 뇌는 점점 경고에 둔감해진다. 중요한 것과 중요하지 않은 것의 경계가 흐려지고, 결국 진짜 위급한 상황도 놓치기 쉬워진다. 특히 ops 스크립트는 대부분 야간이나 새벽 시간에 주기적으로 실행되는데, 매 시간마다 "모두 정상입니다"라는 알림이 오면 담당자 입장에서는 번들번들한 휴대폰 알림에 시달리게 되는 것.

어떻게 풀었나

변경은 두 가지 축으로 진행했다.

첫째, 침묵의 원칙. 여러 스크립트에 일관된 로직을 적용했다. 정상 완료면 조용히 끝낸다. 에러나 경고, 비정상적인 지표가 감지되었을 때만 명시적으로 알림을 보낸다. 예를 들어 인증 체크 스크립트는 성공했으면 그냥 종료하고, 특정 서비스의 인증이 실패했을 때만 "서비스 X의 인증 실패 감지" 같은 구체적인 메시지를 띄운다.

# Before
✓ Auth check completed (all passed)
✓ Health monitor executed
✓ Slot checkup finished

# After
⚠ Auth service X failed
⚠ Health metric Y below threshold

둘째, 일일통합요약. 단순히 알림을 줄인 것만으로는 불충분했다. 담당자 입장에서는 여전히 "우리 시스템이 지금 제대로 돌아가고 있나?"라는 의문이 남는다. 그래서 매일 정해진 시간에 그 날의 전체 모니터링 결과를 종합해서 보여주는 일일 통합 리포트를 추가했다.

이 리포트에는 각 스크립트의 실행 결과, 발생한 모든 문제 사항, 주요 지표들이 정리된다. 팀장이나 운영자는 아침에 이 리포트 하나를 확인하면 어제 하루 동안 뭐가 어떻게 돌아갔는지 파악할 수 있다.

왜 이런 선택을 했는가

이 작업을 할 때 고민했던 부분은, "혹시 우리가 중요한 신호를 놓치게 되지 않을까?"라는 것이었다. 실시간 알림을 줄이면, 혹시 한밤중에 뭔가 터졌을 때 못 챙기지 않을까?

그런데 생각해보면 현실은 그렇지 않았다. 실제로 운영팀이 해야 하는 일은:
- 즉각적인 반응이 필요한 문제: 매우 드물다. 정말 중요한 장애는 고객 상담이나 모니터링 대시보드 접속으로 먼저 감지되는 경우가 많다.
- 한 시간 내 확인하면 되는 문제: 대부분의 경우다. 이런 건 일일요약으로 충분하다.
- 인지만 해두면 되는 정상 진행 상황: 가장 많았는데, 이게 noise를 만들고 있었다.

그래서 우리는 "중요한 건 즉시, 나머지는 일일요약"이라는 이중 구조로 가기로 했다. 각 스크립트에는 여전히 진짜 critical한 상황(예: 데이터베이스 연결 실패, 인증 서버 다운)을 감지하면 즉시 알림을 보낼 수 있는 로직이 있다. 하지만 "배치 작업 완료", "슬롯 2000개 보충됨" 같은 정상 사항들은 일일요약에만 들어간다.

팀 관점의 의사결정

이 변경은 단순한 기술 개선이 아니라 팀 문화의 문제였다. ops 모니터링은 결국 사람이 의사결정을 내린다. 알림이 많을수록 신호-대-잡음 비율이 떨어지고, 결국 운영팀의 정신적 리소스가 낭비된다.

비슷하게 많은 팀에서 경험하는 일인데, 처음엔 "뭔가 모니터링이 철저해 보이려고" 모든 것을 알림으로 설정한다. 그다음엔 담당자가 "이걸 다 확인할 수 없어"라고 불평하고, 결국 아무도 알림을 보지 않게 되는 악순환. 우리는 처음부터 이 덫에 빠지지 않으려고 했다.

앞으로의 고려사항

한 가지 배운 점은, "침묵한다"는 정책도 명확한 정의가 필요하다는 것이다. 각 스크립트마다 "뭐가 정상이고 뭐가 비정상인가"를 명시적으로 문서화해야 다음 담당자가 이 로직을 이해할 수 있다. 그래서 변경 시에 그 기준들을 주석이랑 README에 정리했다.

또한 일일요약도 "사람이 실제로 읽는" 형태여야 한다. 너무 길면 아무도 안 본다. 핵심만 꼬집어서, 1분 안에 훑을 수 있는 수준으로 유지하는 게 중요하다.


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

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

댓글 0

첫 댓글 달아줘.