analytics-engineering

당근은 왜 User Activation을 전사 공통 데이터 레이어로 만들었을까? | by Juyeon Park | 당근 테크 블로그 | Jan, 2026 | Medium (새 탭에서 열림)

당근은 단순한 액티브 유저(Active User) 수치만으로는 파악하기 어려운 사용자 행동의 원인과 흐름을 분석하기 위해 전사 공통 데이터 레이어인 'Activation 레이어'를 구축했습니다. 이를 통해 사용자의 활성 상태와 상태 전이를 일관된 기준으로 정의함으로써 데이터 신뢰성을 확보하고, 팀 간 중복 계산으로 인한 비용과 운영 리소스를 대폭 절감했습니다. 결과적으로 데이터 분석 환경을 쿼리 중심에서 시스템 중심으로 격상시켜 전사적인 의사결정 속도와 정확도를 높였습니다. **단순 지표를 넘어선 User Activation의 중요성** * 단순한 액티브 유저 수는 '무슨 일이 일어났는지'는 보여주지만, '왜' 일어났는지에 대한 해답을 주지 못하므로 유저를 상태별로 쪼개어 보는 관점이 필요합니다. * **활성 상태**: 특정 시점에 유저가 신규(New), 유지(Retained), 복귀(Reactivated), 이탈(Inactive) 중 어떤 상태인지 분류합니다. * **상태 전이**: 기간의 흐름에 따라 유저가 어떤 경로로 이동하는지(예: 유지 → 이탈) 파악하여 활동성 수준에 따른 구체적인 액션을 가능하게 합니다. * 이전에는 팀마다 이 기준을 각자 계산하여 신뢰도가 낮고 운영 안정성이 떨어졌으나, 이를 공통 레이어로 통합하여 해결했습니다. **신뢰성 확보를 위한 기준 행동의 고정** * 단순한 UI 로그(클릭 등)가 아닌, 비즈니스적 의미를 담은 **Fact 모델**을 기준으로 Activation을 계산하도록 설계했습니다. * 로그 내 파라미터에 따라 의미가 달라지는 혼선을 방지하기 위해, 사전에 정제된 Fact 레이어를 입력값으로 사용합니다. * `<fact_name>_activation_<time_grain>`과 같은 엄격한 네이밍 컨벤션을 적용하여 모델 이름만으로도 어떤 행동과 주기(일/주/월)를 기준으로 하는지 누구나 쉽게 알 수 있게 했습니다. **증분 모델(Incremental Model)을 통한 비용 최적화** * 수천만 명의 사용자 데이터를 매일 전체 재처리하는 방식은 비용 소모가 크기 때문에, dbt의 증분 모델 방식을 도입했습니다. * **FirstLast 모델**: 각 유저별 최초/직전/최근 활동일을 별도로 관리하여 전체 이력을 매번 스캔하지 않도록 했습니다. * **Activation 모델**: 당일 활동 유저 정보와 FirstLast 모델을 결합하여 상태와 복귀 간격 등을 계산하고, 결과를 다시 FirstLast 모델에 업데이트하는 순환 구조로 데이터 스캔량을 최소화했습니다. * **Activation Status 모델**: 활동이 없는 유저를 포함한 전체 유저의 현재 상태(특히 이탈 기간)를 관리하여 분석 편의성을 높였습니다. **dbt 매크로를 활용한 생산성 극대화** * 다양한 행동(앱 방문, 게시글 작성 등)과 시간 단위(Daily, Weekly, Monthly)별로 수많은 모델을 직접 구현해야 하는 번거로움을 매크로로 해결했습니다. * 복잡한 상태 계산 로직을 dbt 매크로로 표준화하여, 새로운 Activation 모델이 필요할 때 설정값만 입력하면 자동으로 수십 개의 모델이 생성되도록 자동화했습니다. * 이를 통해 데이터 엔지니어의 반복 작업을 줄이고, 분석가들이 필요할 때 즉시 공통 레이어를 확장할 수 있는 환경을 만들었습니다. 데이터를 단순히 쿼리 결과물로 보는 단계를 넘어, 시스템화된 '인프라'로 구축할 때 비로소 전사적인 데이터 활용도가 극대화됩니다. 당근의 사례처럼 상태 전이와 같은 복잡한 로직을 공통 레이어로 추상화하고 자동화한다면, 분석 효율성을 높이는 동시에 데이터 기반의 의사결정 문화를 더욱 공고히 할 수 있습니다.

토스 피플 : 데이터를 ‘이해하는’ 구조를 설계합니다 (새 탭에서 열림)

데이터의 품질은 사후 수습이 아닌 생성 단계의 초기 설계에서 결정되며, 특히 AI 시대에는 사람뿐만 아니라 기계도 데이터의 맥락을 완벽히 이해할 수 있는 의미 기반의 구조 설계가 필수적입니다. 토스는 이를 위해 데이터의 생성부터 활용까지 전 과정을 관리하는 'End-to-End 데이터 거버넌스'를 지향하며, 개발 속도를 저해하지 않으면서도 품질을 높이는 유연한 설계 표준을 구축하고 있습니다. 결과적으로 데이터 아키텍처는 단순한 규칙 강제가 아니라 비즈니스의 빠른 변화 속에서 데이터의 정합성을 유지하고 AI와 사람이 신뢰할 수 있는 기반을 만드는 핵심적인 역할을 수행합니다. **데이터 설계의 본질과 품질 관리의 전환** * 데이터의 품질은 분석 단계에서의 정제가 아니라, 데이터가 처음 만들어지는 순간의 설계(Design)에 의해 결정됩니다. * 서비스가 빠르게 변하는 플랫폼 환경에서는 데이터 수습에 에너지를 쏟는 사후 대응보다, 데이터가 생성되는 흐름부터 구조적으로 정리하는 사전 설계가 중요합니다. * '속도'와 '품질'은 대립하는 가치가 아니며, 설계 시 미래의 변화 가능성을 고려한 유연한 기준선을 마련함으로써 두 가치 사이의 균형을 잡아야 합니다. **AI가 이해할 수 있는 의미 중심의 데이터 구조** * 현대의 데이터 아키텍처는 사람뿐만 아니라 AI가 질문하고 분석하는 시대를 대비하여 기계가 읽을 수 있는(Machine-readable) 형태로 진화해야 합니다. * 단순한 메타데이터 관리를 넘어, 데이터 간의 의미 관계를 명확히 하는 '의미 기반 표준 사전'과 '온톨로지(Ontology)'를 도입하여 AI가 맥락을 놓치지 않도록 설계합니다. * 데이터 간의 연결 고리를 명확히 설계함으로써 AI가 스스로 의미를 추론하며 발생할 수 있는 해석 오류를 줄이고 데이터의 신뢰성을 극대화합니다. **실천적인 데이터 거버넌스와 아키텍트의 역할** * 효과적인 거버넌스는 규칙을 강제하는 것이 아니라, "표준을 따르는 것이 오히려 더 편하다"고 느낄 수 있도록 자연스러운 프로세스를 설계하는 것입니다. * 비즈니스의 빠른 사이클 속에서 모든 것을 완벽하게 설계하기보다, 현재 맥락에 맞으면서도 나중에 무리 없이 정리할 수 있는 '확장성 있는 여지'를 남겨두는 전략이 필요합니다. * 데이터 아키텍트는 거창한 담론에서 시작하는 것이 아니라, 작은 구조 하나를 더 낫게 만들고 싶어 하는 데이터 엔지니어와 분석가 모두가 도달할 수 있는 전문 영역입니다. 데이터 아키텍처는 단순히 테이블 명세서를 관리하는 일이 아니라 비즈니스의 복잡도를 구조로 풀어내는 일입니다. 고품질의 데이터를 유지하면서도 개발 속도를 잃지 않으려면, 초기 설계 단계에서부터 AI와 협업할 수 있는 표준 체계를 구축하고 이를 조직 내에서 자연스럽게 수용할 수 있는 '실현 가능한 거버넌스 모델'을 고민해 보는 것이 좋습니다.