MLOps 완전 정복: 머신러닝을 프로덕션으로
MLOps의 핵심 원칙, ML 시스템 생명주기, 주요 도구 스택을 체계적으로 정리하고 도입 전략을 제시합니다.
지난 글에서 LLM 편향과 독성 평가를 마무리하며 AI 시스템의 품질 측면을 살펴보았다. 이제 시선을 품질 평가에서 운영으로 넓혀, 머신러닝 모델이 어떻게 프로덕션에서 살아남는지 들여다보자.
연구 환경에서 90% 정확도를 자랑하던 모델이 프로덕션에 올라가는 순간 조용히 죽어버린 경험을 해본 적 있는가? 데이터 파이프라인이 바뀌었고, 피처 분포가 달라졌고, 누군가 라이브러리 버전을 올렸다. ML 시스템은 소프트웨어이면서 동시에 데이터에 종속된 생물체다. MLOps는 이 복잡성을 길들이는 엔지니어링 철학이다.
MLOps란 무엇인가
MLOps(Machine Learning Operations)는 DevOps의 원칙을 머신러닝 시스템에 적용한 엔지니어링 문화이자 기술 집합이다. DevOps가 개발(Dev)과 운영(Ops)의 사일로를 허물었듯, MLOps는 데이터 사이언스·ML 엔지니어링·운영 팀이 협력하여 모델을 빠르고 안정적으로 프로덕션에 배포·운영할 수 있도록 한다.
Google이 2015년에 발표한 논문 “Hidden Technical Debt in Machine Learning Systems”는 ML 프로젝트의 실제 코드가 전체 시스템의 극히 일부에 불과하고, 나머지 대부분이 인프라·파이프라인·모니터링 코드라는 사실을 보여줬다. MLOps는 이 “보이지 않는 빙산” 전체를 관리 가능하게 만든다.
DevOps와의 공통점과 차이점
DevOps와 MLOps는 CI/CD, 자동화, 모니터링, 버전 관리라는 핵심 원칙을 공유한다. 그러나 ML 시스템은 전통 소프트웨어에는 없는 독특한 복잡성을 가진다.
| 관심사 | DevOps | MLOps |
|---|---|---|
| 버전 관리 대상 | 코드 | 코드 + 데이터 + 모델 |
| 테스트 대상 | 기능 단위 | 데이터 유효성 + 모델 성능 |
| 배포 산출물 | 애플리케이션 바이너리 | 모델 아티팩트 + 서빙 코드 |
| 모니터링 지표 | 지연시간·에러율 | 예측 분포·데이터 드리프트 |
| 실패 원인 | 코드 버그 | 데이터 변화·모델 열화 |
DataOps는 MLOps의 데이터 파이프라인 측면을 강화한 개념이고, LLMOps는 LLM 특유의 프롬프트 관리·파인튜닝·평가 파이프라인을 추가한 상위 집합이다.
ML 시스템의 특수성
일반 소프트웨어와 달리 ML 시스템을 어렵게 만드는 두 가지 근본 속성이 있다.
1. 데이터 의존성
ML 모델의 동작은 코드와 데이터의 곱으로 결정된다. 코드가 동일해도 학습 데이터가 달라지면 완전히 다른 모델이 된다. 이것이 의미하는 바는 크다.
- 재현성 문제: “3개월 전에 학습한 모델을 다시 만들어달라”는 요청에 답하려면 당시의 데이터 스냅샷, 코드 버전, 환경 설정 모두가 보존되어야 한다.
- 데이터 드리프트: 프로덕션 입력 데이터의 분포가 학습 데이터와 점점 달라지면 모델 성능이 조용히 저하된다.
- 피처 파이프라인 의존성: 학습 시 피처를 계산하는 로직과 서빙 시 로직이 다르면(학습-서빙 스큐) 모델이 엉뚱한 예측을 한다.
2. 실험적 특성
소프트웨어 개발은 요구사항이 명확하다. ML 개발은 어떤 아키텍처가, 어떤 피처가, 어떤 하이퍼파라미터가 통할지 사전에 알 수 없다. 수십, 수백 번의 실험을 거쳐야 좋은 모델이 나온다. 이 실험들을 체계적으로 기록하지 않으면 어떤 조합이 왜 좋은 결과를 냈는지 알 수 없다. 실험 트래킹은 MLOps의 가장 기초적인 실천이다.
ML 생명주기의 6단계
MLOps는 ML 프로젝트 전체 생명주기를 자동화하고 관리한다. 각 단계를 구체적으로 살펴보자.
1단계: 데이터 수집·준비
모든 ML 프로젝트의 시작점. 원시 데이터를 수집하고, 정제하고, 레이블을 붙이고, 학습에 쓸 수 있는 형태로 변환한다.
- 데이터 수집: 데이터베이스, API, 스트리밍(Kafka), 크롤링
- 데이터 정제: 결측값 처리, 이상값 제거, 중복 제거
- 데이터 레이블링: 사람 주석(Label Studio, Scale AI), 약지도 학습
- 데이터 검증: Great Expectations, TFX Data Validation으로 스키마·분포 검증
2단계: 모델 학습
정제된 데이터로 모델을 훈련한다. 이 단계에서 실험 트래킹이 가장 중요하다.
- 피처 엔지니어링 및 피처 스토어 조회
- 모델 아키텍처 선택 (사이킷런, PyTorch, TensorFlow, HuggingFace)
- 하이퍼파라미터 최적화 (Optuna, Ray Tune)
- 분산 학습 (Horovod, DeepSpeed, PyTorch DDP)
3단계: 평가·검증
학습된 모델이 비즈니스 요구사항을 충족하는지 확인한다.
- 오프라인 평가: 홀드아웃 테스트셋으로 정확도·F1·AUC 등 측정
- 공정성 평가: 서브그룹 간 성능 격차 확인
- 모델 레지스트리 등록: 검증 통과 모델을 스테이징 상태로 등록
4단계: 배포
검증된 모델을 프로덕션 환경에 올린다.
- 배포 전략: 블루-그린, 카나리, 쉐도우 배포
- 서빙 방식: REST API(FastAPI + 모델), gRPC, 배치 추론, 엣지 배포
- 컨테이너화: Docker + Kubernetes로 스케일 아웃
5단계: 모니터링
배포된 모델의 상태를 지속적으로 추적한다.
- 성능 모니터링: 예측 정확도, 지연시간, 처리량
- 데이터 드리프트 감지: 입력 피처 분포 변화 감지 (Evidently, Alibi Detect)
- 개념 드리프트: 예측-레이블 관계의 변화 감지
- 알림: Slack, PagerDuty로 임계값 초과 시 알림
6단계: 피드백·재학습
모니터링에서 수집된 신호로 데이터를 보강하고 모델을 재학습시킨다.
- 능동 학습: 모델이 불확실한 샘플을 레이블링 큐에 추가
- 지속 학습: 스케줄 기반 또는 드리프트 감지 기반 재학습 트리거
- 데이터 플라이휠: 프로덕션 데이터가 다음 학습 데이터가 되는 선순환
MLOps 성숙도 모델
Google이 정의한 MLOps 성숙도 레벨은 조직이 현재 어디 있고 어디로 가야 하는지 이해하는 데 유용하다.
레벨 0: 수동 프로세스
대부분의 스타트업·중소기업이 여기서 시작한다.
- 모든 단계가 수동, 스크립트 기반
- 모델 재학습이 분기별·반기별로 이뤄짐
- 실험 결과를 스프레드시트나 노트로 관리
- 배포는 수동 zip 파일 복사
문제점: 재현 불가능, 협업 어려움, 배포 공포증(deploy fear)
레벨 1: ML 파이프라인 자동화
- 데이터 수집부터 모델 배포까지 파이프라인 자동화
- 실험 트래킹 도입 (MLflow, W&B)
- 모델 레지스트리 운영
- 재학습 트리거 자동화 (스케줄 또는 드리프트 감지)
도달 조건: 파이프라인 코드가 버전 관리되고, 새 데이터가 들어오면 자동으로 재학습이 돌아감.
레벨 2: CI/CD 파이프라인 자동화
MLOps의 완성형. 소프트웨어 CD와 ML 파이프라인이 완전히 통합된다.
- 모델 코드 변경 → 자동 테스트 → 자동 재학습 → 자동 평가 → 자동 배포
- 피처 스토어로 학습-서빙 스큐 제거
- A/B 테스트·카나리 배포 자동화
- 전체 ML 파이프라인이 자동으로 트리거되고 모니터링됨
핵심 도구 스택
인프라 & 컴퓨팅
Kubernetes가 ML 워크로드의 표준 오케스트레이터가 되었다. GPU 스케줄링, 자동 스케일링, 장애 복구를 처리한다. 클라우드별로는 AWS SageMaker, GCP Vertex AI, Azure ML이 관리형 ML 플랫폼을 제공한다.
데이터 레이어
**DVC(Data Version Control)**는 Git과 유사한 인터페이스로 대용량 데이터와 모델 아티팩트를 버전 관리한다. .dvc 파일만 Git에 커밋하고 실제 데이터는 S3·GCS·Azure Blob에 저장한다.
피처 스토어는 피처 계산 로직을 중앙화하여 학습-서빙 스큐를 방지한다. Feast(오픈소스), Tecton, Hopsworks가 주요 선택지다.
실험 관리
MLflow는 오픈소스 실험 트래킹의 사실상 표준이다. Weights & Biases는 딥러닝·연구 팀에서 인기 높고, Neptune은 엔터프라이즈 실험 거버넌스에 강하다. 다음 글에서 이 세 도구를 심층 비교한다.
파이프라인 오케스트레이션
Kubeflow Pipelines는 Kubernetes 위에서 ML 파이프라인을 정의하고 실행한다. ZenML은 파이프라인 코드를 다양한 인프라에서 실행할 수 있는 추상화 레이어를 제공한다. Prefect와 Airflow는 범용 데이터 파이프라인 오케스트레이터로 ML에도 활용된다.
서빙 & 모니터링
BentoML은 모델을 REST API로 감싸는 가장 직관적인 도구다. Seldon Core는 Kubernetes 네이티브 ML 서빙 플랫폼으로 A/B 테스트, 카나리 배포를 기본 지원한다. Evidently는 오픈소스 ML 모니터링 라이브러리로 데이터 드리프트 리포트를 생성한다.
MLflow 실전 예제
실험 트래킹의 가장 기본적인 형태를 코드로 보자.
import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
mlflow.log_param("n_estimators", 100)
mlflow.log_param("max_depth", 6)
model = RandomForestClassifier(n_estimators=100, max_depth=6)
model.fit(X_train, y_train)
accuracy = model.score(X_test, y_test)
mlflow.log_metric("accuracy", accuracy)
mlflow.sklearn.log_model(model, "model")
print(f"Run ID: {mlflow.active_run().info.run_id}")이 코드 몇 줄이 실험 트래킹의 전부다. mlflow ui 명령으로 브라우저에서 실험 대시보드를 열면, 각 실행의 파라미터·메트릭·아티팩트가 한눈에 비교된다. Run ID로 어떤 실험이든 재현할 수 있고, 가장 좋은 모델을 모델 레지스트리에 등록해 프로덕션으로 승격시킬 수 있다.
어디서 시작해야 하나: 실전 진입 전략
MLOps는 거대한 개념처럼 느껴지지만, 시작은 간단하다.
단계별 접근
1주차: 실험 트래킹 도입
가장 임팩트 크고 도입 비용이 낮다. 기존 학습 스크립트에 MLflow 5줄만 추가하면 된다. 팀 전체가 실험 결과를 공유할 수 있게 된다.
2-4주차: 데이터 버전 관리
DVC를 도입해 학습 데이터셋을 버전 관리한다. dvc add data/train.csv로 시작. 6개월 후 “그때 그 모델 재현해줘”라는 요청에 자신 있게 답할 수 있다.
1-2개월: 모델 레지스트리
MLflow Model Registry 또는 SageMaker Model Registry로 모델 버전을 관리한다. 스테이징→프로덕션 승격 프로세스를 정의한다.
3-6개월: 파이프라인 자동화
재학습 파이프라인을 코드로 정의하고 자동화한다. GitHub Actions + Python 스크립트로 시작해 필요 시 Kubeflow나 ZenML로 이전한다.
6개월 이후: 모니터링 & 드리프트 감지
Evidently로 주기적인 데이터 드리프트 리포트를 생성한다. 임계값 초과 시 재학습 파이프라인을 자동 트리거한다.
흔한 함정들
- 처음부터 완벽한 시스템 구축 시도: 레벨 0에서 레벨 2로 한 번에 뛰어가려다 포기하는 케이스가 많다. 작게 시작하고 점진적으로 확장하라.
- 도구 과잉: 모든 도구를 도입하려다 유지보수 부담만 커진다. 팀 규모와 요구사항에 맞는 최소한의 스택부터 시작하라.
- ML 코드만 버전 관리: 데이터와 모델도 함께 버전 관리해야 완전한 재현성이 보장된다.
마치며
MLOps는 ML 프로젝트를 “연구 프로토타입”에서 “운영 가능한 시스템”으로 격상시키는 엔지니어링 체계다. DevOps의 빠른 피드백 루프와 높은 신뢰성을 ML에 가져오는 것이 목표다.
처음 접하면 배울 것이 많아 압도되지만, 하나씩 도구를 추가하다 보면 자연스럽게 성숙도가 올라간다. 가장 중요한 첫 걸음은 실험 트래킹이다. 다음 글에서 MLflow·W&B·Neptune을 실전 코드와 함께 깊이 파고든다.
지난 글: LLM 편향과 독성 평가 다음 글: MLOps 실험 트래킹: 재현 가능한 ML 개발
읽어주셔서 감사합니다. 😊