3-3. MLflow 모델 배포 기준¶
MLflow 배포의 핵심은 모델 파일을 아무 디렉터리에 복사하는 방식에서 벗어나, 학습 실행(run), 모델 artifact, dependency, 모델 버전을 하나의 배포 단위로 묶는 것입니다. 2장에서 만든 Tree 기반 분류모델은 pickle 파일로도 실행할 수 있지만, 운영 파이프라인에서는 그 파일이 어떤 데이터와 코드와 parameter에서 나왔는지 함께 추적되어야 합니다.
MLflow 공식 문서에서 MLflow Model은 여러 downstream tool이 사용할 수 있는 표준 패키징 포맷입니다. 모델 디렉터리에는 MLmodel 파일이 있고, 이 파일에는 flavor, loader, dependency, signature 같은 실행 정보가 연결됩니다. 이 구조를 사용하면 같은 모델을 local serving, batch inference, Docker packaging, cloud serving으로 옮길 때 모델을 다시 설명하지 않아도 됩니다.
3-3-1. 모델 파일과 MLflow Model의 차이¶
모델 파일은 예측에 필요한 최소 객체입니다. 예를 들어 scikit-learn 모델을 pickle로 저장하면 Python에서 다시 로딩해 predict_proba를 호출할 수 있습니다. 그러나 모델 파일만으로는 어떤 학습 run에서 만들어졌는지, 입력 schema가 무엇인지, 어떤 dependency가 필요한지, 어떤 모델이 운영 alias인지 알기 어렵습니다.
MLflow Model은 모델 파일보다 넓은 배포 단위입니다. 모델 artifact, flavor, dependency, signature, input example을 함께 담을 수 있습니다. 운영에서는 이 묶음이 중요합니다. 모델이 실행되는지만 확인하는 것이 아니라, 같은 모델이 같은 입력 계약과 같은 라이브러리 조건에서 재현되는지 봐야 하기 때문입니다.
| 구분 | 모델 파일 중심 | MLflow Model 중심 |
|---|---|---|
| 저장 단위 | .pkl, .joblib 같은 serialized object |
MLmodel, flavor, artifact, dependency 디렉터리 |
| 추적 가능성 | 파일명과 수동 기록에 의존 | run id, artifact path, registered model version과 연결 |
| 입력 계약 | 코드 밖 문서에 의존 | signature와 input example로 함께 기록 가능 |
| 배포 이동성 | wrapper 코드가 직접 경로를 알아야 함 | runs:/, models:/ URI로 참조 가능 |
| 운영 전환 | 파일 복사와 설정 변경 | registry alias나 version 기준으로 전환 |
이번 과정에서는 기존 Tree 모델을 MLflow Model로 패키징하는 방향을 기준으로 설명합니다. 즉 모델 자체를 바꾸지 않고, 모델을 담는 운영 포맷을 고도화합니다.
3-3-2. Model Registry와 alias¶
Model Registry는 등록된 모델과 버전을 관리하는 공간입니다. 학습 run에서 모델을 log한 뒤, 그 artifact를 registered model로 등록하면 version이 생성됩니다. 이후 version마다 tag, description, alias를 붙여 어느 버전이 배포 후보인지 구분합니다.
MLflow 최신 workflow에서는 alias가 운영 전환에 중요합니다. 예를 들어 risk-classifier은 현재 운영 모델을 가리키고, risk-classifier@candidate는 다음 배포 후보를 가리킬 수 있습니다. 코드가 version number를 직접 박아두는 대신 alias를 참조하면, 운영 전환과 되돌림을 registry에서 관리할 수 있습니다.
| Registry 요소 | 의미 | 배포에서 쓰는 방식 |
|---|---|---|
| Registered Model | 모델 이름의 장기 식별자 | risk-classifier |
| Model Version | 특정 run에서 나온 모델 artifact 버전 | version=3 |
| Alias | 운영 의미를 가진 포인터 | `,@candidate,@baseline` |
| Tag | 검색과 정책 판단용 metadata | 데이터 기간, feature set, owner |
| Description | 사람이 읽는 변경 설명 | 새 데이터, metric 변화, 되돌림 사유 |
초기 과정에서는 실제 MLflow 서버를 띄우지 못할 수 있습니다. 이 경우에도 registry 개념은 파일 inspection과 prepared artifact로 설명할 수 있습니다. 중요한 것은 배포할 모델을 “어느 파일”로만 부르지 않고 “어느 run에서 나온 어느 registered model version”으로 부르는 습관을 만드는 것입니다.
3-3-3. MLflow local serving¶
MLflow는 모델을 local REST endpoint로 띄우는 mlflow models serve 경로를 제공합니다. 이 기능은 운영 배포 전체를 대체하기보다, 모델 artifact가 MLflow Model format으로 정상 실행되는지 확인하는 smoke test로 사용합니다.
대표적인 확인 흐름은 다음과 같습니다.
mlflow models serve -m runs:/<run_id>/model -p 5000
또는 registry를 사용하는 환경에서는 다음처럼 alias 기반 URI를 사용할 수 있습니다.
mlflow models serve -m models:/risk-classifier@candidate -p 5000
이 명령이 성공하면 모델 artifact, dependency, flavor loader가 하나의 serving process로 실행될 수 있음을 확인한 것입니다. 다만 이 단계만으로 운영 배포가 끝난 것은 아닙니다. local serving은 단일 process smoke test이고, 운영 serving에는 container image, network, scaling, readiness, model storage, access control이 추가됩니다.
| 확인 단계 | 확인 값 | 아직 부족한 것 |
|---|---|---|
runs:/ URI serving |
특정 run artifact 실행 가능 | 운영 alias와 version governance |
models:/name@alias serving |
registry alias 기반 실행 가능 | production endpoint와 scale |
| local request | input/output shape 확인 | latency, concurrency, rollout |
| Docker build | dependency 포함 확인 | cluster runtime과 model storage |
3-3-4. MLflow와 KServe의 연결¶
MLflow와 KServe는 같은 일을 하는 도구가 아닙니다. MLflow는 모델을 추적하고 패키징하고 versioning하는 쪽에 강합니다. KServe는 Kubernetes 위에서 모델 serving endpoint를 표준화하는 쪽에 강합니다. 운영 구조에서는 두 도구를 이어서 사용합니다.
연결 방식은 두 가지로 볼 수 있습니다. 첫째, MLflow Model artifact를 model storage에 배치하고 KServe InferenceService의 storageUri에서 참조합니다. 둘째, custom predictor container가 MLflow model URI를 읽어 모델을 로딩하고, KServe는 그 container를 serving endpoint로 관리합니다.
| 방식 | 장점 | 주의점 |
|---|---|---|
| MLflow artifact를 KServe storage로 제공 | model version과 serving storage 분리 | model artifact 선택과 storage sync가 필요 |
| custom predictor가 MLflow model URI 로딩 | alias 전환과 registry 정책을 코드에 연결 가능 | predictor container dependency와 startup latency 관리 필요 |
| MLflow local serving 사용 | 빠른 smoke test | 운영 scale과 rollout 대체 불가 |
| KServe built-in runtime 사용 | Kubernetes serving 표준화 | custom response contract는 transformer나 predictor 필요 |
이번 과정에서는 MLflow를 model package와 registry 기준으로 두고, KServe를 serving endpoint 기준으로 둡니다. 이 구분이 있어야 “MLflow로 배포한다”와 “KServe로 serving한다”가 섞이지 않습니다.