책에 포함된 노트AI 교육 7권 : 재현 가능한 AI 시스템 운영: 데이터 엔지니어링·MLOps·LLM 운영 실무

재현 가능한 MLOps 프로젝트

2026-05-20Views 7약 6분생성형 AI 활용

Summary

이 장에서 배울 것

이번 장에서는 앞에서 배운 내용을 하나의 작은 프로젝트로 묶는다. 데이터 수집, 품질 검증, 버전관리, 실험 추적, 파이프라인, CI/CD/CT, 서빙, 모니터링, 장애 대응 문서를 모두 연결한다. 목표는 "내 컴퓨터에서는 됐다"가 아니라 "다른 사람이 새 환경에서 다시 실행해도 비교 가능한 결과가 나온다"이다.

최종 산출물은 코드 하나가 아니다. Git 저장소, DVC 데이터 상태, MLflow 실험 기록, 실행 가능한 파이프라인, 간단한 서빙 테스트, 모니터링 지표 초안, runbook, 비용 추정표, 회고문, AI 사용 로그까지 포함한다.

재현 가능한 MLOps 프로젝트

왜 이 주제가 중요한가

ML 프로젝트는 모델 성능표에서 끝나지 않는다. 운영에서는 시간이 지난 뒤 같은 모델을 다시 만들어야 하는 일이 자주 생긴다. 장애가 났을 때 "어떤 데이터와 코드로 이 모델이 만들어졌는가?"를 추적해야 한다. 감사나 보안 검토가 들어오면 "이 모델은 어떤 기준을 통과했는가?"를 설명해야 한다.

재현성은 같은 코드, 같은 데이터, 같은 환경, 같은 설정으로 실행했을 때 같은 실험 결과를 다시 얻을 수 있는 능력이다. MLOps에서는 디버깅, 협업, 감사, 롤백의 기본 조건이다¹. Google의 MLOps 문서도 ML 시스템의 CI가 코드뿐 아니라 데이터와 모델 검증까지 포함해야 하며, CT는 새 데이터로 모델을 자동 재학습하는 ML 고유의 속성이라고 설명한다².

이 장의 프로젝트는 완벽한 상용 시스템이 아니다. 대신 실무에서 반드시 필요한 뼈대를 만든다. 작은 프로젝트라도 재현 가능하게 만들 수 있어야 큰 시스템도 안정적으로 운영할 수 있다.

핵심 개념 설명

재현 가능한 MLOps 프로젝트는 여섯 가지를 고정한다.

첫째, 문제 정의를 고정한다. 예를 들어 "고객 이탈 여부를 예측한다"는 문제라면 입력 데이터, 예측 대상, 성공 지표, 배포 형태를 문서로 남긴다. 성공 지표는 단순히 정확도만 쓰지 않는다. F1, ROC-AUC, 지연 시간, 오류율, 비용 한도처럼 운영 지표도 함께 둔다.

둘째, 데이터 버전을 고정한다. 원천 데이터는 바뀔 수 있다. 따라서 학습에 사용한 데이터 스냅샷을 DVC로 추적한다. Git은 코드와 작은 메타데이터를 관리하고, DVC는 큰 데이터와 모델 산출물을 추적한다. Git 커밋과 DVC 상태를 함께 기록해야 "이 모델의 재료"를 되찾을 수 있다.

셋째, 실험 기록을 고정한다. MLflow에는 하이퍼파라미터, 메트릭, 모델 파일, 데이터 버전, Git 커밋, 실행 시간을 남긴다. 실험 추적은 나중에 성능 비교와 원인 분석을 가능하게 한다. 모델 레지스트리는 운영 후보 모델을 등록하고 승인 상태를 관리하는 장소다.

넷째, 실행 환경을 고정한다. Python 버전, 패키지 버전, 운영체제 차이 때문에 결과가 달라질 수 있다. requirements.txt, uv.lock, poetry.lock, Dockerfile 중 하나 이상으로 환경을 명시한다. GPU나 딥러닝 프레임워크를 쓰면 난수 시드와 비결정적 연산 설정도 기록한다.

다섯째, 파이프라인을 고정한다. 사람이 순서를 기억해서 실행하면 반드시 누락이 생긴다. 데이터 검증, 전처리, 학습, 평가, 등록, 배포 테스트를 DVC pipeline, Airflow DAG, GitHub Actions 중 하나로 연결한다. 핵심은 "정해진 명령 하나로 전체 흐름이 실행되는가"이다.

여섯째, 운영 기준을 고정한다. 장애 대응 runbook, 롤백 절차, 모니터링 지표, drift 대응 기준, 비용 추정표를 프로젝트 안에 둔다. 모델은 배포 후에도 계속 관찰되어야 한다. MLOps 원칙에서는 버전관리, 자동화, 테스트, 모니터링이 ML 자산을 소프트웨어 자산처럼 다루기 위한 핵심 실천이라고 본다³.

쉬운 비유 또는 사례

재현 가능한 MLOps 프로젝트는 음식점의 표준 조리법과 비슷하다.

맛있는 음식을 한 번 만드는 것은 어렵지만 가능하다. 그러나 매일 같은 맛을 내고, 문제가 생기면 어떤 재료가 바뀌었는지 찾고, 다른 지점에서도 같은 품질을 내는 것은 전혀 다른 문제다.

모델도 같다. 노트북에서 높은 성능을 한 번 얻는 것은 시작일 뿐이다. 데이터라는 재료, 전처리라는 손질법, 학습 코드라는 조리법, Docker라는 주방 환경, MLflow라는 조리 기록, 모니터링이라는 고객 반응 기록이 함께 있어야 운영 가능한 시스템이 된다.

직접 해보는 실습

아래는 최종 미니 프로젝트의 권장 구조다.

mlops-mini-project/
  README.md
  Makefile
  requirements.txt
  Dockerfile
  dvc.yaml
  params.yaml
  .github/workflows/mlops.yml
  data/
    raw/
    processed/
  models/
  reports/
  src/
    data_validate.py
    preprocess.py
    train.py
    evaluate.py
    register_model.py
    serve.py
  tests/
    test_data_schema.py
    test_smoke_train.py
  monitoring/
    dashboard_draft.md
    drift_policy.md
  ops/
    runbook.md
    rollback.md
    cost_estimate.md
    rca_template.md
  logs/
    ai_usage_log.md

먼저 프로젝트 계약서를 작성한다. README.md에 다음 항목을 넣는다.

문제: 고객 이탈 예측
데이터 출처: 공개 CSV 또는 사내 샘플 데이터
목표 지표: F1 >= 0.75
배포 형태: FastAPI 실시간 API 또는 배치 예측
품질 기준: 필수 컬럼 존재, 결측률 5% 이하, target 값 범위 검증
모니터링: 요청 수, 지연 시간, 오류율, 입력 분포, 예측 분포, F1 재평가
롤백 기준: 오류율 급증, 지연 시간 SLO 위반, 주요 지표 기준 미달

다음으로 저장소와 데이터 추적을 초기화한다.

git init
dvc init
pip install -r requirements.txt
python src/data_validate.py
python src/preprocess.py
dvc add data/raw data/processed
git add .
git commit -m "Initialize reproducible MLOps project"

params.yaml에는 학습 설정을 둔다.

seed: 42
train:
  test_size: 0.2
  model_type: random_forest
  n_estimators: 100
  max_depth: 8
evaluate:
  min_f1: 0.75

학습 코드에서는 반드시 MLflow에 기록한다.

import mlflow

with mlflow.start_run():
    mlflow.log_param("seed", 42)
    mlflow.log_param("n_estimators", 100)
    mlflow.log_param("data_version", "dvc-tracked")
    # train model
    mlflow.log_metric("f1", f1)
    mlflow.sklearn.log_model(model, "model")

DVC pipeline은 다음 흐름을 가진다.

stages:
  validate:
    cmd: python src/data_validate.py
    deps:
      - data/raw
      - src/data_validate.py
  preprocess:
    cmd: python src/preprocess.py
    deps:
      - data/raw
      - src/preprocess.py
    outs:
      - data/processed
  train:
    cmd: python src/train.py
    deps:
      - data/processed
      - src/train.py
      - params.yaml
    outs:
      - models/model.pkl
  evaluate:
    cmd: python src/evaluate.py
    deps:
      - models/model.pkl
      - data/processed
      - src/evaluate.py
    metrics:
      - reports/metrics.json

실행 명령은 단순해야 한다.

dvc repro
mlflow ui
python src/serve.py
curl -X POST http://localhost:8000/predict -H "Content-Type: application/json" -d @sample_request.json

마지막으로 GitHub Actions나 Airflow 중 하나로 자동 실행을 구성한다. 처음에는 GitHub Actions가 쉽다. PR이 열릴 때 단위 테스트, 데이터 스키마 테스트, 작은 샘플 학습, 평가 기준 검사를 실행한다. 운영 환경에 바로 배포하지 않아도 된다. 중요한 것은 변경이 들어올 때마다 재현성 검사가 자동으로 수행되는 것이다.

흔한 실수와 오류 분석

가장 흔한 실수는 데이터만 버전관리에서 빠지는 것이다. 코드가 같아도 데이터가 바뀌면 모델은 달라진다. 데이터 파일을 Git에 직접 넣을 필요는 없지만, 어떤 데이터 버전을 썼는지는 반드시 남겨야 한다.

두 번째 실수는 난수 시드를 고정하지 않는 것이다. train_test_split, RandomForest, PyTorch, TensorFlow처럼 무작위성이 들어가는 부분은 시드를 명시해야 한다. 다만 시드만으로 모든 환경 차이가 사라지는 것은 아니다. 패키지 버전과 하드웨어 설정도 함께 기록해야 한다.

세 번째 실수는 평가 기준을 나중에 정하는 것이다. 모델을 보고 나서 기준을 정하면 승인 게이트가 약해진다. 프로젝트 시작 시점에 "운영 후보가 되기 위한 최소 조건"을 문서화해야 한다.

네 번째 실수는 운영 문서를 부록처럼 다루는 것이다. runbook이 없으면 장애 때마다 사람이 새로 판단한다. 롤백 절차가 없으면 나쁜 모델을 오래 서비스한다. 비용 추정표가 없으면 불필요한 재학습과 과한 인스턴스 사용을 막기 어렵다.

다섯 번째 실수는 최종 실행을 자기 컴퓨터에서만 확인하는 것이다. 재현성 챌린지는 반드시 깨끗한 새 환경에서 해야 한다. 새 가상환경이나 새 컨테이너에서 저장소를 클론하고, 문서에 적힌 명령만 실행한다. 실패하면 "환경 문제", "데이터 원격 저장소 누락", "비밀값 누락", "패키지 버전 충돌", "경로 하드코딩" 중 어디에 속하는지 기록한다.

요약

재현 가능한 MLOps 프로젝트는 모델 파일 하나가 아니라 운영 가능한 생명주기다. 문제 정의, 데이터 버전, 실험 기록, 실행 환경, 자동 파이프라인, 운영 문서가 함께 있어야 한다.

최종 프로젝트의 기준은 간단하다. 다른 사람이 저장소를 클론했을 때 지정된 명령으로 같은 데이터 버전과 같은 설정을 불러오고, 비교 가능한 성능의 모델을 만들 수 있어야 한다. 또한 장애가 났을 때 어떤 지표를 보고, 누구에게 알리고, 어떤 조건에서 롤백할지 설명할 수 있어야 한다.

퀴즈

ML 프로젝트에서 Git만으로 재현성을 보장하기 어려운 이유는 무엇인가?
MLflow에 반드시 기록해야 할 실험 정보 세 가지를 말해보라.
깨끗한 새 환경에서 재현성 챌린지를 수행해야 하는 이유는 무엇인가?
모델 배포 후 모니터링해야 할 시스템 지표와 ML 지표를 각각 두 가지씩 말해보라.
runbook과 RCA 문서는 각각 어떤 상황에서 쓰이는가?

체크리스트

문제 정의, 데이터 출처, 성공 지표, 배포 형태를 README에 적었다.
데이터와 모델 산출물을 DVC로 추적했다.
하이퍼파라미터, 메트릭, 모델 아티팩트를 MLflow에 기록했다.
requirements.txt 또는 lock 파일과 Dockerfile로 환경을 고정했다.
데이터 검증, 전처리, 학습, 평가가 파이프라인으로 연결되어 있다.
평가 기준 미달 시 모델 등록이나 배포가 중단된다.
API 또는 배치 예측에 대한 최소 배포 테스트가 있다.
모니터링 지표와 drift 대응 기준을 문서화했다.
runbook, 롤백 절차, 비용 추정표, RCA 템플릿을 작성했다.
새 환경에서 클론 후 재실행하고 실패 원인을 기록했다.
AI 사용 로그 또는 검증 기록을 제출물에 포함했다.

다음 장 연결

이 장으로 7권의 핵심 흐름이 끝난다. 우리는 데이터 품질에서 시작해 버전관리, 실험 추적, 파이프라인, CI/CD/CT, 서빙, 모니터링, 장애 대응, 비용 관리까지 하나의 프로젝트로 묶었다.

다음 권으로 넘어가면 더 큰 AI 시스템을 다룰 수 있다. 특히 LLM 애플리케이션, 검색 증강 생성, 에이전트, 보안, 평가 자동화처럼 모델 하나를 넘어선 운영 문제가 중요해진다. 그러나 기준은 같다. 재현 가능해야 하고, 관찰 가능해야 하며, 자동화되어야 한다.

참고

¹7.0. Reproducibility - MLOps Coding Course

²MLOps: Continuous delivery and automation pipelines in machine learning

³MLOps Principles

책 목록

AI 교육 7권 : 재현 가능한 AI 시스템 운영: 데이터 엔지니어링·MLOps·LLM 운영 실무

전체 목차 보기