MLOps 04 - 모델 버전 관리와 레지스트리

Git만으로는 부족하다

소프트웨어 개발에서 버전 관리는 이미 해결된 문제이다. Git을 사용하여 코드의 모든 변경 이력을 추적하고, 브랜치를 나누어 병렬 개발을 수행하며, 필요하면 과거 시점으로 되돌릴 수 있다. 그렇다면 ML 모델도 Git으로 관리하면 되지 않을까?

문제는 모델이 코드와 근본적으로 다른 성격을 가진다는 것이다. 코드는 텍스트이기 때문에 diff를 통해 변경 내용을 파악할 수 있고, 용량도 크지 않다. 반면 학습된 모델 파일은 수백 MB에서 수 GB에 이르는 바이너리 파일이며, diff가 무의미하다. 더 중요한 것은 모델의 동작을 결정하는 것이 코드만이 아니라는 점이다. 동일한 코드라도 학습 데이터, 하이퍼파라미터, 학습 환경이 달라지면 완전히 다른 모델이 만들어진다.

따라서 모델의 버전을 관리한다는 것은 코드뿐만 아니라 데이터, 파라미터, 환경, 성능 메트릭까지 함께 추적하는 것을 의미한다. Git이 코드의 계보를 관리한다면, 모델 버전 관리는 모델의 계보를 관리하는 것이다.

모델 레지스트리의 개념

모델 레지스트리는 학습된 모델을 중앙에서 저장하고 관리하는 시스템이다. 단순한 파일 저장소가 아니라, 각 모델의 메타데이터와 생명주기를 함께 관리한다는 점에서 차이가 있다.

모델 레지스트리가 관리하는 정보는 다음과 같다. 모델 자체(학습된 가중치 파일), 모델의 메타데이터(학습에 사용된 데이터셋, 하이퍼파라미터, 성능 메트릭), 모델의 계보(어떤 실험에서 파생되었는지, 이전 버전과의 관계), 그리고 모델의 현재 상태(개발 중인지, 스테이징에 배포되었는지, 프로덕션에서 서빙 중인지)가 그것이다.

이러한 정보가 중앙에서 관리되면, 팀 전체가 현재 프로덕션에서 어떤 모델이 서빙되고 있는지, 다음 배포 후보는 무엇인지, 과거에 어떤 모델이 사용되었는지를 투명하게 파악할 수 있게 된다.

모델의 생명주기

모델은 만들어진 후 일정한 단계를 거쳐 프로덕션에 도달한다. 이 과정을 체계적으로 관리하지 않으면 검증되지 않은 모델이 프로덕션에 배포되거나, 반대로 이미 검증이 완료된 모델이 배포되지 못한 채 방치되는 상황이 발생한다.

일반적인 모델 생명주기는 세 단계로 구성된다.

None → Staging → Production → Archived
        ↑                        │
        └────── 롤백 ──────────┘

첫 번째 단계는 스테이징이다. 실험에서 유망한 결과를 보인 모델이 레지스트리에 등록되면 스테이징 상태가 된다. 이 단계에서 추가적인 검증이 수행된다. 다양한 테스트 데이터에 대한 성능 평가, A/B 테스트, 편향성 검사 등이 이루어지는 것이다.

두 번째 단계는 프로덕션이다. 검증을 통과한 모델이 실제 서비스에 배포되어 추론 요청을 처리하는 상태이다. 동일한 모델에 대해 프로덕션 상태인 버전은 하나만 유지하는 것이 일반적이다.

세 번째 단계는 아카이브이다. 새로운 모델이 프로덕션에 배포되면 이전 모델은 아카이브 상태로 전환된다. 이 모델은 더 이상 서빙에 사용되지 않지만, 롤백이 필요한 경우를 대비하여 삭제하지 않고 보존한다.

승인 워크플로우

모델의 상태 전환이 자동으로 이루어지면 위험할 수 있다. 성능 메트릭이 좋다고 해서 바로 프로덕션에 배포하는 것은 적절하지 않다. 공정성, 규제 준수, 비즈니스 영향 등 정량적 메트릭만으로는 판단할 수 없는 요소들이 존재하기 때문이다.

이를 위해 승인 워크플로우를 도입한다. 스테이징에서 프로덕션으로의 전환에 담당자의 승인이 필요하도록 하는 것이다. 자동화된 검증(성능 임계값 충족 여부, 데이터 품질 검증 등)과 수동 검토(비즈니스 로직 확인, 윤리적 검토 등)를 조합하여, 모델의 프로덕션 배포가 통제된 과정을 거치도록 만드는 것이다.

DVC를 활용한 데이터 버전 관리

모델의 버전을 관리하려면 학습 데이터의 버전도 함께 관리해야 한다. DVC(Data Version Control)는 Git과 유사한 인터페이스로 대용량 파일과 데이터셋의 버전을 관리하는 도구이다.

DVC의 핵심 아이디어는 대용량 파일 자체는 원격 스토리지(S3, GCS 등)에 저장하고, Git에는 해당 파일의 해시값과 메타데이터만 추적하는 것이다. 이를 통해 코드와 데이터의 버전을 동기화할 수 있다. 특정 Git 커밋으로 체크아웃하면 그 시점의 데이터도 함께 복원되므로, 과거 실험의 완전한 재현이 가능해진다.

# 데이터 파일을 DVC로 추적
dvc add data/training_dataset.csv

# 원격 스토리지 설정
dvc remote add -d storage s3://my-bucket/dvc-store

# 데이터 푸시
dvc push

# 특정 버전의 데이터 복원
git checkout v1.0
dvc checkout

MLflow Model Registry

MLflow는 실험 추적 기능에 더해 모델 레지스트리 기능을 내장하고 있다. 실험에서 학습된 모델을 레지스트리에 등록하고, 버전을 부여하며, 생명주기 상태를 관리할 수 있다.

MLflow Model Registry의 장점은 실험 추적과의 통합이다. 어떤 실험에서 어떤 파라미터로 학습된 모델이 현재 프로덕션에 서빙되고 있는지를 하나의 시스템에서 추적할 수 있다. 모델을 로드할 때도 버전 번호나 상태(예: "Production")를 지정하여 가져올 수 있어, 배포 파이프라인과의 연동이 자연스럽다.

버전 관리 없는 모델은 관리 불가능하다

모델의 수가 적고 배포 주기가 긴 초기 단계에서는 버전 관리의 필요성을 체감하기 어렵다. 하지만 모델의 수가 늘어나고 배포 주기가 짧아질수록, 어떤 모델이 어떤 상태에 있는지 파악하는 것이 점점 어려워진다. 모델 레지스트리는 이 복잡성을 관리 가능한 수준으로 유지하는 장치이다. 코드에 Git이 필수적인 것처럼, ML 시스템에는 모델 레지스트리가 필수적인 것이다.

다음 포스트에서는 학습된 모델을 실제 서비스에 배포하는 모델 서빙과 배포 전략을 살펴본다.