왜 이 문서를 썼는가?#

유저 행동 데이터 수집이 필요하다—라는 말은 종종 들어왔지만, 그럴 때마다 나는 고개를 끄덕이며 GA4 같은 서비스를 쓸 건지, 자체 API를 쓸 건지 정도만 묻고는, SDK 세팅법이나 찾아보며 “트리거랑 파라미터만 알려주시면 바로 반영할게요”라는 말로 스스로 꽤나 적극적인 편이라 착각하곤 했다.

하지만 이벤트 텍소노미에 대해 짧은 기간이나마 공부해본 결과, 개발자로서 이벤트 설계는 단순히 소스코드에 이벤트를 심는 걸로 끝나는 일이 아니라, 머리를 맞대고 함께 고민해야 하는 작업임을 알게 되었다.

이 문서는 그런 깨달음의 기록이다. ‘이벤트는 정리된 대로 심는 게 내 일’라고만 생각했던 누군가에게, 흥미로운 생각거리가 되어주기를 바란다.

이벤트 텍소노미란?
이벤트 텍소노미는 사용자 행동 이벤트와 그 속성들을 조직적이고 구조화된 방식으로 설계하는 체계입니다. 이를 통해 이벤트 이름, 속성, 카테고리 등을 일관성 있게 관리하며, 모든 분석 작업의 기반을 튼튼히 다질 수 있습니다

1. 저는 디바이스가 5개 있는데요?#

문제: 하나의 유저가 여러 디바이스에서 활동하면 어떻게 추적할까?

• A라는 유저가 스마트폰 2개와 태블릿, 노트북에서 로그인해서 활동합니다.
• 그런데 클라이언트에서 자동 생성되는 식별자(Device ID)는 디바이스마다 다릅니다.
• 서버에서는 유저 계정 ID(예: user_123)가 기준입니다.
• 이 둘이 연결되지 않으면, Amplitude나 Firebase에서는 동일 유저로 묶이지 않고 서로 다른 사람처럼 보이게 됩니다.

2. 이벤트의 홍수에 휩쓸리다…#

처음에는 가능하면 많이 다는 것이 좋다고 생각했다. 그러나 좋지 않은 예시들을 보면, 이벤트가 너무 많으면 어떤 정보를 봐야 할지 몰라지는 역효과가 발생한다고 하는데…

우리는 CBL (Challenge Based Learning)이라는 프레임워크를 접했다. 어떻게 적용해볼까?

전 : 유저 행동은 결국 어떤 화면에 접근하고, 어떤 컴포넌트를 누르느냐 아님? 이벤트 다 추적하면 되는 거 아님? 기획자나 뭐.. 아무튼 나 아닌 누군가가 알아서 분석해주겠지!

후 : 우리는 왜 유저의 행동을 추적해야하는데? 뭣 땜에? 도대체 뭘 위해서?

그렇다. CBL을 하고나니, 이벤트를 심을 생명주기와 컴포넌트가 있으니 냅다 심어버리는 것이 아닌, 왜 이 이벤트를 심는가를 먼저 묻는 구조가된다.

목표와 지표부터 시작하세요#

먼저 평가 기준을 간략하게 설명한 다음 해당 평가 기준에 대해 적절하게 보고해야 하는 이벤트에 대해 간략하게 진행하는 것이 중요합니다. 목표, 지표 및 이벤트 간의 연결이 없으면 실제로 필요하지 않은 추적 계획과 데이터를 망라놓치게 될 가능성이 높으며 비즈니스에 중요한 이벤트를 놓치게 됩니다.

목표	1분기에 인수를 15% 증가
미터법	전환율 = 가입한 사용자/고유 방문자
이벤트	가입한 사용자
속성	user_id, 캠페인, 실험, 참조자 등

또한 계측을 위한 이벤트의 우선 순위를 정하는 데 도움이 되며 제품 관리자와 데이터 분석가가 새로운 기능의 목표 또는 성공 지표뿐만 아니라 이를 측정하는 데 필요한 제품에서 필요한 실제 추적으로 어떻게 변환되는지에 대해 생각하도록 할 수 있기를 바랍니다.

3. 과식보단 소식이 건강에 좋다#

• page_view, onAppear, onChange 등 과도하게 붙인 이벤트는 노이즈가 된다
• 지표를 설계하지 않은 이벤트는 결국 아무도 안 본다
• 예를 들어, “유저가 날씨를 선택했다”는 행동을 슬라이더를 바꿀 때마다 기록하는가, 저장을 눌렀을 때 한 번 기록하는가는 완전히 다른 해석을 낳는다

결론적으로는, 사용자 인텐트가 실현된 시점에만 이벤트를 로깅해야 한다는 통찰을 얻을 수 있다.

4. 찌를 때마다 돈입니다… Debounce & Throttle#

유저의 행동은 생각보다 고빈도로 발생한다. 특히 슬라이더, 스크롤, 키 입력, 제스처 등은 사용자가 한 번의 인텐트를 표현하기 위해 수십 번의 이벤트를 발생시킬 수도 있다.

이런 경우, 정말 모든 이벤트를 기록해야 할까? 무지성 호출 하기 전에 한번쯤 고려해봐야한다.

예: 유저가 온도 슬라이더를 18도에서 25도로 움직였다고 하자. 이걸 모든 중간 값(19, 20, 21…)으로 로깅해야 할까?

절대 아니다. 그래서 필요한 것이 Debounce와 Throttle 개념이다.

• Debounce: 이벤트가 연속적으로 발생할 때, 마지막 이벤트만 실행 → 예: 유저가 텍스트를 입력할 때, 입력을 멈춘 뒤 1초 후 이벤트 발생
• Throttle: 이벤트가 연속적으로 발생할 때, 일정 주기로만 실행 → 예: 유저가 스크롤할 때, 500ms 단위로만 이벤트 발생

이런 처리를 하지 않으면, 서버나 이벤트 툴이 감당 못할 로그 폭탄이 발생할 수 있다. 실제로 Firebase나 Amplitude에서도 초당 수십 건의 이벤트가 들어오면 이상 탐지 시스템에 걸리거나 요금 폭탄이 나올 수 있다.

이벤트를 로깅하는 것은 사용자 행동을 기록하는 것이지만, 그 행동은 “해석 가능한 단위”로 축소되어야 한다. 그게 바로 개발자가 고려해야 할 책임이다.

5. 이벤트 네이밍, 변수명만큼 중요하다#

이벤트 설계에서 종종 간과되는 요소가 바로 이름이다. 하지만 이름은 그 자체로 의미를 부여하고 해석을 유도하는 메타데이터다.

예: click_button vs submit_feedback

• click_button이라는 이름은 UI의 단순 인터랙션을 설명할 뿐이다.
• 반면, submit_feedback은 유저의 의도와 비즈니스 목적을 더 명확히 보여준다.

마무리하며#

이벤트를 설계하는 것은 단순한 로그 수집의 문제가 아니다. 해석 가능한 행동 데이터의 구조를 만드는 일이자, 작은 선택 하나가 분석의 효율과 품질을 결정짓는 작업이다.

이 문서가 모든 상황에 정답이 될 수는 없겠지만, 이벤트 설계를 고민할 때 작게나마 방향을 제시하는 힌트가 되었으면 한다.

이벤트 코드를 심는 일이 재미없고 반복적인 작업처럼 느껴졌다면, 이제는 함께 머리를 맞대고 고민할 수 있는 의미 있는 일로 다시 보이기를!