신뢰할 수 있는 지표 만들기
💬 이 글의 원문은 당근 테크 블로그에 업로드 된 ‘신뢰할 수 있는 지표 만들기’ 입니다. 
안녕하세요. 당근마켓 데이터 가치화 팀에서 Software Engineer, Data로 일하고 있는 Henry예요. 당근마켓 데이터 가치화팀이 지표 관련해서 어떠한 문제들에 직면했고, 어떻게 해결해 가고 있는지 소개해 드리려고 해요.
지표란 무엇이고, 우린 왜 지표를 볼까요?
데이터 분석이나 비즈니스 측면에서 지표를 설명하자면, 성과를 측정하고 평가하기 위한 측정 항목이에요. 따라서 지표를 본다는 것은 팀, 기업의 목표나 전략이 있고 그 목표가 어떤 성과를 달성하고 있는지 파악한다는 것을 뜻해요. 지표를 기반으로 하는 팀은 성과에 대해 잘 이해하게 되고, 제품이나 서비스 최적화를 통해 목표를 달성하는 방향으로 의사 결정할 수 있게 돼요. 이처럼 신뢰할 수 있는 지표를 보는 것은 제품을 만드는 데 중요한 역할을 해요.
하지만 기업이 성장하면서 구성원의 수, 데이터양이 커지고 복잡도도 올라가게 되면, 그에 따라 지표의 신뢰성이 떨어지는 경우가 종종 발생해요. 당근마켓도 단기간 안에 크게 성장한 만큼 지표의 신뢰성 관련한 문제들이 발생했는데, 데이터 가치화 팀에서 이 문제를 어떻게 해결하려고 시도했는지 얘기해 보려고 해요.
지표를 볼 때 어떤 문제점들이 올바른 의사결정을 방해할까요?
아래와 같은 구성원들의 목소리를 들어본 적이 있다면 지표가 신뢰될 수 있는 방법으로 관리되고 계산이 되는지 확인을 해봐야 하는 상태에요.
“A 대시보드와 B 대시보드에 있는 지표 값이 다른데 어떤 값을 봐야 하나요?”
“이 지표의 정의는 어떻게 되나요? 이 지표가 어떻게 계산되는지 아시는 분이 계신가요? @data”
“4월에 봤을 때와 지금 7월에 봤을 때와 지표 값이 달라진 것 같은데 확인해 주실 수 있을까요?”
“3월 17일부터 지표 값이 갑자기 급증했는데 왜 그렇게 된 건가요?”
이러한 목소리가 들려온다면 지표의 정의부터 계산까지 프로세스 관리가 안 되고 있다는 것이고, 대다수의 구성원에게 지표가 만들어지는 과정을 알아내기도 어렵고 이해하기도 어려워서 블랙박스와 같다고 볼 수 있어요. 그리고 이는 곧 아래의 문제점들이 있다는 것을 의미하기도 해요
같은 지표에 대해 팀마다 다른 값을 보고 있음
지표의 정의나, 지표가 계산되는 로직을 알기가 어려움
지표가 신뢰할 수 없는 형태로 계산됨
지표가 중간에 값이 변경되었을 때 그 이유를 파악하기 어려움
이처럼 팀마다 지표를 다르게 해석하고, 지표를 각자만의 방식으로 계산하고 있을 가능성이 있어요. 각 팀이 해석한 지표에 대한 정의나 계산 방식이 잘 공유되지 않을 가능성도 있고요. 이러면 다른 팀에서 같은 지표를 중복으로 만들 수 있게 되고, 이는 팀 간 협업을 할 때 혹은 전사 단위의 의사결정을 할 때 커뮤니케이션 비용으로 이어져요.
예를 들어, 중고거래 게시글 등록 수 지표를 측정할 때 A 팀은 기간 내 삭제된 중고거래 게시글 수를 포함해서 측정하고, B 팀은 기간 내 삭제된 중고거래 게시글은 제외한 수를 측정 기준으로 삼을 수도 있어요. A 팀과 B 팀이 중고거래 게시글 등록 수 라는 이름의 같은 지표를 보지만 실제로는 다른 값을 보게 되는 거예요. 마치 각자가 여러 다른 언어로 얘기하는 것과 비슷해요.
지표의 신뢰성을 떨어트리는 문제 결국 잘못된 의사결정으로 이어질 수 있고, 커뮤니케이션 비용으로 인한 의사결정 iteration의 속도를 늦추게 될 수도 있어요. 이러한 문제들이 반복되면 데이터 조직, 더 나아가 데이터 기반 의사결정 전체에 대한 불신으로 이어질 수 있고요. 그렇기 때문에 지표를 올바른 방식으로 정의하고, 계산하고, 전사가 지표를 통일된 기준으로 바라보게 하는 것, 궁극적으로 팀과 회사가 데이터 기반의 신뢰할 수 있는 의사결정을 하게 하는 것이 중요해요.
신뢰할 수 있는 지표 만들기
당근마켓 내에서도 지표의 신뢰성이 저해되고 있는 건 아닌지 생각해 볼 만한 구성원들의 목소리들이 들리기 시작했어요. 데이터 가치화팀에서는 이러한 현상을 파악했고, 이대로 둔다면 당근마켓이 앞으로 더 큰 성장을 하는 데 있어서 데이터 및 지표가 방해 요소가 될 것이라고 판단했어요.
1. 신뢰할 수 있는 지표 정의
가장 먼저 현재 상황을 파악하기 위해 전사에서 중요하게 보고 있는 지표들에 대한 정의와 지표가 계산되고 있던 로직들을 하나의 문서로 모았어요. 지표들을 모으면서 보니 지금까지는 팀에서 지표를 관리하고 있었기 때문에 지표의 스키마나 디멘션 정보가 다른 경우가 많이 있었고, 지표를 계산하는 로직도 BigQuery 예약 쿼리나 자체 통계 파이프라인 등에 산재되어있어 계산되는 로직도 조금씩 달랐어요.
그 때문에 지표가 정확히 어떻게 계산되는지 알기 어려웠고, 지표를 개발한 오너가 누구인지에 대한 추적도 어려웠어요. 지표 관련 질문이 있을 때 알음알음 여러 팀에 문의하며 알아내야 하는 문제도 있었고요.
산재되어있던 지표들에 대한 정보를 문서로 모은 이후에는 신뢰할 수 있는 형태의 지표로 정의하기 위해 다음과 같은 작업을 했어요.
지표의 정의와 로직을 한 곳에서만 정의하기
먼저 문서로 정리한 각 지표에 대한 정의와 비즈니스 로직을 다시 확인해서 정의에 대한 cross check을 했고, 필요한 경우에 지표의 정의와 로직을 수정했어요. 이 작업을 거쳐 지표들이 다시 한번 정리가 된 이후에는 해당 내용을 코드로 다시 옮겼어요.
코드로 지표를 관리하게 됨으로써 하나의 중앙화된 저장소에서 지표들을 관리 및 모니터링 할 수 있게 되었고 지표의 source of truth를 만들 수 있게 되었어요. 지표를 추가할 때 코드로 작성하고 리뷰를 받아야 하므로 지표에 대한 정의나 로직을 다른 구성원들에게 확인받을 수 있게 되었어요. 이 과정 중에 지표에 대해 더 고민을 해보고, 모두가 이해할 만한 지표를 만들 수 있었어요.
지표의 오너와 도메인 지정하기
지표를 정의할 때 지표의 오너와 도메인을 지정해서 추후에 해당 지표에 대해 질문이 있을 때 오너를 쉽게 찾을 수 있도록 metadata들도 포함했어요.
지표 로직 변화에 따른 지표 버저닝
지표를 개발하고 나서 시간이 지남에 따라 사용되는 원본 데이터 소스나, 지표의 기준이 변경하는 경우가 있어요. 이 변경 사항으로 인해 지표의 값이 달라질 수 있기 때문에 변경 사항을 잘 기록하는 것이 중요하다고 생각했어요. 그래서 이러한 이력들도 지표 정보에서 확인할 수 있도록 했어요.
# 예시
number_of_active_users:
  description: "Active User의 수"
  owner: "someone@daangn.com"
  domains: ["common"] # 도메인 정보
  rollup_dimensions: ["region", "platform", "service"] # 지표의 롤업 디멘션 ex) platform 롤업 디멘션이 있다면 ios/android/전체별로 지표의 값을 볼 수 있음
  dependencies: ["wait_a_db_sync", "wait_b_pipeline_sync"] # 지표가 계산되려면 미리 적재되어야 하는 의존성
  supported_countries: ["kr", "jp"]
  time_grains: ["daily", "weekly", "monthly"]
  versions:
    - version: "v1"
	started_at: "2020-01-01"
	ended_at: "2021-05-31"
    - version: "v2"
	started_at: "2021-06-01"
# v2/number_of_active_users.yaml 예시
user_action: | # 유저의 행동 정의
    SELECT
	...
	event_id,
	user_id,
	platform
	...
    FROM <데이터 소스>
    WHERE DATE(_PARTITIONTIME) BETWEEN <시작 시간> AND <끝 시간> # data ingestion time
	AND DATE(event_time) BETWEEN <시작 시간> AND <끝 시간> # event time
	<그 외 필요한 필터 조건들>

metric_calculation: # 지표의 계산 방식
    COUNT(DISTINCT event_id)
2. 신뢰할 수 있는 지표 계산
지표에 대한 정의와 비즈니스 로직을 문서로 모으면서 보니 기존 지표들이 계산된 방식에도 몇몇 문제점이 있었어요.
지표를 계산할 때 사용되는 앞단의 데이터 소스에 오류가 발생해도 기존 지표는 그대로 계산이 되어서 지표 값이 맞지 않는 경우가 있었어요
지표 계산하는 스케줄링 쿼리가 실패해도 모니터링이 잘 안되어서 실패한 걸 인지하지 못한 경우가 있었어요
매번 전체 기간에 대해 계산해서 과거의 지표 값이 달라지는 경우가 있었어요
CURRENT_DATE와 같은 구문을 사용해서 지표를 특정 날짜에 대해 다시 계산했을 때 다른 값이 나오게 돼서, 멱등성*이 보장되지 않은 경우가 있었어요
멱등성: 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질
이 외에도 상대적으로 마이너한 문제이지만 스키마나 디멘션 정보가 지표마다 달라서 복잡성이 올라가는 경우, 쿼리 자체가 너무 길어서 로직을 파악하기 어려운 경우 등이 있었어요.
지표의 계산이 데이터 가치화팀이 사용하고 있는 Airflow라는 워크플로우 툴을 활용해서 될 수 있도록 구성했고, 지표가 신뢰 가는 방식으로 계산될 수 있도록 다음과 같은 작업을 했어요.
통일된 기준으로 계산하기
지표를 정의할 때 지표를 계산할 국가, time grain(일간, 주간, 월간), 그 외 디멘션만 정의된다면 같은 방식으로 모든 지표가 계산될 수 있도록 했어요. 그러기 위해서 국가의 단위가 무엇인지, time grain의 단위가 무엇인지 등에 대한 기준을 세웠어요.
또한, 지표의 값이 매번 볼 때마다 달라지는 것을 최소화면서도 충분한 데이터로 계산될 수 있도록 하기 위해 결산이란 개념을 적용했어요. 앱에서 발생하는 클라이언트 사용자 행동 이벤트 같은 경우는 사용자의 네트워크 상태나, 디바이스의 상태, 클라이언트 버퍼 로직 등의 이유로 인해 당근마켓 데이터 인프라에 지연되어서 도착하는 경우가 있어요.
예를 들어, 2023–04–10 23:58에 발생한 이벤트가 실제로는 당근마켓 인프라에는 2023–04–11 01:23에 도착할 수도 있어요. 이런 이벤트들은 2023–04–10 일자의 지표를 계산할 당시에는 집계가 안 될 수도 있어요. 데이터 가치화팀에서는 지연되어서 들어오는 데이터들을 측정해 봤을 때, 이벤트 발생 시점 이후 3일이면 충분히 데이터가 들어오고 있다고 판단했어요. 그래서 지표를 최대 3일까지는 재계산을 해서 지연되어서 들어오는 데이터들을 포함해서 계산했고, 3일 이후에는 지표의 값이 결산 되었다고 보고 다시 계산해도 지표의 값이 변경되지 않도록 했어요.
올바른 시점에 계산하기
지표를 계산할 때 필요한 원본 데이터 소스들이 잘 준비된 시점 이후 국가별 타임존을 고려해서 계산되도록 했어요. 원본 데이터 소스를 적재하는 앞단의 데이터 파이프라인에 문제가 있으면 지표가 계산이 안 되게 하고, 이러한 상황에 대한 알림이 슬랙으로 전달이 돼서 데이터 가치화 팀에서 문제를 확인할 수 있도록 했어요. 지표 계산에 필요한 앞단의 데이터가 온전한 경우에만 지표가 계산되도록 해서 잘못된 값이 최대한 보이지 않도록 했어요.
KarrotMetrics
신뢰할 수 있는 방식으로 지표를 정의해서 관리하고, 계산되도록 하는 이 전체적인 구성을 KarrotMetrics라는 이름으로 제품화했어요. KarrotMetrics로 계산된 지표 값을 하나의 Source of truth로 보고 어느 BI Tool이나 서비스에서 사용할 수 있도록 했고 결과 전사 구성원들이 KarrotMetrics에 등록한 지표들에 대해서는 통일된 기준으로 보고 얘기할 수 있게 됐어요. 그동안 구성원들이 각기 다른 언어로 소통하고 있었다면 이제는 하나의 언어로 소통할 수 있게 된 거예요.
KarrotMetrics는 데이터 업계에서 흔히 얘기하는 Metrics store, Semantic layer로 나아가기 위한 첫 스텝이에요. 지표에 대한 현상들을 파악하며 문제 사항을 하나씩 해결해 나갔기에 현재는 MVP 수준이라고 볼 수 있어요. Metrics store라고 했을 때 기대되는 다른 기능들은 하나씩 개선해 나갈 예정이에요.
KarrotMetrics로 지표를 개발하는 방식이 각 팀의 지표를 만드는 모든 문제 해결해주지는 않아요.
지표를 모두가 합의할 만한 기준으로 정의하기 이전에, 빠르게 데이터를 여러 방식으로 집계해서 보고 싶은 경우에는 아직도 ad-hoc으로 계산하는 경우가 많이 있어요. 다만, 전사나 팀에서 중요하게 보고 싶은 지표가 있다면 최대한 신뢰할 수 있는 형태로 만드는 게 중요하다고 생각했고 이 경우 데이터 가치화팀에서 개발한 KarrotMetrics라는 지표 플랫폼을 사용하리라 기대하고 있어요.
지표 Catalog
KarrotMetrics로 개발된 지표의 정의와 계산 로직은 구성원 모두가 볼 수 있도록 사내 Data discovery tool인 Datahub에 등록했어요. 지표들은 코드로 관리되고 있지만 지표의 정의, 스키마 및 디멘션, 계산되는 로직, 지표의 설명, 오너의 정보 등을 조회하고 싶은 구성원들은 해당 툴로 확인할 수 있어요.
KarrotMetrics 그 이후
전사 회의에서 발표할 때나 회의 중 다른 팀과 지표를 공유할 때, 기존에는 각기 다른 대시보드를 보고 지표들을 비교하면서 어떤 지표가 옳은지 확인했다면, 이제는 지표마다 KarrotMetrics의 결과물 하나만 보고 있어요. 실제로 의사결정을 하거나 소통할 때도 객관적인 해당 지표 값 하나로 소통하는 덕분에, 의사결정 기준이 더욱더 명확해지고 효율적으로 됐어요.
무엇보다 흥미로웠던 변화는 각 팀에서 지표를 KarrotMetrics에 추가하는 과정에서, 지표의 정의와 어떤 디멘션 단위로 보면 좋을지에 대해 깊이 고민했다는 건데요. 지표는 팀이나 회사가 나아가야 할 방향성에 대한 객관적인 성과를 보여주기 때문에, 이렇게 고민하는 과정에서 각 팀이 어떤 부분에 가치를 두고 있고 앞으로 어떻게 나아가려고 계획하는지 서로 더 깊이 이해할 수 있는 계기가 됐어요.
앞으로는 데이터 가치화팀은 KarrotMetrics를 더 많은 구성원이 사용할 수 있도록, 더 쉽게 또 언제든 다시 활용할 수 있게 구조화 및 효율화하려고 해요. 나아가 데이터 가치화팀의 실험 플랫폼과 같은 다른 제품 간의 원활한 연동이 가능하도록 지원할 예정이에요.
당근마켓의 데이터 가치화 여정에 관심이 생기셨다면, ‘Data Scientist, Decision’, ‘Software Engineer, Data’ 채용 공고에 함께해주세요!
당근 팀 채용


conversion_type

시리즈 내 순서

conversion_text

멤버 전용

대표 이미지

공개 가능

작성일

예상 읽기 시간

전환 텍스트

글쓴이

시리즈

상단 노출

전환 유형

요약

제목

당근에서 프로덕트 데이터 분석가는 어떤 일을 할까요?

당근 팀과 데이터 분석

당근의 A/B 테스트 문화를 공유해요.

1주 1개 실험하는 프로덕트 팀이 되는 여정

당근마켓의 파워 유저 커브는 어떤 모양을 그릴까?

파워 유저 커브(스마일 커브)

분석 프로세스 덕분에 프로젝트 당 소요되던 시간을 50% 이상 감소시킬 수 있었고, 그 중 실제 액션플랜으로 이어진 분석도 2배 이상 증가했어요.

공학적 관점으로 데이터 분석 프로세스 만들기

당근 앱에서 ‘OO님, 거래 잘 하셨나요? 판매한 이웃에게 따뜻한 마음을 전해보세요!’ 메시지를 보신 적이 있나요?

거래 후기 실험을 통해 따뜻한 거래 경험 만들기

A 대시보드와 B 대시보드에 있는 지표 값이 다른데 어떤 값을 봐야 하나요?

신뢰할 수 있는 지표 만들기

KarrotMetrics을 만들 때 고려했던 기술적인 부분들을 얘기해볼게요

신뢰할 수 있는 지표 만들기 2 : KarrotMetrics 기술편

Data scientist, Decision은 전사의 데이터 기반 의사결정을 더 좋은 방향으로 개선하려고 노력해요

100+ 팀원의 의사결정에 영향을 주는 Data Scientist, Decision : 실험플랫폼

지표란 무엇이고, 우린 왜 지표를 볼까요?

지표를 볼 때 어떤 문제점들이 올바른 의사결정을 방해할까요?

신뢰할 수 있는 지표 만들기

Contents

데이터 분석 소식을
매월 받아보세요

🥕 당근 데이터 분석 사례 모아보기

함께 읽어보면 좋은 글

매출 분석 (3) LTV(고객 생애 가치), LTR(고객 생애 매출) 왜 필요하고 어떻게 계산할까?

매출 분석 (2) ARPPU를 이용하여 매출 분석하기

그로스 팀의 지표 미팅 (1) 구독 지표 모니터링

데이터 분석 소식을
매월 받아보세요데이터 분석 소식을 받아보세요

신뢰할 수 있는 지표 만들기

Contents

데이터 분석 소식을 매월 받아보세요

🥕 당근 데이터 분석 사례 모아보기

함께 읽어보면 좋은 글

매출 분석 (3) LTV(고객 생애 가치), LTR(고객 생애 매출) 왜 필요하고 어떻게 계산할까?

매출 분석 (2) ARPPU를 이용하여 매출 분석하기

그로스 팀의 지표 미팅 (1) 구독 지표 모니터링

데이터 분석 소식을 매월 받아보세요데이터 분석 소식을 받아보세요

데이터 분석 소식을
매월 받아보세요

데이터 분석 소식을
매월 받아보세요데이터 분석 소식을 받아보세요