Post

ML Systems Tracking & Versioning

Posted Updated
By Hoon
16 min read
ML Systems Tracking & Versioning

모델 개발 과정에서는 수많은 아키텍처와 하이퍼파라미터 조합을 실험하게 됩니다. 겉보기에는 학습률을 0.003에서 0.002로 바꾸는 정도의 작은 차이처럼 보여도, 실제 성능은 크게 달라질 수 있습니다. 각 실험을 재현할 수 있을 만큼의 정보와 산출물(artifact)을 체계적으로 남기는 일이 중요합니다.
학습 과정의 상태를 관찰하고 비교하는 experiment tracking, 재현과 비교를 위해 실험의 구성요소를 기록하는 versioning, ML 디버깅이 왜 어렵고 어떤 접근이 유효한지, 대규모 학습을 위한 분산 학습 개념, AutoML과 하이퍼파라미터 튜닝, 오프라인 평가의 베이스라인 및 방법론 흐름을 정리합니다.

핵심 개념: tracking vs versioning

Artifact(아티팩트)란 무엇입니까?

  • 실험 중 생성되는 파일/결과물을 의미합니다.
  • 예: loss curve, eval loss graph, 학습 로그, 중간 체크포인트, 중간 예측 결과, 분석 리포트 등입니다.
  • 아티팩트가 잘 관리되면 실험 간 비교, 디버깅, 재현성 확보가 쉬워집니다.

Experiment tracking(실험 추적) 정의

  • 학습 과정에서 무엇이 일어나는지 지속적으로 관찰하고 기록하는 과정입니다.
  • 목적은 다음과 같습니다.
    • 학습 이상 징후(손실 미감소, 과적합/과소적합, 불안정한 가중치, dead neuron, OOM 등) 탐지
    • 모델이 유의미한 것을 배우고 있는지 판단
    • 변경점이 성능에 미치는 영향 비교

Versioning(버저닝) 정의

  • 나중에 재현하거나 다른 실험과 정확히 비교하기 위해 실험의 모든 구성을 기록하는 과정입니다.
  • tracking은 학습 중 관찰, versioning은 실험 구성(코드/데이터/환경)의 기록에 무게가 실립니다.
  • 두 과정은 함께 가야 재현 가능성이 높아집니다.

Experiment tracking: 무엇을 추적해야 합니까?

학습은 “모델을 babysitting 하는 과정”이라는 표현이 나올 정도로 변수와 문제가 많습니다. 따라서 추적의 목표는 문제 탐지, 원인 추정, 실험 비교입니다.

최소로도 반드시 권장되는 추적 항목

  • loss curve
    • train split
    • 각 eval split(검증/개발 등, 단 test는 튜닝에 사용하지 않는다는 원칙 유지)
  • 핵심 성능 지표
    • accuracy / F1 / perplexity 등 문제에 맞는 지표를 test가 아닌 split에서 기록합니다.
  • 샘플 단위 로그
    • 입력 샘플, 예측, 정답 라벨(가능하면 함께) 로그를 남깁니다.
    • 사후 분석(ad hoc analytics)과 sanity check에 유용합니다.

성능/자원 관점에서 중요한 추적 항목

  • 학습 속도
    • steps/sec 또는 텍스트라면 tokens/sec
  • 시스템 지표
    • 메모리 사용량, CPU/GPU utilization
    • 병목 탐지 및 자원 낭비 방지에 필요합니다.
  • 학습에 영향을 주는 파라미터/하이퍼파라미터의 시간 변화
    • learning rate(스케줄 사용 시 특히 중요)
    • gradient norm(전역/레이어별), 특히 gradient clipping 시
    • weight norm, 특히 weight decay 사용 시

“다 추적하면 좋다” vs “너무 많으면 방해된다”의 균형

  • 이론적으로는 가능한 것을 다 추적하는 것이 나쁘지 않습니다.
  • 그러나 실제로는 도구/대시보드 제약 때문에 너무 많은 지표가 오히려 핵심 신호를 가릴 수 있습니다.
  • 결론적으로, 추적은 모델의 상태에 대한 observability(가시성)를 제공하지만,
    • 중요하지 않은 것까지 과도하게 추적하면 운영 부담이 커지고
    • 정말 중요한 것을 놓치게 되는 역효과가 날 수 있습니다.

간단한 구현 방식과 전문 도구의 가치

  • 간단한 방식: 실험에 필요한 코드 파일을 자동 복사하고, 모든 출력(log/그래프/결과)을 타임스탬프와 함께 저장합니다.
  • 전문 도구(예: MLflow, Weights & Biases 등)를 쓰면
    • 보기 좋은 대시보드
    • 팀 공유 및 비교
    • 일부 버저닝 기능 통합 등 장점이 있습니다.
  • 또한 DVC 같은 버저닝 도구도 experiment tracking 기능을 통합하는 추세입니다.

Versioning: 왜 필요한가, 무엇이 어려운가?

“좋았던 실험이 재현되지 않는” 전형적 시나리오

  • 특정 run이 유독 잘 나왔습니다.
  • 기록해둔 하이퍼파라미터로 다시 돌렸는데 결과가 미묘하게 다릅니다.
  • 알고 보니 그 run 이후 코드가 약간 바뀌었고, 당시에는 “사소한 변경”이라 커밋을 안 했습니다.
  • 기억을 더듬어 되돌려도 완전 재현이 안 됩니다.
  • 이런 문제는 실험 버저닝이 제대로 되어 있었다면 상당 부분 예방됩니다.

ML은 코드 + 데이터입니다

  • 코드 버저닝은 산업 표준에 가깝게 자리 잡았습니다.
  • 그러나 데이터 버저닝은 “치실(fl ossing)” 비유처럼, 필요성은 모두 인정하지만 실제로는 덜 합니다.

데이터 버저닝이 어려운 이유

  • 데이터는 코드보다 훨씬 큽니다.
    • 코드처럼 diff(라인 단위 비교)를 적용하기 어렵습니다.
    • 데이터 한 “라인”이 수백만 문자일 수도 있고, 바이너리 포맷은 더 애매합니다.
    • 과거 버전을 파일 단위로 계속 복제해 저장하는 것도 비용상 불가능할 수 있습니다.
    • 데이터는 로컬 머신에 복제해서 협업하기도 어렵습니다.
  • 무엇이 데이터의 diff인가에 대한 합의가 부족합니다.
    • 파일 내용 변경? 파일 추가/삭제? 디렉터리 체크섬 변경?
    • (책 기준) 2021년 당시 DVC는 디렉터리 체크섬 변경 + 파일 추가/삭제 수준에서 diff를 등록하는 방식이 언급됩니다.
    • merge conflict 해결도 애매합니다.
  • 규제(GDPR 등)로 인해 과거 데이터 복원이 법적으로 불가능할 수 있습니다.
    • 예: 사용자가 삭제 요청하면 데이터를 삭제해야 하므로, 예전 버전을 복원하는 것이 불법이 될 수 있습니다.

“버저닝을 잘해도 재현성이 100% 보장되지는 않습니다”

  • 프레임워크/하드웨어가 만드는 비결정성(nondeterminism) 때문에 결과가 달라질 수 있습니다.
  • 예: CUDA 원자 연산의 실행 순서 차이로 인한 부동소수점 반올림 오차 등이 대표 예시로 언급됩니다.
  • 따라서 재현성은 코드/데이터/환경 기록, 시드 고정 및 실험 프로토콜, 하드웨어/라이브러리 버전까지의 관리 등을 함께 고려해야 합니다.

Debugging ML models: 왜 더 어렵고, 무엇이 원인일 수 있습니까?

ML 디버깅이 특히 어려운 이유

  • 조용히 실패합니다.
    • 코드가 돌아가고 loss가 줄어도, 예측은 틀릴 수 있습니다.
  • 버그 수정 검증이 느립니다.
    • 재학습/수렴을 기다려야 해서 시간이 오래 걸립니다.
  • 교차 기능적 복잡성(cross-functional complexity)이 큽니다.
    • 데이터, 라벨, 피처, 알고리즘, 코드, 인프라 등 원인이 다양합니다.

실패 원인 분류

  • 이론적 제약
  • 모델 구현 버그
  • 하이퍼파라미터 선택 실패
  • 데이터 문제
  • 피처 선택 문제

실전 디버깅 테크닉

  • 단순하게 시작하고 점진적으로 복잡도를 올립니다.
  • 단일 배치를 과적합(overfit) 시켜봅니다.
  • 랜덤 시드를 고정합니다.

Distributed training: 규모가 커질수록 생기는 문제들

Out-of-core와 메모리 제약

  • 데이터가 메모리에 안 들어가면 전처리/셔플/배칭이 out-of-core 및 병렬 처리가 필요합니다.
  • 샘플이 큰 경우 배치 크기를 줄여야 하며, 이는 최적화 불안정으로 이어질 수 있습니다.
  • gradient checkpointing은 메모리-연산 트레이드오프로 더 큰 모델/더 큰 배치를 가능하게 합니다.

Data parallelism: 동기/비동기 SGD

  • 동기 SGD는 straggler 때문에 느려질 수 있습니다.
  • 비동기 SGD는 gradient staleness 문제가 생길 수 있습니다.
  • 워커 수 증가로 배치가 커지면 학습률 스케일링이 필요하지만 너무 크면 불안정하며, 일정 규모 이후 효용이 줄어듭니다.

Model parallelism & pipeline parallelism

  • model parallelism은 모델 구성요소를 여러 머신에 나눠 학습합니다.
  • pipeline parallelism은 마이크로배치로 쪼개 파이프라인처럼 흘려보내 병렬도를 높입니다.
  • 실제로는 data parallelism과 함께 쓰기도 하지만 엔지니어링 부담이 큽니다.

AutoML: soft vs hard

Soft AutoML = 하이퍼파라미터 튜닝

  • random search, grid search, Bayesian optimization 등이 활용됩니다.
  • 중요한 원칙은 테스트 셋으로 하이퍼파라미터 튜닝을 하면 안 된다는 점입니다.

Hard AutoML = NAS & learned optimizer

  • NAS는 search space, 성능 추정, search strategy로 구성됩니다.
  • learned optimizer는 업데이트 규칙을 신경망으로 학습하려는 방향입니다.
  • upfront cost가 매우 커서 일부 조직만 가능하다는 점이 강조됩니다.

오프라인 평가: 베이스라인과 운영 관점이 필요합니다

지표만 보면 오해합니다

  • 지표는 베이스라인 대비로 해석해야 합니다.
  • 클래스 불균형에서는 단순한 예측도 높은 지표를 만들 수 있습니다.

베이스라인 종류

  • random baseline
  • simple heuristic
  • zero rule baseline
  • human baseline
  • existing solutions

생산 환경에서 중요한 평가 관점

  • perturbation tests
  • invariance tests
  • directional expectation tests
  • model calibration
  • confidence measurement
  • slice-based evaluation

맺음말

모델을 더 잘 만들기 위해서는 더 많이 실험하는 것만큼이나, 실험을 기록하고 비교하고 재현할 수 있는 체계가 중요하다는 점입니다. Experiment tracking은 학습 과정의 문제를 조기에 발견하고, 작은 변경이 성능에 미치는 영향을 이해하게 해주는 관찰 장치입니다. Versioning은 재현 실패를 예방하고 팀 단위 협업에서 실험의 신뢰도를 높입니다. 또한 ML 디버깅은 조용한 실패, 느린 검증, 복잡한 원인 구조 때문에 어렵지만, 단순 모델부터 단계적으로 확장하고 작은 데이터 과적합과 시드 고정 같은 기본 절차만으로도 많은 문제를 빠르게 걸러낼 수 있습니다. 마지막으로 오프라인 평가는 단일 지표로 끝나지 않으며, 베이스라인 대비 해석, 보정(calibration), 슬라이스 평가, 교란 테스트 등 운영 환경에 필요한 관점을 함께 포함해야 실제로 “좋은 모델”을 넘어 “유용한 시스템”에 가까워질 수 있습니다.

mlops
mlops tracking versioning automl
This post is licensed under CC BY 4.0 by the author.