ML 프로젝트 수명 주기: 문제 정의 · 데이터 · 실험 관리 · 재현성 · 배포 준비

ML 프로젝트 수명 주기: 문제 정의 · 데이터 · 실험 관리 · 재현성 · 배포 준비

노트북에서 정확도 95%가 나온 모델과, 매일 실제 사용자에게 예측을 내는 시스템 사이에는 큰 간격이 있습니다. 구글의 머신러닝 단기 과정은 실제 시스템에서 모델 코드가 전체 코드의 5% 이하인 경우가 많다고 설명합니다. 이 수업은 나머지 95%의 첫 절반 — 문제 정의, 데이터 버전 · 라벨 · 누수, 실험 기록, 재현성, 배포 전 점검 — 을 MLOps(머신러닝 운영)의 관점으로 정리하고, 누수가 점수를 얼마나 부풀리는지 직접 돌려 봅니다.

들어가기 전에

• 구글 머신러닝 단기 집중 과정 — 학습 · 검증 · 손실의 기본
• 모델 평가와 과적합: 데이터 나누기 · 혼동 행렬 · 정규화 — 학습 · 검증 · 시험 데이터 나누기. 누수는 이 나누기가 깨지는 문제입니다.
• AI 규제 · 저작권 · 책임 있는 AI 개요 — 문서화 · 기록이 왜 필요한지의 바깥 이유

한눈에 보기

• ML 프로젝트를 "문제 정의 → 데이터 → 실험 → 평가 → 배포 → 모니터링 → 다시 데이터"의 고리로 봅니다.
• 데이터 누수의 세 유형을 구분하고, 누수가 무작위 데이터에서도 정확도를 0.5에서 0.8대로 부풀리는 것을 확인합니다.
• 실험마다 무엇을 기록해야 나중에 같은 결과를 다시 낼 수 있는지 압니다.
• ML 시스템에만 있는 기술 부채의 종류를 압니다.
• ML Test Score로 배포 준비 상태를 점수로 매깁니다.

1. 수명 주기 전체 그림

직관(해설용 비유). 식당 메뉴 개발에 비유하면, 레시피(모델)를 만드는 일은 일부일 뿐이고 재료 조달(데이터 수집) · 재료 검수(검증) · 레시피 기록(실험 관리) · 시식(평가) · 주방 배치(배포) · 손님 반응 관찰(모니터링)이 더 많은 일을 차지합니다. 그리고 손님 반응이 다음 재료 선택으로 돌아옵니다.

12345678910flowchart LR
  A[문제 정의<br/>지표 · 기준선] --> B[데이터 수집 · 라벨링]
  B --> C[데이터 검증 · 버전 고정]
  C --> D[실험<br/>학습 · 기록]
  D --> E[오프라인 평가<br/>집단별 · 시간별]
  E --> F{배포 준비 점검<br/>ML Test Score}
  F -->|통과| G[배포]
  F -->|부족| D
  G --> H[모니터링<br/>드리프트 · 품질]
  H -->|새 데이터 · 문제 발견| B

구글 MLCC의 Production ML 모듈도 같은 관점에서 학습 방식(정적 · 동적), 추론 방식(정적 · 동적), 데이터 변환 시점, 배포 테스트, 모니터링 파이프라인을 차례로 다룹니다.

2. 문제 정의: 지표와 기준선부터

단계.

1. 결정 을 적습니다. "이 예측으로 누가 무엇을 바꾸나?" (예: 상담원이 이탈 위험 고객에게 먼저 전화)
2. 지표 를 정합니다. 사업 지표(이탈률 감소)와 모델 지표(재현율@상위 10%)를 짝지어 둡니다.
3. 기준선 을 만듭니다. 규칙 하나("최근 30일 미접속이면 위험")나 가장 단순한 모델의 점수입니다.

왜 기준선이 먼저인가. 기준선이 없으면 "정확도 92%"가 좋은지 나쁜지 알 수 없습니다. 고객의 92%가 이탈하지 않는 데이터라면 "모두 이탈 안 함"이라고만 답해도 92%입니다.

3. 데이터: 버전 · 라벨 · 누수

버전 관리. 코드는 Git으로 버전을 남기지만 수 GB의 데이터는 Git에 넣기 어렵습니다. DVC 같은 도구는 Git과 함께 쓰는 확장으로, 큰 데이터는 원격 저장소에 두고 Git에는 그 데이터를 가리키는 작은 메타 파일(.dvc)을 남깁니다. 요점은 도구가 아니라 "이 모델은 정확히 어떤 데이터 스냅숏으로 학습했나"를 언제든 답할 수 있게 하는 것입니다.

라벨 품질. 라벨러 간 일치도를 재고, 애매한 예를 위한 지침을 문서로 남깁니다. 라벨 기준이 바뀌면 데이터 버전도 바꿉니다.

데이터 누수(leakage). scikit-learn 문서의 정의는 "예측 시점에는 쓸 수 없는 정보가 모델을 만드는 데 쓰이는 것"입니다. 성능 추정이 부풀려지고, 실제 새 데이터에서는 성능이 떨어집니다.

숫자로 해 보기(해설용, 파이썬으로 직접 실행). scikit-learn 문서가 보여 주는 실험을 넘파이로 다시 해 봅니다. 표본 200개, 정답과 아무 관계 없는 무작위 특징 10,000개, 무작위 0/1 라벨입니다. 정답과 관계가 없으니 어떤 모델이든 정확도는 0.5 근처여야 정상입니다.

• 잘못된 순서: 전체 200개로 라벨과 가장 관련 있어 보이는 특징 25개를 고른 뒤 150 / 50으로 나눠 학습 · 시험 → 정확도 평균 약 0.83(20번 반복)
• 올바른 순서: 먼저 나누고, 학습용 150개로만 특징 25개를 고름 → 정확도 평균 약 0.48

특징 선택이 시험 데이터의 라벨을 '엿본' 것만으로 존재하지 않는 패턴이 생겼습니다(문서의 scikit-learn 예에서는 0.76 대 약 0.5). 해결책은 문서 권고대로 나누기를 가장 먼저 하고, 전처리를 Pipeline 으로 묶어 학습 데이터로만 fit 하는 것입니다.

학습/서빙 불일치(training-serving skew). 같은 특징을 학습 때는 로그 처리 코드로, 서비스 때는 실시간 코드로 따로 계산하면 값이 달라질 수 있습니다. ML Test Score 논문은 이를 감시 항목으로 두고, 서비스 입력 일부를 기록해 학습 때 값과 직접 비교하라고 권합니다.

4. 실험 관리: 무엇을 기록하나

직관. 실험 노트 없이 실험하는 과학자는 없습니다. 수십 번 학습을 돌리다 보면 "지난주 최고 점수는 어떤 설정이었지?"를 아무도 답하지 못하게 됩니다.

MLflow Tracking 문서가 정리한 기본 단위는 다음과 같습니다.

mlflow.autolog() 를 학습 코드 앞에 부르면 scikit-learn · XGBoost · PyTorch 등에서 지표 · 파라미터 · 모델을 자동으로 기록합니다. 도구는 무엇이든 괜찮습니다. 핵심은 모든 실행이 기록되고 비교 가능 해지는 것입니다.

5. 재현성: 같은 입력이면 같은 결과

같은 결과를 다시 내려면 네 가지가 고정되어야 합니다(해설용 정리).

시드 다루기. scikit-learn 문서는 random_state 에 정수를 주면 매번 같은 결과가 나오고, None(기본값)이면 매번 달라진다고 설명합니다. 재현하려면 None 을 피하고, 프로그램 맨 위에서 난수 생성기를 하나 만들어 넘기라고 권합니다. 또 교차 검증 분할기에는 정수를 주어 폴드끼리 비교가 가능하게 하라고 권합니다.

주의. GPU의 일부 연산은 실행 순서에 따라 소수점 아래가 조금씩 달라질 수 있어 시드만으로 완전히 같아지지 않을 수 있습니다. 그래서 "한 번의 점수"가 아니라 여러 시드의 평균 · 편차 로 비교하는 습관이 중요합니다. 위 누수 실험도 20번 반복해 평균을 냈습니다.

6. ML 시스템의 기술 부채

Sculley 외(NIPS 2015)는 ML 시스템에서 빨리 만들수록 나중에 비싸게 갚게 되는 '숨은 기술 부채'를 정리했습니다. 논문이 꼽은 ML 고유 위험은 다음과 같습니다.

7. 배포 준비 점검: ML Test Score

Breck 외(IEEE Big Data 2017)는 구글 실무 경험에서 뽑은 28개 시험 · 감시 항목 을 네 영역 — ① 특징과 데이터 ② 모델 개발 ③ ML 인프라 ④ 모니터링 — 에 7개씩 나눴습니다. 예를 들어 데이터 영역의 첫 항목은 "특징에 대한 기대가 스키마로 정리되어 있다", 모니터링 영역에는 "학습과 서빙이 같은 값을 계산한다", "모델이 너무 오래되지 않았다" 같은 항목이 있습니다.

점수 매기는 법(논문 기준).

1. 항목마다 수동으로 실행 · 문서화했으면 0.5점, 자동으로 반복 실행되는 체계가 있으면 1점.
2. 네 영역별로 합산합니다.
3. 최종 점수는 네 영역 점수 중 최솟값 입니다.

숫자로 해 보기(해설용). 데이터 4.5 · 모델 5.0 · 인프라 3.0 · 모니터링 1.5점이면 최종 점수는 1.5입니다. 모델 쪽을 아무리 다듬어도 모니터링을 올리지 않으면 점수가 오르지 않습니다. 논문은 네 영역이 모두 중요하다는 뜻에서 최솟값을 택했다고 설명합니다.

연습 문제

1. 이탈 고객 비율이 8%인 데이터에서 "모두 이탈 안 함" 기준선의 정확도는?
   • 풀이: 92%입니다. 정확도만으로 모델을 평가하면 안 되는 이유입니다.
2. 다음 중 누수가 있는 것은? (가) 학습 데이터 평균으로 시험 데이터를 정규화 (나) 전체 데이터 평균으로 정규화한 뒤 나누기 (다) 2025년 데이터로 학습하고 2026년 데이터로 시험
   • 풀이: (나)입니다. (가)는 올바른 방법, (다)는 시간 순서를 지킨 올바른 분할입니다.
3. ML Test Score 영역 점수가 6 · 2.5 · 4 · 3.5면 최종 점수는?
   • 풀이: 최솟값 2.5입니다(모델 개발 영역).
4. 재현성을 위해 실행마다 남겨야 할 네 가지는?
   • 풀이: 코드 버전(커밋), 데이터 버전, 설정 · 시드, 실행 환경(라이브러리 버전 · 컨테이너)입니다.

스스로 점검

1. 무작위 특징에서도 정확도가 0.8대가 나온 이유는?
   • 답: 시험 데이터의 라벨까지 보고 특징을 골라, 우연히 시험 라벨과 맞아떨어진 특징들이 선택되었기 때문입니다. 나누기 전에 전처리를 하면 시험 데이터 정보가 학습에 새어 들어갑니다.
2. '숨은 피드백 고리'의 예를 들어 보세요.
   • 답: 추천 모델이 보여 준 상품만 클릭되고, 그 클릭 기록으로 다시 학습하면 모델이 자기 선택을 강화해 다른 좋은 상품을 영영 배우지 못하는 경우입니다.
3. ML Test Score가 합계가 아니라 최솟값을 쓰는 이유는?
   • 답: 한 영역이라도 비어 있으면 시스템 전체가 위험하므로, 가장 약한 영역을 올려야만 점수가 오르게 하려는 것입니다.

용어 정리

더 깊이 보려면

• Google MLCC Production ML systems: developers.google.com/machine-learning/cr…
• Sculley 외, Hidden Technical Debt in Machine Learning Systems: papers.nips.cc/paper/5656-hidden-technica…
• scikit-learn Common pitfalls and recommended practices: scikit-learn.org/stable/common_pitfalls.h…
• MLflow Tracking: mlflow.org/docs/latest/ml/tracking

다음에 볼 것

• 배포 · 서빙 · 모니터링: 지연 시간 · 카나리 · 드리프트 — 배포한 다음에 할 일
• XGBoost: 확장 가능한 트리 부스팅 — 실무 표 데이터에서 가장 흔한 기준 모델
• 파일럿에서 확산까지: 파일럿 설계 · 성공 기준 · 확산과 운영 — ML 프로젝트를 조직 파일럿 · 확산으로 잇기(AX)

라이선스

본문은 KAITABASE 자체 해설입니다. 참고 자료 Google MLCC는 CC BY 4.0(코드 예는 Apache 2.0)입니다. 누수 실험은 scikit-learn 문서의 예를 넘파이로 다시 구현해 직접 실행한 결과(20회 평균)이며, 기준선 · 점수 숫자는 해설용 예입니다.

출처

• Google, Machine Learning Crash Course — Production ML systems: developers.google.com/machine-learning/cr…
• Sculley 외 (2015), Hidden Technical Debt in Machine Learning Systems, NIPS 2015: papers.nips.cc/paper/5656-hidden-technica…
• Breck 외 (2017), The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction, IEEE Big Data 2017: research.google/pubs/the-ml-test-score-a-…
• scikit-learn, Common pitfalls and recommended practices: scikit-learn.org/stable/common_pitfalls.h…
• MLflow Tracking 문서: mlflow.org/docs/latest/ml/tracking
• DVC 문서: doc.dvc.org