# 이벤트의 구조

이벤트는 ‘정보 전달의 최소 단위’입니다. 자동차 비유로 개체-속성 사고에서 출발해, 이벤트와 프로퍼티, 변수(Key/Value), 이벤트 매개변수, 그리고 GA4 측정기준까지 한 흐름으로.

- 카테고리: 이벤트 택소노미
- 소요 시간: 약 8분
- 난이도: 입문
- 업데이트: 2026.05.14
- 원문: /wiki/playbook/ga4-event-taxonomy-checklist/what-is-event-structure

## 목차

- [구매 이벤트 예시](#purchase-example)
- [변수(Variable)로 쪼개기](#variable)
- [KEY와 VALUE](#key-value)
- [이벤트 매개변수](#parameter)
- [KEY가 측정기준이 되면](#ga4-dimension)
- [자주 묻는 질문](#faq)

이벤트는 ‘정보 전달의 **최소 단위**’입니다. 그런데 이름 하나만 가지고는 ‘무엇이 어떻게 일어났는지’를 다 전할 수 없죠 — 그래서 이벤트는 늘 그 사건을 설명하는 부가 정보(프로퍼티·매개변수)를 함께 데리고 다닙니다. 이 글은 길에서 본 ‘아반떼’ 이야기로 시작해서, 이벤트의 구성요소가 어떻게 변수(Key/Value)로 분해되고, 그것이 어떻게 GA4의 ‘측정기준’으로 이어지는지를 따라갑니다.

## 정보를 전달하는 최소 단위, 이벤트(Event)

수백 대의 차량이 지나가고 있습니다. 그중 저는 제가 봤던 한 대의 아반떼 차량이 지나간다는 것을 친구한테 말해 주고 싶습니다. 그래서 저는 친구한테 말합니다.

“친구야, 자동차가 지나간다!”

이렇게 ‘자동차가 지나간다’는 말로는 제가 가리키는 특정 한 대를 지칭할 수가 없습니다. 그래서 저는 자동차가 가지고 있는 성격을 함께 표현합니다.

“저 자동차의 이름은**아반떼**고, 색깔은**흰색**이고, 번호판은**1752**이고, 시속은**60km/h**야!”

이렇게 제가 설명하려는 차량이 가지고 있는 성격들을 여러 가지로 열거하여 친구에게 정보를 전달하는 것이지요.

친구에게 정보를 전달할 때, **정보 전달의 대상**이 되는 것을 우리는 사물 또는 대상이라는 의미를 가지고 있는 **개체(Object)**라고 부릅니다. 그리고 좀 더 구체적으로 특정 차량을 지목하기 위해 해당 차량이 가지고 있는 성격을 열거하는데, 이 열거된 정보들은 차량이 가지고 있는 성질 또는 특징을 의미하며, 그 대상이 가지고 있는 **속성(Attribute)**이라고 부릅니다.

> **다이어그램 설명:** 자동차 비유 그림 — 좌측 위에 ‘이건 자동차야!’라는 주황색 박스가 있고 그 아래로 ‘이름은 아반떼야 / 색깔은 흰색이야 / 번호판은 1752이야 / 속도는 60km/h야’ 네 개의 박스가 세로로 나열되며, 우측에 ‘설명의 대상(Object)’과 ‘대상이 가지고 있는 성질(Attribute)’ 두 박스가 화살표로 연결된 모습

‘자동차’ 그 자체가 **설명의 대상(Object)**이고, 그 자동차가 가지고 있는 이름·색깔·번호판·속도가 각각 **대상의 속성(Attribute)**입니다.

구글 애널리틱스를 비롯한 분석툴은 같은 원리로 데이터를 적재합니다. 실제로 웹사이트에 방문하는 순간, GA4는 아래와 비슷한 방식으로 데이터를 보냅니다.

예시 — 페이지뷰 이벤트

event: page_view page_title: "허들러스 — 홈" page_location: "https://hurdlers.kr/" page_referrer: "https://google.com/" language: "ko"

여기서 `page_view`는 설명의 **대상(Object)**이 되는 동시에, 정보를 전달하는 가장 작은 단위인 **이벤트(EVENT)**입니다. 또 그 이벤트의 추가 정보를 제공해 주기 위해 속성(Attribute) 정보를 추가로 제시하는데, 이 정보를 우리는 전문 용어로 **프로퍼티(Property)**라고 부릅니다.

마치 오브젝트와 오브젝트가 가지고 있는 성질을 가지고 누군가에게 정보를 전달하는 것처럼, 로그 데이터는 **이벤트와 이벤트가 가지고 있는 성질**을 데이터로 전송합니다. 그렇습니다 — 이벤트는 고객이 웹/앱에서 행동하는 하나의 상호작용을 나타내는 단위이며, **이벤트와 프로퍼티**로 구성요소가 나뉘어져 있습니다.

## 예시 — 쇼핑몰의 구매 완료 이벤트

우리가 쇼핑몰을 운영한다고 생각해 봅시다. 실제로 고객이 구매 완료 페이지에 도착했을 때, 우리는 아래와 같은 형태로 데이터를 전송하게 됩니다.

> **다이어그램 설명:** 구매 이벤트의 자연어 표현 그림 — 좌측 위에 ‘구매가 발생했어!’라는 주황색 박스가 있고 그 아래로 ‘제품 이름은 티셔츠야 / 제품 가격은 8000원이야 / 통화는 KRW야 / 제품 컬러는 검정색이야’ 네 개의 박스가 세로로 나열되며, 우측에 EVENT·PROPERTY 두 박스가 화살표로 연결된 모습

자동차 비유 그대로입니다 — ‘구매가 발생했어!’가 우리가 설명하려는 **이벤트(EVENT)**이고, 제품 이름·가격·통화·컬러는 그 이벤트의 **프로퍼티(PROPERTY)**입니다.

이것을 그대로 데이터로 전송하는 ‘코드 방식’으로 변환하면 아래와 같은 모습이 됩니다.

> **다이어그램 설명:** 구매 이벤트의 코드 표현 그림 — 좌측에 purchase 이벤트 이름과 4개 프로퍼티(item_name·item_price·currency·item_color)가 JSON 형태로 나열되고, 우측에 EVENT·PROPERTY 박스가 화살표로 연결된 모습

앞 그림과 같은 정보를 코드 형태로 옮긴 것뿐입니다. 같은 정보가 ‘말하기 좋은 형태’와 ‘기계가 읽기 좋은 형태’ 두 모습으로 표현된 셈입니다.

## 프로퍼티(Property)를 한 번 더 쪼개 보자 — 변수(Variable)

위 그림에서는 실제 우리 웹사이트에 방문해서 구매가 발생할 때, 전송되는 이벤트와 프로퍼티를 단순하게 보여 주고 있습니다. 여기서 우리는 프로퍼티를 좀 더 해부해 보겠습니다. 지금 보면 프로퍼티를 구성하고 있는 성질이 총 4가지가 있습니다 — **제품 이름·제품 가격·통화·제품 컬러**. 이 속성을 구성하고 있는 요소들은 좀 더 쪼갤 수 있습니다. 4개의 속성은 각각 **변수(variable)**라는 단위로 불립니다.

> **팁**
>
> **변수라는 개념을 이해하는 것은 매우 중요합니다.** 데이터는 모두 변수의 형태로 저장되기 때문입니다. 변수란,*그 정보를 저장하고 있는 공간의 이름*과,*정보 그 자체*를 의미합니다.

철수가 가지고 있는 돈이 2,000원이지만, 1,000원짜리 아이스크림을 사 먹는다면, 철수가 가지고 있는 돈은 1,000원입니다. **2,000원에서 1,000원으로 정보는 바뀌었지만, 정보를 담고 있는 공간의 이름 — 즉 ‘철수가 가지고 있는 돈’이라는 이름은 바뀌지 않았습니다.**

변수 = 이름 + 그 안에 든 값

철수가 가지고 있는 돈 = 2000 ← 아이스크림 사기 전 철수가 가지고 있는 돈 = 1000 ← 아이스크림 사고 난 후 └─────────┬─────────┘ └──┬──┘ ‘이름(공간)’ ‘값(내용)’ — 그대로 — 바뀜

이벤트의 프로퍼티도 마찬가지입니다. 프로퍼티 역시 변수 형태로 저장되어 있습니다. 이렇듯 **정보를 담고 있는 공간의 이름과 정보 그 자체를 묶어서 우리는 변수**라고 부릅니다.

## KEY와 VALUE — 변수의 두 부분

여기서 조금 더 전문적인 용어를 사용하자면, 연산자(`=`)를 기준으로 **좌측**에 있는 ‘정보를 담는 그릇’을 우리는 **KEY**라고 부르고, **우측**에 있는 ‘정보 그 자체’를 **VALUE**라고 부릅니다.

KEY와 VALUE

item_color = "white" ─────── ─────── KEY VALUE (담는 그릇) (담긴 내용)

|  | KEY | VALUE |
| --- | --- | --- |
| 정의 | 정보를 담는 그릇(공간의 이름) | 그 그릇에 든 정보 그 자체 |
| 설계 단계에서 | **우리가 미리 정해 두는 것** — 어떤 이벤트에 어떤 키를 같이 보낼지 | 고객 행동에 따라 그때그때 들어오는 것 |
| 예시 | `item_color`, `item_price`, `currency` | `"white"`, `89000`, `"KRW"` |

## 총 정리 — 이벤트 매개변수(Event Parameter)

정보를 전달할 때에는 이벤트를 전송하는데, 정보가 부족할 경우 이벤트에 변수 형태로 이벤트의 추가적인 속성(Property)을 변수(Variable) 형태로 함께 전달합니다. 이 순간 각각의 변수들은 이벤트에 대한 추가적인 정보를 제공해 주는 매개체의 역할을 하기 때문에, 우리는 이들을 **이벤트 매개변수(Event Parameter)**라고 부릅니다.

> **다이어그램 설명:** purchase 이벤트의 종합 구조 그림 — 좌측 말풍선이 이벤트 매개변수 개념을 설명하고, 중앙에 purchase 이벤트의 4개 속성이 각각 KEY와 VALUE로 분해되어 나열되며 첫 번째 줄이 ‘변수’로 강조되어 있고, 우측에 EVENT·PROPERTY 박스가 화살표로 연결된 모습

한 그림에 다 모았습니다 — 이벤트(EVENT) + 변수(Key/Value) 4개(PROPERTY). 각 변수가 이벤트의 추가 정보를 제공해 주는 ‘매개체’이기 때문에 이 변수들을 묶어 ‘**이벤트 매개변수**’라고 부릅니다.

| 분류상의 이름 | 우리가 보내는 데이터에서 | 이번 글에서 본 예시 |
| --- | --- | --- |
| 개체(Object) | 이벤트(Event) | `purchase` · `page_view` |
| 속성(Attribute) | 프로퍼티(Property) = 이벤트 매개변수(Parameter) | `item_color`, `item_price`, … |
| 속성을 담는 형태 | 변수(Variable) = KEY + VALUE | `item_color = "white"` |

## KEY가 ‘측정기준’이 되면 — GA4에서의 활용

이렇게 이벤트 + 매개변수의 형태로 데이터를 전송하면, 우리는 GA4·엠플리튜드·믹스패널 같은 분석툴에서 다양한 방법으로 활용할 수 있습니다. 이번 가이드에서는 GA4에서의 활용을 한 가지만 짚어 보겠습니다.

데이터를 보낼 때 **매개변수의 KEY가 GA4의 측정기준이 되는 순간, 우리는 훨씬 많은 데이터를 관측할 수 있습니다.** 여기서 **측정기준(Dimension)**이란, *데이터를 바라보는 기준*을 의미합니다. 아래는 GA4의 대표적인 리포트인 ‘인구통계 세부정보’ 리포트의 모양새입니다.

GA4 ‘인구통계 세부정보’ 리포트를 단순화한 모습. 표의 가장 왼쪽 주황색 열이 ‘**국가**’ — 즉 **측정기준**이고, 그 옆이 활성 사용자·참여율 같은 ‘측정항목’입니다. 측정기준을 바꾸면 같은 데이터를 ‘기기’별로도, ‘소스/매체’별로도, ‘페이지 경로’별로도 볼 수 있습니다.

위 표는 측정기준이 ‘**국가**’인 리포트이며, 국가별로 방문자 수, 참여율과 같은 다양한 지표들을 관측할 수 있습니다. 표의 가장 왼쪽이 ‘데이터를 바라보는 기준’이라 하여 **측정기준(Dimension)**이라 부릅니다.

다시 위에서 언급한 명제로 돌아가 봅시다 — **KEY가 측정기준이 되면 우리는 더 많은 것을 볼 수 있다**는 것이죠. 예를 들어 구매(`purchase`)라는 이벤트에 매개변수 4개를 넣었고, 그 안에 `item_color`라는 ‘제품의 컬러’를 담은 변수를 매개변수의 형태로 전송할 때, 우리가 `item_color`를 측정기준으로 설정하면 다음과 같은 것을 볼 수 있습니다.

측정기준을 `item_color`로 설정한 결과. 어느 컬러가 가장 많이 팔렸는지(블랙·화이트), 어느 컬러의 ‘구매당 평균 수익’이 가장 높은지(블랙)를 한 표에서 볼 수 있습니다. 이런 분석이 가능한 이유는 단 하나 — 구매 이벤트에 `item_color`를 매개변수로 함께 보내 두었기 때문입니다.

어떤 컬러가 인기가 있었는지, 어떤 컬러의 수익이 높은지 등을 GA4에서 쉽게 관측할 수 있습니다. 이렇듯 **이벤트 하나에 매개변수를 추가하면 추가할수록 우리는 더 많은 것을 관측**할 수 있습니다.

## 자주 묻는 질문

### ‘프로퍼티’와 ‘매개변수(Parameter)’는 다른 건가요?

같은 것을 가리키는 다른 단어입니다. Mixpanel·Amplitude 문서는 ‘프로퍼티(Property)’를, GA4 문서는 ‘매개변수(Parameter)’를 씁니다. ‘이벤트에 따라붙는 속성(Attribute) 한 줄’이라는 점에서 본질은 같습니다. 본 위키는 GA4가 기준이라 주로 **매개변수**로 표기합니다.

### 매개변수는 많이 붙일수록 무조건 좋은가요?

‘분석에 쓸 것’이라면 좋습니다 — 매개변수가 많아질수록 그만큼 ‘쪼개서 볼 수 있는 축’이 늘어나기 때문입니다. 다만 GA4에는 한 이벤트가 가질 수 있는 매개변수 개수에 한도가 있고(약 25개), 보고서에서 이름으로 보려면 따로 ‘맞춤 측정기준’으로 등록해야 하는데 이 한도도 빠듯합니다(이벤트 범위 약 50개). 그래서 ‘일단 다 보내고 보자’보다 **‘분석에 쓸 것 위주’**가 현실적인 기준입니다.

### KEY는 우리가 정하고 VALUE는 정하지 않는 건가요?

네 — 설계 단계에서 우리가 ‘약속해 두는 것’은 KEY 쪽입니다. “구매 이벤트에는 `item_color`·`item_price`·`currency`를 같이 보낸다”처럼요. VALUE는 고객의 실제 행동·상황에 따라 그때그때 들어옵니다(`"white"`일 때도, `"black"`일 때도). ‘이벤트 택소노미’가 다루는 영역은 KEY 쪽 약속입니다.

### ‘측정기준’이 안 되는 매개변수도 있나요?

모든 매개변수가 자동으로 측정기준이 되지는 않습니다. GA4는 우리가 보낸 매개변수 중 ‘맞춤 측정기준/측정항목’으로 **등록한 것**만 보고서·탐색에서 이름으로 골라 쓸 수 있게 합니다. 등록하지 않아도 데이터는 쌓이지만(BigQuery에서는 보입니다), GA4 UI에서 ‘쪼개서 보기’를 하려면 등록이 필요합니다.

### ‘이벤트=개체(Object)’라는 비유, 너무 단순화한 거 아닌가요?

맞습니다 — 엄밀히는 객체지향(OOP)에서의 Object와 분석툴의 Event는 결이 다릅니다. 다만 ‘**설명의 대상**’과 ‘**그 대상의 성질을 열거**’한다는 사고 구조는 같아서, 이 글에선 교육용 비유로 사용했습니다. 실제 데이터 모델링에서는 둘을 섞어 쓰지 않도록 주의하세요.

## 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)