Mathpresso DB팀의 데이터 분석과 시각화 방법(1)

hz
hz in MATHPRESSO
Jul 22, 2018 · 8 min read

Data Science에 대한 사람들의 관심이 식을 줄 모르고 있다. 이 학문의 내용은 기초적인 통계 분석부터 Machine Learning까지 다양하며, 필자가 흥미를 느꼈던 부분은 경연대회 형태로 기업이 처한 문제 상황과 Data Set이 제공되면 참가자들이 문제를 진단하고 중요한 요소가 무엇인지에 대한 통계적인 근거를 통해 insight를 주는 Kaggle(https://www.kaggle.com)이라는 Web Site를 본 뒤였다. 이를 본 이후로 Mathpresso에서도 이런 분석과정과 그를 토대로한 의사결정 과정이 도입되어야 한다고 판단하여, AI 개발팀과는 별개로 DB팀을 구성하여 콴다(Qanda) 서비스 사용자에 대한 체계적인 분석을 시작하게 되었다. 이 글에서는 DB팀이 그 동안 사용했던 Tool들의 개요와 간략한 장단점, 그리고 미래에는 어떻게 움직일 것인지에 대해 다루려고 한다. 글을 시작하기 전에, 필자가 비개발자이기 때문에 개발자 입장에서는 다소 의아한 표현과 사고방식이 느껴지더라도 양해를 부탁드린다.


어떤 Tool들을 사용해왔나?

a. MySQL + Excel

팀 초기, KPI를 설정하지 못했던 시절(어떤 숫자가 어떻게 상호작용하여 어떤 의미를 가져다주는 건지 모르던 시절)부터 7일치 데이터가 2백 만 건을 훌쩍 넘어버린 현재에도 간간히 사용하고 있는 조합이다. 장점과 단점은 명확하다.

<장점> ① 약 105만 행까지 지원 ② 필터 기능, 우측 하단 요약 정보(평균, 합 등등), 중복제거 등등 사용자 친화적인 UI (또한 raw data가 모두 보여서 편할 때가 있음) ③ 그러면서도 꽤 큰 자유도를 제공(Join 기능까지 구현 가능) ④ Graph(나아가 Chart) 기능이 다양하고 쉬움

<단점> ① 105만 행 이상의 raw data를 직접 Excel에다 넣을 수가 없음 ② Excel에서는 Group by 기능을 제한적으로밖에 쓸 수 없어서 불편 ③ 다른 사람들에게도 해당 내용을 공유하려면 만든 Graph나 분석 내용에 대해서 다른 Tool(Powerpoint나 Word)에서 정리해주어야 함 ④ 분석 과정을 저장하기가 힘들어서 다른 Data Set을 가지고 똑같은 분석과정을 거치기 위해서는 모두 반복해야 함 ⑤ 이렇게 만들어진 Chart를 실시간으로 보여줄 수 없음

필자가 다른 Tool들에 대해 전혀 모르던 시절에는 유일한 선택지였고 어느 정도 다른 Tool에 대해서 공부를 하던 시절에는 반복 작업이 많아도 작업 효율이 좋아 애용하던 조합이다. 현재에는 팀에서 중요하다고 설정하지 않은 부가적인 수치들, 6개월에 한 번 정도 보고 마는 수치들(이들의 특징은 Data를 SQL query를 통해 뽑아 Excel로 집어넣을 때 10,000행 혹은 6열이 넘지 않는 정도의 양이다.)을 빠르게 보거나 팀원들에게 공유할 때 사용하고 있다. 다음 단계로 분석 Tool를 옮겨야 한다고 결정했을 때 가장 중요하게 작용했던 이유는 ‘실시간성’의 확보였었다.

b. Django + 자체제작 Webpage

우리가 제공하고 있는 서비스를 ‘얼마나 많은 학생들이 사용’하며 그들의 ‘서비스 만족도는 어떤지’에 대해 팀원들이 실시간으로 살펴봐야 할 필요성에 대해 깨닫고 실시간(혹은 지정한 기간)으로 Chart를 그려주는 페이지를 직접 제작했다. 통계 페이지에서 보여줬으면 하는 수치들을 모아 기획하였고 Django와 Angular 2 를 이용하여 통계 페이지를 구현하였다. 덕분에 팀원들은 자신이 궁금한 항목에 대해 매번 SQL query를 거칠 필요없이 통계 페이지에서 수치를 확인할 수 있게 되었다. 다만 이렇게 직접 구현한 통계 페이지의 한계는 명확했다. 팀 내의 웹 개발자 자원은 한정적이고 고객을 위한 개발을 우선적으로 진행(기업의 생존을 위해서)하다 보니 통계 페이지의 개선은 고사하고 유지보수도 하지 못하여 통계 페이지 완성 후 몇 개월 뒤에는 기능들이 정상적으로 작동하지 못했다. 그렇다고 실시간으로 수치를 보여주는 페이지를 아예 포기할 수 없기에 방법을 찾아 나서게 된다.

c. Big Query & Red Shift + Chart.io

통계 페이지가 고장난 시점에서는 Google Playstore 개발자 console과 Firebase(Google에서 제공하는 사용자 수치 분석 Platform) console 상에서 기본적으로 보여주는 Dashboard를 참고했었다.

그러나 주/월 단위 잔존율(retention), 신규/기존 사용자의 구분 등을 제공하지 않다보니 깊이있는 정보를 얻어낼 수 없었다. 다만, Firebase는 상세한 origin event data(실제로 사용자가 언제 설치했고, 어떤 화면에 언제 머물렀고, 언제 이탈했고, 언제 앱을 삭제했는지 등을 기록한 Log Data)를 Big Query에 저장한다. 이 시기 쯤부터 필자도 SQL 문법에 대해 꽤 많이 이해하고 작성할 수 있는 시점이었기 때문에, 콴다 서버의 DB(MySQL)와 Firebase의 DB(Big Query)에서 query한 결과를 실시간으로 시각화해주는 Tool만 있다면 충분히 Dashboard를 만들 수 있는 상황이었다. 이 때 알게된 Tool이 Chart.io 였다.

SQL 문법을 잘 몰라서 query로 Data를 잘 정렬하지 못하더라도 chart.io에서 제공하는 정렬 방식(group by, join 등을 UI에서 제공하는 버튼을 통해 구현할 수 있다.)을 통해서 숫자, 이전에 비해 화살표와 퍼센트로 나타낸 등락의 정도, 꺾은선 그래프, 막대 그래프 등등을 사용자가 원하는대로 그려줄 수 있다.

Chart.io를 기반으로 Mathpresso DB팀에서 만든 Dashboard의 Data source는 다음과 같이 변화하였다.

① MySQL : BigQuery 사용법을 잘 몰라서 Qanda DB에서만 Data를 뽑아서 차트를 만들던 시기 ② MySQL, BigQuery : Qanda DB에서는 저장하지 않는 BigQuery의 Data(앱 설치 기록, 앱 삭제 기록 등)를 추가하여 사용자 집단에 대한 분석을 곁들인 Dashboard를 제작 ③ RedShift, BigQuery : 주 단위 검색 시도 수가 100만 건을 넘어가면서 MySQL의 instance 용량에 따른 요금과 낮은 요금제에서의 느린 응답속도가 감당하기 힘든 수준이 되었고 Qanda DB를 RedShift로 주기적으로 복제하여 저렴한 비용과 사용할 만한 응답속도를 확보

현재는 팀별 KPI에 대한 주간 수치 전달과 사용자 집단별 잔존율 등의 부가적인 정보를 제공하고 있다. 그러나 문제점은 Excel로 Data를 가공하는 것보다는 자유도가 낮기 때문에 문제점 분석을 위한 이런저런 가설과 검증에는 한계가 있었다.

그 이후의 Mathpresso의 DB팀 분석 Tool은 다음과 같다.

d. Django + Jupyter Notebook

e. Statistics server

글이 다소 길어졌고, d와 e 항목에 대해서는 별도로 설명해야 하는 부분(구축 환경, 어떤 작업이 가능하고, 어떤 분석을 했었는지 등등)이 많다 보니 이후의 글에서 언급하려고 한다. 초창기부터, 지금은 사용자들의 Log Data 량이 Big Data라고 언급할 수 있을 정도로 성장한 지금까지의 Mathpresso가 어떻게Dashboard를 구축했는지 설명을 하였다. 다음 글에서는 더 많은 Data를 낭비없이 효과적으로 Dashboard에 나타내는지, Dashboard에는 어떤 분석 방법을 거친 수치들이 나오게 되는지, Jupyter Notebook으로는 어떻게 가설 검증을 하며 insight들을 얻어내는지 설명하려고 한다.

MATHPRESSO

We rebuild education.

hz

Written by

hz

Mathpresso

MATHPRESSO

We rebuild education.