장애 감지와 알림 체계는 어떤 신호부터 잡아야 실무에 도움이 되나

모니터링과 알림(alerting)은 서비스 운영의 기본이지만, 어떤 신호를 모니터링하고, 어떤 조건에서 알림을 보낼 것인지의 설계는 간단하지 않다. 모니터링이 없으면 장애를 감지하지 못하고, 알림이 너무 많으면 경보 피로(alert fatigue)로 실제 중요한 알림을 놓치게 된다.

이 글은 Breeze 플랫폼의 모니터링 및 알림 체계 운영 경험을 바탕으로, 어떤 신호가 실제 장애를 빠르게 감지하는 데 도움이 되었는지, 그리고 알림 설계에서 어떤 실수를 했고 어떻게 개선했는지를 기록한다.

새벽 3시에 알림이 울릴 때 그것이 즉시 대응이 필요한 진짜 장애인지, 아침까지 기다려도 되는 경미한 이상인지를 구분하는 것은 운영 경험이 쌓여야 가능하다. 이 경험을 체계적으로 기록한다.

Breeze 플랫폼은 커머스 서비스이므로 24시간 가용성이 중요했다. 장애가 발생하면 매출 손실과 고객 불만이 직접적으로 발생한다. 장애를 빠르게 감지하고 대응하는 것은 서비스 안정성의 핵심이다.

모니터링의 계층은 여러 레벨로 나뉜다. 인프라 레벨(CPU, 메모리, 디스크, 네트워크), 미들웨어 레벨(DB 커넥션 풀, 큐 깊이), 애플리케이션 레벨(HTTP 에러율, 응답시간, 비즈니스 메트릭), 사용자 경험 레벨(페이지 로딩 시간, 전환율) 등이 있다. 어떤 레벨의 모니터링이 장애를 가장 빠르게 감지하는지는 장애의 유형에 따라 다르다.

알림 채널로는 주로 Slack을 사용했다. 심각한 알림은 개인 DM이나 전화(PagerDuty 또는 유사 시스템)로 에스컬레이션되었다. 알림의 긴급도에 따라 채널을 분리하는 것이 중요했다.

알림 설계 절차

가장 유용했던 신호: HTTP 5xx 비율과 응답시간 P95/P99

장애를 가장 빨리 감지한 신호는 HTTP 5xx 에러율과 응답시간의 고분위수(P95, P99)였다. 5xx 에러는 서버 쪽 오류를 의미하므로, 5xx 비율이 평소 대비 급증하면 무언가 잘못된 것이다. P95/P99 응답시간은 대부분의 요청은 정상이지만 일부 요청이 비정상적으로 느린 상황을 감지한다.

평균(mean) 응답시간은 장애 감지에 별로 도움이 되지 않았다. 대부분의 요청이 정상(50ms)이고 소수의 요청이 타임아웃(30초)인 경우, 평균은 크게 변하지 않는다. 하지만 P99가 급증하면 일부 사용자가 심각한 지연을 경험하고 있다는 신호다. 이런 이유로 P95/P99를 주요 알림 기준으로 사용했다.

인프라 메트릭의 역할과 한계

CPU 사용률, 메모리 사용량, 디스크 I/O 등의 인프라 메트릭도 모니터링했다. 이 메트릭들은 장애의 원인을 분석하는 데는 유용하지만, 장애 자체를 감지하는 데는 한계가 있다. CPU가 80%라는 것만으로는 서비스에 문제가 있는지 알 수 없다. CPU가 80%여도 서비스가 정상일 수 있고, CPU가 30%여도 서비스가 장애일 수 있다.

하지만 특정 인프라 메트릭은 선행 지표(leading indicator)로 유용했다. DB 커넥션 풀 고갈은 5xx 에러보다 먼저 나타난다. 커넥션 풀이 가득 차면 새 요청이 커넥션을 획득하지 못해 타임아웃이 발생하고, 이것이 5xx로 이어진다. 커넥션 풀 사용률을 모니터링하면 5xx가 발생하기 전에 문제를 감지할 수 있다.

Alert Fatigue: 너무 많은 알림의 문제

초기에 모니터링을 세팅할 때 보수적으로 임계치를 설정하여 많은 알림을 받았다. CPU 70% 이상, 응답시간 500ms 이상, 5xx 1건 이상 등 — 이렇게 하면 많은 알림이 발생하고, 대부분은 일시적인 변동이거나 서비스에 실질적 영향이 없는 경우였다.

알림이 너무 많으면 경보 피로가 발생한다. Slack 알림 채널에 수십 건의 알림이 쌓이면, 담당자는 알림을 읽지 않거나 자동으로 무시하게 된다. 이 상태에서 진짜 중요한 알림이 발생해도 묻혀버린다. ‘양치기 소년’ 효과다. 이것은 모니터링이 없는 것보다 더 위험할 수 있다 — 모니터링이 있다는 착각을 주기 때문이다.

알림의 계층화: 새벽 3시에 깨울 것 vs 아침에 확인할 것

alert fatigue를 해결하기 위해 알림을 계층화했다. P0(Critical): 서비스 전체가 다운되었거나, 결제가 불가능하거나, 데이터 유실이 발생하는 경우 — 새벽 3시에도 즉시 깨워야 한다. P1(High): 특정 기능의 에러율이 높거나, 성능이 심각하게 저하된 경우 — 새벽이면 아침까지 대기할 수 있지만, 업무 시간이면 즉시 대응. P2(Medium): 비정상적이지만 사용자 영향이 제한적인 경우 — 다음 업무일에 확인.

이 계층화를 도입한 후 실제로 의미 있는 알림에 집중할 수 있게 되었다. P0 알림은 극히 드물게 발생하므로 발생하면 즉시 주의를 기울이고, P2 알림은 별도 채널에서 모아서 확인하는 방식으로 운영했다. 중요한 것은 각 알림 레벨의 기준을 명확히 정의하고 팀 전체가 합의하는 것이었다.

에러 로그 패턴 분석

메트릭 기반 모니터링 외에, 에러 로그의 패턴을 분석하는 것도 유용했다. 특정 에러 메시지의 빈도 변화를 추적하면, 새 배포 후 발생하는 regression이나 외부 서비스의 장애를 감지할 수 있다. 예를 들어, PG(결제 게이트웨이)에서 반환하는 특정 에러 코드의 빈도가 급증하면 PG 쪽에 문제가 있다는 신호다.

로그 기반 알림은 메트릭 기반 알림보다 설정이 복잡하지만, 더 구체적인 문제를 감지할 수 있다. ‘5xx 에러 증가’보다 ‘결제 API에서 TimeoutException 증가’가 더 actionable한 알림이다. 담당자가 알림을 받았을 때 무엇을 해야 하는지 바로 알 수 있기 때문이다.

모니터링 대시보드 운영

알림 외에도, 일상적으로 확인하는 모니터링 대시보드를 운영했다. 대시보드에는 주요 서비스의 트래픽 추이, 에러율, 응답시간, 시스템 리소스 사용량 등이 시각화되어 있었다. 배포 후에는 이 대시보드를 주시하면서 새 버전의 동작을 확인했고, The Draw 등 고트래픽 이벤트 시에는 실시간으로 모니터링했다.

운영 안정성과 보안은 개별 도구의 문제가 아니라 개발 흐름과 운영 기준을 바꾸는 구조적 작업이었다. 다음 글에서는 2021 - 외부 장애가 내부 서비스로 전파되지 않게 막는 방법를 통해 이 흐름을 계속 좁혀 본다.

알림 설계의 장단점

알림 체계의 장점은 이상 징후를 조기에 포착해 대응 시간을 줄인다는 점이다. 그러나 신호를 과도하게 늘리면 노이즈가 증가해 실제 중요한 경보를 놓칠 수 있다. 결국 핵심은 지표 수가 아니라, 각 알림이 어떤 실행을 요구하는지 명확히 연결하는 것이다.

그래서 이 글에서의 기준은 “관측 가능성”과 “행동 가능성”의 균형이다. 대시보드와 알림이 분리되어 있으면 대응이 느려지고, 둘이 연결되어 있으면 장애 분류와 조치가 훨씬 빨라진다.

참고 자료

• Google SRE Book - Monitoring Distributed Systems 
• Prometheus Alerting Best Practices 
• OpenTelemetry Documentation 

알림 체계 설계 체크포인트

• 알림 기준은 인프라 지표가 아니라 사용자 영향 지표(SLI) 중심으로 구성한다.
• 동일 원인 알림은 상관관계 규칙으로 묶어 노이즈를 줄인다.
• 알림마다 담당자, 대응 런북, 종료 조건을 명시해 실행 가능성을 높인다.

신호 우선순위 표