# Amplitude 주요이벤트와 서브이벤트

비즈니스 KPI와 직결되는 ‘주요이벤트(Key Event)’와 그 밖의 행동을 추적하는 ‘서브이벤트’의 차이, 그리고 두 종류의 이름 짓기 방식(의미론적 vs 행동 기술적). Amplitude의 Funnel·Cohort·Retention에서 주요이벤트가 어떻게 활용되는지까지 정리.

- 카테고리: Amplitude 이벤트 택소노미
- 소요 시간: 약 7분
- 난이도: 입문
- 업데이트: 2026.06.01
- 원문: /wiki/playbook/amplitude-event-taxonomy-checklist/amplitude-key-events-vs-sub-events

## 목차

- [한눈에 — 두 종류](#overview)
- [주요이벤트](#key-event)
- [서브이벤트](#sub-event)
- [이름 짓기 비교](#naming)
- [Amplitude에서 어떻게 쓰이나](#amplitude-usage)
- [자주 묻는 질문](#faq)

이벤트는 ‘누가 설치하느냐’(자동 추적·표준 권장·사용자 정의)로도 나뉘지만, ‘**비즈니스 KPI에 직결되는가**’라는 또 하나의 축이 있습니다 — **주요이벤트(Key Event)**와 **서브이벤트**입니다. 이 분류는 같은 이벤트라도 이름을 짓는 방식이 다른 이유와도 직결됩니다. 주요이벤트는 의미론적으로, 서브이벤트는 행동을 직관적으로.

## 한눈에 — 두 종류

| 구분 | ★ 주요이벤트 (Key Event) | 서브이벤트 |
| --- | --- | --- |
| 의미 | 우리 비즈니스의 **KPI와 직결되는** 이벤트. ‘구매’·‘회원가입’·‘리드 제출’처럼 그 자체가 ‘비즈니스의 결과’를 의미하는 행동. | 주요이벤트가 아닌 모든 행동. ‘메뉴 클릭’·‘탭 전환’·‘버튼 누름’처럼 KPI에 도달하는 **경로 위의 발자취**를 채우는 행동. |
| 예시 | `purchase`, `sign_up`, `login`, `generate_lead` | `click_gnb`, `click_btn`, `click_tab`, `submit_survey` |
| 이름 짓는 방식 | 의미론적 이름(semantic event name) — 행위의 ‘결과·의도’를 가리키는 이름 | 사내 `[행위]_[대상]` 컨벤션([이벤트 이름과 표기법](/wiki/playbook/amplitude-event-taxonomy-checklist/how-to-name-amplitude-events)) |
| Amplitude 활용 | Funnel Analysis의 최종 단계, Cohort 정의 기준, 광고 매체 Audience sync 대상 | Funnel 중간 단계, Event Segmentation의 분류축, Pathfinder의 경로 노드 |

> **팁**
>
> **두 축은 별개입니다.** ‘[자동 추적·표준 권장·사용자 정의](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-event-types)’가 *이벤트가 어디서 오는가*의 축이라면, ‘주요/서브’는 *그 이벤트가 비즈니스에 무엇을 의미하는가*의 축입니다. 예) `purchase`는 ‘표준 권장’이면서 ‘주요이벤트’; `click_gnb`는 ‘사용자 정의’이면서 ‘서브이벤트’.

## 주요이벤트 (Key Event)

주요이벤트는 **‘이 행동이 일어났다는 사실 자체가 우리 비즈니스 목표의 달성·진척을 가리키는’ 이벤트**입니다. 쇼핑몰의 구매(`purchase`), 회원제 서비스의 가입(`sign_up`), B2B의 문의 제출(`generate_lead`)이 대표적입니다.

### 이름은 ‘무엇을 했는가’가 아니라 ‘무엇이 일어났는가’

주요이벤트의 이름은 행동의 ‘방법’이 아니라 **‘결과·의도’**를 가리킵니다. 이런 작명을 **의미론적(semantic) 이름**이라 부릅니다.

| 행동(우리가 한 일) | 의미론적 이름 | 왜 이 이름인가 |
| --- | --- | --- |
| 결제 완료 페이지 도달 | `purchase` | 결제 ‘페이지를 봤다’가 아니라 ‘구매가 일어났다’가 KPI라 — 결과 중심의 이름. |
| ‘가입하기’ 버튼 클릭 후 가입 완료 | `sign_up` | ‘버튼을 클릭했다’가 아니라 ‘회원가입이 일어났다’가 KPI. |
| 로그인 완료 | `login` | ‘아이디·비번을 입력했다’가 아니라 ‘로그인이 성공했다’가 KPI. |
| 문의 폼 제출 | `generate_lead` | ‘폼을 제출했다’보다 ‘잠재 고객 한 명이 생겼다’가 KPI 언어에 가까움. |

이런 이름은 두 가지 이유로 중요합니다 — ① 표준 권장 이름과 일치하면 GA4·Amplitude 공통으로 같은 분석이 됩니다. ② 이름 자체가 KPI 언어라, 비개발자(마케터·기획자)와 대화할 때 ‘우리 사이트의 구매가 어제 몇 건’이라고 그대로 통합니다.

> **팁**
>
> **이름 정하는 순서** — ① [표준 권장 이벤트 목록](/wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-event-types)에 같은 의미가 있으면 그 이름을 그대로 씁니다(`purchase`·`sign_up`·`view_item` 등). ② 없으면 사내에서 **의미론적 이름**을 새로 짓습니다(예: `submit_application`, `complete_onboarding`). 이때도 동사+명사 조합이지만, 동사는 ‘결과를 가리키는’ 동사(complete, submit, finish, generate 등)를 씁니다.

## 서브이벤트

서브이벤트는 ‘주요이벤트가 아닌 모든 행동 추적 데이터’입니다. 별도의 Amplitude 공식 명칭은 없지만 — 우리 사내에서는 ‘주요이벤트 외 모든 사용자 정의 이벤트’를 묶어 이렇게 부릅니다.

예: `click_gnb`(글로벌 내비게이션 클릭), `click_btn`(버튼 클릭), `click_tab`(탭 전환), `click_floating`(플로팅 버튼 클릭), `submit_survey`(설문 제출). 모두 ‘무엇을 했는가’를 행동 단위로 잡아 두는 이벤트들입니다.

### 서브이벤트 이름의 제1원칙 — ‘최대한 직관적으로’

> **팁**
>
> **서브이벤트의 이름은 보자마자 ‘어떤 행동인지’가 이해되어야 합니다.** 동사 + 대상이 분명한`[행위]_[대상]` 패턴이 효과적인 이유입니다. `click_gnb`를 보면 누구나 ‘GNB 클릭이구나’를 1초 안에 이해할 수 있어야 합니다.

## 이름 짓기 비교 — 같은 행동, 다른 이름

‘*가입하기 버튼을 클릭해서 가입을 완료한 사용자*’의 경로를 추적한다고 합시다. 같은 경로 위에 있는 두 이벤트를 어떻게 다른 식으로 이름 짓는지 비교해 봅니다.

| 이벤트 | 이름 | 왜 이 이름인가 |
| --- | --- | --- |
| 서브이벤트 (경로 위) | `click_btn` + `btn_name=sign_up` | ‘버튼을 클릭했다’는 행동을 직관적으로. 어떤 버튼인지는 속성으로. |
| 주요이벤트 (KPI) | `sign_up` | ‘회원가입이 일어났다’는 결과를 의미론적으로. 표준 권장 이름. |

두 이벤트는 같은 사용자의 같은 흐름 위에 놓이지만 의도가 다릅니다 — 서브이벤트는 ‘이 버튼이 얼마나 클릭되는가’를 추적하기 위해, 주요이벤트는 ‘우리 KPI인 가입이 얼마나 일어났는가’를 추적하기 위해. 둘은 중복이 아니라 서로 보완합니다.

## Amplitude에서 주요이벤트는 어떻게 쓰이나

Amplitude에는 GA4의 ‘주요 이벤트 마킹’ 같은 명시적 UI는 없지만, 다음 세 곳에서 ‘핵심 이벤트’로 직접 활용됩니다.

- **Funnel Analysis의 마지막 단계.** ‘페이지 조회 → 상품 조회 → 장바구니 → 구매’ 같은 전환 퍼널의 마지막은 거의 항상 주요이벤트입니다.
- **Cohort 정의 기준.** “지난 30일 동안 `purchase` 1회 이상 한 사용자” 같은 코호트는 광고 매체에 잠재고객으로 sync되는 가장 흔한 단위입니다.
- **Retention 차트의 ‘재방문’ 기준 이벤트.** N-day retention의 ‘N일 후에 무엇을 했는가’의 기준 이벤트로 주요이벤트를 자주 사용합니다.

> **완료**
>
> **주요이벤트 목록을 사내 문서에 명시해 두세요.** Amplitude UI 자체가 “이건 주요이벤트 입니다”라고 표시하지 않으므로, 사내 위키나 택소노미 문서에 ‘이 사이트의 주요이벤트 = N개’라고 명시해 두면 분석가가 새 차트를 만들 때 헷갈리지 않습니다.

## 자주 묻는 질문

### Amplitude에 ‘주요 이벤트 마킹’ 같은 UI가 정말 없나요?

Govern 메뉴(유료 Amplitude Data)에서 이벤트마다 ‘Category’를 부여할 수는 있지만, GA4 같은 ‘토글로 주요 이벤트 표시’ 기능은 없습니다. 대신 차트·코호트·광고 매체 연동 시 ‘*이 이벤트를 KPI 기준으로 쓰겠다*’는 결정을 그때그때 합니다. 그래서 어떤 이벤트가 주요인지 사내에 합의·문서화해 두는 것이 중요합니다.

### 같은 행동을 주요이벤트와 서브이벤트로 둘 다 보내면 중복 아닌가요?

중복이 아니라 ‘다른 시점·다른 의미’로 보는 두 이벤트입니다. `click_btn`은 ‘버튼이 눌렸다’는 사실을, `sign_up`은 ‘가입이 완료됐다’는 결과를 추적합니다. 사용자가 가입 버튼을 눌렀지만 약관 동의를 안 해서 가입이 완료되지 않은 경우라면 — `click_btn`은 발생, `sign_up`은 미발생이 됩니다. 두 이벤트를 비교하면 ‘버튼은 눌렸는데 완료까지 못 간 비율’이 나옵니다.

### 회원가입을 sign_up과 submit_join 둘 다 쓰면 안 되나요?

**안 됩니다.** 같은 KPI(회원가입)를 두 이름으로 보내면 합산할 때마다 두 이벤트를 더해야 하고, 빠뜨리는 순간 분석이 어긋납니다. 표준 권장 이름인 `sign_up` 하나로 통일하세요.

### 주요이벤트는 몇 개 정도가 적당한가요?

서비스 규모에 따라 다르지만 보통 **5~15개** 정도가 일반적입니다. 너무 많으면 ‘진짜 중요한 게 뭐였지’가 흐려지고, 너무 적으면 분석 가능한 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)