학습 주제
오늘은 데이터 기반으로 어떻게 의사 결정을 해야하는지에 대해서 배웠습니다. 또한 데이터 조직이 일주일 동안 무엇을 하는지를 알고 선행 지표와 후행지표간의 연관성을 배웠고 마지막으로 실습을 통해 차트를 만들어보았습니다.
주요 메모 사항 소개
데이터 문해력 퀴즈 리뷰
빅데이터 데이터베이스 뿐만아니라 프로덕션 데이터베이스를 웨어하우스로 사용할 수 있다.
ETL은 데이터 파이프라인이라고 부르고 이를 구현하고 관리하는 사람이 데이터 엔지니어이고 결과는 데이터 웨어하우스에 테이블 형태로 나오게 된다.
Airflow: 오픈소스기반의 에어비엔비에서 시작된 소프트웨어 (스케줄러로 가장 많이 사용된다.)
ETL: 데이터 엔지니어가 데이터 시스템 밖에 있는 데이터 소스에서 데이터를 추출하고 변환한 다음 이를 데이터 웨어하우스에 테이블 형태로 적재하는 것
ELT: 데이터 시스템에 적재된 데이터를 다시 조합해 새로운 데이터를 만들어 내는 것 (ELT를 할 때 많이 사용하는 툴: DBT)
데이터 일을 하는 사람들이 꼭 알아야할 기술은 SQL이다.
A/B 테스트는 어떤 새로운 기능을 만들었을 때 그 기능이 정말 의미가 있는지 실제 사용자들에게 노출시켜서 판단하는 것이다.(50%는 기존 기능, 50%는 새로운 기능을 노출하고 중요 지표를 통해 기준으로 비교한다)
데이터 기반 의사결정이란?
두가지 형태의 데이터 기반 의사 결정
Data Driven Decision(데이터 기반 의사 결정) vs Data Informed Decision(데이터 참고 의사 결정)
데이터 기반으로 간다는 것이 꼭 좋은 것만은 아니다.(대시보드가 많아지면 무엇을 보고 결정해야할지 모르게 된다.)
데이터에서 인사이트 찾기
조직 회사 프로젝트에서 성공을 결정하는 지표를 정의한 다음, 그것을 대시보드 위에서 시각화해 의사결정을 하는데 도움을 받는다.
데이터를 보고 개선할 부분을 파악하고 가설을 세워 A/B 테스트 형태로 실제 검증을 해본다.
데이터 분석 케이스들 살펴보기
고객 이탈률 혹은 잔존률 같은 경우 어떠한 기준으로 고객을 나눠보느냐가 중요해지는데 그때 많이 사용하는 것이 코호트(Cohort)이다.
코호트란 동일한 특성을 가지는 고객 그룹이다.(코호트로 가장 많이 사용하는 것은 처음 우리 서비스의 회원이된 년도와 월이다.)
마케팅 쪽에서는 어떠한 마케팅 채널을 통해 우리 서비스를 오래동안 쓰는지 분석을 많이한다.
고객 이탈률
데이터 일을 할 때 보는 것
- 어떤 사용자들이 계속 서비스를 사용하는가
- 유료 고객들의 이탈률이 얼마나 되는가
이탈하는 이유를 알면 서비스의 문제점을 해결할 수 있다.
돈을 내는 고객들이 계속 서비스를 사용하는지 꼭 살펴봐야한다.
마케팅 기여도 분석
디지털 마케팅은 어떠한 채널에 어떤한 형태의 캠페인을 했을 때 효율적인지 찾는 것이 중요하다. 따라서 데이터팀이 중요하다.
고객 불만과 이탈률간의 관계
오히려 서비스에 관심이 많은 사람들이 불만을 직접적으로 표현하고 서비스가 정말 마음에 안드는 사람들은 기능개선을 요구하거나 불만을 이야기하는 것이 아니라 그냥 그만두는 경우가 많다.
Survivorship Bias: 내 눈에 보이는 것만 문제라고 생각하고 해결하려는 것(불만을 이야기하는 사람을 분석하는 것이 아니라 그냥 그만두는 사람들이 더 큰 문제인 것을 파악해야한다.)
Confirmation Bias: 내가 가지고 있는 믿음을 더 강하게 밀어주는 증거들만 채택하는 것(형사들이 수사를 할 때 범죄자라고 생각하는 사람들만 대상으로 수사를 깊게 들어가는 것)
내가 가정을 하고 가설을 가지고 검증을 할 때 내 가설에서 생각하는 문제보다 더 큰 문제가 있는지 다시 생각하보는 버릇을 가지는 것이 중요하다.
데이터 분석가의 역할
좋은 데이터 분석가의 사고방식: 반복적인 질문들을 대시보드로 만들어서 내가 답을 하지 않아도 궁금한 사람들이 대시보드만 보고 원하는 답을 얻을 수 있게 해주는 것
의사결정권자들이 데이터기반 결정을 내릴 수 있도록 교육을 하는 것도 인정받는 데이터 분석가가 되기 위한 포인트이다.
조직 구조의 중요성과 트렌드
3가지 데이터 팀 조직 구조
중앙 집중 구조: 모든 데이터팀원들(데이터 엔지니어, 데이터 분석가, 데이터 과학자)이 모두 하나의 팀에 속한 모델
분산 구조: 특히 데이터 분석가나 데이터 과학자가 중앙 조직에 있는 것이 아니라 현업 조직에 밑에 소속이 되어 일을 하는 것(보통 인프라를 담당하는 데이터 엔지니어는 중앙 조직에 있다.)
하이브리드 구조: 모든 데이터 조직원들이 한 팀 밑에 소속되지만 일을 할 때는 현업 부서와 같이 일을 하는 구조
중앙 집중 구조
장점: 데이터팀원들 간의 협업이 늘어나고 데이터팀의 구성원들의 만족도가 올라간다.
단점: 현업 부서의 만족도는 상대적으로 떨어진다.(모든 일의 우선순위는 데이터팀 내에서 자체적으로 정하면서 현업 부서가 원하는 우선순위가 결정될 수도 있고 응답속도가 빠르지 않다. 즉 데이터팀의 팀장에 따라 현업 부서의 만족도를 결정한다.)
분산 구조
장점: 현업 부서의 만족도가 올라간다.
단점: 데이터 일을 하는 사람들은 지식과 경험을 공유가 힘들어지고 팀을 이루어 커리어에 방향성을 잃을 수 있다. 경험과 데이터가 공유가 되지 않아 부서별로 비슷한 일들을 중복해서 하게 될 확률이 높아진다.
팀 별로 별도의 데이터 조직을 운영하거나 데이터인력이 있다보니 회사 전체적으로 데이터에 관한 전략이나 방향이 명확하지 않아 각자가 데이터 전략을 세울 가능성이 있다.
데이터 공유를 못할 확률이 높다.
중앙집중과 분산의 하이브리드 모델
데이터팀에 소속되어 있지만 데이터팀의 인력들이 파견 형태로 현업 부서와 일을 하는 것
재배치를 통해 다양한 경험을 할 수 있다.
데이터 메쉬: 조직별로 데이터 시스템을 별도로 구성해 속도와 효율을 높여 각 조직이 가지고 있는 데이터가 무엇이있는지 카탈로그를 만들어 쉽게 찾을 수 있게하는 것(분산 데이터 아키텍처)
마이크로서비스: 복잡도를 줄이고 문제가 발생했을 때 피해를 줄일 수 있다.
Service Registry: 어떤 마이크로서비스들이 있는지 기록하는 저장소(이를 통해 개발시간을 단축시킬 수 있다.)
데이터 카탈로그: 각 조직이 가지고 있는 데이터가 무엇인지 기록하는 것(마이크로서비스에서 데이터 카탈로그는 Service Registry이다.)
데이터 조직의 일주일 살펴보기
데이터팀도 애자일 방식으로 2주씩 나눠서 개발을 한다.
월요일
데이터에 문제가 있을 경우 이유가 무엇인지 파악하고 그 데이터를 기다리고 있는 다른 팀들에게 알려주는 활동이 필요하다.(ETL과 관계된 다양한 이슈들을 해결할 전담 인력을 배치한다.)
스프린트 관리: 무엇을 해야하고 어떤 것이 진행중이고 끝났는지 파악한다.(JIRA를 많이 사용한다.)
화요일
외부 팀과 협업을 하는 경우 미팅을 해서 프로젝트 진행상황이나 문제 해결을 논의한다.
수요일/목요일
중요 지표 리뷰 미팅에서는 매출이 어떻게 바뀌고 있고 유료 고객의 비율이 어떻게 바뀌고 있고 어떤 A/B 테스트가 진행중이고 상황이 어떤지 새로운 A/B 테스트를 해야하는지 미팅한다.
금요일
지표 KPI에 관해 짚어보고 채용과 관계된 이야기를 한다.
사후 점검 미팅을 통해 동일한 문제가 생기는 것을 막는다.
좋은 지표(KPI)란?
KPI는 중요 지표이다.
KPI는 어떤 시점에 숫자만 보는 것이 아니라 시간을 두고 어떻게 변화하는지 보는 것이 일반적이다. 따라서 대시보드 위에서 시각화하는 것이 필요하다.
성공인지 실패인지 판단하기위해 KPI 혹은 지표를 사용한다.
지표(Metrics)
모든 지표가 KPI일 수는 없다. 목표에 성공이나 진행상황을 나타내주는 정량인 숫자가 필요하다면 그것이 지표가 된다.
프로젝트마다 지표가 있을 수 있다.
KPI는 아니지만 참고해야하는 중요한 지표가 있을 수 있다.
지표는 중요도에 따라 KPI일 수도 일반 지표일 수도 있다.
회사 전체의 KPI가 아니더라도 팀이나 개인이 가지고 있는 중요한 목표가 있다면 그것의 성공실패 여부나 진행상황 여부를 알려주는 지표를 만드는 것이 중요하다. 이것이 데이터 문해력의 시작점이다.
KPI 기준
KPI 자체가 어떠한 가치를 나타내야한다.(회원 등록 수는 가치가 없다 - 등록한 회원이 모두 서비스를 사용하지 않기 때문이다.)
좋은 지표는 현재 가치만 이야기하는 것이 아니라 계속 재발생되는 가치인지 판단할 수 있다.(월간 구독형태로 서비스를 한다면 재구매율의 지표)
후행지표: 모든 일이 벌어지고나서 최종적인 결과물을 보여주는 지표(중요한 선행지표는 별도로 모니터링 할 필요가 있다.)
서비스를 피드백 받을 수 있어야한다.(문제가 될만한 것을 확인해본다.)
KPI와 선행/후행 지표 예
Working Backwards
아마존은 일반적으로 새로운 서비스를 출시할 때 일반적인 제품 개발 방법론과는 반대 방향으로 한다.
KPI를 계속 측정하는 것도 중요하지만 이것에 영향을 주는 선행지표(Input Metrics)들이 무엇인지 파악하고 개선하는 것이 더 중요하다. 선행지표가 개선이 되야 후행지표에 좋은 영향을 줄 수 있다.
Input Metrics: 선행 지표
Output Metrics: 후행 지표(보통 KPI는 후행 지표)
KPI와 선행 지표 예
기존 고객 매출과 새로운 고객 매출의 비율이 잘 맞아야한다.
선행 지표를 잘 찾아내고 관찰하는 것이 회사의 중요 지표를 유지하는데 큰 도움이 된다.
두 가지 중요한 KPI
매출 vs. 서비스 사용 고객수 (DAU, WAU, MAU)
DAU: 일간 서비스 사용 고객수
WAU: 주간 서비스 사용 고객수
MAU: 월간 서비스 사용 고객수
어떠한 행동을 했을 때 서비스 사용자인지 정의를 잘해야한다.
네트워크 현상이 중요한 도메인: 페이스북과 같이 사람이 많아야 할 수 있는 비즈니스
시각화 대시보드 툴 소개
시각화 툴을 통해 사람들이 중요한 정보를 쉽게 볼 수 있게 해준다.
KPI나 지표를 시간에 흐름에 따라 어떻게 변화나는지 보여주는 것이 일반적이다.
중요한 지표가 무엇인지 명확히 정하고 이를 데이터 기반으로 계산해서 언제든지 볼 수 있도록 하는 것이 중요하다.
Looker
대시보드를 만들거나 만들어놓은 대시보드를 수정할 수 있다.
Tableau
무료버전이 존재한다.
Looker가 해메면서 다시 원래 위치를 유지하고있다.
어떤 시각화 툴을 선택할 것인가?
Looker보다 Tableau가 더 좋다.
대시보드를 만들 줄 알아야한다. 대시보드를 사용하는 사람이 대시보드 개발자에게 많은 요구를 하지 않고 본인이 필요한대로 다양하게 분석을 하거나, 부족한 기능을 추가를 할 수 있도록 하는 것이 좋다.
대시보드들이 사용하기 쉬워야 데이터 기반 의사결정을 하거나 직접 대시보드를 만들거나 수정할 수 있다.(데이터 민주화, 데이터 탈중앙화)
그러나 많은 대시보드를 만들면 잘못된 대시보드를 만들 확률도 높아지고, 사람들이 어느 대시보드를 봐야하는지 혼란을 줄 수 있다. 따라서 중요한 지표인 경우 몇개의 공식 대시보드를 만들고 그것들만 보고 결정하는 것이 좋다. 본인이 직접 만든 것은 참고용으로만 사용한다.
[실습] 지표 정의하고 차트 만들어보기
Tableau 제품군 소개
Tableau Desktop: 웹 브라우저에서도 사용가능하다.
Tableau Server: Tableau Desktop으로 만든 대시보드를 호스팅 해주는 환경이다. 이를 통해 다양한 대시보드들을 공유하거나 접근권한을 설정해줄 수 있다.
Tableau Online: 보통 Tableau Server보다 Tableau Online을 요즘 많이 사용한다.
Tableau Prep
Tableau Public
Tableau Moblie: 대시보드를 모바일 환경에서 쉽게 볼 수 있게 해주는 어플리케이션이다.
Tableau Public 소개
제약점: 데이터 웨어하우스와 같은 관계형 DB를 벡엔드에 연결해서 데이터를 테이블 형태로 다운로드해 시각화하지만 Tableau Public은 무조건 파일을 업로드해 정적인 데이터를 기반으로 대시보드를 만든다.
전체 과정 설명
한 달에 몇 명의 사용자가 방문하는지 시각화(사용자가 여러번 방문해도 한 번으로 취급)
X축(columns): 시간(dimension - ts필드로 계산)
ts : time stamp
Y축(rows): 실제로 알고 싶은 지표(measure)
채널에 따라 그래프를 그려본다.
공부하며 어려웠던 내용
매출이나 서비스 사용 고객수뿐만 아니라 KPI에 해당하는 다양한 지표에는 무엇이 있는지 궁금했습니다. 또한 Survivorship Bias와 Confirmation Bias를 해결하는 방법이나 요령에는 무엇이 있는지 궁금했습니다.
