쿠팡이츠의 초기 론칭부터 MAU 550만까지의 실험 및 데이터 분석을 담당한 Data Scientist는 어떻게 일할까요? 핵클 Data Scientist, Jen님이 3월 25일 핵클 웨비나<데이터를 잘 보기 위한 첫걸음>에서 실무경험을 바탕으로 인사이트를 공유드려요.

👉🏻 Jen님의 <데이터를 잘보기 위한 첫걸음> 웨비나 신청하기

‍

‍

* 본 글에서는 유저의 행동 데이터를 편의상 이벤트로 작성했습니다.

‍‍

Q. 쿠팡이츠 초기 멤버라고 들었어요. 이벤트(로그) 설계를 직접 하셨다구요.

 안녕하세요! 핵클 데이터 사이언티스트, Jen이라고 합니다. 학부에서 컴퓨터 과학, 통계, 교육학을 전공하고 데이터 사이언티스트로 일한지는 벌써 12년차가 되었네요. 첫 커리어는 메가스터디에서 시작했고, 유저 행동 데이터(이벤트) 분석은 쿠팡에서 본격적으로 하기 시작했어요. 쿠팡이츠에서 고객앱, 배달파트너앱의 95%의 로그를 직접 정의했었네요. 쿠팡 이전에는 Google Analytics를 활용해서 자동으로 수집되는 데이터만 봤었는데요. 그 당시에는 웹 중심이라서 이벤트 정의가 사실 별로 필요하지 않았었어요. 페이지(URL) 단위로 유저의 행동을 트레킹하는 정도였죠. 스마트폰 보급으로 사람들이 앱을 많이 사용하면서, PV뿐만 아니라 스크롤, 클릭 등 이벤트를 직접 정의하는 작업들이 굉장히 중요해진 것 같아요.

 ‍

그리고 최근 IT회사들의 고속성장을 위한 SaaS플랫폼, 핵클에 조인했습니다.

 지금 핵클에는 저와 쿠팡페이, 쿠팡이츠에서 함께 근무하였던 시니어 PO, 개발자 분들이 10명 넘게 있는데요. 저는 쿠팡에서 근무기간이 3년 조금 넘는데, 대부분 저보다 쿠팡에서 오래 계셨던 분들이에요. 저는 이분들 노력 덕분에 쿠팡이 100조 IPO에 성공하지 않았나~ 항상 감사하게 생각하고 있어요😊 (어떻게 보면 저는 쿠팡에 뒤늦게 승차해서 덕만 봤어요). 

‍

 다들 아시겠지만 쿠팡페이, 쿠팡이츠가 단기간에 급성장했잖아요. 지금 핵클에서 함께 근무중인 멤버 분들은 쿠팡에서도 탑오브 탑이었던 핵심 인재들이었어요. 그래서인지 이들이 데이터에 기반해 제품을 고속성장 시켰던 노하우를 담은 핵클 플랫폼도 시장에서 빠르게 반응을 얻고 있고, 핵클 또한 고속성장중이랍니다. 아마 조만간 핵클을 통해 유니콘이 되는 스타트업들이 쏟아져 나오지 않을까 싶어요. 핵클 또한 빠른 속도로 유니콘, 데카콘이 될거구요!

‍

Q. 이벤트 설계는 왜 중요한가요? 

이벤트를 모으면 할 수 있는 일이 많아져요!

 유저 행동 데이터 분석하면 퍼널 분석, 패스 파인더 (journey)를 가장 많이 떠올리실 거에요. 저는 클릭 스트림을 이용해서 고객의 다음 행동을 예측하는 모델을 만들어 보기도 했었고, 고객들이 관심있게 클릭하는 상품 정보를 바탕으로 추천 알고리즘을 설계하기도 했어요. 제대로 설계된 이벤트 데이터를 수집한다면 고객의 니즈를 알 수 있고 이를 활용해 개인화 추천서비스에 활용할 수도 있고 프로덕트에 다양한 시도를 할 수 있는 기회를 찾을 수 있어요

‍

가설, 검증, 분석에서 제대로 된 이벤트 설계가 없으면 유의미한 결과도출이 어렵습니다.

 일단 데이터를 쌓고보자는 식의 마인드는 굉장히 위험하다고 생각해요. 우리가 어떤 프로모션을 진행했는데, 100명이 응모했다고 해볼게요. 1000명이 들어와서 100명이 응모한건지, 1만명이 들어와서 100명이 응모한건지에 따라서 효율 자체가 엄청 달라지겠죠! 이처럼, 이벤트 설계가 제대로 안되어있으면 결과만 알 수 있어요. 이벤트를 잘 설계하면, 현재의 상태(status)뿐만 아니라 과정 전체를 볼 수 있습니다.

무엇을 볼 지를 먼저 생각해야합니다.

 모든 것을 데이터로 수집할 필요가 있을까요? 우리는 모든 것의 범위가 어디까지인지 조차 몰라요. 이미 있는 필드인데 또 만들 수도 있고, 아무 속성 값(property)없이 횟수(count)만 남기면, 정작 딥다이브한 분석이 불가능해요. 고객의 행동을 이해하고 싶어서 데이터를 수집했지만, 데이터에 어떤 identity도 부여할 수 없어요. 처음 온 사람의 잔존율, 최종까지 가는 사람의 잔존율.. 다 다를텐데, 뭉뚱그려서 보면 어떤 문제가 있는지 발견하기 어려워요. 무엇을 보고 싶은지를 명확하게 정의해놓고, 데이터로 저장해야 쓸모 있는 데이터가 수집되겠죠!

‍

Q. 이벤트 설계가 말처럼 쉽지 않은 것 같은데요. Jen님은 처음 이벤트를 정의하는 것이 어렵지 않았나요?

 저는 이벤트 설계가 일기를 쓰는 것과 똑같다고 생각해요. 몇시에 눈을 떠서, 욕실에 가서 세수를 하고, 옷을 입고, 회사를 가고.. 이 모든 것이 이벤트인데요. 유저가 했던 행동을 명명해주는 것. 그리고 그 규칙을 서로 합의할 수 있는 형태로 표준화하는 것이 이벤트 설계라고 할 수 있어요. 페이지뷰(PV), 팝업 노출 수(imps), 클릭(click), 몇번 스와이프를 했다, 몇 퍼센트까지 봤다(scroll).. 등 남길 수 있는 정보 자체는 사실 많지 않을 수 있어요. 남길 수 있는 유저 행동은 한정되어 있어요.이벤트 정의는 어렵지 않은데, 어떤 속성을 함께 남길지가 관건이지요.

데이터를 효율적으로 남겨야해요. 

 쿠팡이츠 유저가 홈 진입부터 카트에 담기까지 얼마나 많은 스토어를 봤을까를 데이터로 본다고 해볼게요. 

• 유저가 본 (단순 노출된) 상점들 모두
• 클릭해서 본 상점들만
• 스와이프하면서 마지막으로 본 1개만

 어떤 기준으로 데이터를 수집해야할까요? 이런 애매한 데이터들을 어떻게 정의하는가가 로그를 설계하는 영역입니다. 쿠팡이츠에서 저는 각 영역을 컴포넌트 별로 묶어서 수집했어요. 1번 컴포넌트에서 3개, 2번째 컴포넌트 3개, 골라먹는 맛집에선 5개 이런식으로요. 유저가 한 번에 봤던 것이기 때문에 하나의 세션에서 몇개를 봤다고 카운트했죠. 로그를 남기느라 앱에 부하를 주면 안됩니다. 최대한 개별 동작을 남기되, 묶어서 수집할 수 있는 것은 묶어서 수집하는 것이 필요해요.

데이터는 최대한 보기 쉽고, 활용성을 고려해서 효율적으로 수집해야 합니다.

 실무에서 데이터를 어떻게 효율적으로 수집할 수 있는지는 경험에서 나옵니다. 인하우스에서 데이터를 ‘많이' 수집하는 것 그 자체는 개발자가 다소 귀찮아지는 것일뿐 고민 포인트가 아닐 수 있는데. 핵클과 같은 3rd party를 사용하는 경우 비용의 문제와 직결되죠. 고객사 입장에서는 효율적으로 이벤트를 수집하는데 관심이 많으신 것 같아요. 그래서 이런 고민포인트를 해결해드리고자 웨비나를 준비하고 있습니다. 

‍

‍

 Q. 가장 기억에 남는 프로젝트가 있나요?

거창한 건 아닌데, 표준화된 로깅 프로세스를 정립했어요. 쿠팡에는 로그와 관련된 내부 관리 툴이 있긴했는데, 기능상 커버가 안되는 부분이 있다보니 조직마다 로그를 설계하고 관리하는 방법이 다 달랐어요. 핀테크 조직에서는 분석가가 스프레드 시트를 활용해 설계하면 개발자가 내부 툴에 메타 정보를 등록하고, 코드에 반영해 주었는데요. 쿠팡이츠에서는 데이터 분석가가 Jira 티켓을 활용해 설계하고 내부 툴에 메타 정보 등록까지 했어요. 이후 과정은 개발자가 담당하고요.

저는 로그가 설계 되어 실제 데이터 수집 되기까지의 과정을 총 6단계로 정의하고 각 과정별로 PoC를 누가 가져갈지 표준화했어요.

로그 설계 (분석가) -> 메타 정보 등록 및 수정 (분석가) <-> 리뷰 (개발자) <-> QA -> 승인 (개발자) -> 릴리즈 (개발자)

사실 이벤트 정의와 관리는 분석가, PM, 개발자를 포함해 누구나 할 수 있는 작업이라 누가 어디까지 해야하는지 R&R 정하기가 정말 어려워요. 그리고 나중에 필요한데 없으면 '왜 누락됐나?'하는 문제의 소지가 되지, 잘한다고 누가 칭찬해주는 업무는 아니거든요. 그러다 보니 제가 총대를 메고 표준화된 프로세스를 만들고 명확하게 R&R을 부여하는게 너무 고된 작업이었어서 기억에 남네요.😂

‍

Q. A/B테스트 설계시, 이벤트 관리에 특히 주의해야하는 점이 있다고요.

 AS-IS와 TO-BE를 비교하려면, 동일선 상에 같은 것을 비교해야해요. A그룹 안에 z 컴포넌트가 B그룹에는 다른 형태로 있을텐데, A그룹과 같은 이벤트를 쓸지 혹은 다르게 정의할지 하는 고민들이 있죠. 동일하게 동작하진 않지만, 기존의 것을 대체하는 것이라면 최대한 이전 것과 같이 쓸 수 있는게 더 좋아요. 신규 기능마다 새롭게 이벤트를 만들 수 있지만, 제품의 복잡성이 증가하면 이벤트간의 중복이 발생할 수도 있어요. 중요한 이벤트인데, 다른 이벤트를 심다가 날라가는 일도 있죠. 영속성을 가지고 데이터가 수집이 되야해요. 테크 기업에서 데이터 공백은 굉장히 위험합니다. 

Q. 이번 <데이터 잘보기 첫걸음> 웨비나 어떤 분들이 들으면 특히 도움이 될까요?

  본인이 만든 프로덕트를 유저들이 어떻게 쓰는지 궁금한 사람 누구나요! 이런 궁금증을 해소하려면 이벤트를 정의하고, 이벤트 수집이 되려면 개발팀에 '잘' 요청해야해요. 

• 개발자와 의사소통을 혼란없이 하고 싶은 사람
• 이벤트 수집이 어떻게 되는지 궁금한 사람
• 어디까지 이벤트 수집이 가능한지 궁금한 사람
  
  

 쇼핑몰에서 특정 상품에 대한 검색은 많지만 고객은 구매하지 않는다고 가정해볼게요. '우리 사이트에서 안 팔아서 못 사는건지' '품절이라서 못 사는 건지' ..이유는 굉장히 다양할 겁니다. last action만 관리하고 있다면 어떨까요? 그래서 검색양, 구매 성공률만 보고 있었다면..🤔..? 우린 문제의 원인을 결코 알 수 없을 겁니다. 

 여러분의 서비스에서 어떤 이벤트를 수집하고 싶으신가요? 그 질문에 대한 답을 이번 웨비나를 통해서 구체화 해봐요! 3월 25일에 뵙겠습니다 :)

‍

‍

👉🏻 Jen님의 <데이터를 잘보기 위한 첫걸음> 웨비나 신청하기