머신러닝 모델을 프로덕션에 올린 팀이 6개월 뒤 가장 자주 겪는 사고는 "모델이 조용히 틀리기 시작했다"는 것이다. 코드는 한 줄도 안 바뀌었고, 인프라도 정상이고, 에러 로그도 깨끗하다. 그런데 추천 클릭률이 떨어지고, 사기 탐지가 새 패턴을 놓치기 시작한다. 원인은 코드가 아니라 세상이 변했기 때문이다 — 입력 데이터의 분포가 학습 때와 달라졌거나(data drift), 정답의 패턴 자체가 바뀌었다(concept drift). 전통적인 소프트웨어 운영(DevOps)은 이런 "조용한 성능 저하"를 다루는 도구가 없다. MLOps는 ML 시스템 특유의 이 문제 — 데이터 의존성, 드리프트, train-serve skew, 재학습 자동화 — 를 운영 규율로 푼다. SAP-C02 시험에서 MLOps는 "운영 후 품질을 어떻게 감시하나", "재학습을 어떻게 자동 트리거하나", "모델 승인·배포를 어떻게 거버넌스하나"라는 운영 아키텍처로 출제된다.
오늘은 MLOps 도구를 나열하는 대신, 드리프트가 왜 발생하고 어떻게 감지하는지, Feature Store가 어떤 구조적 문제를 푸는지, 그리고 완전 자동 재학습 파이프라인이 어떻게 구성되는지를 분해한다.
DevOps의 핵심 가정은 "코드가 변하지 않으면 동작이 변하지 않는다"는 결정성(determinism)이다