# Amplitude 이벤트 설계의 세분성

이벤트를 어디까지 쪼개고 어디까지 합칠지 — ‘이벤트는 적게, 속성은 풍부하게’ 원칙과 5가지 판단 체크리스트, Amplitude 한도 관점을 정리합니다.

- 카테고리: Amplitude 이벤트 택소노미
- 소요 시간: 약 8분
- 난이도: 중간
- 업데이트: 2026.06.01
- 원문: /wiki/playbook/amplitude-event-taxonomy-checklist/how-to-decide-amplitude-event-granularity

## 목차

- [세분성 3구간](#spectrum)
- [우리의 원칙](#principle)
- [적용 예시](#examples)
- [판단 체크리스트](#checklist)
- [Amplitude 한도 관점](#limits)
- [자주 묻는 질문](#faq)

이벤트를 어디까지 ‘쪼개고’, 어디까지 ‘합칠지’. 이걸 **설계의 세분성(granularity)**이라고 부릅니다. 너무 잘게 쪼개면 `click_btn_signup_hero_top` 같은 이름이 페이지마다 양산되어 한 행동이 수십 개 이벤트로 흩어지고, 반대로 너무 뭉치면 `click` 하나로 모든 행동이 들어와 ‘무엇이 일어난 건지’를 속성만으로 구분해야 합니다. 이 글은 그 적정선을 잡는 원칙과 판단 체크리스트를 정리합니다.

## 세분성의 스펙트럼 — 너무 잘게 / 적정 / 너무 뭉치기

같은 ‘회원가입 버튼 클릭’이라는 행동을 세 가지 방식으로 설계하면 다음과 같이 갈립니다.

| 구간 | 이벤트 이름 패턴 | 왜 안 좋은가 / 왜 좋은가 |
| --- | --- | --- |
| ❌ 너무 잘게 | `click_btn_signup_hero_top`, `click_btn_signup_hero_bottom`, `click_btn_signup_footer`, `click_btn_signup_modal` … | 한 행동이 **N개 이름으로 흩어짐**. ‘회원가입 버튼 총 클릭’을 보려면 매번 N개를 합산해야 하고, 한 개라도 빠뜨리면 분석이 어긋남. |
| ✅ 적정 | 이벤트 `click_btn` + 속성 `btn_name="회원가입"`, `btn_location="hero_top"` | 한 행동은 **한 이름**. 합쳐서도(전체 버튼 클릭) 쪼개서도(`btn_name="회원가입"`만) 볼 수 있고, 운영도 가벼움. |
| ❌ 너무 뭉치기 | 이벤트 `click` 하나 + 속성 `element_type`, `element_name`, `element_location` | 이벤트 이름이 모두 `click`이라 ‘어떤 행동 종류가 많이 일어났는가’를 한눈에 보기 어려움. Amplitude 자동 추적 이름과도 헷갈림. |

중앙의 ‘**적정**’이 우리가 추구하는 자리입니다. 다만 ‘적정’이 어디인지는 사이트의 성격 ·분석 목적·운영 환경에 따라 미세하게 달라집니다 — 그래서 ‘세분성’ 이야기는 한 줄 규칙이 아니라 **판단 기준**이 됩니다.

## 우리의 원칙 — “이벤트는 적게, 속성은 풍부하게”

> **팁**
>
> **이벤트 이름은 ‘UX 요소 유형’까지만, 그 안의 세부는 속성으로 푼다.** · 이벤트 이름은 *한 자릿수~두 자릿수 종류*로 좁히고, · 그 이벤트의 ‘어떤 것’·‘어디서’·‘어떻게’는 속성으로 채웁니다. — 한 행동은 한 이름, 그 행동의 다양성은 속성의 값으로.

이 원칙이 좋은 이유는 ‘**합치는 분석**’과 ‘**쪼개는 분석**’ 둘 다 가능하기 때문입니다.

- **합치기** — `click_btn`의 총 클릭 수를 한 줄로 본다.
- **쪼개기** — `btn_name`을 Event Segmentation의 분류축으로 두면 ‘회원가입 버튼·결제 버튼·취소 버튼…’이 어떻게 다른지를 즉시 본다.
- **새 버튼이 추가돼도** — 새 이벤트를 만들지 않고 `btn_name`에 새 값만 들어오면 분석에 자동 반영. 운영이 가벼움.

반대로 ‘**이벤트로 쪼개야 마땅한 경우**’도 있습니다 — 같은 ‘클릭’이라도 ① UX 요소 유형이 다르면(`click_btn` vs `click_tab` vs `click_gnb`), ② KPI에 직결되는 행동이라면(`sign_up`, `purchase`는 주요이벤트로 별도), 이때는 이벤트를 분리합니다.

## 적용 예시 — 무엇을 이벤트로, 무엇을 속성으로

| 상황 | 이벤트 이름 | 속성에 넣을 것 |
| --- | --- | --- |
| 홈·카테고리·상세 등 **여러 페이지의 GNB 클릭** | `click_gnb` (하나) | `gnb_name` · `page_path`(자동) |
| 상품 상세의 **탭(리뷰·문의·배송) 전환** | `click_tab` (하나) | `tab_name` |
| 같은 모달 안의 **닫기 / 확인 버튼** | `click_popup` (하나) | `popup_name` · `element_name` |
| 일반 CTA 버튼 | `click_btn` (하나) | `btn_name` · `btn_location` |
| 회원가입이 *완료*되는 순간 | `sign_up` (별도 — 주요이벤트) | `method`(google · kakao ·...) |
| 구매가 *완료*되는 순간 | `purchase` (별도 — 주요이벤트) | `transaction_id` · `value` · `currency` · `items` |

요지 — **UX 요소가 같으면 같은 이벤트, 다르면 다른 이벤트.** 회원가입·구매처럼 ‘결과’가 KPI인 행동만 의미론적 이름으로 따로 분리합니다(→ [주요이벤트와 서브이벤트](/wiki/playbook/amplitude-event-taxonomy-checklist/amplitude-key-events-vs-sub-events)).

## 새 이벤트로 쪼갤지 — 5가지 판단 체크리스트

‘이 행동을 별도 이벤트로 만들어야 할까, 속성으로 처리할까?’를 결정할 때 다음 다섯 가지를 차례로 봅니다.**대부분은 속성으로 처리**가 정답이고, 그 모든 질문에 ‘분리’ 쪽 답이 나올 때만 새 이벤트를 만듭니다.

1. **UX 요소 유형이 다른가?** ‘버튼’·‘탭’·‘메뉴’는 사용 맥락이 달라 분석가가 따로 봅니다 → 다르면 분리.
2. **KPI에 직접 영향을 주는 ‘결과’ 행동인가?** 회원가입·구매·로그인·문의 제출 같은 비즈니스 마일스톤은 별도 이벤트(주요이벤트)로.
3. **두 행동을 ‘합쳐서 본 적이 있나/볼 가능성이 있나’?** 합쳐 보고 싶으면 같은 이벤트로(속성으로 구분). 절대 합치지 않을 별개 행동이라면 분리.
4. **속성만으로 구분하기 어려운가?** 같은 속성 키에 너무 많은 종류의 값이 들어가 분석가가 헷갈리면 분리. 반대로 `btn_name` 단일 키로 100가지 버튼을 구분해도 무리 없으면 속성 그대로.
5. **새 이벤트로 만들면 Amplitude 한도가 부담되지 않나?** 비슷한 행동을 50개로 늘리는 결정은 ‘이게 정말 필요한가’를 한 번 더 묻고.

다섯 질문 중 분리할 명백한 근거가 두 개 이상이 아니라면 — **같은 이벤트로 두고 속성으로 차이를 두는** 쪽이 거의 항상 안전합니다.

## Amplitude 한도 관점

세분성 판단은 Amplitude의 운영 한도와도 직결됩니다.

| 한도 항목 | 일반적 권장 | 세분성 결정에 미치는 영향 |
| --- | --- | --- |
| 프로젝트당 이벤트 종류 | ~ **1,000개** 권장 | 이벤트를 잘게 쪼개면 빠르게 닳습니다. 위치·맥락별 이벤트명을 양산하면 1년 안에 도달. |
| 이벤트당 이벤트 속성 | ~ **2,000개** | 속성을 풍부하게 — 다만 한 이벤트가 다 쓸 일은 없습니다. 평균 5~10개가 자연스러움. |
| 프로젝트당 사용자 속성 | ~ **1,000개** | 회원 등급·가입 방식 같은 사용자 상태용. |
| 차트 드롭다운 가독성 | — | 이벤트가 너무 많으면 분석가가 드롭다운에서 원하는 이벤트를 찾기 어려움. ‘찾기 비용’도 한도라고 봐야 함. |

정확한 한도는 요금제와 시기별 정책에 따라 다르니 Amplitude 공식 문서를 확인하세요 — 본 표는 일반적인 설계 의사결정을 도울 어림수입니다.

## 자주 묻는 질문

### 회원가입 버튼만큼은 따로 이벤트를 두는 게 자연스러워 보이는데요?

회원가입은 ‘버튼 클릭’이 아니라 ‘회원가입 완료’가 KPI라 — 표준 권장 이름인 `sign_up`을 ‘완료 시점’에 별도로 보냅니다. 버튼 클릭은 그냥 일반 `click_btn`이고, `btn_name="회원가입"` 속성으로 충분합니다. ‘버튼 클릭’과 ‘가입 완료’는 종(種)이 다른 행동이라 분리, ‘회원가입 버튼’과 ‘다른 버튼’은 같은 종이라 속성으로 — 가 원칙입니다.

### 같은 GNB가 페이지마다 위치가 조금 다르면 어떻게 하나요?

이벤트는 `click_gnb` 하나, 위치는 `page_path`(자동) 또는 `gnb_position` 속성으로 처리합니다. 페이지마다 이벤트 이름을 다르게 만들면 즉시 ‘너무 잘게’의 함정에 빠집니다.

### btn_name에 들어가는 값이 너무 많아지면(수십·수백 종) 문제 아닌가요?

값의 개수 자체는 Amplitude가 문제 삼지 않습니다. 다만 사용자 입력 텍스트가 그대로 들어가면(같은 버튼인데 띄어쓰기·구두점만 다른 값이 양산) 분석이 흐려집니다 — 그래서 `btn_name`의 값을**운영 단계에서 정규화**(공통 표기로 통일)하는 작업이 필요합니다.

### ‘적정 세분성’의 정답은 사이트마다 다른가요?

네 — 그래서 ‘복잡미묘’합니다. 일반적인 원칙(이벤트는 적게·속성은 풍부하게)을 따르면 대부분 맞지만, 사이트의 분석 깊이·운영 인력·KPI 정의에 따라 미세 조정이 필요합니다. 한 가지 안전한 출발선 — **처음에는 보수적으로 ‘조금 더 합치는’ 쪽**으로 시작하고, 운영하면서 ‘분리하지 않아 불편한 지점’이 발견될 때 분리합니다. 일단 만든 이벤트를 합치는 것보다 합쳐 둔 이벤트를 나중에 분리하는 게 훨씬 쉽습니다.

## Navigation

- [전체 플레이북 Markdown sitemap](/wiki/playbook/sitemap.md)

### Amplitude 이벤트 택소노미

- [Amplitude 이벤트 택소노미](/wiki/playbook/amplitude-event-taxonomy-checklist)
- [Amplitude의 로그와 이벤트](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-logs-and-events)
- [Amplitude 이벤트의 구조](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-event-structure)
- [이벤트 택소노미의 정의와 CASE STUDY](/wiki/playbook/amplitude-event-taxonomy-checklist/amplitude-event-taxonomy-case-study)
- [Amplitude 이벤트의 종류](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-event-types)
- [Amplitude 이벤트 이름과 표기법](/wiki/playbook/amplitude-event-taxonomy-checklist/how-to-name-amplitude-events)
- [Amplitude 주요이벤트와 서브이벤트](/wiki/playbook/amplitude-event-taxonomy-checklist/amplitude-key-events-vs-sub-events)
- [Amplitude 이벤트 설계의 세분성](/wiki/playbook/amplitude-event-taxonomy-checklist/how-to-decide-amplitude-event-granularity) (현재 문서)
- [Amplitude 속성 이름과 표기법](/wiki/playbook/amplitude-event-taxonomy-checklist/how-to-name-amplitude-properties)
- [Amplitude 속성의 타입](/wiki/playbook/amplitude-event-taxonomy-checklist/how-to-choose-amplitude-property-types)
- [Amplitude의 이벤트와 속성 4계층](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-event-and-properties)
- [Amplitude의 사용자 식별 — Device ID · User ID · Amplitude ID](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-identity)
- [Amplitude Identify call — set·setOnce·add·append·unset](/wiki/playbook/amplitude-event-taxonomy-checklist/how-to-use-amplitude-identify-call)
- [Amplitude Group Analytics — 회사·팀 단위 분석](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-group-analytics)
- [Amplitude 전자상거래 이벤트 구현](/wiki/playbook/amplitude-event-taxonomy-checklist/how-to-implement-amplitude-ecommerce)