AI Agent 모니터링 및 운영
이 문서에서는 Agentic AI 애플리케이션의 모니터링 아키텍처, 핵심 메트릭 설계, 알림 전략을 개념 수준에서 다룹니다.
Langfuse Helm 배포, AMP/AMG 구성, ServiceMonitor YAML, Grafana 대시보드 JSON 등 실전 구성은 모니터링 스택 구성 가이드를 참조하세요.
1. 개요
Agentic AI 애플리케이션은 복잡한 추론 체인과 다양한 도구 호출을 수행하기 때문에, 전통적인 APM(Application Performance Monitoring) 도구만으로는 충분한 가시성을 확보하기 어렵습니다. LLM 특화 관측성 도구인 Langfuse와 LangSmith는 다음과 같은 핵심 기능을 제공합니다:
- 트레이스 추적: LLM 호출, 도구 실행, 에이전트 추론 과정의 전체 흐름 추적
- 토큰 사용량 분석: 입력/출력 토큰 수 및 비용 계산
- 품질 평가: 응답 품질 점수화 및 피드백 수집
- 디버깅: 프롬프트 및 응답 내용 검토를 통한 문제 진단
이 문서는 플랫폼 운영자, MLOps 엔지니어, AI 개발자를 대상으로 합니다. Kubernetes와 Python에 대한 기본적인 이해가 필요합니다.
2. 모니터링 아키텍처
Langfuse 아키텍처 개요
Langfuse v3 (2024-12+)는 다음 컴포넌트로 구성됩니다. v3는 ClickHouse+Redis+S3 아키텍처로, v2 대비 셀프호스팅 복잡도가 증가했습니다:
AMP/AMG 통합 데이터 흐름
모니터링 데이터 계층
| 계층 | 수집 도구 | 메트릭 패턴 | 확인 가능 항목 |
|---|---|---|---|
| LLM 추론 | Langfuse | trace, generation | 토큰 사용량, 비용, TTFT, 사용자별 패턴 |
| 모델 서버 | vLLM Prometheus | vllm_* | 요청 수, 배치 크기, KV cache 사용률, TPS |
| GPU | DCGM Exporter | DCGM_FI_DEV_* | GPU 활용도, 온도, 전력, 메모리 사용량 |
| 인프라 | Node Exporter | node_* | CPU, 메모리, 네트워크, 디스크 I/O |
| 게이트웨이 | kgateway | envoy_* | 요청 수, 지연 시간, 에러율, 업스트림 상태 |
3. 핵심 모니터링 메트릭
Agentic AI 애플리케이션에서 추적해야 할 핵심 메트릭을 정의합니다.
메트릭 카테고리
Latency 메트릭
| 메트릭 | 설명 | 목표값 | 알림 임계값 |
|---|---|---|---|
| agent_request_duration_seconds | 전체 요청 처리 시간 | P95 < 5s | P99 > 10s |
| llm_inference_duration_seconds | LLM 추론 시간 | P95 < 3s | P99 > 8s |
| tool_execution_duration_seconds | 도구 실행 시간 | P95 < 1s | P99 > 3s |
| vector_search_duration_seconds | 벡터 검색 시간 | P95 < 200ms | P99 > 500ms |
Token Usage 메트릭
| 메트릭 | 설명 | 모니터링 목적 |
|---|---|---|
| llm_input_tokens_total | 입력 토큰 총합 | 프롬프트 최적화 |
| llm_output_tokens_total | 출력 토큰 총합 | 응답 길이 분석 |
| llm_total_tokens_total | 전체 토큰 총합 | 비용 추적 |
| llm_cost_dollars_total | 추정 비용 (USD) | 예산 관리 |
Error Rate 메트릭
| 메트릭 | 설명 | 알림 임계값 |
|---|---|---|
| agent_errors_total | 에이전트 오류 총합 | 오류율 > 5% |
| llm_rate_limit_errors_total | Rate Limit 오류 | 분당 10회 이상 |
| tool_execution_errors_total | 도구 실행 오류 | 오류율 > 10% |
| agent_timeout_total | 타임아웃 발생 | 분당 5회 이상 |
4. PromQL 쿼리 레퍼런스
GPU 메트릭
# 전체 GPU 평균 활용도
avg(DCGM_FI_DEV_GPU_UTIL)
# 노드별 GPU 활용도
avg(DCGM_FI_DEV_GPU_UTIL) by (Hostname)
# GPU 메모리 사용률
avg(DCGM_FI_DEV_FB_USED / DCGM_FI_DEV_FB_FREE * 100) by (gpu)
vLLM 메트릭
# 전체 TPS (초당 생성 토큰)
rate(vllm_generation_tokens_total[5m])
# 모델별 TPS
sum(rate(vllm_generation_tokens_total[5m])) by (model)
# TTFT P99 (Time to First Token)
histogram_quantile(0.99, rate(vllm:time_to_first_token_seconds_bucket[5m]))
# TTFT P95
histogram_quantile(0.95, rate(vllm:time_to_first_token_seconds_bucket[5m]))
# E2E 지연 P99
histogram_quantile(0.99, rate(vllm_e2e_request_latency_seconds_bucket[5m]))
# 배치 크기 평균
avg(vllm_num_requests_running)
Gateway 메트릭
# 5xx 에러율 (%)
rate(envoy_http_downstream_rq_xx{envoy_response_code_class="5"}[5m])
/
rate(envoy_http_downstream_rq_total[5m]) * 100
# 업스트림 헬스 체크 실패율
sum(rate(envoy_cluster_upstream_cx_connect_fail[5m])) by (envoy_cluster_name)
비용 메트릭
# 일별 총 비용
sum(increase(llm_cost_dollars_total[24h]))
# 테넌트별 일별 비용
sum(increase(llm_cost_dollars_total[24h])) by (tenant_id)
# 모델별 비용 비율
sum(increase(llm_cost_dollars_total[24h])) by (model)
/ ignoring(model) group_left
sum(increase(llm_cost_dollars_total[24h]))
# 예산 대비 사용률 (월간)
sum(increase(llm_cost_dollars_total[30d])) by (tenant_id)
/ on(tenant_id) group_left
tenant_monthly_budget_usd
5. 알림 전략
알림 임계값 설계
| 알림 | 조건 | 심각도 | 지속 시간 |
|---|---|---|---|
| Agent High Latency | P99 지연 > 10초 | Warning | 5분 |
| Agent High Error Rate | 에러율 > 5% | Critical | 5분 |
| LLM Rate Limit | Rate limit 에러 > 10건/5분 | Warning | 2분 |
| Daily Cost Budget | 일일 비용 > $100 | Warning | 즉시 |
| GPU High Temperature | GPU 온도 > 85도 | Warning | 5분 |
| GPU Memory Full | GPU 메모리 > 95% | Critical | 3분 |
| vLLM High Latency | P99 E2E 지연 > 30초 | Warning | 5분 |
알림 계층 구조
- 인프라 계층: GPU 온도, 메모리, 전력 이상
- 모델 서버 계층: vLLM 지연 증가, KV cache 부족
- 애플리케이션 계층: Agent 에러율, Rate limit
- 비즈니스 계층: 비용 초과, SLA 위반
- 계층별 메트릭 연결: LLM 요청이 늘면 GPU 활용도가 오르고 인프라 부하가 커지는 상관관계를 분석
- 이상 탐지: P99 지연이 갑자기 증가하면 GPU 온도나 메모리 사용량 동시 확인
- 용량 계획: 평균 GPU 활용도가 70% 이상이면 추가 GPU 노드 프로비저닝 고려
- 비용 최적화: TTFT가 낮은 모델을 우선 사용하여 사용자 경험 개선 + 처리량 증가
6. Cascade Fallback 전략
Self-hosted 모델(vLLM/llm-d)이 과부하이거나 장애일 때, Amazon Bedrock의 관리형 모델로 자동 폴백하는 Cascade Routing을 구성하면 GPU 장애·Spot 중단 시에도 무중단 서비스를 유지할 수 있습니다. Bifrost(또는 LiteLLM)가 Gateway 역할을 하며, 응답 실패·타임아웃 시 Bedrock으로 요청을 전환합니다.
Fallback 조건 설정
Bifrost는 요청 본문의 fallbacks 배열과 governance routing_rules(CEL 표현식 + weighted targets)로 폴백을 구성합니다. 폴백 트리거는 5xx/429 등 재시도 가능한 에러로 하드코딩되어 있습니다(status code/latency/error-rate 기반 조건부 폴백은 2026-05 기준 feature request, issue #3261).
# bifrost Helm values - governance routing_rules 예시
routing_rules:
- name: cost-optimized-cascade
match: "request.model == 'qwen3-32b'"
targets:
- provider: "self-hosted"
model: "qwen3-32b"
weight: 80
- provider: "bedrock"
model: "claude-sonnet"
weight: 20
fallbacks:
- "bedrock/claude-sonnet" # 순서대로 시도
가용성·비용 관점 비교
| 관점 | Self-hosted 단독 | Cascade (Self-hosted + Bedrock) |
|---|---|---|
| 가용성 | GPU 장애 시 서비스 중단 | Bedrock 폴백으로 무중단 |
| 비용 | GPU 고정 비용 | 평시 Self-hosted(저비용) + 피크 Bedrock(종량제) |
| 용량 계획 | 피크 트래픽 기준 GPU 확보 | 기본 트래픽만 GPU, 초과분 Bedrock |
| Cold Start | Spot 중단 시 수 분 지연 | Bedrock 즉시 응답 |
평시 트래픽의 80%를 Self-hosted로 처리하고 피크 시 20%를 Bedrock으로 오프로드하는 하이브리드 패턴은 GPU를 피크 기준으로 프로비저닝할 필요를 줄입니다. 실제 절감률은 트래픽 패턴에 따라 크게 달라지며(제3자 추정 30-70%), 일반화는 어렵습니다.
온프레미스 GPU 팜까지 포함한 3-Tier Cascade(On-Prem → Cloud → Bedrock) 구성은 하이브리드 GPU 워크로드와 SR-IOV 네트워킹, Gateway 레벨 라우팅 튜닝은 Cascade 라우팅 튜닝을 참조하세요.
7. 비용 추적
비용 추적 개념
본 섹션은 비용의 관측(Observation) — 메트릭 수집·PromQL 쿼리·대시보드 — 을 다룹니다. 관측된 비용을 테넌트에 배부(showback/chargeback) 하는 방법론과 예산 정책 설계는 LLM FinOps — Chargeback 및 비용 배부를 참조하고, 게이트웨이 레벨 예산 강제는 AI Gateway 멀티테넌시를 참조하세요.
LLM 사용 비용을 다음 기준으로 추적합니다:
- 모델별: 모델별 총 비용 및 요청 수, 가장 비용이 높은 모델 식별
- 테넌트별: 테넌트/팀별 일일 토큰 사용량 및 예산 대비 사용률
- 시간별: 피크 시간대 분석, 비용 추세
모델별 비용 참조 (2026-04 기준)1
| Tier | 모델 | 입력 ($/1M tok) | 출력 ($/1M tok) | 특징 |
|---|---|---|---|---|
| Frontier | Claude Opus 4.7 / 4.8 | $5 | $25 | 최고 품질 추론 |
| Frontier | GPT-4.1 / o3 | $2 | $8 | 복잡한 reasoning (o3는 2025-06 80% 인하, GPT-5로 승계) |
| Frontier | Gemini 2.5 Pro | $1.25 | $5 | 멀티모달 강화 |
| Balanced | Claude Sonnet 4.6 | $3 | $15 | 품질-비용 균형 |
| Balanced | GPT-4.1 mini | $0.40 | $1.60 | 빠른 추론 |
| Balanced | Gemini 2.5 Flash | $0.10 | $0.40 | 높은 처리량 |
| Fast/Cheap | Claude Haiku 4.5 | $0.80 | $4 | 간단한 작업 |
| Fast/Cheap | GPT-4.1 nano / o4-mini | $0.15 | $0.60 | 초저비용 |
| Fast/Cheap | Gemini 2.5 Flash-Lite | $0.05 | $0.20 | 최소 지연 |
| Open-weight | DeepSeek V3.1 | Self-hosted | Self-hosted | 오픈 라이선스 |
| Open-weight | Llama 4 Scout | Self-hosted | Self-hosted | Meta 공식 |
| Open-weight | Qwen3-32B | Self-hosted | Self-hosted | Alibaba Cloud (Qwen3 최대 dense 모델) |
- 모델 선택 최적화: 간단한 작업에는 저렴한 모델(GPT-4.1 nano, Haiku 4.5, Gemini 2.5 Flash-Lite) 사용
- 프롬프트 최적화: 불필요한 컨텍스트 제거로 입력 토큰 절감
- 캐싱 활용: 반복적인 쿼리에 대한 응답 캐싱 (Prompt Caching, Semantic Caching)
- Cascade Routing: 저비용 모델 우선 시도 후 실패 시 고성능 모델로 Fallback — 66% 비용 절감 가능
- Open-weight 모델: 자체 호스팅 시 DeepSeek V3.1, Llama 4, Qwen3로 고정 비용 전환
8. 운영 체크리스트
일일 점검 항목
| 점검 항목 | 확인 방법 | 정상 기준 |
|---|---|---|
| GPU 상태 | `kubectl get nodes -l nvidia.com/gpu.present=true` | 모든 노드 Ready |
| 모델 Pod | `kubectl get pods -n inference` | Running 상태 |
| 에러율 | Grafana 대시보드 | < 1% |
| 응답 시간 | P99 레이턴시 | < 5초 |
| GPU 사용률 | DCGM 메트릭 | 40-80% |
| 메모리 사용 | GPU 메모리 | < 90% |
주간 점검 항목
| 점검 항목 | 확인 방법 | 조치 사항 |
|---|---|---|
| 비용 분석 | Kubecost 리포트 | 이상 비용 식별 |
| 용량 계획 | 리소스 트렌드 | 스케일링 계획 |
| 보안 패치 | 이미지 스캔 | 취약점 패치 |
| 백업 검증 | 복구 테스트 | 백업 정책 확인 |
9. 모니터링 성숙도 모델
10. 다음 단계
- 모니터링 스택 구성 가이드 - AMP/AMG 배포, Langfuse Helm 설치, ServiceMonitor, Grafana 대시보드 실전 구성
- LLMOps Observability 비교 가이드 - Langfuse vs LangSmith vs Helicone 심층 비교
- Agentic AI Platform 아키텍처 - 전체 플랫폼 설계
- RAG 평가 프레임워크 - Ragas를 활용한 품질 평가
참고 자료
- Langfuse Documentation
- LangSmith Documentation
- CloudWatch Generative AI Observability
- OpenTelemetry Documentation
- Prometheus Monitoring