이벤트 택소노미 설계 가이드: 트래킹이 무너지지 않는 명명 규칙

이벤트 택소노미 설계란?
이벤트 택소노미 설계는 서비스에서 수집할 사용자 행동을 이벤트와 속성으로 분류하고, 이름 문법·필수 속성·값 형식 규칙을 팀 공용 문서로 고정하는 작업이다. (본문 기준 시점: 2026년 8월)

트래킹은 한 번에 무너지지 않는다. 조금씩 어긋나다가, 어느 분기 회의에서 "이 퍼널 숫자 왜 이래요?" 한마디로 무너진다.

대개 원인은 계측 누락이 아니다. 같은 행동이 서로 다른 이름으로 세 번 쌓였을 뿐이다. 웹 팀은 purchase, iOS 팀은 Purchase Complete, 리뉴얼 때 붙인 신규 코드는 order_completed. 데이터는 다 있는데 하나의 퍼널로 묶이지 않는다.

이 글은 이벤트를 무엇으로 정할지가 아니라, 정한 이벤트가 2년 뒤에도 살아남게 만드는 명명 규칙과 검수 절차를 다룬다. 어떤 행동을 이벤트로 뽑을지, 트래킹 플랜 문서를 어떻게 채울지는 믹스패널 이벤트 트래킹 플랜 작성 가이드에서 이미 정리했으니, 여기서는 그다음 단계인 규칙 설계와 거버넌스에 집중한다.

명명 규칙이 무너질 때 실제로 얼마를 잃나

추상적인 경고보다 산수가 빠르다. 월 구매 1만 건이 발생하는 커머스 앱을 가정한다. 구매 완료 행동이 세 가지 이름으로 흩어져 있고 비중이 각각 60%, 30%, 10%라고 하자.

상세 조회 5만 건 대비 실제 구매 전환율은 20%다. 그런데 퍼널에 purchase 하나만 걸면 12%로 보인다. 절대값이 틀린 것도 문제지만, 더 위험한 건 A/B 테스트다. 신규 결제 화면을 iOS에 먼저 배포했는데 iOS 쪽 이벤트 이름만 다르면, 실험군 전환율이 구조상 낮게 찍힌다. 개선안이 데이터상 개악으로 판정되고 롤백된다. 잘못된 계측은 분석을 못 하게 만드는 데서 그치지 않고, 반대 방향 의사결정을 유도한다.

이벤트로 쪼갤 것 vs 속성으로 담을 것

택소노미가 붕괴하는 두 번째 경로는 이벤트 개수 폭발이다. 상품 화면 CTA를 이름으로 구분하기 시작하면 조합 수만큼 이벤트가 늘어난다.

CTA 종류 3개, 노출 위치 4곳, 플랫폼 2개를 전부 이름에 넣으면 3 × 4 × 2 = 24개 이벤트가 생긴다. 여기에 프로모션 유형 5종을 더하면 120개다. 반면 이벤트는 product_cta_clicked 하나로 두고 cta_type, placement, platform, promo_type 네 개를 속성으로 받으면 정의 문서는 한 줄로 끝난다.

판단 기준은 단순하다. "이 구분으로 퍼널 단계가 바뀌는가"가 이벤트, "같은 단계 안에서 누가·어디서·무엇으로가 달라지는가"는 속성이다. 장바구니 담기와 구매 완료는 퍼널 단계가 다르니 이벤트를 나눈다. 안드로이드 구매와 iOS 구매는 같은 단계이므로 platform 속성으로 처리한다.

단계별 실행 절차

1단계. 문법 하나를 골라 문서 첫 줄에 박는다

가장 널리 쓰이는 형태는 object_action 구조다. 대상을 앞에, 동작을 뒤에 놓고 동사는 과거형으로 통일한다. signup_completed, cart_item_added, video_playback_started 식이다. 목적어가 앞에 오면 알파벳 정렬만으로 관련 이벤트가 한곳에 모인다. 이벤트가 200개를 넘어가는 시점부터 탐색 비용 차이가 확연해진다.

• 케이스: snake_case 또는 Title Case 중 하나만. 혼용 금지
• 시제: 과거형 고정 (clicked, viewed, submitted)
• 언어: 영문 소문자 고정. 한글 이벤트명은 SDK와 웨어하우스 연동 단계에서 인코딩 이슈를 만든다
• 금지어: test, temp, new, v2는 이름에 넣지 않는다. 6개월 뒤 new는 가장 오래된 이벤트가 된다

2단계. 속성 사전을 이벤트 사전과 분리한다

속성은 이벤트보다 재사용 빈도가 높다. product_id는 조회·장바구니·구매 세 이벤트에 모두 붙는다. 그런데 이벤트별로 따로 정의하면 한쪽은 문자열, 다른 쪽은 정수로 들어가는 사고가 난다. 속성 사전을 별도 시트로 두고 이름, 데이터 타입, 예시값, 허용값 목록, 필수 여부를 한 곳에서 관리한다.

값 형식도 규칙화 대상이다. 통화는 소수점 포함 숫자와 ISO 4217 코드를 분리하고, 불리언은 true/false로 통일하며, 없는 값은 빈 문자열이 아니라 null로 보낸다. 빈 문자열은 나중에 "값이 없음"인지 "빈 값을 보냄"인지 구분되지 않는다.

3단계. 카디널리티 상한을 미리 정한다

속성값 종류가 수천 개를 넘으면 분석 도구의 세그먼트 드롭다운이 사실상 못 쓰는 상태가 된다. 검색어 원문, 자유 입력 텍스트, 타임스탬프 문자열이 대표적인 고카디널리티 함정이다. 상한을 정하고(예: 값 종류 50개), 넘는 값은 버킷팅한 파생 속성을 함께 보낸다. 검색어 원문은 로그로 남기되, 분석용으로는 query_length_bucket, result_count_bucket을 따로 만든다.

4단계. 사용자 속성과 이벤트 속성을 구분한다

요금제 등급처럼 시점에 따라 바뀌는 값은 두 곳 모두에 필요하다. 사용자 속성에만 넣으면 과거 이벤트가 현재 등급으로 소급 해석된다. 6개월 전 무료 사용자가 지금 유료라면, 과거 행동이 전부 유료 사용자 행동으로 집계된다. 요금제 변경 시점 분석이 목적이라면 이벤트 발생 시점 값을 이벤트 속성으로 함께 실어 보내야 한다.

5단계. 리뷰 게이트와 폐기 절차를 만든다

규칙 문서만으로는 안 지켜진다. 새 이벤트가 배포 파이프라인에 들어가기 전 통과해야 할 관문이 필요하다.

1. 기획 단계에서 이벤트 정의를 트래킹 플랜 문서에 먼저 등록한다. 코드보다 문서가 앞선다
2. PR 템플릿에 "신규 이벤트 여부 / 문서 링크" 항목을 넣어 리뷰어가 강제로 확인하게 한다
3. 스테이징에서 실제 payload를 확인한다. 이름뿐 아니라 속성 타입과 null 여부까지 본다
4. 배포 후 7일간 발생량을 모니터링한다. 예상 대비 10분의 1이면 계측 누락, 10배면 중복 발화를 의심한다
5. 90일간 조회되지 않은 이벤트는 폐기 후보로 분류하고, 담당자 확인 후 정리한다

마지막 항목이 특히 빠지기 쉽다. 이벤트는 대체로 추가만 되고 삭제되지 않는다. 그래서 3년 차 서비스의 이벤트 목록에는 이미 없어진 화면의 이벤트가 절반쯤 섞여 있다. 폐기 절차가 없으면 신규 입사자는 어떤 이벤트가 살아 있는지 알 방법이 없다.

시나리오: 재설계 없이 규칙만 도입한 팀

아래는 실제 프로젝트에서 관찰되는 패턴을 재구성한 가상 시나리오다. 특정 기업의 공개 수치가 아니다.

국내 이커머스 팀 A는 이벤트 214개를 운영 중이었다. 전수 점검 결과는 이랬다.

• 중복 정의 이벤트 38개 (같은 행동, 다른 이름)
• 90일간 조회 0회 이벤트 76개
• 필수 속성 product_id가 빠진 이벤트 12개

이 팀은 트래킹 코드를 새로 짜지 않았다. 대신 중복 38개를 하나로 매핑하고, 미사용 76개를 폐기 목록으로 옮기고, 속성 사전을 만들어 필수값을 채웠다. 남은 이벤트는 100개 아래로 줄었다. 정확도가 올라간 것보다 체감이 컸던 변화는 따로 있었다. PM이 이벤트 목록에서 원하는 행동을 찾는 시간이 짧아지면서, 분석가에게 "이거 어느 이벤트로 봐야 해요?"를 묻는 슬랙 스레드가 눈에 띄게 줄었다.

데이터를 직접 보는 사람이 늘어나는 조건은 도구 도입 자체가 아니다. 비개발 직군이 이름만 보고 무슨 행동인지 알 수 있는 이벤트 목록, 그리고 드래그앤드롭으로 퍼널과 코호트를 조립할 수 있는 환경이 함께 있어야 한다. 택소노미가 정리되지 않은 상태에서는 어떤 분석 도구를 붙여도 결국 쿼리를 아는 사람에게 질문이 몰린다.

전체 체크리스트

이벤트 택소노미 점검 체크리스트

• [ ] 이름 문법(object_action) 한 가지로 고정했다
• [ ] 케이스와 동사 시제를 문서 첫 줄에 명시했다
• [ ] 같은 행동이 두 개 이상 이름으로 존재하지 않는다
• [ ] 퍼널 단계가 바뀌지 않는 구분은 전부 속성으로 옮겼다
• [ ] 속성 사전을 이벤트 사전과 분리해 관리한다
• [ ] 속성별 데이터 타입, 허용값, 필수 여부를 정의했다
• [ ] 고카디널리티 속성에 버킷팅 파생 속성을 만들었다
• [ ] 시점에 따라 변하는 값을 이벤트 속성으로도 보낸다
• [ ] 신규 이벤트가 PR 리뷰 항목에 포함돼 있다
• [ ] 스테이징에서 payload 타입까지 검증한다
• [ ] 배포 후 7일 발생량 모니터링 담당자가 있다
• [ ] 90일 미사용 이벤트 폐기 절차가 돌아간다
• [ ] 이름과 속성 정의의 최종 결정권자가 지정돼 있다

도구 선택을 앞두고 있다면 프로덕트 애널리틱스란 무엇인가에서 분석 도구가 답하는 질문의 범위를 먼저 보고, 사용자 분석 툴 비교에서 택소노미 관리 기능 차이를 확인하면 판단이 빨라진다.

더 읽어보기

• 프로덕트 애널리틱스란?
• 믹스패널 완벽 입문 가이드
• 사용자 분석 툴 비교 (믹스패널·앰플리튜드·포스트호그)

자주 묻는 질문

이벤트는 몇 개가 적당한가?

개수 자체에 정답은 없지만, 초기 서비스라면 핵심 퍼널을 설명하는 20~30개로 시작하는 편이 안전하다. 중요한 건 상한이 아니라 비율이다. 최근 90일간 한 번도 조회되지 않은 이벤트가 전체의 30%를 넘는다면 설계가 아니라 폐기 절차가 없는 문제다. 분기마다 사용 빈도를 뽑아 정리 대상을 걸러내는 루틴을 먼저 만들어야 한다.

이미 이름이 엉킨 상태인데 전부 다시 짜야 하나?

전면 재계측은 마지막 수단이다. 분석 도구 대부분은 이벤트 병합이나 표시 이름 변경을 지원한다. 우선 중복 이벤트를 하나로 매핑해 과거 데이터를 살린 뒤, 신규 개발분부터 새 규칙을 적용하는 방식이 현실적이다. 다만 매핑은 임시방편이므로 전환 기한을 정해두고, 기한 이후 구버전 이벤트를 코드에서 제거해야 한다. 기한 없는 병존은 규칙이 두 개가 되는 것과 같다.

GA4로 이벤트 택소노미를 관리하면 되지 않나?

GA4는 트래픽 소스와 광고 성과 측정에 특화된 도구다. 제품 내 행동 분석에서는 구조에서 오는 제약이 따라온다. 커스텀 이벤트와 파라미터 수 제한, 24~48시간 데이터 처리 지연, 대량 데이터에서 걸리는 탐색 보고서 샘플링, BigQuery 연동 없이는 로데이터에 접근하기 어려운 구조가 대표적이다. 택소노미를 정교하게 설계할수록 세그먼트 조합과 로데이터 검증 요구가 늘어나는데, 바로 그 지점에서 한계가 드러난다. 행동 기반 코호트와 이탈 경로 추적이 분석의 중심이라면, 프로덕트 애널리틱스 도구가 답하는 질문의 범위가 다르다는 점을 먼저 확인하는 편이 좋다.

마무리

택소노미 설계는 한 번 하고 끝나는 문서 작업이 아니라, 배포 프로세스에 심어두는 루틴에 가깝다. 이름 문법 한 줄, PR 체크 항목 하나, 분기별 폐기 리뷰 한 번. 이 세 가지만 돌아가도 트래킹은 웬만해선 무너지지 않는다.

반대로 규칙 없이 쌓인 이벤트는 시간이 지날수록 정리 비용이 커진다. 이벤트 200개를 정리하는 일과 50개를 정리하는 일은 난이도가 다르다. 지금이 가장 이른 시점이다.

믹스패널 입문 가이드에서 이벤트와 속성이 실제 분석 화면에서 어떻게 쓰이는지 확인하고, Nitrox 블로그에서 관련 가이드 더 보기.