[운영] 알림 설계: 알림 피로(alert fatigue) 막는 3등급 체계와 좋은 알림의 조건

[운영] 알림 설계: 알림 피로(alert fatigue) 막는 3등급 체계와 좋은 알림의 조건

모니터링을 처음 붙이면 누구나 같은 길을 걸어요 — "혹시 모르니" 알림을 하나씩 추가하다가, 어느 날 하루 수십 건이 울려요. 팀 전체가 알림을 읽지 않고 지우는 습관이 생겨요. 그러다 진짜 장애 알림이 그 소음에 묻히고 결국 장애를 고객 문의로 알게 돼요. 알림은 많을수록 안전한 게 아니라, 어느 선을 넘으면 많을수록 위험해져요.

지난 편(장애 대응 첫 5분)이 알림이 울린 다음의 이야기였다면, 이번 편은 그 알림 자체를 설계하는 이야기예요 — 3등급 분류, 좋은 알림 한 통의 조건, 그리고 알림을 계속 건강하게 유지하는 루틴을 짚어볼게요. 운영 기본기 시리즈 2편이에요.

01. 알림 피로: 많이 울릴수록 위험해지는 역설

알림 피로(alert fatigue)의 메커니즘은 단순해요. 행동이 필요 없는 알림이 반복되면 사람의 뇌는 "또 그거네"로 학습하고 그 학습은 알림별로 구분되지 않아요 — 모든 알림에 대한 반응 속도가 같이 무뎌져요. 늑대 소년 효과죠. 하루 50건이 울리는 채널에서 진짜 1건의 가치는 0에 수렴해요.

그래서 알림 설계의 제1원칙은 이거예요 — 울리면 반드시 "지금 행동"이 따라야 한다. 받은 사람이 아무것도 안 해도 되는 알림은 안전장치가 아니라, 진짜 알림의 신뢰를 갉아먹는 비용이에요. "일단 알림 걸어두자"의 반대편에 서는 게 좋은 알림 설계의 시작이에요.

02. 모든 신호를 3등급으로: 깨울 것, 내일 볼 것, 기록할 것

그럼 "지금 행동이 필요 없는" 신호들은 버리느냐 — 아니에요. 등급을 나눠서 전달 방식을 다르게 해요.

• 🔴 페이지(즉시) — 사용자 영향이 진행 중인 것. 에러율 급등, 서비스 다운, 결제 실패율 임계 초과. 기준은 하나예요 — "지금 사람이 개입해야 피해가 멈추는가." YES면 새벽에 깨울 가치가 있고 깨워야 해요.
• 🟡 티켓(근무시간) — 지금은 괜찮지만 곧 문제가 될 추세. 디스크 70%, 인증서 만료 D-14, 대사 불일치 증가, 느린 쿼리 증가. 자는 사람을 깨울 이유가 없으니 업무 큐로 보내고 다음 날 처리해요.
• ⚪ 로그/대시보드(알림 금지) — 개별 재시도 성공, GC 1회, 일시 스파이크 후 자동 회복 같은 맥락 정보. 조사할 때 찾아보는 것이지, 푸시할 이유가 없어요.

실무에서 가장 흔한 설계 실수가 🟡감과 ⚪감을 🔴 채널로 보내는 것이에요. "디스크 70%"는 중요한 신호지만 새벽 3시의 페이지감은 아니거든요. 같은 정보라도 어느 채널로 가느냐가 알림 체계 전체의 신뢰를 결정해요. 분류가 애매하면 "이게 새벽에 울렸을 때 내가 지금 일어나서 할 일이 있나"를 물어보면 돼요 — 없으면 🔴이 아니에요.

03. 좋은 알림 한 통의 조건

증상 기반 > 원인 기반

"CPU 80% 초과"는 원인 지표예요 — CPU가 높아도 사용자는 멀쩡할 수 있고, CPU가 낮아도 서비스는 죽어 있을 수 있어요. 반면 "결제 성공률 95% 미만"은 증상 지표예요 — 이게 울리면 사용자 영향이 확실하니, 무조건 페이지감이에요. 페이지는 가능한 한 증상(성공률·에러율·지연)에 걸고, 원인 지표(CPU·메모리·디스크)는 티켓·대시보드 쪽으로 보내요. 원인 지표에 페이지를 걸면 "울렸는데 아무 일 없음"이 쌓이면서 1번의 악순환이 시작되거든요.

지속 조건 + 추세

순간 스파이크는 대부분 자기 회복해요. "임계 초과 즉시"가 아니라 "5분간 지속 시 발사"로 걸면 오탐의 큰 덩어리가 사라져요. Kafka lag 모니터링 편에서 "lag 절대값보다 추세"라고 했던 그 원칙이 모든 알림에 일반화돼요 — 값 하나의 스냅샷보다, 방향과 지속이 신호예요.

알림 본문이 첫 5분을 안내한다

새벽 3시에 받은 알림의 본문이 "CPU high" 한 줄이면, 받은 사람은 맨몸으로 조사를 시작해요. 좋은 알림은 제목 = 영향 한 줄, 본문 = 관련 대시보드 링크 + 런북 링크예요. 지난 편의 "누가 받아도 같은 첫 5분"이 바로 이걸로 만들어져요 — 첫 5분의 절차를 알림이 들고 오는 거예요.

상태 전이를 알리는 알림도 같은 원칙이에요. 서킷 브레이커 편에서 서킷 OPEN 전환을 알림으로 받으라고 했는데 — 이것도 "OPEN 됐다"만 오는 것과, "어느 의존성이 OPEN / 영향 받는 API / fallback 동작 중 여부"가 같이 오는 것의 차이가 새벽의 30분이에요.

04. 알림은 만드는 게 아니라 가꾸는 것

알림 체계는 한 번 설계하고 끝이 아니에요. 서비스가 변하면 임계값의 의미도 변하고, 한때 유의미했던 알림이 소음이 돼요. 그래서 루틴이 필요해요.

• "행동 없이 닫힌 알림"을 주기적으로 강등·삭제 — 지난달 울린 알림 중 아무 조치 없이 닫힌 것들을 목록으로 뽑아요. 그게 알림 체계의 부채 목록이에요. 🔴→🟡 강등하거나, 임계값을 조정하거나, 삭제해요.
• 장애 후엔 반대 질문 — "이 장애를 더 일찍 알 수 있었던 신호가 있었나?" 있었는데 ⚪에 묻혀 있었다면 승격 후보예요. 포스트모템(이 시리즈 마지막 편)의 단골 액션 아이템이에요.
• 온콜 인수인계 때 알림 건수 공유 — 지난 주 페이지가 몇 건이었는지를 팀이 숫자로 봐요. 주당 페이지가 두 자릿수면 그 자체가 개선 대상이에요. 사람이 갈리기 전에요.

05. 자주 만나는 문제

알림을 줄이자니 "그러다 놓치면 어떡해"라는 반대가 있어요

삭제가 아니라 강등이라고 설명하는 게 좋아요 — 신호는 티켓·대시보드에 그대로 남고, 전달 방식만 바뀌는 거예요. 그리고 반대 증거를 보여줘요: 그 알림이 지난 N개월간 울렸을 때 실제 조치로 이어진 비율. 0%면 그건 이미 "놓치고 있는" 알림이에요 — 아무도 안 읽으니까요.

임계값을 어떻게 잡아야 할지 모르겠어요

처음부터 정답은 없어요. 평시 데이터 1~2주를 보고 "평소 최대치보다 여유 있게" 잡은 뒤, 위 루틴으로 조정해가는 거예요. 임계값은 설정이 아니라 운영이에요.

같은 장애에 알림이 수십 통씩 쏟아져요

알림 폭풍(alert storm)이에요. DB 하나가 죽으면 그걸 쓰는 모든 서비스의 알림이 같이 울리거든요. 같은 시간대·같은 원인의 알림을 묶는 그룹핑(대부분의 알림 도구가 지원해요)과, 가능하면 의존성 기반 억제(DB 다운 알림이 떴으면 하위 서비스 알림은 묶음 처리)를 둬요. 첫 통만 페이지, 나머지는 그 스레드에 붙는 게 이상적이에요.

새벽에 깨울 가치

알림의 가치는 개수가 아니라 신뢰예요 — 울렸을 때 "진짜다"라고 믿고 일어나게 만드는 것. 그래서 울리면 반드시 "지금 행동"이 따라야 하고, 신호는 페이지/티켓/로그 3등급으로 나눠 전달 방식을 달리해요. 페이지는 증상 기반으로 걸고 지속 조건을 달며 본문에 런북을 실어요. 그리고 행동 없이 닫힌 알림은 주기적으로 강등하는 루틴까지가 설계예요.

알림 하나를 만들거나 지울 때마다 던질 질문은 이거예요 — 이게 새벽 3시에 울렸을 때, 받은 사람이 지금 일어나서 할 일이 있나? 없으면 그건 페이지가 아니에요. 다음 편은 운영 DB를 손으로 고쳐야 할 때의 데이터 보정 규율이에요.

출처: Google SRE Book — Monitoring Distributed Systems · Google SRE Workbook — Alerting on SLOs