3-4. 모델 학습 반복 흐름¶
모델 학습 반복 흐름은 새 데이터가 들어왔을 때 모델을 다시 만들고 이전 모델과 비교하는 절차입니다. 단순히 학습 스크립트를 다시 실행하는 것과 다릅니다. 운영 가능한 흐름은 데이터 버전, parameter, metric, artifact, registry version, 배포 후보를 한 줄로 연결합니다.
이번 과정에서는 기존 Tree 기반 분류모델을 유지합니다. 모델 아키텍처를 새로 바꾸는 것이 아니라, 같은 모델 계열을 반복 학습하고 비교할 수 있는 구조로 고도화합니다. 이 방식이 있어야 다음 데이터 배치가 들어왔을 때도 “이번 모델이 이전 운영 모델보다 나은가”를 판단할 수 있습니다.
3-4-1. 수동 학습과 반복 학습의 차이¶
수동 학습은 한 번 실행해서 모델 파일을 만드는 방식입니다. 실습에서는 빠르게 이해할 수 있지만, 운영에서는 위험합니다. 실행한 사람이 어떤 데이터를 썼는지, parameter가 무엇인지, 결과 metric이 이전 모델과 비교해 어떤지 기록하지 않으면 같은 모델을 재현하기 어렵습니다.
반복 학습은 이 과정을 구조화합니다. 데이터 입력을 정하고, 학습을 실행하고, 평가 metric을 기록하고, 모델 artifact를 MLflow에 log하고, 기준을 만족한 모델만 registry에 등록합니다. 그 다음 배포 후보 alias를 바꿀지 결정합니다.
| 단계 | 수동 학습 | 학습 loop |
|---|---|---|
| 데이터 | 로컬 파일 경로 사용 | dataset version 또는 snapshot 기록 |
| 학습 | 스크립트 1회 실행 | pipeline step으로 반복 실행 |
| metric | 출력값을 사람이 읽음 | MLflow run metric으로 기록 |
| 모델 저장 | 파일명으로 저장 | MLflow Model artifact로 log |
| 배포 후보 | 사람이 파일 선택 | registry alias와 선택 기준으로 선택 |
운영 관점에서는 학습이 성공했다는 사실보다, 학습 결과가 비교 가능하다는 점이 중요합니다. 비교 가능하려면 같은 metric 이름, 같은 데이터 기준, 같은 threshold 정책, 같은 artifact 위치가 필요합니다.
3-4-2. 기본 단계¶
반복 학습은 최소 다섯 단계로 구성합니다. 첫째, 학습 데이터를 고정합니다. 둘째, 모델을 학습합니다. 셋째, 보류out 또는 validation metric을 계산합니다. 넷째, 모델과 metric을 MLflow에 기록합니다. 다섯째, 기준을 만족한 모델을 registry에 등록하고 alias를 후보로 전환합니다.
data snapshot
→ train
→ evaluate
→ log model and metrics
→ register model version
→ compare with 기준 모델
→ choose candidate or keep current
이 흐름에서 가장 중요한 경계는 학습과 배포 사이입니다. 학습이 성공했다고 바로 배포하지 않습니다. 모델이 registry에 등록되더라도, 운영 alias로 바꾸기 전에는 후보일 뿐입니다. 이 구분이 있어야 이전 모델과 비교하고 되돌릴 수 있습니다.
| 단계 | 생성 산출물 | 다음 단계 조건 |
|---|---|---|
| data snapshot | 데이터 경로, 기간, schema | 학습 입력으로 고정 가능 |
| train | fitted model, parameters | 평가 실행 가능 |
| evaluate | precision, recall, confusion matrix, latency 후보 | 이전 기준 모델과 비교 가능 |
| log | MLflow run, model artifact, metric | registry 등록 가능 |
| register | model version, tag, alias candidate | 배포 후보 판단 가능 |
| choose | alias 전환 또는 보류 | serving 배포 후보 확정 |
3-4-3. 모델 선택 기준¶
반복 학습에는 모델 선택 기준이 있어야 합니다. 기준이 없으면 새 모델이 만들어질 때마다 배포 후보가 되고, 운영 품질은 우연에 가까워집니다. 기준은 모델 종류와 비즈니스 목적에 따라 달라질 수 있지만, 최소한 이전 운영 모델과 비교하는 방향이어야 합니다.
이번 Tree 기반 분류모델에서는 Accuracy 하나만 선택 기준으로 쓰지 않습니다. Precision, Recall, Confusion Matrix, threshold를 함께 봅니다. 다만 이 장의 목적은 metric 이론을 다시 설명하는 것이 아니라, 어떤 값을 보고 배포 후보를 고를지 확인하는 것입니다.
| 기준 | 질문 | 문제가 있으면 |
|---|---|---|
| schema | 학습 데이터 schema가 기대와 같은가 | train 중단 |
| metric | 후보 모델이 이전 모델보다 핵심 metric에서 후퇴하지 않는가 | registry 등록은 가능하되 배포 보류 |
| threshold | threshold 정책이 이전 운영 기준과 비교 가능한가 | serving 후보 제외 |
| artifact | MLflow Model artifact와 signature가 남았는가 | 배포 후보 제외 |
| smoke test | local serving 또는 container smoke test가 가능한가 | KServe 전환 보류 |
모델 선택 기준은 완벽한 모델을 찾기 위한 장치가 아닙니다. 운영으로 넘기기 어려운 모델을 미리 거르는 최소 안전장치입니다. 강의에서는 이 기준을 코드 자동화 전체로 구현하기보다, 어떤 산출물이 있어야 반복 학습이 성립하는지 확인하는 데 집중합니다.
3-4-4. 학습 결과와 serving의 연결¶
반복 학습의 마지막은 모델 파일 생성이 아니라 serving 후보 확정입니다. registry alias가 candidate로 설정되면, serving 쪽에서는 그 alias 또는 해당 model version을 읽어 endpoint를 갱신합니다. KServe를 사용하는 경우에는 storageUri가 새 모델 artifact 위치를 가리키거나, custom predictor가 MLflow model URI를 읽도록 설계할 수 있습니다.
이 연결이 없으면 학습 loop와 serving은 분리된 수작업이 됩니다. 수작업 전환은 모델 version 혼선, dependency 불일치, 되돌림 실패를 만들기 쉽습니다. 따라서 학습 loop는 registry와 serving manifest를 함께 갱신하거나, 최소한 어떤 artifact가 serving 후보인지 명확히 남겨야 합니다.
| 연결 지점 | 확인할 값 | 의미 |
|---|---|---|
| MLflow run | run id, metric, artifact URI | 모델 출처 |
| Model Registry | registered model, version, alias | 배포 후보 |
| Container | dependency, environment, image tag | 실행 환경 |
| KServe | InferenceService, storageUri, runtime |
endpoint 선언 |
| Smoke test | health, prediction response | serving 전환 확인 |
이번 장의 결론은 학습 결과와 serving을 분리해서 보지 않는 것입니다. 모델이 좋아졌다는 말은 metric 비교에서 나오고, 모델이 배포 가능하다는 말은 registry, container, serving smoke test가 연결될 때 나옵니다.