(FASTCAMPUS) 패스트캠퍼스 온라인 'THE RED: 데이터사이언티스트 하용호' 후기 - 강의내용요약 #2

이번 글에서는 이전 편에 이어서 패스트캠퍼스의 온라인 강의 'THE RED: 데이터사이언티스트 하용호'의 강의내용을 요약한 것을 전달 해드리려 합니다. 

 

• 10년이 넘게 지난 현재의 데이터 업계에서 데이터사이언티스트가 하는 일 (#1)
• 데이터 팀을 일구기 위해 가장 먼저해야할 데이터 수집하기, 그리고 팀을 단계별로 발전시켜가기 (이번글)
• 개인의 데이터사이언티스트로써 문제를 찾고 해결하는 법(분석), 비주얼라이제이션과 커뮤니케이션 방법 (#3)

 

이번 편에서는 많은 회사에 입사하게 되면 마주할 데이터 '제대로' 수집하기와 데이터 팀의 발전 단계와 각 단계별 특징에 대해 기술합니다.

 

 

데이터 '제대로' 수집하기

데이터 팀은 회사에 매출에 기여할 데이터 상품을 만드는 것이 목표입니다. 그렇기에 무엇보다도 데이터가 목적에 맞게 잘 수집되고 운영되는 부분이 중요합니다. 하지만, 대부분의 회사에서 데이터는 '1) 없거나', '2) 쓸수 없거나' 인 경우가 많습니다. 

 

 데이터 수집과 관련해서는 '구축하기'와 '운영하기'로 집니다.

 

구축하기

데이터가 '쓸수 없는' 전형적인 형태는 주로 결제데이터는 정산을 위해 중요하기에 잘 남겨지지만, 그 결제로그가 새로운 고객이 발생시킨 것인지, 그 고객은 해당 상품을 구매 시 이벤트를 통해 구입했는지 또는 세일을 적용받아 구매했는지와 같이 분석을 진행하고자 할 때 알 수 없는 경우입니다. 

 

그렇기에, 데이터는 아래와 같은 형식으로 쓸 수 있게 수집하여야 합니다:

 

• 어떻게? 수많은 데이터를 추후에 이어서 어떤 사실을 알 수 있도록 전체를 연결시킬 수 있는 ID를 만들고, 분석 시 연결될 수 있는 데이터 형태로 수집하여야 합니다. Google Analytics, Amplitude, SegmentIO, 클라우드 환경의 SDK(AWS, GCP)와 같은 도구를 사용하거나 직접 구축하여 수집할 수 있습니다. 
• 어디에? AARRR 퍼널을 통과하는 패스에 달아야 합니다. 그리고 또 다른 한 곳은 바로 첫화면입니다. 이 부분에서 강조할 부분은, AARRR은 사실 너무 넓지 않다는 사실입니다. 쇼핑사이트에 가서 구매를 하거나, 음악사이트에서 노래를 듣거나 할 때, 많은 곳을 거쳐가지 않습니다. 사용자는 목적을 달성하기 위해 쓰는(한정된) 기능만 씁니다. 그렇기에 이 쓰는 기능을 개선하는 데 집중해야 합니다.

 

위의 첫화면은 앞에서도 언급된 NUX(New User Experience)와도 관련이 깊습니다. 사실 이 부분에서 데이터만 고집하지 말고 직접 유저를 만나고, 어떻게 사용하는지 오프라인으로 느껴보고 NUX를(특히 서비스 초기에) 개선해야 합니다.

 

간략화하면, 위는 아래 3가지 목표를 위함을 항상 기억해야 합니다:

 

• 방문 / 재방문을 확인할 수 있는 ID 체계 만들기
• 처음 유저가 만나는 N개 페이지의 NUX 개선
• 그리고, 돈으로 연결 되는 path의 개선

728x90

운영하기

새로운 서비스가 개설되고, 사용하지 않는 서비스가 사라지는 것과 같이 로그도 라이프 사이클을 가집니다. 로그를 높은 품질로 잘 수집하는 것이 서비스 개발자의 책임은 아니기에, 사라진 서비스의 데이터가 안들어오는 것을 서비스가 사라지고 한참 뒤에나 깨닫거나, 상태이름이 변경된 사실을 회사 내 많은 사람들이 보는 대쉬보드가 빨갛게 물들고 알게되는 등과 같은 일들이 벌어지게 됩니다. 

 

 

운영 상의 또 다른 어려운 점 하나는, 컨벤션을 일관되게 사용하는 부분입니다. 헤비유저월평균히트상품매출액과 같은 지표가 헤비유저 기준이 변경되며 바뀌고, 헤비유저인 새로운 고객군이 서비스에 추가되었는데 뒤늦게 그 사실을 알고 적용하면서도 바뀌고 등등 다양한 이유로 지표, 용어, 계산법의 정의가 오염됩니다. 

 

 

그렇기에 크게 위 2가지 문제를 해결하기 위해서 사용할 수 있는 방법은 다음과 같습니다:

 

 

• 사내 통합 공용 문서: 로그에 대한 모든 변경사항을 기록하고 보존합니다. 로그와 관련된 모든 사람들이 이 하나의 문서를 보고 커뮤니케이션하고 그 기준으로 삼아 혼동의 여지를 줄입니다.
• 서비스 코드 - 사내 통합 공용 문서 간의 미스매치 발견 시 알람을 보내는 자동화 검증 도구 개발: 사내 통합 공용 문서에는 수집되고 있다고 나와있는데, 서비스 코드 상에서는 사라진 경우(또는 반대)를 사전에 알림 받고 항상 일치할 수 있도록 주기적으로 검증하는 도구를 개발합니다.
• 신규 추가 로그 검수 프로세스: 자동화 도구가 있다면 좋지만, 서비스 개발 전 QA의 확인 이후 서비스가 배포 되듯이, 로그도 개발자와 함께 데이터 팀의 검수 프로세스가 있어야 합니다. 

 

데이터 팀의 발전단계와 각 단계별로 해야할 일들

총 6단계가 있는데, 앞의 3단계가 Passive, 뒤의 3단계가 Active라고 할 수 있습니다. Passive라는 명칭 그대로 앞의 단계에서 데이터 팀은 지원조직으로 남는데요. 하지만 뒤의 단계에서는 지원조직에서 벗어나 데이터 팀자체로 회사의 이익에 중추적인 일을 해가는 팀으로 진화할 수 있습니다.

 

그 분기점에 있는 것이 바로 A/B Testing을 통한 실험가능 여부입니다.

 

앞의 Passive 3단계는 아래와 같이 구성되고, 

LV1: 데이터 확충 + 리포트 수렁	LV2: 대쉬보드 수렁	LV3: 데이터 현업 보급 + 여력 확보
쓸 수 있는 데이터가 없고, 시간을 투자해 수집하여 기획, 영업과 같은 부서의 요청에 매번 리포트를 만드는 시기	반복되는 리포트가 대쉬보드로 변하는 시기 대쉬보드로 리포트를 대체해 시간을 벌고 고급 분석에도 시간을 쓸 수 있게됨 현업의 데이터 직접 접근 요청도 늘게됨	현업의 직접 데이터 접근이 가능해짐(SQL 등) 직접 데이터를 보려는 사람이 늘어남 (그에 따라 요청하는 도구도 발전) 데이터팀이 점점 여력이 생김
	목표설정 여러 개의 분산된 목표보다는 가장 중요한 한 가지 지표(One Metric That Matters)를 찾고 추구해야 합니다. 회사에 이익과 관련이 있을 수록, 갱신주기가 빠르고 발생 건수가 많을 수록, 후행지표보다는 선행지표가, 수동적인 지표보다는 영향을 미칠 수 있는 지표가 좋습니다. 기술적으로는 다양한 지표들과 회사 매출(또는 이익)과의 상관성을 분석하고 위의 기준에 따라 가늠하면서 선택을 하는 것입니다. 예로, 게임회사에서 상관관계를 그려보니 가장 매출과 관련 있는 것이 '얼마나 적극적으로 게임을 하나?'였고, 그 지표가 후행지표였다면, 그 지표를 대리할(또는 상관관계가 높은) 지표를 찾아보고 다시 위의 기준에 따라 비교해 선택하는 것입니다. '하루당 로그인 수', '아이템 구매 수', '채팅수' 등이 있다면 전체 유저 중 일부만 하는 '아이템 구매 수'보다는 '하루당 로그인 수'가 더 좋은 목표지표가 될 수 있을 것이라 판단할 수 있습니다. 너무 어렵게 느껴진다면 보통은 AARRR에서 잡습니다. 그러나 바뀌지 않는 단 한가지 지표는 바로 Retention입니다. 목표설정에 따라 다양한 목표가 등장하고 바뀌어도, 항상 리텐션만은 신경쓰고 유지되고 있는지 꾸준히 체크해야 합니다.

 

 

뒤의 Active 3단계는 아래와 같습니다:

LV1: A/B Testing 시작 + 우리편 확보	LV2: A/B Testing 본격 도입 + 투머치실험	LV3: 데이터 업무의 분권화 + 자동화 + ML
A/B test를 통해 매출에 직접적인 팀으로 변모 마케팅 요소와 같이 간단한 것(푸시메시지 등)에서 기능 테스트와 같은 어려운 것으로 점차 도전 첫 실험과 성공사례로 내부 마케팅이(다른 팀의 협조를 얻기 위해) 중요한 시기	더 구체적이고 어려운 A/B test 요청 증가 실험 수 증가	Data Driven 다양한 일들을 자동화, 최적화(ML) MLOps에 대한 요구
A/B test를 통한 실험은 Growth Hacking의 주요 개념과 많이 결부되어 있습니다. LTV, 고객세그먼트에 따른 각 그룹별 전략, 그리고 한 가지 다시 강조할 부분은 NUX(New User Experience)입니다.  Multi Armed Bandit과 같은 A/B test의 개념 외에도 특별히 중요한 부분은, 사내에 A/B test 기반의 문화를 다지는 일입니다. 첫 성공은 그 성공만큼이나 사내 마케팅을 통해 알리고 데이터 팀을 지원해줄 다른 팀을 확보해야 합니다.		ML과 관련해서는 먼저 '이것이 적정기술인가?'하는 질문에 대해 많은 고민 후 결정하는 것이 좋습니다. 많은 비용과 시간이 드는 ML보다 간단한 룰베이스 추천이 가성비로 볼 때 더욱 좋은 판단일 수 있기 때문입니다. ML이 필요하다면, 너무 많은 알고리즘보다는 잘 쓸 수 있는 지도/비지도학습 계열 1개 정도씩(GBM과 DBScan, LightScan 추천) 집중하고 있다면 업무에는 충분한 성과를 낼 수 있다고 합니다. 그리고 마지막으로는 다른 부서의 기대관리입니다.

 

우리 데이터 팀은 어떤 단계에 있는가?에 대한 답을 찾고 계신다면, 아래의 단계에 따른 업무 변화를 기준으로 자문해 볼 수 있을 것 같습니다. 1회성 분석이 충분히 자동화 되었는지, 타팀의 데이터 관련 역량이 직접 분석을 이끌만큼 충분히 따라와 주고 있는지 등이 될 것 같네요.

 

데이터 팀의 단계별 성장에 따른 변화

 

다음 글(#3)에서는 '개인의 데이터사이언티스트로써 문제를 찾고 해결하는 법(분석), 비주얼라이제이션과 커뮤니케이션 방법'에 대해 전달드리도록 하겠습니다. :)