모델 버전 관리 인프라: 대규모 ML 아티팩트 관리

2025년 12월 11일 업데이트

2025년 12월 업데이트: MLflow 3.0이 생성형 AI와 AI 에이전트를 위해 레지스트리를 확장하고 있습니다—모델을 정확한 코드 버전, 프롬프트, 평가 실행, 배포 메타데이터와 연결합니다. 이제 모델 버전 관리는 단순히 가중치뿐만 아니라 파인튜닝된 어댑터, 프롬프트 템플릿, 검색 구성까지 추적합니다. 수백 GB에 달하는 가중치를 가진 LLM은 Git을 넘어서는 전문 인프라가 필요합니다.

MLflow 3.0은 생성형 AI 애플리케이션과 AI 에이전트를 처리하도록 모델 레지스트리를 확장하여 모델을 정확한 코드 버전, 프롬프트 구성, 평가 실행, 배포 메타데이터와 연결했습니다.¹ 이러한 발전은 "모델 버전 관리"의 의미가 근본적으로 변화했음을 반영합니다—단순한 pickle 파일 추적에서 다수의 파인튜닝된 어댑터, 프롬프트 템플릿, 검색 구성을 포함하는 복잡한 시스템 관리로 전환되었습니다. 프로덕션 AI를 운영하는 조직에는 가중치뿐만 아니라 모델을 안정적으로 재현하고 배포하는 데 필요한 전체 컨텍스트를 버전 관리하는 인프라가 필요합니다.

기존 소프트웨어 버전 관리와 달리 ML 모델 버전 관리는 대용량 바이너리 파일, 복잡한 학습 구성, 데이터셋 버전, 평가 지표를 추적하면서 재현성과 규정 준수 요구사항을 유지해야 합니다.² 파인튜닝된 모델이 급격히 증가하고 프롬프트 엔지니어링이 버전 관리가 필요한 또 다른 아티팩트 레이어를 추가하는 LLM에서는 이 도전이 더욱 복잡해집니다.

모델 버전 관리가 중요한 이유

프로덕션 ML 시스템은 조용히 실패합니다. 모델은 시간이 지나면서 성능이 저하되고, 파인튜닝된 버전이 예기치 않게 성능이 떨어지며, 적절한 버전 관리 없이는 팀이 무엇이 변경되었는지 파악하거나 알려진 정상 상태로 롤백할 수 없습니다.

버전 관리의 도전 과제

바이너리 아티팩트: 모델 가중치는 고전적인 ML의 메가바이트에서 대규모 언어 모델의 수백 기가바이트까지 다양합니다. Git은 이러한 파일을 효율적으로 처리할 수 없어 전문 인프라가 필수가 됩니다.

구성 폭발: 단일 모델은 학습 코드, 하이퍼파라미터, 데이터 전처리, 피처 엔지니어링, 배포 구성을 포함합니다. 어떤 변경이든 잠재적으로 모델 동작에 영향을 미칩니다.

데이터셋 의존성: 모델 품질은 학습 데이터에 의존합니다. 데이터셋 버전 관리 없이는 동일한 코드로도 모델 재현이 불가능해집니다.

평가 결합: 특정 테스트 세트에 대한 성능 지표가 배포 결정을 결정합니다. 이러한 지표는 모델 버전에 영구적으로 연결되어야 합니다.

비즈니스 요구사항

재현성: 금융 및 의료 분야의 규제 요구사항은 특정 시점에 배포된 정확한 모델 버전을 재생성할 수 있는 능력을 요구합니다.³

감사 가능성: 규정 준수를 위해 배포된 모델을 학습 데이터, 코드, 배포를 승인한 의사결정자까지 추적해야 합니다.

롤백 기능: 프로덕션 인시던트 발생 시 몇 시간이 아닌 몇 분 내에 이전 모델 버전으로 되돌릴 수 있어야 합니다.

협업: 동일한 모델에서 작업하는 여러 데이터 과학자는 모델 아티팩트에 대한 명확한 소유권과 충돌 해결이 필요합니다.

모델 레지스트리 아키텍처

모델 레지스트리는 개발부터 프로덕션까지 ML 모델의 라이프사이클을 관리하는 중앙 저장소 역할을 합니다:⁴

핵심 구성요소

버전 관리: 각 모델 버전은 고유 식별자를 받으며, 일반적으로 모델 이름과 시맨틱 버전(v1.2.3) 또는 해시 기반 식별자를 결합합니다.

메타데이터 저장소: 학습 파라미터, 평가 지표, 데이터 계보, 배포 이력이 모델 아티팩트와 함께 저장됩니다.

아티팩트 저장소: 모델 가중치, 구성 파일, 관련 자산은 확장 가능한 오브젝트 스토리지(S3, GCS, Azure Blob)에 저장됩니다.

라이프사이클 관리: 모델은 개발, 스테이징, 프로덕션, 아카이브 단계를 거치며, 각 전환 단계에서 거버넌스 제어가 적용됩니다.

레지스트리 워크플로우

학습 작업 → 모델 등록 → 스테이징 검토 → 프로덕션 배포
     ↓              ↓               ↓                    ↓
  지표       버전 ID      승인           트래픽 라우팅
  로깅       생성       기록           모니터링

등록: 학습 파이프라인이 관련 메타데이터와 함께 성공적인 모델을 자동으로 등록합니다: - 학습 실행 ID 및 실험 컨텍스트 - 하이퍼파라미터 및 구성 - 홀드아웃 데이터에 대한 평가 지표 - 데이터 버전 참조 - 코드 커밋 해시

스테이징: 후보 모델은 프로덕션 전에 검증을 거칩니다: - 벤치마크 대비 자동화된 테스트 - 민감한 애플리케이션에 대한 휴먼 리뷰 - 현재 프로덕션 모델과의 A/B 테스트 - 추론 지연 시간에 대한 성능 프로파일링

승격: 승인된 모델이 프로덕션에 배포됩니다: - 트래픽이 점진적으로 새 버전으로 전환 - 모니터링이 성능 저하 감지 - 지표가 하락하면 롤백 트리거

플랫폼 비교

MLflow

MLflow는 가장 포괄적인 오픈소스 모델 레지스트리를 제공합니다:⁵

모델 레지스트리 기능: - 버전 관리 및 별칭 지정이 가능한 중앙집중식 모델 저장소 - 계보 추적 (실험 → 실행 → 모델) - 단계 전환 (Staging, Production, Archived) - 주석 및 메타데이터 태깅 - 프로그래밍 방식 접근을 위한 REST API

MLflow 3.0 개선사항: - LoggedModel 엔티티가 모델을 코드, 프롬프트, 평가와 연결 - 생성형 AI 애플리케이션을 위한 향상된 트레이싱 - 복잡한 AI 시스템을 위한 에이전트 지원 - Databricks가 관리형 엔터프라이즈 버전 제공

예제 워크플로우:

import mlflow

# 학습 중 모델 로깅
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# 모델 레지스트리에 등록
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# 프로덕션으로 승격
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

적합한 경우: 오픈소스 유연성과 함께 포괄적인 MLOps 기능을 원하는 조직.

Weights & Biases

W&B는 강력한 아티팩트 버전 관리와 함께 실험 추적을 강조합니다:⁶

주요 기능: - 풍부한 시각화와 실험 추적 - 계보 그래프가 있는 아티팩트 버전 관리 - 별칭(@champion, @production)이 있는 모델 레지스트리 - 팀 워크플로우를 위한 협업 기능 - 주요 ML 프레임워크와의 통합

아티팩트 버전 관리:

import wandb

run = wandb.init(project="nlp-models")

# 모델을 아티팩트로 로깅
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# 별칭과 함께 레지스트리에 연결
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

고려사항: 클라우드 우선 아키텍처로 인해 데이터를 외부 서버로 전송해야 하므로, 엄격한 데이터 프라이버시 요구사항과 충돌할 수 있습니다.

적합한 경우: 최소한의 설정으로 실험 추적과 협업을 우선시하는 팀.

DVC (Data Version Control)

DVC는 대용량 파일과 데이터셋을 위해 Git을 확장합니다:⁷

아키텍처: - Git과 유사한 명령어 (dvc add, dvc push, dvc pull) - 메타데이터 파일은 Git에서, 대용량 파일은 원격 스토리지에서 추적 - 재현 가능한 실험을 위한 파이프라인 정의 - 다양한 스토리지 백엔드 지원 (S3, GCS, Azure, SSH)

최근 개발: DVC가 lakeFS 패밀리에 합류했으며, lakeFS가 페타바이트 규모 데이터 버전 관리의 엔터프라이즈 표준으로 자리잡고 있습니다.

예제 워크플로우:

# 대용량 모델 파일을 DVC에 추가
dvc add models/bert-finetuned.pt

# 메타데이터를 Git에 커밋
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# 원격 스토리지에 푸시
dvc push

# 모든 커밋에서 재현
git checkout v1.0
dvc checkout

적합한 경우: 기존 Git 워크플로우에 경량 데이터 및 모델 버전 관리를 원하는 팀.

클라우드 네이티브 레지스트리

Vertex AI Model Registry (Google Cloud):⁸ - 네이티브 GCP 통합 - 엔드포인트로 직접 배포 - 자동 계보 추적 - Vertex AI Pipelines와 통합

Amazon SageMaker Model Registry: - AWS 생태계 통합 - 승인 워크플로우 - 교차 계정 모델 공유 - SageMaker Pipelines와 통합

Azure ML Model Registry: - Azure 통합 - MLflow 호환성 - 관리형 엔드포인트 배포

적합한 경우: 특정 클라우드 제공업체에 전념하고 네이티브 통합을 원하는 조직.

LLM 관련 고려사항

대규모 언어 모델은 기존 ML을 넘어서는 고유한 버전 관리 도전 과제를 제시합니다:⁹

버전 관리할 대상

기본 모델: 어떤 파운데이션 모델(Llama 3.1-8B, GPT-4, Claude)이 시작점인지 추적합니다.

파인튜닝된 가중치: 전체 파인튜닝은 완전히 새로운 가중치 파일을 생성하고, LoRA 어댑터는 기본 모델을 참조하는 작은 델타 파일을 생성합니다.

프롬프트 템플릿: 시스템 프롬프트, few-shot 예제, 지시 형식은 모델 동작에 상당한 영향을 미칩니다.

검색 구성: RAG 시스템은 임베딩 모델, 청킹 전략, 검색 파라미터의 버전 관리가 필요합니다.

LLM을 위한 시맨틱 버저닝

변경의 중요도를 전달하기 위해 시맨틱 버저닝을 채택합니다:¹⁰

메이저 버전 (v2.0.0): - 다른 기본 모델 - 아키텍처 변경 - Breaking API 변경

마이너 버전 (v1.3.0): - 새로운 데이터에 대한 파인튜닝 - 상당한 성능 개선 - 새로운 기능 추가

패치 버전 (v1.2.1): - 버그 수정 - 사소한 최적화 - 구성 업데이트

어댑터 관리

LoRA와 QLoRA는 체계적인 조직이 필요한 증가하는 어댑터 파일을 생성합니다:

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

어댑터 버전 관리 전략: - 어댑터를 기본 모델과 독립적으로 버전 관리 - 호환 가능한 기본 모델 버전 문서화 - 어댑터별 학습 데이터 및 하이퍼파라미터 추적 - 서빙 시 어댑터 간 빠른 전환 가능

배포 전략

카나리 배포

전체 롤아웃 전에 새 모델 버전으로 작은 비율의 트래픽을 라우팅합니다:¹¹

# Kubernetes 카나리 구성
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

프로세스: 1. 프로덕션과 함께 새 버전 배포 2. 새 버전으로 5-10%의 트래픽 라우팅 3. 지표 모니터링 (지연 시간, 에러율, 비즈니스 지표) 4. 지표가 유지되면 트래픽 점진적 증가 5. 결과에 따라 롤아웃 완료 또는 롤백

도구: Istio, Argo Rollouts, Flagger가 지표 저하 시 자동 롤백과 함께 점진적 배포를 자동화합니다.

A/B 테스트

비즈니스 영향을 측정하기 위해 모델 버전을 비교합니다:¹²

카나리와의 주요 차이점: - 카나리는 문제를 감지 (분에서 시간 단위) - A/B 테스트는 영향을 측정 (일에서 주 단위) - A/B 결론에는 통계적 유의성이 필요

구현: - 사용자 ID를 해시하여 일관된 라우팅 - 변형별 전환 지표 추적 - 통계적 유의성에 도달할 때까지 실행 - 향후 참조를 위해 결과 문서화

섀도우 배포

응답을 제공하지 않고 프로덕션 트래픽을 새 모델로 라우팅합니다:

장점: - 실제 트래픽 패턴으로 테스트 - 사용자 영향 없이 출력 비교 - 배포 전 엣지 케이스 식별

구현: - 프로덕션 모델이 응답 제공 - 섀도우 모델이 동일한 요청 처리 - 출력 비교하지만 사용자에게 반환하지 않음 - 불일치 시 조사 트리거

롤백 절차

모든 배포에는 롤백 기능이 필요합니다:

즉시 롤백:

# 트래픽 라우팅 롤백
kubectl set image deployment/model-service model=model:v1.2.0

# 피처 플래그 롤백
feature_flags.disable("new_model_v2")

레지스트리 기반 롤백: ```py

[콘텐츠가 번역을 위해 잘렸습니다]