Machine Learning Platform Engineering 파트 3은 1 ~ 6장에서 갖춘 플랫폼을 실제 프로젝트에 적용한다. 캡스톤 프로젝트는 세 개이고, 7장은 그중 신분증 객체 탐지기와 영화 추천 시스템의 첫 단계인 데이터 분석과 준비를 다룬다. 여기선 7.1절 Kubeflow 노트북과 7.2절 KFP 데이터 전달을 정리하고, 1 ~ 6장에서 구축한 환경에서 돌린 결과를 정리한다.

1. 한눈에 보기

MLOps 파이프라인 그림에서 7장은 데이터 수집·준비 자리다. 7.1절은 그 단계를 사람이 노트북으로 탐색하는 방법이고, 7.2절은 같은 단계를 KFP 컴포넌트로 나눴을 때 컴포넌트 사이로 데이터를 넘기는 방법이다.

6.1절까지 소득 분류기를 배치 파이프라인과 API 두 가지로 배포했다. 배포한 모델은 처음에는 잘 맞다가, 몇 달 뒤 들어오는 데이터가 학습 때와 달라지면서 조용히 성능이 떨어질 수 있다. 6.2절은 이 데이터 드리프트를 Evidently로 탐지하고 대시보드로 추적한다.

1. 한눈에 보기

6.2절은 그림 아래쪽의 모델 모니터링에 해당한다. 드리프트를 보는 경로는 두 가지로, 5장에서 KFP 배치 추론 파이프라인에 넣은 detect_drift 단계와 6.1절 BentoML API의 마이크로배치 윈도다. 둘 다 4.1절 MLflow 모델 run에 남긴 학습 피처를 기준(reference)으로 삼아 리포트를 Evidently UI에 쌓는다.

Machine Learning Platform Engineering 6장은 배포와 모니터링을 다룬다. 5장에서 소득 분류기를 배치 파이프라인으로 돌렸다면 6장은 같은 모델을 BentoML로 API 서비스로 만들고 Evidently로 데이터 드리프트를 추적한다.

1. 한눈에 보기

MLOps 파이프라인 그림에서 6.1절은 모델 배포와 모델 API부분이다. 모델은 4.1절 MLflow 레지스트리에서 피처는 4.2절 Feast 온라인 스토어(Redis)에서 가져오고 모델 모니터링은 6.2절에서 다룬다.

EDA run의 막대그래프 인자 position="fill"을 "stack"으로 바꿔 run을 하나 더 만들고, 두 그래프가 무엇을 보여 주는지 비교한다.

1. 무엇을 바꾸나

책의 EDA 셀은 범주형 컬럼 8개마다 막대그래프를 그린다. 막대 하나가 컬럼의 값 하나(예: Workclass의 Private)이고, 막대 안은 소득 구간 Target(<=50K, >50K)별 색으로 나뉜다. geom_bar의 position 인자가 두 색을 어떻게 쌓을지 정한다.

2. 실행

JupyterLab에서 책 노트북 옆에 새 노트북 eda_fill_vs_stack.ipynb를 만들고, 4.1절과 같은 chapter-4 커널로 실행했다. 첫 셀은 데이터를 읽고 실험 income-classifier를 고르며, 둘째 셀이 run 두 개를 만든다. 책 셀과 다른 곳은 position을 바꿔 가며 두 번 돈다는 것과, 어느 쪽인지 알 수 있게 position을 파라미터로 기록한다는 것뿐이다.

4장에서 실험과 모델은 MLflow로, 피처는 Feast로 관리하게 됐다. 하지만 둘을 이어 붙이는 일은 여전히 사람 몫이다. 5장에서는 이 연결을 Kubeflow Pipelines(KFP)로 자동화해, 데이터를 읽는 단계부터 추론 결과를 저장하는 단계까지 한 번에 도는 배치 추론 파이프라인을 만든다.

예제 코드는 practical-mlops/chapter-5에 있다.

앞 글에서 만든 홈랩 환경에 피처 스토어 Feast를 올려, 학습과 추론이 같은 피처를 꺼내 쓰는 책 4.2절 실습을 진행한다.

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

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

1. 한눈에 보기

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

Machine Learning Platform Engineering 4장은 MLflow로 실험과 모델을 추적하고 Feast로 피처를 관리하며, 5장은 둘을 Kubeflow Pipelines로 이어 배치 추론 파이프라인을 만든다. 2주차 실습은 1주차에 설치한 홈랩 Kubernetes 클러스터 위에서 그대로 진행한다. 이번에는 Kubernetes 클러스터에 MLflow, Feast, Kubeflow Pipelines를 올린다.

1. 전체 구성

Machine Learning Platform Engineering 3장은 Docker, Kubernetes, CI/CD, 모니터링만 다룹니다. 앞 글에서 MLOps를 루프로 바라보는 관점을 제시하였고 이번에는 그 루프가 올라갈 플랫폼에 대해서 학습합니다. 기존에 홈랩 환경이 구축되어 있어서 별도 kind를 사용하지는 않았습니다.

1. 전체 흐름

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

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

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

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

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

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

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