8. MLOps 파이프라인
Databricks Jobs (스케줄링)
ML 모델을 프로덕션에서 운영하려면, 데이터 수집 → 피처 엔지니어링 → 학습 → 평가 → 배포라는 파이프라인이 자동으로 반복 실행 되어야 합니다. Databricks Jobs 는 노트북, Python 스크립트, JAR 등을 DAG(방향 비순환 그래프) 형태로 연결하고 스케줄링하는 워크플로 오케스트레이터입니다.| 기능 | 설명 |
|---|---|
| 멀티태스크 워크플로 | 여러 태스크를 순차/병렬로 구성 |
| 트리거 방식 | Cron 스케줄, API 트리거, 파일 도착 트리거 |
| 조건부 실행 | 이전 태스크 결과에 따라 분기 (if/else) |
| 파라미터 전달 | 태스크 간 파라미터 전달 (dbutils.jobs.taskValues) |
| 재시도 정책 | 태스크 실패 시 자동 재시도 설정 |
| 알림 | 성공/실패 시 이메일, Slack 알림 |
| 서버리스 | Serverless Compute로 클러스터 관리 없이 실행 |
Databricks Asset Bundles (CI/CD)
왜 등장했는가: ML 파이프라인을 Git 기반으로 관리하고 개발/스테이징/프로덕션 환경을 분리하여 배포하려면 Infrastructure as Code 도구가 필요합니다. Databricks Asset Bundles (DABs) 는 Databricks 리소스(Jobs, Pipelines, Model Serving 등)를 YAML 파일로 정의하고 CLI로 배포하는 IaC 도구입니다.전체 MLOps 워크플로
아래 표는 Databricks에서의 전체 MLOps 워크플로를 단계별로 정리한 것입니다.| 단계 | 환경 | 활동 | Databricks 기능 |
|---|---|---|---|
| 1. 개발 | Dev Workspace | 탐색적 분석, 피처 엔지니어링, 모델 프로토타이핑 | Notebooks, AutoML, MLflow Experiment |
| 2. 코드 관리 | Git (GitHub/Azure DevOps) | 코드 리뷰, 버전 관리 | Git Integration, Repos |
| 3. 테스트 | Staging Workspace | 단위 테스트, 통합 테스트, 모델 검증 | DABs (--target staging), pytest |
| 4. 등록 | Unity Catalog | 검증된 모델을 레지스트리에 등록 | UC Model Registry, Alias |
| 5. 배포 | Prod Workspace | 서빙 엔드포인트 업데이트, 배치 추론 스케줄링 | Model Serving, Jobs |
| 6. 모니터링 | Prod Workspace | 데이터/모델 드리프트 감지, 알림 | Lakehouse Monitoring, Inference Table |
| 7. 재학습 | Prod Workspace | 드리프트 감지 시 자동 재학습 트리거 | Jobs (API 트리거), Webhooks |
주의 MLOps 워크플로의 성숙도는 조직마다 다릅니다. 처음에는 수동 배포(Level 0)로 시작하고, 점진적으로 CI/CD 자동화(Level 1), 자동 재학습(Level 2)으로 발전시키는 것이 현실적입니다.
9. Databricks ML 기능 매핑 테이블
아래 표는 ML 라이프사이클의 각 단계에서 사용되는 Databricks 기능을 한눈에 보여줍니다. 새로운 ML 프로젝트를 시작할 때 이 표를 참고하여 필요한 기능을 빠르게 파악할 수 있습니다.| ML 라이프사이클 단계 | Databricks 기능 | 카테고리 | 비고 |
|---|---|---|---|
| 데이터 저장 | Delta Lake, Unity Catalog | 플랫폼 기반 | Lakehouse의 기반 |
| 데이터 탐색 | Notebooks, SQL Editor, AI/BI Dashboard | 분석 | EDA, 시각화 |
| 피처 엔지니어링 | Feature Engineering in UC | 데이터 준비 | Feature Table + Feature Function |
| 피처 서빙 | Online Tables | 데이터 준비 | 실시간 피처 조회 |
| 자동 ML | AutoML | 학습 | 투명한 노트북 생성 |
| 모델 학습 | Runtime ML, GPU Clusters | 학습 | 사전 설치 라이브러리 |
| 분산 학습 | TorchDistributor, Horovod, DeepSpeed | 학습 | Spark 클러스터 활용 |
| 실험 관리 | MLflow Tracking | 실험 | 파라미터, 메트릭, 아티팩트 |
| 모델 레지스트리 | Unity Catalog Models | 거버넌스 | 3-level 네임스페이스, Alias |
| 실시간 추론 | Model Serving Endpoints | 배포 | 오토스케일링, A/B 테스트 |
| 배치 추론 | Spark UDF, Jobs | 배포 | 대규모 병렬 처리 |
| LLM 호출 | Foundation Model APIs | GenAI | Pay-per-token, Provisioned |
| 외부 LLM | External Models (AI Gateway) | GenAI | 거버넌스, 비용 추적 |
| 벡터 검색 | Vector Search | GenAI | Delta Sync, RAG 기반 |
| AI Agent | Agent Framework (ChatAgent) | GenAI | 개발 → 평가 → 배포 |
| Agent 평가 | MLflow Evaluate | GenAI | LLM-as-a-Judge |
| LLM 테스트 | AI Playground | GenAI | 코드 없이 모델 비교 |
| 모델 모니터링 | Lakehouse Monitoring | 운영 | 드리프트 감지, 자동 대시보드 |
| 추론 로깅 | Inference Tables | 운영 | 요청/응답 자동 기록 |
| 워크플로 관리 | Jobs (Workflows) | MLOps | DAG, 스케줄링, 트리거 |
| CI/CD | Asset Bundles (DABs) | MLOps | YAML 기반 IaC |
| 앱 배포 | Databricks Apps | 배포 | Streamlit/FastAPI 호스팅 |
10. 한계와 트레이드오프
모든 플랫폼에는 제약이 있으며, Databricks ML/AI도 예외는 아닙니다. 아래 표는 주요 고려사항을 정리한 것입니다.| 고려사항 | 설명 | 대안/완화 방법 |
|---|---|---|
| 벤더 종속 | Databricks 전용 기능(AutoML, Feature Store UI 등) 사용 시 이식성 감소 | MLflow는 오픈소스이므로 모델/실험은 이식 가능 |
| 비용 | GPU 클러스터, Model Serving은 비용이 높을 수 있음 | Spot 인스턴스, Scale-to-zero, Serverless 활용 |
| 실시간 학습 | 온라인 학습(실시간 모델 업데이트)은 네이티브 지원 미흡 | Structured Streaming + 주기적 재학습으로 대체 |
| 엣지 배포 | 온프레미스/엣지 디바이스 배포는 직접 지원하지 않음 | MLflow 모델을 export하여 별도 서빙 인프라에 배포 |
| 커스텀 서빙 | 복잡한 전/후처리 로직이 필요한 경우 서빙 제약 | Custom Container 또는 Databricks Apps로 해결 |
| 소규모 팀 | 전체 MLOps 파이프라인 구축은 소규모 팀에게 과한 투자일 수 있음 | AutoML + 수동 배포로 시작, 점진적으로 자동화 |
다음 단계
- Classic ML 실습: 예지보전 & 이상탐지 MLOps 핸즈온 — 전체 MLOps 파이프라인을 직접 구축
- GenAI 이론: GenAI 핵심 개념 — LLM, Agent, Prompt Engineering 이론
- RAG 구축: RAG 가이드 — Vector Search + Agent 실전 구축
- ML 알고리즘: ML 트렌드 & 최신 기법 — 알고리즘 선택, 앙상블, 이상탐지 기법
- 모델 운영: 재학습 전략 — Drift 감지, 재학습 자동화 전략