책 4.1절(실험 추적과 모델 레지스트리) 노트북을 홈랩 MLflow에서 돌린 기록이다. 실습 환경(MLflow, Postgres, RustFS, JupyterLab)을 Kubernetes에 올린 과정은 앞 글에 있다.

책은 로컬 mlflow ui와 Kubeflow에 딸린 MinIO를 쓰지만 여기서는 Kubernetes 위의 MLflow, Postgres, RustFS를 썼다. RustFS는 홈랩에서 이미 쓰고 있어서 골랐고 다른 이유는 없다.

1. 한눈에 보기

아래는 이번 절에서 실습할 파이프라인이다. 초록 칸은 Jupyter 노트북 셀로 직접 실행한 단계이고, 주황 칸은 노트북이 만든 결과를 MLflow에 기록하고 등록한 곳이다.

Machine Learning Platform Engineering 의 2장은 MLOps가 왜 루프여야만 하는지 다룬다.

기억하자. 모델은 조직의 최종 산출물이 아니라 수단이다.

1. 모델 만들기는 어려운 부분이 아니다

모델 아키텍처를 처음부터 연구하는 회사는 드물다. 대부분 기존 구조를 재사용하거나 공개 모델을 도메인에 적응시킨다. Hugging Face 같은 생태계가 이 과정을 더 간단하게 만들었다.

정말 어려운 것은 이제부터다.

• 모델을 어떻게 학습시킬 것인가
• 데이터는 모델까지 어떻게 도달하는가
• 모델은 다른 서비스와 어떻게 상호작용하는가
• 모델은 어디서 실행되는가
• 시간이 지나도 정확도를 어떻게 유지하는가

다섯 개 모두 모델링보다는 플랫폼의 문제다. 비즈니스 가치와 인프라 사이의 이 간극이 MLOps를 어렵게 만든다.

Machine Learning Platform Engineering 1장을 읽고 정리한 글이다.

1. ML 프로젝트가 소프트웨어 프로젝트와 다른점

소프트웨어 프로젝트는 안정성을 우선하며 배포한 것이 그대로 돌기를 기대한다.

ML 프로젝트는 맞는 접근을 미리 알 수 없어서 시행착오의 연속이고 단계 사이 흐름이 비선형적이다. 학습을 돌려본 뒤 데이터 준비로 되돌아가는 일이 흔하다.

2. 두가지 국면

같은 단계 이름이 양쪽에 다 나온다는 데서 이 구분이 중요해진다. 데이터 버전 관리, 모델 학습, 평가, 검증이 양쪽 모두에 있다.