MLflow 해부 (1) 실험 추적 문제와 MLflow 구조

MLflow 해부 시리즈의 1편입니다. 전체 목차는 0편에 있습니다.

실험 추적이 푸는 문제

실험을 서른 번쯤 돌리면 최고 점수가 어떤 파라미터 조합이었는지 기억나지 않습니다. 노트북 셀은 마지막 실행으로 덮어써지고, 모델 파일은 model_final_v2.pkl처럼 쌓입니다. 이 문제의 자세한 전개는 머신러닝 실전 워크플로 6편에서 다뤘으므로 여기서는 결론만 가져옵니다. 실행 하나마다 세 가지를 남겨야 합니다.

• 파라미터: 무엇을 바꿨나 (하이퍼파라미터, 피처 목록, 데이터 버전)
• 지표: 무엇이 좋아졌나 (RMSE, AUC)
• artifact: 무엇이 나왔나 (모델 파일, 그림, 리포트)

MLflow는 이 세 가지를 기록, 비교, 재현하는 오픈소스 도구입니다.

네 가지 구성요소

구성요소	역할	이 시리즈에서
Tracking	run의 파라미터, 지표, artifact 기록과 조회	2편, 5편
Models	모델 저장 포맷(flavor), 로딩, 서빙 인터페이스	3편
Model Registry	모델 이름, 버전, alias 관리	4편
Projects	실행 환경과 진입점 패키징	다루지 않음 (실무 사용 빈도가 낮음)

중심은 Tracking입니다. 나머지는 Tracking이 남긴 기록 위에 얹히는 층입니다. Models는 “run이 남긴 모델을 어떻게 다시 쓰나”이고, Registry는 “그 모델들에 이름과 버전을 어떻게 붙이나”입니다.

저장은 두 곳으로 갈라진다

MLflow의 저장 구조를 처음에 정확히 잡아야 뒤의 운영 구성이 읽힙니다. 기록은 성격에 따라 두 저장소로 갈라집니다.

• backend store: 파라미터, 지표, run 메타데이터 같은 작은 구조화 데이터. 파일(mlruns/) 또는 DB(SQLite, PostgreSQL)
• artifact store: 모델 파일, 그림 같은 큰 파일. 로컬 디스크 또는 S3 호환 오브젝트 스토리지

로컬에서 혼자 쓸 때는 둘 다 mlruns/ 폴더 하나로 합쳐져 있어서 이 구분이 안 보입니다. 원격 서버를 구성하는 6편에서 이 둘이 PostgreSQL과 MinIO로 갈라집니다.

클라이언트 (학습 코드)
    │  log_param, log_metric ──> backend store (메타데이터)
    │  log_artifact, log_model ──> artifact store (파일)
    ▼
tracking server (원격 구성 시)

다른 도구 대비 위치

• TensorBoard: 학습 곡선 시각화가 중심입니다. run 간 비교와 모델 버전 관리가 없어서 실험 추적 시스템이라기보다 시각화 도구입니다
• Weights & Biases: 기능은 MLflow와 겹치고 UI가 좋지만 호스팅형 SaaS가 기본입니다. 데이터를 외부에 못 보내는 환경에서는 선택지가 좁아집니다
• MLflow: 오픈소스 자체 호스팅이 기본이고, 추적부터 registry, 서빙까지 한 도구에 있습니다. 팀 규모와 무관하게 시작 비용이 가장 낮은 축입니다

이 시리즈는 MLflow 기준으로 진행하지만, 2편에서 다루는 “무엇을 기록하는가”는 도구를 바꿔도 그대로 유효합니다.

다음 편에서 설치하고 첫 실험을 기록합니다.

다음 글: MLflow 해부 (2) Tracking 기초: 설치와 첫 기록