지표가 많아도 액션이 없으면 의미가 없습니다.
알림은 “누가 언제 무엇을 할지”까지 포함해야 합니다.
핵심 메트릭 세트
| 카테고리 | 메트릭 | 목적 |
|---|
| 품질 | task success, groundedness | 사용자 성과 추적 |
| 안정성 | error rate, timeout rate | 장애 조기 감지 |
| 성능 | p50/p95 latency | SLA 관리 |
| 비용 | cost/request, token/request | 비용 통제 |
| 안전 | policy violation rate | 규정 준수 |
알림 설계 예시
| 조건 | 심각도 | 대응 |
|---|
| p95 latency 15분 연속 상승 | 중 | 온콜 확인, 모델 라우팅 점검 |
| error rate 급증 | 상 | 트래픽 제한, 롤백 검토 |
| policy violation 증가 | 상 | 해당 기능 임시 차단, 원인 분석 |
| cost/request 급등 | 중 | 캐시/모델 라우팅 재조정 |
알림 피로 줄이기
- 단일 요청 실패는 알림에서 제외
- 5~15분 집계 윈도우로 노이즈 완화
- 같은 원인의 중복 알림은 묶어서 발송
- 알림마다 런북 링크를 포함
Langfuse에서 바로 보는 운영 화면
1) 대시보드에서 지연/비용 추세를 확인합니다
- 기본 대시보드에서 latency/cost/usage를 먼저 확인합니다.
- 실험 배포 직후에는
updated at 기준으로 최신 대시보드를 우선 점검합니다.
2) Spend alerts로 비용 알림 정책을 운영합니다
- 조직 설정의 Spend alerts에서 임계값을 설정합니다.
- 월간 상한 + 단기 급등(일/시간) 알림을 함께 둡니다.
알림 조건은 분기마다 재조정합니다.
트래픽 규모가 바뀌면 임계값도 함께 바꿔야 합니다.
실무 적용 체크리스트
자주 나는 실수
- 기준 지표 없이 개선을 선언합니다.
- 한 번에 여러 변수를 바꿔 원인 추적이 불가능해집니다.
- 롤백 조건 없이 배포해 장애 복구가 늦어집니다.
다음 문서
다음: 비용 모니터링
학습 흐름을 이어서 진행합니다.
