[PYTHON] Training-Serving Skew 해결을 위한 3가지 전략과 데이터 불일치 방지 방법

Training-Serving Skew

 

머신러닝 모델을 배포한 후, 오프라인 테스트에서는 성능이 훌륭했음에도 실제 운영 환경에서 성능이 급격히 저하되는 현상을 겪어보셨나요? 이것이 바로 Training-Serving Skew(학습-서빙 불일치)입니다. 본 가이드에서는 Python 기반 MLOps 환경에서 이러한 병목 현상을 진단하고 해결하는 전문적인 기술적 접근법을 심층적으로 다룹니다.

---

1. Training-Serving Skew의 정의와 발생 원인

Training-Serving Skew는 모델 학습 시 사용된 데이터의 특성, 전처리 로직, 혹은 환경이 운영 환경(Inference)에서의 그것과 차이가 날 때 발생합니다. 이는 단순한 모델의 노화(Model Drift)와는 구별되는 개념으로, 주로 시스템 설계의 미비함에서 비롯됩니다.

주요 원인은 다음과 같습니다.

• 로직의 불일치: 학습 시에는 SQL이나 대용량 처리를 위해 Pandas를 썼지만, 운영 시에는 FastAPI와 같은 API 내부에서 순수 Python이나 다른 라이브러리로 전처리 로직을 재작성한 경우.
• 시간적 편향: 학습 시점에는 알 수 없었던 미래의 데이터(Future Leakage)가 특징량(Feature)에 포함된 경우.
• 데이터 소스 차이: 학습용 Batch 데이터와 실시간 스트리밍 데이터의 수집 방식이나 정밀도가 다른 경우.

2. 데이터 불일치 유형별 3가지 해결 전략 비교

문제의 원인에 따라 적용해야 할 아키텍처적 해결책이 다릅니다.

구분	공통 라이브러리 방식	피처 스토어(Feature Store) 도입	스키마 검증(TFX/Great Expectations)
핵심 개념	전처리 코드를 모듈화하여 공유	중앙 집중식 특징 관리 및 배포	데이터 구조 및 분포 실시간 검증
장점	구현 비용이 저렴하고 직관적임	학습/운영 데이터의 일관성 100% 보장	변화(Skew)를 즉각 감지하고 차단
단점	언어/프레임워크 제약 발생 가능	인프라 구축 및 유지보수 비용 높음	검증 오버헤드로 인한 응답 지연 발생
추천 상황	소규모 팀, 단일 언어 환경	대규모 모델 및 실시간 피처 사용 시	데이터 품질이 중요한 금융/의료 분야

---

3. 실무 적용을 위한 7가지 Skew 방지 솔루션 (Python Code)

개발자가 실제 서빙 파이프라인에서 데이터 정합성을 유지하기 위해 즉시 적용 가능한 예제입니다.

Example 1: Scikit-learn Pipeline을 활용한 전처리 로직 캡슐화

학습과 서빙에서 동일한 객체를 사용해 전처리 수치(Mean, Std 등)가 변하지 않도록 고정하는 방법입니다.

import joblib
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.ensemble import RandomForestClassifier

# 1. 학습 단계: 파이프라인 구성 및 저장
pipe = Pipeline([
    ('scaler', StandardScaler()),
    ('clf', RandomForestClassifier())
])
pipe.fit(X_train, y_train)
joblib.dump(pipe, 'model_pipeline.pkl')

# 2. 서빙 단계: 저장된 파이프라인 로드 (전처리 로직이 완벽히 일치함)
loaded_pipe = joblib.load('model_pipeline.pkl')
prediction = loaded_pipe.predict(new_inference_data)
        

Example 2: Great Expectations를 이용한 운영 데이터 스키마 해결

운영 환경으로 들어오는 데이터가 학습 데이터의 범위를 벗어나는지 실시간으로 검증합니다.

import great_expectations as ge

def validate_serving_data(df):
    ge_df = ge.from_pandas(df)
    # 학습 시 정의했던 기대 조건 검증
    validation_result = ge_df.expect_column_values_to_be_between(
        "age", min_value=0, max_value=120
    )
    if not validation_result["success"]:
        raise ValueError("Training-Serving Skew Detected: Age range mismatch")
    return True
        

Example 3: Feast(Feature Store) 기반 오프라인/온라인 피처 통합

학습과 서빙에서 동일한 피처 정의를 공유하여 로직 불일치를 해결하는 예시입니다.

from feast import FeatureStore

store = FeatureStore(repo_path=".")

# 서빙 환경에서 온라인 특징량 가져오기
feature_vector = store.get_online_features(
    features=["user_stats:avg_orders", "user_stats:last_login"],
    entity_rows=[{"user_id": 1001}]
).to_dict()

# 학습 시 사용했던 'user_stats' 정의와 100% 동일함을 보장
        

Example 4: TFX(TensorFlow Data Validation)를 통한 분포 차이 해결

학습 데이터셋(Statistics)과 운영 데이터셋 간의 Jensen-Shannon Divergence를 측정합니다.

import tensorflow_data_validation as tfdv

# 학습 데이터 통계 로드
train_stats = tfdv.generate_statistics_from_csv('train.csv')
# 운영 데이터 통계 생성
serving_stats = tfdv.generate_statistics_from_dataframe(serving_df)

# Skew 감지 (L-infinity distance 기반)
anomalies = tfdv.validate_statistics(statistics=train_stats, serving_statistics=serving_stats)
tfdv.display_anomalies(anomalies)
        

Example 5: Docker 컨테이너 기반 환경 일관성 유지 방법

라이브러리 버전 차이(예: Numpy 버전 차이로 인한 부동 소수점 오차)를 해결하기 위한 Dockerfile 전략입니다.

# 학습과 서빙에 동일하게 사용되는 베이스 이미지
FROM python:3.9-slim

WORKDIR /app
COPY requirements.txt .
# 의존성 고정 (Lock file 활용 권장)
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
# 서빙 엔진 실행 (예: FastAPI)
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]
        

Example 6: Custom Transformer를 활용한 피처 엔지니어링 동기화

복잡한 전처리를 클래스로 구조화하여 학습과 서빙에서 코드 중복 없이 사용합니다.

from sklearn.base import BaseEstimator, TransformerMixin

class DateFeatureExtractor(BaseEstimator, TransformerMixin):
    def fit(self, X, y=None):
        return self
    def transform(self, X):
        X = X.copy()
        X['hour'] = X['timestamp'].dt.hour
        return X.drop('timestamp', axis=1)

# 학습 시 fit_transform, 서빙 시 transform 호출
        

Example 7: Shadow Mode를 활용한 실제 운영 데이터 검증

모델을 실제 배포하기 전, 운영 데이터를 흘려보내 예측값의 분포를 학습 시와 비교합니다.

def shadow_predict(data):
    # Production 모델 결과 (기존)
    prod_res = prod_model.predict(data)
    # 신규 후보 모델 결과 (Skew 확인 대상)
    candidate_res = candidate_model.predict(data)
    
    # 두 결과의 분포 차이 기록 및 모니터링
    log_to_prometheus(prod_res, candidate_res)
    return prod_res # 실제 응답은 기존 모델로
        

---

4. 결론: 지속 가능한 MLOps를 위한 로드맵

Training-Serving Skew는 일회성 해결 과제가 아닌, 서비스 생명 주기 전반에 걸쳐 관리해야 할 리스크입니다. 가장 효과적인 해결 방법은 전처리 로직의 단일화(Code-as-Single-Source-of-Truth)와 실시간 모니터링 시스템의 결합입니다.

운영 환경에서 발생하는 데이터의 미묘한 변화를 감지하기 위해 데이터 유효성 검사 도구를 파이프라인에 내재화하십시오. 이는 단순한 버그 방지를 넘어, 비즈니스 신뢰도를 결정짓는 AI 서비스의 핵심 역량이 될 것입니다.

내용 출처 및 참고 문헌

• Google Cloud Architecture Center: "MLOps: Continuous delivery and automation pipelines in machine learning"
• TensorFlow Extended (TFX) Documentation - Data Validation
• "Reliable Machine Learning" by Cathy Chen et al. (O'Reilly Media)
• Feast Project