쿼리가 아니라 정의를 고치기로 했습니다: Databricks Metric View 도입기

안녕하세요. 기술본부 데이터인텔리전스셀 박현기입니다. 이 글에서는 Databricks Unity Catalog의 Metric View를 신규 런칭 게임의 데이터 파이프라인에 도입하면서, 대시보드와 분석 에이전트가 같은 지표 정의를 읽게 하기 위해 데이터 구조를 어떻게 나눴는지, 그 과정에서 정한 설계 규칙과 결과를 공유합니다. #배경: 쿼리마다 다르게 계산되던 지표 게임의 런칭 직후는 데이터 요청이 가장 많고 가장 급한 시기입니다. 게임 서버 DB의 스냅샷, 클라이언트와 서버가 남기는 분석 로그, 메타 정보 테이블처럼 소스가 여럿이고, 어떤 유저를 지표에서 제외할지, 봇이 섞인 게임을 어떻게 다룰지, 어떤 시점의 값을 쓸지 같은 조건도 복잡했습니다. 그런데 짧은 기간에 여러 대시보드가 만들어지고 분석 요청도 쏟아지면서, 이 조건들이 대시보드마다, 그리고 adhoc 분석 쿼리마다 각자 따로 정의되며 쿼리되고 있었습니다. 각 대시보드의 데이터셋은 자기 쿼리 안에서 필요한 집계를 그 안에서 계산했습니다. 빠르게 만들기에는 좋은 방식이었지만 몇 주가 지나자 세 가지 문제가 드러났습니다. 같은 지표가 데이터셋마다 다른 산출식으로 정의됐습니다. 승률 하나만 놓고 봐도 승부가 결정된 게임을 구분하는 조건이 데이터셋에 따라 달랐고, 비정상 데이터 정제 기준(운영 계정 제외, 비정상 유저 제외)도 어떤 곳은 넓고 어떤 곳은 좁았습니다. 정의를 바꾸면 여러 곳을 고쳐야 했고 한 곳을 빼먹는 순간 차트끼리 숫자가 어긋났습니다. 집계 전 정제 비용이 대시보드를 열 때마다 반복됐습니다. 게임 로그는 한 이벤트에 여러 참가자와 아이템이 중첩(nested) 필드로 함께 기록되는 경우가 많습니다. 지표를 계산하려면 이 필드를 행으로 펼치고, 서로 다른 소스 데이터를 합치고, 중복을 걸러 내야 합니다. 이 과정이 대시보드의 데이터셋 쿼리때마다 매번 다시 실행되었으므로, 지표 자체 쿼리보다, 지표 앞의 정제 쿼리 비용과 시간이 더 드는 문제도 있었습니다. 분석 에이전트가 지표를 매번 스스로 정의했습니다. 사내 분석 에이전트에 "지난주 승률 상위 10개 쿠키"를 물으면 정제되지 않은 로그 데이터를 읽어 답을 냈습니다. 그 과정에서 이탈자를 제외할지, 표본 하한을 둘지, 정제를 어느 기준으로 할지 등등 다양한 기준을 에이전트가 판단하여 생성했습니다. 이런 조건을 에이전트가 읽는 가이드 문서(스킬)에 적어 두기는 했습니다. 그런데 지표마다 붙는 조...