4편에 걸쳐 MLOps 환경을 처음부터 만들어봤다.MLflow 실험 추적모델 레지스트리FastAPI 서빙GitHub Actions CI/CDPrometheus + Grafana 모니터링결과적으로 docker compose up -d 한 번으로 전체 환경이 올라오는 구조가 됐다.이번 글에서는 코드나 설정을 더 추가하지 않는다.대신 이 구조가 왜 이렇게 만들어졌는지, 그리고 실무에서는 어디까지 확장되는지를 정리해보려고 한다.전체 아키텍처지금까지 만든 구조를 한 번에 보면 이렇다.처음 보면 복잡해 보이지만, 실제로는 역할이 명확하게 나뉜 구조다.왜 이런 구조가 되는가MLOps 시스템은 대부분 다음 네 가지 문제를 해결하려고 만든다.모델 학습 관리모델 저장모델 배포운영 모니터링지금 만든 구조도 결국 이 네 가지..

3편까지 모델 학습, MLflow 실험 기록, 모델 레지스트리 등록, FastAPI 서빙까지 만들었다.문제는 하나다.전부 수동이다.코드를 수정할 때마다 직접 해야 했다.python src/train_experiments.pypython src/register_best_model.py서빙 서버 상태도 로그를 직접 확인해야 했다.이 정도는 개인 실험에서는 괜찮다.하지만 팀 프로젝트나 반복 실험에서는 금방 한계가 온다.그래서 이번 편에서는 두 가지를 붙인다. GitHub Actions로 코드 push 시 학습 파이프라인을 자동 실행하는 CI/CD, 그리고 Prometheus + Grafana로 서빙 서버 상태를 실시간으로 확인하는 모니터링이다.CI/CD: GitHub Actions로 학습 파이프라인 자동화왜 ..

2편에서 하이퍼파라미터 튜닝으로 최적 모델을 찾고, 모델 레지스트리에 등록했다. 하지만 모델을 등록만 해두면 실제 서비스에서는 아무 의미가 없다. 외부 요청을 받아 추론 결과를 반환하는 API 서버가 있어야 비로소 모델이 "서비스"로 동작한다.이번 편에서는 MLflow 레지스트리에 등록된 모델을 불러와 FastAPI로 추론 API를 만들고, Docker 컨테이너로 배포하는 과정을 정리해봤다.전체 구조1편에서 만든 MLflow 인프라 위에 서빙 서버가 하나 추가되는 구조다.[ 클라이언트 (curl, 브라우저, 앱) ] │ │ POST /predict (JSON) ▼[ FastAPI 서빙 서버 (Docker) ] │ │ 모델 로드 ..