머신러닝 모델을 학습시키는 것과 실제 서비스에서 운영하는 것은 다른 문제다.
처음에는 데이터만 준비하고 모델을 학습시키면 끝날 것처럼 보인다.
데이터-> 모델 학습-> 평가-> 배포
하지만 실제 환경에서는 모델을 한 번 배포하고 끝나는 경우가 드물다.
데이터가 바뀌고, 모델을 다시 학습해야 하고, 새로운 버전을 배포해야 한다. 모델의 성능이 떨어지고 있는지도 확인해야 한다.
이런 머신러닝 시스템의 개발과 배포, 운영을 체계적으로 관리하기 위한 개념이 MLOps다.
DevOps가 소프트웨어의 개발과 운영을 연결한다면, MLOps는 여기에 머신러닝의 특성을 추가해서 생각하는 방식에 가깝다.
머신러닝은 코드만 관리하면 끝나지 않는다
일반적인 소프트웨어 프로젝트에서는 Git으로 코드를 관리하고 빌드한 뒤 배포하면 된다.
Code-> Build-> Test-> Deploy
머신러닝에서는 코드 외에도 관리해야 할 것이 많다.
Code
Data
Model
Configuration
Environment
같은 코드라도 학습 데이터가 달라지면 완전히 다른 모델이 만들어질 수 있다.
예를 들어,
Code A + Data A -> Model A
Code A + Data B -> Model B
처럼 같은 코드에서도 데이터가 달라지면 결과가 달라진다.
그래서 머신러닝 시스템에서는 어떤 코드와 어떤 데이터, 어떤 설정으로 모델이 만들어졌는지 추적할 수 있어야 한다.
MLOps가 필요한 이유
모델을 직접 학습시키는 것만 보면 크게 어렵지 않다.
model.fit(X_train, y_train)
문제는 모델을 실제 서비스에 넣은 이후다.
예를 들어 추천 모델을 운영하고 있다고 하자.
처음에는 성능이 좋았는데 시간이 지나면서 사용자의 행동 패턴이 바뀔 수 있다.
학습 당시 데이터-> 현재 사용자 데이터-> 데이터 분포 변화-> 모델 성능 저하
이런 현상을 Data Drift와 연결해서 볼 수 있다.
모델 자체가 갑자기 망가진 것이 아니다.
모델이 학습했던 데이터와 실제 서비스에서 들어오는 데이터의 특성이 달라진 것이다.
따라서 운영 중인 머신러닝 시스템에서는 모델의 결과뿐 아니라 입력 데이터와 성능도 계속 확인해야 한다.
머신러닝 개발 과정
MLOps를 이해하기 위해 전체적인 머신러닝 개발 과정을 보면 좋다.
데이터 수집-> 데이터 정제-> 데이터 전처리-> 학습-> 평가-> 모델 등록-> 배포-> 추론-> 모니터링-> 재학습
한 번의 작업으로 끝나는 Pipeline이 아니다.
서비스가 계속 운영되는 동안 이 과정이 반복된다.
MLOps는 이 반복되는 과정을 안정적으로 운영하는 데 초점을 둔다.
Experiment Tracking
머신러닝을 공부하거나 개발하다 보면 실험을 많이 하게 된다.
예를 들어,
Learning Rate = 0.001
Batch Size = 32
Epoch = 10
Model = A
로 학습한 결과가 있을 수 있다.
그리고 다음 실험에서는
Learning Rate = 0.0005
Batch Size = 64
Epoch = 20
Model = B
를 사용한다.
실험이 몇 개라면 기억할 수 있지만 수십, 수백 개가 되면 어떤 설정으로 어떤 결과가 나왔는지 관리하기 어렵다.
그래서 Experiment Tracking을 사용한다.
Experiment-> Parameters-> Dataset Version-> Model Version-> Metrics-> Result
예를 들어 Accuracy, F1 Score, Loss 같은 평가 지표와 학습 설정을 함께 기록한다.
이렇게 하면 “어떤 설정에서 가장 좋은 모델이 나왔는가?”를 다시 확인할 수 있다.
데이터 버전 관리
머신러닝에서 데이터는 모델의 일부처럼 취급할 필요가 있다.
예를 들어 오늘 학습한 모델이 다음 데이터를 사용했다고 하자.
dataset_v1
나중에 데이터를 추가해서 다시 학습한다.
dataset_v2
그러면 모델도 달라진다.
dataset_v1 -> model_v1
dataset_v2 -> model_v2
그런데 몇 주 뒤 model_v1의 성능이 더 좋았다는 사실을 발견했다고 하자.
어떤 데이터로 학습했는지 추적할 수 없다면 원인을 분석하기 어렵다.
그래서 데이터의 버전을 관리하고 모델과 어떤 데이터가 연결되어 있는지 기록하는 것이 중요하다.
Model Registry
학습한 모델이 많아지면 모델 파일만 저장하는 것으로는 부족하다.
model_v1
model_v2
model_v3
...
이 중 어떤 모델이 개발 중이고 어떤 모델이 실제 서비스에 배포되어 있는지 구분해야 한다.
이런 모델의 버전과 상태를 관리하는 시스템을 Model Registry라고 한다.
개념적으로는 다음과 같은 상태를 관리할 수 있다.
Training
-> Validation
-> Staging
-> Production
예를 들어 새로운 모델이 만들어졌다고 바로 Production에 배포하는 것이 아니라 검증 과정을 거치게 할 수 있다.
Model v5-> Evaluation-> Validation-> Production
문제가 있으면 이전 모델로 되돌릴 수도 있다.
Production-> Model v5
문제 발생-> Model v4로 Rollback
모델도 결국 서비스에서 사용하는 하나의 배포 대상이라는 관점이 필요하다.
CI/CD와 머신러닝
소프트웨어에서는 코드가 변경될 때 자동으로 테스트하고 배포하는 CI/CD를 사용한다.
머신러닝에서도 비슷한 자동화가 필요하다.
다만 머신러닝에서는 코드만 변경되는 것이 아니다.
Code 변경
Data 변경
Model 변경
Configuration 변경
이런 변경이 학습과 배포 과정에 영향을 준다.
예를 들어 새로운 데이터가 들어오면 Pipeline이 자동으로 실행되도록 만들 수도 있다.
새 데이터-> Data Validation-> Training-> Evaluation-> Model Registry-> Deployment
새로운 모델의 성능이 기존 모델보다 좋을 때만 배포하도록 조건을 걸 수도 있다.
New Model Accuracy > Current Model Accuracy-> Deploy
New Model Accuracy <= Current Model Accuracy-> Reject
이런 자동화가 쌓이면 모델을 업데이트할 때 사람이 모든 과정을 직접 실행할 필요가 줄어든다.
모델 배포
학습이 끝났다고 모델이 바로 서비스가 되는 것은 아니다.
실제 애플리케이션에서 모델을 사용할 수 있는 형태로 제공해야 한다.
대표적인 방법 중 하나가 API 서버로 모델을 제공하는 것이다.
Game Server / Web Server-> Model API-> Model-> Prediction
예를 들어 사용자가 데이터를 보내면 서버가 모델의 예측 결과를 반환한다.
Request-> API-> Preprocessing-> Model Inference-> Postprocessing-> Response
여기서 학습할 때 사용했던 전처리와 실제 서비스의 전처리가 달라지면 문제가 발생할 수 있다.
따라서 모델뿐만 아니라 전처리 과정과 의존성, 실행 환경까지 함께 관리해야 한다.
Container가 필요한 이유
머신러닝 모델은 특정 라이브러리와 환경에 의존하는 경우가 많다.
예를 들어,
Python 3.x
PyTorch 특정 버전
CUDA 특정 버전
NumPy 특정 버전
등의 조건이 필요할 수 있다.
개발 환경에서는 정상적으로 동작하는데 서버에서는 라이브러리 버전이 달라서 실행되지 않는 문제가 생길 수 있다.
그래서 Docker 같은 Container 기술을 사용해서 실행 환경을 함께 패키징하는 경우가 많다.
Model + Code + Dependencies + Runtime Environment-> Container
이렇게 하면 동일한 환경을 재현하기 쉬워진다.
Monitoring
모델을 배포했다고 운영이 끝나는 것은 아니다.
오히려 여기서부터가 중요하다.
일반적인 서버라면 CPU, Memory, Network, Response Time 등을 모니터링한다.
머신러닝에서는 여기에 모델과 데이터에 대한 지표가 추가된다.
System Metrics -> CPU -> Memory -> Latency -> Error Rate
ML Metrics -> Prediction Distribution -> Data Drift -> Model Performance
예를 들어 모델이 과거에는
Positive = 40%
Negative = 60%
정도의 결과를 냈는데 어느 순간
Positive = 95%
Negative = 5%
처럼 급격하게 바뀐다면 데이터나 모델에 문제가 있는지 확인할 필요가 있다.
실제 정답을 나중에 알 수 있는 문제라면 Accuracy나 F1 Score 같은 모델 성능 지표도 지속적으로 확인할 수 있다.
Data Drift와 Model Drift
운영 환경에서 자주 나오는 개념이 Drift다.
Data Drift는 입력 데이터의 분포가 학습 당시와 달라지는 현상을 말한다.
Training Data-> 입력 분포 A
Production Data-> 입력 분포 B
예를 들어 사용자 행동 패턴이 시간이 지나면서 크게 바뀌었다면 학습 당시의 데이터와 현재 데이터가 달라질 수 있다.
Model Drift라는 표현은 시간이 지나면서 모델의 예측 성능이나 관계가 변화하는 현상을 넓게 설명할 때 사용된다.
둘을 구분해서 볼 필요가 있다.
Data 변화-> 모델 입력 변화
Model 성능 변화-> 예측 품질 변화
실제 운영에서는 데이터 변화와 모델 성능 변화를 함께 모니터링하는 것이 중요하다.
재학습은 자동화할 수 있다
모델의 성능이 떨어졌다고 사람이 직접 데이터를 모으고 학습하고 배포할 필요는 없다.
조건을 정해 Pipeline을 자동으로 실행할 수 있다.
데이터 축적-> 데이터 검증-> 학습-> 평가-> 기존 모델과 비교-> 조건 만족-> 배포
예를 들어 새로운 모델의 F1 Score가 기존 모델보다 높을 때만 배포하도록 할 수 있다.
New Model F1 > Production Model F1 -> Deploy
반대로 성능이 떨어지면 배포하지 않는다.
이렇게 하면 모델 업데이트도 일반적인 소프트웨어 배포 Pipeline처럼 자동화할 수 있다.
MLOps에서 중요한 것은 재현성이다
MLOps를 공부하면서 가장 중요하게 느껴지는 개념 중 하나가 Reproducibility, 재현성이다.
어떤 모델이 좋은 성능을 냈다면 같은 조건으로 다시 실행했을 때 비슷한 결과를 재현할 수 있어야 한다.
이를 위해 다음과 같은 정보를 관리할 수 있다.
Code Version
Dataset Version
Model Version
Hyperparameters
Dependencies
Environment
Random Seed
예를 들어 Production에서 문제가 발생했을 때,
이 모델은 어떤 코드로 만들어졌는가?
어떤 데이터를 사용했는가?
어떤 Hyperparameter를 사용했는가?
어떤 환경에서 학습했는가?
를 추적할 수 있어야 한다.
이게 되지 않으면 문제가 생겼을 때 원인을 찾기 굉장히 어렵다.
MLOps의 전체 구조
지금까지의 내용을 하나로 연결하면 대략 이런 구조가 된다.
이 과정이 계속 반복된다.
MLOps는 이 전체 생명주기를 안정적으로 운영하기 위한 방법이라고 볼 수 있다.
MLOps와 DevOps의 차이
둘은 상당히 비슷한 부분이 있다.
DevOps가 코드의 개발, 테스트, 배포, 운영을 자동화하고 안정적으로 관리하는 데 초점을 둔다면 MLOps에서는 여기에 머신러닝 특유의 요소가 추가된다.
DevOps -> Code -> Build -> Test -> Deploy -> Monitor
MLOps-> Code-> Data-> Training-> Evaluation-> Model-> Deploy-> Monitor-> Retrain
가장 큰 차이 중 하나는 모델이 데이터에 의해 만들어진다는 것이다.
소프트웨어는 같은 코드라면 일반적으로 같은 프로그램이 만들어진다.
머신러닝에서는 코드가 같아도 데이터나 학습 설정이 달라지면 다른 모델이 만들어진다.
그래서 MLOps에서는 코드뿐만 아니라 데이터와 모델의 생명주기도 함께 관리해야 한다.
정리
MLOps는 단순히 “머신러닝을 자동 배포하는 기술”이라고 보기에는 범위가 넓다.
핵심은 머신러닝 모델이 만들어지고 운영되는 전체 과정을 관리하는 것이다.
데이터-> 학습-> 평가-> 모델 관리-> 배포-> 모니터링-> 재학습-> 반복
특히 머신러닝에서는 코드만 관리해서는 부족하다.
Code
+ Data
+ Model
+ Configuration
+ Environment
이 요소들을 함께 추적하고 재현할 수 있어야 한다.
그리고 실제 서비스에서는 모델을 배포한 이후가 더 중요하다.
데이터가 바뀌고 모델의 성능이 떨어질 수 있기 때문에 모니터링하고 필요하면 다시 학습해야 한다.
결국 MLOps는 새로운 머신러닝 알고리즘을 만드는 기술이라기보다 머신러닝을 실제 서비스에서 지속적으로 운영하기 위한 개발·배포·관리 체계에 가깝다.
모델 하나를 학습시키는 것과 머신러닝 시스템을 운영하는 것은 다른 문제다.
MLOps는 그 차이를 메우는 역할을 한다.