2What — 배포와 운영은 완전히 다른 역량이다
3- ML 모델을 학습하고 배포하는 것은 전체 생명주기의 시작일 뿐이다
4- 실제 ML 시스템에서 모델 코드가 차지하는 비중은 전체의 약 5%에 불과하다 (Sculley et al., 2015)
5- 나머지 95%는 데이터 검증, 모니터링, 피처 추출, 설정 관리, 인프라 등 운영 인프라가 차지한다
6Why — 배포 후에 진짜 문제가 시작된다
7- 성능 저하: 실제 데이터 분포는 시간이 지나면 학습 데이터와 달라진다 (데이터 드리프트)
8- 장애 전파: ML 모델 하나의 오류가 하류 서비스 전체에 연쇄 장애를 일으킨다
9- 운영 비용 폭발: GPU 추론 비용, 재학습 비용, 스토리지 비용이 배포 후 급증한다
10- 규제 대응: GDPR, AI Act 등 모델 설명 가능성·공정성 감사를 지속적으로 충족해야 한다
11- 비유: 집을 짓는 것(배포)과 집에 사는 것(운영)은 완전히 다른 역량이다. 짓는 데 1년이 걸려도, 유지보수는 수십 년 계속된다
12Hidden Technical Debt — ML 시스템의 숨은 부채
13- Google의 연구에 따르면 ML 시스템은 전통 소프트웨어의 기술 부채에 ML 특유의 부채가 추가된다 (Sculley et al., 2015)
14- ML 특유 부채 목록:
15 - 데이터 의존성: 외부 데이터 소스 변경 시 모델 성능이 무경고로 저하
16 - 피드백 루프: 모델 출력이 미래 입력에 영향 → 자기강화 편향
17 - 설정 부채: 하이퍼파라미터·피처 목록·전처리 로직이 코드 외부에 산재
18 - 재현성 부채: "지난달 모델"을 정확히 재현할 수 없는 상태
19실제 사례 — Uber Michelangelo
20- Uber는 Michelangelo 플랫폼으로 수백 개 ML 모델을 동시에 운영한다 (Hermann & Del Balso, 2017)
21- 경험한 운영 복잡도:
22 - 모델 수가 50개를 넘자 버전 관리만으로 전담 팀이 필요해짐
23 - 피처 파이프라인 하나의 장애가 수십 개 모델에 동시 영향
24 - 배포 당일 정상이던 모델이 2주 후 예측 정확도 15% 하락 — 원인 추적에 수일 소요
25- 교훈: 모델 수가 늘수록 운영 복잡도는 선형이 아닌 조합적으로 폭발한다
26이 레슨에서 다루는 운영 역량 6가지
27- 1) Shadow Mode 배포 — 실제 트래픽에 영향 없이 신규 모델을 검증하는 전략
28- 2) 롤백 전략 — 장애 발생 시 이전 안정 버전으로 즉시 복구하는 메커니즘
29- 3) 인시던트 관리 — ML 장애의 감지·대응·사후분석(postmortem) 프로세스
30- 4) 비용 모니터링 — 추론/학습/저장 비용을 추적하고 최적화하는 체계
31- 5) 거버넌스 — 모델 감사 추적, 규제 준수, 접근 제어 정책
32- 6) MLOps 성숙도 — 수동 운영에서 완전 자동화까지의 단계별 로드맵
33핵심 수치로 보는 현실
34- ML 프로젝트의 약 87%가 프로덕션에 도달하지 못한다 (VentureBeat, 2019)
35- 프로덕션에 도달한 모델 중에서도 지속적으로 운영되는 비율은 절반 이하
36- 원인의 대부분은 모델 성능이 아니라 운영 역량 부족이다