작은 회사의 모니터링 — 무엇을 보고 무엇을 무시하는가

지표는 자산이 아니라 부채일 수 있다

모니터링 도구를 처음 붙이면 거의 모든 팀이 같은 실수를 한다. 수집할 수 있는 건 다 수집한다. CPU, 메모리, 디스크, 네트워크 I/O, 응답 시간, 에러율, DB 커넥션 수, JVM 힙, 스레드 수, GC pause time… 도구가 뱉어주는 숫자라면 일단 대시보드에 올린다. "나중에 필요할 수도 있으니까"라는 논리로.

문제는 이 시점부터 시작된다. 지표가 많아질수록 대시보드는 '그래프의 벽'이 되고, 각 선이 정상인지 비정상인지 판단할 기준이 없으면 그냥 노이즈의 집합이다. 알림도 마찬가지다. 임계치를 여기저기 걸어놓으면 알림이 자주 울리고, 자주 울리면 팀은 무감각해진다. 이른바 **알림 피로(alert fatigue)**다. 결국 중요한 알림도 "또 울었네" 하고 넘기게 된다.

결제·정산 운영에서 알림 피로가 특히 위험한 이유

일반적인 웹 서비스라면 알림을 늦게 확인해도 사용자 경험이 잠깐 나빠지는 수준에서 끝난다. 그런데 결제와 정산은 다르다. 에러 하나가 돈의 흐름에 직결되기 때문에, 장애를 늦게 인지하면 단순한 서비스 저하가 아니라 미처리 결제 누적, 정산 오차, 고객사 SLA 위반으로 이어진다.

우리 팀도 초기에 이 함정에 빠진 적이 있다. 알림 채널에 크고 작은 알림이 수십 건씩 쌓이다 보니 슬랙 채널 자체를 반쯤 무시하게 됐다. 그 시기에 정산 집계 잡(job)이 외부 API 타임아웃으로 30분 가까이 재시도를 반복하고 있었는데, 알림은 울리고 있었으나 "또 CPU 튀는 거겠지"로 넘겼다. 결국 해당 일자 정산 데이터가 일부 누락된 채로 배치가 완료됐고, 다음날 아침 수기로 재처리하는 데 팀 전체 오전을 썼다. 30분짜리 장애가 반나절짜리 복구 작업으로 번진 셈이다.

우리가 실제로 보는 지표 세 가지

그 사건 이후 모니터링 구조를 완전히 뒤집었다. 지금은 상시 알림 대상은 세 가지로 고정되어 있다.

첫째, 5xx 에러 비율. 개별 에러 로그를 보는 게 아니라 전체 요청 대비 5xx 응답의 비율을 본다. 우리 기준으로 1분 윈도우 기준 에러율 1% 초과 시 즉시 알림이 온다. 비율을 보는 이유는 트래픽 볼륨의 차이 때문이다. 새벽 2시에 에러 5건과 낮 12시에 에러 5건은 의미가 다르다. 절대치가 아니라 비율로 봐야 실질적인 이상을 잡을 수 있다.

둘째, 응답 지연 P95/P99. 평균(average) 응답 시간은 쓰지 않는다. 결제 API가 평균 200ms라도 P99가 8초라면, 100명 중 1명은 8초를 기다리고 있다는 뜻이다. 결제 플로우에서 8초는 사용자가 '결제가 안 됐다'고 판단하고 창을 닫는 시간이다. 현재 우리 기준은 P95 기준 2초 초과 시 경고, P99 기준 5초 초과 시 즉시 대응이다. 숫자는 서비스 특성마다 다르겠지만 분위수(percentile) 기반으로 정하는 것 자체가 핵심이다.

셋째, 디스크 사용량. 이건 성격이 다른 지표다. CPU나 메모리는 순간 치솟아도 자동으로 내려오는 경우가 많다. 디스크는 다르다. 꽉 차면 로그가 안 쌓이고, 로그가 안 쌓이면 트랜잭션 기록 자체가 날아갈 수 있다. 정산 시스템에서 트랜잭션 로그 손실은 말 그대로 돈이 어디 갔는지 모르는 상황이다. 80% 도달 시 경고, 90% 도달 시 즉시 대응. 자동화 배치 서버는 로그가 주기적으로 쌓이기 때문에 특히 이 지표를 빠뜨리지 않는다.

끊어낸 지표들과 그 이유

반대로 상시 알림에서 제거한 것들을 정리하면 훨씬 많다.

CPU 사용률은 알림에서 뺐다. 배치 작업, GC, 암호화 연산이 돌 때마다 스파이크가 생기고 대부분 2-3분 안에 내려간다. 우리 경험상 CPU 알림이 실제 장애로 이어진 비율은 전체의 10% 미만이었다. 나머지 90%는 오탐이었고, 그 오탐 90%가 알림 피로를 만들었다. 지금은 CPU는 대시보드에서 육안으로 추이를 보는 용도로만 쓴다.

JVM 힙, 스레드 수, DB 커넥션 수도 상시 알림에서 제외했다. 이 지표들은 트러블슈팅 중에는 매우 유용하다. 문제가 생겼을 때 원인을 파고드는 도구로는 필수다. 그러나 맥락 없이 숫자만 봐서는 "힙이 70%인데 이게 나쁜 건가?" 판단하기 어렵다. 이런 지표들은 장애 발생 후 사후 분석(postmortem)에서 사용하고, 평상시에는 보지 않기로 했다.

알림 설계의 단 하나의 기준

알림 설계에서 우리가 채택한 원칙은 하나다: 알림을 받았을 때 즉각 행동해야 하는 것만 알림으로 설정한다.

"이상하네, 조금 지켜봐야겠다"는 알림이 아니다. 그 수준이라면 주기적으로 대시보드를 확인하거나, 별도 리포트로 처리한다. 알림은 오직 "지금 당장 누군가 이것을 봐야 한다"는 상황에만 발동해야 한다. 이 기준을 적용하고 나서 슬랙 알림 채널의 일일 알림 건수가 평균 40건 이상에서 5건 미만으로 줄었다. 그리고 알림이 오면 팀 전체가 실제로 본다. 알림의 신뢰도가 올라간 것이다.

추가로, 알림 자체에도 심각도 계층을 만들었다. PagerDuty 류의 온콜 호출은 진짜 서비스 중단 수준에서만 쓰고, 경고 레벨은 슬랙 스레드로만 보낸다. 새벽 3시에 온콜을 깨우는 알림과 출근해서 확인하면 되는 알림을 같은 채널에 섞으면, 온콜도 결국 무뎌진다.

HEDVION 팀이라면 이렇게 적용한다 — 정산 자동화 시나리오

구체적인 시나리오로 정리해보자. 우리가 운영하는 자동화 정산 파이프라인을 예로 들면, 모니터링 포인트는 다음처럼 설계되어 있다.

• 정산 배치 잡 성공 여부: 잡이 완료됐는지 여부 자체를 헬스체크로 본다. 30분 내 완료되지 않으면 알림. 잡 서버의 CPU/메모리가 아니라 "잡이 제때 끝났는가"가 핵심이다.
• 외부 PG사 API 에러율: PG사 API를 호출하는 컴포넌트에서 5xx 또는 타임아웃 비율이 임계치를 넘으면 즉시 알림. 외부 의존성의 에러율이 올라가는 건 내부 자원 지표로는 잡을 수 없다.
• 정산 금액 이상 감지: 이건 인프라 지표가 아니라 비즈니스 지표다. 직전 동 시간대 대비 정산 총액이 일정 비율 이상 튀거나 급감하면 알림이 온다. 시스템은 정상으로 보이지만 데이터가 이상한 케이스를 이 방식으로 잡는다.

이 세 가지는 전부 "행동이 필요한 알림"이다. 시스템이 살아있는지를 넘어서, 비즈니스가 정상적으로 돌아가는지를 보는 것이 결제·정산 모니터링의 본질이다.

지금 당장 써먹을 수 있는 시사점

장황한 정리 없이, 팀에 돌아가서 바로 적용할 수 있는 액션을 순서대로 나열한다.

1. 지금 설정된 알림 목록을 꺼내서 각 항목에 "이게 울리면 내가 뭘 하나?"를 적어라. 즉각적인 행동 시나리오가 없는 알림은 비활성화하거나 대시보드 전용으로 강등시킨다.

2. 평균 응답 시간 알림을 P95 또는 P99 기반으로 교체한다. 설정 한 줄 바꾸는 일이지만, 잡아내는 이상의 종류가 달라진다.

3. 디스크 사용량에 80%/90% 이중 임계치를 설정한다. 특히 로그를 로컬에 쌓는 배치 서버에서 이걸 빠뜨리면 언젠가 반드시 데인다.

4. 인프라 지표 외에 비즈니스 지표 하나를 모니터링 대상에 추가한다. 결제라면 에러율 외에 "단위 시간당 결제 성공 건수", 정산이라면 "배치 완료 여부"가 될 수 있다. 시스템 지표가 모두 정상이어도 비즈니스 지표가 이상할 수 있다.

5. 알림 채널을 심각도별로 분리한다. 온콜 호출, 슬랙 경고, 이메일 리포트 세 계층으로 나누는 것만으로도 알림 피로가 크게 줄어든다.

모니터링의 목적은 많이 수집하는 것이 아니라, 중요한 것을 빠르게 발견하는 것이다. 그리고 그 "중요함"의 정의는 인프라 지표가 아니라 서비스가 만들어내는 결과 — 결제가 됐는가, 정산이 맞는가, 돈이 제대로 움직이는가 — 에서 시작해야 한다.