ML 시스템 설계 패턴 (ML System Design Patterns)¶

개요¶

ML 시스템 설계는 단순한 모델 학습을 넘어, 예측 서빙, A/B 테스팅, 특성 관리, 모니터링, 피드백 루프 등 프로덕션 환경의 전체적인 아키텍처를 설계하는 것이다. Google의 유명한 논문 "Hidden Technical Debt in Machine Learning Systems"에서 강조했듯이, ML 코드는 전체 시스템의 극히 일부이며, 나머지는 데이터 관리, 서빙, 모니터링 인프라이다.

핵심 개념¶

1. Online vs Batch Prediction¶

특성	Batch (오프라인)	Online (실시간)	Near-Realtime
처리 방식	주기적 대량 예측, 결과 저장	요청마다 즉시 예측	마이크로배치 (수초~수분)
지연시간	수분~수시간	수십 밀리초~수초	수초~수분
사용 예	추천 시스템, 보고서	사기 탐지, 검색 랭킹	뉴스 개인화
장점	간단, 복잡한 모델 사용 가능	최신 데이터 반영	균형 잡힌 접근
단점	데이터 신선도 낮음	인프라 복잡, 지연 제약	양쪽의 복잡성

선택 기준: 지연시간 요구사항, 데이터 신선도(freshness), 인프라 비용

2. A/B Testing¶

기존 모델(A)과 새 모델(B)을 동시에 서빙하여 성능을 비교한다.

설계 요소: - 통계적 유의성: p-value, 신뢰 구간, 최소 표본 크기 계산 - 트래픽 분배: 보통 50:50 또는 90:10 (위험 최소화) - 기간: 충분한 데이터 수집 + seasonality 고려

A/B 테스트의 최소 표본 크기(Minimum Sample Size)는 다음으로 결정된다:

\[n \geq \frac{(z_{\alpha/2} + z_{\beta})^2 \cdot 2\sigma^2}{\delta^2}\]

\(z_{\alpha/2}\): 유의 수준에 대응하는 z-값 (예: \(\alpha=0.05\)이면 \(z_{0.025}=1.96\))
\(z_{\beta}\): 검정력(power)에 대응하는 z-값 (예: power=0.8이면 \(z_{0.2}=0.84\))
\(\sigma^2\): 메트릭의 분산
\(\delta\): 탐지하고자 하는 최소 효과 크기 (Minimum Detectable Effect)

주의사항: - Novelty effect: 새 것에 대한 일시적 선호 - Seasonality: 계절/요일 패턴 고려 - Interference: 실험 그룹 간 상호 영향

Multi-Armed Bandit: Explore-exploit trade-off를 활용한 A/B Testing 대안. 더 좋은 모델에 점진적으로 더 많은 트래픽을 할당한다.

3. Shadow Deployment¶

새 모델의 예측을 실제 서비스에 반영하지 않고, 기록만 하여 기존 모델과 비교한다.

장점	단점
위험 없이 실환경 평가	사용자 반응 정보 부재
실제 트래픽으로 테스트	추가 인프라 비용
배포 전 성능 검증	시간 지연

4. Feature Store¶

ML 특성의 중앙 저장소로, 특성의 생성, 저장, 서빙을 통합 관리한다.

graph TD
    subgraph "Feature Store"
        OF["Offline Store<br>(배치 특성)"]
        ON["Online Store<br>(실시간 특성)"]
        REG["Feature Registry<br>(메타데이터)"]
    end

    RAW["원시 데이터"] --> PIPE["특성 파이프라인"]
    PIPE --> OF
    PIPE --> ON

    OF --> TRAIN["학습"]
    ON --> SERVE["서빙"]

    REG --> TRAIN
    REG --> SERVE

장점: - 특성 재사용: 여러 모델이 동일 특성 공유 - Online/Offline 일관성: Training-Serving Skew 방지 - 특성 발견: 팀 간 특성 공유와 검색

도구: Feast, Tecton, Vertex AI Feature Store

5. 프로덕션 모니터링 (Monitoring)¶

Data Drift (데이터 드리프트)¶

드리프트 유형	정의	탐지 방법
Covariate Shift	입력 분포 변화	PSI, KS test
Prior Probability Shift	클래스 비율 변화	클래스 분포 추적
Concept Drift	입출력 관계 변화 (가장 위험)	성능 지표 하락

탐지 도구:

PSI (Population Stability Index): 두 분포 간의 안정성 측정

\[\text{PSI} = \sum_{i=1}^{B}\bigl(p_i^{\text{new}} - p_i^{\text{ref}}\bigr) \ln\frac{p_i^{\text{new}}}{p_i^{\text{ref}}}\]

KS Test (Kolmogorov-Smirnov): 두 분포의 최대 차이 검정

\[D_{KS} = \sup_x |F_{\text{ref}}(x) - F_{\text{new}}(x)|\]

\(D_{KS}\)가 임계값 \(c(\alpha) \cdot \sqrt{\frac{n_1 + n_2}{n_1 \cdot n_2}}\)을 초과하면 분포 변화가 유의하다고 판단한다.

특성별 분포 비교: 히스토그램, 분위수 추적

대응 전략: - 자동 재학습 파이프라인 - 적응적(incremental) 학습 - 모델 fallback / 규칙 기반 전환 - 알림 시스템 구축

6. 피드백 루프 (Feedback Loops)¶

모델 예측이 미래 데이터에 영향을 미치는 현상이다.

예시: 추천 시스템 → 추천된 아이템만 클릭 데이터 생성 → 다음 학습에서 더 추천 → 선순환/악순환

문제: 자기 강화 편향, 다양성 감소, 필터 버블

완화: Exploration 메커니즘, 랜덤 노출 실험, 다양성 제약

상세 내용¶

ML 시스템 아키텍처 전체 그림¶

graph TD
    subgraph "데이터 플랫폼"
        DL["Data Lake"]
        DW["Data Warehouse"]
        FS["Feature Store"]
    end

    subgraph "학습 플랫폼"
        EXP["실험 추적<br>(MLflow, W&B)"]
        TRAIN["학습 파이프라인"]
        MR["Model Registry"]
    end

    subgraph "서빙 플랫폼"
        API["API 서버"]
        BATCH["배치 예측"]
        AB["A/B Test Router"]
    end

    subgraph "모니터링"
        MON["성능 모니터링"]
        DRIFT["드리프트 탐지"]
        ALERT["알림"]
    end

    DL --> FS
    FS --> TRAIN
    TRAIN --> EXP
    TRAIN --> MR
    MR --> API
    MR --> BATCH
    API --> AB
    AB --> MON
    MON --> DRIFT
    DRIFT --> ALERT
    ALERT -.-> TRAIN

Google MLOps 성숙도 모델¶

레벨	설명	특징
Level 0	수동 ML	스크립트 기반, 수동 배포, 모니터링 없음
Level 1	ML 파이프라인 자동화	지속적 학습, 자동 재학습
Level 2	CI/CD 파이프라인	코드+데이터+모델 전체 자동화, 자동 테스트

용량 계획 (Capacity Planning)¶

프로덕션 ML 시스템의 리소스 산정에 사용하는 정량적 공식이다.

QPS (Queries Per Second) 추정:

\[\text{QPS}_{\text{peak}} = \text{QPS}_{\text{avg}} \times \text{Peak Factor}\]

일반적으로 Peak Factor는 2~5배 사이이며, 서비스 특성에 따라 달라진다.

모델 서빙 인스턴스 수:

\[N_{\text{instances}} = \left\lceil \frac{\text{QPS}_{\text{peak}}}{\text{QPS}_{\text{per\_instance}}} \right\rceil \times (1 + \text{Redundancy Factor})\]

\(\text{QPS}_{\text{per\_instance}}\): 단일 인스턴스의 최대 처리량
Redundancy Factor: 장애 대비 여유분 (보통 0.2~0.5)

모델 메모리 요구량:

\[\text{Memory}_{\text{total}} = N_{\text{params}} \times B_{\text{precision}} + \text{Memory}_{\text{activation}} + \text{Memory}_{\text{KV-cache}}\]

\(N_{\text{params}}\): 모델 파라미터 수
\(B_{\text{precision}}\): 파라미터당 바이트 (FP32=4, FP16=2, INT8=1)
\(\text{Memory}_{\text{activation}}\): 추론 시 중간 활성화 메모리
\(\text{Memory}_{\text{KV-cache}}\): Transformer 모델의 경우 KV-cache 메모리 (배치 크기와 시퀀스 길이에 비례)

언제 사용하는가¶

패턴	적합한 상황
Batch Prediction	지연시간 덜 중요, 복잡한 모델, 주기적 업데이트
Online Prediction	실시간 결정 필요, 최신 데이터 반영
A/B Testing	새 모델의 비즈니스 영향 측정
Shadow Deployment	위험 최소화, 대규모 변경 검증
Feature Store	여러 모델이 특성 공유, 대규모 팀
자동 재학습	빈번한 데이터 변화, concept drift

흔한 오해와 함정¶

모니터링 없이 배포: 모델 성능은 시간이 지남에 따라 반드시 저하된다. 모니터링 없이 배포하면 성능 저하를 인지하지 못한다.
A/B Test의 통계적 유의성 무시: 충분한 데이터 없이 결론을 내리면 잘못된 의사결정을 한다. 최소 표본 크기를 사전 계산하라.
Feature Store 없이 대규모 ML: Feature Store 없이 여러 모델을 운영하면 특성 정의 불일치, Training-Serving Skew, 중복 작업이 발생한다.
피드백 루프를 인식하지 못함: 추천 시스템에서 인기 편향이 자기 강화되는 것처럼, 모델의 예측이 미래 데이터에 미치는 영향을 고려해야 한다.
자동 재학습만으로 충분하다: 재학습 시 데이터 품질 검증, 성능 임계값 확인, 편향 검사 등이 함께 자동화되어야 한다.

다른 주제와의 연결¶

ML 파이프라인 설계: 파이프라인의 프로덕션 확장
실험 추적: Model Registry와 배포 관리
모델 배포: 서빙 인프라와 압축
윤리적 AI: 피드백 루프와 공정성
흔한 실수: Training-Serving Skew
MLOps 기초: CI/CD, 모니터링의 자동화
데이터 누수: Feature Store로 누수 방지