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) ] │ │ 모델 로드 ..

1편에서 Docker Compose로 MLflow 실험 추적 서버를 만들었다.모델을 학습하면서 파라미터, 메트릭, 모델 파일을 자동으로 기록하는 것까지 확인했다.하지만 실험을 한 번만 돌려서는 MLflow를 쓸 이유가 없다.MLflow가 진짜 유용해지는 순간은실험을 여러 번 돌리고 비교할 때다.이번 글에서는 하이퍼파라미터를 바꿔가며 여러 번 학습하고, MLflow UI에서 성능을 비교한 뒤, 가장 좋은 모델을 레지스트리에 등록하고, 코드에서 불러와 추론하는 과정을 다룬다.같은 모델인데 성능이 왜 이렇게 다를까머신러닝 모델은 파라미터 설정에 따라 성능이 크게 달라진다.예를 들어 RandomForest에서 n_estimators = 1과 n_estimators = 200은 완전히 다른 모델이라고 봐도 된다...

회사에서 AI 프로젝트를 하다 보면 항상 비슷한 문제가 생긴다.모델을 여러 번 학습하다 보면 어떤 파라미터로 학습했는지, 정확도가 얼마였는지, 어떤 모델이 제일 좋았는지 기억이 안 난다.처음에는 그냥 노트에 적거나 파일 이름에 버전을 붙여서 관리한다.model_v1model_v2model_finalmodel_final_realmodel_final_real2그리고 어느 순간 깨닫는다.이건 사람이 관리할 수 있는 문제가 아니다.그래서 보통 MLflow 같은 실험 관리 도구를 쓴다.MLflow는 쉽게 말하면 실험 기록 저장, 파라미터/메트릭 기록, 모델 버전 관리를 해준다.문제는 여기서 끝이 아니다.MLflow를 로컬에서 한 번 띄워보는 것과실제로 서버로 운영하는 것은 완전히 다른 이야기다.그래서 이번 시리즈..