알림이 하루 200개면 아무도 안 본다 — 알림 피로 줄이기

알림을 꼼꼼히 걸어 뒀어요. CPU, 메모리, 디스크, 응답 시간, 오류율, 큐 길이까지요.

그런데 하루에 알림이 200개씩 와요. 대부분은 잠깐 튀었다가 저절로 돌아오는 것들이에요.

몇 주 지나니 아무도 안 봐요. 채널은 음소거됐고, 새 알림이 와도 스크롤로 지나가요.

그리고 진짜 장애가 났을 때, 그 알림도 그 200개 사이에 묻혔어요.

알림을 많이 걸어서 아무것도 못 보게 된 상태예요.

관측에 쓴 노력이 전부 무의미해진 거예요. 더 나쁜 건 그동안 우리가 잘 대비하고 있다고 믿고 있었다는 점이고요. 알림이 많다는 게 안심의 근거였으니까요.

왜 그런가

알림의 목적은 정보 전달이 아니라 행동 유발이에요. 사람이 지금 무언가를 해야 할 때 부르는 거죠.

그런데 대부분의 알림은 이 기준을 안 지켜요. "CPU 가 80% 를 넘었다"는 사실이지 행동이 아니에요. 그래서 받아도 할 게 없고, 할 게 없는 알림이 반복되면 무시하는 법을 배웁니다.

이건 사람의 잘못이 아니에요. 대부분이 거짓 경보인 신호를 계속 받으면 무시하는 게 합리적인 적응이에요. 그리고 한번 무시하기 시작하면 진짜 신호도 같이 무시돼요.

여기서 나쁜 알림의 특징을 정리할 수 있어요.

행동이 없어요. 받아도 뭘 해야 할지 모르거나, 할 게 없어요.

원인이 아니라 증상을 봐요. CPU 가 높은 건 결과예요. 사용자가 겪는 문제와 직접 연결되지 않아요.

임계값이 임의적이에요. 80% 라는 숫자에 근거가 없어요. 그 위가 왜 문제인지 설명할 수 없어요.

저절로 회복돼요. 사람이 볼 때쯤이면 이미 정상이에요.

그리고 이 모든 게 합쳐지면 알림 시스템 자체가 신뢰를 잃어요. 그때부터 관측에 쓴 모든 노력이 무의미해집니다.

코드로 보면

사람을 부를 만한 것만 부른다:

✕ CPU > 80%        — 사실이지 행동이 아니다
✕ 메모리 > 90%     — 그래서 뭘 해야 하나
✕ 디스크 > 70%     — 아직 여유가 있다

· 사용자가 겪는 문제로 건다
✓ 오류율이 5분간 1% 초과
✓ 1초를 넘긴 요청 비율이 5% 초과
✓ 주문 완료 건수가 평소의 절반 이하

· 예측 가능한 소진은 남은 시간으로
✕ 디스크 > 70%
✓ 현재 증가 속도로 4시간 내 소진 예상

· 등급을 나눈다
✓ 지금 깨워야 함 / 업무 시간에 보면 됨 / 대시보드만
✕ 전부 같은 등급이면 등급이 없는 것과 같다

✕ 문제 지점 · ✓ 해법 · 그대로 돌려 보기 전에 자기 환경에 맞게 고쳐 주세요.

실전에서는

좋은 알림의 기준을 정리하면 이래요.

첫째, 사람이 지금 행동해야 하는 것만. 자동으로 회복되거나, 나중에 봐도 되거나, 할 게 없는 건 알림이 아니라 대시보드 항목이에요.

둘째, 증상이 아니라 사용자 영향으로. CPU 가 아니라 오류율, 메모리가 아니라 응답 시간, 큐 길이가 아니라 처리 지연이요. 사용자가 아프지 않으면 굳이 새벽에 깨울 이유가 없어요. 반대로 CPU 가 30% 여도 사용자가 실패하고 있으면 그건 알림이어야 하고요.

셋째, 등급을 나눠서. 지금 깨워야 하는 것, 업무 시간에 보면 되는 것, 대시보드에만 있으면 되는 것. 전부 같은 등급으로 보내면 등급이 없는 것과 같아요.

넷째, 무엇을 해야 하는지 함께. 알림에 대응 문서 링크와 확인할 지표를 담으면 받은 사람이 바로 움직일 수 있어요. 그게 없으면 받은 사람이 처음부터 조사해야 합니다.

다섯째, 묶어서. 같은 원인에서 나온 여러 알림을 하나로 묶으면 한 번만 울려요. 서버 열 대가 동시에 문제면 알림도 열 개가 아니라 하나여야 해요.

그리고 정기적으로 정리해야 해요. 알림을 추가하기는 쉬운데 지우는 사람은 없어요. 그래서 시간이 지날수록 늘기만 해요. 한 달에 몇 번 울렸는지, 그중 실제로 행동한 게 몇 번인지 세어 보면 지울 것이 금방 나옵니다.

여기서 앞 편들과 이어져요. 에러를 삼키면 알 수 없고, 알림이 너무 많아도 알 수 없어요. 둘 다 같은 결과에 도달합니다 — 중요한 신호를 놓치는 것.

처방

1. 사람이 지금 행동해야 하는 것만 알림으로 만드세요. 나머지는 대시보드로 옮기세요.
2. 증상이 아니라 사용자 영향으로 거세요. 오류율·지연·전환 실패요.
3. 등급을 나누세요. 깨울 것과 업무 시간에 볼 것을 구분하세요.
4. 알림에 무엇을 해야 하는지 담으세요. 대응 문서와 확인할 지표를 함께요.
5. 같은 원인의 알림을 묶으세요. 서버 열 대의 문제가 알림 열 개가 되면 안 됩니다.
6. 예측 가능한 소진은 남은 시간으로 표현하세요. "디스크 70%" 보다 "4시간 뒤 소진"이 행동 가능합니다.
7. 정기적으로 정리하세요. 울린 횟수와 실제 행동한 횟수를 세면 지울 것이 보입니다.
8. 알림 하나를 추가할 때마다 하나를 지울 수 있는지 검토하세요. 알림은 추가하기는 쉽고 지우는 사람은 없어서 시간이 지날수록 늘기만 합니다.
9. 임계값을 올려 줄이지 말고 지속 시간을 조건에 넣으세요. "5분간 지속되면" 이 "값을 두 배로" 보다 낫습니다.
10. 알림 경로를 주기적으로 시험하세요. 조용한 것과 고장 난 것은 구별되지 않습니다.

지금 확인해 보세요

알림이 일하고 있는가:

· 알림별 울린 횟수와 실제 행동한 횟수
✓ 많이 울렸는데 행동이 0 이면 지울 후보다
✓ 이 두 숫자만 세도 정리할 것이 보인다

· 하루 알림 수
✕ 사람이 하루에 볼 수 있는 알림 수에는 한계가 있다

· 알림에 대응 방법이 담겨 있는가
✕ 받은 사람이 처음부터 조사해야 하면 대응이 늦다

· 등급이 실제로 나뉘어 있는가
✕ 전부 같은 등급이면 등급이 없는 것과 같다

· 알림 경로가 살아 있는가
✓ 주기적으로 시험 알림을 보낸다
✕ 조용한 것과 고장 난 것은 구별되지 않는다

핵심 한 줄알림은 행동을 부르는 것이다. 행동이 없으면 그건 소음이다.