4. LLM이 장애를 감지한다 — 알림 피로 끝내기

Prometheus가 "CPU 90%"라고 알려준다. 그런데 그게 배포 중 일시적 스파이크인지, 진짜 장애인지는 안 알려준다.

하루 200건의 알림 중 조치가 필요한 건 5건 미만인데, 나머지 195건을 일일이 확인하느라 정작 진짜 장애를 놓기도 한다. 1편에서 다뤘던 알림 피로다. 이번 편에서는 LLM으로 이 문제를 해결하는 방법을 설계한다.

임계값 알림의 세 가지 한계

현재 대부분의 팀이 쓰는 알림 방식은 이렇다.

CPU > 80%       → 알림
메모리 > 85%    → 알림
에러율 > 5%     → 알림
응답시간 > 3초   → 알림

간단하고 명확하다. 그런데 현실에서는 이런 일이 생긴다.

• 알림 피로. 배포 직후 5분간 CPU가 85%까지 올랐다가 내려온다. 정상인데 알림이 울린다. 새벽 배치 작업 때마다 메모리가 90%까지 올라간다. 매일 같은 시간에 같은 알림이 온다. 마이크로서비스 A가 재시작되면서 B, C, D에 일시적 에러가 발생한다. 알림 4개가 동시에 울리지만 원인은 하나다.
• 놓치는 장애. 평소 응답 시간이 0.05초인 API가 0.8초로 느려졌다. 16배 느려진 거다. 하지만 임계값(3초) 미만이라 알림이 안 울린다.
• 컨텍스트 부재. "CPU 90%"라는 알림만으로는 아무것도 할 수 없다. 어떤 프로세스가 먹고 있는지, 최근에 배포가 있었는지, 같은 시간에 다른 알림은 없는지 — 이 모든 맥락을 사람이 직접 수집해야 한다.

LLM에게는 알림 + 로그 + 최근 변경 이력을 한꺼번에 넣어줄 수 있다.

프롬프트 설계 — 나쁜 것에서 좋은 것으로

LLM에게 이상 탐지를 시키는 핵심은 프롬프트다. 같은 모델이라도 프롬프트에 따라 결과가 완전히 달라진다.

v1: 나쁜 프롬프트.

다음 로그에서 이상한 점을 찾아줘:
(로그)

이렇게 물어보면 LLM이 모든 줄을 "이상할 수도 있다"고 답하거나, 너무 일반적인 답을 한다. 기준이 없으니까.

v2: 정상 패턴을 알려준다.

다음은 이 서버의 정상적인 로그 패턴이다:
- 응답 시간: 0.01~0.15초
- 상태 코드: 200, 201이 95% 이상
- 에러율: 1% 미만
 
아래 로그에서 위 정상 패턴에서 벗어난 항목을 찾아줘.
각 항목에 대해 왜 비정상인지 설명해줘.
(로그)

정상 기준을 명시하면 판단이 훨씬 정확해진다. few-shot의 힘이다.

v3: 구조화된 출력을 요청한다.

당신은 24/7 서버 모니터링 시스템이다.
 
[정상 패턴]
- 응답 시간: 0.01~0.15초
- 상태 코드: 200, 201이 95% 이상
- 에러율: 1% 미만
- 로그 빈도: 분당 50~100건
 
[분석 대상 로그]
(로그)
 
반드시 아래 형식으로 답해라:
판정: [정상 / 주의 / 이상]
이상 항목:
- (시간) (내용) (이유)
심각도: [낮음 / 중간 / 높음 / 긴급]
추천 조치: (있으면)

출력 형식을 지정하면 파싱이 쉽고, 후속 자동화(Slack 알림, 에스컬레이션)에 연결하기 좋다. v1에서 v3으로 바꾸는 것만으로 정탐률이 극적으로 올라간다.

알림 상관관계 분석 — 15개를 1개로

서비스 하나가 죽으면, 의존하는 서비스들도 에러를 뿜는다. 5분 만에 알림이 15개 쏟아지는데, 원인은 하나다.

14:00:01  web-01   에러율 15%
14:00:02  web-02   에러율 12%
14:00:03  api-01   응답시간 5초
14:00:05  api-02   응답시간 4.5초
14:00:10  db-01    커넥션 풀 고갈
14:00:12  web-01   메모리 85%
14:00:15  cache-01 히트율 30% 이하

사람이라면 "DB 커넥션 풀이 고갈되면서 API가 느려지고, 웹 서버에 에러가 쌓인 거"라고 판단할 수 있다. LLM에게 이 알림 묶음을 JSON으로 넣고 "관련 있는 알림끼리 그룹으로 묶고, 추정 원인을 한 줄로 설명해줘"라고 요청하면 같은 추론을 해준다.

이게 핵심이다. 알림 200개를 사람이 보는 게 아니라, LLM이 "이건 하나의 장애고, 원인은 DB 쪽이고, 먼저 확인할 건 db-01이다"라고 정리해주는 거다.

실제로 이 알림 7개를 LLM에 JSON으로 넣고 "관련 알림끼리 그룹으로 묶고, 각 그룹의 추정 원인을 설명해줘"라고 요청하면 이런 답이 나온다.

[그룹 1] DB 커넥션 풀 고갈 → API 지연 → 웹 서버 에러 (7개 알림)
  추정 원인: db-01의 커넥션 풀 고갈이 근본 원인.
  인과관계: db-01 커넥션 풀 고갈(14:00:10) → api-01/02 응답 지연(14:00:03~05)
           → web-01/02/03 에러율 상승(14:00:01~20)
           → cache-01 히트율 하락(14:00:15, DB 쿼리 증가로 캐시 우회)
  먼저 확인: db-01의 커넥션 상태 (SELECT count(*) FROM pg_stat_activity)
  
[독립 알림] web-01 메모리 85%(14:00:12)
  추정: 에러 처리 과정에서 메모리 일시 증가. DB 문제 해결 시 자연 해소 예상.

7개 알림이 하나의 이야기로 정리됐다. 엔지니어는 "db-01부터 확인하자"라는 방향을 바로 잡을 수 있다. 이걸 사람이 7개 알림을 하나씩 보면서 인과관계를 파악하면 10분은 걸린다.

실시간 감시 구조

전체 흐름을 그림으로 그리면 이렇다.

[로그 스트림]                     [Prometheus 알림]
     │                                │
     ▼                                ▼
[10줄 단위 배치]              [알림 JSON 수집]
     │                                │
     └────────────┬───────────────────┘
                  │
                  ▼
            [LLM에 전달]
           ┌──────────────┐
           │  정상 패턴 +  │
           │  현재 데이터 + │
           │  v3 프롬프트   │
           └──────┬───────┘
                  │
                  ▼
            [판정: 정상/주의/이상]
                  │
        ┌─────────┼─────────┐
        │         │         │
     정상       주의       이상
        │         │         │
     패스     카운터 증가  Slack 알림 +
              연속 3회 시  상세 분석 요청
              → 이상 처리

경로 A와 B에서 이 구조가 약간 다르다.

경로 A. 10분 단위로 로그를 배치로 모아서 Claude API에 보낸다. API 호출 비용이 있으니 실시간보다는 주기적 배치가 현실적이다. 단순하고 정확하다.

경로 B. 로컬 모델이 상시 감시한다. 비용이 무제한이니 10줄 단위로 계속 분석할 수 있다. 다만 추론 지연이 있어서, 긴급한 알림은 기존 Prometheus 임계값 알림을 유지하고, LLM 감시는 "놓치는 장애"를 잡는 보완 역할로 쓰는 게 현실적이다.

실제로 이 구조를 운영하면 이런 흐름이 된다.

[시나리오: 배포 후 점진적 성능 저하]
 
14:00 배포 완료
14:15 응답 시간 0.05s → 0.12s (임계값 3초 미만, Prometheus 알림 없음)
14:30 응답 시간 0.25s (여전히 임계값 미만)
14:45 응답 시간 0.8s
 
기존 방식: 15:30쯤 누군가 "뭔가 느린 것 같은데?" → 그제야 조사 시작
 
LLM 감시:
14:30 감시 Agent 판정: "주의 — 응답 시간이 30분간 5배 증가.
      배포(14:00) 이후 선형 증가 패턴. 추세가 지속되면
      16:00경 임계값(3초) 도달 예상."
→ Slack 알림 전송 → 엔지니어가 14:35에 확인 시작

임계값에 도달하기 1시간 전에 잡는 거다. 이게 LLM 감시의 가치다. 숫자가 아니라 "추세"를 읽고, "배포 직후"라는 맥락을 결합해서 판단한다.

incident.io의 사례

SRE 전문 플랫폼 incident.io가 2025년에 출시한 AI SRE 기능이 이 구조와 같은 방향이다.

기존에 엔지니어가 Datadog, GitHub, Slack을 오가며 15분간 수동으로 하던 컨텍스트 수집을 LLM이 30초 만에 자동으로 한다. 배포와 에러 스파이크의 상관관계를 자동 식별하고, 200개 알림 대신 "의미 있는 3개 알림"만 보여준다. MTTR을 최대 80%까지 단축했다는 게 이들의 주장이다.

80%가 정확한 숫자인지는 모르겠다. 하지만 방향은 맞다. 알림 노이즈를 LLM이 필터링하고, 사람에게는 "지금 당장 봐야 할 것"만 전달하는 구조. 이게 알림 피로의 해법이다.

기존 모니터링과의 관계

한 가지 분명히 해두고 싶은 게 있다. LLM 기반 감지가 기존 Prometheus 알림을 대체하는 게 아니다.

Prometheus의 임계값 알림은 여전히 필요하다. "디스크 95%"같은 확실한 위험은 임계값으로 바로 잡아야 한다. 빠르고, 확실하고, LLM이 죽어도 동작한다.

LLM은 임계값으로 잡지 못하는 것을 보완한다. "평소보다 16배 느려졌지만 임계값 미만인 경우", "알림 15개가 실은 하나의 장애인 경우", "배포 직후라서 일시적인 스파이크인 경우." 이런 맥락 기반 판단이 LLM의 영역이다.

둘 다 쓰는 거다. 그리고 이 둘을 조합하는 구조가 1편에서 그린 "AIOps + LLM = 자율 SRE" 아키텍처다.

다음 편에서는 감지된 장애의 "왜?"를 다룬다. LLM에게 RCA(Root Cause Analysis)를 시키면 그럴듯한 답이 나온다. 그런데 가끔 존재하지 않는 파일을 원인으로 지목한다. 이 환각 문제를 어떻게 다루는지가 5편의 핵심이다.