실험 추적 (Experiment Tracking)
핵심 요약: 실험 기록 없이 ML은 과학이 아니라 요행이다. 모든 설정(코드, 데이터, 하이퍼파라미터)과 결과(메트릭, 모델)를 기록하라. “지난주 최고 모델의 설정이 뭐였지?”에 답할 수 없다면, 실험 추적이 부족한 것이다.
초보자를 위한 핵심 용어
섹션 제목: “초보자를 위한 핵심 용어”- 실험 추적(Experiment Tracking): ML 실험의 코드 버전, 하이퍼파라미터, 결과 메트릭, 모델 아티팩트를 체계적으로 기록하는 것.
- 재현성(Reproducibility): 동일한 코드와 데이터로 동일한 결과를 다시 만들어낼 수 있는 능력. 과학적 ML의 기본 요건.
- MLflow: 오픈소스 ML 생명주기 관리 플랫폼. 실험 기록, 모델 패키징, 버전 관리를 제공한다.
- 아티팩트(Artifact): 실험에서 생성된 산출물. 학습된 모델 가중치, 설정 파일, 예측 결과 등을 의미한다.
실험 추적(Experiment Tracking)은 ML 실험의 코드, 데이터, 하이퍼파라미터, 메트릭, 아티팩트를 체계적으로 기록하고 관리하는 것이다. “지난주에 좋았던 모델의 설정이 뭐였지?”라는 질문에 답할 수 없다면, 실험 추적이 부족한 것이다. 재현성(reproducibility), 비교 가능성, 그리고 팀 협업을 위해 필수적이다.
비유: 실험 추적은 과학자의 실험 노트와 같다. 실험 노트 없이 과학을 하면, 그건 과학이 아니라 요행이다. 어떤 조건에서 어떤 결과가 나왔는지 기록하지 않으면, 성공을 반복할 수도, 실패에서 배울 수도 없다.
탄생 배경
섹션 제목: “탄생 배경”실험 추적 도구가 탄생하기까지, 업계에서는 수많은 “잃어버린 모델(Lost Model)” 사건들이 있었다.
반복된 문제들:
- “최고 성능 모델 증발 사건” (2014~2016): 초기 ML 팀들은 주로 Jupyter Notebook과 수동 기록(스프레드시트, 위키)에 의존했다. 연구원이 퇴사하거나, 노트북 서버가 교체되면, 모델의 하이퍼파라미터, 전처리 로직, 학습 데이터 버전 등이 함께 사라졌다. 한 대형 전자상거래 회사에서는 프로덕션에서 잘 작동하던 추천 모델의 원본 학습 코드를 찾지 못해, 재학습이 불가능해진 사례가 보고되었다.
- Notebook Hell:
model_v2_final.ipynb,model_v2_final_real.ipynb,model_v2_final_real_FINAL.ipynb같은 파일명이 난립하면서, 어떤 노트북이 실제 프로덕션 모델을 만들었는지 아무도 알 수 없는 상황이 반복되었다. - 규제 준수 요구: 2016년 이후 EU의 GDPR과 금융 규제가 강화되면서, “이 모델이 왜 이런 결정을 내렸는가?”에 대한 감사 추적(Audit Trail)이 법적 의무가 되었다. 실험 기록 없이는 이 요구를 충족할 수 없었다.
이러한 문제들이 축적되면서, MLflow (2018, Databricks), Weights & Biases (2017), Neptune.ai (2017) 등의 실험 추적 전문 도구가 등장했다. 이들은 “ML 실험의 Git”이라는 비전으로, 모든 실험의 코드, 데이터, 하이퍼파라미터, 결과를 자동으로 기록하고 비교할 수 있는 환경을 제공했다.
핵심 개념
섹션 제목: “핵심 개념”1. 왜 실험을 추적해야 하는가
섹션 제목: “1. 왜 실험을 추적해야 하는가”| 목적 | 설명 |
|---|---|
| 재현성 | 어떤 코드/데이터/하이퍼파라미터로 어떤 결과를 얻었는지 기록 |
| 비교 | 여러 실험의 성능을 체계적으로 비교 |
| 감사 추적 | 모델 결정의 근거를 추적 (규제 환경에서 특히 중요) |
| 팀 협업 | 팀원 간 실험 결과와 인사이트 공유 |
| 회귀 방지 | 이전 최고 성능 대비 새 모델의 성능 검증 |
2. MLflow
섹션 제목: “2. MLflow”오픈소스 ML 생명주기 관리 플랫폼이다.
구성 요소:
| 컴포넌트 | 역할 |
|---|---|
| Tracking | 파라미터, 메트릭, 아티팩트 기록 |
| Projects | 재현 가능한 실행 환경 정의 |
| Models | 모델 패키징 포맷 |
| Registry | 모델 버전 관리, staging/production 단계 |
3. Weights & Biases (W&B)
섹션 제목: “3. Weights & Biases (W&B)”클라우드 기반 실험 추적 플랫폼이다.
주요 기능:
- 실시간 학습 시각화 (loss, accuracy 곡선)
- Sweep: 하이퍼파라미터 자동 탐색
- Artifacts: 데이터셋과 모델의 버전 관리 및 계보(lineage) 추적
- Reports: 실험 결과를 팀과 공유하는 인터랙티브 문서
4. 재현성 체크리스트 (Reproducibility Checklist)
섹션 제목: “4. 재현성 체크리스트 (Reproducibility Checklist)”
기록해야 할 항목:
| 범주 | 항목 |
|---|---|
| 코드 | git commit hash, branch |
| 데이터 | 데이터셋 버전, 해시, 분할 방법 |
| 환경 | Python 버전, 패키지 버전, OS, GPU |
| 하이퍼파라미터 | 학습률, 배치 크기, 에폭, 모델 구조 |
| 메트릭 | loss, accuracy, F1, 사용자 정의 지표 |
| 아티팩트 | 모델 가중치, 설정 파일, 예측 결과 |
| 시드 | 모든 랜덤 시드 값 |
상세 내용
섹션 제목: “상세 내용”실험 추적 워크플로우
섹션 제목: “실험 추적 워크플로우”메트릭 비교와 통계적 유의성
섹션 제목: “메트릭 비교와 통계적 유의성”실험 간 성능 비교 시, 상대적 개선율(Relative Improvement)을 계산한다:
- : 새 모델의 메트릭 값
- : 기준 모델의 메트릭 값
단순 차이만으로는 개선이 의미 있는지 판단할 수 없다. 통계적 유의성 검정이 필요하다. K-Fold 교차 검증에서 두 모델 와 의 성능 차이에 대해 Paired t-test를 수행한다:
- : 각 fold에서 모델 , 의 오차
- : 평균 성능 차이
- : fold 수
이면 두 모델의 성능 차이가 통계적으로 유의하다고 판단한다. 단, fold 간 상관관계로 인해 paired t-test는 Type I 오류를 과소추정할 수 있으므로, corrected resampled t-test 또는 5x2 CV paired t-test를 사용하는 것이 더 엄밀하다.
실용 팁
섹션 제목: “실용 팁”-
자동화: 실험 기록을 수동으로 관리하면 누락이 발생한다. MLflow나 W&B를 코드에 통합하여 자동으로 기록하라.
-
명명 규칙: 실험에 의미 있는 이름을 부여하라 (예:
resnet50_lr001_aug_v2). -
태깅: 실험에 태그를 붙여 필터링과 검색을 용이하게 하라 (예:
baseline,final,ablation). -
비교 대시보드: 메트릭을 시각화하여 병렬 비교할 수 있는 환경을 구축하라.
언제 사용하는가
섹션 제목: “언제 사용하는가”| 상황 | 추적 수준 |
|---|---|
| 개인 연구/실험 | 최소한 git + 간단한 로깅 |
| 팀 프로젝트 | MLflow 또는 W&B |
| 프로덕션 ML | MLflow + Model Registry + CI/CD |
| 규제 환경 (금융, 의료) | 엄격한 감사 추적 필수 |
실전 사례
섹션 제목: “실전 사례”6개월간 달성한 F1 94% 모델을 재현하지 못한 연구팀
섹션 제목: “6개월간 달성한 F1 94% 모델을 재현하지 못한 연구팀”한 의료 AI 스타트업의 연구팀이 겪은 실화이다.
상황: 병리학 이미지에서 암세포를 탐지하는 모델을 개발하던 연구팀이 6개월간의 실험 끝에 F1 0.94라는 인상적인 성능을 달성했다. 이 결과를 논문으로 발표하고, 규제 기관에 의료 기기 인증을 신청할 계획이었다.
문제 발생:
| 시점 | 사건 |
|---|---|
| 6개월차 | F1 0.94 달성, 팀 전체가 축하 |
| 7개월차 | 논문 작성을 위해 실험 재현 시도 |
| 7개월차 +1주 | 동일한 코드로 F1 0.87만 달성 |
| 7개월차 +2주 | 데이터 전처리 파이프라인 차이 발견, 수정 후 F1 0.89 |
| 8개월차 | 원래 실험의 정확한 하이퍼파라미터를 아무도 기억하지 못함 |
| 9개월차 | 원래 실험에 사용된 데이터 버전을 특정할 수 없음 발견 |
| 10개월차 | 결국 F1 0.94 재현 포기, 처음부터 다시 실험 시작 |
근본 원인:
- 실험 기록을 개인 노트북과 슬랙 메시지에 의존
- 데이터 전처리에 사용한 라이브러리 버전이 중간에 업데이트됨
- 데이터 증강(Augmentation) 파라미터를 코드에 하드코딩했으나, 여러 번의 실험 중 어떤 값이 최종 결과를 만들었는지 기록하지 않음
- GPU 연산의 비결정적 특성(Non-deterministic)을 고려하지 않아 시드 고정이 불완전
결과: 4개월의 추가 시간과 약 $200K의 비용이 낭비되었다. 이후 팀은 MLflow를 도입하고, 모든 실험의 코드 커밋 해시, 데이터 버전, 환경 정보, 하이퍼파라미터를 자동으로 기록하는 파이프라인을 구축했다.
흔한 오해와 함정
섹션 제목: “흔한 오해와 함정”-
코드만 버전 관리하고 데이터/환경은 무시: 동일 코드라도 다른 데이터나 패키지 버전에서 다른 결과를 낸다. DVC 등으로 데이터도 버전 관리하라.
-
“나중에 기록하면 돼”: 실험 직후가 아니면 세부 사항을 잊는다. 코드에 추적 로직을 미리 포함시켜라.
-
랜덤 시드 하나만 고정: Python 내장 random, NumPy, PyTorch, CUDA 등 모든 랜덤 소스의 시드를 고정해야 한다. GPU 연산의 비결정적 특성(non-deterministic)도 고려해야 한다.
-
하이퍼파라미터만 기록: 전처리 방법, 데이터 분할 방식, 증강 설정 등도 결과에 영향을 미친다. 모든 결정을 기록하라.
-
실험 추적을 오버엔지니어링: 초기에는 간단한 CSV나 JSON 로깅으로 시작해도 충분하다. 필요에 따라 도구를 도입하라.
다른 주제와의 연결
섹션 제목: “다른 주제와의 연결”- ML 파이프라인 설계: 파이프라인의 기록과 관리
- 모델 배포: Model Registry로 배포 관리
- MLOps 기초: CI/CD와 실험 추적의 통합
- ML 시스템 설계 패턴: 프로덕션 실험 관리
- 흔한 실수: 재현 불가능한 실험