[MLOps 실전] Day 5: 재학습과 CI/CD/CT - 스스로 갱신되는 ML 시스템

서론: 한 바퀴를 닫기

Day 1~4에서 데이터·학습·서빙·모니터링을 다뤘다. 이것들은 따로 떨어진 단계가 아니라 하나의 순환 고리다. 모니터링(Day 4)이 드리프트를 감지하면 재학습이 돌고, 새 모델이 검증·배포(Day 3)되고, 다시 모니터링된다. 마지막 편은 이 고리를 자동화하는 것 — ML의 CI/CD에 더해진 CT(Continuous Training)다. 그리고 전체 MLOps를 종합한다.

1. ML의 세 가지 자동화: CI/CD/CT

CI (Continuous Integration):
  코드뿐 아니라 데이터·모델도 검증
  → 코드 테스트 + 데이터 검증(Day 1) + 모델 평가(Day 2)

CD (Continuous Delivery):
  검증된 모델을 자동으로 서빙까지 배포 (Day 3의 카나리 등)

CT (Continuous Training) ← ML 고유:
  새 데이터·드리프트에 따라 모델을 자동 재학습
  → 일반 소프트웨어엔 없는, ML만의 세 번째 축

2. 언제 재학습하는가

스케줄 기반: 정기적으로 (매일/매주) — 단순, 예측 가능
  → 데이터가 꾸준히 쌓이고 패턴이 점진적으로 변할 때

트리거 기반: 드리프트 감지(Day 4) 시 — 효율적, 반응적
  → PSI 임계 초과, 정확도 하락 시 자동 실행

데이터량 기반: 새 데이터가 N건 쌓이면

원칙: 재학습이 항상 좋은 건 아니다.
  잦은 재학습 = 비용↑ + 불안정 위험. 필요할 때만.

3. 재학습 파이프라인

재학습은 새로운 게 아니라, Day 1~3의 파이프라인을 자동 재실행하는 것이다.

[트리거: 스케줄/드리프트]
   ↓
[신규 데이터 수집 + 검증]  ← Day 1 (스키마·드리프트 체크)
   ↓
[피처 생성]               ← Day 1 (피처 스토어)
   ↓
[학습 + 실험 추적]         ← Day 2 (MLflow)
   ↓
[평가: 기존 모델과 비교]   ← 핵심 게이트 (아래)
   ↓ 통과?
[레지스트리 등록 → 카나리 배포] ← Day 2, 3
   ↓
[모니터링]                ← Day 4 → 다시 트리거로 (순환)

4. 자동 배포의 안전장치: 챔피언-챌린저

새 모델이 무조건 더 좋다고 가정하면 안 된다. 반드시 검증 게이트를 둔다.

챔피언-챌린저:
  챔피언 = 현재 프로덕션 모델
  챌린저 = 새로 학습된 모델
  → 챌린저가 같은 평가셋에서 챔피언을 "이겨야만" 승격

게이트 조건 (모두 통과해야 배포):
  □ 평가 메트릭이 챔피언 이상 (회귀 방지 — Day 2)
  □ 데이터 검증 통과 (Day 1)
  □ 공정성·편향 체크 (특정 그룹에서 성능 저하 없나)
  □ 추론 지연·크기가 SLA 이내 (Day 3)

하나라도 실패 → 배포 중단, 챔피언 유지, 알림

def promotion_gate(challenger, champion, eval_set):
    c_score = evaluate(challenger, eval_set)
    champ_score = evaluate(champion, eval_set)
    if c_score < champ_score:                  # 회귀
        return reject("챌린저가 챔피언보다 나쁨")
    if not fairness_check(challenger, eval_set):
        return reject("공정성 검증 실패")
    if latency(challenger) > SLA_MS:
        return reject("지연 SLA 초과")
    return approve()   # 통과 → 카나리 배포 (Day 3)

5. 거버넌스와 재현성

규제·감사가 중요한 도메인(금융·의료)에서는 모든 것을 추적·설명할 수 있어야 한다.

모델 계보(lineage): 이 프로덕션 모델은
  어떤 코드(Git) + 어떤 데이터(DVC, Day 1) + 어떤 실험(MLflow, Day 2)에서
  나왔는가를 완전히 역추적 가능

모델 카드(Model Card): 모델의 용도·한계·성능·편향을 문서화

감사 로그: 누가 언제 어떤 모델을 승인·배포했나 (LLM 앱 Day 5의 로깅 연장)

설명 가능성: 왜 이런 예측을 했나 (SHAP 등) — 규제 대응

재현성(Day 1~2의 핵심)은 단순한 편의가 아니라, 규제 환경에서는 법적 요구사항이다.

6. MLOps 성숙도

조직의 MLOps 수준을 단계로 본다.

Level 0 (수동): 노트북에서 수동 학습·배포. 재현 어려움.
Level 1 (파이프라인 자동화): 학습 파이프라인 자동화, 데이터·모델 버전 관리.
Level 2 (CI/CD/CT 완전 자동): 드리프트 감지 → 자동 재학습 → 자동 검증·배포.

대부분의 조직은 Level 0~1에 있다.
원칙: 한 번에 Level 2를 목표하지 말고, 가장 아픈 곳부터 자동화한다.
  (대부분 데이터 검증·실험 추적이 최대 ROI)

7. 시리즈 종합 체크리스트

1. 데이터 버전관리·검증·피처 스토어로 재현 가능한 토대를 만들었다. (Day 1)
2. 실험 추적·파이프라인·레지스트리로 학습을 관리했다. (Day 2)
3. 배치/실시간 서빙과 카나리 배포로 모델을 안전하게 전달했다. (Day 3)
4. 드리프트 탐지·모니터링으로 모델의 조용한 실패를 감지했다. (Day 4)
5. CI/CD/CT와 챔피언-챌린저로 자동 갱신 고리를 닫았다. (Day 5)

시리즈 마무리

MLOps의 본질은 ML을 일회성 실험에서 신뢰할 수 있는 시스템으로 바꾸는 공학이다. 핵심 교훈은 세 가지다. 첫째, 재현성이 모든 것의 토대다 — 코드·데이터·모델·환경을 함께 버전 관리하지 않으면 나머지는 사상누각이다. 둘째, 모델은 살아있는 시스템이다 — 배포가 끝이 아니라, 모니터링하고 갱신해야 하는 순환의 시작이다. 셋째, 자동화는 수단이지 목적이 아니다 — 가장 아픈 곳부터, 검증 게이트와 함께 자동화한다.

데이터→학습→서빙→모니터링→재학습 다섯 단계는 직선이 아니라 원이다. 이 고리를 닫으면, 모델은 한 번 만들고 잊는 산출물이 아니라 세상의 변화에 발맞춰 스스로 갱신되는 시스템이 된다. 그리고 이 모든 토대에는 앞선 시리즈들 — 대규모 시스템의 관측성과 배포, 분산 시스템의 추적과 멱등성, LLM 앱의 평가 — 의 원칙이 그대로 흐른다. MLOps는 결국, 비결정적이고 데이터에 의존하는 컴포넌트를 위한 DevOps의 확장이다.