당근
안녕하세요. “신뢰할 수 있는 지표 만들기”라는 글을 썼던 데이터 가치화팀의 Henry예요. 이전 글에서 ’왜 신뢰할 수 있는 지표를 만드는 것이 중요하고 신뢰할 수 있는 지표를 만들기 위해 무엇을 했는지‘에 대해 이야기했어요. 실제로 신뢰할 수 있는 지표를 만드는 과정에서 생각보다 많은 벽을 만났고 동료들과 함께 그 벽을 뛰어넘었는데요. 더 자세한 경험을 공유하고자 2편으로 찾아왔어요.
당근마켓의 Metrics Store는 KarrotMetrics라는 이름을 가지고 있고, 이 제품을 만들 때 고려했던 기술적인 부분은 다음과 같아요. (사실 기술과 기술이 아닌 것을 나누는 게 어렵긴 해요. ㅎㅎ)
- 각 지표를 정의할 때 어디에, 어떤 식으로 정의해야 하는가?
- Dimension이라는 개념을 어떻게 구현해야 하는가?
- 지표를 구할 때마다 값이 변하지 않게 하기 위해서는 어떻게 만들어야 하는가?
- 지표의 버전 관리를 코드 내에서 어떻게 해야 하고, 데이터에 어떻게 남겨야 하는가?
- 다른 파이프라인이나 데이터 적재를 기다려야 하는 의존성 문제를 어떻게 해결해야 하는가?
- 지표의 정의나 로직이 문제가 없는지, 파이프라인이 제대로 작동하는지 어떻게 쉽게 테스트할 수 있는가?
- 과거의 지표 데이터 백필을 어떤 식으로 해야 하는가?
위와 같은 기술적 고민에 해결책을 팀이 함께 KarrotMetrics에 녹여냈어요. 현재까지 총 249개의 지표가 KarrotMetrics로 정의되고 사용되고 있어요. 하지만 여기서 끝이 아니라고 생각해요. 팀에서는 KarrotMetrics가 궁극적으로 어떤 제품이 되어야 하는지, 우리가 앞으로 무엇을 해야 하는지 고민하는 시간을 가졌어요. 글의 마지막에서는 KarrotMetrics의 미래에 대해서 이야기 드리려고 해요. 글이 길 텐데, 필요할 때마다 찾아볼 수 있겠다 싶어서 용기를 내서 길게 적어봤어요. 이렇게 적고 나면 정리가 되어서 좋더라고요.
각 지표를 정의할 때 어디에, 어떤 식으로 정의해야 하는가
보통 지표를 구한다고 하면 SQL문을 작성해서 빅쿼리와 같은 콘솔에서 SQL문을 실행해서 값을 구해요. 지표를 구하는 가장 가벼운 방법 중 하나인데, 이 방법으로는 이 지표가 무슨 지표인지에 대한 정보가 담겨있지 않아요.
당근마켓에서도 정말로 많은 지표를 구하는 SQL 문이 있지만 그것만 봐서는 SQL문이 어떤 지표를 구하는지 알기 어려웠어요. 또한 지표를 구하는 사람은 “이 로직이 맞는 로직인가? 제대로 작성한 것이 맞는가?”라는 고민도 항상 하게 돼요. 따라서 지표의 정의라는 게 무엇인가라는 생각을 많이 했어요.
지표라는 개념의 구성요소는 다음과 같다고 생각했어요.
- 지표의 이름: 정의라는 행동을 할 때, 이름을 짓는 것은 빼놓을 수 없죠. 이 지표가 어떤 지표인지 직관적으로 알려줄 수 있는 지표의 이름이 필요해요. 예를 들어, MAU라는 지표의 이름을 보게 되면 계산된 지표의 값이 어떤 의미를 갖는지 알 수 있어요.
- 지표의 종류: 단순 합산된 값을 보는 지표와 Retention과 같은 지표는 계산하는 방법과 계산된 값을 봐야 하는 방법이 달라요. 이처럼 보고자 하는 지표의 의미에 따라서 지표의 종류로 구분을 두었어요. 현재는 default, cohort_retention, custom 3가지의 지표 종류를 지원해요.
- 지표를 구하기 위해 사용하는 재료: 지표를 구하기 위해서는 어떤 이벤트, DB의 데이터, 외부 데이터 등을 사용할 거고, 어떤 필드를 가져올 것인지 정의가 되어야 해요. SQL문이 명확하면서도 자유도가 높기 때문에 이 부분을 가장 잘할 수 있다고 생각했어요.
- 지표 계산 방법: 지표의 재료를 사용해서 COUNT를 할 것인지, COUNT(DISTINCT)를 할 것인지, SUM(IF())와 같은 방식으로 계산할 것인지에 대한 내용이에요.
- 지표 계산 기간: 어느 기간의 데이터를 계산할지에 대한 정의예요. 현재 KarrotMetrics에서는 time_grain이라고 부르는 용어로 하루가 끝났을 때 계산하는 daily, 일주일이 끝났을 때 계산하는 weekly, 한달이 끝났을 때 계산하는 monthly를 지원하고 있어요.
- 지표 계산 대상: “어떤 국가의 지표인가”에 대한 내용이에요. 당근마켓은 글로벌 서비스이기 때문에 어떤 지표는 모든 국가별로 보기도 하고, 어떤 지표는 한국에서만 보기도 해서 지표의 계산 대상을 정의해야 해요.
지표라는 개념에는 이처럼 여러 내용이 포함되는데 이 내용들을 어떻게 담을지 고민을 많이 했어요. KarrotMetrics의 취지가 하나의 정의로 모든 지표의 계산을 하는 것이었기 때문에 지표 정의의 형태가 가장 처음 고민한 기술적 과제였어요. 지표를 정의하는 사람은 기술적인 부분이 아닌 “지표의 정의”라는 본래의 목적에 집중할 수 있으면 좋겠다고 생각했어요. 따라서 지표 정의의 복잡도를 낮추기 위해서는 지표의 종류를 나누고 template을 만들어서 복잡한 과정을 뒤에서 플랫폼이 알아서 하는 방법이 좋다고 생각했어요. 문제는 모든 형태의 지표를 다 담을 template을 생각보다 만들기 어렵다는 것이었어요. 지금까지 만든 template은 default, cohort retention, custom 3가지에요.
따라서 지표의 완전한 정의는 3가지가 합쳐서 만들어져요.
- 지표의 메타 정보(이름, 국가, 오너)를 담는 metrics.yaml
- 지표의 재료 및 계산 방법을 담은 <지표 이름>.yaml
- 1번과 2번을 가져다가 실제 지표 계산 SQL문을 만드는 template
1번은 다음과 같은 형태로 작성하도록 했어요.
2번을 만들 때 많이 고민했어요. 단순하게 지표의 로직을 정의할 수 있어서 누구나 쉽게 지표를 만들게 하면서도 확장성과 용이성을 갖춘 유연한 형태로 만들고 싶었어요. 구성원들이 기본적으로 SQL문에 익숙했기 때문에 지표의 재료나 계산 방법은 SQL로 정의하도록 했어요. 지표의 재료는 user_action으로 정의하고 지표의 계산 방법은 metric_calculation으로 정의했어요. 지표의 종류가 count니까 metrics.yaml에 count라고 정의하면 알아서 계산해 주는 것이 아니라 사용자가 직접 어떻게 계산해야 할지 적어주는 형태에요.
위와 같이 user_action과 metric_calculation을 적으면 실제 다음 정도의 길이의 SQL문을 자동으로 만들어서 여러 time_grain과 국가의 지표 값을 구해요.
위와 같은 형태로 해결되지 않는 지표들은 custom template이나 cohort retention template으로 별도로 적도록 했어요. 대부분의 지표들은 위의 default template으로 커버할 수 있었어요. cohort retention template은 팀의 data scientist, decision 분들과 같이 작업했는데 관련 컨텍스트가 좀 길기 때문에 나중에 별도의 글로 설명해 보려고 해요.
Dimension이라는 개념을 어떻게 구현해야 하는가
Dimension이라는 개념은 어떤 분들에게는 익숙하고 어떤 분들에게는 생소한 개념일 거예요. Dimension의 개념을 예를 들어 설명해 보자면, 1월 방문자 수 지표를 구한다고 하면 1월 1일부터 31일까지의 데이터를 가져와서 COUNT(DISTINCT user_id)와 같은 식으로 구할 거예요. 1월 동안의 전체 방문자 수를 구하고 나면 당연하게도 여러 질문이 나와요. “전체 방문자 수 중에서 iOS와 Android는 각각 몇 명이지?”, “특정 광역시의 방문자 수는 몇 명이지?”, “방문자 중 거래를 해본 사용자는 몇 명이었지?”와 같은 질문이에요. iOS 방문자 수와 Android의 방문자 수는 별개의 지표로서 정의할 수도 있지만, 사실 “방문자 수”라는 지표에 “platform”이라는 dimension이 있어서 해당 dimension으로 나눠볼 수 있다고 생각하는 것이 조금 더 자연스러워요.
데이터 가치화 팀에서는 KarrotMetrics에서 dimension이라는 개념을 어떻게 구현해야 하는지에 대해서 고민을 많이 했어요.
- a라는 dimension에 대해서도 지표를 쪼개 볼 수 있고, b라는 dimension에 대해서도 지표를 쪼개볼 수 있으려면 어떻게 해야할까?
- Dimension이라는 개념을 위에서 정의했던 user_action에서 어떻게 녹이고 그걸 template이 어떻게 가져와서 실제 계산할 SQL문을 만들어낼 것인가?
- 지역별로 볼 때 시, 구, 동과 같은 식으로 hierarchy가 있는 지역별 지표를 어떻게 쪼개볼 수 있게 만들 것인가?
위와 같은 고민을 다음과 같은 식으로 해결했어요.
step 1 : user_action에서 SELECT 문의 필드로 dimension을 정의
step 2 : metrics.yaml에서 실제 dimension으로 사용할 필드명을 user_action 안에서 가져와서 정의
step 3 : template 안에서 metrics.yaml에서 정의한 필드들에 대해서 GROUP BY ROLLUP 함수를 사용해서 각 dimension 별로 나눠서 보면서도 전체 값을 볼 수 있는 로직 생성. dimension 별로 전체의 값을 볼 수 있도록 “all”이라는 값을 dimension에 추가. 자세한 로직은 GROUP BY ROLLUP의 작동 방식에 대한 설명이 되어서 생략하도록 할게요.
이미 데이터에 dimension이 있다면 현재 template으로 문제 없이 처리가 가능해요. 하지만, 데이터에 보고자 하는 dimension이 없다면 다른 테이블들과 join하던지 예외 처리하는 방법들이 필요했어요. 예를 들어, 오랜만에 돌아온 사용자인지 아닌지와 같은 dimension은 별도의 처리가 필요했어요. 사실 dimension은 서로 공동으로 사용하는 것이 많기 때문에 지표마다 별도로 정의하는 것이 아니라 중앙에서 관리되면서 가져다가 사용할 수 있는 형태가 되어야한다고 생각하는데 아직 그 부분까지는 가지 못했어요.
지표를 구할 때마다 값이 변하지 않게 하기 위해서는 어떻게 만들어야 하는가
KarrotMetrics를 만든 여러 이유 중에 하나가 “구할 때마다 지표 값이 달라지기” 때문이었어요. 그래서 지표는 왜 구할 때마다 값이 달라지는지에 대해 고민하게 됐어요. 지표를 구할 때마다 달라졌던 이유는 다음과 같아요.
- 실제로 구할 때마다 SQL문을 다르게 작성함.
- 해당 기간의 클라이언트 사용자 행동 이벤트나 그외 지표가 의존하고 있는 데이터가 적재되지 않았는데 지표를 계산함
초기 스타트업에서 지표를 계산할 때는 주로 DB에 직접 쿼리를 해서 계산하기 때문에 데이터가 수집이 완료되지 않은 상황에서 지표를 계산한다는 상황을 만나기 어려워요. 하지만, 다양한 사용자 행동을 지표로 관찰하기 시작하면 클라이언트에서 기록한 사용자 행동 이벤트를 사용하기 마련이에요. 클라이언트의 사용자 행동 이벤트는 DB와는 다르게 여러 가지 이유로 유실되거나 뒤늦게 데이터가 수집될 수 있어요. 그렇기 때문에 회사와 관련해서 정책을 세우고 (며칠까지만 뒤늦게 들어오는 데이터를 기다리겠다) 정책에 따라 지표를 구해야 해요.
당근마켓에서는 실제 이벤트 발생 시간으로부터 +72시간까지만 데이터가 들어오길 기다려요. 예를 들어 1월 1일에 발생한 이벤트 데이터를 1월 2일, 3일, 4일까지 기다려요. 단순히 생각하면 1월 1일이 끝나고 72시간이 지난 1월 5일에 1월 1일에 대한 지표를 계산하면 돼요. 당근마켓에서는 이 개념을 “결산”이라고 불러요. 하지만 프로덕트를 만들 때는 최대한 빠르게 사용자의 반응을 보는 것이 중요하기 때문에 바로 다음 날 데이터를 볼 수 있는 것이 중요해요. “빠르게 데이터를 봐야 한다”와 “결산 된 데이터로 정확히 봐야 한다”라는 가치 사이에 고민을 많이 했어요.
결론적으로는 똑같은 지표 계산을 기간에 따라 4번 실행하기로 했어요. 결산 된 데이터를 보고 싶은 분들의 니즈도 만족시키기 위해 is_fixed라는 필드를 만들고, 4번의 계산이 끝날 때 is_fixed 필드의 값은 False에서 True로 변경하도록 했어요. is_fixed가 True가 된 지표의 값은 더 이상 변경되지 않아요. 주별이나 월별도 지표들에 대해서도 동일하게 적용했어요. 당근마켓은 Airflow라는 스케줄링 툴을 사용하고 있어서 Airflow DAG들을 활용해서 주기적으로 지표가 계산되도록 했어요.
지표의 버전 관리를 코드 내에서 어떻게 해야 하고, 데이터에 어떻게 남겨야 하는가
지표를 구할 때마다 값이 다르게 나오는 다른 이유 중 하나는 “실제로 구할 때마다 SQL문을 다르게 작성함” 때문이에요. 다르게 작성하는 데는 여러 이유가 있을 거예요. 지표 계산에 사용되는 이벤트나 DB가 변경될 때도 있고, 로직을 변경하게 될 때도 있어요. 이러한 변경에 대한 기록이 전혀 남지 않고 바뀐 지표의 값만 접하다 보면 많은 혼란을 느끼게 되더라고요. 개발할 때 git으로 코드의 버전을 관리하는 것처럼 지표도 버전 관리하면 좋지 않을까? 생각하게 됐어요.
이처럼 지표마다 지표의 재료나 계산 방법이 달라질 수 있기 때문에 지표별로 버저닝을 적용하게 됐어요. 폴더로 버전들을 구분해서 지표를 수정해야 하는 경우에 위의 버전 폴더 안에 작성하도록 했어요. 현재까지 지표 중에 최대로 v4까지 간 지표가 있었고, 앞으로는 더 많은 버전이 생겨날 거라고 예상해요.
이렇게 버전을 나누고 실제로 DAG에서 지표 값을 계산할 때는 가장 최신의 버전을 통해 계산하도록 했어요. 하지만 지표는 과거의 값을 백필할 수도 있기 때문에 각 버전이 언제부터 언제까지 유지되었는지를 알아야 해요. 따라서 지표의 정의 부분에 각 버전이 언제부터 언제까지를 의미하는 것인지 적도록 했어요.
실제로 계산된 지표 값을 담고 있는 빅쿼리 테이블에도 버전이 끝에 달리도록 했어요. 하지만 대시보드에서 지표를 볼 때는 모든 버전에 대해서 이어서 볼 수 있어야 해요. 이런 문제를 해결하기 위해 빅쿼리의 view를 활용해서 모든 버전을 다 하나의 뷰로 볼 수 있도록 했어요.
언제 어떻게 버전이 추가될지 모르기 때문에 view가 유동적으로 변해야 하므로 view를 만드는 파이프라인을 별도로 만들고 다음과 같은 SQL 문들 template로 활용해서 view를 주기적으로 업데이트하도록 했어요. 지표 값을 사용하려는 사용자는 단 하나의 view만 보고 모든 국가와 모든 time_grain 그리고 모든 버전의 데이터를 볼 수 있어요.
다른 파이프라인이나 데이터 적재를 기다려야 하는 의존성 문제를 어떻게 해결해야 하는가
지표를 구할 때마다 값이 다르게 나오는 다른 이유 중 하나는 “지표가 의존하고 있는 다른 파이프라인이나 데이터 적재가 완료되기 전에 지표를 계산함”이라는 이유가 있어요. 당근마켓에서는 데이터 웨어하우스로 빅쿼리를 사용하고 있고, 모든 데이터가 빅쿼리로 싱크되고 있어요. 각 데이터가 빅쿼리에 싱크되는 시간은 상황과 데이터의 성격에 따라 달라요.
이런 의존성 문제를 잘 해결해 주는 것이 Airflow이지만 모든 구성원이 Airflow의 작동 방식을 알고 사용할 수는 없어요. 그래서 Airflow에 대해 이해도가 낮더라도 의존성 관리를 쉽게 할 수 있도록 어느 정도 구조화해서 sensors.yaml이라는 파일로 관리하게 했어요. sensors.yaml에는 데이터가 적재되는 DAG를 기다리는 “sensor”들을 정의하도록 했어요.
sensors.yaml에 기다려야 하는 sensor를 정의하고 해당 sensor 이름을 metrics.yaml에서 dependencies에 적도록 했어요. 그러면 자동으로 sensor task를 만들어서 DAG를 구성하도록 했어요.
이를 통해 지표 계산에 필요한 데이터가 적재되었는지를 기다렸다가 지표가 계산되도록 해서 데이터의 신뢰성을 챙겼어요.
지표의 정의나 로직이 문제가 없는지, 파이프라인이 제대로 작동하는지 어떻게 쉽게 테스트할 수 있는가
지표를 정의하고 관리하는 것만큼이나 지표의 정의대로 파이프라인이 문제 없이 돌아가는지, 지표 값은 올바른 형태인지 테스트를 쉽게 하는 것이 중요하다고 생각했어요. 그래야 KarrotMetrics 내부 로직이나 스케줄링을 담당하는 Airflow에 대한 이해도가 높지 않더라도 구성원들이 쉽게 올바른 형태의 지표를 만들 수 있다고 생각했기 생각했기 때문이에요.
당근마켓 데이터 파이프라인을 다루는 github repository에서는 Pull Request를 오픈하면 기본적으로 테스트를 할 수 있는 Testing 환경이 PR별로 배포돼요. 각 Pull Request마다 독립적인 airflow 환경이 구축되어서 파이프라인 코드 자체에 오류가 없는지, 파이프라인을 실제로 실행했을 때의 결과 값이 올바른지 확인할 수 있어요.
PR Testing환경에서 KarrotMetrics 지표 정의나, 로직, 실제 지표의 값이 올바르게 실행되는지 확인할 수 있도록 별도의 airflow DAG를 만들어서 운영했어요. 구성원들은 해당 파이프라인의 JSON configuration에 테스트할 지표명들을 적고 실행시키면, 실제 파이프라인에서 돌아가는 것과 동일한 로직으로 자동으로 국가별로 일간, 주간, 월간으로 지표가 계산되도록 했어요. 그리고 계산된 결과 값은 별도의 빅쿼리 dataset에서 확인해서 데이터 결과 값에 이상 없는지 확인할 수 있게 했어요.
과거의 지표 데이터 백필을 어떤 식으로 해야 하는가
지표를 정의하고 나서 많은 경우에 지표의 과거 값이나 트렌드를 보기 위해 지표 정의대로 과거 데이터 백필이 필요해요. 그래서 KarrotMetrics 초기 버전에서 과거 지표 값 들에 대해 백필이 가능하도록 만들었어요. 다만, 지표 백필 작업은 많은 양의 과거 데이터 그리고 긴 기간에 대한 데이터를 처리하기 때문에 비용적으로나 시간상으로 효율적인 작업은 아니에요. 그렇기 때문에 자동으로 정의된 지표가 백필되는 방식이 아니라 구성원이 수동으로 백필 작업을 트리거 할 수 있도록 했어요.
백필을 위한 별도의 airflow DAG를 만들었고 지표를 테스트할 때의 방법과 유사하게 백필을 트리거할 수 있도록 했어요. 백필 파이프라인을 트리거하면 파이프라인이 지표에 정의된 start_date를 확인해서 지표 start_date 부터 현재까지의 날짜를 추출한 다음에 지표 정의대로 자동으로 계산해서 빅쿼리에 저장하도록 했어요.
지표를 백필할 때 기존에 이미 계산된 값이 해당 날짜에 있다면 지표 값을 overwrite하는 것에 주의해야 해요. 지표에 사용되는 데이터에 따라서 실제로 과거 시간에 지표를 계산했을 때와 현재 과거 시간에 대한 지표를 계산했을 때와 값이 다르게 나올 수도 있기 때문이에요. 그래서, 백필을 할 때 백필하려고 하는 날짜에 이미 계산된 값이 있다면 계산하지 않도록 작업했어요.
그리고 언제 지표가 계산되었는지, 어떤 이유로 백필되었는지를 기록하도록 해서 나중에 각 지표에 대한 결과 값에 대해 디버깅이 필요할 때 도움이 될 수 있도록 메타 컬럼값들도 추가했어요.
마지막으로 백필 작업의 관측성 확보를 위해 백필 작업이 완료되면 slack으로 노티를 보내도록 구성했어요. 어떤 지표가 어느 기간에 대해 백필을 완료했는지, 에러가 났으면 어느 기간/time_grain/국가에 대해 실패했는지 표시해서 지표 백필을 트리거한 지표의 오너를 태그하도록 했어요.
KarrotMetrics의 미래
지금까지 과거에 KarrotMetrics라는 제품을 어떻게 만들었는지에 대한 이야기를 자세하게 적어봤어요. 하지만 사실 이제부터가 더 중요하다고 생각해요. 그래서 최근 팀이 모여서 KarrotMetrics란 어떤 제품이고 앞으로 어떤 방향으로 발전해야 할지에 대해서 이야기했어요.
간단히 말하자면 KarrotMetrics는 “대시보드를 손으로 만들지 말자”라는 목적을 달성하는 제품이라고 생각했어요. 현재 지표 관련한 문제는 “당근마켓이나 서비스의 상태가 궁금한 사람이 서비스의 상태를 알기 위해 항상 지표를 개발하고 대시보드를 만들어야 한다는 것”이에요. 이런 목표를 달성하기 위해 5 step으로 나눠서 계획을 세웠어요.
Step 1 : unified metric engine
지표를 만드는 경험을 한 곳으로 통일하고 반복 작업을 줄이기 위해,
- 실험 플랫폼과 현재의 KarrotMetrics 지표를 리스트업하고
- 두 가지의 지표를 모두 하나의 정의로 통일하기 위해 구조화하고
- 실험 플랫폼 지표를 모두 KarrotMetrics 지표로 옮겨요.
Step 2 : easy metric definition
Github의 PR이 익숙하지 않은 누구나 지표를 정의하고 만들 수 있게 하기 위해,
- PR 상태에서 지표 추가 작업에 들어가는 리소스를 줄이고,
- UI에서 지표를 추가하거나 기존의 지표를 찾고 내용을 확인할 수 있도록 해요.
Step 3 : dashboard template
대시보드를 항상 만들어야 하는 문제를 해결하기 위해,
- 각 서비스에서 공통적으로 보는 지표를 추리고,
- yaml과 같은 형태의 코드로 쉽게 지표 리스트를 만들어서,
- 배포하면 자동으로 superset 같은 곳에서 대시보드가 만들어지도록 해요.
Step 4 : metric definition using ChatGPT
SQL이 익숙하지 않고, 기존의 데이터 구조를 잘 모르는 분들이 쉽게 지표를 만들기 위해,
- ChatGPT에게 당근의 데이터 구조나 데이터 용어 (테이블 이름들)을 학습시키고,
- 자연어로 물어보면 지표의 정의를 스스로 만들어서 추천해주도록 해요.
Step 5 : information-rich chart
지표의 등락을 지금보다 쉽게 이해하기 위해,
- 장애가 났던 날을 기록해서 차트에서 보이도록 하고,
- 각 지표에 행해졌던 실험이 차트에서 보이도록 하고,
- 지표를 여러 차원으로 한 차트에서 둘러볼 수 있도록 해요.
데이터 가치화 팀은 이 제품을 통해 대시보드를 만드는 리소스가 절반 이상으로 줄기를 희망해요. 현재 지표나 차트, 대시보드를 만드는 분들도 제품과 사용자에 더 집중할 수 있고 지표를 보고 의사결정 하고 싶은 분들도 다른 누구의 도움 없이도 지표를 볼 수 있어요.
지난 글을 시작하며 이야기한 것처럼, 지표를 본다는 것은 곧 팀이 목표를 이루기 위한 성과 달성을 잘 이해하고 파악한다는 뜻인데요. 데이터 가치화 팀은 당근마켓 내에서 데이터를 통한 사용자를 위한 의사결정이 가능해지도록 만들어 가고 있어요.
이 글을 통해 당근마켓의 데이터 가치화팀 여정에 관심이 생기셨다면, 채용 공고에 함께해주세요!
