알림 피로를 줄이는 SLO 기반 모니터링

알림이 하루에 수십 건 오는 팀이 있다. 처음에는 다들 확인하지만 곧 무시하게 된다. 그러다 진짜 장애 알림이 그 사이에 묻힌다. 이 글은 무엇을 알림으로 만들어야 하는지, 그리고 SLO를 기준으로 알림을 정리하는 방법을 다룬다. 결론부터 말하면 사람이 지금 행동해야 하는 것만 알림이어야 한다.

알림 피로가 생기는 구조

알림이 많아지는 이유는 대개 선의에서 시작된다. 장애를 놓치고 싶지 않으니 이것저것 걸어둔다. CPU 80%, 메모리 70%, 디스크 75%, 에러 로그 발생, 응답 시간 1초 초과.

문제는 이 지표들이 사용자 경험과 직접 연결되지 않는다는 점이다. CPU가 80%여도 서비스는 멀쩡할 수 있다. 반대로 CPU가 30%인데 데이터베이스 커넥션이 고갈돼 모든 요청이 실패할 수도 있다.

그래서 알림이 오지만 할 일이 없는 상황이 반복된다. 몇 주 지나면 사람들은 알림 채널을 음소거한다. 그 시점부터 모니터링은 있지만 작동하지 않는 상태가 된다.

악순환이다. 알림을 늘려서 생긴 문제를 알림을 더 늘려서 풀려고 한다.

사용자가 겪는 것을 기준으로 삼는다

끊는 방법은 기준을 바꾸는 것이다. 시스템 내부 지표가 아니라 사용자가 겪는 것을 본다.

이걸 정리한 것이 SLI와 SLO다.

SLI(Service Level Indicator)는 서비스 품질을 나타내는 측정값이다. 대표적인 것이 넷이다. 요청 성공률, 응답 지연, 처리량, 포화도.

SLO(Service Level Objective)는 그 SLI의 목표치다. "30일간 요청의 99.9%가 성공한다", "95%의 요청이 300밀리초 안에 응답한다" 같은 형태다.

여기서 나오는 개념이 에러 예산(error budget)이다. 목표가 99.9%라면 0.1%는 실패해도 된다. 30일이면 약 43분이다. 이 예산이 남아 있으면 급하지 않고, 빠르게 소진되고 있으면 급하다.

알림은 예산 소진 속도로 건다

에러 예산 개념을 쓰면 알림 기준이 자연스럽게 정해진다. "지금 오류가 났다"가 아니라 "이 속도면 예산을 다 쓴다"로 바꾼다.

이렇게 하면 짧은 스파이크로는 알림이 오지 않는다. 오류가 잠깐 났다가 회복되면 예산 소진이 미미하기 때문이다. 반대로 조용히 지속되는 낮은 수준의 실패는 잡힌다. 임계값 방식으로는 놓치던 것이다.

알림을 세 등급으로 나눈다

모든 것이 즉시 호출일 필요는 없다. 등급을 나누면 알림 총량이 유지되면서도 중요한 것이 드러난다.

등급	기준	전달 방식
페이지(Page)	지금 사람이 개입하지 않으면 사용자 피해가 커진다	전화·푸시, 새벽에도 깨움
티켓(Ticket)	대응은 필요하지만 업무 시간에 해도 된다	이슈 생성, 채널 알림
정보(Info)	알아두면 좋지만 행동은 불필요	대시보드에만 표시

페이지 등급을 엄격하게 유지하는 것이 핵심이다. 새벽에 깨울 만한 일인가를 기준으로 삼는다. 이 질문에 "아니오"면 페이지가 아니다.

디스크 사용량 75%는 정보다. 90%이고 하루 안에 가득 찰 추세면 티켓이다. 95%이고 한 시간 안에 찰 것 같으면 페이지다. 같은 지표라도 긴급도에 따라 등급이 다르다.

알림에는 대응 방법이 붙어야 한다

새벽에 깬 사람이 알림만 보고 무엇을 해야 할지 모르면 그 알림은 절반만 쓸모 있다.

좋은 알림에는 이런 것이 들어간다. 무엇이 잘못됐는지(어떤 SLO가 위협받는지), 영향 범위(어느 기능, 어느 사용자), 관련 대시보드 링크, 대응 절차 문서 링크, 최근 배포 정보.

특히 마지막이 유용하다. 장애의 상당수는 방금 나간 변경 때문이다. 알림에 "30분 전 배포됨"이 붙어 있으면 첫 행동이 정해진다.

대응 절차(runbook)는 거창할 필요 없다. "이 알림이 오면 먼저 X를 확인하고, Y면 롤백, Z면 에스컬레이션" 정도의 세 줄이면 충분하다. 없는 것보다 훨씬 낫다.

알림을 줄이는 것이 목표다

마지막으로 관점 하나. 모니터링을 개선한다는 것은 알림을 늘리는 것이 아니라 줄이는 것이다.

정기적으로 알림을 되돌아보는 자리를 만드는 것이 좋다. 지난달에 온 알림 목록을 놓고 각각에 대해 묻는다. 이 알림으로 실제로 무언가 했는가. 안 했다면 등급을 낮추거나 없앤다. 여러 번 울렸는데 매번 같은 조치를 했다면 자동화한다.

그리고 알림을 추가할 때마다 제거할 것을 하나 찾는 규칙도 효과가 있다. 총량을 강제로 묶어두면 정말 중요한 것만 남는다.

반론도 있다. 알림을 줄이다가 진짜 장애를 놓치면 어떡하냐는 것이다. 나는 반대로 본다. 알림이 너무 많으면 이미 놓치고 있다. 사람은 하루 수십 건의 알림을 성실하게 확인하지 못한다. 다섯 건이면 전부 본다. 놓치지 않으려면 줄여야 한다.

참고 자료

• Google SRE Book: Service Level Objectives — SLI·SLO·에러 예산의 정의
• Google SRE Workbook: Alerting on SLOs — 예산 소진 속도 기반 알림 설계
• Google SRE Book: Monitoring Distributed Systems — 네 가지 골든 시그널과 알림 원칙