1. 왜 버전 관리와 모니터링이 중요한가
AI 에이전트의 비결정성 (Non-determinism)
전통적인 소프트웨어와 달리 AI 에이전트는 동일한 입력에도 다른 출력을 생성할 수 있습니다. 이 특성은 다음과 같은 운영 리스크를 만들어냅니다.- LLM 드리프트 (LLM Drift): 파운데이션 모델 제공자(예: OpenAI, Anthropic)가 내부적으로 모델을 업데이트하면 동일한 API 호출도 다른 결과를 낳습니다.
- 데이터 드리프트 (Data Drift): RAG 파이프라인의 지식 베이스(Knowledge Base)가 변경되면 검색 결과가 달라지고, 에이전트의 응답 품질이 변합니다.
- 프롬프트 민감성 (Prompt Sensitivity): 프롬프트 템플릿의 사소한 변경이 응답 스타일이나 정확도에 큰 영향을 줄 수 있습니다.
프로덕션 장애의 대표 패턴
| 장애 유형 | 원인 | 영향 |
|---|---|---|
| 할루시네이션 급증 | 프롬프트 변경 또는 모델 업그레이드 | 잘못된 정보 제공, 신뢰도 손상 |
| 응답 지연 급증 | 도구 호출 루프, 컨텍스트 길이 초과 | 타임아웃, 사용자 이탈 |
| 오류율 증가 | 외부 API 장애, 스키마 변경 | 서비스 중단 |
| 비용 폭증 | 토큰 소비 이상, 무한 루프 | 예산 초과 |
2. 모델 버전 관리 — Unity Catalog Model Registry
Unity Catalog에서의 버전 등록
Databricks Unity Catalog (UC)는 모델을 3단계 네임스페이스 (catalog.schema.model_name)로 관리합니다. 모델을 등록하면 버전 번호가 자동으로 부여됩니다.
Champion/Challenger 패턴
앨리어스 (Alias) 를 활용하면 버전 번호 대신 역할(Role) 기반으로 모델을 참조할 수 있습니다.자동 승격 기준 (Promotion Criteria)
Challenger 버전이 아래 조건을 모두 만족하면 Champion으로 자동 승격합니다.| 메트릭 | 최소 기준 | 측정 기간 |
|---|---|---|
| 정확도 (Accuracy) | Champion 대비 ≥ 95% | 24시간 |
| p95 Latency | ≤ 3,000ms | 24시간 |
| Error Rate | ≤ 1% | 24시간 |
| 사용자 긍정 피드백 | ≥ 70% | 24시간 |
3. 배포 전략 (Deployment Strategies)
3-1. Canary 배포
신규 버전에 소량의 트래픽(예: 5–10%)만 먼저 흘려 리스크를 제한합니다.3-2. Blue-Green 배포
두 개의 동일한 환경(Blue = 현재, Green = 신규)을 운영하고, 검증 후 즉시 전환합니다. 트래픽 전환이 순간적(0→100%)이므로 롤백도 빠릅니다.3-3. A/B 테스트 (Traffic Splitting)
두 버전을 동시에 운영하며 비즈니스 메트릭(전환율, 해결률 등)을 비교합니다.참고: A/B 테스트는 통계적 유의성(Statistical Significance)이 확보될 때까지 유지해야 합니다. 최소 수백 건 이상의 샘플이 필요합니다.
4. 모니터링 핵심 메트릭
인프라 메트릭 (Infrastructure Metrics)
| 메트릭 | 설명 | 권장 임계값 |
|---|---|---|
| Latency (p50/p95/p99) | 응답 시간 분포 | p95 > 5s → 알림 |
| Throughput (RPS) | 초당 요청 수 | 비정상 급증/급감 감지 |
| Error Rate | 4xx/5xx 비율 | > 5% → 알림, > 10% → 롤백 |
| Concurrency | 동시 처리 요청 수 | 스케일 아웃 기준 |
LLM 특화 메트릭 (LLM-specific Metrics)
| 메트릭 | 설명 | 활용 |
|---|---|---|
| Token 사용량 | 입력/출력 토큰 수 | 비용 예측 및 이상 탐지 |
| Context Length | 컨텍스트 윈도우 활용률 | 최대 한계 근접 시 최적화 |
| Tool Call Count | 에이전트 루프 당 도구 호출 횟수 | 무한 루프 탐지 |
| Retrieval Relevance | RAG 검색 관련성 점수 | 지식 베이스 품질 측정 |
품질 메트릭 (Quality Metrics)
5. MLflow Tracing — 추론 과정 추적
Tracing이 필요한 이유
프로덕션에서 에이전트가 잘못된 답변을 생성했을 때, 어느 단계에서 문제가 발생했는지 파악하려면 분산 추적 (Distributed Tracing) 이 필수입니다. MLflow Tracing은 LLM 호출, RAG 검색, 도구 실행 각 단계를 Span 단위로 기록합니다.자동 추적 활성화
커스텀 Span 추가
프로덕션 Trace 분석
6. Inference Table — 자동 로깅과 활용
활성화 방법
Model Serving 엔드포인트 생성 시auto_capture_config를 설정하면 모든 요청/응답이 Delta Table에 자동 저장됩니다.
Inference Table 주요 스키마
| 컬럼 | 타입 | 설명 |
|---|---|---|
request_id | STRING | 고유 요청 ID (Trace와 연계 키) |
timestamp | TIMESTAMP | 요청 수신 시각 |
status_code | INT | HTTP 상태 코드 |
execution_time_ms | BIGINT | 총 처리 시간 |
request | VARIANT | 원본 요청 JSON |
response | VARIANT | 원본 응답 JSON |
sampling_fraction | DOUBLE | 샘플링 비율 |
client_request_id | STRING | 클라이언트 제공 요청 ID |
실전 활용 쿼리
피드백 루프 (Feedback Loop) 구성
Inference Table 데이터를 활용해 사용자 피드백을 수집하고 재훈련 데이터셋을 구축합니다.7. 알림과 자동 대응 (Alerting & Auto-response)
Lakehouse Monitoring 알림 설정
Unity Catalog의 Lakehouse Monitoring 기능으로 메트릭이 임계값을 초과하면 자동 알림을 발송합니다.자동 롤백 파이프라인
Databricks Jobs를 활용해 메트릭 이상 감지 시 자동 롤백을 구현합니다.8. 전체 버전 업데이트 워크플로
| 단계 | 작업 | 설명 |
|---|---|---|
| 1 | 개발 (v4) | 에이전트 신규 버전 개발 |
| 2 | MLflow 로깅 + UC 등록 | challenger 앨리어스 부여 |
| 3 | Review App 테스트 | 내부 테스터 검증 (오프라인 평가) |
| 4 | 기준 미충족 | 1단계로 돌아가 재개발 |
| 5 | Canary 배포 (10%) | 소량 트래픽으로 실서비스 검증 |
| 6 | 모니터링 (24h) | Inference Table + MLflow Tracing 분석 |
| 7a | 이상 감지 | 자동 롤백 (v4 → v3) + 알림 발송 |
| 7b | 정상 확인 | 트래픽 100% 전환, champion 앨리어스 이동 |
9. 베스트 프랙티스와 흔한 실수
베스트 프랙티스
- 모든 실험을 MLflow Run으로 추적합니다. 프롬프트, 모델 버전, 하이퍼파라미터를 빠짐없이 기록하면 나중에 어떤 조합이 왜 좋았는지 재현할 수 있습니다.
- 앨리어스(Alias)를 사용해 버전 번호 의존을 제거합니다. 코드에 버전 번호를 하드코딩하면 배포 시마다 코드를 변경해야 합니다.
- Canary → Full 롤아웃 단계를 반드시 거칩니다. 아무리 오프라인 평가가 좋아도 실사용자 트래픽에서 예상치 못한 문제가 발생할 수 있습니다.
- Inference Table 보존 기간을 정책으로 명시합니다. 기본적으로 무제한 누적되므로 TTL(Time-to-Live) 정책을 설정해 스토리지 비용을 관리합니다.
- 품질 메트릭과 인프라 메트릭을 분리해 모니터링합니다. Error Rate가 낮아도 응답 품질이 저하될 수 있습니다.
흔한 실수
| 실수 | 결과 | 해결책 |
|---|---|---|
| 버전 번호를 코드에 하드코딩 | 배포마다 코드 변경 필요 | 앨리어스(champion/challenger) 사용 |
| Canary 없이 즉시 100% 전환 | 전체 서비스 장애 위험 | 항상 점진적 롤아웃 적용 |
| 오프라인 평가만으로 배포 결정 | 실사용 품질 저하 발생 | A/B 테스트 + 온라인 평가 병행 |
| 롤백 절차 미수립 | 장애 시 복구 시간 증가 | 자동 롤백 파이프라인 사전 구축 |
| 토큰 비용 모니터링 누락 | 월말 예산 초과 | 일별 비용 알림 설정 |
| Tracing 비활성화 상태로 운영 | 장애 원인 파악 불가 | autolog()를 기본값으로 설정 |