왜 모니터링이 중요한가요?
모델을 학습하고 배포하는 것은 ML 라이프사이클의 시작 에 불과합니다. 프로덕션 환경에서 모델은 다양한 이유로 성능이 저하될 수 있습니다.- 데이터 드리프트(Data Drift): 실제 입력 데이터의 분포가 학습 데이터와 달라집니다
- 모델 성능 저하: 시간이 지나면서 예측 정확도가 떨어집니다
- 인프라 장애: 지연 시간 증가, 에러율 상승, 리소스 부족 등이 발생합니다
- 비용 폭증: 예상치 못한 트래픽 증가로 비용이 급격히 올라갑니다
💡 MLOps의 핵심 원칙: “모니터링 없는 모델 배포는, 계기판 없이 비행기를 조종하는 것과 같습니다.” 모니터링은 모델의 건강 상태를 지속적으로 확인하고, 문제를 조기에 발견하여 대응할 수 있게 해줍니다.
프로덕션 ML 장애 패턴과 SLA 관리
실제 프로덕션 환경에서 발생하는 대표적인 장애 패턴과 SLA(Service Level Agreement) 관리 방법을 이해하는 것이 중요합니다. 대표적인 프로덕션 장애 패턴:| 장애 유형 | 발생 시기 | 탐지 난이도 | 영향 범위 |
|---|---|---|---|
| 콜드 스타트 지연 | Scale-to-Zero 후 첫 요청 | 쉬움 (즉시 감지) | 개별 요청 |
| 데이터 스키마 변경 | 업스트림 파이프라인 배포 후 | 중간 (에러율 급증) | 전체 서비스 |
| 개념 드리프트(Concept Drift) | 수주~수개월 경과 후 | 어려움 (점진적 성능 저하) | 비즈니스 전체 |
| 메모리 누수 | 오랜 운영 후 | 중간 (지연 시간 증가) | 서버 전체 |
| 토큰 폭발(Token Explosion) | 사용자 프롬프트 변화 | 쉬움 (비용 급증) | 비용 및 지연 시간 |
| 모델 버전 불일치 | A/B 테스트 중 배포 오류 | 어려움 (부분적 오류) | 일부 사용자 |
| 메트릭 | 경고 임계값 | 위험 임계값 | SLA 예시 |
|---|---|---|---|
| P99 지연시간 | > 500ms | > 1,000ms | 99%의 요청을 500ms 이내 처리 |
| 에러율(Error Rate) | > 1% | > 5% | 99.9% 가용성 보장 |
| 처리량(Throughput) | < 계획 대비 80% | < 계획 대비 50% | 최대 1,000 RPS 처리 |
| 드리프트 PSI | > 0.1 | > 0.2 | 월간 재학습 트리거 |
⚠️ 중요: SLA 임계값은 비즈니스 요구사항에 따라 조정해야 합니다. 추천 시스템과 실시간 사기 탐지는 요구되는 지연시간 SLA가 크게 다릅니다.
모니터링 계층 구조
효과적인 모니터링은 세 가지 계층으로 나누어 접근합니다. 인프라/서빙 → 모델 성능 → 비즈니스 메트릭 순으로 계층적으로 모니터링합니다.| 계층 | 주요 메트릭 | 도구 |
|---|---|---|
| 1. 인프라/서빙 | QPS, 지연시간(P50/P95/P99), 에러율, GPU/CPU 사용률, 비용(DBU/토큰) | Serving UI, 시스템 테이블 |
| 2. 모델 성능 | 예측 정확도, 데이터 드리프트, 피처 분포 변화 | Inference Table + Lakehouse Monitoring |
| 3. 비즈니스 | 전환율, 매출 영향, 사용자 만족도 | 커스텀 대시보드, AI/BI |
핵심 메트릭 심화
지연 시간 Percentile (Latency Percentiles)
단순 평균(Average) 지연 시간은 이상치(Outlier)에 민감하여 실제 사용자 경험을 왜곡할 수 있습니다. 반드시 Percentile 기반 메트릭 을 사용해야 합니다.| 메트릭 | 의미 | 활용 |
|---|---|---|
| P50 (중앙값, Median) | 요청의 50%가 이 시간 이내에 처리됨 | ”보통 사용자”의 경험 |
| P95 | 요청의 95%가 이 시간 이내에 처리됨 | 대부분 사용자의 경험 |
| P99 | 요청의 99%가 이 시간 이내에 처리됨 | 느린 사용자의 경험, SLA 기준으로 주로 사용 |
| P99.9 | 요청의 99.9%가 이 시간 이내에 처리됨 | 매우 엄격한 SLA (금융, 의료 등) |
💡 P99가 중요한 이유: P50이 100ms이더라도 P99가 5,000ms이면, 100명 중 1명은 5초를 기다립니다. 높은 트래픽에서는 이 1%가 수백 명에 달할 수 있습니다.
처리량 (Throughput)
처리량(Throughput) 은 단위 시간당 처리된 요청 수를 의미합니다. 엔드포인트가 부하를 감당할 수 있는지 판단하는 핵심 지표입니다.| 메트릭 | 단위 | 설명 |
|---|---|---|
| RPS (Requests Per Second) | 요청/초 | 초당 처리 요청 수, 일반 모델에 사용 |
| TPS (Tokens Per Second) | 토큰/초 | LLM 생성 속도, 스트리밍 경험에 직접 영향 |
| QPS (Queries Per Second) | 쿼리/초 | RPS와 동일 개념으로 혼용 |
에러율 분류
에러는 HTTP 상태 코드로 분류하며, 원인에 따라 대응 방법이 다릅니다.| 상태 코드 | 분류 | 일반적인 원인 | 대응 방법 |
|---|---|---|---|
| 400 | 클라이언트 오류 | 잘못된 요청 형식, 스키마 불일치 | 입력 유효성 검증 강화 |
| 429 | Rate Limiting | 클라이언트 요청 폭주 | Rate Limit 설정, 클라이언트 재시도 로직 |
| 500 | 서버 오류 | 모델 로딩 실패, 메모리 부족 | 리소스 확대, 모델 디버깅 |
| 503 | 서비스 불가 | 콜드 스타트, 과부하 | Provisioned Concurrency 설정 |
| 504 | 타임아웃 | 추론 시간 초과 | 타임아웃 임계값 조정, 모델 최적화 |
Inference Tables (추론 테이블)
💡 Inference Table 은 Model Serving 엔드포인트의 모든 요청과 응답을 자동으로 Delta 테이블에 기록 하는 기능입니다. 모델 성능 모니터링, 디버깅, 규정 준수 감사에 활용됩니다.
기록되는 정보
| 항목 | 설명 |
|---|---|
| 요청 입력 | 모델에 전달된 입력 데이터 (피처, 프롬프트 등) |
| 응답 출력 | 모델의 예측 결과 (점수, 생성 텍스트 등) |
| 타임스탬프 | 요청/응답 시간 |
| 지연 시간 | 추론에 걸린 시간 (밀리초) |
| 상태 코드 | HTTP 상태 (200 성공, 4xx/5xx 오류) |
| 모델 버전 | 어떤 모델 버전이 응답했는지 (A/B 테스트 시 유용) |
| 토큰 사용량 | LLM 엔드포인트의 입력/출력 토큰 수 |
| 요청 메타데이터 | 클라이언트 ID, 요청 ID 등 추적 정보 |
자동 캡처 설정
💡 Inference Table 이름 규칙:{catalog}.{schema}.{prefix}_payload형태로 자동 생성됩니다. 기존 엔드포인트에도PUT /api/2.0/serving-endpoints/{name}/config로 활성화할 수 있습니다.
페이로드 구조
Inference Table에 기록되는 데이터의 스키마는 다음과 같습니다.
⚠️ 주의: Inference Table은 파티션 기반으로 데이터를 저장하므로, 쿼리 시 반드시 date 컬럼으로 필터링하여 성능을 확보하시기 바랍니다.
샘플링 전략과 데이터 보존 정책
트래픽이 많은 엔드포인트에서 모든 요청을 기록하면 스토리지 비용이 빠르게 증가 합니다. 샘플링 전략과 보존 정책을 적절히 설정해야 합니다. 샘플링 전략 비교:| 전략 | 방법 | 장점 | 단점 |
|---|---|---|---|
| 전수 기록 (100%) | sampling_fraction=1.0 | 완전한 감사 추적 | 스토리지 비용 높음 |
| 랜덤 샘플링 | sampling_fraction=0.1 | 비용 절감, 통계적 대표성 | 희귀 이벤트 누락 가능 |
| 계층적 샘플링 | 에러는 100%, 정상은 10% | 오류 완전 캡처 + 비용 절감 | 구현 복잡성 |
| 시간 기반 샘플링 | 피크 시간대만 100% | 중요 시간대 완전 캡처 | 비피크 시간대 누락 |
💡 권장 보존 기간: 규정 준수 요구사항이 없는 경우 30~90일을 권장합니다. GDPR/개인정보보호법 적용 환경에서는 법적 의무 보존 기간을 반드시 확인하십시오.
Lakehouse Monitoring 연동
Inference Table의 데이터를 Lakehouse Monitoring 과 연동하면, 데이터 드리프트와 모델 품질을 체계적으로 모니터링할 수 있습니다.데이터 드리프트 감지
| 생성 테이블 | 내용 |
|---|---|
*_profile_metrics | 각 컬럼의 통계 요약 (평균, 분산, 분포 등) |
*_drift_metrics | 기준 기간 대비 드리프트 지표 (PSI, KL Divergence 등) |
💡 PSI(Population Stability Index): 두 분포의 차이를 측정하는 지표입니다. PSI가 0.2를 초과하면 유의미한 드리프트로 판단합니다.드리프트 지표 해석 기준:
| 지표 | 범위 | 해석 |
|---|---|---|
| PSI | < 0.1 | 안정 (No Change) |
| PSI | 0.1 ~ 0.2 | 소폭 변화 (Minor Shift), 모니터링 강화 |
| PSI | > 0.2 | 유의미한 드리프트 (Major Shift), 재학습 권장 |
| KS 통계량 | < 0.05 | 두 분포 동일 (p-value 기준) |
| Jensen-Shannon Divergence | > 0.1 | 분포 차이 감지 |
Lakehouse Monitoring 알림 설정
드리프트 감지 시 자동으로 알림을 발송하도록 설정할 수 있습니다.모델 품질 모니터링
Ground Truth 레이블이 확보되면 모델의 실제 성능을 추적할 수 있습니다.MLflow Tracing (에이전트/LLM 서빙)
LLM 기반 에이전트를 서빙하는 경우, MLflow Tracing 을 통해 각 요청의 내부 실행 경로를 추적할 수 있습니다.| 구성 요소 | 역할 | 설명 |
|---|---|---|
| 사용자 요청 | 입력 | 에이전트에 요청을 전송합니다 |
| 에이전트 | 오케스트레이션 | 요청을 분석하고 필요한 작업을 수행합니다 |
| 문서 검색 | Vector Search | 관련 문서를 검색합니다 |
| LLM 호출 | Foundation Model | 답변을 생성합니다 |
| 도구 실행 | SQL, API 등 | 외부 도구를 호출합니다 |
| 최종 응답 | 출력 | 사용자에게 결과를 반환합니다 |
| 트레이스 항목 | 설명 |
|---|---|
| Span 계층구조 | 에이전트의 각 단계(검색, LLM 호출, 도구 실행)를 트리 형태로 표시합니다 |
| 입출력 | 각 단계의 입력과 출력을 기록합니다 |
| 토큰 사용량 | LLM 호출별 입력/출력 토큰 수를 추적합니다 |
| 지연 시간 | 각 단계별 소요 시간을 밀리초 단위로 측정합니다 |
| 에러 정보 | 실패 시 에러 메시지와 스택 트레이스를 기록합니다 |
시스템 테이블 활용
Databricks 시스템 테이블(system.serving)에는 모든 서빙 엔드포인트의 운영 메트릭이 자동으로 기록됩니다.
💡 시스템 테이블 은 Unity Catalog의 system 카탈로그에 위치하며, 워크스페이스 관리자가 활성화해야 합니다. 추가 비용 없이 90일간의 데이터를 보존합니다.
비용 모니터링
토큰 사용량 추적 (LLM 엔드포인트)
DBU 기반 비용 추적
Serving UI 메트릭
Model Serving 엔드포인트 페이지에서 다음 메트릭을 실시간으로 확인할 수 있습니다.| 메트릭 | 설명 |
|---|---|
| QPS (Queries Per Second) | 초당 처리 요청 수 |
| Latency (P50, P99) | 응답 시간 분포 |
| Error Rate | 실패한 요청 비율 |
| GPU Utilization | GPU 엔드포인트의 리소스 활용도 |
| Provisioned Concurrency | 동시 처리 가능한 요청 수 |
| Scale-to-Zero Events | 0으로 축소/복원된 횟수 |
| Token Throughput | LLM 엔드포인트의 초당 토큰 처리량 |
🆕 Endpoint Telemetry (Beta): OpenTelemetry 기반의 관찰 가능성 기능이 추가되었습니다. OTLP(OpenTelemetry Protocol)로 외부 모니터링 시스템(Datadog, Grafana 등)과 연동할 수 있습니다.
알림 설정 (Alerting)
모니터링 메트릭에 기반한 알림을 설정하여, 문제가 발생하면 즉시 대응할 수 있습니다.Databricks SQL Alert 활용
알림 채널 설정
| 채널 | 설정 방법 | 적합한 용도 |
|---|---|---|
| SQL Alert에서 직접 지정 | 일일 리포트, 비긴급 알림 | |
| Slack | Webhook URL 연동 | 팀 채널 실시간 알림 |
| PagerDuty | Webhook URL 연동 | 긴급 장애 대응 (On-call 연동) |
| Microsoft Teams | Webhook URL 연동 | 팀 채널 실시간 알림 |
대시보드 구축 (System 테이블 기반)
종합 모니터링 대시보드 쿼리
아래 쿼리들을 Databricks SQL 대시보드에 위젯으로 추가하면, 종합 모니터링 대시보드를 구축할 수 있습니다.멀티 엔드포인트 비교 대시보드
여러 엔드포인트를 동시에 비교하는 운영 대시보드용 쿼리입니다.모니터링 장단점과 트레이드오프
모니터링 체계를 설계할 때 비용과 가치 사이의 트레이드오프를 이해해야 합니다.모니터링 수준별 비교
| 수준 | 구성 | 월 추가 비용 (예시) | 탐지 가능 문제 |
|---|---|---|---|
| 기본 | Serving UI만 활용 | $0 | 인프라 장애, 지연시간 급증 |
| 중간 | + Inference Table (100%) | $50~200 | 스키마 오류, 입력 이상 |
| 고급 | + Lakehouse Monitoring | $200~500 | 데이터 드리프트, 모델 성능 저하 |
| 완전 | + Ground Truth 연동 | $500~2,000 | 실제 예측 정확도, 비즈니스 영향 |
💡 비용은 트래픽 규모, 데이터 크기, 클러스터 구성에 따라 크게 달라집니다. 실제 비용은 Databricks Cost Management에서 확인하십시오.
Inference Table: 전수 기록 vs 샘플링
| 항목 | 전수 기록 (100%) | 샘플링 (10%) |
|---|---|---|
| 비용 | 높음 | 낮음 (약 1/10) |
| 드리프트 감지 정확도 | 높음 | 중간 (통계적으로 충분) |
| 희귀 이벤트 캡처 | 모두 캡처 | 누락 가능 |
| 규정 준수 감사 | 완전한 감사 추적 | 불완전 |
| 적합한 환경 | 금융, 의료, 법규 준수 | 추천 시스템, 일반 ML |
Lakehouse Monitoring 설정 트레이드오프
| 항목 | 빠른 갱신 주기 (1시간) | 느린 갱신 주기 (1일) |
|---|---|---|
| 드리프트 탐지 속도 | 빠름 (1시간 이내) | 느림 (최대 24시간) |
| 컴퓨팅 비용 | 높음 | 낮음 |
| 통계적 신뢰도 | 낮음 (샘플 수 부족 시) | 높음 |
| 적합한 환경 | 실시간 의사결정 시스템 | 배치 예측 시스템 |
베스트 프랙티스와 흔한 실수
베스트 프랙티스 (Best Practices)
1. 모니터링을 배포 전에 설계하세요 모델 배포 후 모니터링을 추가하면 초기 데이터가 유실됩니다. Inference Table은 엔드포인트 생성 시 함께 활성화하십시오.흔한 실수 (Common Mistakes)
실수 1: Inference Table을date 파티션 없이 쿼리
| 알림 유형 | 채널 | 임계값 기준 |
|---|---|---|
| P1 긴급 | PagerDuty (On-call) | 에러율 > 10%, 서비스 중단 |
| P2 경고 | Slack #ml-alerts | 에러율 > 5%, P99 > 2초 |
| P3 정보 | Email 일일 리포트 | 드리프트 감지, 비용 임계값 |
트러블슈팅 가이드
| 증상 | 가능한 원인 | 확인 방법 | 해결 방안 |
|---|---|---|---|
| 지연 시간 급증 | 모델 크기 증가, 입력 길이 증가 | P99 지연 시간 트렌드 확인 | 모델 최적화, 인스턴스 크기 증가 |
| 에러율 상승 | 입력 스키마 불일치, 메모리 부족 | 에러 로그 샘플 확인 | 입력 유효성 검증 추가, 리소스 확대 |
| Scale-to-Zero 후 콜드 스타트 | 트래픽 불규칙 | 스케일링 이벤트 로그 확인 | 최소 프로비저닝 동시성 설정 |
| 토큰 비용 급증 | 프롬프트 길이 증가, 트래픽 급증 | 일별 토큰 사용량 확인 | 프롬프트 최적화, Rate Limiting |
| 드리프트 알림 | 입력 데이터 분포 변화 | Lakehouse Monitor 대시보드 확인 | 모델 재학습, 피처 파이프라인 점검 |
| Inference Table 미기록 | Auto Capture 미활성화 | 엔드포인트 설정 확인 | auto_capture_config 활성화 |
정리
| 핵심 기능 | 설명 |
|---|---|
| Inference Table | 모든 요청/응답을 Delta 테이블에 자동 기록합니다 |
| Lakehouse Monitoring | 데이터 드리프트와 모델 품질을 자동으로 감지합니다 |
| MLflow Tracing | LLM/에이전트의 실행 경로를 단계별로 추적합니다 |
| 시스템 테이블 | 모든 엔드포인트의 운영 메트릭을 중앙에서 조회합니다 |
| 비용 모니터링 | 토큰 사용량과 DBU 기반 비용을 추적합니다 |
| 알림 | SQL Alert + Webhook으로 실시간 알림을 받을 수 있습니다 |
- 배포 전 설계 — Inference Table은 엔드포인트 생성 시 활성화합니다
- Percentile 기반 SLA — P99를 기준으로 서비스 수준을 정의합니다
- 계층적 알림 — 긴급/경고/정보로 구분하여 알림 피로를 방지합니다
- 비용과 가치 균형 — 트래픽 규모에 맞는 샘플링 전략을 선택합니다
- Ground Truth 연동 — 가능하면 실제 레이블을 수집하여 성능을 검증합니다