MLOps 기초 (MLOps Basics)¶

개요¶

MLOps(Machine Learning Operations)는 ML 모델의 개발, 배포, 운영을 자동화하고 체계화하는 실천 방법이다. 소프트웨어 엔지니어링의 DevOps에서 영감을 받았으나, ML 특유의 요소(데이터 의존성, 모델 성능 변동, 실험 관리)를 추가로 다룬다. MLOps의 목표는 모델을 안정적이고 반복 가능하게 프로덕션에 전달하는 것이다.

핵심 개념¶

1. CI/CD for ML¶

소프트웨어 CI/CD와 달리, ML에서는 코드, 데이터, 모델 세 가지가 모두 버전 관리와 테스트의 대상이다.

flowchart LR
    A["코드 변경"] --> B["CI: 코드 테스트"]
    C["데이터 변경"] --> D["CI: 데이터 검증"]
    B & D --> E["학습 파이프라인"]
    E --> F["CI: 모델 검증"]
    F --> G["CD: 배포"]
    G --> H["모니터링"]
    H -.->|"트리거"| E

ML 파이프라인 테스트¶

배포 게이트(Performance Gate): 자동 배포 시 다음 조건을 만족해야 한다:

여기서 \(M_{\text{new}}\)는 새 모델의 성능, \(M_{\text{production}}\)은 현재 프로덕션 모델의 성능, \(\epsilon\)은 회귀 허용치(regression tolerance), \(M_{\text{min}}\)은 절대 최소 성능 기준이다. 두 조건을 동시에 충족해야 배포가 승인된다.

도구: GitHub Actions + DVC, Kubeflow Pipelines, Vertex AI Pipelines

2. 모델 모니터링 (Model Monitoring)¶

알림 설정: 성능이 임계값 이하로 떨어지거나, 시스템 지표가 비정상일 때 자동 알림을 발송한다. 성능 저하 알림의 정량적 기준은 다음과 같다:

여기서 \(M_{\text{current}}\)는 현재 성능 지표, \(M_{\text{baseline}}\)은 배포 시점의 기준 성능, \(\delta\)는 허용 임계값(예: 0.05, 즉 5%)이다. 비율 기반으로 설정하면 지표의 절대 크기에 관계없이 일관된 알림 기준을 유지할 수 있다.

3. 데이터 드리프트 탐지 (Data Drift Detection)¶

탐지 방법:

PSI (Population Stability Index)는 학습 시점과 현재 데이터의 분포 변화를 정량화한다:

여기서 \(B\)는 히스토그램 구간(bin) 수, \(p_i^{\text{actual}}\)은 현재 데이터의 비율, \(p_i^{\text{expected}}\)는 학습 데이터의 비율이다. PSI < 0.1이면 안정, 0.1~0.25이면 주의, > 0.25이면 유의한 분포 변화로 판단한다.

KS 검정(Kolmogorov-Smirnov Test)은 두 누적분포함수 간의 최대 차이를 측정한다:

여기서 \(F_{\text{train}}(x)\)는 학습 데이터의 누적분포함수, \(F_{\text{current}}(x)\)는 현재 데이터의 누적분포함수이다.

대응 전략: - 자동 재학습 파이프라인 - 적응적(incremental) 학습 - 모델 fallback / 규칙 기반 전환 - 알림 + 인간 개입

4. 모델 레지스트리와 버전 관리¶

stateDiagram-v2
    [*] --> Development: 실험/학습
    Development --> Staging: 검증 통과
    Staging --> Production: 승인
    Production --> Archived: 새 버전 배포
    Staging --> Development: 검증 실패
    Production --> Staging: 성능 저하 → 롤백

관리 대상: - 모델 아티팩트 (가중치, 설정) - 메타데이터 (학습 데이터 버전, 하이퍼파라미터, 메트릭) - 계보(lineage): 어떤 데이터/코드로 만들어졌는지

도구: MLflow Model Registry, SageMaker Model Registry

5. 인프라 패턴¶

6. MLOps 성숙도 모델 (Google)¶

graph LR
    L0["Level 0<br>수동 ML"] -->|"파이프라인 구축"| L1["Level 1<br>ML 파이프라인<br>자동화"]
    L1 -->|"CI/CD 추가"| L2["Level 2<br>CI/CD<br>파이프라인"]

    L0 -.- D0["Jupyter로 실험<br>수동 배포"]
    L1 -.- D1["자동 재학습<br>모니터링"]
    L2 -.- D2["자동 테스트/검증<br>자동 배포/롤백"]

상세 내용¶

MLOps 전체 아키텍처¶

graph TD
    subgraph "소스"
        CODE["코드 (Git)"]
        DATA["데이터 (DVC)"]
    end

    subgraph "CI/CD"
        TEST["코드 테스트"]
        DVAL["데이터 검증"]
        MVAL["모델 검증"]
    end

    subgraph "학습"
        ORCH["오케스트레이션<br>(Airflow)"]
        TRAIN["학습<br>(GPU 클러스터)"]
        EXP["실험 추적<br>(MLflow)"]
    end

    subgraph "배포"
        REG["Model Registry"]
        SERVE["서빙<br>(TorchServe)"]
        AB["A/B Router"]
    end

    subgraph "운영"
        MON["모니터링"]
        DRIFT["드리프트 탐지"]
        RETRAIN["재학습 트리거"]
    end

    CODE --> TEST
    DATA --> DVAL
    TEST & DVAL --> ORCH
    ORCH --> TRAIN
    TRAIN --> EXP
    TRAIN --> MVAL
    MVAL --> REG
    REG --> SERVE
    SERVE --> AB
    AB --> MON
    MON --> DRIFT
    DRIFT --> RETRAIN
    RETRAIN --> ORCH

실무 권장 사항¶

단계적 도입: 1. 시작: 실험 추적(MLflow/W&B) + Git 2. 다음: 자동화된 학습 파이프라인 + 데이터 검증 3. 이후: 모델 모니터링 + 자동 재학습 4. 성숙: 전체 CI/CD + A/B Testing + Feature Store

언제 사용하는가¶

흔한 오해와 함정¶

1. "MLOps는 대기업만 필요하다": 규모가 작아도 실험 추적과 기본적인 파이프라인은 초기부터 도입할 가치가 있다. 나중에 도입하면 기술 부채가 누적된다.

2. "자동 재학습만 하면 된다": 재학습 시 데이터 품질 검증, 성능 임계값 확인, 편향 검사가 함께 자동화되어야 한다. 잘못된 데이터로 재학습하면 성능이 악화된다.

3. "DevOps와 동일하다": ML 특유의 요소(데이터 버전, 모델 성능, 드리프트)를 추가로 관리해야 한다.

4. "도구를 많이 쓸수록 좋다": 도구 스택이 복잡해지면 관리 부담이 늘어난다. 필요한 것부터 단계적으로 도입하라.

5. "모니터링은 배포 후에 생각하면 된다": 모니터링은 설계 단계에서부터 고려해야 한다. 어떤 지표를 추적할지, 알림 기준은 무엇인지 미리 정의하라.

다른 주제와의 연결¶

• ML 파이프라인 설계: MLOps의 기반이 되는 파이프라인
• 실험 추적: MLOps의 핵심 구성 요소
• 모델 배포: 서빙 인프라와 최적화
• ML 시스템 설계 패턴: A/B Testing, Feature Store, 모니터링
• 흔한 실수: Training-Serving Skew
• 데이터 누수: 파이프라인에서 누수 방지
• LLM: LLM 서빙 및 모니터링의 특수성