모델을 한 번 잘 만드는 일과, 그 모델을 계속 잘 일하게 만드는 일은 전혀 다릅니다. 전자는 실험의 승리이고, 후자는 운영의 승리입니다. 많은 팀이 첫 번째 문턱은 넘습니다. 노트북에서 모델이 돌아가고, 검증 점수도 제법 괜찮게 나옵니다. 그런데 두 번째 문턱에서 자주 멈춥니다. 다음 달에도 같은 방식으로 다시 학습할 수 있는가, 운영 중 성능이 떨어지면 원인을 찾을 수 있는가, 새 모델을 안전하게 교체할 수 있는가 같은 질문 앞에서 갑자기 말문이 막히는 것입니다.
바로 이때 등장하는 것이 MLOps입니다. 이름은 조금 거창해 보이지만, 뜻은 의외로 현실적입니다. 머신러닝을 우연한 성공이 아니라 반복 가능한 제품 개발 방식으로 바꾸는 운영 체계입니다.
MLOps는 왜 필요한가
머신러닝 프로젝트가 어려운 이유는 모델이 똑똑해서가 아니라, 모델이 혼자 존재하지 않기 때문입니다. 모델 뒤에는 데이터 수집, 전처리, 피처 생성, 학습, 평가, 배포, 모니터링, 재학습이 길게 이어져 있습니다. 이 긴 줄 중 하나만 흔들려도 전체 시스템이 흔들립니다.
예를 들어 이탈 고객 예측 모델을 운영한다고 해봅시다. 지난달에는 잘 맞던 모델이 이번 달에는 갑자기 성능이 떨어졌습니다. 이때 팀이 "모델을 다시 학습해 볼까요?"만 반복하면 문제는 계속 돌아옵니다. 실제 원인은 학습 코드가 아니라 입력 데이터 분포의 변화일 수 있고, 피처 생성 배치가 실패했기 때문일 수도 있고, 새 모델은 좋아졌지만 배포 과정에서 예전 전처리 로직이 섞였기 때문일 수도 있습니다.
MLOps는 이런 혼란을 줄이기 위해 생겼습니다. 모델을 만드는 사람, 배포하는 사람, 운영하는 사람이 같은 흐름을 보고, 같은 자산을 관리하고, 같은 기준으로 판단하게 만드는 방식입니다.1
DevOps와 닮았지만, 그대로 복사할 수는 없다
처음 들으면 MLOps는 "DevOps를 머신러닝에 적용한 것"처럼 보입니다. 맞는 말이지만, 절반만 맞습니다. DevOps가 코드의 빌드, 테스트, 배포를 다룬다면, MLOps는 거기에 더해 데이터와 모델까지 함께 다룹니다.2
여기서 큰 차이가 생깁니다. 일반 소프트웨어는 같은 코드를 같은 환경에서 실행하면 대체로 같은 결과가 나옵니다. 하지만 머신러닝은 같은 코드라도 학습 데이터가 달라지면 다른 모델이 나옵니다. 피처 정의가 달라져도 결과가 바뀌고, 하이퍼파라미터가 달라져도 결과가 바뀌며, 심지어 동일한 모델이라도 시간이 지나 현실 데이터가 변하면 성능이 떨어질 수 있습니다.2
그래서 MLOps에서 관리해야 하는 자산은 코드만이 아닙니다. 적어도 다음 것들은 함께 봐야 합니다.
데이터셋 버전
피처 정의와 생성 규칙
학습 코드와 설정값
실험 기록과 평가 결과
학습된 모델 아티팩트
운영 중인 모델 버전과 배포 이력
이 목록을 보면 느낌이 옵니다. MLOps는 단순히 배포 자동화가 아닙니다. 머신러닝 시스템의 모든 흔적을 추적 가능하게 만드는 일에 가깝습니다.
코드만 버전 관리하면 절반만 관리한 것이다
초보 팀은 종종 Git 저장소만 잘 관리하면 충분하다고 생각합니다. 물론 그것도 중요합니다. 하지만 머신러닝에서는 그것만으로 부족합니다.
같은 train.py를 실행해도 어떤 데이터 스냅샷을 썼는지 모르면 결과를 재현할 수 없습니다. 똑같은 데이터라도 피처 생성 규칙이 조금만 바뀌면 전혀 다른 모델이 나옵니다. 모델 파일만 남아 있고 어떤 검증을 통과했는지 기록이 없으면, 그 모델은 사실상 정체불명의 압축 파일과 다를 바가 없습니다.
그래서 MLOps에서 특히 중요한 개념이 계보 추적(lineage) 입니다. 이 모델이 어떤 데이터에서 왔고, 어떤 피처를 거쳤고, 어떤 파라미터로 학습되었으며, 어떤 지표를 얻어 운영에 올라갔는지를 연결해서 볼 수 있어야 합니다.2
이 계보 추적이 중요한 이유는 두 가지입니다. 하나는 재현성입니다. 같은 결과를 다시 만들 수 있어야 비교도 할 수 있습니다. 다른 하나는 책임성입니다. 문제가 생겼을 때 "왜 이런 예측이 나왔는가"를 어느 정도라도 따라갈 수 있어야 운영이 됩니다.
쉽게 말해, MLOps는 모델에게 주민등록증을 만들어 주는 일입니다. 이름 모를 파일이 아니라, 출생 기록이 분명한 자산으로 만드는 것입니다.
노트북의 수동 핸드오프를 파이프라인으로 바꾸기
앞 장에서 데이터 파이프라인과 실험 운영의 중요성을 살펴봤다면, 이제는 그 흐름을 한 단계 더 밀어 올릴 차례입니다. 실험 파이프라인이 "다시 실행 가능한 학습 구조"였다면, MLOps 파이프라인은 "다시 실행 가능한 운영 구조"입니다.
핵심은 수동 핸드오프를 줄이는 것입니다. 데이터 준비를 누가 손으로 하고, 학습을 누가 버튼 눌러서 하고, 성능 보고를 누가 표로 붙여넣고, 배포는 또 다른 팀이 따로 하는 구조에서는 작은 차이와 오해가 계속 쌓입니다. 반면 데이터 준비, 학습, 검증, 승인, 배포가 정해진 순서로 자동 실행되면 릴리스 속도도 빨라지고 실수도 줄어듭니다.23
MLOps에서 자주 나오는 네 가지 약어를 아주 단순하게 이해해 봅시다.23
CI는 코드뿐 아니라 데이터와 모델 관련 변경도 함께 검사하는 단계입니다.
CD는 검증된 파이프라인과 모델을 목표 환경에 안정적으로 내보내는 단계입니다.
CT는 새 데이터나 특정 조건이 생겼을 때 모델을 다시 학습시키는 단계입니다.
CM은 운영 중인 모델과 데이터를 계속 관찰하는 단계입니다.
여기서 특히 CT와 CM이 머신러닝답습니다. 일반 웹 서비스는 배포하면 끝나는 경우가 많지만, 머신러닝은 배포된 뒤부터 현실과 싸워야 하기 때문입니다.
좋은 MLOps의 중심은 배포가 아니라 모니터링이다
많은 입문자가 MLOps를 "모델을 자동으로 배포하는 기술"쯤으로 이해합니다. 하지만 실무에서는 배포보다 더 중요한 것이 있습니다. 바로 운영 중인 모델의 상태를 계속 관찰하는 일입니다.
왜냐하면 모델은 종종 아주 조용하게 망가지기 때문입니다. 서버가 죽는 것도 아니고, API가 500 에러를 내는 것도 아닙니다. 요청은 멀쩡히 처리됩니다. 다만 추천이 점점 덜 맞고, 사기 탐지가 새 패턴을 놓치고, 수요 예측이 천천히 빗나가기 시작합니다. 문제는 이런 실패가 초반에는 눈에 잘 띄지 않는다는 점입니다.2
그래서 운영 모니터링은 정확도 하나만 보는 것으로 끝나지 않습니다. 실제로는 여러 층을 함께 봐야 합니다.
입력 데이터 분포가 학습 때와 달라졌는가
예측값 분포가 갑자기 한쪽으로 쏠리지 않았는가
지연 시간이 늘어나지 않았는가
오류율이 높아지지 않았는가
CPU, 메모리 같은 자원 사용량이 이상하지 않은가
라벨이 늦게 들어오는 문제도 중요합니다. 예를 들어 이탈 예측 모델은 오늘 예측한 결과의 정답을 한 달 뒤에야 알 수 있을 수 있습니다. 그러면 정확도 지표만 기다리다가는 너무 늦습니다. 그래서 현실의 팀은 성능 지표와 운영 지표를 함께 본다는 원칙을 세웁니다.
모델이 나빠졌다면, 무엇이 변한 것인가
운영 중 성능 저하가 보이면 먼저 해야 할 일은 당황이 아니라 구분입니다. 무엇이 변했는지 종류를 나눠서 봐야 합니다.
가장 자주 만나는 것은 데이터 드리프트입니다. 입력 피처의 분포가 달라지는 현상입니다. 예를 들어 겨울 세일 시즌이 시작되면서 고객 유입 경로, 주문 금액, 방문 시간대가 평소와 달라질 수 있습니다. 모델은 예전 세상의 패턴을 기준으로 학습했는데, 지금은 다른 세상이 들어오고 있는 것입니다.5
더 까다로운 것은 개념 드리프트입니다. 같은 입력이라도 정답의 관계 자체가 달라지는 경우입니다. 예전에는 야간 주문이 사기 거래의 강한 신호였는데, 이제는 정상 고객의 심야 이용이 늘어 그 신호가 약해질 수 있습니다. 이 경우는 단순히 입력 분포만 본다고 해결되지 않습니다.5
예측 드리프트도 있습니다. 입력은 비슷해 보여도 모델 출력의 분포가 갑자기 달라지는 현상입니다. 이진 분류 모델이 어느 날부터 거의 모든 샘플에 0.9 이상의 확률을 내놓기 시작했다면, 무언가 비정상일 가능성이 큽니다.5
하지만 현실은 여기서 끝나지 않습니다. 성능 저하처럼 보여도 사실은 모델 문제가 아닐 수 있습니다. 피처 생성 배치가 실패해 결측치가 대량으로 들어왔을 수도 있고, 학습 때와 서빙 때 전처리 규칙이 미묘하게 달라진 학습-서빙 불일치 문제가 원인일 수도 있습니다.3
그래서 좋은 대시보드는 단지 "성능 하락"만 띄우지 않습니다. 어떤 종류의 이상이 발생했는지 분리해서 보여주는 구조를 가져야 합니다. 그래야 원인 추적이 빨라집니다.
경고는 많이 울리는 것보다 잘 울리는 것이 중요하다
모니터링을 처음 붙이는 팀은 대개 의욕이 넘칩니다. 모든 피처의 평균, 분산, 결측치 비율, 예측 분포, 서버 지표에 임계값을 걸어 둡니다. 그리고 며칠 뒤 무슨 일이 벌어질까요. 경고가 너무 많이 울려서 아무도 보지 않게 됩니다.
좋은 MLOps는 경고를 크게 많이 만드는 것이 아니라, 행동 가능한 신호로 줄이는 데서 출발합니다.
예를 들어 입력 분포가 잠깐 흔들린 정도는 정보 수준으로 남기고, 중요한 핵심 피처에서 며칠 연속 이상이 관찰되면 경고로 올리는 식이 더 현실적입니다. 예측값 분포의 미세한 흔들림은 지켜보되, 특정 클래스 비율이 급격히 치우치면 즉시 점검하게 만들 수 있습니다. 시스템 지표도 평균보다 p95 지연 시간이나 오류율 급증처럼 사용자 영향이 큰 항목에 더 민감해야 합니다.
결국 경고 설계는 "변화가 있었는가"보다 "지금 사람이 개입해야 하는가"에 맞춰야 합니다. 알람은 종이 울리는 기술이 아니라, 팀의 집중력을 관리하는 기술입니다.
재학습은 주기표가 아니라 운영 정책이다
운영 중인 모델이 흔들릴 때 많은 팀이 가장 먼저 묻는 질문은 이것입니다.
"그럼 재학습을 얼마나 자주 하면 되죠?"
좋은 질문 같지만, 사실은 조금 부족한 질문입니다. 더 중요한 것은 언제, 어떤 조건에서, 어떤 검증을 거친 뒤 모델을 교체할 것인가입니다.
무작정 매주 재학습한다고 좋은 것은 아닙니다. 데이터가 거의 안 바뀌는 문제라면 계산 자원만 낭비할 수 있습니다. 반대로 변화가 빠른 도메인에서 한 달에 한 번만 재학습하면 이미 늦을 수 있습니다. 그래서 재학습은 일정표라기보다 정책으로 생각하는 편이 맞습니다.6
대표적인 방식은 세 가지입니다.6
시간 기반 재학습: 매주, 매달처럼 정해진 주기로 다시 학습합니다.
트리거 기반 재학습: 성능 하락, 드리프트 증가, 신규 데이터 누적량 같은 조건을 넘으면 실행합니다.
하이브리드 방식: 기본 주기를 두되, 이상 신호가 오면 앞당겨 재학습합니다.
실무에서는 하이브리드가 꽤 현실적입니다. 기본적으로는 일주일에 한 번 재학습하지만, 특정 핵심 피처 드리프트가 임계값을 넘거나 온라인 성능이 급락하면 추가 재학습을 트리거하는 식입니다. 이렇게 하면 안정성과 민첩성을 어느 정도 함께 가져갈 수 있습니다.6
재학습 뒤에는 반드시 비교와 승인, 롤백이 따라와야 한다
재학습이 자동이라고 해서, 새 모델을 무조건 자동 배포해야 한다는 뜻은 아닙니다. 이 둘은 다른 문제입니다.
새로 학습한 모델은 최소한 현재 운영 모델과 비교되어야 합니다. 오프라인 검증 지표가 좋아졌는지, 특정 세그먼트에서 성능이 무너지지 않았는지, 추론 속도나 자원 사용량이 과하게 나빠지지 않았는지 확인해야 합니다.36
특히 고위험 도메인일수록 승인 절차가 필요합니다. 금융, 의료, 채용처럼 잘못된 자동화의 비용이 큰 분야에서는 "성능이 조금 올랐으니 바로 배포"가 아니라, 사람이 결과를 보고 최종 승인하는 구조가 더 적절할 수 있습니다.
그리고 언제나 롤백 가능성이 열려 있어야 합니다. 재학습은 새 출발이 아니라 새 위험이기도 하기 때문입니다. 좋은 MLOps는 새 모델을 뽐내는 체계가 아니라, 새 모델을 의심하면서도 안전하게 시험하는 체계입니다.
MLOps 성숙도는 한 번에 뛰는 사다리가 아니다
현실의 팀은 모두 다른 출발점에 서 있습니다. 어떤 팀은 아직 노트북과 수동 배포 단계에 있고, 어떤 팀은 이미 여러 모델을 자동 재학습하고 있습니다. 그래서 MLOps는 "도입했다 / 안 했다"보다 어느 단계에 있는가로 보는 편이 더 정확합니다.234
아주 단순하게 나누면 보통 세 단계로 생각할 수 있습니다.
첫 단계는 수동 단계입니다. 데이터 준비도 수동, 학습도 수동, 배포도 수동입니다. 아직은 사람이 모든 연결을 기억하고 있습니다. 이 단계는 작게 시작하기에는 괜찮지만, 반복이 늘어날수록 사고가 많아집니다.34
두 번째 단계는 학습 파이프라인 자동화 단계입니다. 새 데이터가 들어오면 정해진 파이프라인이 데이터를 검증하고 모델을 다시 학습하고 평가합니다. 여기서 중요한 것은 모델 자체보다 학습 흐름이 제품화되기 시작한다는 점입니다.34
세 번째 단계는 CI/CD와 CT, 모니터링이 연결된 단계입니다. 코드 변경, 데이터 변경, 모니터링 이벤트가 파이프라인을 트리거하고, 모델 레지스트리와 배포 절차가 연결되며, 운영 상태가 다시 학습 루프로 되돌아옵니다. 이쯤 되면 머신러닝은 개인 작업이 아니라 팀의 시스템이 됩니다.23
중요한 것은, 이 단계를 순서 없이 건너뛰기 어렵다는 사실입니다. 아직 데이터 버전도 정리되지 않았는데 완전 자동 재학습부터 꿈꾸면 대개 복잡도만 늘어납니다.
작은 팀이라면 무엇부터 시작해야 할까
MLOps라는 단어를 들으면 어떤 사람은 곧바로 쿠버네티스, 오케스트레이터, 피처 스토어, 레지스트리, 대시보드 수십 개를 떠올립니다. 하지만 초반부터 그렇게 갈 필요는 없습니다. 오히려 많은 팀은 너무 큰 그림을 먼저 그리다가 하나도 제대로 굴리지 못합니다.
작은 팀이라면 이렇게 시작해도 충분합니다.
먼저 학습 코드를 노트북 밖으로 꺼내 반복 실행 가능한 스크립트나 파이프라인으로 만듭니다. 그다음 실험 기록, 데이터 버전, 모델 아티팩트를 한곳에서 추적합니다. 여기까지만 해도 재현성과 협업 수준이 크게 올라갑니다.
그다음 단계는 운영 후보 모델과 실제 운영 모델을 구분하는 것입니다. 모델 레지스트리가 거창하지 않아도 좋습니다. 중요한 것은 "지금 서비스가 어느 모델을 쓰는지"를 팀이 정확히 아는 것입니다.
이후에는 모니터링을 붙입니다. 처음부터 모든 드리프트 통계를 다 보지 말고, 핵심 피처 몇 개의 분포 변화, 예측값 분포, 지연 시간, 오류율부터 시작하면 됩니다. 마지막으로 재학습 트리거와 승인 절차를 붙이면, 비로소 기본적인 MLOps 루프가 완성됩니다.
즉, 좋은 시작은 완전 자동화가 아니라 반복되는 수동 실수를 하나씩 없애는 것입니다.
결국 MLOps는 머신러닝을 운영 가능한 시스템으로 바꾸는 일이다
머신러닝을 처음 배울 때는 모델이 이야기의 주인공처럼 보입니다. 하지만 실무로 오면 진짜 주인공은 조금 다릅니다. 모델 하나가 아니라, 모델을 계속 만들고, 비교하고, 배포하고, 관찰하고, 교체할 수 있는 시스템이 더 중요해집니다.
MLOps는 유행어가 아닙니다. 멋진 툴 이름을 늘어놓는 장식도 아닙니다. 그것은 코드와 데이터와 모델과 실험 기록을 하나의 재현 가능한 자산으로 다루는 태도이고, 수동 핸드오프를 자동화된 파이프라인으로 바꾸는 설계이며, 배포 후의 침묵 속에서 벌어지는 성능 저하를 빠르게 발견하기 위한 관찰 체계입니다.12
한 문장으로 정리하면 이렇습니다.
MLOps는 모델을 한 번 배포하는 기술이 아니라, 모델이 현실에서 계속 제대로 일하게 만드는 운영 체계다.
이 관점을 갖게 되면 머신러닝은 더 이상 점수표 경쟁이 아닙니다. 데이터가 바뀌고, 환경이 흔들리고, 제품이 성장해도 따라갈 수 있는 시스템 설계가 됩니다. 그리고 바로 그 지점에서, 머신러닝은 실험을 넘어 진짜 제품 개발이 됩니다.
참고
3MLOps: Continuous delivery and automation pipelines in machine learning
5ML Model Monitoring and Drift Detection: Evidently AI + MLflow Production Operations Guide
6AI Model Drift Detection and Retraining: Maintenance Guide for Production ML Systems
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.