MLOps

agnusdei·2025년 11월 7일

✨ MLOps (Machine Learning Operations)

1. MLOps의 정의 및 핵심 목표

1.1 정의

MLOps는 데이터 과학, ML 엔지니어링, DevOps를 결합한 학문 분야로, 복잡하고 끊임없이 변화하는 ML 워크로드의 특성을 다루기 위해 등장했습니다.

MLOps = ML + DevOps + Data Engineering

ML 모델은 일반적인 소프트웨어와 달리 Code (코드), Data (데이터), Model (모델) 세 가지 핵심 요소에 의존하며, 이 세 가지 모두 변화의 잠재적 원인이 될 수 있으므로, DevOps보다 더 복잡한 파이프라인 관리가 필요합니다.

1.2 핵심 목표

목표	설명
재현성 (Reproducibility)	모델 학습에 사용된 코드, 데이터, 환경 구성을 완벽하게 추적하고 재현할 수 있어야 합니다.
자동화 (Automation)	모델 학습, 검증, 배포 및 재학습에 이르는 모든 단계를 CI/CD (Continuous Integration/Continuous Delivery, 지속적 통합/지속적 제공) 파이프라인을 통해 자동화합니다.
지속적 통합/배포 (CI/CD)	새로운 기능, 데이터 또는 알고리즘 변경이 발생할 때마다 빠르고 안정적으로 모델을 업데이트하고 배포합니다.
거버넌스 및 규정 준수	학습 데이터와 모델 버전 관리를 통해 규제 요구사항(예: GDPR (General Data Protection Regulation))에 대한 추적 및 감사(Audit) 기능을 제공합니다.
품질 및 안정성	프로덕션 환경에서 모델의 성능 (Performance) 과 안정성 (Reliability) 을 지속적으로 보장합니다.

2. MLOps 성숙도 모델 (MLOps Maturity Model)

Google 등에서 제시한 MLOps 성숙도 모델은 조직이 MLOps를 적용하는 단계를 0부터 3까지 나누어 설명하며, 이는 MLOps 구현 전략의 로드맵 역할을 합니다.

단계	특징	자동화 수준	핵심 관심사
Level 0 (수동)	수동적이고 산발적인 프로세스. 데이터 과학자가 직접 노트북 환경에서 실험 후 수동 배포.	수동	개발 및 실험 속도
Level 1 (ML 파이프라인 자동화)	CI/CD 파이프라인은 없지만, ML 파이프라인 (특성 추출, 학습, 검증) 자체는 자동화됨. 실험 관리 시스템 도입.	부분 자동화	빠른 학습/재학습 주기
Level 2 (CI/CD 자동화)	ML 파이프라인과 CI/CD 파이프라인 모두 자동화됨. 코드가 변경되면 CI/CD 시스템이 자동으로 학습 및 배포를 트리거함.	완전 자동화	신뢰성 및 거버넌스
Level 3 (지속적 학습 및 운영)	Level 2 기반 위에 CD4ML (Continuous Deployment for ML)이 구현됨. 프로덕션 데이터 편향(Drift) 감지 시 자동 재학습 및 배포.	완전 자동화 + 자동 재학습	비즈니스 가치 극대화

3. MLOps의 핵심 구성 요소 및 파이프라인

MLOps 파이프라인은 크게 CI (지속적 통합), CD (지속적 배포), CT (지속적 훈련), CM (지속적 모니터링) 네 부분으로 구성됩니다.

3.1 지속적 통합 (Continuous Integration, CI)

ML 환경의 CI는 일반 소프트웨어와 달리 코드, 데이터, 모델 세 가지를 통합합니다.

컴포넌트 테스트: 특성 엔지니어링 코드, 모델 학습 코드, 배포 코드를 단위 테스트합니다.
파이프라인 테스트: 전체 ML 파이프라인 (데이터 추출 $\rightarrow$ 특성 변환 $\rightarrow$ 학습)이 올바르게 실행되는지 테스트합니다.
모델 테스트: 학습된 모델이 모델 품질 기준 (Model Quality Metrics) 을 만족하는지 검증합니다.

3.2 지속적 훈련 (Continuous Training, CT)

CT는 모델을 재훈련하고 새로운 버전을 생성하는 프로세스입니다.

데이터 검증: 입력 데이터의 스키마, 통계적 특성, 분포가 학습 시 사용된 데이터와 일치하는지 검증합니다.
특성 저장소 (Feature Store): 특성 추출 로직을 개발/운영 환경에서 공유하여 학습/서비스 편향(Serving-Training Skew) 을 방지합니다.
실험 관리: MLflow와 같은 도구를 사용하여 모델 학습 메타데이터(하이퍼파라미터, 성능 지표, 학습 아티팩트)를 추적하고 버전 관리합니다.
모델 레지스트리 (Model Registry): 학습이 완료되고 검증된 모델을 중앙 집중식으로 저장하고 버전 관리합니다.

3.3 지속적 제공/배포 (Continuous Delivery/Deployment, CD)

검증된 모델을 프로덕션 환경에 배포하는 과정입니다.

배포 전략:
- Canary Deployment (카나리 배포): 소수의 사용자에게 신규 모델을 먼저 노출하여 성능과 안정성을 테스트합니다.
- Blue/Green Deployment: 구 버전(Blue)과 신 버전(Green)을 동시에 운영하며, 트래픽 스위칭을 통해 안정적으로 전환합니다.
모델 서비스 (Model Serving): 모델을 RESTful API 또는 gRPC를 통해 서비스 형태로 노출하며, 낮은 Latency (지연 시간)와 높은 Throughput (처리량)을 보장해야 합니다.

3.4 지속적 모니터링 (Continuous Monitoring, CM)

배포된 모델의 성능과 데이터를 지속적으로 감시합니다.

운영 모니터링: 시스템 자원 사용량 (CPU, GPU, 메모리), 요청 Latency, 에러율 등 IT 운영 관점의 지표를 모니터링합니다.
모델 성능 모니터링:
- 데이터 편향 (Data Drift): 프로덕션 데이터의 통계적 분포가 학습 데이터와 달라지는 현상을 감지합니다.
- 개념 편향 (Concept Drift): 입력과 출력 사이의 관계(예: 사용자의 선호도 변화)가 달라져 모델 예측 정확도가 떨어지는 현상을 감지합니다.
- 지표 추적: 모델의 실제 예측 정확도, Precision (정밀도), Recall (재현율) 등의 비즈니스 지표를 추적합니다.

4. MLOps 구현을 위한 주요 기술

MLOps 환경을 구축하는 데는 다양한 도구와 기술이 사용되며, 이는 조직의 규모와 요구사항에 따라 달라집니다.

컨테이너화 및 오케스트레이션: Docker를 사용하여 환경 종속성을 제거하고, Kubernetes를 사용하여 ML 학습 및 서빙 파드를 대규모로 배포하고 관리합니다.
ML 파이프라인 관리: Kubeflow Pipelines, Apache Airflow, Azure ML Pipelines, SageMaker Pipelines 등을 사용하여 CT 파이프라인을 정의하고 실행합니다.
특성/데이터 버전 관리: DVC (Data Version Control)와 같은 도구를 사용하여 데이터셋을 버전 관리하고, Feature Store (예: Feast)를 사용하여 특성 관리를 통합합니다.
모델 서빙: TensorFlow Serving, TorchServe, Triton Inference Server 등을 사용하여 고성능으로 모델을 서비스합니다.

5. MLOps의 기술적 난제

MLOps는 일반적인 DevOps에 비해 다음과 같은 고유한 기술적 난제를 가집니다.

데이터 버전 관리 (Data Versioning): 코드가 아닌 대규모 데이터셋의 변경 사항을 추적하고 재현성을 보장하는 것은 매우 복잡합니다.
학습-서비스 편향 (Training-Serving Skew): 학습 환경과 프로덕션 서비스 환경 간의 데이터 처리 로직 불일치로 인해 모델 성능이 저하될 수 있으며, 이를 방지하는 것이 중요합니다.
환경 관리 (Environment Management): Python 라이브러리, GPU (Graphics Processing Unit) 드라이버 등 ML 종속성이 복잡하고 자주 충돌합니다. Docker 및 Kubernetes를 통한 환경 표준화가 필수적입니다.
모델 모니터링의 어려움: 소프트웨어는 고장 나면 멈추지만, ML 모델은 고장 나지 않고도 시간이 지남에 따라 점진적으로 예측 정확도가 떨어지므로, Data/Concept Drift를 감지하는 정교한 통계적 모니터링이 필요합니다.