요즘 예측 모델 + 시뮬레이터 UI를 만드는데 한창이다. 최근 몇 주간 건강이 좋지 않아 업무에 집중하지 못했는데, 이번 주는 예측 데이터 마트를 구축하느라 자잘한 이슈가 많아 두뇌가 강제로 활성화됐다. 그래서 지금 이 기록을 남겨야만 한다는 의무감이 든다.

step 1. predictive model

홈쇼핑 회사는 이런 질문이 있다. 쇼핑호스트를 바꾸면 매출이 얼마나 오를까? 이 아이템은 언제 팔아야 가장 잘 팔릴까? 프로모션을 걸면 얼마나 효과가 있을까?
이러한 질문에 답을 해줄 수 있는 예측 모형을 만드는 프로젝트를 선행했다. 몇가지 기억에 남는 점은 1. (사실 매출을 예측하려면 필요한 데이터가 포함이 됐다고 생각하지는 않지만) 회사에 있는 거의 모든 데이터를 긁어와서 해봐도 충분한 데이터를 얻기 어려웠다. 2. 데이터에서 그 어떤 패턴도 쉽게 보이지 않는다. (정말 noisy하다) 3. 아무리 좋다는 모델을 써도 효과가 없어서 흔한 boosting 알고리즘을 사용했다. 4. 그래도 현재 현업에서 as-is로 사용한 예측값보단 낫다.

step 2. web developement

웹을 통해 시뮬레이션 서비스를 제공하기에 웹 개발은 필수. 예측 모형이 python으로 짜여있어 flask로 간단한 UI를 구성했다. 사실 이 파트는 내 담당이 아니라 잘 모르겠다.

step 3. data mart!

실시간 시뮬레이션 서비스를 위해 매일 데이터와 모델을 갱신하고 test 데이터를 만들어줘야한다. 이 부분이 참 말로는 쉽지만 실제 액션은 절대 그렇지가 않다는 걸 뼈저리게 느꼈다. (그래서 소제목에 느낌표를 붙였다!)

  1. test 셋을 만드는 건 train보다 어렵다. train 셋은 과거의 값이니 주어진 데이터를 그대로 사용하면 된다. 반면 test 셋은 미래의 데이터이니 사내 데이터의 대부분을 차지하는 집계치를 사용할 수 없고 네이버트렌드처럼 시계열 데이터를 가져다 쓸 수 없다.
  2. 자동화 코드를 만드는 것도 데이터 수작업 못지 않게 일이다. 먼저 DB에서 데이터를 가져오는 etl 과정, python에서 돌아가는 복잡한 데이터 전처리 과정의 예외 처리가 까다로웠다. (전처리 과정이 많다보니 기상천외한 에러도 있었다.) DB/python/외부API 3군데를 돌아다니며 데이터가 쌓이다보니 로깅 작업도 꼼꼼히 하고 나서야 실제 로직을 원활히 테스트할 수 있었고 이후로 1~2주 정도 수정하는 기간이 필요했다.
  3. 친숙하지 않은 DB와 Linux. SQLD 취득, 웹개발 경험도 실무에서 큰 도움은 되지 못했다. 언제나 그렇듯 개발 과정은 구글링 시간이 절반 정도 되는 것 같다. python 콘솔에서 보이는 에러를 잡기 위해 무엇을 해야하는지 구글링을 하며 mysql 설정, 테이블 설정, crontab 설정등등 DB와 server os를 반드시 만져야 했다. 시스템을 구성한다는 건 개발자로서의 능력도 요구하기에 녹록하지가 않았다.