[LLM Observability] Day 4: 알람과 이상 탐지 - LLM 응답 품질 저하 신호 감지

서론: 무엇이 달라졌는지 알아야 알림을 보낼 수 있다

인프라 알람은 임계값이 명확하다. CPU 90% 초과, 에러율 1% 초과. LLM 품질 알람은 다르다. “응답이 나빠졌다”는 신호는 지연이나 에러율에 나타나지 않고, 여러 간접 지표가 복합적으로 변할 때 드러난다.

1. 알람 대상 지표 계층

LLM 시스템의 알람은 세 계층으로 구분한다.

1.1 인프라 계층 (즉각 알람 가능)

• p99 지연 > SLO 임계값
• 에러율 > 임계값
• 토큰 사용량 급증 (비용 이상)

1.2 파이프라인 계층

• guardrail 차단률 급변 (인젝션 공격 징후 또는 과도한 필터링)
• RAG retrieval 히트율 급락 (인덱스 상태 이상)
• 툴 호출 실패율 상승

1.3 품질 계층 (더 복잡한 신호)

• LLM-as-Judge 평균 점수 하락
• 재질의율 / 이탈률 이상 증가
• finish_reason=length 비율 급증 (컨텍스트 부족 징후)
• 특정 응답 패턴의 빈도 이상 (예: 모델이 특정 거부 문구를 반복하는 현상)

2. 이상 탐지 전략

2.1 정적 임계값

빠르고 단순하다. 인프라 계층에 적합하다.

alert if error_rate > 0.01 for 5m

2.2 동적 기준선 (Seasonal Baseline)

트래픽은 시간대·요일마다 패턴이 다르다. 절대값이 아니라 “과거 같은 시간대 대비 편차”로 알람을 만든다.

alert if metric > baseline(7d_avg) * 1.5

2.3 다변량 이상 탐지

단일 지표가 아니라 여러 지표가 동시에 변할 때 이상으로 판단한다. 예를 들어 지연은 정상이지만 재질의율과 LLM 점수가 함께 하락하는 경우다.

간단한 구현은 지표 Z-score 조합을 사용하는 것이다.

3. 알람 설계 원칙

3.1 오탐률 관리

LLM 알람은 오탐이 많으면 팀이 알림 피로로 무감각해진다.

• 신규 알람은 먼저 실루엣(silent alert)으로 배포한다
• 2주 이상 오탐/누락 패턴을 관찰 후 임계값을 튜닝한다
• 알람 발화 횟수 자체를 지표로 추적한다

3.2 알람 계층화

심각도	대응
Critical	즉시 대응 (PD/Opsgenie)
Warning	Slack 채널 알림, 업무 시간 내 대응
Info	대시보드 기록만

LLM 품질 신호는 대개 Warning/Info로 시작해 Critical로 격상하는 경우가 드물다.

4. 배포 연계 알람

모델/프롬프트/인덱스 변경 직후에는 알람 민감도를 높인다.

Deployment Event -> Alert Sensitivity Window (30~60분)
  -> 품질 지표 집중 모니터링
  -> 이상 감지 시 자동 롤백 트리거 (선택적)

변경 사항과 품질 하락이 시간적으로 겹치면 배포가 원인일 가능성이 높다.

5. 운영 관측 지표

• 알람 발화 건수 / 월 (팀당 소화 가능 범위 유지)
• 알람-실제 장애 상관률 (알람 정밀도)
• MTTD (Mean Time to Detect) 추이
• 품질 이상 → 배포 원인 식별 소요 시간

6. Day 4 체크리스트

1. 인프라/파이프라인/품질 계층별 알람 지표를 정의했다.
2. 신규 알람을 silent alert으로 먼저 배포해 오탐률을 측정했다.
3. 배포 이벤트 후 품질 지표 민감도 강화 윈도우를 설정했다.
4. 알람 피로도 방지를 위해 발화 횟수를 지표로 추적한다.

다음 글 예고

Day 5에서는 LLM 관측성 플랫폼 설계를 다룬다. 로그·트레이스·메트릭·평가 체계를 하나의 운영 성숙도 로드맵으로 통합하는 방법을 정리한다.