Chanhee Lee

마케팅 Life Time Value (LTV) 예측 프로젝트: Stage 1

진행 기간: 2021.01 ~ 2022.02

프로젝트 소개

효율적인 마케팅 예산 집행을 위해 캠페인 별 평생 가치(LTV)를 예측하는 프로젝트.
(LTV 프로젝트 설명)

Stage 1 목표

• 기존 코드 및 대시보드 유지보수

LTV 예측 프로젝트는 제가 입사한 2021년 이전부터 오랫동안 연구가 이어진 오래된 프로젝트로, 이미 LTV 예측값을 통해 마케터가 캠페인의 성과를 판단하는 프로세스가 어느 정도 정립된 상황이었습니다. 그렇기 때문에 주 목표는 예측 모델이 잘 작동할 수 있도록 데이터 파이프라인 및 모델 코드를 관리하는 것이었습니다.

서빙 방식

마케터는 두 가지 방식으로 LTV 예측값을 제공받았는데, 하나는 대시보드, 하나는 jupyter notebook 형태의 코드였습니다.

1. 대시보드: 고정적으로 보는 분석
   • 주기적으로 큰 단위의 LTV 를 확인하고자 하는 케이스
   • 대시보드에 들어가는 파라미터 종류도 적고 파라미터 값의 cardinality 도 낮음
   • 대시보드에 필요한 데이터는 매일 airflow 배치 잡을 통해 LTV DW (Data Warehouse) 에 적재
2. jupyter notebook: 대시보드보다 좀더 세세한 분석
   • 미세하게 파라미터 값을 조정해가며 캠페인 성과를 확인하고자 하는 케이스
   • 파라미터를 interactive 하게 조정하면서 모델링 코드를 실행할 수 있는 노트북을 제공
   • 마케터가 직접 노트북을 실행한 뒤 결과를 표나 그래프로 확인할 수 있고, 엑셀로 export 할 수도 있음

운영 및 유지보수

• airflow 배치 잡 장애 대응
• 대시보드 시각화 개선 (SQL, 대시보드 디자인)
• jupyter notebook 코드 유지보수
• 마케터 대상 jupyter notebook 활용법 가이드 및 트러블슈팅 지원
• LTV 관련 ad-hoc 분석/시각화

모델링

(작성 중)

회고

이 시기 동안 모델링 자체는 개선한 부분이 없었지만, 아직 python 및 소프트웨어 엔지니어링에 대해 배워나가는 시기였기 때문에 핸즈온으로 여러 작업들을 하면서 새로 배운 것들이 많았습니다.

• 모델 운영 및 유지보수의 중요성:
  • 모델을 개발하는 것도 중요하지만, 결국 이 모델이 꾸준히 활용되고 가치를 만들기 위해서는 잘 돋보이지 않는 운영과 유지보수가 필요하다는 것을 꺠달았습니다.
  • 또한 구체적으로 어떤 운영, 유지보수 작업이 필요한지 배운 시기였습니다.
• 개발 환경 세팅은 개발 속도에 큰 영향을 끼친다:
  • MCMC 모델을 구성하기 위해 pymc3 라는 라이브러리를 사용했는데, numpy, pandas, theano 등 여러 라이브러리와의 디펜던시가 엮여있어 환경이 조금 달라질 때마다 어려움을 겪었습니다.
  • 게다가 개발 환경과 서빙 환경이 크게 다르다는 문제도 있었습니다. 데이터 과학자가 개발하기 위한 클러스터, airflow 배치 잡이 실행되는 환경, 마케터가 사용하는 클러스터, 이 셋 모두 각각의 권한과 python 환경이 달라 문제가 생겼습니다.
  • 지금이라면 Docker 컨테이너 등을 통해 최대한 환경을 비슷하게 맞추려는 노력을 하거나, 최소한 python 환경이라도 고정시키기 위한 시도를 했을 것 같습니다.
• 코드 버전 관리를 잘해야 코드의 의도를 파악하기 쉽다:
  • jupyter notebook 형태의 코드는 google drive 에 저장되어 있어 버전 관리가 어려웠습니다.
  • 또한 airflow 배치 잡을 위한 코드는 데이터 엔지니어들이 관리하는 별도의 레포에서 관리되어 이원화되는 문제가 있었습니다.
  • 기존의 코드에서 복잡한 비즈니스 로직이 추가/변경되면서 코멘트를 계속 추가하는 방식으로 작성되어 있었는데, 이를 git 같은 도구로 관리했으면 훨씬 추적이 쉬웠을 것 같습니다.
• 코드를 목적성에 맞게 잘 분리해야 이해가 쉬워지고, 변경도 쉬워진다:
  • jupyter notebook 으로 제공하던 코드는 복잡한 비즈니스 로직이 많이 포함돼 있어, 시뮬레이션을 실행하는 함수 하나가 지나치게 길어져 가독성이 떨어졌습니다.
  • 이 때문에 문제가 생겼을 때 디버깅하기도 어려웠고, 새로운 기능을 추가하는 것도 제한적이었습니다.
  • 또한 가독성으로 인해 코드 자체를 이해하기 어려워지는 것도 코드 개선 작업에 부담을 주는 큰 요인 중 하나였습니다.
  • 이 때의 경험을 통해, 이후의 프로젝트에서는 각 역할에 따라서 코드를 구조화하고 그에 따라 함수를 쪼개거나 모듈화하면서 작업하게 되었습니다.
  • 또한, 비즈니스 로직은 반드시 타 모듈에 존재하는 함수나 클래스를 호출하는 형태로 만들어, 비즈니스 로직 자체를 최대한 분리하는 방향으로 코드를 작성하는 게 좋은 패턴이라는 것을 이해하게 되었습니다.
• 유저의 편의를 고려한 서빙 역시 중요하다:
  • python 자체에 익숙하지 않은 마케터에게 jupyter notebook 형태의 코드를 제공하는 것은 최선의 방법은 아니었던 것 같습니다. 최대한 개발 공수가 적은 방향으로 서빙하려다 보니 어쩔 수 없는 부분이었던 것 같습니다.
  • 특히 많은 데이터를 대상으로 시뮬레이션할 경우 시간이 오래 걸리기 때문에, 노트북을 실행하는 동안 웹브라우저 사용이 불편해지는 문제가 제일 컸습니다.
  • 이를 해결하기 위해 이후 프로젝트에서 웹서비스의 형태로 개발하는 시도도 해봤으나, 프로토타입 수준 이상의 서비스를 개발하기에는 한계점을 느낄 수 있었습니다.
    • 참고: LTV Stage 3
• 결과 재현성은 더 발전된 모델링을 위해 필수적이다:
  • MCMC의 특성 상 랜덤성을 제어하지 않으면 매번 실행할 때마다 결과가 달라집니다.
  • 이 때문에 문제가 생겼을 때 디버깅 과정에서 맞게 나온 결과인지 확인하려면 많은 노력이 필요했습니다.
  • 이전의 결과와 비교하고 싶을 때도 제한적이었습니다.
  • 모델링의 결과를 과학적으로 분석하고 평가하기 위해서 결과를 다시 재현할 수 있는 것이 중요하다는 것을 깨달았습니다.