기존의 문제점
- 반복적인 실험 과정에서 실험 간 비교 기준과 모호해짐
- 파라미터 변경 이력이 체계적으로 관리되지 않아, 성능 개선의 원인을 명확히 설명하기 어려움
- Featrue 변경에 따른 성능 변화가 누적 관리되지 않아, 각 feature의 기여도를 정량적으로 추적하기 어려움
- 실패한 실험은 단순 결과로만 남아, 향후 의사결정에 활용되지 못하는 한계가 존재
“문제가 바뀌어도 항상 같은 방식으로 실험할 수 있는 기본 틀”이 필요하다고 생각하여, 개인용 MLOps 베이스 템플릿을 만들게 되었다.
해결하고 싶은 것
- 실험을 항상 같은 구조와 흐름으로 실행할 수 있을 것
- 코드 수정 없이 설정만 바꿔도 실험을 반복할 수 있을 것
- 성공한 실험뿐 아니라, 실패한 실험도 다시 돌아볼 수 있도록 남길 것
- 나중에 봐도 “왜 이 실험을 했는지?”를 설명할 수 있을 것
실험 결과보다 실험 과정이 남는 구조를 만드는 것을 초점에 두었다.
현재 버전(v1.0.0)에서 다루는 범위
현재 템플릿은 실험 관리와 재현성에 집중한 초기 버전이다.
- 실험의 공통 구조를 강제 (setup → load_data → train → evaluate)
- 모든 실험 설정을 YAML로 관리
- 여러 실험을 순차적으로 실행하고 결과를 비교
- 실험 결과를 파일로 남겨, 이후 분석 가능하도록 구성
Github
구조
mlops-labs/ ├── README.md ├── requirements.txt ├── .env ├── .gitignore │ ├── mlops/ │ ├── experiments/ │ │ └── base_experiment.py │ ├── config/ │ │ ├── schema.py │ │ └── loader.py │ ├── tracking/ │ │ └── mlflow_utils.py │ └── utils/ │ └── logger.py │ ├── projects/ │ ├── config/ │ │ ├── baseline.yaml │ │ ├── lr_0001.yaml │ │ └── lr_01.yaml │ ├── results/ │ ├── run.py │ ├── run_all.py │ └── summarize_results.py │ └── scripts/ ├── run_experiment.sh ├── run_all_experiment.sh └── run_summarize_results.sh
사용법
Hydra의 config group 개념을 활용, 하나의 실험을 데이터 / 모델 / 실험 설정 / 검증 전략 단위로 분리하여 구성
프로젝트 추가 예시
projects/ └── kaggle_experiment/ ├── config/ │ ├── config.yaml # experiment entry config │ ├── cv/ # validation strategy │ ├── data/ # dataset & feature configs │ ├── model/ # model-specific configs ├── dataset/ ├── experiment.py └── train.py
결과 예시
아직 포함되지 않은 것들 (앞으로의 계획)
다음 단계로 생각하고 있는 영역들이 있는데, 현재 버전에서는 의도적으로 포함하지 않았다.
- 실시간 공동 작업 및 실험 관리
- 모델 배포 및 서비스 운영 자동화
- 배포 이후 실시간 모니터링과 성능 추적
