[Upstage AI Lab] 9주차 - MLOps

들어가며

이번에는 MLOps에 대한 개념 정리와 실습 내용을 다룰 예정이다.
MLOps의 핵심 구성 요소들과, 실습을 통해 Docker 기반 환경 설정 및 명령어 흐름을 함께 정리했다.

MLOps

---

1. MLOps 란?

MLOps는 머신러닝의 개발과 운영을 연결하는 DevOps 확장 개념으로 모델 실험부터 배포 및 모니터링까지의 전 과정을 체계화하는 방법론이다.

MLOps는 단순한 도구 세트가 아니라 개발 문화이자 협업 전략이다.

• 모델 개발, 배포, 모니터링 자동화
• 일관된 환경 유지 (컨테이너 기반)
• 재현 가능한 실험과 협업 지원
• 안정적인 배포와 지속적인 개선 가능

2. MLOps가 필요한 이유

80%의 머신러닝 프로젝트가 실제 배포 전에 중단된다는 보고도 있다.
ML 프로젝트가 실제 서비스화되기까지 가장 흔히 겪는 문제는 다음과 같다.

• 개발 환경과 운영 환경의 차이
• 수작업 위주의 실험 및 버전 관리 실패
• 재현이 불가능한 실험 환경
• 배포 지연 및 성능 저하 후 추적 불가
• 이러한 문제를 해결하기 위해 MLOps는 필수적

3. MLOps 구조

MLOps는 단순히 모델을 잘 만들자는 것이 아닌, 어떻게 일관성 있게 운영하고 개선할 것인가에 대한 체계

출처: 마키나락스

• 각 단계는 자동화되어야 하며, 구성 요소는 서로 유기적으로 연결되어야 한다.
• 파이프라인 관리, 실험 추적, 버전 관리, 테스트 자동화 등이 포함된다.

MLOps 구성 요소

2021년 Google에서 발표한 Practitioner’s Guide to MLOps 문서에서는, 효과적인 MLOps 시스템을 위해
필요한 기능들을 다음과 같이 정리하고 있다.

Experimentation (실험)

• 버전 관리 도구와 연동된 노트북 환경 제공
• 실험 데이터, 하이퍼파라미터, 평가지표 추적
• 시각화 및 분석 도구 지원

Data Processing (데이터 처리)

• 다양한 소스의 데이터 인코더/디코더 및 커넥터 제공
• 배치 & 스트리밍 기반 전처리 및 피처 엔지니어링
• 학습/서빙을 위한 대규모 데이터 처리 지원

Model Training (모델 학습)

• ML 프레임워크 및 커스텀 런타임 환경 제공
• 분산 학습 및 다중 GPU 환경 지원
• 하이퍼파라미터 튜닝 및 AutoML 기능 제공

Model Evaluation (모델 평가)

• 테스트 데이터셋 기반 성능 평가
• 실험 및 서빙 모델의 예측 성능 추적
• Explainable AI 기반 성능 해석 및 비교

Model Serving (모델 서빙)

• 온라인/배치 서빙 모두 지원 (TensorFlow Serving, TorchServe 등)
• 전/후처리 파이프라인, 다중 모델 서빙 지원
• 오토스케일링, 로깅 기능 내장

Online Experimentation (온라인 실험)

• A/B 테스트, MAB, 캐너리 배포 지원
• 실시간 모델 성능 비교 및 트래픽 분산
• Model Registry와 연동된 배포 결정 가능

Model Monitoring (모델 모니터링)

• 지연 시간, 오류율, 리소스 사용량 추적
• 데이터 드리프트, 스키마 이상 탐지
• 모니터링 결과를 모델 평가 및 재학습과 연계

ML Pipeline (ML 파이프라인)

• 이벤트/스케줄 기반 자동 실행
• 파라미터 추적 및 아티팩트 저장
• 다양한 실행 환경 지원 (로컬, 클라우드 등)

Model Registry (모델 레지스트리)

• 모델 등록, 버전 관리, 배포 이력 추적
• 성능 지표 기반 모델 검토, 승인, 롤백
• 메타데이터 및 패키지 의존성 관리

Dataset & Feature Repository (데이터셋/피처 저장소)

• 데이터셋 및 피처의 공유, 검색, 재사용 가능
• 피처 버전 관리 및 지연 시간 최소화 설계
• 다양한 데이터 포맷(표, 이미지, 텍스트 등) 지원

ML Metadata & Artifact Tracking (메타데이터/아티팩트 추적)

• 실험, 파이프라인, 모델의 이력 및 메타데이터 관리
• 구성 파라미터, 실행 히스토리 추적
• 재현성과 디버깅을 위한 시각화 및 통합 기능 제공

4. 단계별 MLOps

Google은 MLOps의 발전 수준을 Level 0 ~ Level 2의 3단계로 구분했다.

Level 0: 수동 프로세스

• 특징
  • 데이터 분석, 모델 학습, 검증, 배포까지 모든 단계가 수동
  • 머신러닝 팀과 운영 팀이 분리되어 있음
  • 모델 배포는 비정기적이며 드물게 발생
  • 예측 결과 로깅이나 모니터링 시스템이 없음
• 도전 과제
  • 프로덕션 환경에서 모델 성능 저하 감지 어려움
  • 최신 데이터에 따른 재학습 필요
  • 수동 프로세스로 인해 개선 속도 느림

Level 1: ML Pipeline 자동화

• 특징
  • 개발/운영 환경 통일 → 전체 파이프라인 자동화
  • 실험 반복 속도 증가 및 자동 배포 가능
  • CT (Continuous Training) 기반
  • 데이터 검증 / 모델 검증 / 메타데이터 관리 / 특성 저장소(Feature Store) 포함
• 추가 구성 요소
  • 예상치 못한 입력 데이터를 감지하는 데이터 검증
  • 모델 성능 기준에 따라 배포 여부를 결정하는 모델 검증
  • 실행 이력 및 아티팩트를 저장하는 메타데이터 로깅
  • 일관된 학습/서빙 feature 제공을 위한 Feature Store

Level 2: CI/CD Pipeline 자동화

• CI (지속적 통합)
  • 코드 커밋 시 테스트 및 패키징 자동 수행
  • 특성 추출 로직, 모델 수렴, NaN 발생 여부 등 테스트
• CD (지속적 배포)
  • 프로덕션에 빠르게 반영
  • 모델/인프라 호환성, API 테스트, 부하 테스트 등 포함
• 핵심:
  • DevOps 수준의 자동화 수준을 ML 학습 파이프라인 전체에 적용
  • 코드 변경 → 학습 → 평가 → 자동 배포까지 연결됨

Docker

---

1. Container 란?

컨테이너는 개별 Software의 실행에 필요한 실행환경을 독립적으로 운용할 수 있도록 기반환경 또는 다른 실행환경과의 간섭을 막고 실행의 독립성을 확보해주는 운영체계 수준의 격리 기술

• 기존의 가상 머신(VM) 은 OS 전체를 가상화하지만
• 컨테이너는 필요한 애플리케이션과 환경만 격리하여 훨씬 가볍고 빠르게 실행된다.
• 특징
  • 애플리케이션 레벨 고립
  • 빠른 셋업 (VM 대비)
  • 적은 메모리 사용량
  • 마이그레이션 / 백업 / 전송 용이
  • 하드웨어 밀접 실행 → 성능 유리
  • 유지보수와 배포 용이성 향상
  • 전달 시간 단축

Ex: Python 3.10 환경에서 개발한 모델을 운영 서버에 배포할 때, 해당 컨테이너에 필요한 라이브러리, 코드만 포함하면 운영 서버가 어떤 OS든 관계없이 동일하게 실행 가능

2. 컨테이너와 가상머신(VM) 차이

컨테이너와 VM은 모두 격리된 환경에서 APP을 실행하기 위한 기술이지만, 구조와 실행 방식은 차이가 있다.

구조 비교

항목	가상머신(VM)	컨테이너(Container)
가상화 대상	전체 운영체제(OS)	애플리케이션 + 실행 환경만
크기	수 GB 단위 (OS 포함)	수 MB 단위 (필요한 부분만)
부팅 속도	느림 (OS 부팅 필요)	빠름 (즉시 실행 가능)
리소스 사용량	높음	낮음
실행 성능	비교적 낮음	하드웨어에 가까워 상대적으로 빠름
실행 개수 제한	호스트 자원에 따라 제한적	수백 개까지도 가능 (리소스 효율적 사용)
대표 기술	VMware, VirtualBox, Hyper-V	Docker, Podman, containerd

특히 MLOps에선 컨테이너가 VM보다 재현성과 이식성 측면에서 더 적합한 인프라로 쓰인다.

3. Docker 란?

Docker는 컨테이너 기반 가상화 기술로, APP 그 실행환경 전체를 하나의 단위로 포장하고 어디서든 일관된 방식으로 실행할 수 있게 해주는 플랫폼이다.

• 개발자가 설정한 Python, library, 설정 파일 등 전체 실행 환경을 하나로 묶어 배포 가능
• 운영체제(OS)에 의존하지 않고, 동일한 결과를 모든 시스템에서 재현할 수 있음
• 실행 환경이 일관되기 때문에 “내 PC에서는 되는데?” 문제를 근본적으로 방지할 수 있음
• 구성 요소
  • Image: 컨테이너 실행에 필요한 모든 설정과 파일이 포함된 패키지이며, 레이어 단위로 캐시 및 재사용 가능
  • Container: 이미지의 실행 인스턴스로, 독립된 실행 환경을 제공하며 실제 애플리케이션을 수행
  • Registry: 이미지를 저장하고 공유하는 공간으로, docker pull, docker push 등을 통해 접근
  • Volume: 외부 스토리지를 연결해주는 기능으로, 컨테이너 삭제 후에도 데이터를 유지할 수 있게 해줌

Docker 기본 구조

• Docker 클라이언트: 사용자가 명령어 입력 → 내부적으로 REST API 요청 발생
• Docker 데몬 (dockerd): 이미지 빌드, 컨테이너 실행 등 실제 작업 수행
• Docker 레지스트리: 이미지 저장소 (공용: Docker Hub / 개인: 프라이빗 레지스트리)

Docker Image 란?

• Docker 이미지란 컨테이너 실행에 필요한 파일과 설정값이 포함된 불변 패키지이다.
• 컨테이너는 이미지를 실행한 인스턴스로, 이미지는 변경되지 않고 상태 변화는 컨테이너에 저장된다.
• 같은 이미지로 여러 개의 컨테이너를 생성할 수 있다.
• Docker Image Layer 구조
  • Docker Image는 명령어 하나하나가 하나의 레이어로 구성된다.
  • 기존 레이어는 캐시되어 재사용되며, 변경된 부분만 새로 빌드된다.
  • 예를 들어, Ubuntu 이미지를 기반으로 Nginx만 추가하면 기존 레이어 위에 새로운 레이어만 추가된다.

Dockerfile 이란?

• Dockerfile은 이미지 생성을 위한 설계도다.
• Python 설치, requirements 설치, main.py 실행 같은 명령어들을 기술할 수 있다.
• 각 명령어는 이미지에 새로운 레이어를 형성하며, 수정 시 해당 레이어만 다시 빌드된다.
• 위 그림처럼, Dockerfile → Docker Image → Docker Container로 이어지는 구조는
  Docker의 기본 생애 주기이며, 이는 MLOps에서의 재현 가능한 실험 환경 구성에 핵심적인 역할을 한다.

요약

Docker는 컨테이너 기반 APP 실행을 위한 최적의 환경이며 Image와 Dockerfile을 통해
완전한 실험 재현성과 운영 자동화 기반을 제공

4. Docker 명령어

실제 MLOps 프로젝트를 운영할 때 자주 사용하는 Docker 명령어들을
컨테이너 준비 → 학습 실행 → 결과 추출 → API 서빙 흐름에 맞춰 정리했다.

1. 네트워크 생성 (선택)

# 사용자 정의 네트워크 생성 (게이트웨이 IP 지정 예시: 192.168.100.1)
docker network create --gateway 192.168.100.1 custom_network

2. 컨테이너 상태 확인

# 현재 실행 중인 컨테이너 목록 출력
docker ps

# 중지된 컨테이너 포함 전체 목록 출력
docker ps -a

3. 컨테이너 시작 및 접속

# 중지된 컨테이너 재시작
docker start container_name

# 실행 중인 컨테이너 내부 bash 쉘 접속
docker exec -it container_name bash

4. 컨테이너 이미지화 및 재실행

# 현재 컨테이너 상태를 이미지로 저장 (버전 명시 가능)
docker commit container_name container_name:v0

# 컨테이너 강제 삭제 (중지/실행 중 모두 포함)
docker rm -f container_name

# 저장한 이미지로 새 컨테이너 백그라운드 실행
docker run -itd --name container_name container_name:v0

5. 컨테이너 ↔ 로컬 파일 복사

# 컨테이너 내 /opt/mlops 디렉토리를 현재 경로로 복사
docker cp container_name:/opt/mlops .

6. 모델 학습 실행

# 컨테이너 내에서 모델 학습 실행 (모델명, epoch 지정)
docker exec -it container_name python src/main.py train --model_name movie_predictor --num_epochs 2

7. API 서버 실행

# API 서버 실행 (백그라운드 모드)
docker exec -d container_name bash start_api_server.sh

8. 컨테이너 로그 확인

# 컨테이너 로그를 실시간 확인
docker logs -f container_name

9. 이미지 목록 확인 및 삭제

# 현재 존재하는 이미지 목록 확인
docker images

# 불필요한 이미지 삭제
docker rmi container_name:v0

위 명령어는 MLOps 실험부터 서빙까지 반복되는 실무 흐름을 재현한 예시이다.
Docker 기반의 재현 가능한 워크플로우를 설계할 때 매우 유용하다.
단, 컨테이너 삭제 시 데이터가 사라질 수 있으므로, 결과는 꼭 Volume 또는 외부 저장소에 백업하자.