HomeAbout
Metric
지표 모델링 모험
조우진
April 24, 2022
3 min

Table Of Contents

01
들어가기 전에
02
Welcome to the Data Analytics World
03
떠나보자 지표 모델링의 세계
04
V1: 단순한 것이 최고이다.
05
V2: 다양한 요구사항을 미리 반영하자.
06
V3: 지표란 무엇인가? 본질을 이해하자.
07
V4는 없을까?

들어가기 전에

안녕하세요, 이 글은 필자가 데이터 분석 업무를 하면서 실제 겪었던 일을 회상하며 정리한 글입니다. 글에서 다루는 상황은 실제 업무와는 무관하도록 각색하였습니다.


Welcome to the Data Analytics World

김코딩씨는 7년차 개발자입니다.

일에 대한 흥미가 예전 같지 않던 김코딩 씨는 얼마 전부터 데이터를 다루는 일에 관심이 생겼습니다. 때마침 사내에서 데이터 분석 환경 구축 담당자를 찾는 것을 발견했습니다! 김코딩씨는 관심 갖던 데이터 업무를 경험할 수 있으리란 기대와 함께 데이터 분석의 세계에 발을 내딛습니다.


떠나보자 지표 모델링의 세계

기존 플랫폼 사용자를 믿고 시작한 프로젝트는 K-유튜브(?)로 유튜브에 대항할 새로운 동영상 플랫폼입니다. 출시한 지 반년이 지났지만 아쉽게도 사용자의 반응은 뜨겁지 않군요. 늦은 감이 있지만 경영진이 데이터에 기반한 의사결정의 필요성을 느끼고 데이터 분석 환경을 만들기로 한 것입니다.

김코딩씨가 합류하고 보니 지금까지는 KPI 보고를 위해서 주기적으로 개발팀에서 통계업무의 일환으로 지표를 제공하고 있었습니다. 김코딩씨가 해야 할 업무는 바로 기존의 지표를 Product Owner를 포함한 이해관계자가 매일 볼 수 있도록 하는 것이었습니다.


현재 관리중인 지표는 다음과 같은 것들이었습니다.

  • Active User
  • 사용자당 비디오 컨텐츠 시청 수
  • 서비스 체류 시간
  • Weekly Retention
  • 컨텐츠 공유 수

담당자가 요청한 지표는 김코딩씨가 개발업무 하면서 늘 모니터링하던 서버에서 발생하는 시계열 데이터와 다르게 느껴지지 않았습니다. 그의 머릿속엔 자연스럽게 Grafana와 같이 본인에게 익숙한 대시보드와 PostgreSQL 같은 RDB 정도가 바로 떠올랐습니다.

Grafana Time-series chart Example
https://grafana.com/docs/grafana/latest/visualizations/time-series


V1: 단순한 것이 최고이다.

김코딩씨는 빠르게 구상했던 설계 내용을 글로 옮겨봅니다.

  • 분석에서 사용하는 지표는 시계열 데이터의 특성을 갖는다.
  • 집계단위는 보통 일간,주간,월간이고 아무리 빨라도 시간 단위이다.
  • 즉, 적재되는 데이터의 양이 많지 않다.
  • 보통의 RDB에 date, metric_name, metric_value정도의 컬럼을 필수로 하는 테이블 설계로 충분해 보인다.

작성한 내용을 바탕으로 김코딩 씨는 테이블을 설계합니다. 기존에 개발팀에서 인계받은 쿼리를 수정한 뒤 Airflow를 통해서 KPI 집계 Task를 자동화했습니다. 데이터는 간단히 다음과 같이 적재됩니다.

datemetric_namemetric_value
2022-04-11active_user12311
2022-04-12active_user14549
2022-04-13active_user13653

자 이제, 김코딩씨는 서비스의 성장을 위해 Deep Dive 한 분석에 힘을 쏟고자 합니다. 하지만… KPI를 매일 볼 수 있도록 담당자에게 제공하자, 사람들의 요구사항은 KPI 넘어 다른 것들을 묻기 시작합니다.

  • DAU를 device, 접속 국가로 볼 수 없나요?
  • 체류시간을 각 화면 별로 나눠서도 보고 싶어요.
  • 지난달 신규 버전 릴리즈 후 주간 리텐션이 떨어졌어요. 사용자를 세분화해서 보고싶어요.

처음 몇 건은 임시방편으로 ad-hoc하게 대응합니다. 그러나 요청사항은 시간이 갈수록 폭증하기 시작합니다. 김코딩씨는 아쉽지만, 현재 적재하고 있는 지표에 대해서 새롭게 설계할 필요를 느끼게 됩니다.

폭증하는 요구사항을
V1모델링의 결과로 대응할 수 없는 요구사항을 줄 세워 하나씩 처리할 수 밖에 없다.


V2: 다양한 요구사항을 미리 반영하자.

V1의 문제점은 주어진 요구사항만을 고려해서 지표를 쌓다 보니 추가적인 요구사항에 대응할 수 없다는 점입니다. ad-hoc 요청사항을 복기해보니, 기존의 KPI 집계 시 같이 추출할 수 있는 지표가 많다는 것을 알았습니다. 가급적 자주 사용하고 모니터링이 필요한 지표를 최대한 미리 뽑아두는 방식으로 설계를 바꾸었습니다.

바뀐 설계의 가장 큰 차이점은 테이블을 여러개로 만드는 일이었습니다. 예를 들면, 화면별 체류시간을 위해서는 screen이란 컬럼이 필요하지만, DAU 집계에서는 굳이 screen이 필요 없기 때문에 다음과 같이 테이블을 분리했습니다.

datedevicecountrydau
2022-04-11DesktopKR12311
2022-04-12IOSKR14549
2022-04-13IOSCN13653

k-tube.active_user_daily


datedevicecountrypagespent_time_sec
2022-04-11DesktopKRpage-a8730412
2022-04-12IOSKRpage-b9230991
2022-04-13IOSCNpage-a5839932

k-tube.user_spent_time_daily

그동안의 ad-hoc 추출 업무를 하면서 어느새 도메인에 대한 이해도가 높아지고 쿼리 머신(?)으로 성정한 덕분인지 V2 작업도 그리 어렵지 않았습니다. 하지만 행복한 시간은 그리 오래가지 않았습니다. V2도 여전히 새로운 문제들을 안고 있었습니다.

Messy Room
https://pixabay.com/vectors/messy-bedroom-home-bed-room-1459688/

다양한 요청사항에 대응하려다 보니 하나, 둘 씩 테이블의 수와 관리해야 할 지표가 점점 늘어났습니다. 지표를 다양하게 미리 쌓아놓은 덕분에 요청 사항에 좀 더 빠르게 대응할 수 있었지만, 여전히 뽑아놓은 지표를 찾아서 제공하는 중개인 역할의 부담도 줄지 않았습니다. 집계 쿼리 자체의 정합성, raw 데이터의 퀄리티 체크 등의 문제도 생겨나기 시작했습니다.

이쯤에서 김코딩은 충분히 고민하지 않고 관성으로 업무했던 자신을 되돌아보게 됩니다. 다시금 새로운 결단의 시기가 온 것입니다. 그래 갈아엎자!


V3: 지표란 무엇인가? 본질을 이해하자.

김코딩은 익숙한 방식을 내려놓고 조사를 하기 시작합니다. 이 분야에도 ‘수학의 정석’ 같은 도서가 있다는 사실과 Star, Snowflake 스키마와 같은 설계 방식도 배웁니다. 이제, 리서치의 내용을 바탕으로 김코딩은 지표의 개념을 자신의 언어로 소화합니다.

지표(Metric)란 무엇인가?

데이터를 활용하여 목적에 맞게 정량적(quantitative)으로 측정(measure)한 것

개념의 정의에서 한 발 더 나아가 그동안 쿼리 머신으로 작업했던 업무를 밑거름 삼아 지표를 다음과 같아 기술적으로 모델링합니다.

지표(Metric)은 다음의 요소로 이루어진다.

  • 행위(Action): 지표를 특정하는 정의
  • 측정(Measure): 행위를 어떻게 측정할 것인지
  • 축(Dimension): 지표를 구체화하는 속성
  • 제약조건(Condition): 행위에 추가되는 조건

이해를 돕기 위해 이 모델을 구체적으로 적용해 봅니다.

먼저 각 요소 중 행위측정이 지표를 구성하는 최소 단위가 됩니다. 서비스의 DAU를 예로 살펴봅시다. 각 서비스의 Activation행위가 되고, 이 행위를 발생시킨 고유한 사용자 수를 측정한 것이 DAU가 됩니다.

필요한 경우 축을 통해서 지표를 세분화할 수 있습니다. 이번엔 디바이스별 일별 컨텐츠 소비 수를 지표로 모델링해봅시다. 행위는 사용자의 컨텐츠 소비가 되고 측정은 이를 Count한 것이 됩니다. 축은 기본적으로 시간 단위인 Day와 함게 Device로 표현할 수 있습니다.

여기서 한가지 V3 모델의 이점이 생깁니다. 디바이스별 일별 컨텐츠 소비 수라는 긴 지표명을 DSL(Domain Specific Language)로 표현할 수도 있습니다.

다음은 행위는 A, 측정은 M, 축은 D로 표현하고, 각 정의는 -으로 연결, 정의의 값이 여러개 일때는 | 사용이란 규칙을 임의로 정했을 때 디바이스별 일별 컨텐츠 소비 수를 DSL로 표현한 것입니다.

A-컨텐츠소비,M-수,D-Day|Device

V3 모델에서는 지표를 다룰 때 발생할 수 있는 정의의 불명확함도 사라지게 됩니다.

좀 더 복잡한 사례로 컨텐츠의 전환율인 CTR(Clickthrough rate)을 보겠습니다. CTR은 다음의 두 개의 지표로부터 파생(derived)하여 Click/Impression으로 계산된 지표로 정의할 수 있습니다.

  • 행위: Impression / 측정: Count / 축: Page A => Impression Count
  • 행위: Click / 측정: Count / 축: Page A => Click Count

CTR외에 다른 복잡한 사례에도 축과 제약조건을 사용하면 대부분의 지표를 모두 모델링할 수 있습니다.

이제 김코딩씨는 새롭게 정의한 V3 모델은 이해관계자에게 전파합니다. 표준화된 지표의 정의를 통해서 분석가나 개발자가 아니라도 손 쉽게 지표에 직접 접근할 수 있는 형태가 되었습니다.


V4는 없을까?

김코딩에서 현실의 필자로 돌아오겠습니다. 저는 이 글에서 설명한 V3 모델에 엔지니어링, 데이터 거버넌스 요소를 더하여 실무에서 지표를 다루고 있습니다.

필자는 유용한 데이터 웨어하우스의 구축이 데이터 민주화의 첫걸음이라는 생각을 갖고 있습니다. 부족하지만 계속해서 더 좋은 방법을 고민하고 있습니다. 관련해서 의견이나 제안은 필자에게 큰 도움이 됩니다

더 나은 데이터 분석 환경을 찾아 떠나는 모두의 여정에 축복이 임하길!


Tags

#Metric#Analytics Engineering

Share


Related Posts

Carrying Capacity 심화편
2022-07-17
3 min
© 2023, All Rights Reserved.
Powered By

Quick Links

About UsOfficial Page

Social Media