당근의 사용자 행동 로그 관리 플랫폼: 이벤트센터 개발기

당근은 늘어나는 사용자 행동 로그를 더 일관되고 안전하게 다루기 위해, Git과 코드 중심이던 스키마 관리 방식을 UI 중심의 이벤트센터로 전환했다. 로그는 실험 설계, 제품 개선, 의사결정의 출발점이지만, 수가 많아질수록 네이밍 불일치와 리뷰 병목, 운영 복잡도가 크게 커졌기 때문이다.

로그 수집은 모바일 앱의 SDK에서 시작해 이벤트 서버, GCP Pub/Sub, GCP Dataflow, GCS와 BigQuery로 이어지는 파이프라인으로 처리된다. 유효하지 않은 이벤트는 DLQ로 분리해 별도 테이블에 저장하고, 이후 배치 단계에서 한 번 더 시간 윈도우 기반 중복 제거를 수행해 정확도를 높인다.

이 체계 위에서 핵심이 되는 것은 사용자 행동 이벤트 스키마다. 이벤트마다 오너와 도메인을 명시하고, 공통 필드와 커스텀 파라미터의 의미와 타입을 정의해 두면 BigQuery에서 이벤트별 테이블이 자동 생성되고, JSON을 파싱하지 않아도 컬럼처럼 바로 조회할 수 있다.

기존에는 이 스키마를 Spark StructType JSON으로 직접 작성해 Git으로 관리했다. 이 방식은 다음과 같은 문제를 만들었다.

• 스키마 파일 작성에 코드 지식이 필요했고, metadata, nullable, type 같은 속성을 일일이 채워야 했다.
• 중첩 구조가 자주 등장해 JSON 작성 실수가 잦았고, 사소한 오타나 괄호 누락도 CI 실패로 이어졌다.
• PR 작성 후 데이터가치화팀 리뷰를 거쳐야 해서 수정과 재리뷰가 반복됐다.
• home_feed와 homeFeed, show_article와 shown_article처럼 이벤트 네이밍이 제각각이었다.
• 화면 이름과 문서가 팀별로 흩어져 있어, 같은 화면을 놓고도 기준이 달라졌다.

이를 해결하기 위해 전사 공통의 이벤트 체계를 먼저 정리했다. 사용자 행동 로그는 서비스 - 스크린 - 액션의 계층 구조를 따르고, 이름은 client_{action}_{service}_{screen}_{object} 형식을 사용한다. action은 과거형으로 정의하고, 요소는 snake_case를 쓰되 각 요소 내부 표기는 camelCase로 맞춰 일관성을 확보했다.

그 다음 단계로 이벤트센터를 만들었다. 서비스와 스크린을 등록하고, 특정 스크린에서 발생하는 이벤트를 UI에서 정의할 수 있게 했으며, 시스템이 네이밍 컨벤션 적용, Spark StructType JSON 생성, 유효성 검사, BigQuery View Table 생성을 자동으로 처리한다. 덕분에 누구나 몇 번의 클릭만으로 이벤트 스키마를 등록할 수 있고, 리뷰와 CI에 의존하던 과정도 크게 줄었다.

운영 편의성도 강화했다. 개발자는 로깅 코드를 심은 뒤 이벤트센터에서 본인 ID로 발생한 로그를 준실시간으로 확인하며 파라미터 값과 수집 여부를 검증할 수 있다. 별도 쿼리나 앱 접속 없이 QA가 가능해져, 로깅 오류를 빠르게 찾을 수 있다.

정의된 스키마는 CLI를 통해 타입 안전한 코드로도 변환된다. 현재는 플랫폼별로 Swift, Kotlin, TypeScript 타입이 생성되며, 개발자는 생성된 타입을 그대로 사용해 필드명 실수나 타입 오류를 컴파일 타임에 잡을 수 있다.

남은 과제도 명확하다.

• 이벤트 추가 과정은 아직 클릭과 입력이 많아 더 빠른 UX가 필요하다.
• 단일 스크린만 등록할 수 있어 성공/실패처럼 상태가 갈리는 화면은 별도 관리가 필요하다.
• 화면 내 특정 요소에서 이벤트가 발생했는지 더 정밀하게 식별하는 자동화가 필요하다.
• Figma 연동과 코드 자동 생성까지 이어지는 설계 자동화가 다음 목표다.
• CTR, PV, AU 같은 지표 계산과 실험 지표 설정까지 UI에서 처리하는 분석 도구 확장도 고민하고 있다.

결국 이벤트센터는 한 팀의 내부 도구가 아니라, 당근 전체가 사용자 행동 로그를 다루는 방식을 바꾸기 위한 기반이다. 데이터 분석가, 데이터 엔지니어, 프론트엔드 엔지니어, 모바일실과 웹뷰 담당자들이 같은 규칙 위에서 협업하도록 만들며, 로그 수집을 넘어 해석과 활용까지 연결하는 방향으로 진화하고 있다.