API 장애 알림 시스템은 단순한 모니터링 기능이 아니라, 실제 장애 대응 속도를 결정하는 핵심 인프라입니다. 많은 시스템이 다양한 지표를 수집하고 있음에도 불구하고, 실제 장애 발생 시 대응이 늦어지는 이유는 알림 설계 자체가 잘못되어 있기 때문입니다.
새벽 두 시에 슬랙 알림 소리에 깨서 확인해 보면 "CPU 사용률 75% 초과"라는 메시지가 와 있습니다. 실제로 아무 문제도 없는데 말입니다. 이런 상황을 몇 달 동안 반복하다가 결국 알림 자체를 무시하는 습관이 생겼고, 그러다 진짜 장애를 30분 넘게 놓친 적이 있습니다. 알림이 많다고 좋은 게 아니라는 걸 그때 몸으로 배웠습니다.
알림 시스템이 실패하는 가장 흔한 이유
일반적으로 알림 시스템을 처음 구축할 때는 "최대한 많이 감지하자"는 방향으로 설계하는 경우가 많습니다. CPU, 메모리, 디스크, 네트워크 지연시간까지 모든 지표에 임계값을 걸어두고 조금이라도 튀면 알림이 오도록 만들었습니다. 처음은 뭔가 철저하게 운영하는 것 같은 느낌이 들었는데, 두 달째가 되자 팀원들이 알림 채널 자체를 음소거하기 시작했습니다.
문제의 핵심은 오탐(False Positive)이었습니다. 오탐이란 실제로는 장애가 아님에도 알림이 발생하는 경우를 말합니다. 단순 임계값 기반 알림은 구조적으로 오탐에 취약합니다. 예를 들어 배포 직후 워밍업 구간에서 응답 지연이 잠깐 늘어나거나, 새벽 배치 작업이 돌아가는 동안 CPU가 순간적으로 치솟는 경우가 모두 알림으로 날아옵니다. 이런 일이 반복되면 팀 전체에 알림 피로(Alert Fatigue)가 쌓입니다. 알림 피로란 지속적인 알림 노출로 인해 실제 위험 신호에도 반응이 둔해지는 현상입니다. 그리고 그 결과는 제가 직접 경험했듯이 진짜 장애를 늦게 인지하는 것으로 이어집니다.
일반적으로 알림이 많을수록 시스템이 철저하다고 생각하는 분들도 있는데, 알림 수와 대응 속도는 비례하지 않습니다. 신호 대 노이즈 비율, 즉 실제 의미 있는 알림이 전체 알림에서 차지하는 비율이 낮아질수록 대응 품질은 오히려 떨어집니다.
SLO 기반 신호 정의로 바꾸고 나서 달라진 것들
알림 시스템을 뜯어고치면서 제가 가장 먼저 한 것은 SLO(Service Level Objective) 기반으로 알림 기준을 재정의하는 일이었습니다. SLO란 서비스가 사용자에게 제공해야 하는 품질 목표를 수치로 정의한 것으로, 예를 들어 "99%의 요청은 200ms 이내에 응답해야 한다"는 식의 기준입니다. 서버가 얼마나 열심히 일하는지가 아니라, 사용자가 실제로 체감하는 품질을 기준으로 알림을 설정하는 방식입니다.
이렇게 바꾸고 나니 알림 수는 줄었지만, 각 알림의 밀도가 완전히 달라졌습니다. CPU가 80%를 넘어도 에러율이 정상이고 응답 시간이 SLO 범위 안에 있으면 알림이 오지 않습니다. 반대로 CPU는 50%인데 에러율이 급등하면 즉시 알림이 옵니다. "이렇게 조용해도 되나?" 하는 불안감이 있었는데, 2개월 운영해 보니 진짜 대응이 필요한 알림이 훨씬 선명하게 눈에 들어왔습니다.
또 단일 지표보다 복합 조건이 훨씬 정확하다는 것도 경험상 맞습니다. "응답 시간 증가"만으로는 오탐이 많지만, "응답 시간 증가 + 에러율 동시 상승"이라는 조건을 걸면 실제 장애와의 일치율이 눈에 띄게 올라갑니다. 구글의 SRE(Site Reliability Engineering) 원칙에서도 증상 기반 알림(Symptom-based Alerting)을 권장하고 있는데, 이는 원인 지표가 아닌 사용자 영향 지표를 먼저 보라는 개념입니다. (출처: Google SRE Book - Monitoring Distributed Systems)
알림 단계를 경고(Warning)와 심각(Critical)으로 나눈 것도 효과가 컸습니다. 경고 단계에서는 추적 대시보드 링크만 슬랙으로 보내고, 심각 단계에서만 온콜 담당자에게 직접 호출이 가게 구성했습니다. 당연한 것 같지만 이걸 제대로 구분한 팀이 생각보다 많지 않다는 게 제 느낌입니다.
알림 전달 구조와 에스컬레이션 설계
알림을 잘 설계해도 전달 구조가 엉망이면 무용지물입니다. 제가 겪은 또 하나의 실패 사례는, 알림이 팀 공용 채널 하나로만 가도록 설정해 놨을 때였습니다. 누군가 보겠지 하는 암묵적 기대가 있었는데, 야근 없는 새벽에 발생한 장애에 아무도 반응하지 않았습니다. 책임이 분산되면 사실상 책임이 없는 것과 같습니다.
이 문제를 해결한 방식은 서비스별로 온콜 담당자를 지정하고, 에스컬레이션(Escalation) 정책을 도입하는 것이었습니다. 에스컬레이션이란 일정 시간 안에 대응이 이루어지지 않을 경우 상위 담당자나 팀장에게 자동으로 알림이 전달되는 구조를 말합니다. PagerDuty나 OpsGenie 같은 도구가 이 기능을 제공하는데, 핵심은 도구보다 정책 자체를 명확하게 정의하는 것입니다. "15분 응답 없으면 시니어 엔지니어에게 전달, 30분 이내 처리 없으면 팀 리드에게 전달"처럼 구체적인 기준이 있어야 합니다.
채널 선택도 생각보다 중요합니다. 저는 아래와 같이 알림 유형에 따라 채널을 분리해서 운영하고 있습니다.
- Critical 알림: 온콜 담당자에게 앱 푸시 + SMS 이중 전달. 확인 여부를 반드시 ACK(Acknowledgement, 수신 확인) 처리해야 알림이 멈추는 구조.
- Warning 알림: 슬랙 전용 채널로 전달. 대응이 즉각 필요하진 않지만 추이를 지켜봐야 하는 경우.
- Info 로그: 알림 채널이 아닌 모니터링 대시보드에서만 확인 가능하도록 분리.
이렇게 세 단계로 나눈 이후로 정말 중요한 알림이 묻히는 일은 거의 사라졌습니다. 물론 초기에 채널 구분 기준을 놓고 팀 내에서 논쟁이 있었는데, 그 과정 자체가 팀이 알림에 대한 공통 기준을 갖게 되는 계기가 됐습니다.
알림 시스템은 운영하면서 계속 다듬어야 한다
알림 시스템을 한 번 잘 만들면 끝이라고 생각하는 분들도 있는데, 서비스는 계속 변하고, 트래픽 패턴도 변하고, 팀 구조도 바뀝니다. 처음에 잘 설계된 알림도 6개월이 지나면 맥락이 달라져서 오탐을 만들어내기 시작합니다.
지금 운영하는 방식은 매달 한 번씩 지난달 알림 이력을 짧게 검토하는 것입니다. 오탐이 반복된 알림은 조건을 수정하거나 제거하고, 실제 장애가 발생했는데 알림이 없었던 경우는 미탐(False Negative)으로 기록해서 커버리지를 보완합니다. 미탐이란 실제 장애가 발생했음에도 알림이 발생하지 않는 경우를 말합니다. 오탐보다 미탐이 더 위험하기 때문에 이 부분은 특히 신경 써야 합니다.
자동화와 알림의 결합도 점점 효과가 생기고 있습니다. 트래픽이 갑자기 치솟을 때 알림과 동시에 오토스케일링(Auto Scaling)이 실행되도록 연결했더니, 실제로 엔지니어가 개입하기 전에 시스템이 먼저 대응하는 경우가 늘었습니다. 오토스케일링이란 트래픽 변화에 따라 서버 자원을 자동으로 늘리거나 줄이는 기능으로, 알림 시스템과 연계하면 장애 발생 전에 선제 대응이 가능합니다. AWS나 GCP 모두 이 기능을 지원하며, 설정 방법은 각 클라우드 공식 문서에서 확인할 수 있습니다. (출처: AWS EC2 Auto Scaling 공식 문서)
알림 시스템이 성숙해질수록 조용해집니다. 처음에는 그게 불안하게 느껴졌는데, 지금은 조용한 알림 채널이 오히려 시스템이 잘 작동하고 있다는 신호라는 걸 압니다. 결국 좋은 알림 시스템은 "많이 알리는 것"이 아니라 "정확한 순간에, 정확한 사람에게, 행동 가능한 정보를 전달하는 것"으로 귀결됩니다.
알림 시스템을 처음부터 완벽하게 만들 수는 없습니다. 저도 여러 번 실패하고, 진짜 장애를 놓치는 경험을 하면서 지금의 구조를 만들었습니다. 지금 운영 중인 알림 시스템이 자꾸 무시되고 있다면, 그건 팀원들의 태도 문제가 아니라 설계 문제일 가능성이 높습니다. SLO 기준으로 신호를 다시 정의하고, 채널과 에스컬레이션을 명확하게 나누는 것부터 시작해 보시길 권합니다. API 장애 이후의 회고 방법이 궁금하신 분은 아래 관련 글도 참고해 보시기 바랍니다.
관련 글
댓글
댓글 쓰기