MLflow와 Azure Machine Learning

MLflow와 BentoML 기능 정리 2편과 로컬 실험부터 AML 모델 등록 및 추론까지 이어지는 6편의 실습

✎ 이 문서 수정하기 + 이 카테고리에 새 문서 만들기 GitHub에서 수정

책에서 읽은 MLflow를 직접 실행해 보고, 같은 코드를 Azure Machine Learning에 연결하는 순서로 나눴다. Azure Machine Learning은 아래에서 AML로 줄여 쓴다. 전체 흐름은 이 목차에 두고, 개념과 실습은 주제별 여섯 편으로 구분했다.

모든 편은 같은 Wine 분류 예제를 이어서 사용한다. 서로 다른 프로젝트를 매번 만드는 것이 아니라 하나의 mlflow-aml-lab 폴더에 파일과 실행 기록을 추가하는 구조다.

전체 기능은 MLflow 기능과 구성과 BentoML 기능과 구성에 나눠 정리했다. 두 글은 도구의 범위를 살펴보는 참고 자료이며, 번호가 붙은 01~06편은 같은 코드를 이어서 실행하는 실습이다. 최신 기능 소개와 AML 실습의 고정 버전도 구분했다.

MLflow와 BentoML의 의미

MLflow

MLflow는 실험 추적, 모델 평가, 모델 패키징과 버전 관리, 배포 도구를 제공하는 오픈소스 프로젝트다. 공식 ML 문서도 이 기능들을 하나의 모델 개발 생애주기로 다룬다.

이 시리즈에서는 어떤 데이터와 설정으로 학습했고 어떤 결과를 얻었는지 남기는 Tracking, 모델을 다시 읽기 위한 모델 형식, 선택한 모델을 관리하는 Registry에 초점을 둔다. 학습 자체는 scikit-learn이 실행하고 MLflow는 그 과정과 결과를 기록한다.

예를 들어 같은 데이터로 규제 설정을 세 번 바꾸면 MLflow에는 세 개의 run이 남는다. 그중 하나의 모델을 선택해 이름과 버전을 부여하면, 나중에 배포한 모델이 어느 실험에서 나왔는지 연결할 근거가 생긴다.

MLflow를 실험 기록 전용 도구로만 이해하지는 않았다. 자체 모델 서빙과 배포 연동 기능도 있다. 다만 MLflow API를 쓴다는 사실만으로 학습용 컴퓨팅이나 운영 인프라까지 자동으로 준비되는 것은 아니다.

BentoML

BentoML은 학습한 모델을 사용하는 추론 서비스의 코드, 입출력과 실행 환경을 정의하고 배포하는 오픈소스 서빙 프레임워크다. Service 문서는 모델 로딩, 전처리와 예측 같은 처리 흐름을 API로 노출하는 단위로 Service를 설명한다.

모델의 predict()가 메모리 안의 함수 호출이라면, BentoML Service는 외부 요청을 받아 그 함수를 실행하고 응답을 돌려주는 서비스 구현에 해당한다. 입력 형식, 전처리, 여러 모델의 호출, 시간 제한과 자원 설정 같은 결정을 함께 다룰 수 있다.

Bento는 이런 서비스를 배포하기 위한 패키지다. 패키징 문서는 서비스 코드, Python 의존성, 모델 관련 파일과 설정을 묶는 형식으로 설명한다. 모델 참조와 패키지 구성을 바탕으로 컨테이너 이미지를 만들 수도 있다.

BentoML과 BentoCloud는 구분한다. BentoML로 서비스를 만들고 컨테이너 환경에서 실행할 수 있으며, BentoCloud는 그 위에서 배포와 컴퓨팅 운영을 제공하는 관리형 플랫폼이다. BentoML을 사용한다는 사실이 반드시 BentoCloud를 사용한다는 뜻은 아니다.

두 도구를 구분할 기준

기능이 완전히 나뉘는 것은 아니다. MLflow에도 서빙 기능이 있고 BentoML에도 모델 저장과 관리 기능이 있다. 이 표는 기능의 존재 여부보다 각각을 어떤 책임으로 사용하는지 구분하기 위한 것이다.

전체 MLOps에서의 역할

MLOps는 모델을 학습하고 API로 만드는 두 작업만을 뜻하지 않는다. 업무 목적과 데이터의 정의, 학습과 검증, 출시 판단, 운영 관측과 개선을 반복 가능하게 연결하는 일이다.

    flowchart TD
    accTitle: 전체 MLOps에서의 MLflow와 BentoML 역할
    accDescr: 업무 목적과 데이터 준비에서 학습과 평가로 이어지고 MLflow로 실험 및 모델 버전을 관리한다. 선택한 모델은 AML 추론이나 BentoML 서비스 같은 서빙 경로로 연결하며 운영 결과는 데이터와 모델의 재검토에 사용한다.
    A["업무 목적과 평가 기준"] --> B["데이터 준비와 품질 검사"]
    B --> C["학습과 모델 평가"]
    C --> M["MLflow: 실험 기록과 모델 패키지 및 버전 관리"]
    M -->|"이 시리즈의 추론 경로"| E["AML 온라인 또는 배치 추론"]
    M -->|"별도의 서빙 구현을 구성하는 예"| S["BentoML: Service와 Bento"]
    S --> I["컨테이너 실행 환경 또는 BentoCloud"]
    E --> O["운영 관측과 대응"]
    I --> O
    O -->|"데이터와 입력 변화 확인"| B
    O -->|"후보 모델 재검증"| C
  

위 도식은 서빙 경로를 비교한 예시이지 모든 시스템이 두 도구를 함께 사용해야 한다는 뜻은 아니다. 각 단계에서 기록할 정보와 다음 단계에 넘길 계약을 기준으로 역할을 나누었다.

두 도구가 데이터 품질 기준, 출시 승인, 접근 제어, 장애 대응의 책임까지 대신 결정하지는 않는다. 운영 관측에서도 서비스 지연과 오류, 입력 변화, 정답 기반 모델 품질을 구분할 필요가 있다.

이 시리즈에서 사용하는 경로

이 시리즈는 MLflow로 기록한 모델을 AML에 등록하고, AML의 온라인 또는 배치 추론으로 소비하는 경로를 다룬다. AML의 MLflow no-code 배포에서는 모델 계약을 읽어 기본 추론 코드와 환경을 구성하므로, 이 경로를 따라가기 위해 BentoML을 추가할 필요는 없다.

서비스의 입출력이나 여러 모델의 호출을 별도 애플리케이션으로 구성하려는 경우에는 BentoML 같은 서빙 프레임워크를 다른 선택지로 검토할 수 있다. BentoML의 MLflow 연동 예제는 MLflow 모델을 가져와 BentoML의 모델 저장소와 Service에서 사용하는 흐름을 보여 준다.

이 경우에도 MLflow의 모델 버전과 Bento의 패키지 버전은 다른 식별자다. 어떤 모델을 어떤 서비스 코드와 환경으로 배포했는지 연결해 남겨야 한다. AML에 모델이 등록되었다고 BentoML 서비스까지 자동 생성되거나, BentoML을 사용한다고 AML 인증과 모델 접근이 자동 구성되지는 않는다.

BentoML은 여기서 역할을 비교하는 대상이며 여섯 편의 실행 예제에 추가 설치하지 않는다. MLflow와 AML을 먼저 익히고, 별도 서빙 구현이 필요한지 판단할 때 이어서 볼 범위로 두었다.

학습 순서

목록의 첫 두 글에서 기능 범위를 살펴보고, 01~06편을 순서대로 이어서 볼 수 있다.

• MLflow 기능과 구성 : 실험과 데이터 추적, 모델 패키징과 Registry, 평가와 배포, LLM 관측까지 MLflow의 기능 범위 정리
• BentoML 기능과 구성 : Service와 모델 관리, API와 서비스 조합, 배칭과 비동기 작업, Bento 패키징과 배포 및 운영 관측 정리
• 01. MLflow 기본과 로컬 실험 기록 : Experiment와 run을 구분하고 같은 학습 코드의 설정과 결과를 로컬에 기록하기
• 02. 실행 비교와 메트릭 및 아티팩트 조회 : 실행의 비교 조건을 고정하고 메트릭 이력과 모델 파일을 코드로 다시 조회하기
• 03. 모델 형식과 재사용 : MLmodel, flavor, signature와 환경을 구분하고 저장 모델의 예측과 입력 계약을 확인하기
• 04. AML 연결과 원격 학습 Job : 로컬 코드를 AML에 연결해 기록한 뒤 같은 학습을 원격 command Job으로 실행하기
• 05. 모델 등록과 버전 관리 : AML에 기록한 모델의 출처를 유지하며 이름과 구체 버전으로 등록하고 다시 읽기
• 06. 온라인 및 배치 추론과 모델 교체 : 등록 모델을 온라인과 배치 추론에 연결하는 계약과 요청 형식, 점진적 전환을 구분하기

전체 흐름: 로컬 학습 결과를 AML 모델로 등록하기

이 예제에서 MLflow는 로컬 Python 코드가 호출하는 라이브러리다. 별도의 로컬 MLflow 서버에 모델을 보낸 뒤 그 서버가 AML로 옮기는 구조가 아니다. azureml-mlflow 플러그인을 설치하고 기록 대상을 AML workspace로 지정하면, 같은 Python 코드의 MLflow 호출이 AML에 실행 정보와 모델을 남긴다.

학습, 실행 기록, 모델 등록을 나누어 보니 흐름을 이해하기 쉬웠다. model.fit()은 모델을 학습하고, log_model()은 학습한 모델을 특정 run의 결과물로 기록하며, register_model()은 그 결과물을 모델 이름 아래의 버전으로 등록한다. 모델을 학습했다는 사실만으로 뒤의 두 작업까지 수행되지는 않는다.

로컬 Python과 AML 사이의 호출 순서

아래는 04편의 AML 연결과 05편의 모델 등록을 기준으로 그린 흐름이다. 학습과 비교 코드는 로컬에서 실행하고, 기록과 등록은 같은 AML workspace를 대상으로 한다. SDK와 플러그인도 로컬 Python 프로세스 안에서 동작하는 라이브러리이며, 그림에서 나눈 칸은 별도 서버를 뜻하지 않는다.

    sequenceDiagram
    accTitle: 로컬 학습부터 AML 모델 버전 등록까지
    accDescr: 로컬 Python이 MLflow SDK와 Azure 플러그인으로 AML에 run을 만들고 학습 결과를 기록한다. 기록된 모델 중 하나를 선택한 뒤 같은 workspace에 이름과 버전으로 등록한다.
    participant P as 로컬 Python
    participant M as MLflow SDK와 azureml-mlflow
    participant A as AML workspace
    P->>M: AML Tracking URI와 Registry URI 지정
    Note over P,A: Azure CLI 로그인과 workspace 접근 권한 필요
    P->>M: start_run()
    M->>A: 인증 후 experiment에 run 생성
    A-->>M: run_id
    M-->>P: run_id
    P->>P: model.fit()으로 로컬 학습
    P->>M: log_params()와 log_metrics()
    M->>A: 설정과 검증 지표 기록
    P->>M: sklearn.log_model(artifact_path="model")
    M->>A: 해당 run에 모델 파일과 메타데이터 기록
    Note over A: 모델 참조는 runs:/run_id/model
    P->>M: search_runs()로 후보 비교
    M->>A: 기록된 실행과 지표 조회
    A-->>M: 후보 실행의 결과
    M-->>P: 비교할 결과와 선택할 run_id
    P->>M: register_model()에 선택한 모델 URI 전달
    M->>A: wine-logistic-study 이름 아래 새 버전 등록
    A-->>M: 등록된 모델 이름과 버전
    M-->>P: models:/wine-logistic-study/version
  

AML이 실행 메타데이터를 관리하고, 모델 파일과 보고서는 workspace에 연결된 아티팩트 저장소에 보관한다. log_model() 단계에서는 모델 파일도 원격에 기록한다. 모델 이름과 버전을 부여하는 등록 요청은 이 예제의 register_model() 단계에서 별도로 보낸다.

각 호출이 만드는 결과

05편의 finalize.py에서 등록에 사용하는 호출은 다음 부분이다. 아래는 전체 파일에서 등록 요청만 뽑은 코드이며, run_id는 같은 AML workspace에서 선택한 실행의 ID다.

registered = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="wine-logistic-study",
)

runs:/<run_id>/model은 로컬 폴더 경로가 아니다. 현재 Tracking URI가 가리키는 저장소에서 특정 run에 기록한 model을 참조한다. Registry URI도 같은 AML workspace로 맞췄으므로 그 모델이 같은 workspace의 모델 버전으로 등록된다.

AML studio에서는 실행과 지표를 Jobs의 experiment에서, 등록한 모델 이름과 버전을 Models에서 확인한다. 로컬에서 학습한 실행도 Jobs에 보일 수 있다. 화면에 Job으로 표시된다는 사실과 AML 클러스터가 학습을 수행했다는 사실은 구분한다.

라이브러리와 서비스의 역할

MLflow 개요는 AML이 오픈소스 MLflow 서버 인스턴스를 호스팅하는 것이 아니라 호환 API를 제공한다고 설명한다. 서버 프로세스의 설치와 AML workspace 연결을 같은 작업으로 보지 않았다.

AML SDK v2의 MLClient를 만든다고 학습 메트릭이 자동으로 기록되는 것은 아니다. 리소스와 Job 관리는 CLI나 SDK v2로, 학습 결과의 구조화된 기록은 MLflow로 나누었다. 이 시리즈는 CLI를 사용하므로 로컬에 azure-ai-ml을 별도로 설치하지 않는다.

로컬 연습과 AML 연결의 구분

01~03편에서는 로컬 SQLite와 파일 저장소를 사용한다. 이 단계의 모델은 AML에 등록된 것이 아니다. 04편에서 기록 대상을 AML workspace로 바꾸고, 05편에서 선택한 모델을 이름과 버전으로 등록한다. 06편의 추론 서비스 배포는 등록과 별개의 작업이다.

Tracking URI를 바꾸는 것만으로 이전 로컬 run이 AML로 복사되지는 않는다. 예제에서는 같은 학습 코드를 다시 실행해 원격에 새 기록을 만든다. 이미 가진 모델을 다시 학습하지 않고 가져오는 경로는 05편에서 따로 다룬다.

실습 폴더와 파일의 연결

코드는 해당 편에 파일명과 함께 제시했다. 명령은 Windows PowerShell을 기준으로 하며 가상환경을 활성화하지 않고 .venv 안의 실행 파일을 직접 호출한다. 각 편의 명령은 같은 실습 폴더의 루트에서 실행한다.

실행 범위와 비용

로컬 학습과 비교, 모델 재로딩 및 등록, 자동 기록, 요청 파일 생성은 로컬에서 확인한 범위다. 실제 AML workspace 연결, 원격 학습과 배포는 사용하는 구독의 권한, 네트워크와 컴퓨팅 조건에서 별도로 확인한다.

04편부터는 AML 리소스와 비용이 관계된다. 06편은 등록 모델을 온라인 또는 배치 추론에 연결하는 후속 학습이다. 학습 코드를 실행했다고 endpoint가 자동 생성되지는 않는다. 공유 리소스를 실습 종료를 이유로 삭제하지 않는다.

다른 Azure 실행 환경으로 확장

로컬 Python에서 기록 대상과 모델 등록 대상을 구분한 뒤에는 실행 환경을 Databricks나 Synapse로 옮겨 볼 수 있다. 학습이 실행되는 제품과 모델을 관리하거나 배포하는 제품이 반드시 같아야 하는 것은 아니다.

Databricks의 dual tracking이 모델 Registry에도 자동으로 이중 등록한다는 뜻은 아니다. 기록 대상과 등록 대상을 별도로 확인해야 한다. 해당 문서는 Private Link를 사용하는 AML workspace에 대한 dual tracking 제약도 설명하므로, 같은 설정을 모든 네트워크에 적용하지 않는다.

Synapse에서는 패키지를 로컬 PC에 설치한 것만으로 Spark 세션에서 사용할 수 있는 것은 아니다. 관리 대상인 pool 또는 실행 환경의 의존성과 인증을 확인해야 한다. Spark UDF로 모델을 실행하는 것과 AML endpoint에 모델을 배포하는 것도 별도 경로다.

참고 자료와 학습 후 확인할 결과

아래는 세 출발 문서와 직접 연결된 주요 문서를 읽으며 정리한 범위다. AML의 모든 기능을 같은 실습에 넣지는 않고, 기본 경로와 후속 확장 경로를 나누었다. 확인 기준은 2026-10-21이다.

도구의 의미와 역할 비교

개념과 기본 학습 경로

모델 소비와 후속 확장

리소스와 실행 준비

MLflow API, AML 서비스의 지원 범위, 플러그인의 의존성은 따로 바뀐다. 환경을 다시 만들 때는 이 노트의 고정 버전과 공식 문서의 버전 조건을 함께 확인한다.