당근 / data-engineering

당근의 사용자 행동 로그 관리 플랫폼: 이벤트센터 개발기. 코드로 관리하던 사용자 행동 로그를 플랫폼으로 만든 이유 (새 탭에서 열림)

당근은 방대한 사용자 행동 로그를 보다 효율적이고 체계적으로 관리하기 위해 기존의 Git 기반 코드 관리 방식에서 벗어나 UI 중심의 로그 관리 플랫폼인 ‘이벤트센터’를 구축했습니다. 이를 통해 복잡한 JSON 스키마 작성 과정과 수동 리뷰 절차를 자동화하여 데이터 관리 비용을 획기적으로 낮추었으며, 전사적인 로그 컨벤션을 확립해 데이터의 일관성과 분석 편의성을 동시에 확보했습니다. 결과적으로 개발자와 분석가 모두가 데이터 기반의 의사결정에만 집중할 수 있는 환경을 조성하는 데 성공했습니다. **기존 Git 기반 관리 방식의 한계** * **높은 진입장벽:** 새로운 로그 스키마를 추가하기 위해 Spark의 StructType JSON 형식을 직접 코드로 작성해야 했으며, 이는 데이터 엔지니어링 지식이 부족한 구성원에게 큰 부담이 되었습니다. * **비효율적인 프로세스:** 스키마 하나를 추가할 때마다 PR 생성, 데이터 팀의 수동 리뷰, 수정 반복 과정을 거쳐야 했기에 데이터 반영 속도가 느려지는 문제가 발생했습니다. * **일관성 없는 명명 규칙:** 이벤트 이름에 대한 강제적인 컨벤션이 없어 유사한 행동이 서로 다른 이름으로 정의되거나, snake_case와 camelCase가 혼용되는 등 데이터 정합성 관리가 어려웠습니다. **사용자 행동 로그 수집 및 처리 아키텍처** * **실시간 파이프라인:** 모바일 앱 SDK에서 발생한 이벤트는 서버를 거쳐 GCP Pub/Sub으로 전달되며, Dataflow를 통해 유효성 검증, 중복 제거, 데이터 변환(Flatten)이 실시간으로 이루어집니다. * **스키마 기반 자동 테이블 생성:** 이벤트 스키마를 정의하면 BigQuery에 해당 이벤트 전용 테이블이 자동으로 생성되며, JSON 형태의 커스텀 파라미터가 일반 컬럼으로 펼쳐져 저장되어 복잡한 쿼리 없이도 즉시 분석이 가능합니다. * **데이터 신뢰성 확보:** 스트리밍 단계에서의 단기 중복 제거와 배치 단계에서의 시간 윈도우 기반 중복 제거를 병행하여 데이터의 정확도를 극대화했습니다. **이벤트센터를 통한 로그 관리 혁신** * **UI 중심의 스키마 정의:** 코드를 직접 수정하는 대신 웹 인터페이스에서 필드명, 타입, 설명, 오너십 등을 설정할 수 있어 누구나 쉽게 로그를 설계하고 관리할 수 있습니다. * **명격한 컨벤션 적용:** '행동(Action)-서비스(Service)-대상(Object)' 구조의 명명 규칙을 시스템적으로 강제하여 이벤트 검색성을 높이고 중복 정의를 방지했습니다. * **자동화된 유효성 검사:** 스키마 변경 시 발생할 수 있는 오류를 시스템이 사전에 체크하고, 변경 사항을 즉시 데이터 파이프라인에 반영하여 운영 리소스를 최소화했습니다. 데이터의 양이 늘어날수록 로그 관리의 핵심은 '자율성'과 '통제' 사이의 균형을 잡는 것입니다. 당근의 사례처럼 로그 정의 과정을 플랫폼화하고 컨벤션을 시스템으로 강제한다면, 휴먼 에러를 줄이는 동시에 전사 구성원이 데이터라는 공통 언어를 더욱 쉽고 정확하게 사용할 수 있는 환경을 만들 수 있습니다.

당근은 왜 User Activation을 전사 공통 데이터 레이어로 만들었을까? (새 탭에서 열림)

당근은 단순한 액티브 유저(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 모델이 필요할 때 설정값만 입력하면 자동으로 수십 개의 모델이 생성되도록 자동화했습니다. * 이를 통해 데이터 엔지니어의 반복 작업을 줄이고, 분석가들이 필요할 때 즉시 공통 레이어를 확장할 수 있는 환경을 만들었습니다. 데이터를 단순히 쿼리 결과물로 보는 단계를 넘어, 시스템화된 '인프라'로 구축할 때 비로소 전사적인 데이터 활용도가 극대화됩니다. 당근의 사례처럼 상태 전이와 같은 복잡한 로직을 공통 레이어로 추상화하고 자동화한다면, 분석 효율성을 높이는 동시에 데이터 기반의 의사결정 문화를 더욱 공고히 할 수 있습니다.