23. ML Operations 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/23-ops/source.md

짧은 소개

이 장은 머신러닝 모델을 실제 서비스에서 오래 안정적으로 운영하는 방법, 즉 MLOps를 설명해요.

개발 환경에서 잘 맞던 모델도 실제 세상에 나가면 데이터가 바뀌고, 사용자가 바뀌고, 시스템 부하가 바뀌어요. 더 어려운 점은 모델이 완전히 멈추지 않고도 조용히 나빠질 수 있다는 점이에요. 이 장은 그 조용한 실패를 발견하고, 고치고, 다시 배포하고, 책임 있게 관리하는 운영 체계를 다룹니다.

읽는 방법

이 장은 처음부터 모든 도구 이름을 외우려고 하면 복잡해져요. 세 번에 나누어 읽어보면 좋아요.

1회독: "모델은 배포 후에도 계속 돌봐야 하는구나"라는 큰 그림을 잡아요.
  ↓
2회독: 데이터, 모델, 배포, 모니터링이 어떤 순서로 이어지는지 흐름을 봐요.
  ↓
3회독: 기술 부채, feature store, CI/CD, serving, governance, 역할 분담을 섹션별로 파고들어요.

특히 이 장의 핵심 질문은 하나예요.

“모델이 서버에 올라간 뒤, 계속 믿을 수 있게 만들려면 무엇을 관리해야 할까요?”

이 장의 한 줄 요약

MLOps는 모델을 한 번 배포하는 기술이 아니라, 변하는 데이터와 불확실한 예측을 가진 ML 시스템을 계속 관찰하고, 검증하고, 갱신하고, 책임 있게 운영하는 엔지니어링 discipline입니다.

1단계: 중학교 수준

1. 모델은 식물이랑 비슷해요

화분에 식물을 심었다고 끝이 아니죠. 물도 줘야 하고, 햇빛도 봐야 하고, 잎이 시들면 원인을 찾아야 해요.

머신러닝 모델도 비슷해요. 개발실에서 테스트할 때는 잘 맞았더라도, 실제 서비스에 나가면 환경이 달라져요. 사람들의 행동이 바뀌고, 계절이 바뀌고, 제품도 바뀌고, 데이터가 예전과 달라져요.

MLOps는 모델에게 물을 주고, 상태를 확인하고, 필요하면 다시 손봐주는 운영 방법이에요.

2. 일반 프로그램은 크게 아프면 티가 나요

일반 프로그램은 문제가 생기면 보통 에러가 나거나 멈춰요. 마치 자동차 경고등이 켜지는 것과 비슷해요.

하지만 머신러닝 모델은 더 까다로워요. 모델은 계속 대답을 내놓는데, 그 답이 조금씩 틀려질 수 있어요. 겉으로 보기에는 서비스가 정상인 것처럼 보이지만, 추천이 점점 이상해지거나 예측이 점점 부정확해질 수 있어요.

이 장에서는 이것을 silent failure, 즉 “조용한 실패”라고 봐요.

3. MLOps는 모델 운영의 건강검진이에요

병원 건강검진은 병이 커지기 전에 신호를 찾으려고 해요. MLOps도 비슷해요.

즉, MLOps는 모델이 “살아 있는 서비스”로 계속 건강하게 작동하도록 돌보는 체계예요.

4. DevOps와 MLOps의 차이를 쉽게 보면요

DevOps는 일반 소프트웨어를 빠르고 안정적으로 배포하기 위한 방법이에요. 예를 들어 쇼핑몰 앱의 버튼, 결제 페이지, 서버를 안전하게 바꾸는 일이에요.

MLOps는 여기에 데이터와 모델이 추가돼요. 모델은 같은 코드라도 어떤 데이터로 학습했는지에 따라 다르게 행동해요. 그래서 MLOps는 코드뿐 아니라 데이터, 학습 과정, 모델 버전, 평가 결과까지 함께 관리해야 해요.

5. 이 장에서 나오는 어려운 말을 일상어로 바꾸면요

1단계 중간 정리

MLOps는 “모델 배포 버튼”이 아니에요.

모델이 실제 세상에서 계속 잘 작동하는지 지켜보고, 문제가 생기면 안전하게 고치고, 누가 무엇을 했는지 기록하는 전체 운영 방식이에요.

2단계: 고등학교 수준

1. 이제 블랙박스 안의 흐름을 볼게요

1단계에서는 MLOps를 모델 건강검진으로 봤어요. 이제 실제로 어떤 순서로 돌아가는지 살펴볼게요.

데이터 수집
  ↓
데이터 정리와 feature 생성
  ↓
모델 학습
  ↓
모델 검증
  ↓
모델 등록과 배포
  ↓
실시간/배치 예측 제공
  ↓
성능과 시스템 상태 모니터링
  ↓
필요하면 재학습 또는 롤백

이 흐름에서 중요한 점은 마지막이 “끝”이 아니라 다시 처음으로 이어진다는 거예요. 운영 중에 새 데이터가 쌓이고, 그 데이터로 모델을 다시 평가하거나 학습해야 해요.

2. 왜 ML은 일반 소프트웨어보다 더 조심해야 할까요?

일반 소프트웨어는 보통 규칙이 명확해요.

입력 → 사람이 작성한 규칙 → 출력

머신러닝은 조금 달라요.

입력 → 데이터로 학습한 모델 → 확률적인 출력

모델의 출력은 “항상 맞는 정답”이라기보다 “지금까지 배운 패턴으로 볼 때 가장 그럴듯한 예측”이에요. 그래서 데이터가 바뀌면 예측 품질도 바뀔 수 있어요.

3. 데이터 drift를 간단한 확률 관점으로 보면요

모델은 과거 학습 데이터의 분포를 보고 배워요. 아주 단순하게 쓰면 이렇게 생각할 수 있어요.

학습 때 본 데이터 분포: P_train(x)
실제 운영 때 들어오는 데이터 분포: P_prod(x)

두 분포가 비슷하면 모델이 배운 패턴이 잘 통할 가능성이 높아요. 하지만 시간이 지나면서 P_prod(x)가 달라지면 모델은 예전 세상을 기준으로 새 세상을 예측하게 돼요.

예를 들어 여름 쇼핑 데이터를 많이 보고 학습한 추천 모델이 겨울 소비 패턴을 만나면 성능이 떨어질 수 있어요. 이것이 data drift의 기본 직관이에요.

4. DevOps와 MLOps 비교

MLOps는 DevOps를 버리는 것이 아니라, DevOps 위에 ML 특유의 요소를 더하는 방식이에요.

5. CI/CD도 ML에서는 더 길어져요

일반 소프트웨어 CI/CD는 보통 코드를 테스트하고 배포하는 흐름이에요. ML에서는 후보 모델을 만들고, 데이터와 모델을 함께 검증해야 해요.

코드 변경 또는 새 데이터 도착
  ↓
데이터 스키마와 품질 검사
  ↓
feature 생성
  ↓
모델 학습
  ↓
성능 평가
  ↓
기존 모델과 비교
  ↓
모델 registry에 등록
  ↓
staging 배포
  ↓
canary, shadow, blue-green 같은 방식으로 점진 배포
  ↓
문제 있으면 rollback

여기서 핵심은 “새 모델이 만들어졌다”가 아니라 “새 모델이 실제 운영 조건에서도 더 낫고 안전한지 확인했다”예요.

6. 기술 부채는 왜 쉽게 커질까요?

ML 시스템에서는 작은 변경 하나가 여러 곳에 영향을 줄 수 있어요.

예를 들어 숫자 feature를 구간으로 나누는 방식을 조금 바꾸면:

feature 값 변화
  ↓
모델 입력 분포 변화
  ↓
모델 성능 변화
  ↓
사용자에게 보이는 추천/판정 변화
  ↓
다시 쌓이는 학습 데이터 변화

이처럼 “하나 바꾸면 다 바뀌는” 현상을 원문은 CACHE, 즉 Change Anything Changes Everything 관점으로 설명해요.

7. 운영 지표도 두 종류로 나누어 봐야 해요

일반 서버 모니터링만으로는 ML 모델의 조용한 성능 저하를 발견하기 어려워요. 그래서 MLOps는 모델 지표와 인프라 지표를 함께 봐요.

8. 간단한 수학 관계로 보는 운영 판단

MLOps에서 쓰는 수학은 복잡한 공식보다 “비교와 기준선”이 중요해요.

성능 하락량 = 기준 성능 - 현재 성능
사용률 = 사용한 자원 / 전체 자원
오류율 = 실패 요청 수 / 전체 요청 수

예를 들어 정확도가 90%에서 83%로 떨어졌다면 성능 하락량은 7%p예요. 이 하락이 하루 만에 생겼는지, 6개월 동안 천천히 생겼는지에 따라 대응 방식이 달라져요.

2단계 중간 정리

MLOps의 논리는 간단해요.

변하는 데이터 때문에 모델 성능이 변해요.
그래서 데이터, 모델, 코드, 인프라를 함께 버전 관리해요.
그리고 배포 후에도 모델 지표와 시스템 지표를 계속 관찰해요.
문제가 보이면 재학습, 점진 배포, 롤백, governance로 통제해요.

3단계: 대학교 수준

이제 원문 섹션 흐름을 따라가며 더 엄밀하게 볼게요. 이 단계에서는 MLOps를 단순한 도구 묶음이 아니라, 확률적 모델을 생산 시스템으로 유지하기 위한 시스템 공학으로 이해해야 해요.

1. Purpose: 왜 MLOps가 필요한가요?

원문의 출발점은 분명해요. 개발 환경에서는 잘 작동하던 ML prototype이 production에서는 왜 실패할까요?

핵심 이유는 production 환경이 고정되어 있지 않기 때문이에요.

• 데이터 분포가 바뀌어요.
• 사용자 행동이 바뀌어요.
• 외부 환경과 계절성이 바뀌어요.
• 시스템 장애나 지연이 생겨요.
• 모델은 확률적으로 행동해서 문제가 조용히 누적될 수 있어요.

전통적인 소프트웨어 실패는 보통 “명령한 로직이 실행되지 않음”으로 드러나요. 반면 ML 실패는 “계속 실행되지만 예측 품질이 악화됨”으로 나타날 수 있어요. 그래서 MLOps는 monitoring, automation, governance, retraining, versioning을 통해 조용한 실패를 드러내고 관리하려는 discipline이에요.

원문이 제시하는 MLOps의 학습 목표는 크게 다음으로 묶을 수 있어요.

2. Introduction to Machine Learning Operations

원문은 MLOps를 실험적으로 검증된 모델과 안정적인 production system 사이를 연결하는 운영 discipline으로 설명해요.

ML 시스템의 어려움은 모델이 단독으로 존재하지 않는다는 점이에요. 모델은 데이터 pipeline, feature engineering, training job, serving infrastructure, monitoring dashboard, 조직의 승인 절차와 함께 움직여요.

2.1 Silent Failure Problem

Silent failure는 모델이 멈추지 않고도 나빠지는 문제예요.

학습 당시의 세상
  ↓
모델이 그 패턴을 학습함
  ↓
현실의 데이터와 행동이 변함
  ↓
모델은 계속 예측하지만 정확도가 낮아짐
  ↓
에러 로그 없이 비즈니스 손실이나 사용자 피해가 누적됨

이 문제를 다루려면 모델의 예측 결과뿐 아니라 입력 분포, confidence, 하위 그룹별 성능, 사용자 피드백, downstream effect까지 봐야 해요.

2.2 운영 discipline으로서의 MLOps

MLOps는 다음 성질을 production workflow에 넣어요.

원문의 ridesharing 수요 예측 예시는 이 점을 잘 보여줘요. 실험에서는 정확도와 latency가 좋아도, 실제 서비스에서는 데이터 품질이 흔들리고 시간 패턴이 계절에 따라 바뀌며 실시간 응답 요구도 생겨요. MLOps는 이런 운영 복잡성을 관리하는 틀이에요.

3. Historical Context: DevOps에서 MLOps로

MLOps는 DevOps에서 출발하지만, 그대로 복사해서는 충분하지 않아요.

3.1 DevOps

DevOps는 개발팀과 운영팀이 분리되어 생기던 지연과 책임 불일치를 줄이기 위해 발전했어요. 핵심은 자동화, 협업, 반복 배포, infrastructure as code예요.

원문은 Jenkins, Docker, Kubernetes 같은 도구가 CI/CD와 container orchestration의 기반이 되었다고 설명해요.

개발자가 코드 변경
  ↓
자동 테스트
  ↓
패키징
  ↓
배포
  ↓
모니터링과 피드백

이 흐름은 일반 소프트웨어에서는 강력했어요. 하지만 ML에서는 배포 대상이 코드만이 아니에요.

3.2 MLOps

MLOps는 DevOps의 자동화와 협업 원리를 받아들이되, 다음 ML 고유 문제를 추가로 다뤄요.

원문의 retail recommendation 예시는 uptime만 보는 모니터링의 한계를 보여줘요. 시스템은 살아 있었지만 data drift 때문에 추천 품질이 떨어졌고, 매출 손실이 뒤늦게 발견돼요. 그래서 MLOps는 engineering best practice를 넘어 business necessity가 됩니다.

4. Technical Debt and System Complexity

이 장에서 가장 중요한 이론적 축 중 하나가 hidden technical debt예요. 기술 부채는 당장은 빠른 선택이지만, 나중에 유지보수 비용과 시스템 위험으로 돌아오는 선택이에요.

ML 시스템의 부채는 코드뿐 아니라 데이터, feature, 모델 출력, 설정, feedback loop에서 생겨요.

4.1 Boundary Erosion

Boundary erosion은 컴포넌트 사이의 경계가 흐려지는 현상이에요.

전통 소프트웨어에서는 모듈 간 interface가 비교적 명확해요. 하지만 ML 시스템에서는 data pipeline, feature engineering, model training, downstream application이 데이터 흐름으로 암묵적으로 묶여요.

문제는 작은 변화가 멀리 전파된다는 점이에요.

전처리 방식 변경
  ↓
feature 분포 변경
  ↓
모델 입력 의미 변경
  ↓
모델 성능 저하
  ↓
downstream 서비스 결과 변경

원문은 CACHE, 즉 Change Anything Changes Everything을 소개해요. feature encoding, hyperparameter, 데이터 선택 기준 같은 작은 변경도 전체 시스템 행동을 바꿀 수 있다는 뜻이에요.

대응 방법은 명확해요.

• 데이터 수집, feature 생성, 모델 학습, serving logic을 분리해요.
• 각 단계의 입력과 출력 schema를 문서화해요.
• interface contract를 정하고 검증해요.
• 단계별 테스트와 monitoring을 둬요.

대학 수준으로 보면, boundary erosion은 소프트웨어 공학의 information hiding과 modularity가 데이터 흐름 때문에 약해지는 문제예요. 전통적인 compile-time type check는 모델의 통계적 행동 변화를 잡지 못하므로, 계약은 schema와 통계 분포까지 포함해야 해요.

4.2 Correction Cascades

Correction cascade는 한 문제를 고치려던 수정이 다음 문제를 만들고, 그 수정이 다시 다른 수정을 요구하는 연쇄예요.

예를 들어 기존 churn prediction 모델을 새 제품에 fine-tuning했다고 해볼게요. 이전 제품의 feature encoding이나 labeling 기준이 새 제품에는 맞지 않을 수 있어요. 성능 문제가 생기면 모델을 조금씩 패치하지만, 실제 원인은 더 앞단의 feature selection이나 label definition일 수 있어요.

기존 모델 재사용
  ↓
새 도메인에서 성능 문제
  ↓
모델 패치
  ↓
feature 또는 label 문제 발견
  ↓
데이터 pipeline 수정
  ↓
모델 재학습과 재평가
  ↓
배포 전략 재조정

원문은 sequential model development가 효율적일 수 있지만 hidden dependency를 만든다고 설명해요. 작은 데이터셋이나 안정적인 문제에서는 fine-tuning이 적절할 수 있어요. 반대로 데이터가 크고 빠르게 변하면 새 architecture나 scratch retraining이 장기적으로 더 안전할 수 있어요.

시스템 이론 관점에서는 correction cascade가 tight coupling의 결과예요. 모델 A의 출력이 모델 B의 학습 데이터가 되면 두 모델은 코드 interface 없이도 강하게 연결돼요. 이런 의존성은 정적 dependency analysis로 잘 보이지 않기 때문에 MLOps에서는 lineage와 explicit dependency tracking이 중요해요.

4.3 Interface and Dependency Challenges

원문은 두 가지 대표 패턴을 강조해요.

예를 들어 credit scoring 모델의 출력이 eligibility engine에 들어가고, 그 결과가 다시 미래 applicant pool을 바꾼다면 feedback loop가 생겨요. 이 연결이 문서화되어 있지 않으면 모델 업데이트가 bias를 조용히 키울 수 있어요.

대응책은 access control, formal interface contract, documented schema, data versioning, lineage tracking, prediction usage monitoring이에요.

4.4 System Evolution Challenges

ML 시스템은 시간이 지나며 다음 부채를 쌓기 쉬워요.

추천 시스템은 feedback loop의 전형적인 예예요. 추천된 item이 클릭을 유도하고, 클릭 데이터가 다시 학습 데이터가 되면 모델은 자신이 만든 세계를 다시 학습할 수 있어요.

4.5 Real-World Technical Debt Examples

원문은 실제 사례로 부채가 이론이 아니라는 점을 보여줘요.

여기서 중요한 결론은 “모델 코드”만 잘 짜서는 부족하다는 점이에요. feature store, versioning, monitoring, modular pipeline이 기술 부채를 줄이는 운영 인프라로 등장합니다.

5. Development Infrastructure and Automation

이제 원문은 “문제를 알았으니 어떤 인프라로 대응할 것인가”로 넘어가요.

5.1 Data Infrastructure and Preparation

ML 시스템의 신뢰성은 데이터 처리의 반복 가능성에서 시작해요. 데이터는 수집, 정제, 변환, 저장, labeling, serving까지 이어져요. 운영 환경에서는 이 모든 과정이 추적 가능하고 재현 가능해야 해요.

Data Management

Data management는 초기 데이터 준비를 넘어, ML lifecycle 전체에서 데이터 artifact를 관리하는 일이에요.

핵심 요소는 다음과 같아요.

• dataset versioning: 특정 시점의 데이터 snapshot을 남겨요.
• annotation workflow: labeling 기준과 변경 이력을 관리해요.
• cloud object storage: raw data와 processed data를 안정적으로 보관해요.
• orchestration: Airflow, Prefect, dbt 같은 도구로 ingestion, validation, transformation, loading을 관리해요.

예를 들어 산업용 predictive maintenance에서는 sensor stream과 maintenance log를 결합하고, rolling average 같은 feature를 만들어 feature store에 저장해요. 이 pipeline은 versioning, monitoring, model registry와 연결되어야 prediction 하나가 어떤 데이터에서 나왔는지 추적할 수 있어요.

Feature Stores

Feature store는 data engineering과 machine learning 사이의 추상화 계층이에요.

핵심 목적은 training과 inference에서 같은 feature logic을 쓰게 하는 것이에요. 그렇지 않으면 training-serving skew가 생겨요.

Offline feature store: 과거 데이터와 label을 이용해 학습용 feature 제공
Online feature store: 최신 요청에 대해 낮은 latency로 serving용 feature 제공

Feature store가 중요한 이유는 세 가지예요.

Versioning and Lineage

ML 재현성은 코드만으로는 불가능해요. 다음 artifact가 모두 맞아야 해요.

• raw data
• processed data
• feature definition
• training code
• hyperparameter와 configuration
• model weights
• environment
• evaluation metrics
• serving infrastructure version

Lineage는 이 artifact들의 의존 관계 그래프예요.

Raw data
  ↓
Cleaning / labeling
  ↓
Feature set
  ↓
Training run
  ↓
Model artifact
  ↓
Registry entry
  ↓
Deployment endpoint

문제가 생겼을 때 lineage가 있으면 “데이터가 바뀌었나요?”, “feature definition이 바뀌었나요?”, “serving 환경이 모델 version과 맞나요?” 같은 질문에 답할 수 있어요.

5.2 Continuous Pipelines and Automation

Automation은 ML 시스템이 새 데이터와 바뀌는 목표에 맞춰 계속 진화하도록 해요. 여기서 자동화는 단순 편의가 아니라 재현성과 안정성의 조건이에요.

CI/CD Pipelines

ML CI/CD는 일반 CI/CD보다 더 많은 artifact를 다뤄요.

코드 checkout
  ↓
데이터 전처리
  ↓
후보 모델 학습
  ↓
성능 검증
  ↓
모델 패키징
  ↓
serving 환경 배포
  ↓
모니터링과 rollback

원문은 idempotency도 중요하게 설명해요. 같은 pipeline을 다시 실행했을 때 같은 결과가 나와야 디버깅이 가능해요. ML training은 random seed, data shuffling, hardware 차이 때문에 결과가 흔들릴 수 있으므로 deterministic data ordering, 고정 seed, 일관된 compute environment가 필요해요.

Training Pipelines

Training pipeline은 ad hoc notebook 실험을 production-grade workflow로 바꾸는 과정이에요.

TensorFlow, PyTorch, Keras 같은 framework는 모델 개발 기반을 제공하지만, MLOps에서는 여기에 다음이 붙어야 해요.

• training script와 config version control
• experiment tracking
• hyperparameter tuning
• neural architecture search
• automatic feature selection
• cloud GPU/TPU resource orchestration
• retraining trigger
• baseline metric과 비교

즉, training은 “한 번 실행하는 작업”이 아니라 “새 데이터나 성능 저하에 따라 반복 가능한 운영 절차”가 돼요.

Model Validation

Model validation은 배포 전 모델이 production에 나갈 준비가 되었는지 검증하는 단계예요.

기본적으로 holdout test set에서 accuracy, AUC, precision, recall, F1 같은 지표를 봐요. 하지만 원문은 offline metric만으로 충분하지 않다고 말해요.

그래서 다음을 결합해야 해요.

특히 고위험 영역에서는 자동 지표가 놓치는 문제를 사람이 검토해야 해요.

5.3 Infrastructure Integration Summary

원문은 인프라 요소들이 앞서 본 기술 부채를 직접 줄인다고 정리해요.

중요한 전환점은 여기예요. 개발 인프라는 모델을 안전하게 만들 준비를 해주지만, 실제 배포 후에는 production operations가 필요해요.

6. Production Operations

Production operations는 검증된 모델을 실제 서비스로 운영하는 단계예요. 여기서는 latency, throughput, availability, rollback, drift, governance가 모두 중요해져요.

6.1 Model Deployment and Serving

Model Deployment

Model deployment는 model artifact를 live system component로 바꾸는 일이에요.

필요한 작업은 다음과 같아요.

• 모델과 dependency를 container로 packaging해요.
• model registry에 version, metric, metadata를 저장해요.
• staging 또는 QA 환경에서 검증해요.
• shadow, canary, blue-green 같은 점진 배포 전략을 써요.
• 문제가 생기면 stable model로 rollback해요.
• inference endpoint를 REST API, batch job, serverless endpoint 등으로 노출해요.

배포 전략을 비교하면 이렇습니다.

Canary에서 문제가 드러나면 단순히 “성능 낮음”으로 끝내면 안 돼요. 데이터 분포, feature importance 변화, 하위 사용자 그룹, latency, business impact를 함께 분석해야 해요.

Inference Serving

Serving은 모델이 실제 요청에 예측을 돌려주는 runtime layer예요. 원문은 대규모 서비스에서는 inference query가 매우 많기 때문에 serving system design이 핵심이라고 설명해요.

Serving 방식은 크게 세 가지예요.

Serving system은 SLA와 SLO를 만족해야 해요. 예를 들어 P95 latency, P99 latency, error rate, uptime 같은 목표를 정하고 이를 지켜야 합니다.

원문이 소개하는 serving 최적화 전략은 다음과 같아요.

대학 수준에서 serving은 최적화 문제예요. 단순히 정확도만 최대화하는 것이 아니라, accuracy, latency, cost, throughput, availability를 함께 고려해야 해요.

Edge AI Deployment Patterns

Edge AI는 inference를 중앙 cloud가 아니라 데이터가 생기는 곳 근처에서 수행하는 방식이에요. latency, bandwidth, privacy, connectivity 문제 때문에 중요해요.

Edge 환경에서는 제약이 훨씬 강해요.

원문은 hierarchical deployment를 설명해요.

Sensor-level processing
  ↓
Edge gateway processing
  ↓
Cloud coordination

latency-critical decision은 local에 남기고, 계산이 무거운 작업이나 aggregated learning은 cloud가 맡는 구조예요.

Edge deployment에서는 quantization, pruning, knowledge distillation, TensorFlow Lite Micro, CMSIS-NN, hardware-specific library가 중요해요. 또한 OTA update는 보안 서명, 무결성 검증, rollback, differential compression, 연결 상태와 전력 상태를 고려해야 해요.

실시간 시스템에서는 worst-case execution time을 따져야 해요. 평균 latency가 좋아도 최악의 경우가 safety threshold를 넘으면 안 되기 때문이에요.

6.2 Resource Management and Performance Monitoring

Infrastructure Management

MLOps infrastructure는 고정된 서버 묶음이 아니라 versioned, programmable system으로 관리돼야 해요. 그래서 Infrastructure as Code가 중요해요.

IaC는 server, network, storage, GPU/TPU resource, Kubernetes cluster 같은 환경을 code처럼 정의하고 version control하는 방식이에요.

Infrastructure definition
  ↓
Review and version control
  ↓
Automated provisioning
  ↓
Consistent training/serving environment
  ↓
Audit and rollback 가능

MLOps workload는 일반 web service와 resource pattern이 달라요.

원문은 resource management가 cost, accuracy, inference latency, training throughput 사이의 다차원 최적화라고 설명해요.

예를 들어 GPU 사용률은 높을수록 좋지만, serving에서는 latency 여유가 필요해요. batch training은 GPU utilization 80% 이상을 목표로 할 수 있지만, serving workload는 reliability와 tail latency를 위해 다른 기준이 필요해요. 또한 memory bandwidth, power budget, thermal throttling도 운영 지표가 됩니다.

Model and Infrastructure Monitoring

Monitoring은 production ML의 눈이에요. 모델이 live 상태가 되면 실제 입력, 변화하는 분포, 사용자 행동에 노출돼요.

모니터링은 두 층으로 나뉩니다.

원문은 drift를 두 종류로 설명해요.

수학적으로는 다음처럼 볼 수 있어요.

Data drift: P_prod(x)가 P_train(x)에서 멀어짐
Concept drift: P_prod(y | x)가 P_train(y | x)에서 달라짐

여기서 x는 입력 feature, y는 target이에요. Data drift는 입력의 모양이 바뀌는 것이고, concept drift는 같은 입력이라도 정답과의 관계가 바뀌는 것이에요.

원문은 특히 “천천히 누적되는 장기 성능 저하”를 강조해요. 하루에 0.05%씩 나빠지면 일별 alert에는 안 걸릴 수 있지만, 1년이면 큰 문제가 됩니다. 그래서 daily, weekly, quarterly baseline과 sliding window comparison, seasonal performance profile이 필요해요.

모니터링 시스템 자체도 장애에 대비해야 해요. Prometheus나 Grafana가 죽으면 모델 상태를 볼 수 없어요. 그래서 secondary metric collector, local logging, heartbeat check, cross-monitoring이 필요해요.

Multi-region 환경에서는 monitoring도 distributed coordination 문제가 돼요. 네트워크 partition 때문에 한 지역만 이상하게 보일 수 있고, false positive alert를 줄이기 위해 consensus-based alerting, circuit breaker coordination, distributed metric aggregation이 필요해요.

6.3 Model Governance and Team Coordination

Model Governance

Governance는 모델이 투명하고, 공정하고, 규정에 맞게 작동하도록 보장하는 정책과 절차예요.

원문은 governance의 세 목표를 다음처럼 정리할 수 있어요.

개발 단계에서는 SHAP, LIME 같은 post hoc explanation을 사용해 feature 영향도를 설명할 수 있어요. 배포 전에는 대표성 있는 dataset으로 fairness, robustness, model behavior를 감사해야 해요. 배포 후에는 drift, subgroup disparity, recurring failure mode를 계속 관찰해야 해요.

Governance가 pipeline에 들어가면, 모델 승격은 단순히 accuracy threshold를 넘는 것이 아니라 fairness, explainability, auditability 조건도 만족해야 해요.

Cross-Functional Collaboration

MLOps는 혼자 하는 일이 아니에요. data scientist, ML engineer, software developer, infrastructure specialist, product manager, compliance officer가 함께 일해요.

협업을 가능하게 하는 공통 artifact가 중요해요.

• experiment log
• model version
• metric record
• model registry
• Git commit
• data dictionary
• schema reference
• lineage documentation
• dashboard

MLflow는 parameter, metric, artifact, registry를 공유 reference로 만들고, Weights & Biases는 실험 비교와 metric visualization을 돕는 예로 제시돼요. 중요한 것은 도구 자체보다 팀이 같은 사실을 보고 대화할 수 있다는 점이에요.

Stakeholder Communication

원문은 business stakeholder와의 소통도 MLOps 역량으로 봐요. ML 시스템은 확률적이고 trade-off가 많기 때문에 “정확도만 올려주세요” 같은 요청은 바로 실행 계획이 될 수 없어요.

예를 들어 accuracy를 85%에서 87%로 올리려면 데이터 수집이 4배 필요하고, inference latency가 50ms에서 120ms로 늘어날 수 있어요. 이런 trade-off를 숫자로 설명해야 stakeholder가 의사결정할 수 있어요.

기술 지표도 비즈니스 언어로 바꿔야 해요.

원문은 데이터 준비 60%, 모델 개발 25%, 배포/모니터링 15%라는 식으로 timeline expectation을 명확히 전달하는 것도 중요하다고 말해요. 모델 학습만이 프로젝트의 대부분이라고 오해하면 일정과 자원 판단이 흔들려요.

6.4 Managing Hidden Technical Debt

숨은 기술 부채를 관리하려면 reactive fix만으로는 부족해요. 원문은 다음 원칙을 제시해요.

핵심은 복잡성을 없애는 것이 아니에요. 복잡성을 견딜 수 있게 구조화하는 것이에요.

7. Roles and Responsibilities

원문은 MLOps가 여러 전문 역할의 협업으로 이루어진다고 설명해요. 한 사람이 전체 lifecycle을 안정적으로 책임지기는 어렵기 때문이에요.

7.1 Roles

Data Engineers

Data engineer는 ML의 기반이 되는 데이터 인프라를 만들어요. transactional database, log stream, sensor 같은 source에서 데이터를 가져오고, object storage나 warehouse에 저장하고, cleaning, join, aggregation을 수행해요.

MLOps 관점에서는 versioned pipeline, metadata catalog, schema, lineage, access control이 중요해요.

Data Scientists

Data scientist는 business problem을 classification, regression, forecasting 같은 learning task로 바꾸고, 적절한 evaluation metric을 정해요. EDA, feature selection, model training, hyperparameter tuning, cross-validation, error analysis를 수행해요.

배포 후에도 drift 분석과 retraining strategy 정의에 참여해요.

ML Engineers

ML engineer는 연구 artifact를 production system component로 바꾸는 역할이에요. 모델 interface를 만들고, FastAPI나 serving framework로 API를 제공하고, Docker/Kubernetes 환경에서 배포 가능하게 만들어요.

또한 quantization, pruning, batch serving, dynamic model selection 같은 최적화로 latency, throughput, cost 제약을 맞춰요.

DevOps Engineers

DevOps engineer는 인프라를 provision하고 automation pipeline을 운영해요. Terraform, CloudFormation, Ansible 같은 IaC 도구와 Docker, Kubernetes, Jenkins, GitHub Actions, Prometheus, Grafana 같은 운영 도구가 이 역할과 연결돼요.

MLOps에서는 일반 DevOps보다 GPU/TPU, model artifact, training job, drift-aware alert 같은 요소를 더 이해해야 해요.

Project Managers

Project manager는 목표, 성공 기준, 일정, dependency, 자원을 조율해요. ML 프로젝트는 데이터 준비, 모델 개발, 인프라, 배포, 모니터링이 서로 물려 있으므로 handoff가 중요해요.

예를 들어 churn prediction 프로젝트에서는 데이터 요구사항, baseline model, staging deployment, post-deployment monitoring 같은 milestone을 관리해요.

Responsible AI Lead

Responsible AI Lead는 모델이 성능만 좋은 것이 아니라 투명하고 공정하며 책임 있게 운영되는지 봐요. group disparity audit, explanation 검토, model card, dataset documentation, compliance 협업이 이 역할에 포함돼요.

Security and Privacy Engineer

Security and Privacy Engineer는 ML 시스템의 confidentiality, integrity, availability를 지켜요. 학습 데이터 접근 제어, encryption, anonymization, secure aggregation, differential privacy, model inversion과 membership inference 위험, API rate limiting, query attack monitoring을 다뤄요.

7.2 Intersections and Handoffs

MLOps에서 위험한 지점은 역할 사이의 handoff예요.

Data Engineer → Data Scientist
깨끗하고 문서화된 데이터와 feature 정의를 넘겨야 해요.

Data Scientist → ML Engineer
모델 artifact뿐 아니라 가정, metric, preprocessing 요구사항을 넘겨야 해요.

ML Engineer → DevOps Engineer
serving 방식, resource requirement, rollback 조건, monitoring 지표를 맞춰야 해요.

Project Manager ↔ 모든 역할
dependency, 일정, milestone, stakeholder expectation을 조율해야 해요.

handoff가 불명확하면 schema 변경, feature 의미 차이, latency 요구사항 누락, 배포 후 monitor 부재 같은 문제가 생겨요.

7.3 Evolving Roles and Specializations

조직이 작을 때는 한 사람이 여러 역할을 겸할 수 있어요. 하지만 규모가 커지면 ML platform team, MLOps engineer, full-stack ML engineer, applied ML specialist 같은 전문화가 생겨요.

중요한 점은 역할 경계가 고정되어 있지 않다는 거예요. 효과적인 MLOps는 각 역할이 자기 영역만 보는 것이 아니라, 서로의 artifact와 운영 제약을 이해하는 interdisciplinary fluency를 필요로 해요.

8. System Design and Maturity Framework

이 섹션은 “좋은 MLOps 시스템은 조직 성숙도와 함께 설계되어야 한다”는 내용을 다뤄요.

8.1 Operational Maturity

Operational maturity는 조직이 ML 시스템을 얼마나 반복 가능하고, 확장 가능하고, 관찰 가능하게 개발·배포·관리할 수 있는지를 뜻해요.

도구를 많이 샀다고 maturity가 높은 것은 아니에요. 중요한 것은 system integration과 coordination이에요.

8.2 Maturity Levels

원문은 maturity를 엄격한 단계라기보다 continuum으로 설명해요.

Ad hoc 단계
  - local 실험, 수동 배포, 추적 어려움

Structured 단계
  - version control, 자동 training, model registry, 제한적 monitoring

Integrated 단계
  - IaC, CI/CD, feature store, drift monitoring, governance, audit 통합

성숙도는 도구 목록보다 lifecycle 전체를 얼마나 일관되게 지원하는지로 판단해야 해요.

8.3 System Design Implications

성숙도가 높아지면 architecture도 바뀌어요.

낮은 성숙도에서는 monolithic script와 결합된 component가 많아요. 데이터 처리 logic이 모델 코드에 섞이고, configuration이 informal하게 관리돼요.

중간 성숙도에서는 feature engineering과 model logic이 분리되고, pipeline이 선언적으로 정의되며, API와 orchestration으로 경계를 만들어요.

높은 성숙도에서는 stateless service, contract-driven interface, environment isolation, observable execution이 중요해져요. system behavior는 정적 가정이 아니라 실시간 monitoring과 feedback으로 관리됩니다.

8.4 Design Patterns and Anti-Patterns

성숙한 조직은 clear ownership, cross-functional collaboration, interface discipline을 갖춰요. platform team이 shared infrastructure와 tooling을 제공하고, domain team이 business-specific model을 개발하는 구조가 한 패턴이에요. 또는 federated model로 MLOps engineer를 product team 안에 두되 중앙 architecture 기능을 유지할 수도 있어요.

반대로 anti-pattern도 있어요.

원문은 reliability pattern도 ML에 맞게 바뀌어야 한다고 설명해요. Circuit breaker는 단순 error rate뿐 아니라 prediction accuracy degradation도 고려해야 해요. Bulkhead pattern은 experimental model이 production resource를 고갈시키지 않도록 분리해야 해요. Byzantine-like failure는 모델이 명백히 죽는 것이 아니라 그럴듯하지만 틀린 출력을 내는 형태일 수 있어요.

8.5 Contextualizing MLOps

MLOps 원칙은 추상적인 이상형이 아니라 실제 환경 제약 속에서 적용돼요.

즉, 제약 때문에 성숙도가 낮아지는 것이 아니에요. 제약을 고려해 원칙을 재설계하는 것이 성숙한 MLOps예요.

8.6 Future Operational Considerations

원문은 ML이 연구 환경을 넘어 production infrastructure의 핵심이 되었다고 봐요. 초기 시스템은 process discipline과 modular abstraction이 중요하고, 성숙한 시스템은 automation, governance, resilience가 중요해요.

운영 성숙도는 model lifecycle의 끝이 아니라, production-grade responsible adaptive system을 만들기 위한 기반이에요.

8.7 Enterprise-Scale ML Systems

가장 높은 성숙도에서는 AI factory라는 형태가 나타나요. 이는 하나의 모델이 아니라 여러 모델과 다양한 inference pattern, 대규모 continuous operation을 다루는 AI 생산 인프라예요.

AI factory는 일반 data center의 확장이 아니라 AI workload에 특화된 운영 구조예요. post-training scaling, test-time scaling, heterogeneous workload, system-level observability, cascading failure tolerance가 중요해져요.

8.8 Investment and Return on Investment

원문은 MLOps가 비용이 큰 투자라는 점도 숨기지 않아요. enterprise-scale platform은 feature store, model registry, orchestration, monitoring system, 전문 인력이 필요하고 여러 해에 걸친 투자가 될 수 있어요.

하지만 성숙한 MLOps는 다음 return을 만들 수 있어요.

• 모델 배포 시간이 months에서 days/weeks로 줄어요.
• ad hoc 환경의 높은 production failure rate를 낮출 수 있어요.
• 수백 개 이상의 모델을 운영할 때 economies of scale이 생겨요.
• 자동 retraining과 표준화된 배포가 운영 부담을 줄여요.
• feature reuse가 중복 개발을 줄여요.
• 데이터 과학자는 운영 문제보다 모델 개선에 더 집중할 수 있어요.

원문은 투자 단계를 다음처럼 설명해요.

9. Case Studies

원문은 MLOps 원칙이 실제 도메인에서 어떻게 달라지는지 두 사례로 보여줘요.

9.1 Oura Ring Case Study

Oura Ring은 wearable device에서 sleep, activity, physiological recovery를 추정하는 예예요. Cloud 중심 시스템과 달리 많은 처리와 inference가 device 가까이에서 일어나므로 resource constraint가 강해요.

Context and Motivation

목표는 Oura Ring의 sleep stage classification 정확도를 clinical gold standard인 polysomnography와 더 가깝게 만드는 것이었어요. 초기 모델은 PSG label과 62% correlation을 보였고, 인간 전문가 간 82-83% correlation에 비해 낮았어요.

이 차이는 단순히 모델 architecture 문제가 아니라 data collection, preprocessing, evaluation workflow를 다시 설계해야 하는 MLOps 문제로 이어져요.

Data Acquisition and Preprocessing

Oura team은 3개 대륙의 106명 참여자, 440 nights, 3,400시간 이상의 time-synchronized recording을 수집했어요. wearable sensor data와 PSG annotation을 함께 맞춘 high-fidelity labeled dataset을 만든 거예요.

데이터 pipeline은 ingestion, cleaning, preprocessing, temporal alignment, validation을 자동화했어요. 이는 data dependency debt와 pipeline debt를 줄이는 역할을 해요.

Model Development and Evaluation

두 모델 구성이 검토돼요.

평가는 five-fold cross-validation과 PSG benchmark로 수행됐고, 개선된 모델은 79% correlation accuracy까지 올라갔어요. 원문은 이 개선이 architecture만의 결과가 아니라, 데이터 수집, 재현 가능한 training pipeline, hyperparameter와 feature configuration 관리의 결과라고 해석해요.

Deployment and Iteration

배포는 ring의 제한된 memory, compute, power를 고려해야 해요. 모델은 quantization과 pruning 같은 compression을 거치고, preprocessing routine과 함께 packaging되어 OTA update로 배포돼요.

여기서 핵심 MLOps 원칙은 다음이에요.

• resource-aware model packaging
• embedded hardware에 맞춘 optimization
• OTA update와 rollback
• post-deployment observability
• accuracy와 efficiency 사이의 runtime trade-off

Key Operational Insights

Oura 사례는 edge 환경에서 MLOps가 어떻게 바뀌는지 보여줘요. 대규모 PSG 기반 label, versioned pipeline, configuration management, role collaboration이 결합되어 wearable ML의 정확도와 운영 가능성을 높였어요.

9.2 ClinAIOps Case Study

ClinAIOps는 healthcare 환경에서 MLOps를 확장한 framework예요. 의료에서는 모델 성능뿐 아니라 clinician judgment, patient safety, regulatory compliance, ethical governance가 필수예요.

왜 일반 MLOps만으로 부족할까요?

원문은 clinical 환경의 차이를 다음처럼 정리해요.

Feedback Loops

ClinAIOps의 중심에는 세 feedback loop가 있어요.

Patient-AI loop
  환자 생체 데이터를 AI가 분석하고 맞춤 치료 제안을 만들어요.

Clinician-AI loop
  AI 제안을 임상의가 검토, 승인, 수정하고 기준을 정해요.

Patient-Clinician loop
  환자와 임상의가 데이터 추세를 함께 해석하고 치료 목표를 조정해요.

여기서 feedback loop는 일반 ML 시스템의 부채가 아니라, 안전하게 설계된 기능이에요. 중요한 차이는 human accountability를 유지한다는 점이에요.

Hypertension Case Example

고혈압 관리는 continuous therapeutic monitoring에 잘 맞는 예예요. wearable device의 PPG, ECG, accelerometer data와 medication adherence log, demographic attribute, electronic health record를 결합해 개인별 혈압 관리 모델을 만들 수 있어요.

AI는 blood pressure estimate, circadian rhythm, physical activity, medication adherence를 보고 dosing과 timing을 추천해요.

하지만 모든 결정을 자동화하지 않아요.

• 작은 용량 조정은 clinician-defined safety threshold 안에서 환자에게 직접 제안될 수 있어요.
• 큰 변경은 clinician review와 approval을 거쳐요.
• hypotension이나 hypertensive crisis 같은 위험 신호는 즉시 clinician intervention alert로 이어져요.

이 구조는 accountability, safety, human-in-the-loop governance를 구현해요.

MLOps vs ClinAIOps Comparison

ClinAIOps는 모델을 최종 의사결정자로 두지 않아요. 모델은 clinician, patient, care system 사이의 협력 구조 안에 들어갑니다.

원문에서 가장 중요한 비교는 다음이에요.

ClinAIOps는 운영 도전 과제를 부채가 아니라 설계 기회로 바꿔요. feedback loop를 숨기지 않고 architecture에 명시하며, AI responsibility와 human responsibility의 경계를 분명히 해요.

10. Fallacies and Pitfalls

원문은 MLOps에서 흔히 하는 오해를 정리해요.

10.1 Fallacy: MLOps는 DevOps를 ML에 적용하면 끝이다

틀린 생각이에요. DevOps는 deterministic software에 강하지만, ML은 probabilistic model, data dependency, model drift를 다뤄야 해요. 일반 CI/CD만으로는 data validation, model monitoring, retraining trigger를 충분히 다루기 어려워요.

10.2 Pitfall: 모델 배포를 한 번의 이벤트로 본다

모델 배포는 끝이 아니라 시작이에요. 배포 후 data drift, user behavior 변화, business requirement 변화가 계속 생겨요. 운영 지원이 없으면 모델은 점점 신뢰할 수 없게 돼요.

10.3 Fallacy: 자동 재학습이 모든 문제를 해결한다

자동화는 중요하지만 사람의 판단을 완전히 대체하지 못해요. 새 데이터에 bias가 들어 있으면 자동 재학습은 그 bias를 더 강화할 수 있어요. 규제, 드문 failure mode, business logic 변화는 human checkpoint가 필요해요.

10.4 Pitfall: 기술 인프라만 보고 조직 정렬을 놓친다

비싼 도구를 도입해도 역할, 책임, communication protocol이 없으면 효과가 작아요. MLOps는 문화와 프로세스까지 포함해요.

11. Summary

이 장의 결론은 MLOps가 production ML을 위한 통합 framework라는 점이에요. 데이터 pipeline 자동화, model versioning, infrastructure orchestration, continuous monitoring, governance가 함께 작동해야 edge 환경, 보안 요구, robustness 요구, domain-specific constraint를 처리할 수 있어요.

핵심을 압축하면 다음과 같아요.

복습 질문

1. 일반 소프트웨어의 실패와 ML 시스템의 silent failure는 어떻게 다른가요?
2. MLOps가 DevOps를 그대로 복사하는 것만으로는 부족한 이유는 무엇인가요?
3. Data drift와 concept drift를 각각 예를 들어 설명해볼 수 있나요?
4. Feature store가 training-serving skew를 줄이는 방식은 무엇인가요?
5. Model registry와 lineage tracking은 장애 분석과 rollback에 어떻게 도움이 되나요?
6. Correction cascade가 생기는 원인을 hidden dependency 관점에서 설명해보세요.
7. Canary deployment, shadow deployment, blue-green deployment의 차이는 무엇인가요?
8. Online serving, offline serving, near-online serving은 어떤 상황에 각각 적합한가요?
9. Edge AI deployment에서 cloud 중심 MLOps와 달라지는 제약은 무엇인가요?
10. 모델 monitoring과 infrastructure monitoring은 각각 어떤 지표를 봐야 하나요?
11. Governance가 accuracy threshold보다 더 넓은 기준을 요구하는 이유는 무엇인가요?
12. Data Engineer, Data Scientist, ML Engineer, DevOps Engineer의 handoff에서 어떤 정보가 전달되어야 하나요?
13. Operational maturity가 낮은 조직이 도구부터 도입하면 어떤 anti-pattern이 생길 수 있나요?
14. Oura Ring 사례에서 자동화된 데이터 pipeline과 configuration management가 왜 중요했나요?
15. ClinAIOps가 feedback loop를 기술 부채가 아니라 설계 요소로 다루는 이유는 무엇인가요?