# 이벤트 이름과 표기법

이벤트 이름은 [행위]_[대상] 패턴(click_gnb)으로 짓습니다. snake_case·camelCase·kebab-case의 차이와, GA4 표준이 왜 snake_case인지, 그리고 사람이 짓는 이름에 표기법이 왜 필요한지를 정리.

- 카테고리: 이벤트 택소노미
- 소요 시간: 약 7분
- 난이도: 입문
- 업데이트: 2026.05.14
- 원문: /wiki/playbook/ga4-event-taxonomy-checklist/how-to-name-ga4-events

## 목차

- [왜 표기법이 필요한가](#why-notation)
- [snake / camel / kebab](#cases)
- [왜 snake_case?](#snake-case)
- [이름의 기술 규칙](#rules)
- [자주 묻는 질문](#faq)

이벤트 이름은 결국 **사람이 짓고, 사람이 입력**합니다. 같은 행동이 사람마다 다른 모양으로 적히면 GA4는 모두 ‘다른 이벤트’로 인식하므로, 한 가지 약속을 정해 두지 않으면 보고서가 흩어집니다. 이 글은 허들러스의 이벤트 이름 패턴 — `[행위]_[대상]` — 과, GA4 표준 표기법인 **snake_case**를 왜·어떻게 쓰는지를 정리합니다.

## 이름 패턴 — `[행위]_[대상]`

이벤트 이름은 두 조각으로 만듭니다. **앞쪽**에는 고객의 ‘행위’를 나타내는 동사가, **뒤쪽**에는 그 행위의 ‘대상’이 되는 명사가 들어가고, 두 조각 사이를 언더바(`_`)로 잇습니다.

> **다이어그램 설명:** 이벤트 이름 패턴 그림 — click_gnb가 click(행위/동사)과 gnb(대상/명사) 두 부분으로 나뉘고, 사이에 언더바가 위치한 모습

앞은 ‘무엇을 했나(행위)’, 뒤는 ‘무엇에 대해(대상)’ — 두 조각을 언더바로 잇는 단순한 규칙 하나로 이벤트 이름의 90%가 결정됩니다.

| 이벤트 이름 | 행위(앞) | 대상(뒤) | 의미 |
| --- | --- | --- | --- |
| `click_gnb` | click | gnb | 글로벌 내비게이션의 어떤 항목을 클릭함 |
| `click_btn` | click | btn | 일반 버튼·CTA를 클릭함 |
| `click_tab` | click | tab | 탭을 전환함 |
| `view_item` | view | item | 상품 상세 페이지를 봄(추천 이벤트) |
| `submit_survey` | submit | survey | 설문을 제출함 |
| `play_video` | play | video | 영상 재생을 시작함 |

이 패턴의 장점은 단순합니다 — 이벤트 목록만 봐도 ‘무엇을 한 것’인지 즉시 보이고, **같은 행위끼리**(모든 `click_*`) 또는 **같은 대상끼리**(모든 `*_gnb`) 묶어서 분석할 수 있습니다. 동사·명사 어휘를 어떻게 좁혀 둘지에 대한 규약은 별도 글(‘이벤트 이름 짓는 규칙’)에서 더 자세히 다룹니다.

## 왜 ‘표기법’이라는 게 필요한가?

이벤트 이름은 사람이 짓고, 사람이 코드/태그에 입력합니다. 그런데 컴퓨터는 글자를 ‘하나하나 정확히’ 비교합니다. **사람 눈에는 같아 보이는 두 이름이 GA4에는 완전히 다른 이벤트**로 들어옵니다.

‘GNB 클릭’이라는 한 가지 행동을, 한 사이트의 여러 사람이 각자 다른 식으로 적었다고 해 봅시다.

> **다이어그램 설명:** 컨벤션 부재 시의 혼란을 보여 주는 그림 — ‘GNB 클릭’이라는 같은 의미를 4가지 모양으로 적은 결과(clickgnb, click_gnb, clickGnb, Click-Gnb)가 GA4에서는 모두 다른 이벤트로 인식되어 보고서가 무너지는 모습

한 회사 안에서 표기법 약속이 없으면 같은 행동이 여러 이름으로 흩어지고, ‘무엇을 합쳐서 봐야 하는지’를 사람이 매번 정리해야 합니다. 합치다 빠지는 항목이 생기면 그 자체로 분석 오류.

> **팁**
>
> **표기법(case style)이란**— 사람이 머릿속에서는 ‘띄어쓰기로 분리해서’ 부르는 단어 묶음(예: ‘click gnb’)을, 시스템이 받아들이는 이름(공백 없음·단일 토큰) 하나로 옮길 때**‘띄어쓰기 자리에 무엇을 넣을지’의 약속**을 말합니다. 약속이 한 가지로 통일되어 있으면, 누가 적든 같은 의미는 같은 이름이 됩니다.

## 대표 표기법 — snake / camel / kebab

같은 두 단어 ‘click gnb’를 각 표기법으로 옮기면 다음과 같이 달라집니다.

snake_case (GA4 표준)

click_gnb

띄어쓰기 자리에 **언더바(_)**를 넣고, 글자는 모두 소문자. Python·SQL·BigQuery에서 표준.

camelCase

clickGnb

두 번째 단어부터 **첫 글자만 대문자**. JavaScript·Java 변수/메서드에서 표준.

kebab-case

click-gnb

띄어쓰기 자리에 **하이픈(-)**. URL·CSS 클래스명에선 표준 — GA4 이벤트 이름에선 비권장(아래 ‘기술 규칙’ 참고).

PascalCase

ClickGnb

모든 단어 첫 글자 대문자. 클래스명·React 컴포넌트에서 표준 — 이벤트 이름엔 거의 안 씀.

각 표기법은 어느 분야에서 출발했느냐의 차이일 뿐, 정답은 없습니다. 다만 한 시스템 안에서는 **한 가지로 통일하는 것**이 정답이고, GA4 환경에서는 그 한 가지가 **snake_case**입니다.

## 왜 GA4는 snake_case인가

GA4의 자동 수집·향상된 측정·추천 이벤트가 모두 snake_case로 정의되어 있습니다 — `page_view`, `session_start`, `first_visit`, `sign_up`, `add_to_cart`, `begin_checkout`, `view_item`… 우리가 만드는 맞춤 이벤트도 같은 모양을 따르는 것이 자연스럽습니다.

| 이유 | 내용 |
| --- | --- |
| GA4 표준이 그렇게 되어 있음 | 자동/추천 이벤트와 맞춤 이벤트가 같은 표기법이라야 보고서에서 ‘이것은 자동 이벤트, 저것은 우리가 만든 이벤트’의 시각적 일관성이 유지됩니다. |
| BigQuery·SQL 친화 | GA4 → BigQuery 내보내기를 켜면 이벤트 이름이 그대로 컬럼 값으로 들어갑니다. SQL에서 대소문자 섞인 식별자는 따옴표 처리가 필요해 쿼리가 지저분해지지만, 모두 소문자면 그런 부담이 없습니다. |
| 오탈자 노출 최소화 | ‘대소문자만 다른’ 실수(`Click_Gnb` vs `click_gnb`)가 사라집니다. 모두 소문자이므로 사람의 손이 헷갈릴 여지가 줄어듭니다. |
| 한국어 가독성 | 한국어를 모국어로 쓰는 사람의 눈에는 `click_gnb`가 `clickGnb`보다 단어 경계가 명확히 보입니다(언더바가 시각적 공백 역할). |

## 이벤트 이름의 기술 규칙

GA4가 요구하는 기술적 제약 + 사내 규약을 한 표로 정리합니다.

| 규칙 | GA4 공식 명세 | 사내 규약(허들러스) |
| --- | --- | --- |
| 시작 문자 | 문자로 시작 (숫자·언더바·기호로 시작 금지). 시작이 잘못되면 GA4가 이벤트를 무시. | 영문 소문자로 시작 |
| 허용 문자 | 문자(영문·다국어 모두 포함), 숫자, 언더바(`_`). 공백·특수문자 금지. | 영문 소문자·숫자·`_`만 |
| 하이픈(`-`) | 공식 미허용. 일부 환경에서 Google이 자동으로 `_`로 치환하지만 보장되지 않음. | 아예 안 씀(자동 치환 의존 회피) |
| 한글 등 비영문 | 기술적으로 허용(‘non-English letters’ 명시). | 사용 안 함 — UTF-8에서 한 글자 3바이트라 메모리·전송 효율↓, 한·영 전환과 받침 입력으로 오탈자 확률↑, BigQuery·SQL·URL 처리 부담 |
| 대소문자 | 대소문자 구분(case-sensitive). `Click_Gnb`와 `click_gnb`는 다른 이벤트. | 모두 소문자(대소문자 실수 원천 차단) |
| 길이 | 40자 이내. 초과분은 잘림(다국어도 한 글자당 1자로 계산). | 의미가 통하는 가장 짧은 이름 |
| 예약 접두사 | `ga_` · `google_` · `firebase_`로 시작 금지. 위반 시 GA4가 무시할 수 있음. | 동일 |
| 개수 | 한 속성당 고유 이벤트 이름 약 500개까지(맞춤 이벤트 기준). | ‘분석에 쓸 것’ 위주로 설계 |

> **주의**
>
> **이벤트 이름은 한번 적재되면 바꾸기 어렵습니다.** GA4의 ‘이벤트 수정·생성’ 기능으로 사후에 이름을 매핑·합칠 수는 있지만,*과거 데이터는 그대로*남고 새 이름으로만 합쳐집니다. 그래서 초기 설계에 표기법 통일이 중요합니다.

## 자주 묻는 질문

### `click`과 `tap`을 구분해야 하나요?

본 위키는 웹·앱 모두 **`click`**으로 통일합니다. 모바일 환경에서도 ‘탭’이라는 행동이 결국 ‘클릭’과 분석상 같은 의미를 가지기 때문에, 두 단어를 섞어 쓰면 합산할 때마다 불편해집니다. (구분이 꼭 필요하면 매개변수에 `device_type`을 함께 보내는 방식을 권장합니다.)

### 동사 종류는 몇 개나 쓰면 적당한가요?

본 위키는 5개로 좁혀 둡니다 — `click`, `view`, `submit`, `play`, `search`. 그 외의 행동도 대부분 이 다섯 중 하나로 분류됩니다(`select_tab` 대신 `click_tab`, `open_popup` 대신 `click_popup`). 자세한 동사 어휘는 ‘이벤트 이름 짓는 규칙’ 글에서 다룹니다.

### 패턴을 벗어나는 이벤트도 있나요?

네 — GA4 **추천 이벤트**는 `sign_up`·`purchase`·`add_to_cart`처럼 ‘의미론적 이름’(동사 단독·동사+대상이 자유 형태)을 씁니다. 추천 이벤트는 GA4가 이미 이름을 정해 둔 영역이라 본 위키의 `[행위]_[대상]` 패턴을 강제하지 않습니다 — 추천 이벤트는 그 이름 그대로 쓰는 게 표준입니다(→ [GA4 이벤트의 종류](/wiki/playbook/ga4-event-taxonomy-checklist/what-is-ga4-event-types)).

### 이름에 한글을 넣으면 안 되나요?

‘기술적으로 안 되는 것’은 아닙니다 — GA4 공식 명세는 이벤트 이름에 ‘English and non-English letters’를 모두 허용한다고 명시하고 있어, `click_핫딜` 같은 이름도 통과 자체는 됩니다. 다만 **실무에서는 권장하지 않습니다**:

- **메모리·전송 효율 ↓** — 한글은 UTF-8 기준 한 글자당 **3바이트**(UTF-16에선 2바이트지만 GA4·BigQuery·웹은 UTF-8 표준). 이름·인덱스·로그 어디에 들어가든 영문보다 부피가 큽니다.
- **오탈자 확률 ↑** — 한·영 키보드 전환과 받침이 있는 조합형 한글 입력 특성상, 사람이 같은 이름을 매번 정확히 적기 어렵습니다.
- **운영 부담 ↑** — BigQuery SQL·URL 인코딩·외부 분석 도구 연동 단계마다 별도 처리가 필요해 유지보수 손이 더 갑니다.

그래서 이름은 영문 소문자로만 만들고, 한글 콘텐츠(예: ‘핫딜’이라는 메뉴 이름)는 **매개변수 값**으로 보냅니다 — 예: `click_gnb` + `gnb_name="핫딜"`. 이름은 ‘무엇을 했나’의 유형까지만, 한국어 콘텐츠는 값으로 — 라는 분리가 핵심입니다.

### 이미 운영 중인 사이트에 표기법이 섞여 있으면 어떻게 하나요?

두 가지 동시 처리 — ① 신규 이벤트는 무조건 snake_case로 통일하고, ② GA4의 ‘**이벤트 수정**’ 기능으로 기존의 `clickGnb`·`ClickGnb` 같은 변형을 `click_gnb`로 매핑해 줍니다. 과거 데이터까지 소급되지는 않지만, ‘앞으로의 데이터는 한 이름으로 모이게’ 만들 수 있습니다.

### 왜 kebab-case는 안 쓰나요? — 하이픈도 받긴 받지 않나요?

받는 경우도 있고, 안 받는 경우도 있어 ‘일관되지 않음’이 문제입니다. GA4 공식 명세에는 허용 문자가 **letters · digits · underscores**로 한정되어 있어 하이픈은 공식 미허용입니다. 다만 실제 동작상 Google이 하이픈을 자동으로 언더바로 치환해 받아 주는 사례가 있어 — `click-gnb`가 `click_gnb`로 바뀌어 들어올 수 있습니다. 이 자동 치환은 **보장된 동작이 아니므로**, ‘하이픈이 항상 안전하다’고 가정하면 곤란합니다.

그리고 보장되더라도 **snake_case가 더 편합니다** — GA4 자동/추천 이벤트가 모두 snake_case라 우리 맞춤 이벤트도 같은 스타일을 따르는 게 시각적으로 일관되고, BigQuery SQL에서도 하이픈 식별자는 따옴표 처리가 필요해 번거롭습니다. 그래서 본 위키는 “하이픈 안 됨”보다 **“snake_case 하나로 통일”**이라는 표현을 씁니다.

## Navigation

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

### 이벤트 택소노미

- [이벤트 택소노미](/wiki/playbook/ga4-event-taxonomy-checklist)
- [로그와 이벤트](/wiki/playbook/ga4-event-taxonomy-checklist/what-is-logs-and-events)
- [이벤트의 구조](/wiki/playbook/ga4-event-taxonomy-checklist/what-is-event-structure)
- [이벤트 택소노미의 정의와 CASE STUDY](/wiki/playbook/ga4-event-taxonomy-checklist/ga4-event-taxonomy-case-study)
- [이벤트 택소노미 문서 — 설계 담당자용](/wiki/playbook/ga4-event-taxonomy-checklist/event-taxonomy-document-for-designers-guide)
- [이벤트 택소노미 문서 — 개발자용](/wiki/playbook/ga4-event-taxonomy-checklist/how-to-implement-event-taxonomy-for-developers)
- [Data Layer와 GTM — 이벤트 태깅의 큰 그림](/wiki/playbook/ga4-event-taxonomy-checklist/data-layer-and-gtm-guide)
- [GA4 이벤트의 종류](/wiki/playbook/ga4-event-taxonomy-checklist/what-is-ga4-event-types)
- [이벤트 이름과 표기법](/wiki/playbook/ga4-event-taxonomy-checklist/how-to-name-ga4-events) (현재 문서)
- [주요이벤트와 서브이벤트](/wiki/playbook/ga4-event-taxonomy-checklist/key-events-vs-sub-events)
- [이벤트 이름 설계의 세분성(granularity)](/wiki/playbook/ga4-event-taxonomy-checklist/how-to-decide-event-granularity)
- [파라미터 이름과 표기법](/wiki/playbook/ga4-event-taxonomy-checklist/how-to-name-ga4-parameters)
- [파라미터의 타입(type)](/wiki/playbook/ga4-event-taxonomy-checklist/how-to-choose-ga4-parameter-types)
- [파라미터의 수준(level)](/wiki/playbook/ga4-event-taxonomy-checklist/what-is-ga4-parameter-levels)
- [GA4 맞춤 측정기준 등록하기](/wiki/playbook/ga4-event-taxonomy-checklist/how-to-register-ga4-custom-dimensions)
- [GA4 전자상거래란?](/wiki/playbook/ga4-event-taxonomy-checklist/what-is-ga4-ecommerce)
- [전자상거래 이벤트를 이해하기 위한 프로그래밍 지식](/wiki/playbook/ga4-event-taxonomy-checklist/ecommerce-event-programming-guide)
- [전자상거래 리포트 100% 이해하기](/wiki/playbook/ga4-event-taxonomy-checklist/ga4-ecommerce-reports-guide)