[MLFlow] #1. 필요성 검토

현재 회사에서 Demand Forecasting 과제를 수행하고 있다

 

여러 모델들을 사용하며 성능 테스트를 진행중인데, 테스트 기간이 길어질 수록 파라미터 및 버전관리에 어려움을 느끼게 되었다

 

원시적인 버전관리

 

취업 전에는 토이 프로젝트 형태로 진행되었던 모델링이기 때문에 버전관리나 별도의 코드 형상관리가 필요없었기 때문에 이런 부분에 대해 신경써본적이 없기도 하고, 팀 내 인프라가 갖춰져있지 않은 상황이다 보니 조언을 구할 방법이 마땅치 않았다

 

물론 팀바팀으로 이런 부분을 전문적으로 관리하는 팀이 있지만, 현재 상황에서 필요한 내용이 정확히 무엇인지 파악하는 과정이 우선시 되어야 필요한 도움을 구할 수 있기 때문에 현재 상황을 바르게 인지하는것이 우선이라 생각했다 (이렇게 만들어진 모델 개수만 1,000개가 넘는다, 현재 버전별 특징이나 결과를 기억하고 있는것도 기적...)

 

 

 

지금껏 모델링을 진행하면서 느꼈던 가장 큰 문제점과 필요한 점은 다음과 같다

 

1. 파라미터 테스트 결과를 파일단위로 저장하니 관리하기가 쉽지 않다

2. 주피터 단위 실행을 진행하니 시간이 너무 오래걸린다
ㄴ 데이터 전처리 과정의 중복 실행 포함, 파일 단위로 저장해도 되지만 데이터 핸들링과 연결된 파라미터가 많아 고정시키기 어려움

3. 결과 공유 과정이 매끄럽지 못함
ㄴ 휴가를 쓰면 이 모델에 대해 설명할 사람이 없다

 

 

물론 이 부분을 전혀 고려하지 않고 프로젝트를 진행했던 것은 아니다

 

모델 서비스를 위해 코드도 모듈화를 시켜두었고, 런타임 환경에 필요한 패키지 버전 체크도 수행 후 별도 관리 파일을 만들어 두었다.

 

또한 결과 공유 및 내부 평가를 위한 BI도 개발하여 활용하였다

 

 

예쁘게 잘 만들었는데 모자이크하니 퀄이 낮아보인다

 

 

streamlit을 기반으로 BI도 만들어서 활용했지만, 아무래도 이건 결과론적인 부분이고 모델링 하는 과정에서는 직접적으로 도움이 되지는 않았다

 

 

결론적으로 이 모든 과정(최적 파라미터 선택, what if case 실험 등) 을 하나의 화면에서 실험하고 파일을 관리했으면 좋겠다는 생각이 들었고, 모델 담당자가 부재여도 다른 사람이 얼마든지 웹에서 실험을 하고 결과를 바로바로 확인할 수 있었으면 좋겠다는 생각이 들었다.

 

 

 

사실 반드시 MLFlow를 써야하는 이유는 크게 체감하지 못했지만 (공부를 아직 하지 않아서) 이런 고충을 많이 해결해줄 수 있다고 하니 한번 시도해보는 것도 나쁘지 않다고 생각이 들었다.

 

 

물론 이 방법을 썻을때 어떤점이 좋아지는지 확인이야 했지만 굳이 글로 정리한 상태에서 시작하고 싶지는 않고, 만들면서 느껴가고 싶어서 늘 그랬듯이 몸통박치기로 해보려고 한다