대시보드 그만 만드세요: 알람이 먼저인 모니터링 철학

모니터링, 진짜 문제는 대시보드가 아니에요

혹시 이런 경험 있으세요? 새 서비스를 배포하면서 그라파나(Grafana) 대시보드를 멋지게 꾸며요. CPU 사용률, 메모리, 요청 수, 응답 시간까지 색깔별로 예쁘게 그려놓죠. 그런데 막상 새벽에 장애가 터지면 그 대시보드는 아무도 안 봐요. 슬랙 알람이 울리고 나서야 부랴부랴 로그를 뒤지고, 대시보드는 그냥 "있긴 있는" 장식품이 되어버리는 경우가 정말 많거든요.

최근에 화제가 된 "Alert-driven monitoring(알람 주도 모니터링)"이라는 글이 바로 이 지점을 정확히 짚어요. 모니터링을 설계할 때 대시보드부터 만들지 말고, 알람부터 정의하라는 거예요. 얼핏 들으면 당연한 말 같은데, 실제로 우리가 일하는 방식을 돌아보면 거의 정반대로 하고 있다는 걸 깨닫게 됩니다.

기존 방식이 왜 잘못됐냐면

전통적인 모니터링 도입 순서를 한번 떠올려 볼게요. 보통 이렇게 흘러가요. 먼저 메트릭(metric, 측정값)을 닥치는 대로 수집해요. 프로메테우스(Prometheus) 같은 도구로 가능한 한 많은 지표를 긁어모으죠. 그다음에 그걸 바탕으로 대시보드를 만들어요. "음, 이 그래프도 있으면 좋겠고, 저 패널도 추가해야지" 하면서요. 그리고 마지막에 가서야 "아, 알람도 걸어야지" 하고 임계값을 대충 정해서 알람을 추가합니다.

이 순서의 문제가 뭐냐면, 노이즈가 너무 많다는 거예요. 수집한 메트릭의 90%는 평소엔 아무도 안 보고, 장애가 터져도 별 도움이 안 돼요. 그리고 알람이 나중에 붙다 보니 "왜 이 알람이 울렸지?"라고 물었을 때 명확한 답이 없어요. 그냥 "CPU가 80% 넘으면 위험하니까" 같은 막연한 이유로 설정된 거죠. 결국 알람은 자주 울리는데 정작 진짜 장애는 놓치는 상황이 반복돼요. 이걸 업계에서는 알람 피로도(alert fatigue)라고 부르는데요, 너무 많은 알람에 시달리다 보면 진짜 중요한 알람도 무시하게 되는 현상이에요.

알람 주도 모니터링은 뭐가 다른가

알람 주도 모니터링은 순서를 완전히 뒤집어요. 가장 먼저 묻는 질문이 이거예요. "우리 서비스에서 사용자에게 영향을 주는 일이 벌어졌을 때, 그걸 어떻게 알아챌 것인가?" 이 질문에서 출발해서 알람을 먼저 정의하고, 그 알람이 정확하게 동작하는 데 필요한 메트릭만 수집하고, 알람이 울렸을 때 디버깅에 도움 되는 정보만 대시보드에 담는 거죠.

예를 들어볼게요. 결제 서비스를 운영한다고 쳐요. 알람 주도 방식이라면 먼저 "결제 실패율이 5%를 넘으면 사용자가 돈을 못 내고 있다는 뜻이니 즉시 알아야 한다"라는 알람을 정의해요. 그러면 이 알람을 위해 필요한 메트릭은 자연스럽게 정해져요. 결제 시도 수, 결제 성공 수, 결제 실패 수, 그리고 실패 사유별 분류 정도가 되겠죠. 대시보드에는 이 알람이 울렸을 때 "어떤 결제 수단에서, 어느 지역에서, 어떤 에러로 실패하고 있는지"를 빠르게 파악할 수 있는 패널을 둡니다. 모든 게 한 줄기로 연결돼요.

이 접근법의 핵심 원칙은 보통 SLO(Service Level Objective, 서비스 수준 목표)와 짝을 이루는 경우가 많아요. 구글의 SRE(Site Reliability Engineering) 책에서 강조한 것처럼, "99.9% 가용성을 보장한다" 같은 약속을 먼저 정하고, 그 약속이 깨질 위험이 있을 때만 알람이 울리도록 설계하는 거죠. 그러면 알람 하나하나에 명확한 비즈니스적 의미가 생겨요.

비슷한 흐름들과 비교해보면

사실 이 철학이 완전히 새로운 건 아니에요. 구글의 SRE 책에서 이야기한 "증상 기반 알람(symptom-based alerting)"이나 마이크 줄리언이 쓴 "Practical Monitoring" 같은 책에서도 비슷한 주장을 해왔거든요. 데이터독(Datadog), 뉴렐릭(New Relic) 같은 상용 모니터링 도구들도 최근엔 이런 방향으로 기능을 다듬고 있어요.

다만 알람 주도 모니터링이 좀 더 강하게 미는 부분은 "필요 없는 메트릭은 아예 수집하지 마라"라는 점이에요. 메트릭을 많이 수집할수록 저장 비용도 늘고, 카디널리티(cardinality, 고유한 값의 가짓수) 폭발로 시스템이 느려지기도 하거든요. 특히 쿠버네티스 환경에서 파드(Pod)가 자주 생기고 사라지면 라벨이 무한정 늘어나서 프로메테우스가 메모리를 다 잡아먹는 일도 흔해요. 알람에 필요한 것만 수집하면 이런 비용도 자연스럽게 줄어듭니다.

OpenTelemetry 같은 표준이 자리잡으면서 메트릭, 로그, 트레이스를 한 번에 다루는 흐름이 강해지고 있는데요, 이런 환경에서 "뭘 수집할지"를 결정하는 기준으로 알람 주도 방식은 꽤 강력한 가이드라인이 됩니다.

한국 개발자에게는 어떤 의미일까

국내 스타트업이나 중견 IT 기업에서 일하는 분들이라면 이 철학이 당장 와닿을 거예요. 많은 팀이 모니터링 도구를 도입했지만 실제로는 "알람이 너무 많아서 다 끄거나, 알람이 너무 없어서 장애를 뒤늦게 알게 되는" 양극단 사이를 오가거든요. 알람 주도 모니터링은 이 사이에서 균형을 잡는 실용적인 방법론이에요.

특히 작은 팀일수록 더 효과적이에요. 인력이 부족한 팀이 화려한 대시보드 수십 개를 유지하는 건 사실상 불가능하잖아요. 그럴 바엔 "진짜 사용자에게 영향을 주는 5~10개 알람"만 정확하게 잡고, 나머지는 과감히 버리는 게 훨씬 운영하기 편해요. 새 서비스를 만들 때부터 "이 서비스가 망가졌다는 걸 어떻게 알아챌 것인가?"를 먼저 적어보고 시작하는 습관, 한 번 들여볼 만합니다.

마무리

결국 핵심은 이거예요. 모니터링의 목적은 예쁜 그래프가 아니라, 문제를 빨리 알아채고 빨리 고치는 것. 대시보드와 메트릭은 그 목적을 위한 도구일 뿐이고요. 여러분 팀의 모니터링은 어떤가요? 알람이 울렸을 때 그 알람이 "왜" 울렸는지 모두가 명확하게 답할 수 있나요? 아니면 그냥 "임계값 넘었으니까" 정도로 끝나고 있나요?