Related to: MLOps
ML 시스템의 진짜 문제
ML 프로젝트는 왜 이렇게 자주 실패할까요?
Google의 연구(Hidden Technical Debt in ML Systems)에 따르면, 실제 ML 시스템에서 ML 코드가 차지하는 비중은 5% 미만입니다. 나머지 95%는 데이터 수집, 피처 엔지니어링, 설정 관리, 서빙 인프라, 모니터링 등 ML 코드를 둘러싼 “보조 시스템”입니다.
[데이터 수집] → [피처 엔지니어링] → [ML 코드] → [서빙]
(5%)
↑___________________피드백 루프____________________↑
이 구조에서 발생하는 핵심 부채들:
- 데이터 종속성(Data Dependency): 업스트림 데이터 스키마 변경 시 조용히 모델 성능이 저하됨
- 피처 누수(Feature Leakage): 학습 시 미래 정보가 포함되어 실제 운영에서 성능 역전
- 분포 이동(Distribution Shift): 학습 데이터와 추론 데이터의 분포가 시간이 지남에 따라 달라짐
- 재현성 부족: “어제는 됐는데 오늘은 안 됨” — 환경, 라이브러리 버전, 랜덤 시드 미관리
MLOps가 필요한 이유
MLOps는 이 문제들에 대한 공학적 해답입니다.
전통 소프트웨어 vs ML 시스템의 차이
| 구분 | 전통 소프트웨어 | ML 시스템 |
|---|---|---|
| 코드 변경 → 동작 변경 | 명확 | 불명확 (데이터도 영향) |
| 배포 단위 | 코드 | 코드 + 데이터 + 모델 |
| 테스트 | 단위/통합 테스트 | + 데이터 검증, 모델 평가 |
| 실패 원인 | 주로 버그 | 버그 + 데이터 변화 + 드리프트 |
| 롤백 | 이전 버전 코드 | 이전 버전 코드 + 모델 + 데이터? |
MLOps가 다루는 세 가지 축
-
재현성 (Reproducibility)
-
자동화 (Automation)
- 데이터 수집 → 학습 → 평가 → 배포 → 모니터링의 파이프라인화
- 사람의 개입 없이 새 데이터로 자동 재학습
- 도구: Kubeflow, Airflow, GitHub Actions
-
관측 가능성 (Observability)
- 배포 후 모델이 “살아있는지” 지속적으로 확인
- 데이터 드리프트, 예측 분포 변화, 레이턴시 이상 감지
- 도구: Prometheus, Grafana, Evidently.ai
MLOps 성숙도: 어디서 시작할까
실제 현장에서는 완벽한 MLOps를 처음부터 구축하지 않습니다. Google이 정의한 MLOps 레벨을 기반으로 단계적으로 접근합니다:
Level 0 → 1 전환 (가장 임팩트가 큰 첫 단계)
- 실험 결과를 노트/스프레드시트 → MLflow로 이전
- 재현 가능한 학습 스크립트 작성
- 모델 아티팩트 버전 관리 시작
Level 1 → 2 전환
- 학습 파이프라인 자동화 (Kubeflow/Airflow)
- 모델 레지스트리 구축
- 배포 자동화 및 롤백 전략 수립
관련 개념
- MLOps — MLOps 핵심 구성요소 및 도구 상세
- Docker — ML 환경 컨테이너화
- Kubernetes — MLOps 배포 인프라
- MLflow - 기본 사용 — 실험 추적 실습
- ONNX(Open Neural Network Exchange) — 모델 포맷 표준화