모델 레지스트리란?
Model Registry(모델 레지스트리) 는 학습된 ML 모델의 버전을 관리 하고, 프로덕션 승격(Promotion)을 제어하는 중앙 저장소입니다. Databricks에서는 Unity Catalog 와 통합되어, 모델에도 테이블과 동일한 거버넌스(권한, 리니지, 감사)가 적용됩니다.
1. 왜 모델 레지스트리가 필요한가
모델 관리 없이 운영할 때의 문제
실제 ML 운영 현장에서 레지스트리 없이 모델을 관리하면 다음과 같은 문제가 반복적으로 발생합니다. 버전 혼란 (Version Chaos)- 파일 시스템에
model_v2_final_FINAL.pkl같은 파일이 쌓입니다. - 어떤 파일이 실제 프로덕션에 배포된 것인지 확인할 방법이 없습니다.
- 팀원이 실수로 구버전 모델을 배포하는 사고가 발생합니다.
- 6개월 후 “이 모델을 어떻게 학습했지?”라는 질문에 답하기 어렵습니다.
- 어떤 데이터셋, 어떤 하이퍼파라미터로 학습했는지 추적이 끊깁니다.
- 동일한 코드로 재학습해도 결과가 달라지는 환경 의존성 문제가 생깁니다.
- 금융·의료 등 규제 산업에서는 “누가 이 모델을 승인했는가”를 입증해야 합니다.
- 모델 변경 이력이 없으면 컴플라이언스(Compliance) 감사를 통과할 수 없습니다.
- 인시던트(Incident) 발생 시 원인 추적이 불가능합니다.
| 문제 | Registry의 해결 |
|---|---|
| 어떤 버전이 프로덕션인지 모름 | Alias (champion, challenger)로 명확히 표시 |
| 이전 버전으로 롤백이 어려움 | 모든 버전이 보존 됨. Alias만 변경하면 롤백 완료 |
| 모델의 출처를 모름 | Lineage(리니지) 추적 — 어떤 데이터, 어떤 실험에서 생성되었는지 |
| 권한 관리가 어려움 | Unity Catalog의 GRANT/REVOKE 로 접근 제어 |
| 모델 변경 이력 추적 | 모든 변경이 Audit Log(감사 로그) 에 기록 |
2. Unity Catalog 기반 모델 레지스트리
Workspace 레지스트리에서 UC 레지스트리로의 전환
Databricks는 원래 Workspace Model Registry 를 제공했습니다. 이는 Workspace 범위 내에서만 동작하는 격리된 레지스트리였습니다. 2023년부터 Unity Catalog(UC) 기반 Model Registry 가 권장 방식이 되었으며, 이유는 다음과 같습니다.| 비교 항목 | Workspace 레지스트리 | UC 레지스트리 |
|---|---|---|
| 범위 | 단일 Workspace | Account 전체 (멀티 Workspace) |
| 네임스페이스 | model_name | catalog.schema.model_name |
| 권한 관리 | Workspace 수준 ACL | UC GRANT/REVOKE (세밀한 제어) |
| 리니지 추적 | 제한적 | UC Lineage와 완전 통합 |
| Delta Sharing | 미지원 | 외부 조직과 모델 공유 가능 |
| 감사 로그 | Workspace 감사 | Account-level 통합 감사 |
3-Level Namespace (3단계 네임스페이스)
UC의 모든 오브젝트는catalog.schema.object 형태의 3단계 네임스페이스를 사용합니다. 모델도 동일합니다.
ml_catalog.fraud_detection.fraud_model 이 됩니다. 이 이름 하나로 버전 관리, 권한 부여, 리니지 추적이 모두 연결됩니다.
3. 모델 등록 방법
방법 1: 학습 중 직접 등록 (MLflow API)
방법 2: 기존 Run에서 사후 등록
방법 3: UI에서 등록
- Databricks 좌측 메뉴 → Experiments 진입
- 실험 Run 클릭 → Artifacts 탭 선택
model폴더 클릭 → Register Model 버튼 클릭- 모델 이름을
catalog.schema.model_name형식으로 입력 - Register 클릭 → 새 버전 자동 생성
방법 4: 자동 등록 (autolog)
4. 모델 버전 관리
버전 번호 체계
모델을 동일한 이름으로 등록할 때마다 버전 번호가 자동으로 증가 합니다. 버전은 삭제하지 않는 한 영구 보존됩니다.| 버전 | 등록일 | accuracy | f1_score | 상태 |
|---|---|---|---|---|
| v1 | 2025-01-15 | 0.89 | 0.87 | 아카이브 |
| v2 | 2025-02-20 | 0.92 | 0.91 | 아카이브 |
| v3 | 2025-03-10 | 0.95 | 0.94 | champion (프로덕션) |
| v4 | 2025-04-01 | 0.96 | 0.95 | challenger (테스트 중) |
Alias (별칭) 관리
Alias 는 특정 버전에 부여하는 가변 포인터 입니다. 버전 번호 대신 Alias를 참조하면, 내부 버전을 바꿔도 참조 코드를 수정할 필요가 없습니다.버전별 메타데이터와 태그
5. 모델 배포 워크플로
개발 → 스테이징 → 프로덕션 (Alias 활용)
UC 레지스트리에서는 Stage 개념 대신 Alias 로 배포 단계를 표현합니다. 일반적인 워크플로는 다음과 같습니다.롤백 (Rollback)
문제가 발생하면 Alias만 변경하여 즉시 이전 버전으로 롤백합니다.Model Serving 엔드포인트와 연결
6. 권한과 거버넌스
UC 기반 권한 체계
UC 레지스트리는 SQL GRANT 문법 으로 권한을 부여합니다. 테이블 권한과 동일한 체계를 사용하므로 데이터 거버넌스와 일관성 있게 관리됩니다.감사 로그 (Audit Log)
UC 레지스트리의 모든 작업은 자동으로 감사 로그 에 기록됩니다.| 이벤트 | 설명 |
|---|---|
registerModel | 새 모델/버전 등록 |
setRegisteredModelAlias | Alias 변경 (프로덕션 배포 이력) |
updateRegisteredModel | 모델 메타데이터·태그 수정 |
deleteModelVersion | 버전 삭제 |
getRegisteredModel | 모델 조회 (누가 언제 조회했는지) |
7. 장단점과 트레이드오프
UC 레지스트리 vs Workspace 레지스트리
| 기준 | UC 레지스트리 | Workspace 레지스트리 |
|---|---|---|
| 장점 | 멀티 Workspace 공유, 세밀한 권한, 감사 로그, Delta Sharing | 설정 간단, UC 미사용 환경에서도 동작 |
| 단점 | UC 활성화 필수, 마이그레이션 작업 필요 | 단일 Workspace 격리, 권한 체계 제한 |
| 추천 대상 | 신규 프로젝트, 엔터프라이즈 환경 | 레거시 환경, 빠른 프로토타이핑 |
마이그레이션 고려사항
Workspace 레지스트리에서 UC 레지스트리로 마이그레이션할 때 주의할 점입니다.- 네임스페이스 변경:
model_name→catalog.schema.model_name으로 모든 참조를 업데이트해야 합니다. - Stage → Alias 전환:
Production,StagingStage 개념이 없어지고 Alias로 대체됩니다. - Model Serving 엔드포인트 재생성: Workspace 레지스트리를 참조하는 엔드포인트는 재배포가 필요합니다.
- 권한 재설정: Workspace ACL을 UC GRANT 문법으로 재작성해야 합니다.
- 공식 마이그레이션 도구:
mlflow.models.migrate_to_uc()API 또는 Databricks UI의 마이그레이션 위저드를 활용합니다.
8. 베스트 프랙티스
네이밍 컨벤션을 팀 전체에서 통일합니다.- Catalog: 데이터 도메인 단위 (
ml_prod,ml_dev) - Schema: 프로젝트/팀 단위 (
fraud_detection,recommendation) - Model: 모델 역할 중심 (
transaction_scorer,item_ranker)
- 디버깅과 규제 감사를 위해 모든 버전을 보존합니다.
- 불필요한 버전은 Alias를 제거하는 것으로 충분합니다.
- 서빙 코드, 배치 추론 코드 모두 버전 번호 대신
@champion같은 Alias를 참조합니다. - 롤백·업그레이드가 코드 변경 없이 가능해집니다.
validation_status: pending → approved → rejected태그로 모델 심사 프로세스를 추적합니다.approved_by,approval_date태그로 규제 감사 요건을 충족합니다.
- PR 머지 시 재학습 → 메트릭 검증 → 자동 등록 →
@stagingAlias 부여까지 자동화합니다. - 사람은
@staging→@champion승격 단계에만 개입합니다.
- 학습 파이프라인:
CREATE MODEL권한만 부여 - 서빙 서비스 계정:
EXECUTE권한만 부여 - 감사자·분석팀:
SELECT권한만 부여