Skip to main content

​
1. Databricks ML/AI 플랫폼 전체 아키텍처

​
Data Intelligence Platform에서 ML의 위치

Databricks는 Data Intelligence Platform 이라는 비전 아래 데이터 엔지니어링, 분석, ML/AI를 하나의 Lakehouse 위에서 통합합니다. ML은 이 플랫폼의 핵심 축으로, 다음과 같은 이점을 제공합니다.
전통적 ML 환경 (분리된 도구)Databricks Lakehouse ML
데이터를 별도 ML 플랫폼으로 복사Delta Lake에 저장된 데이터를 직접 사용
실험 관리 도구 별도 구축 (자체 MLflow 서버)MLflow가 Workspace에 내장
모델 레지스트리를 별도 운영Unity Catalog에 모델을 데이터와 함께 거버넌스
서빙 인프라 별도 구축 (K8s, SageMaker 등)Model Serving Endpoint 내장
피처 스토어 별도 운영 (Feast, Tecton 등)Feature Engineering in Unity Catalog
이 통합의 핵심 가치는 데이터 이동 최소화 와 거버넌스 통합 입니다. 데이터 엔지니어가 만든 테이블을 데이터 사이언티스트가 바로 사용하고, 학습된 모델을 ML 엔지니어가 같은 플랫폼에서 배포하며, 모든 자산(데이터, 피처, 모델, 엔드포인트)이 Unity Catalog라는 단일 거버넌스 레이어로 관리됩니다.

​
Classic ML vs GenAI: 두 축의 역할

Databricks ML/AI 기능은 크게 두 축으로 나뉩니다.
구분Classic MLGenAI
대표 작업수치 예측, 분류, 이상 탐지, 추천자연어 이해/생성, 대화, 코드 생성, 이미지 분석
모델 유형XGBoost, LightGBM, RandomForest, PyTorchLLM (GPT, Claude, Llama), Embedding 모델
데이터 요구정형 데이터 수천~수만 건비정형 데이터 (텍스트, 이미지) + 대규모 사전학습
Databricks 기능AutoML, MLflow, Feature Store, ML RuntimeFoundation Model APIs, Agent Framework, Vector Search
비용 구조학습 1회 후 추론 저렴API 호출 시 토큰당 과금 또는 GPU 서빙 비용
실전에서는 두 축을 함께 사용하는 경우가 많습니다. 예를 들어, 제조 공정에서 이상 탐지(Classic ML)가 알람을 발생시키면 GenAI Agent가 원인을 분석하고 대응 보고서를 자동 생성하는 파이프라인이 가능합니다.

​
2. 데이터 준비 & Feature Engineering

​
왜 Feature Store가 필요한가

ML 모델의 성능은 알고리즘보다 피처(feature)의 품질 에 의해 결정되는 경우가 많습니다. 그러나 실전에서는 세 가지 근본 문제가 반복적으로 발생합니다.
  1. Training-Serving Skew: 학습 시에는 배치로 계산한 피처를 사용하고, 서빙 시에는 다른 코드로 실시간 계산하면서 미묘한 불일치가 발생합니다. 예를 들어, 학습 데이터에서는 “최근 30일 평균 구매액”을 SQL로 계산했는데, 서빙 코드에서는 API 호출 시점 기준으로 계산하여 윈도우가 달라지는 경우입니다.
  2. 피처 중복 개발: 데이터 사이언티스트 A가 만든 avg_purchase_amount 피처를 팀원 B가 모르고 다시 개발합니다. 조직 규모가 커질수록 동일한 비즈니스 개념에 대해 N개의 서로 다른 피처가 존재하게 됩니다.
  3. 피처 거버넌스 부재: 어떤 모델이 어떤 피처를 사용하는지, 피처 정의가 언제 변경되었는지 추적이 불가능합니다.
Workspace Feature Store에서 UC 기반으로 전환한 이유: 초기 Databricks Feature Store는 워크스페이스 단위로 격리되어 있어, 워크스페이스 간 피처 공유가 불가능했고 데이터 테이블과 별도의 거버넌스 체계를 사용했습니다. Unity Catalog 기반으로 전환하면서 피처 테이블이 일반 Delta 테이블과 동일한 3-level 네임스페이스 (catalog.schema.table)로 관리되고, GRANT/REVOKE 권한, Lineage 추적, 크로스 워크스페이스 접근이 모두 통합되었습니다. Databricks는 이 문제를 Feature Engineering in Unity Catalog 로 해결합니다.

​
Feature Engineering in Unity Catalog

구성 요소설명
Feature TableUnity Catalog에 등록된 Delta 테이블. 일반 테이블과 동일하게 SQL로 조회 가능하며, 기본 키(primary key)를 통해 피처 룩업이 가능
Feature FunctionUnity Catalog에 등록된 Python UDF를 피처로 직접 사용. 학습 시와 서빙 시 동일한 함수가 실행 되어 training-serving skew를 원천적으로 방지. 예: calculate_bmi(height, weight) 함수를 한 번 등록하면 배치 학습과 실시간 추론에서 동일한 로직이 적용됨
Feature Spec모델이 사용하는 피처 테이블 + 피처 함수의 조합을 정의한 메타데이터. 모델과 함께 Unity Catalog에 저장
작동 원리: FeatureEngineeringClient를 사용하여 학습 데이터셋을 생성할 때, 라벨 데이터와 피처 테이블을 자동으로 조인합니다. 이때 어떤 피처 테이블에서 어떤 키로 조인했는지가 모델에 기록되어, 서빙 시 동일한 피처를 자동으로 조회합니다. 
from databricks.feature_engineering import FeatureEngineeringClient, FeatureLookup

fe = FeatureEngineeringClient()

# 피처 룩업 정의
feature_lookups = [
    FeatureLookup(
        table_name="catalog.schema.sensor_features",
        feature_names=["avg_temperature", "vibration_rms"],
        lookup_key="device_id"
    )
]

# 학습 데이터셋 생성 (라벨 + 피처 자동 조인)
training_set = fe.create_training_set(
    df=labels_df,
    feature_lookups=feature_lookups,
    label="failure"
)

​
Feature Serving (온라인 추론용)

배치 추론은 Delta 테이블에서 직접 피처를 읽으면 되지만, 실시간 추론 에서는 밀리초 단위의 응답이 필요합니다. Delta Lake는 분석 워크로드에 최적화된 열 기반(Columnar) 스토리지이므로, 단일 키로 한 행을 빠르게 조회하는 Point Lookup에는 적합하지 않습니다. Databricks Online Table 은 이 문제를 해결합니다. Delta 테이블의 데이터를 자동으로 고성능 키-값 저장소(내부적으로 RocksDB 기반)에 동기화 하여, Primary Key 기반 서브밀리초 수준의 조회를 가능하게 합니다. 사용자는 별도의 캐시 레이어(Redis, DynamoDB 등)를 구축할 필요 없이, Unity Catalog UI에서 클릭 몇 번으로 Online Table을 생성할 수 있습니다.
동기화 모드설명적합한 경우
Snapshot주기적으로 전체 테이블 복사피처 변경이 드문 경우
Triggered수동 또는 API 트리거로 증분 동기화배치 파이프라인 완료 후 동기화
ContinuousDelta 변경 사항을 실시간(초 단위) 반영실시간 피처 업데이트가 필요한 경우
주의 Online Table은 Unity Catalog 관리형 테이블에서만 생성 가능합니다. 외부 테이블(External Table)에서는 지원되지 않습니다.