많은 팀이 노트북에서 좋은 정확도를 낸 모델을 운영에 올리는 순간 좌절합니다. 재현이 안 되고, 데이터가 바뀌면 성능이 조용히 무너지며, 누가 어떤 버전을 배포했는지 아무도 모릅니다. MLOps는 이 혼돈을 반복 가능한 파이프라인으로 바꾸는 운영 규율입니다.
운영 문제: 모델은 배포 후에 썩는다
소프트웨어와 달리 모델은 코드가 그대로여도 입력 데이터 분포가 변하면 성능이 떨어집니다. 이를 데이터 드리프트라 부릅니다. 한 추천 모델은 출시 6주 만에 클릭률이 12% 하락했는데, 코드 변경은 전혀 없었습니다. 원인은 신규 사용자 유입으로 입력 분포가 달라진 것이었습니다.
아키텍처: 4개의 흐름으로 보는 파이프라인
MLOps 파이프라인은 데이터 파이프라인, 학습 파이프라인, 배포 파이프라인, 모니터링 파이프라인의 네 흐름으로 나눠 보면 명확해집니다. 각 흐름은 독립적으로 트리거되되, 모니터링이 드리프트를 감지하면 학습 파이프라인을 다시 깨우는 폐루프(closed loop)를 이룹니다.
- 데이터: 수집 → 검증 → 피처 스토어 적재
- 학습: 실험 추적 → 모델 레지스트리 등록 → 평가 게이트
- 배포: 카나리 → 점진 롤아웃 → 롤백 트리거
- 모니터링: 예측 분포·지연·드리프트 관측
구현: 재학습 자동화 예시
드리프트가 임계치를 넘으면 자동으로 재학습을 트리거하는 것이 핵심입니다. 파이프라인 정의는 코드로 관리해 재현성을 보장합니다.
if drift_score > 0.15:
trigger_pipeline(
name="retrain-recommender",
params={"window_days": 30, "min_samples": 50000},
)
register_if_better(metric="auc", threshold=0.82)여기서 register_if_better가 중요합니다. 새 모델이 기존 모델보다 검증 지표가 나을 때만 레지스트리에 승격시켜야 무분별한 배포를 막을 수 있습니다.
모니터링과 비용
학습은 GPU 비용이 크기 때문에 무조건 자주 돌리는 것이 정답이 아닙니다. 드리프트 기반 트리거를 쓰면 정해진 주기 재학습 대비 GPU 사용 시간을 40% 이상 줄이면서도 성능 저하를 조기에 잡을 수 있습니다. 예측 지연(p95 latency)과 처리량도 함께 추적해 서빙 비용과 품질의 균형을 잡아야 합니다.
정리
MLOps의 목표는 멋진 모델이 아니라 ‘믿고 맡길 수 있는 흐름’을 만드는 것입니다. 실험 추적, 모델 레지스트리, 드리프트 모니터링이라는 세 축을 갖추면 모델이 썩기 전에 스스로 회복하는 시스템에 다가설 수 있습니다.
