데이터 분석의 첫 삽
데이터 분석가로 일하고 싶거나, 이미 현직에서 데이터 분석을 업으로 하고 있는 사람들이 갖는 업무의 애환에 대해 이야기해보고자 한다.
이제는 그 어느 하나 데이터 관련 직군을 채용하지 않는 회사가 없고, 관련 교육과정도 많이 생겼으며 학부 전공도 생길락 말락 하는 태동의 시기이다. (이미 생겼을지도..) 많은 회사에서도 찾고 하니 가끔 JD를 받아보거나, 일부러 찾아보기도 하는데 의아한 점이 있다. 데이터 추출에 그 업무의 주안점을 둔 다는 것인데, 물론 데이터 추출 없이 분석을 어찌하겠느냐만은, 너무 추출에만 초첨이 맞춰져 있어서 그렇다. 데이터를 추출함에 있어서 그 방법론적으로 꼽히는 것은 아무래도 SQL이 보통이다. 구글 애널리틱스나 기타 다른 3사 툴들을 사용하기도 하지만, 처음만 그렇고 점차 SQL로 직접 추출하는 테크트리(?)를 타게 된다. 처음에는 SDK만 심으면 기본 지표들 대부분을 제공하는 툴들로 입문하게 되는 것이 일반적이고 추후 데이터 신뢰도의 이슈 혹은 제공하지 않는 데이터, 기존 데이터와의 혼재의 이유로 SQL을 필요로 하게 된다. 흔히 데이터 봇(Bot) 혹은 자판기의 R&R을 주된 업무로 가져가는 롤 (일반적으로는 주니어겠지만..)이 사내에 존재하게 되는데, JD에서 말하는 데이터 추출능력은 SQL 사용능력을 사실상 지칭하는 셈. 헌데 아이러닉 하게 데이터 분석이 Data Analyze인데, 실제로 분석(Analyze)을 하고 있는지에 대해서는 약간 물음표이다.
이런 간쥐나는 자세로 일하는 날이 오겠지..분석의 프로세스에 대해 어느 유명한 사람이 이미 정리해둔 것이 있는지는 모르겠으나, 내 생각에는
데이터 추출 -> 정제(전처리) -> 시각화 (필요시) -> 리포트 -
> 액션 아이템 도출 (인사이트) -> 학습 -> (반복)
의 수순을 갖는다 생각된다.
여기에서 가장 중요한 단계가 데이터 추출에 앞서 필연적으로 진행되어야 할 가설 수립이다. 데이터 분석을 목표로 데이터를 추출한다면, 추출의 목표가 있을 터. 막연하게 아무 데이터나 뽑아 보기보다는 (그냥 아무거나 시계열로 뽑아보다가 얻어걸리는 경우도 있긴 하다) 누수가 예상되는 지점이나, 사용자의 고충이 있을 법한 화면 내지는 기능(Feature)에서 이러이러한 불편이 있겠거니 하고 가설을 수립하고 추출을 하게 된다. 사실 데이터 인프라가 잘 구축되어 있으면, 보통은 대시보드 등을 관제하는 것이 일과의 시작이다. 예를 들어 그 관제를 통해서 사용자 대비 페이지뷰 비중을 나타내는 복합 지표의 등락을 예의 주시하는 도중에, 사용자당 페이지 뷰가 급등했다고 하자. 그냥은 아닐 테고, 필시 이유가 있을 터. 페이지별로 해당 페이지에 페이지뷰를 찍은 사용자의 수와 그 들의 페이지 뷰수를 추출하고 위 복합 지표를 연산해서 붙여보면, 특정 화면에서의 페이지뷰가 다른 화면 대비 높은 것을 발견할 수 있을 것이다. (뭐 전반적으로 다 늘었을 수도 있으니, 시계열로 봐야 할 필요도 있겠다) 만약 그 페이지가 회원가입 화면이라고 했을 때 어떻게 가설을 수립하느냐에 따라서 추출하는 데이터가 달라질 수 있겠다.
첫 번째로 회원가입 화면에서의 반복된 화면 호출의 경우, Javascript 오류 등으로 화면이 정상적으로 출력되지 않거나, 특정 버튼이 작동을 하지 않거나 혹은 다음 화면으로의 이동이 되지 않을 때 사용자들을 F5키를 누르게 된다. 여기서의 가설은 "회원가입 과정에서 어려움이 있어서 재차 반복해서 회원가입을 하려 했다."인데, 다른 화면으로의 이동 후 재 진입 (=가입 시도 이후, 껐다 켰거나 다른 화면 이동 후 재 진입)이라면 Member_Regist (회원 가입 화면명 예시)에서 다른 화면 이동 후 다시 Member_Regist로 진입했을 것이다. 그 페이지 뷰의 시간차가 갖는 의미가 다른데, 아주 짧다면 (짧다의 정의는 각각 다를 수도 있으니, 다른 여타 화면들 간의 이동 시간차의 값과 비교해보면 좋겠다) 정말 뒤로 가기 이후 바로 재진입일 것이고, 길다면 세션이 끊기고 추후에 재시도하는 것 일 수도 있으니 말이다. 그렇다면 여기서 데이터 추출을 한다면, 가설을 입증하기 위해서는 회원가입 화면 내의 각각의 버튼 클릭 여부가 필연적이다. 특정 사용자가 주소 찾기 버튼을 가입 화면 1회 진입에 여러 번 눌렀다면, 잘 안 눌리거나 검색 결과가 올바르지 않아서 일 것이다. 회원 가입하기 완료 버튼을 여러 번 눌렀다면, 아마도 다음 화면으로의 이동이 되지 않아서 일 것이다.
단순히 버튼 클릭 한 가지만 놓고도, 개발적 지식을 조금 가미한다면 여러 뎁스에서 데이터 적재가 가능하다. (아니 필요하다) 단순히 버튼이 클릭되었을 때 (클라이언트에서 적재), 회원가입 요청이 들어왔을 때 (서버에서 적재), 가입의 필수 값이 모두 올바르게 입력돼서 OK가 떨어졌을 때, 특정 값이 불충족 되었을 때 등 여러 상황에 대해서 사용자가 해당 시점에 겪었을 상황을 재현해 볼 수 있도록 깊은 뎁스에서의 데이터 적재가 필요하다.
여러 가지 상황에 대해 데이터를 추출하고 이제는 최초 세웠던 가설을 입증하는지, 반증하는지에 대해서 검토가 필요할 차례이다. 실제로 가설대로 특정 버튼이 작동하지 않아서 여러 번 시도했는지, 가입 요청 이후 별 반응이 없기 때문에 곧바로 이탈했다가 다음에 다시 시도했는지 (혹은 다시는 돌아오지 않았는지), 특정 환경에서만 작동하지 않은 건 아닌지.. 등 여러 가지 관점에서 가설을 증명해야 한다. 별반 특별할 것 없는 데이터만 나온다면 어쩔 수없겠지만, 뭔가 평소와는 다른 점이 발견된 다면 데이터 분석의 첫 삽이 성공적이었다고 판단해도 좋다.
가설이 입증 혹은 반증이 되더라도 그 자체만으로 정보가 되고, 해당 정보를 기반으로 사용자가 겪고 있는 불편 등 사실(인사이트)을 도출해 내서, 해당 고객 경험이 반복되지 않도록 버튼 오작동 수정 요청은 테크팀에게 가입 실패 경험 고객 정보는 CRM팀에게 전달해서 고객 경험을 개선시켜야 한다. 물론 항상 가설이 뻘(?) 가설일 때도 있고, 데이터 적재 기획을 한 사람과 추출하는 사람이 달라서 필요한 데이터가 없거나, 데이터의 결과가 별다른 인사이트를 주지 않을 때가 많지만, 그 프로세스는 위와 같다고 생각된다.
이와 같은 프로세스를 통해 서비스의 개선 내지는 고객 경험 강화 등의 결과를 도출 해 낸다면 성공적인 분석가의 업무를 수행하고 있다는 생각이 든다. 이 과정에서 데이터 추출이 필연적으로 포함되는 것이 당연지사지만, 그것이 업무의 전체 혹은 대부분이 돼서는 안 된다.
