MLOps 기초 (MLOps Basics)

핵심 요약: ML 모델의 배포 → 모니터링 → 재학습 자동화가 MLOps이다. “모델도 관리가 필요한 살아있는 시스템” — 배포하고 방치하면 성능이 반드시 하락한다.

초보자를 위한 핵심 용어

MLOps: ML 모델의 개발, 배포, 운영을 자동화하고 체계화하는 실천 방법. DevOps의 ML 버전이다.
CI/CD for ML: 코드뿐 아니라 데이터와 모델까지 자동으로 테스트하고 배포하는 파이프라인.
Data Drift(데이터 드리프트): 시간이 지나면서 실제 데이터의 분포가 학습 데이터와 달라지는 현상. 모델 성능 하락의 주된 원인.
Model Registry(모델 레지스트리): 학습된 모델의 버전, 메타데이터, 배포 상태를 관리하는 중앙 저장소. “어떤 모델이 프로덕션에 있는지”를 추적한다.

개요

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

비유: MLOps는 모델의 건강관리 시스템이다. 정기 검진(모니터링)으로 이상 징후를 조기 발견하고, 예방접종(데이터 검증, 성능 임계값)으로 문제를 사전에 차단하며, 응급처치(롤백, fallback)로 장애 발생 시 빠르게 대응한다. 건강한 사람도 검진을 받듯이, 잘 작동하는 모델도 지속적 모니터링이 필요하다.

탄생 배경

MLOps 운동의 기폭제가 된 것은 2015년 Google이 발표한 논문 “Hidden Technical Debt in Machine Learning Systems”이다. 이 논문은 ML 시스템에서 실제 ML 코드가 전체 시스템의 극히 일부에 불과하며, 나머지는 데이터 수집, 검증, 특성 추출, 서빙 인프라, 모니터링 등의 “주변 코드”로 이루어져 있다는 충격적인 사실을 보여주었다.

이 논문이 제시한 핵심 문제들:

데이터 의존성: 코드보다 데이터 의존성이 훨씬 관리하기 어렵다. 외부 데이터 소스의 변경이 모델 성능을 예고 없이 떨어뜨린다
피드백 루프: 모델의 예측이 다시 학습 데이터에 영향을 미치는 순환 구조가 예상치 못한 동작을 유발한다
설정 부채: 하이퍼파라미터, 특성 목록, 전처리 파이프라인 등의 설정이 체계적으로 관리되지 않는다

이 논문 이후, Google은 TFX(TensorFlow Extended)를 공개했고, 업계에서는 MLflow, Kubeflow, Metaflow 등의 도구가 등장하며 MLOps 생태계가 빠르게 형성되었다. 2020년경부터 MLOps는 독립적인 분야로 자리 잡아, 전담 엔지니어(ML Engineer, MLOps Engineer) 역할이 업계에 확산되었다.

핵심 개념

1. CI/CD for ML

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

1. CI/CD for ML 다이어그램

ML 파이프라인 테스트

테스트 유형	대상	예시
데이터 검증	스키마, 분포, 범위	결측률 < 5%, 값 범위 확인
모델 검증	최소 성능 임계값	F1 > 0.85, AUC > 0.90
편향 검사	그룹별 성능 차이	성별 간 FPR 차이 < 5%
통합 테스트	전처리 → 추론 파이프라인	End-to-end 추론 성공

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

$\text{Deploy if } M_{\text{new}} \geq M_{\text{production}} - \epsilon \quad \text{and} \quad M_{\text{new}} \geq M_{\text{min}}$

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

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

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

모니터링 유형	라벨 필요	지표
성능 모니터링	필요	Accuracy, F1, AUC
프록시 지표	불필요	예측 분포, 신뢰도 분포
시스템 지표	불필요	Latency, throughput, error rate, GPU 사용률

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

$\text{Alert if } \frac{M_{\text{current}} - M_{\text{baseline}}}{M_{\text{baseline}}} < -\delta$

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

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

드리프트 유형	정의	위험도
Covariate Shift	입력 분포 변화	중간
Prior Probability Shift	클래스 비율 변화	중간
Concept Drift	입출력 관계 변화	높음 (가장 위험)

탐지 방법:

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

$\text{PSI} = \sum_{i=1}^{B} (p_i^{\text{actual}} - p_i^{\text{expected}}) \cdot \ln\frac{p_i^{\text{actual}}}{p_i^{\text{expected}}}$

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

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

$D_{KS} = \sup_x |F_{\text{train}}(x) - F_{\text{current}}(x)|$

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

방법	설명	적용
PSI (Population Stability Index)	두 분포 간 안정성 측정	수치 특성
KS Test	두 분포의 최대 차이 검정	수치 특성
히스토그램/분위수 비교	시각적/정량적 비교	모든 특성
Adversarial Validation	학습/현재 데이터 구분 모델	전체적 분포 변화

대응 전략:

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

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

4. 모델 레지스트리와 버전 관리 다이어그램 관리 대상:

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

도구: MLflow Model Registry, SageMaker Model Registry

5. 인프라 패턴

패턴	설명	도구
Feature Store	Offline/online 특성 일관성	Feast, Tecton
Model Store	모델 바이너리 + 메타데이터 관리	MLflow, S3
Orchestration	파이프라인 스케줄링/실행	Airflow, Kubeflow, Prefect
Containerization	환경 재현성 보장	Docker, Kubernetes

6. MLOps 성숙도 모델 (Google)

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

상세 내용

MLOps 전체 아키텍처

MLOps 전체 아키텍처 다이어그램

실무 권장 사항

단계적 도입:

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

언제 사용하는가

상황	MLOps 수준
개인 연구/PoC	Level 0 (수동) + 실험 추적
소규모 팀, 단일 모델	Level 1 (파이프라인 자동화)
대규모 팀, 다수 모델	Level 2 (전체 CI/CD)
규제 산업 (금융, 의료)	Level 2 + 감사 추적
빈번한 데이터/모델 업데이트	Level 1~2 (자동 재학습)

실전 사례

6개월간 모니터링 없이 방치된 모델: 94% -> 71% 정확도 추락

한 이커머스 회사의 상품 추천 모델이 배포 시점에는 94% 정확도를 달성했으나, 6개월 후 비즈니스 팀의 불만이 제기되어 조사한 결과 정확도가 71%로 추락해 있었다. 원인 분석 결과:

Concept Drift: COVID-19 이후 소비자 구매 패턴이 급변했다. 기존에 “출장용 정장”을 자주 구매하던 직장인들이 “재택근무용 캐주얼”로 전환했지만, 모델은 여전히 정장을 추천하고 있었다
Covariate Shift: 새로운 상품 카테고리(홈오피스 가구, 운동 기구)가 대량 추가되었지만, 학습 데이터에는 이런 카테고리가 거의 없었다
데이터 파이프라인 장애: 3개월 전부터 일부 사용자 행동 로그가 누락되고 있었지만, 아무도 인지하지 못했다

이 회사가 사후에 도입한 MLOps 체계:

PSI 기반 드리프트 모니터링: 주요 특성의 분포 변화를 매일 감시하고, PSI > 0.25 시 자동 알림 발송
성능 프록시 지표: 실제 라벨이 없어도 예측 분포의 엔트로피와 신뢰도 분포를 모니터링하여 이상 징후를 조기 감지
자동 재학습 파이프라인: 월 1회 자동 재학습 + 성능 게이트를 통과한 모델만 자동 배포
데이터 품질 검사: 입력 데이터의 스키마, 결측률, 범위를 자동 검증하여 파이프라인 장애를 즉시 감지

도입 후 모델 정확도는 90% 이상으로 안정적으로 유지되었으며, 드리프트 발생 시 평균 2일 이내에 자동 대응이 이루어지게 되었다.

흔한 오해와 함정

“MLOps는 대기업만 필요하다”: 규모가 작아도 실험 추적과 기본적인 파이프라인은 초기부터 도입할 가치가 있다. 나중에 도입하면 기술 부채가 누적된다.
“자동 재학습만 하면 된다”: 재학습 시 데이터 품질 검증, 성능 임계값 확인, 편향 검사가 함께 자동화되어야 한다. 잘못된 데이터로 재학습하면 성능이 악화된다.
“DevOps와 동일하다”: ML 특유의 요소(데이터 버전, 모델 성능, 드리프트)를 추가로 관리해야 한다.
“도구를 많이 쓸수록 좋다”: 도구 스택이 복잡해지면 관리 부담이 늘어난다. 필요한 것부터 단계적으로 도입하라.
“모니터링은 배포 후에 생각하면 된다”: 모니터링은 설계 단계에서부터 고려해야 한다. 어떤 지표를 추적할지, 알림 기준은 무엇인지 미리 정의하라.

다른 주제와의 연결

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