이 문서는 ML 핵심 개념 섹션의 일부입니다.Databricks는 단순한 데이터 플랫폼이 아니라, 데이터 준비부터 모델 학습, 배포, 모니터링까지 ML 라이프사이클 전체 를 하나의 플랫폼에서 관리할 수 있는 통합 ML/AI 환경입니다. 이 가이드는 Databricks가 제공하는 ML/AI 관련 기능을 체계적으로 정리하여, 각 기능이 왜 필요하고 어떻게 작동하며 실전에서 어떻게 활용되는지를 전문가 수준으로 설명합니다.
참고 이 가이드는 Databricks ML/AI 플랫폼 기능 에 초점을 맞춥니다. ML 알고리즘/기법 자체에 대한 이론은 ML 트렌드 & 최신 기법을, GenAI/LLM 이론은 GenAI 핵심 개념을 참고하세요.
1. Databricks ML/AI 플랫폼 전체 아키텍처
Data Intelligence Platform에서 ML의 위치
Databricks는 Data Intelligence Platform 이라는 비전 아래 데이터 엔지니어링, 분석, ML/AI를 하나의 Lakehouse 위에서 통합합니다. ML은 이 플랫폼의 핵심 축으로, 다음과 같은 이점을 제공합니다.
이 통합의 핵심 가치는 데이터 이동 최소화 와 거버넌스 통합 입니다. 데이터 엔지니어가 만든 테이블을 데이터 사이언티스트가 바로 사용하고, 학습된 모델을 ML 엔지니어가 같은 플랫폼에서 배포하며, 모든 자산(데이터, 피처, 모델, 엔드포인트)이 Unity Catalog라는 단일 거버넌스 레이어로 관리됩니다.
Classic ML vs GenAI: 두 축의 역할
Databricks ML/AI 기능은 크게 두 축으로 나뉩니다.
실전에서는 두 축을 함께 사용하는 경우가 많습니다. 예를 들어, 제조 공정에서 이상 탐지(Classic ML)가 알람을 발생시키면 GenAI Agent가 원인을 분석하고 대응 보고서를 자동 생성하는 파이프라인이 가능합니다.
2. 데이터 준비 & Feature Engineering
왜 Feature Store가 필요한가
ML 모델의 성능은 알고리즘보다 피처(feature)의 품질 에 의해 결정되는 경우가 많습니다. 그러나 실전에서는 세 가지 근본 문제가 반복적으로 발생합니다.- Training-Serving Skew: 학습 시에는 배치로 계산한 피처를 사용하고, 서빙 시에는 다른 코드로 실시간 계산하면서 미묘한 불일치가 발생합니다. 예를 들어, 학습 데이터에서는 “최근 30일 평균 구매액”을 SQL로 계산했는데, 서빙 코드에서는 API 호출 시점 기준으로 계산하여 윈도우가 달라지는 경우입니다.
- 피처 중복 개발: 데이터 사이언티스트 A가 만든
avg_purchase_amount피처를 팀원 B가 모르고 다시 개발합니다. 조직 규모가 커질수록 동일한 비즈니스 개념에 대해 N개의 서로 다른 피처가 존재하게 됩니다. - 피처 거버넌스 부재: 어떤 모델이 어떤 피처를 사용하는지, 피처 정의가 언제 변경되었는지 추적이 불가능합니다.
catalog.schema.table)로 관리되고, GRANT/REVOKE 권한, Lineage 추적, 크로스 워크스페이스 접근이 모두 통합되었습니다.
Databricks는 이 문제를 Feature Engineering in Unity Catalog 로 해결합니다.
Feature Engineering in Unity Catalog
작동 원리:
FeatureEngineeringClient를 사용하여 학습 데이터셋을 생성할 때, 라벨 데이터와 피처 테이블을 자동으로 조인합니다. 이때 어떤 피처 테이블에서 어떤 키로 조인했는지가 모델에 기록되어, 서빙 시 동일한 피처를 자동으로 조회합니다.
Feature Serving (온라인 추론용)
배치 추론은 Delta 테이블에서 직접 피처를 읽으면 되지만, 실시간 추론 에서는 밀리초 단위의 응답이 필요합니다. Delta Lake는 분석 워크로드에 최적화된 열 기반(Columnar) 스토리지이므로, 단일 키로 한 행을 빠르게 조회하는 Point Lookup에는 적합하지 않습니다. Databricks Online Table 은 이 문제를 해결합니다. Delta 테이블의 데이터를 자동으로 고성능 키-값 저장소(내부적으로 RocksDB 기반)에 동기화 하여, Primary Key 기반 서브밀리초 수준의 조회를 가능하게 합니다. 사용자는 별도의 캐시 레이어(Redis, DynamoDB 등)를 구축할 필요 없이, Unity Catalog UI에서 클릭 몇 번으로 Online Table을 생성할 수 있습니다.주의 Online Table은 Unity Catalog 관리형 테이블에서만 생성 가능합니다. 외부 테이블(External Table)에서는 지원되지 않습니다.
3. 모델 학습 (Training)
Databricks Runtime ML
Databricks Runtime ML은 표준 런타임에 ML/DL 라이브러리가 사전 설치된 특수 런타임 입니다. 직접 라이브러리를 설치하고 버전 충돌을 해결하는 고통을 없애줍니다. 주요 사전 설치 라이브러리는 다음과 같습니다.
Runtime ML 버전은 Databricks Runtime 버전과 동일한 넘버링을 따르며 (예: DBR 16.x ML), 분기마다 새로운 버전이 출시됩니다.
AutoML
왜 등장했는가: 데이터 사이언티스트가 새 데이터셋에 대해 적합한 알고리즘, 하이퍼파라미터, 전처리 방법을 찾는 데 수일~수주가 걸립니다. AutoML은 이 탐색 과정을 자동화합니다. Databricks AutoML의 차별점: Google AutoML, AWS SageMaker Autopilot 등 대부분의 AutoML 도구는 결과 모델만 반환하는 블랙박스 방식입니다. Databricks AutoML은 근본적으로 다릅니다 — 각 시도(trial)가 완전한 실행 가능 노트북 으로 생성되고, 모든 전처리/학습/평가 코드가 투명하게 공개됩니다. 이 노트북을 기반으로 도메인 지식을 반영한 수정이 가능하므로, AutoML이 출발점(starting point) 역할을 하고 데이터 사이언티스트가 전문성을 더하는 워크플로가 됩니다. 내부 탐색 과정: AutoML은 내부적으로 다음 단계를 자동 수행합니다.- 데이터 프로파일링: 각 컬럼의 타입, 분포, 결측률을 분석하여 데이터 탐색 노트북 생성
- 전처리 자동화: 수치형 컬럼의 결측치를 중앙값/평균으로 대체, 범주형 컬럼에 원-핫 인코딩, 날짜 컬럼에서 요일/월/시간 등 파생 피처 추출
- 알고리즘 탐색: LightGBM, XGBoost, RandomForest, LogisticRegression/ElasticNet 등을 순차적으로 시도
- 하이퍼파라미터 최적화: Hyperopt(TPE 알고리즘, Tree-structured Parzen Estimator) 기반으로 각 알고리즘의 최적 하이퍼파라미터를 탐색
- 앙상블 시도: 상위 모델들의 가중 투표(Weighted Voting) 앙상블도 자동 시도
참고 AutoML은 baseline 모델 을 빠르게 확보하는 용도로 가장 효과적입니다. 생성된 노트북을 기반으로 도메인 지식을 반영한 피처 추가, 커스텀 전처리 등을 수행하는 것이 일반적인 워크플로입니다.
분산 학습
Databricks 클러스터의 분산 컴퓨팅 능력을 ML 학습에 활용하는 방법은 여러 가지입니다.
TorchDistributor의 동작 원리: Spark 클러스터는 일반적으로 데이터 처리를 위해 설계되었지만, TorchDistributor는 Spark 워커 노드를 PyTorch 분산 학습 노드로 전환 합니다. 내부적으로 다음 과정이 일어납니다.
- Spark 드라이버가 각 워커에 PyTorch 학습 프로세스를 시작하도록 지시
- 각 워커에서
torch.distributed백엔드(NCCL for GPU, Gloo for CPU)가 초기화되어 프로세스 간 통신 채널 구성 - 데이터 병렬(Data Parallel) 방식으로 각 노드가 전체 모델의 복사본을 보유하고, 미니배치를 분할하여 학습
- 그래디언트를 AllReduce 연산으로 동기화하여 모델 파라미터를 일치시킴
Databricks ML Runtime에 DeepSpeed가 사전 설치되어 있으므로, TorchDistributor와 결합하여 대규모 모델의 파인튜닝을 수행할 수 있습니다.
GPU 클러스터 활용
Databricks는 AWS(p4d, p5, g5), Azure(NC, ND 시리즈), GCP의 GPU 인스턴스를 지원합니다. GPU 클러스터 사용 시 고려사항은 다음과 같습니다.4. 실험 관리 & 모델 레지스트리
MLflow Tracking
왜 필요한가: ML 프로젝트에서는 수십~수백 번의 실험을 수행합니다. 어떤 하이퍼파라미터 조합이 최적이었는지, 어떤 전처리를 적용했는지를 체계적으로 기록하지 않으면 재현이 불가능합니다. Databricks에는 Managed MLflow 가 내장되어 있어 별도 서버 구축 없이 바로 사용할 수 있습니다.mlflow.autolog()를 호출하면 scikit-learn, XGBoost, PyTorch, TensorFlow 등의 학습을 자동으로 추적합니다.
Unity Catalog 모델 레지스트리
왜 등장했는가: 기존 Workspace 레벨 모델 레지스트리는 워크스페이스 간 모델 공유가 어렵고, 데이터 거버넌스와 분리되어 있었습니다. Unity Catalog 모델 레지스트리는 모델을 데이터와 동일한 거버넌스 체계 로 관리합니다.
Unity Catalog 모델 레지스트리의 핵심 개념인 Alias 는 기존의 고정된 스테이지(Staging, Production) 대신 유연한 태그 시스템을 제공합니다. 기존 스테이지 방식은 Staging → Production → Archived라는 고정 경로만 허용했으나, Alias는 임의의 이름 을 자유롭게 부여할 수 있어 다양한 배포 전략을 지원합니다.
예를 들어,
Champion(현재 프로덕션 모델)과 Challenger(검증 중인 후보 모델) Alias를 지정하여 A/B 테스트를 구성하거나, region-kr, region-us처럼 지역별 모델을 관리할 수도 있습니다. Model Serving Endpoint가 Alias를 참조하므로, Alias를 다른 버전으로 이동시키면 엔드포인트가 자동으로 새 모델 버전을 로드 합니다 — 제로 다운타임 배포가 가능합니다.
모델 버전 관리 워크플로
아래 표는 일반적인 모델 라이프사이클에서 각 단계별 Databricks 기능 매핑을 보여줍니다.5. 모델 배포 (Serving)
Model Serving Endpoints (실시간 추론)
왜 등장했는가: ML 모델을 프로덕션 API로 노출하려면 컨테이너 이미지 빌드, 로드 밸런서 구성, 오토스케일링 설정 등 인프라 작업이 필요합니다. Databricks Model Serving은 이 복잡성을 완전 관리형 서비스 로 추상화합니다.Batch Inference (대규모 배치 추론)
실시간 응답이 필요하지 않은 경우, 배치 추론 이 비용 효율적입니다. Databricks에서 배치 추론을 수행하는 대표적인 방법은 다음과 같습니다.Foundation Model APIs
왜 등장했는가: LLM을 사용하려면 모델을 직접 호스팅하거나 외부 API를 호출해야 합니다. Databricks Foundation Model APIs 는 오픈소스 LLM을 Databricks 인프라에서 최적화된 상태로 제공하는 서버리스 API입니다. 아래 표는 두 가지 제공 유형의 차이와 각각 적합한 시나리오를 비교합니다.참고 선택 기준: 월 토큰 사용량이 수백만 토큰 이하이면 Pay-per-token이 경제적입니다. 프로덕션 서비스에서 초당 수십~수백 요청을 처리하거나, 파인튜닝한 커스텀 모델을 서빙해야 한다면 Provisioned Throughput을 선택하세요.Foundation Model APIs는 OpenAI 호환 API 를 지원하므로, 기존 OpenAI SDK 코드를 최소한의 변경으로 마이그레이션할 수 있습니다.
External Models
External Models 는 Azure OpenAI, Anthropic Claude, Amazon Bedrock 등 외부 LLM 제공자를 Databricks 엔드포인트로 프록시 하는 기능입니다.
이 아키텍처의 핵심 가치는 모델 제공자를 추상화 하는 것입니다. 애플리케이션 코드에서는 Databricks 엔드포인트만 호출하고, 실제로 어떤 LLM이 뒤에서 동작하는지는 엔드포인트 설정에서 변경할 수 있습니다.
AI Gateway의 실제 역할: External Models 기능의 핵심은 AI Gateway 레이어입니다. 이것은 단순 프록시가 아니라, 엔터프라이즈 환경에서 LLM 사용을 통제하고 관찰하기 위한 핵심 인프라입니다.
6. 모델 모니터링
Lakehouse Monitoring
왜 필요한가: 프로덕션에 배포된 모델은 시간이 지남에 따라 성능이 저하됩니다. 입력 데이터의 분포가 변하거나(Data Drift), 입력과 출력 간의 관계가 변하면(Concept Drift) 모델의 예측 정확도가 떨어집니다. Databricks Lakehouse Monitoring 은 테이블 단위의 모니터링 솔루션으로, 데이터 품질과 모델 성능을 자동으로 추적합니다.
드리프트 감지 메커니즘: Lakehouse Monitoring은 단순 통계 비교를 넘어, 통계적 검정(statistical test)에 기반한 체계적인 드리프트 감지를 수행합니다.
Lakehouse Monitoring이 생성하는 두 개의 출력 테이블 을 이해하는 것이 중요합니다.
이 테이블들은 일반 Delta 테이블이므로, SQL로 쿼리하거나 Databricks Jobs에서 드리프트 임계값을 확인하여 재학습 파이프라인을 자동 트리거 하는 것이 가능합니다.
Lakehouse Monitoring이 생성하는 자동 대시보드 에서는 다음을 확인할 수 있습니다.
- 각 컬럼의 분포 변화를 시각화한 히스토그램
- 드리프트 감지 통계량과 p-value
- 모델 성능 지표의 시간별 추이 (InferenceLog 프로필)
Inference Table (추론 테이블)
Model Serving Endpoint에 Inference Table 을 활성화하면, 모든 요청(입력)과 응답(출력)이 자동으로 Delta 테이블에 기록됩니다.
이 테이블에 Lakehouse Monitoring의 InferenceLog 프로필을 연결하면, 실시간 추론 모니터링 파이프라인 이 완성됩니다.
참고 Inference Table의 데이터는 Ground Truth 라벨링 에도 활용됩니다. 시간이 지나 실제 결과가 확인되면, Inference Table에 라벨을 조인하여 모델의 실제 성능을 계산할 수 있습니다.
7. GenAI & Agent 기능
Foundation Model APIs
앞서 5장에서 설명한 Foundation Model APIs는 GenAI 워크로드의 기반이 됩니다. 추가로 GenAI 특화 기능을 정리합니다.Vector Search
왜 필요한가: RAG(검색 증강 생성) 파이프라인에서 관련 문서를 빠르게 검색하려면 벡터 유사도 검색이 필수입니다. 별도의 벡터 DB(Pinecone, Weaviate 등)를 운영하면 데이터 이중 관리 문제가 발생합니다 — 원본 문서가 업데이트되면 벡터 DB도 수동으로 동기화해야 하고, 삭제된 문서의 임베딩이 남아 “유령 검색 결과”를 반환하는 문제가 생깁니다. Databricks Vector Search 는 Delta 테이블을 Single Source of Truth 로 유지하면서 자동 동기화되는 벡터 인덱스를 제공합니다. 원본 Delta 테이블에서 행이 추가/수정/삭제되면 인덱스가 자동으로 반영되므로, 데이터 정합성이 보장됩니다.
Delta Sync Index는 두 가지 모드를 지원합니다.
Agent Framework (ChatAgent)
Databricks Agent Framework 는 LLM 기반 AI Agent를 개발, 테스트, 배포하기 위한 통합 프레임워크입니다. ChatAgent 인터페이스가 왜 중요한가: MLflow 3.0에서 도입된ChatAgent는 Agent 생태계의 표준 계약(contract) 역할을 합니다. 기존에는 LangChain으로 만든 Agent, LlamaIndex로 만든 Agent, 순수 Python Agent가 각각 다른 입출력 형식을 가져서, 배포/평가/모니터링 도구를 프레임워크별로 따로 만들어야 했습니다.
ChatAgent는 OpenAI Chat Completions 형식 (messages 리스트, role/content 구조)을 표준으로 채택하여, 어떤 프레임워크로 내부를 구현하든 동일한 인터페이스로 배포하고 평가할 수 있게 합니다. 이 덕분에 다음이 가능해집니다.
- 프레임워크 교체 투명성: LangChain에서 순수 Python으로 Agent 내부를 교체해도 배포 엔드포인트, 평가 코드, UI가 변경 없이 동작
- 통합 평가:
mlflow.evaluate()가 모든 ChatAgent에 동일하게 적용 - AI Playground 호환: ChatAgent 인터페이스를 구현한 Agent는 AI Playground에서 즉시 테스트 가능
- Streaming 지원:
predict_stream()메서드를 구현하면 토큰 단위 스트리밍 응답 자동 지원
Agent Evaluation (MLflow 기반)
Agent의 품질을 객관적으로 측정하기 위한 mlflow.evaluate() 기반 평가 프레임워크입니다. 단순히 메트릭 숫자를 보여주는 것을 넘어, 어떤 기준으로 왜 그 점수가 나왔는지 를 추적할 수 있는 체계적인 Scorer 시스템을 제공합니다. Scorer 시스템: Agent Evaluation은 내장 Scorer(Built-in Scorer) 와 커스텀 Scorer 를 조합하여 평가합니다. 각 Scorer는 독립적으로 동작하여, 필요한 평가 항목만 선택적으로 사용할 수 있습니다. 아래 표는 주요 내장 Scorer의 역할과 평가 방식을 정리한 것입니다.
평가는 LLM-as-a-Judge 방식으로 자동화됩니다. Databricks가 제공하는 강력한 Judge LLM이 Agent의 답변을 채점하며, 각 점수에 대한 이유(rationale) 도 함께 반환하여 디버깅이 가능합니다.
참고 Ground Truth가 없는 초기 단계에서도 Groundedness, Relevance, Safety 는 평가 가능합니다. 이후 사용자 피드백이나 SME 리뷰를 통해 Ground Truth를 점진적으로 구축하면 Correctness 평가를 추가할 수 있습니다.
AI Playground
AI Playground 는 Databricks UI에서 다양한 LLM을 즉시 테스트할 수 있는 대화형 인터페이스입니다. Foundation Model APIs, External Models, 파인튜닝한 커스텀 모델 등 Model Serving에 배포된 모든 모델을 별도 코드 없이 비교 테스트할 수 있습니다.8. MLOps 파이프라인
Databricks Jobs (스케줄링)
ML 모델을 프로덕션에서 운영하려면, 데이터 수집 → 피처 엔지니어링 → 학습 → 평가 → 배포라는 파이프라인이 자동으로 반복 실행 되어야 합니다. Databricks Jobs 는 노트북, Python 스크립트, JAR 등을 DAG(방향 비순환 그래프) 형태로 연결하고 스케줄링하는 워크플로 오케스트레이터입니다.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 워크플로를 단계별로 정리한 것입니다.
이 워크플로를 관통하는 핵심 원칙은 환경 분리 (Dev/Staging/Prod), 코드 기반 관리 (Git + DABs), 자동화 (Jobs + 트리거)입니다.
주의 MLOps 워크플로의 성숙도는 조직마다 다릅니다. 처음에는 수동 배포(Level 0)로 시작하고, 점진적으로 CI/CD 자동화(Level 1), 자동 재학습(Level 2)으로 발전시키는 것이 현실적입니다.
9. Databricks ML 기능 매핑 테이블
아래 표는 ML 라이프사이클의 각 단계에서 사용되는 Databricks 기능을 한눈에 보여줍니다. 새로운 ML 프로젝트를 시작할 때 이 표를 참고하여 필요한 기능을 빠르게 파악할 수 있습니다.10. 한계와 트레이드오프
모든 플랫폼에는 제약이 있으며, Databricks ML/AI도 예외는 아닙니다. 아래 표는 주요 고려사항을 정리한 것입니다.
이 한계를 이해하고 프로젝트 요구사항에 맞는 기능을 선택적으로 도입하는 것이 중요합니다.
다음 단계
- Classic ML 실습: 예지보전 & 이상탐지 MLOps 핸즈온 — 전체 MLOps 파이프라인을 직접 구축
- GenAI 이론: GenAI 핵심 개념 — LLM, Agent, Prompt Engineering 이론
- RAG 구축: RAG 가이드 — Vector Search + Agent 실전 구축
- ML 알고리즘: ML 트렌드 & 최신 기법 — 알고리즘 선택, 앙상블, 이상탐지 기법
- 모델 운영: 재학습 전략 — Drift 감지, 재학습 자동화 전략