MLOps

MLOps는 소프트웨어 개발의 DevOps 방식을 머신러닝에 가져와, 모델의 개발·배포·모니터링을 자동화하고 표준화하는 방법론이다. 모델을 한 번 만들고 끝내지 않고 서비스에 올린 뒤에도 계속 재학습하고 배포해야 할 때 쓴다.

모델 코드는 시스템의 작은 일부다

연구실에서 성능이 좋던 모델도 실제 서비스에서는 자주 실패한다. 들어오는 데이터가 학습 때와 달라지거나, 인프라에 문제가 생기거나, 같은 모델을 다시 만들어 낼 수 없는 경우다.

Google 연구진은 실제 ML 시스템에서 모델 코드는 아주 작은 부분이고, 데이터 수집·검증·서빙·모니터링 같은 주변 코드가 대부분이라고 지적했다. 이 주변부를 관리하지 않으면 기술 부채가 빠르게 쌓인다. MLOps는 이 빈틈을 메우는 방법이다.

파이프라인은 이 순서로 짠다

흔한 흐름은 이렇다. 새 모델이 스테이징에서 미리 정해 둔 점수를 넘으면 자동으로 프로덕션에 배포된다. 처음부터 모든 단계를 갖출 필요는 없다. 실험 추적과 데이터 버전 관리부터 시작하면 효과가 가장 빨리 보인다.

자동화는 필요한 만큼만 한다

Google Cloud는 자동화 수준을 세 단계로 나눈다. 모델을 얼마나 자주 바꾸는지에 따라 고르면 된다.

모델을 1년에 한두 번 바꾸는 작은 프로젝트에 Kubeflow 같은 무거운 플랫폼을 들이면 운영 부담만 커진다.

배포한 뒤부터가 진짜 시작이다

ML 모델은 코드를 건드리지 않아도 성능이 조용히 떨어질 수 있다. 세상이 바뀌면서 입력 데이터도 달라지기 때문이다. 그래서 서버 오류만 볼 게 아니라 입력 분포와 예측 품질도 함께 지켜봐야 한다. 품질이 기준 밑으로 떨어지면 재학습이 자동으로 돌도록 해 둔다.

LLM을 API로 가져다 쓰면 모델을 직접 학습할 일은 줄어든다. 대신 프롬프트 버전 관리, 평가(eval) 파이프라인, 파인튜닝 파이프라인 같은 새 과제가 생기는데, 이를 따로 LLMOps라고 부른다. 버전 관리, 자동 평가, 모니터링이라는 기본 원칙은 같다.

데이터가 계속 바뀌는 서비스에서 주로 쓴다

가장 흔한 건 주기적으로 재학습해야 하는 예측 모델을 운영할 때다. 처음에는 실험 추적만 붙여 쓰다가, 모델을 자주 바꾸게 되면 재학습과 배포까지 자동화하는 경우가 많다.