DVC 실험 추적 및 MLflow 통합 완벽 가이드

머신러닝 실험을 체계적으로 관리하고 추적하는 방법을 알아봅니다. DVC의 실험 기능과 MLflow를 연동하여 CI/CD 파이프라인까지 구축하는 전 과정을 다룹니다.

---

목차

1. dvc_exp_run으로_실험_실행
2. metrics와_plots_활용
3. 실험_결과_비교하기
4. DVC와_MLflow_조합_전략
5. CI_CD_파이프라인_구축
6. 자동화된_실험_관리

---

1. dvc exp run으로 실험 실행

김개발 씨는 머신러닝 팀에 합류한 지 한 달이 되었습니다. 오늘도 새로운 모델을 학습시키려고 하이퍼파라미터를 이리저리 바꿔가며 실험을 진행하고 있었습니다.

그런데 문득 깨달았습니다. "어제 시도했던 설정이 뭐였더라?" 노트북 여기저기 흩어진 메모를 뒤지며 한숨이 나왔습니다.

dvc exp run은 머신러닝 실험을 체계적으로 실행하고 추적하는 명령어입니다. 마치 실험실의 연구 노트처럼, 모든 실험 조건과 결과를 자동으로 기록해줍니다.

이것을 제대로 활용하면 수백 번의 실험도 깔끔하게 관리할 수 있습니다.

다음 코드를 살펴봅시다.

# dvc.yaml - 실험 파이프라인 정의
stages:
  train:
    cmd: python train.py
    deps:
      - data/train.csv
      - train.py
    params:
      - learning_rate
      - epochs
      - batch_size
    metrics:
      - metrics.json:
          cache: false
    plots:
      - plots/loss.csv:
          x: epoch
          y: loss

김개발 씨는 입사 후 처음으로 독자적인 머신러닝 프로젝트를 맡게 되었습니다. 이미지 분류 모델을 개선하는 업무였는데, 학습률, 에포크 수, 배치 크기 등 조정해야 할 파라미터가 한두 가지가 아니었습니다.

처음에는 엑셀에 실험 결과를 정리했습니다. 하지만 일주일이 지나자 스프레드시트는 난장판이 되어버렸습니다.

어떤 설정으로 학습한 모델이 어디에 저장되어 있는지, 그때 사용한 코드 버전은 무엇이었는지 도무지 알 수가 없었습니다. 선배 개발자 박시니어 씨가 다가와 물었습니다.

"김개발 씨, 혹시 DVC 써봤어요?" "DVC요? 데이터 버전 관리 도구 아닌가요?" "맞아요.

근데 실험 추적 기능도 정말 강력해요. dvc exp run 한번 써보세요." dvc exp run은 마치 타임머신과 같습니다.

과거의 어떤 실험이든 정확히 재현할 수 있고, 현재 진행 중인 모든 실험을 한눈에 볼 수 있습니다. 더 놀라운 점은 Git 브랜치를 별도로 만들지 않아도 된다는 것입니다.

기존 방식을 생각해보겠습니다. 새로운 하이퍼파라미터를 시도할 때마다 브랜치를 만들고, 커밋하고, 결과를 기록해야 했습니다.

실험이 100개라면 브랜치도 100개가 필요했습니다. 하지만 dvc exp run을 사용하면 이야기가 달라집니다.

모든 실험은 Git 참조로 가볍게 저장됩니다. 브랜치 없이도 수백 개의 실험을 관리할 수 있습니다.

마치 도서관 사서가 책을 분류하듯이, DVC가 모든 실험을 체계적으로 정리해줍니다. 위의 dvc.yaml 파일을 살펴보겠습니다.

stages 섹션에서 학습 파이프라인을 정의합니다. deps는 의존성 파일들을, params는 추적할 하이퍼파라미터를 지정합니다.

metrics와 plots는 결과물을 어떻게 저장할지 알려줍니다. 이제 실험을 실행하려면 터미널에 다음과 같이 입력합니다.

dvc exp run -S learning_rate=0.001 -S epochs=50이라고 치면 됩니다. -S 플래그로 파라미터를 동적으로 변경할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 추천 시스템을 개발한다고 가정해봅시다.

임베딩 차원, 레이어 수, 드롭아웃 비율 등을 다양하게 조합해봐야 합니다. dvc exp run을 사용하면 이 모든 조합을 체계적으로 실험하고 비교할 수 있습니다.

주의할 점도 있습니다. dvc.yaml 파일을 먼저 올바르게 설정해야 합니다.

의존성이나 출력 파일이 잘못 지정되면 실험 결과가 제대로 추적되지 않습니다. 다시 김개발 씨의 이야기로 돌아가봅시다.

dvc exp run을 도입한 후, 그의 실험 관리 방식이 완전히 바뀌었습니다. 더 이상 엑셀을 뒤지지 않아도 되었고, 언제든 과거 실험을 재현할 수 있게 되었습니다.

실전 팁

💡 - dvc exp run --queue로 여러 실험을 대기열에 추가하고 dvc exp run --run-all로 일괄 실행할 수 있습니다

• params.yaml 파일에 기본 하이퍼파라미터를 정의해두면 관리가 더 편해집니다
• 실험 실행 전 dvc repro --dry로 파이프라인이 올바른지 먼저 확인하세요

---

2. metrics와 plots 활용

김개발 씨가 모델 학습을 마쳤습니다. 터미널에 출력된 숫자들을 보며 고민에 빠졌습니다.

"정확도가 92.3%라는데, 이게 좋은 건가? 지난번 실험이랑 비교하려면 어떻게 해야 하지?" 결과를 눈으로 확인하는 것과 체계적으로 추적하는 것은 전혀 다른 문제였습니다.

metrics는 모델의 성능 지표를 JSON이나 YAML 형식으로 저장하고 추적하는 기능입니다. plots는 학습 과정이나 결과를 시각화할 수 있게 해줍니다.

이 두 기능을 활용하면 실험 결과를 한눈에 파악하고 비교 분석할 수 있습니다.

다음 코드를 살펴봅시다.

# train.py - 메트릭과 플롯 데이터 저장
import json
import csv

# 학습 완료 후 메트릭 저장
metrics = {
    "accuracy": 0.923,
    "precision": 0.918,
    "recall": 0.927,
    "f1_score": 0.922,
    "loss": 0.234
}
with open("metrics.json", "w") as f:
    json.dump(metrics, f, indent=2)

# 에포크별 손실값 저장 (플롯용)
with open("plots/loss.csv", "w", newline="") as f:
    writer = csv.writer(f)
    writer.writerow(["epoch", "train_loss", "val_loss"])
    for epoch, (train, val) in enumerate(loss_history):
        writer.writerow([epoch + 1, train, val])

박시니어 씨가 김개발 씨에게 물었습니다. "지난주에 돌린 실험이랑 오늘 실험, 어느 게 더 나아요?" 김개발 씨는 당황했습니다.

터미널 기록은 이미 사라진 지 오래였고, 어딘가에 적어둔 메모도 찾을 수가 없었습니다. 이런 상황이 반복되면서 김개발 씨는 결과 추적의 중요성을 뼈저리게 느꼈습니다.

DVC의 metrics 기능은 마치 성적표와 같습니다. 학생이 시험을 볼 때마다 성적이 기록되듯이, 모델이 학습될 때마다 성능 지표가 자동으로 기록됩니다.

나중에 언제든 꺼내볼 수 있습니다. 메트릭을 사용하려면 먼저 dvc.yaml에 metrics 섹션을 추가해야 합니다.

cache: false 옵션이 중요한데, 이렇게 설정해야 메트릭 파일이 항상 최신 상태로 유지됩니다. 학습 스크립트에서는 결과를 JSON 형식으로 저장합니다.

위 코드에서 볼 수 있듯이, accuracy, precision, recall 같은 주요 지표들을 딕셔너리로 만들어 파일에 씁니다. plots 기능은 또 다른 강력한 도구입니다.

학습 과정에서 손실값이 어떻게 변하는지, 정확도가 어떻게 향상되는지를 그래프로 볼 수 있습니다. 마치 주식 차트를 보듯이, 모델의 학습 추이를 한눈에 파악할 수 있습니다.

플롯 데이터는 주로 CSV 형식으로 저장합니다. 에포크마다 손실값을 기록하면, dvc plots show 명령어로 멋진 그래프가 생성됩니다.

HTML 파일로 출력되어 브라우저에서 바로 확인할 수 있습니다. 실무에서 이 기능이 빛을 발하는 순간이 있습니다.

바로 팀원들과 결과를 공유할 때입니다. "이번 모델이 저번보다 좋습니다"라고 말하는 것보다, 그래프를 보여주며 "여기 보시면 검증 손실이 20% 감소했습니다"라고 설명하는 것이 훨씬 설득력 있습니다.

한 가지 주의할 점이 있습니다. 메트릭 파일 경로가 dvc.yaml에 정의된 것과 정확히 일치해야 합니다.

경로가 다르면 DVC가 메트릭을 인식하지 못합니다. 터미널에서 dvc metrics show를 입력하면 모든 실험의 메트릭을 테이블 형태로 볼 수 있습니다.

dvc plots diff를 사용하면 여러 실험의 플롯을 겹쳐서 비교할 수도 있습니다. 김개발 씨는 이제 매 실험마다 메트릭과 플롯을 꼼꼼히 저장합니다.

덕분에 팀 미팅에서 자신감 있게 결과를 발표할 수 있게 되었습니다.

실전 팁

💡 - 메트릭 파일은 가볍게 유지하세요. 핵심 지표만 포함하고 상세 로그는 별도 파일로 분리하는 것이 좋습니다

• dvc plots modify 명령어로 x축, y축, 제목 등 그래프 스타일을 커스터마이징할 수 있습니다
• 여러 메트릭을 한 파일에 저장하면 관리가 편하고 비교도 쉬워집니다

---

3. 실험 결과 비교하기

김개발 씨의 실험 목록이 점점 늘어났습니다. 학습률을 바꾼 실험, 배치 크기를 조정한 실험, 레이어를 추가한 실험...

어느새 50개가 넘는 실험이 쌓였습니다. "이 중에서 제일 좋은 게 뭐지?" 하나하나 확인하자니 막막했습니다.

dvc exp show와 dvc exp diff는 여러 실험을 한눈에 비교할 수 있게 해주는 명령어입니다. 마치 스프레드시트처럼 모든 실험을 테이블로 정렬하고, 원하는 기준으로 필터링하고 정렬할 수 있습니다.

이를 통해 최적의 실험을 빠르게 찾아낼 수 있습니다.

다음 코드를 살펴봅시다.

# 터미널에서 실험 비교하기

# 모든 실험 목록 보기
dvc exp show --include-params=learning_rate,epochs
# ─────────────────────────────────────────────────
# Experiment      accuracy  f1_score  learning_rate  epochs
# workspace       0.923     0.922     0.001          50
# ├── exp-abc12   0.918     0.915     0.01           50
# ├── exp-def34   0.931     0.929     0.0005         100
# └── exp-ghi56   0.915     0.912     0.001          30

# 특정 실험과 현재 상태 비교
dvc exp diff exp-def34

# 성능 좋은 순으로 정렬
dvc exp show --sort-by=accuracy --sort-order=desc

# 최고 성능 실험을 브랜치로 승격
dvc exp branch exp-def34 best-model

어느 금요일 오후, 팀장님이 김개발 씨에게 다가왔습니다. "다음 주 월요일까지 가장 성능 좋은 모델로 배포 준비해주세요." 김개발 씨의 머릿속이 복잡해졌습니다.

50개가 넘는 실험 중 어떤 것이 최고인지 어떻게 알 수 있을까요? 박시니어 씨가 웃으며 말했습니다.

"dvc exp show 한 번 쳐봐요." 터미널에 명령어를 입력하자 마법 같은 일이 벌어졌습니다. 모든 실험이 깔끔한 테이블로 정렬되어 나타났습니다.

각 실험의 하이퍼파라미터와 성능 지표가 한눈에 들어왔습니다. dvc exp show는 마치 엑셀의 피벗 테이블과 같습니다.

원하는 열만 선택해서 볼 수도 있고, 특정 기준으로 정렬할 수도 있습니다. --include-params 옵션으로 보고 싶은 파라미터만 표시하면 화면이 훨씬 깔끔해집니다.

--sort-by 옵션은 정렬 기능입니다. dvc exp show --sort-by=accuracy --sort-order=desc라고 입력하면 정확도가 높은 순서대로 실험이 정렬됩니다.

가장 위에 있는 것이 최고 성능 모델입니다. 두 실험을 직접 비교하고 싶다면 dvc exp diff를 사용합니다.

이 명령어는 두 실험 사이의 모든 차이점을 보여줍니다. 어떤 파라미터가 달랐는지, 성능 지표가 얼마나 차이 나는지 상세히 알 수 있습니다.

실무에서 자주 쓰이는 패턴이 있습니다. 먼저 dvc exp show로 전체 현황을 파악합니다.

그다음 상위 3-4개 실험을 dvc exp diff로 세밀하게 비교합니다. 마지막으로 최적의 실험을 선택합니다.

최고의 실험을 찾았다면, 이제 정식으로 채택할 차례입니다. dvc exp branch 명령어가 바로 그 역할을 합니다.

임시 실험을 정식 Git 브랜치로 승격시켜줍니다. 이 브랜치는 다른 개발자와 공유하거나 배포에 사용할 수 있습니다.

dvc exp apply라는 명령어도 있습니다. 이것은 특정 실험의 변경사항을 현재 워크스페이스에 적용합니다.

브랜치를 만들지 않고 바로 작업을 이어가고 싶을 때 유용합니다. 주의할 점이 있습니다.

실험 데이터는 정기적으로 정리해주는 것이 좋습니다. dvc exp gc로 오래된 실험을 삭제할 수 있습니다.

너무 많은 실험이 쌓이면 저장 공간도 문제지만, 오히려 비교가 어려워집니다. 김개발 씨는 금방 최고 성능 실험을 찾아냈습니다.

학습률 0.0005에 에포크 100으로 설정한 실험이 정확도 93.1%로 가장 좋았습니다. 주말 동안 마음 편히 쉴 수 있게 되었습니다.

실전 팁

💡 - dvc exp show --csv로 결과를 CSV 파일로 내보내면 팀원들과 공유하기 편합니다

• 중요한 실험은 dvc exp branch로 브랜치를 만들어두세요. 임시 실험은 git gc로 사라질 수 있습니다
• --filter-by 옵션으로 특정 조건의 실험만 필터링할 수 있습니다

---

4. DVC와 MLflow 조합 전략

김개발 씨는 DVC에 완전히 익숙해졌습니다. 그런데 팀에서 새로운 요구사항이 생겼습니다.

"실험 결과를 웹에서 시각화하고, 모델을 체계적으로 저장하고, 팀원들이 실시간으로 진행 상황을 볼 수 있으면 좋겠어." DVC만으로는 한계가 있어 보였습니다.

MLflow는 머신러닝 라이프사이클 전체를 관리하는 플랫폼입니다. DVC의 강력한 데이터 버전 관리와 실험 추적 기능에 MLflow의 시각화 UI와 모델 레지스트리를 결합하면 완벽한 MLOps 환경을 구축할 수 있습니다.

두 도구는 경쟁 관계가 아니라 서로를 보완합니다.

다음 코드를 살펴봅시다.

# train.py - DVC와 MLflow 통합
import mlflow
import json
from dvclive import Live

# MLflow 서버 설정
mlflow.set_tracking_uri("http://localhost:5000")
mlflow.set_experiment("image-classification")

with mlflow.start_run():
    # DVCLive와 MLflow 동시 사용
    with Live(save_dvc_exp=True) as live:
        # 하이퍼파라미터 기록
        params = {"learning_rate": 0.001, "epochs": 50}
        mlflow.log_params(params)
        live.log_params(params)

        # 학습 루프
        for epoch in range(params["epochs"]):
            loss, acc = train_one_epoch(model, data)
            # 두 플랫폼에 동시 기록
            mlflow.log_metrics({"loss": loss, "accuracy": acc}, step=epoch)
            live.log_metric("loss", loss)
            live.log_metric("accuracy", acc)

        # 최종 모델 저장
        mlflow.pytorch.log_model(model, "model")

박시니어 씨가 새로운 도구를 소개했습니다. "MLflow라고 들어봤어요?

DVC랑 같이 쓰면 정말 좋아요." 김개발 씨는 고개를 갸웃거렸습니다. "둘 다 실험 추적 도구 아닌가요?

겹치는 기능이 많을 것 같은데요." "겹치는 부분도 있지만, 각자 잘하는 영역이 달라요." DVC와 MLflow의 관계를 이해하려면 요리사와 영양사를 생각해보면 됩니다. 요리사는 재료를 다루고 요리를 만드는 전문가입니다.

영양사는 완성된 음식의 영양 정보를 분석하고 기록합니다. 둘 다 음식과 관련된 일을 하지만, 전문 분야가 다릅니다.

DVC는 요리사와 같습니다. 데이터 파일을 버전 관리하고, 파이프라인을 정의하고, 코드와 데이터의 재현성을 보장합니다.

Git과 완벽하게 통합되어 개발자 워크플로우에 자연스럽게 녹아듭니다. MLflow는 영양사와 같습니다.

아름다운 웹 대시보드에서 실험 결과를 시각화합니다. 모델을 버전별로 저장하고 관리하는 레지스트리를 제공합니다.

배포까지 지원합니다. 두 도구를 함께 사용하면 시너지가 발생합니다.

DVC로 데이터와 파이프라인을 관리하고, MLflow로 실험 결과를 시각화하고 모델을 관리합니다. DVCLive 라이브러리를 사용하면 이 연동이 매우 쉬워집니다.

위의 코드를 살펴보겠습니다. **mlflow.start_run()**과 Live() 컨텍스트 매니저를 중첩해서 사용합니다.

하이퍼파라미터와 메트릭을 양쪽에 동시에 기록합니다. 이렇게 하면 DVC의 실험 추적과 MLflow의 웹 UI를 모두 활용할 수 있습니다.

실무에서 이 조합이 빛을 발하는 상황이 있습니다. 데이터 사이언티스트는 DVC로 로컬에서 빠르게 실험하고, 프로덕트 매니저는 MLflow 웹 UI에서 진행 상황을 확인합니다.

엔지니어는 MLflow 모델 레지스트리에서 배포할 모델을 선택합니다. 주의할 점도 있습니다.

두 도구를 모두 사용하면 관리 포인트가 늘어납니다. 팀 규모가 작다면 하나만 선택하는 것도 방법입니다.

하지만 팀이 크고 역할이 분화되어 있다면, 두 도구의 조합이 매우 효과적입니다. MLflow 서버는 mlflow server 명령어로 쉽게 실행할 수 있습니다.

기본적으로 5000번 포트에서 웹 UI가 제공됩니다. 팀원들은 브라우저로 접속해서 모든 실험을 살펴볼 수 있습니다.

김개발 씨는 이제 두 도구의 장점을 모두 활용합니다. 로컬에서는 DVC로 빠르게 실험하고, 팀과 공유할 때는 MLflow 대시보드를 보여줍니다.

실전 팁

💡 - DVCLive의 save_dvc_exp=True 옵션을 켜면 DVC 실험과 자동으로 연동됩니다

• MLflow 서버는 PostgreSQL이나 MySQL을 백엔드로 사용하면 더 안정적입니다
• 모델 레지스트리는 MLflow의 강점이니, 최종 모델 관리는 MLflow에 맡기는 것을 추천합니다

---

5. CI CD 파이프라인 구축

김개발 씨의 실험 관리 능력이 일취월장했습니다. 하지만 새로운 고민이 생겼습니다.

매번 수동으로 실험을 돌리고, 결과를 확인하고, 좋으면 배포하는 과정이 번거로웠습니다. "이걸 자동화할 수 없을까?" 김개발 씨는 CI/CD 파이프라인을 고민하기 시작했습니다.

CI/CD 파이프라인은 코드 변경 시 자동으로 테스트, 학습, 배포까지 수행하는 자동화 시스템입니다. DVC와 GitHub Actions 같은 CI 도구를 결합하면, 데이터나 코드가 변경될 때마다 자동으로 실험이 실행되고 결과가 기록됩니다.

이를 통해 수작업을 줄이고 일관성을 확보할 수 있습니다.

다음 코드를 살펴봅시다.

# .github/workflows/ml-pipeline.yml
name: ML Training Pipeline

on:
  push:
    branches: [main]
    paths:
      - 'data/**'
      - 'src/**'
      - 'params.yaml'

jobs:
  train:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install dependencies
        run: |
          pip install dvc dvc-s3 mlflow
          pip install -r requirements.txt

      - name: Pull DVC data
        run: dvc pull
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: Run experiment
        run: dvc exp run

      - name: Push results
        run: |
          dvc push
          git config user.name "github-actions"
          git config user.email "actions@github.com"
          dvc exp push origin

어느 날 팀에서 긴급 상황이 발생했습니다. 중요한 데이터가 업데이트되었는데, 모델 재학습을 깜빡했습니다.

구버전 모델이 프로덕션에서 며칠간 서비스되었습니다. 이 사건 이후 팀은 자동화의 필요성을 절감했습니다.

박시니어 씨가 말했습니다. "CI/CD 파이프라인을 구축합시다.

데이터가 바뀌면 자동으로 모델이 학습되도록요." CI/CD는 마치 공장의 컨베이어 벨트와 같습니다. 원재료가 투입되면 자동으로 가공, 검사, 포장이 진행됩니다.

사람이 일일이 개입하지 않아도 됩니다. 머신러닝에서는 데이터나 코드가 원재료이고, 학습된 모델이 완제품입니다.

위의 GitHub Actions 워크플로우를 살펴보겠습니다. on 섹션에서 트리거 조건을 정의합니다.

main 브랜치에 푸시될 때, data, src, params.yaml 파일이 변경되면 워크플로우가 실행됩니다. dvc pull 단계가 핵심입니다.

원격 저장소에서 데이터를 가져옵니다. DVC는 데이터를 Git이 아닌 별도 저장소(S3, GCS 등)에 보관합니다.

CI 환경에서도 이 데이터에 접근할 수 있어야 합니다. 그래서 AWS 자격증명을 시크릿으로 설정합니다.

dvc exp run은 실험을 실행합니다. dvc.yaml에 정의된 파이프라인이 순서대로 실행됩니다.

전처리, 학습, 평가가 자동으로 진행됩니다. 마지막으로 dvc push와 dvc exp push로 결과를 저장합니다.

학습된 모델과 메트릭이 원격 저장소에 업로드됩니다. 팀원들은 언제든 이 결과를 확인할 수 있습니다.

실무에서 흔히 사용하는 패턴이 있습니다. PR이 생성되면 가벼운 검증 실험을 돌립니다.

메인 브랜치에 머지되면 전체 학습을 실행합니다. 성능이 기준치를 넘으면 자동으로 스테이징 환경에 배포됩니다.

주의할 점이 있습니다. CI 환경에서는 GPU 사용이 제한적입니다.

GitHub Actions의 무료 러너는 GPU를 지원하지 않습니다. 대규모 학습은 AWS SageMaker나 자체 GPU 서버를 활용해야 합니다.

CML(Continuous Machine Learning)이라는 도구가 이 문제를 해결해줍니다. 또한 시크릿 관리에 신경 써야 합니다.

AWS 키, MLflow 서버 주소 같은 민감 정보는 절대 코드에 하드코딩하면 안 됩니다. GitHub Secrets를 활용하세요.

김개발 씨의 팀은 이제 자동화된 파이프라인을 운영합니다. 데이터가 업데이트되면 자동으로 알림이 오고, 새 모델이 학습되고, 결과 리포트가 생성됩니다.

더 이상 재학습을 깜빡할 일이 없습니다.

실전 팁

💡 - actions/cache를 사용해 pip 패키지를 캐싱하면 빌드 시간이 크게 단축됩니다

• CML을 사용하면 PR에 실험 결과 그래프를 자동으로 코멘트로 달 수 있습니다
• 민감한 데이터는 self-hosted runner를 사용해 사내 네트워크에서 처리하는 것이 안전합니다

---

6. 자동화된 실험 관리

김개발 씨는 CI/CD까지 구축했습니다. 이제 마지막 단계입니다.

"실험이 끝나면 자동으로 좋은 모델을 선택하고, 리포트를 만들고, 필요하면 배포까지 할 수 없을까?" 완전 자동화를 향한 마지막 여정이 시작되었습니다.

자동화된 실험 관리는 사람의 개입 없이 실험 실행부터 모델 선택, 배포까지 전 과정을 자동으로 수행하는 시스템입니다. 조건 기반 자동 배포, 알림 시스템, 주기적 재학습 등을 포함합니다.

이를 통해 ML 엔지니어는 모델 개선에만 집중할 수 있습니다.

다음 코드를 살펴봅시다.

# scripts/auto_experiment.py
import subprocess
import json
import requests

def run_experiment_and_decide():
    # 실험 실행
    subprocess.run(["dvc", "exp", "run"], check=True)

    # 현재 메트릭 로드
    with open("metrics.json") as f:
        current = json.load(f)

    # 프로덕션 메트릭과 비교
    prod_metrics = get_production_metrics()

    # 성능 향상 시 자동 배포 결정
    if current["accuracy"] > prod_metrics["accuracy"] * 1.02:
        # 2% 이상 향상되면 배포
        deploy_model()
        send_slack_notification(
            f"새 모델 배포 완료! 정확도: {current['accuracy']:.3f}"
        )
    else:
        send_slack_notification(
            f"실험 완료. 기존 모델 유지. 정확도: {current['accuracy']:.3f}"
        )

def send_slack_notification(message):
    webhook_url = os.environ["SLACK_WEBHOOK_URL"]
    requests.post(webhook_url, json={"text": message})

if __name__ == "__main__":
    run_experiment_and_decide()

팀 미팅에서 팀장님이 질문했습니다. "매주 새 데이터가 들어오는데, 매번 수동으로 실험하고 배포 여부를 결정하는 건 비효율적이지 않아요?" 모두가 고개를 끄덕였습니다.

자동화된 파이프라인이 있지만, 최종 결정은 여전히 사람이 내리고 있었습니다. 이 마지막 단계까지 자동화할 수 있다면 진정한 MLOps가 완성됩니다.

자동화된 실험 관리는 마치 자율주행 자동차와 같습니다. 목적지만 설정하면 차가 알아서 경로를 찾고, 장애물을 피하고, 안전하게 도착합니다.

MLOps에서는 목표 성능만 설정하면, 시스템이 알아서 실험하고, 평가하고, 배포합니다. 위의 코드를 살펴보겠습니다.

run_experiment_and_decide 함수가 핵심입니다. 먼저 dvc exp run으로 실험을 실행합니다.

그다음 현재 메트릭을 프로덕션 메트릭과 비교합니다. 2% 이상 성능이 향상되면 자동으로 배포합니다.

왜 2%라는 기준을 두었을까요? 미미한 성능 차이로 계속 배포하면 시스템이 불안정해집니다.

또한 측정 오차도 고려해야 합니다. 팀마다 적절한 임계값을 정해야 합니다.

알림 시스템도 중요합니다. 자동화되었다고 해서 사람이 완전히 손을 놓으면 안 됩니다.

슬랙이나 이메일로 결과를 통보받아야 합니다. 문제가 생기면 빠르게 대응할 수 있습니다.

실무에서 자주 사용하는 자동화 패턴을 소개합니다. 첫째, 스케줄 기반 재학습입니다.

매일 또는 매주 정해진 시간에 실험이 자동으로 돌아갑니다. 둘째, 트리거 기반 재학습입니다.

새 데이터가 일정량 이상 쌓이면 실험이 시작됩니다. 셋째, 성능 기반 재학습입니다.

프로덕션 모델의 성능이 떨어지면 자동으로 재학습합니다. GitHub Actions에서 스케줄을 설정하려면 cron 문법을 사용합니다.

**schedule: cron: '0 2 * * 1'**이라고 쓰면 매주 월요일 새벽 2시에 워크플로우가 실행됩니다. 주의할 점이 있습니다.

완전 자동화는 위험할 수 있습니다. 특히 중요한 프로덕션 시스템이라면, 마지막 배포 단계만큼은 사람의 승인을 받는 것이 좋습니다.

GitHub Actions의 environment와 required_reviewers 기능을 활용하면 됩니다. 또한 롤백 전략도 준비해야 합니다.

자동 배포된 모델이 문제를 일으키면 빠르게 이전 버전으로 되돌릴 수 있어야 합니다. MLflow 모델 레지스트리는 버전 관리를 지원하므로 롤백이 쉽습니다.

김개발 씨의 팀은 이제 완전 자동화된 MLOps 시스템을 운영합니다. 새 데이터가 들어오면 자동으로 학습하고, 성능이 좋으면 스테이징에 배포하고, 일주일간 모니터링 후 프로덕션에 올라갑니다.

팀원들은 모델 개선에만 집중할 수 있게 되었습니다.

실전 팁

💡 - 자동 배포에는 반드시 카나리 배포 또는 A/B 테스트를 적용해 위험을 분산하세요

• model decay 감지 로직을 추가해 프로덕션 모델 성능을 지속적으로 모니터링하세요
• 중요 시스템은 자동 배포 전 슬랙 승인 버튼을 추가하는 것도 좋은 방법입니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!