# Amplitude의 로그와 이벤트

Amplitude 분석 데이터 설계 입문. 로그(log)라는 단어의 어원부터, ‘이벤트’의 정의, 그리고 ‘무엇이 궁금한지’를 먼저 열거해야 하는 이유까지 정리합니다.

- 카테고리: Amplitude 이벤트 택소노미
- 소요 시간: 약 6분
- 난이도: 입문
- 업데이트: 2026.06.01
- 원문: /wiki/playbook/amplitude-event-taxonomy-checklist/what-is-amplitude-logs-and-events

## 목차

- [로그(log)의 어원](#log)
- [이벤트란](#event)
- [‘무엇이 궁금한지’부터](#questions-first)
- [블로그 예시](#blog-example)
- [분석툴의 공통 단위](#event-as-unit)
- [자주 묻는 질문](#faq)

Amplitude는 사용자의 행동을 **이벤트(Event)** 단위로 적재해 분석하는 도구입니다. 그런데 Amplitude·GA4·Mixpanel 같은 도구들을 흔히 ‘**로그 분석 툴**’이라고 부릅니다 — ‘로그(log)’라는 단어부터 개발 지식이 없는 분들에게는 낯설게 느껴지죠. 그래서 이 글은 로그라는 단어의 어원부터 풀어, 이벤트의 정의, 그리고 데이터 설계 전에 ‘무엇이 궁금한지’를 먼저 정해야 하는 이유까지 정리합니다.

## 로그(log) — ‘배에 매단 통나무’에서 온 단어

흔히 ‘로그’를 ‘항해 일지’에서 온 단어로 소개하지만, 정확히는 그 *한 단계 전*에 어원이 있습니다.** 로그(log)**는 본래 **‘통나무 조각’**을 가리키는 말이었고, 1600년경 선원들이 줄에 매단 작은 통나무(*chip log*)를 바다에 던져 **배의 속도를 측정**한 데서 항해 용어로 자리 잡았습니다. 줄에는 매듭(knot)이 일정 간격으로 묶여 있어, 일정 시간 동안 풀려 나간 매듭의 수로 속도를 셌습니다 — 오늘날 속도 단위 ‘**노트(knot)**’가 여기서 나온 말입니다.

이 측정값을 매일 기록해 둔 책이 ‘**log-book**’(17세기 후반) — 우리가 아는 **항해 일지**입니다. 즉 ‘통나무 → 속도 측정 도구 → 그 측정과 항해 상황을 적어 둔 책’ 순으로 의미가 확장된 셈입니다. 그래서 오늘날 ‘로그’는 특정 상황이나 지속적인 관리가 필요한 영역에서 그 흐름을 기록해 두기 위한 하나의 **기록(History)**이라는 의미를 가지고 있습니다.

![배 뒤편의 릴(REEL)에서 줄이 풀려 나가고, 그 끝에 부채꼴 모양의 통나무 조각(LOG)이 매달려 바다 위에 떠 있는 모습의 해양사 일러스트](/wiki-assets/playbook/what-is-logs-and-events/chip-log.png)

> 배 뒤에 매단 통나무 조각(LOG)이 바다에 떠 있고, 줄이 릴(REEL)에서 풀려 나가는 모습. 줄이 풀려 나간 길이로 배의 속도를 잰 데서 ‘로그’라는 단어가 출발했습니다. (Pearson Scott Foresman, 퍼블릭 도메인)

웹사이트에 방문하는 사용자들은 상세 페이지를 조회하기도 하고, 구매 버튼을 클릭하기도 하고, 스크롤을 하기도 합니다. 이 모든 행위를 데이터 형태로 기록하면 **웹 로그 데이터**가 되고, 모바일 앱에서의 행동을 기록하면 **앱 로그 데이터**가 됩니다. 즉 **로그 데이터(log data)**란 웹/앱 내에서의 사용자의 모든 행동을 데이터 형태로 기록한 것이라고 이해할 수 있습니다.

Amplitude는 이렇듯 사용자가 웹/앱에서 상호작용하는 모든 행위를 로그 데이터 형태로 저장하고, 우리가 보기 쉽게 차트와 대시보드로 정리하거나, 우리가 원하는 방식으로 분석할 수 있게 도와주는 분석 도구입니다.

## 이벤트(Event) — ‘웹/앱에서 발생한 특별한 사건’

그렇다면 **이벤트(Event)**란 무엇일까요? 이벤트란, ‘**우리 웹사이트나 어플리케이션 내에서 발생한 특별한 사건**’을 의미합니다.

예를 들어, 우리가 추적하고자 하는 사용자의 행위가 *공유하기 버튼 클릭*, *공감 버튼 클릭* 2가지라면, 2개의 이벤트가 될 수 있는 것처럼요. 즉, 사용자들이 어떤 특별한 행위를 했을 때 이벤트가 발생하며, **사용자별·시간대별로 기록된 이벤트 데이터를 로그 데이터**라고 부릅니다.

예시 — 가상의 사용자 ‘유성민’이 만든 로그 데이터

유성민이 쇼핑몰에서 다음과 같이 행동했다고 가정해 보겠습니다. 각 행위는 한 건의 **이벤트**로 기록되고, 이렇게 사용자별·시간대별로 줄줄이 쌓인 전체가 **로그 데이터**가 됩니다.

| 시간 | 사용자 | 행위 | 이벤트 이름 |
| --- | --- | --- | --- |
| 2026-05-14 13:18:22 | 유성민 | 쇼핑몰에 처음 방문 | `session_start` |
| 2026-05-14 13:20:05 | 유성민 | 운동화 상세 페이지를 조회 | `view_product` |
| 2026-05-14 13:23:45 | 유성민 | ‘장바구니 담기’ 버튼을 클릭 | `add_to_cart` |
| 2026-05-14 13:24:12 | 유성민 | 장바구니 페이지를 조회 | `view_cart` |
| 2026-05-14 13:26:30 | 유성민 | 결제를 완료 | `complete_purchase` |

유성민 한 명의 기록만 5줄입니다. 모든 사용자의 모든 이벤트가 같은 방식으로 쌓이면, 그 전체가 우리가 Amplitude에서 분석하는 ‘로그 데이터’가 됩니다.

## 데이터를 적재하기 전, ‘무엇이 궁금한지’부터

SQL이나 데이터베이스 지식 없이도 Amplitude 같은 도구를 사용하면 비즈니스의 웹/앱 행동 데이터를 관측하고 활용할 수 있습니다. 다만, Amplitude로 데이터를 본격 수집하기 전에 한 가지 명심할 것이 있습니다.

> **팁**
>
> 데이터를 적재하기 전, ** 여러분이 스스로 무엇이 궁금한지를 열거**해 보는 것입니다.

무엇을 보고 싶은지, 우리 비즈니스에서 어떤 것이 문제인지 정의되지 않았다면, 데이터를 적재해도 활용할 수가 없습니다. **데이터 그 자체에는 정답이 없기 때문입니다.** 한 가지 사례를 들어 봅시다.

## 예시 — 블로그 운영자의 경우

![‘디지털 마케팅의 모든것, Growth Hacker’ 블로그의 한 게시글 상단 화면 — 글 제목·작성자·작성일이 보이고 본문이 시작되는 모습](/wiki-assets/playbook/what-is-logs-and-events/onedge1-blog-example.png)

> 예시로 들 블로그의 한 글입니다. 글 한 편을 사이에 두고, 방문자가 어떻게 ‘관심을 가지고 글을 보는지’ 측정하려면 어떤 행동을 이벤트로 잡아야 할지 같이 따져 보겠습니다.

저는 제가 얻은 경험들을 보관하고, 방문자들에게 유용한 정보를 제공해 주기 위해, 저만의 블로그를 만들었습니다. 블로그에 글을 좀 쓰다 보니 방문자들이 조금씩 생기기 시작했고, 그 이후 저는 제 블로그에 방문하는 사용자들이 글에 얼마나 관심을 가지는지 보고 싶었습니다.

위 사례에서 제가 보고 싶은 것은 — “**사용자들이 얼마나 내 글에 관심을 가지는가?**”입니다. 그렇다면 사용자들이 제 블로그에서 어떤 행동을 해야, 관심을 가지고 글을 본다고 생각할 수 있을까요? 아래와 같은 답변들이 나올 수 있을 것입니다.

| “관심을 가진다”는 행동의 후보 | 이벤트 이름(예) |
| --- | --- |
| 사용자가 내 글을 **스크롤**하는 비율 | `scroll` |
| 사용자가 글 하단의 **공감 버튼**을 클릭하는 정도 | `click_btn_heart` |
| 사용자가 내 글을 **공유**하는 정도 | `click_btn_share` |
| 사용자가 **댓글을 작성**하는 정도 | `submit_comment` |

이렇게 내가 보고 싶은 것이 무엇인지에 대해서 정의하면, 그에 맞는 지표들을 만들어 낼 수 있습니다. 이렇듯 문제 또는 내가 보고 싶은 것이 무엇인지를 먼저 정의하고 데이터 설계 작업을 시작해야만, 그 데이터를 활용할 수 있습니다.

사고의 순서

① 무엇이 궁금한가? “사용자들이 얼마나 내 글에 관심을 가지는가?” ↓ ② 어떤 ‘행동’으로 그것을 측정할 것인가? 스크롤 · 공감 클릭 · 공유 · 댓글 ↓ ③ 각 행동을 어떤 ‘이벤트’로 보낼 것인가? scroll · click_btn_heart · click_btn_share · submit_comment

## 분석툴은 모두 ‘이벤트’ 단위로 말한다

궁금한 점이 열거되었다면, 데이터를 설계해 보아야 합니다. 우리는 이제 필요한 사용자의 행위를 지표로 치환하는 작업을 끝냈습니다. 이제 실제로 데이터를 설계하는 방법을 살펴보아야 합니다. **Amplitude·GA4·Mixpanel·Braze** 등 대부분의 분석 도구와 CRM 도구는 ‘**이벤트**’라는 단위로 데이터를 전송합니다.

| 분석/CRM 도구 | 데이터 단위 |
| --- | --- |
| Amplitude | 이벤트(Event) |
| GA4 (Google Analytics 4) | 이벤트 |
| Mixpanel | 이벤트(Event) |
| Braze | 커스텀 이벤트(Custom Event) |

이벤트는 앞에서도 말해 왔듯이, 우리 웹사이트에서 발생한 **특별한 사건**을 의미합니다. 예를 들어, 내 블로그에 방문하는 사람이 스크롤을 할 때에는 ‘`scroll`’이라는 이벤트를 보내야 합니다. 글 하단에 공감 버튼을 클릭할 때에는 ‘`click_btn_heart`’라는 이름으로 명명하여 이벤트가 발생했다는 사실을 Amplitude로 보내 주는 것입니다.

만약 우리가 쇼핑몰을 운영하고 있다면, ‘`complete_purchase`’, ‘`add_to_cart`’와 같은 주요한 사용자의 행위가 발생할 때마다 이벤트를 보내 주어야 합니다.

웹사이트 · 어플리케이션

사용자가 ‘공감’ 버튼을 클릭

▼ 이벤트로 명명하여 전송

분석툴 (Amplitude · GA4 · …)

click_btn_heart ← 발생함!

▼ 사용자별 · 시간대별로 누적

로그 데이터

전체 사용자의 모든 이벤트 기록 = 로그 데이터

## 자주 묻는 질문

### ‘로그 데이터’와 ‘이벤트’는 같은 말인가요?

겹치지만 결이 다릅니다. **이벤트**는 ‘한 건의 특별한 사건’이고, **로그 데이터**는 그런 이벤트들이 사용자별·시간대별로 차곡차곡 누적된 ‘전체 기록’ 입니다. 즉 이벤트가 모이고 모이면 로그 데이터가 됩니다.

### ‘무엇이 궁금한지’를 정의하지 않고 일단 데이터부터 쌓으면 안 되나요?

쌓을 수는 있지만 **쌓아 둔 것을 활용하기 어렵습니다.** 데이터 그 자체에는 정답이 없기 때문에, “이 숫자가 무엇을 말하는가”를 판단하려면 결국 ‘무엇이 궁금했는지’가 필요합니다. 먼저 질문을 정해 두면 그 질문에 답하는 이벤트만 설계하면 되어 — 설계도, 운영도 훨씬 가벼워집니다.

### 분석툴마다 데이터 단위가 다르지는 않나요?

이름은 조금씩 다르지만 결국 같은 것을 가리킵니다 — Amplitude·GA4·Mixpanel은 모두 ‘**이벤트(Event)**’, Braze는 ‘커스텀 이벤트’라고 부릅니다. ‘우리 서비스에서 일어난 한 건의 행위를 기록한 단위’라는 본질은 동일합니다. 그래서 한 곳에서 잘 설계해 두면 다른 도구로 옮기거나 함께 쓰는 일도 어렵지 않습니다.

### Amplitude는 GA4와 같은 이벤트 이름을 써도 되나요?

**네, 의도적으로 같이 맞추시는 걸 권장합니다.** 같은 사용자의 같은 행동을 두 도구에서 같은 이름으로 보내면, 운영 중에 “GA4와 Amplitude의 숫자가 왜 다르지?” 같은 추적이 쉬워집니다. GA4 표준 이벤트 이름(`add_to_cart`, `purchase` 등)이 있다면 Amplitude에서도 같은 이름으로 보내시는 것이 표준입니다.

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