사용자 행동 로그 설계 | 문제 정의부터 Event, Attribute, Trigger, Tracking Plan까지 전체 정리

이 글은 코드잇 스프린트 데이터 분석가 과정 학습 기록입니다.
수업 내용과 느낀 점을 매일 정리하며 데이터 분석 공부 과정을 기록하고 있습니다.

💁‍♀️사용자 행동 로그 설계 정리

이 글은 사용자 행동 로그 설계 이론을 정리한 글이다. 프로덕트 데이터 분석에서 로그 데이터는 사용자의 행동을 이해하고, 기능 개선이나 지표 분석을 하기 위해 매우 중요한 데이터이다. 하지만 로그 데이터는 서비스 운영 과정에서 자동으로 항상 분석하기 좋게 쌓이는 데이터가 아니다. 분석에 필요한 데이터를 얻기 위해서는 어떤 행동을 기록할 것인지, 어떤 속성을 함께 남길 것인지, 언제 로그를 발생시킬 것인지 미리 설계해야 한다.

 

이번 글에서는 프로덕트 데이터 분석 프로세스에서 로그 설계가 어떤 위치에 있는지, 로그 설계가 왜 필요한지, 로그 설계를 하기 위해 알아야 하는 기초 지식은 무엇인지, 그리고 실제 이벤트 로그를 설계할 때 필요한 User Property, Event Property, Event, Attribute, Trigger, Tracking Plan까지 정리해보려고 한다.

📊프로덕트 데이터 분석 프로세스

프로덕트 데이터 분석 프로세스는 크게 다음과 같은 흐름으로 진행된다.

1. 로그 및 문제 정의
2. 데이터 조회
3. 데이터 분석 및 인사이트 도출
4. 데이터 시각화

각 단계의 역할은 다음과 같다.

단계	설명
로그 및 문제 정의	분석의 목적과 질문을 정의하는 단계
데이터 조회	어떠한 데이터가 필요한지 파악하고 핵심 지표를 선별하는 단계
데이터 분석 및 인사이트 도출	다양한 방법론과 도구를 활용하여 의미 있는 정보를 도출하는 단계
데이터 시각화	효과적인 결과 전달을 위해 데이터를 이해하기 쉽게 표현하는 단계

 

프로덕트 데이터 분석은 단순히 데이터를 조회하고 차트를 그리는 것으로 시작하지 않는다. 가장 먼저 해야 할 일은 무엇을 알고 싶은지, 어떤 문제를 해결하고 싶은지, 어떤 지표를 확인해야 하는지를 정의하는 것이다. 즉, 분석의 출발점은 데이터 자체가 아니라 문제 정의이다.

- 문제 정의가 중요한 이유

문제 정의는 분석의 방향을 결정한다. 문제가 명확하지 않으면 어떤 데이터를 봐야 하는지 알 수 없고, 어떤 지표를 계산해야 하는지도 정하기 어렵다. 또한 분석을 해도 결과가 실제 의사결정으로 연결되지 않을 가능성이 높다. 예를 들어 단순히 '사용자가 줄었다'라고만 생각하면 너무 막연하다. 하지만 이를 다음과 같이 나누면 분석 방향이 훨씬 명확해진다.

• 신규 사용자가 줄어든 것인가?
• 기존 사용자의 재방문이 줄어든 것인가?
• 특정 채널에서 유입이 줄어든 것인가?
• 특정 기능 사용 이후 이탈이 증가한 것인가?
• 결제 전환 단계에서 문제가 생긴 것인가?

이처럼 문제를 구체화해야 어떤 데이터를 확인해야 하는지 정할 수 있다. 따라서 로그 설계에서도 문제 정의는 매우 중요하다. 로그 데이터는 그냥 많이 쌓는 것이 아니라, 분석 목적에 맞게 필요한 행동을 기록하기 위해 설계하는 것이기 때문이다.

🗂️로그 및 문제 정의 단계

로그 데이터는 그냥 적재하는 것이 아니다. 적재를 위한 로그 설계 작업을 먼저 거쳐야 한다. 로그 및 문제 정의 단계에서는 분석의 목적과 질문을 정의한다. 이때 문제를 구조적으로 정리하기 위해 여러 프레임워크를 사용할 수 있다. 대표적인 문제 정의 프레임워크는 다음과 같다.

• MECE
• Logic Tree
• So What?
• Why So?

이 프레임워크들은 문제를 빠짐없이 나누고, 원인을 구조화하고, 결론과 근거를 정리하는 데 사용된다.

👫MECE

MECE는 Mutually Exclusive Collectively Exhaustive의 줄임말이다. 한국어로는 상호 배타적이고 전체를 포괄하는 것을 의미한다. 조금 더 쉽게 말하면, 어떤 대상을 여러 그룹으로 나눌 때 다음 두 가지 조건을 만족해야 한다는 뜻이다.

1. Mutually Exclusive
   각각의 분류가 서로 겹치지 않아야 한다.
2. Collectively Exhaustive
   모든 분류를 합쳤을 때 전체를 빠짐없이 포함해야 한다.

즉, MECE하게 나눈다는 것은 중복 없이, 누락 없이 나누는 것이다.

- MECE 예시

고객을 나이 기준으로 나눈다고 하면 다음과 같이 나눌 수 있다.

구분	설명
0~14세	어린이와 청소년
15~24세	청소년 및 청년
25~44세	성인
45~64세	중년 및 장년
65세 이상	노년층

 

이 경우 각 나이대가 서로 겹치지 않고, 전체 연령대를 빠짐없이 포함한다. 따라서 MECE한 분류라고 볼 수 있다. 반대로 다음과 같이 나누면 MECE하지 않을 수 있다.

구분	분류 기준	MECE하지 않은 이유
10대	연령 기준	청소년과 범위가 겹칠 수 있다.
청소년	생애주기 기준	10대와 범위가 겹칠 수 있고, 법적·사회적 기준에 따라 범위가 달라질 수 있다.
대학생	신분 기준	연령 기준이 아니기 때문에 10대, 청소년, 직장인과 겹칠 수 있다.
직장인	직업 기준	연령 기준이 아니기 때문에 대학생과도 겹칠 수 있고, 다른 분류와 기준이 섞인다.

 

이 경우 10대와 청소년은 겹칠 수 있고, 대학생과 직장인도 연령 기준이 아니라 직업/상태 기준이기 때문에 분류 기준이 섞여 있다. 또한 전체 고객을 모두 포괄한다고 보기도 어렵다. 로그 설계나 지표 설계에서도 MECE는 중요하다. 예를 들어 유입 채널을 나눌 때도 검색, 광고, 추천, 직접 유입 등으로 중복과 누락이 없도록 기준을 잡아야 한다.

🌳Logic Tree

Logic Tree는 문제를 정의할 때 MECE 관점을 기반으로 Tree 형태로 정리하는 방법이다. 문제를 큰 덩어리에서 작은 덩어리로 나누면서 원인을 파악하고, 현상을 분석하고, 해결책을 구체화할 때 유용하다. 예를 들어 '새로운 마케팅 전략'을 세운다고 하면 다음과 같이 나눌 수 있다.

새로운 마케팅 전략
├─ 고객 분석
│  ├─ 세그먼트
│  └─ 니즈와 선호
├─ 경쟁 분석
│  ├─ 경쟁사의 전략
│  └─ 시장 점유율
└─ 내부 자원
   ├─ 예산
   └─ 인력과 기술

 

이렇게 정리하면 막연한 문제를 여러 하위 요소로 나누어 볼 수 있다. Logic Tree를 사용할 때 중요한 점은 단순히 가지를 많이 뻗는 것이 아니라, 각 항목이 가능한 한 MECE하게 나뉘어야 한다는 점이다. 그래야 원인이나 해결책을 빠짐없이 검토할 수 있다.

🤷‍♂️So What? Why So?

So What? Why So?는 핵심을 추려내고, 요점의 타당성을 증명하기 위한 프레임워크이다. 분석 결과를 해석할 때 단순히 숫자만 나열하면 의미 있는 인사이트가 되기 어렵다. 이때 그래서 무엇을 의미하는가?와 왜 그렇게 볼 수 있는가?를 반복해서 질문하면 결론과 근거를 더 명확히 정리할 수 있다.

- So What?

So What?은 분석 결과에서 핵심 결론을 뽑아내기 위한 질문이다. 다음과 같은 질문을 던질 수 있다.

• 결론은 무엇인가?
• 그래서 무엇인가?
• 무엇을 해야 하는가?
• 말하고자 하는 요점은 무엇인가?

예를 들어 '상품 상세 페이지 조회 수가 증가했다'라는 분석 결과가 있다고 하자. 여기서 So What?을 적용하면 다음과 같이 생각할 수 있다.

상품 상세 페이지 조회 수가 증가했다.
→ 그래서 무엇인가?
→ 사용자가 상품에 관심을 가지는 비율이 높아졌을 수 있다.
→ 무엇을 해야 하는가?
→ 상세 페이지 이후 장바구니 담기와 구매 전환율도 함께 확인해야 한다.

 

즉, So What?은 단순한 사실을 실제 의사결정으로 연결하기 위한 질문이다.

- Why So?

Why So?는 결론의 근거를 확인하기 위한 질문이다. 다음과 같은 질문을 던질 수 있다.

• 왜 그런가?
• 어떤 근거로 그렇게 말할 수 있는가?
• 다른 원인은 없는가?
• 더 이상 Why에 대한 생각이 나지 않을 때까지 질문할 수 있는가?

Why So?에서는 흔히 5 Why 방식도 사용할 수 있다. 5 Why는 어떤 현상의 원인을 파악하기 위해 왜?를 반복해서 묻는 방식이다. 예를 들어 구매 전환율이 낮아졌다는 문제가 있을 때 다음과 같이 질문할 수 있다.

구매 전환율이 낮아졌다.
→ 왜 낮아졌는가?
→ 장바구니에서 결제 페이지로 넘어가는 비율이 낮아졌다.
→ 왜 낮아졌는가?
→ 배송비가 결제 직전에 노출되고 있었다.
→ 왜 문제가 되는가?
→ 사용자가 예상하지 못한 추가 비용을 보고 이탈했을 가능성이 있다.

 

이처럼 Why So?는 결론이 단순한 추측이 아니라 근거를 가진 분석이 되도록 도와준다.

📋로그 설계

- 로그 설계란?

로그 데이터는 미리 데이터를 체계적으로 기록해 두어야 분석할 때 사용할 수 있다. 프로덕트 로그 설계는 쉽게 말해 일지의 형식을 정하고, 사용자 행동을 체계적으로 기록할 수 있도록 계획하는 것이다. 예를 들어 일기를 쓴다고 해도 아무 형식 없이 쓰면 나중에 원하는 정보를 찾기 어렵다. 반대로 날짜, 장소, 행동, 감정, 결과처럼 일정한 형식으로 기록하면 나중에 특정 패턴을 찾기 쉬워진다.

로그 데이터도 마찬가지이다. 사용자가 어떤 화면에 들어왔는지, 어떤 버튼을 눌렀는지, 어떤 상품을 봤는지, 어떤 경로로 결제했는지 등을 분석하려면 처음부터 기록 형식을 잘 설계해야 한다.

- 로그 설계와 로그 개발

로그 데이터를 전송하기 위한 개발은 그 앞단에서 기획 과정이 선행되어야 한다. 즉, 로그 설계는 로그 데이터 개발을 위한 기획 단계이다. 흐름은 다음과 같다.

로그 설계 → 로그 개발

 

로그 설계 단계에서는 분석가나 PM/PO가 어떤 로그가 필요한지 정의한다. 이후 개발자는 해당 설계를 바탕으로 실제 로그가 수집되도록 구현한다. 따라서 로그 설계가 명확하지 않으면 개발자가 어떤 시점에 어떤 데이터를 전송해야 하는지 알기 어렵다. 또한 나중에 데이터가 쌓이더라도 분석에 활용하기 어려운 형태가 될 수 있다.

🗃️분석에 활용할 수 있는 데이터

분석에 활용할 수 있는 데이터는 크게 두 가지로 나눌 수 있다.

1. 서비스 운영용 데이터
2. 사용자 행동 데이터

구분	설명	예시
서비스 운영용 데이터	서비스가 제대로 돌아가기 위해 반드시 기록되어야 하는 데이터	회원 가입 정보, 상품명, 가격, 구매 정보
사용자 행동 데이터	사용자가 서비스 안에서 남기는 행동과 관련된 데이터	페이지 방문 정보, 버튼 클릭 정보, 배너 노출 정보

 

두 데이터는 모두 분석에 활용될 수 있지만, 생성되는 방식과 목적이 다르다.

- 서비스 운영용 데이터

서비스 운영용 데이터는 서비스가 제대로 돌아가기 위해 반드시 기록되어야 하는 정보이다. 이 데이터가 기록되지 않으면 서비스 자체가 정상적으로 작동하기 어렵다. 따라서 데이터 분석을 위해 별도로 요청하지 않아도 서비스 운영 과정에서 자연스럽게 데이터베이스에 저장된다. 예시는 다음과 같다.

• 고객의 회원 가입 정보
• 고객의 이름, 이메일, 가입일
• 상품의 이름과 가격
• 상품 재고 정보
• 고객의 상품 구매 정보
• 주문 번호
• 결제 금액
• 배송 상태

예를 들어 사용자가 상품을 구매했는데 구매 정보가 저장되지 않으면 주문 처리를 할 수 없다. 상품 가격이 저장되지 않으면 결제 금액을 계산할 수 없다. 회원 정보가 저장되지 않으면 로그인을 처리할 수 없다. 따라서 서비스 운영용 데이터는 서비스가 운영되기 위해 필수적으로 저장된다.

- 사용자 행동 데이터

사용자 행동 데이터는 사용자가 서비스 내에서 돌아다니면서 남기는 행동과 관련된 정보이다. 이 데이터는 서비스 운영 자체에는 반드시 필요하지 않을 수 있다. 하지만 사용자가 서비스를 어떻게 이용하는지 분석하기 위해서는 매우 중요하다. 예시는 다음과 같다.

• 고객의 페이지 방문 정보
• 특정 버튼 클릭 정보
• 상품 상세 페이지 조회 정보
• 배너 노출 정보
• 배너 클릭 정보
• 검색어 입력 정보
• 장바구니 담기 정보
• 특정 화면에서 이탈한 정보

사용자 행동 데이터는 다음과 같이도 불린다.

• 사용자 행동 로그
• 유저 로그 데이터
• 로그 데이터

사용자 행동 데이터는 데이터 분석을 원하는 사람이 별도로 기록을 요청해야 하는 경우가 많다. 즉, 분석을 위해 따로 설계하고 적재해야 하는 데이터이다.

- 서비스 운영용 데이터와 사용자 행동 데이터의 차이

두 데이터의 차이는 다음과 같이 정리할 수 있다.

구분	서비스 운영용 데이터	사용자 행동 데이터
목적	서비스 운영	사용자 행동 분석
저장 여부	서비스 운영을 위해 자연스럽게 저장	분석을 위해 별도 설계와 개발 필요
저장 위치	주로 데이터베이스	로그 수집 시스템, 데이터 레이크, 데이터 웨어하우스 등
예시	회원 정보, 상품 정보, 주문 정보	페이지 방문, 클릭, 노출, 스크롤, 검색
특징	없으면 서비스 운영이 어려움	없어도 서비스는 돌아가지만 분석이 어려움

 

서비스 운영용 데이터만으로도 매출, 주문 수, 회원 수 같은 전반적인 비즈니스 현황은 분석할 수 있다. 하지만 웹이나 앱의 구체적인 화면과 기능을 개선하고 싶다면 사용자 행동 데이터가 필요하다. 예를 들어 매출이 줄었다는 사실은 주문 데이터를 보면 알 수 있다.
하지만 왜 매출이 줄었는지, 사용자가 어느 화면에서 이탈했는지, 어떤 버튼을 누르지 않았는지, 어떤 배너가 클릭되지 않았는지는 사용자 행동 로그가 있어야 알 수 있다.

- 사용자 행동 데이터를 분석한다는 것

사용자 행동 데이터를 분석한다는 것은 로그 데이터를 활용하여 유저의 행동을 파악하고, 이를 바탕으로 프로덕트를 개선하는 것을 의미한다. 예를 들어 다음과 같은 질문에 답할 수 있다.

• 사용자는 어떤 경로로 유입되는가?
• 어떤 화면을 가장 많이 보는가?
• 어떤 버튼을 많이 클릭하는가?
• 어떤 단계에서 가장 많이 이탈하는가?
• 어떤 상품이 많이 노출되지만 클릭은 적은가?
• 어떤 배너가 클릭률이 높은가?
• 회원가입 과정 중 어느 단계에서 포기하는가?
• 장바구니에 담은 뒤 결제까지 이어지는 비율은 어느 정도인가?

이러한 질문에 답하려면 사용자의 행동이 기록되어 있어야 한다. 따라서 로그 데이터를 잘 활용하려면 미리 데이터를 체계적으로 기록해 두어야 한다.

- 로그 데이터 적재가 필요한 이유

서비스 운영용 데이터만으로도 전반적인 비즈니스 현황은 분석할 수 있다. 하지만 구체적인 화면이나 기능을 개선하고 싶다면 로그 데이터가 필요하다. 로그 데이터 적재가 필요한 이유는 크게 두 가지이다.

 

첫째, 로그 설계를 하지 않으면 자연스럽게 로그 데이터 전송을 위한 개발도 이루어지지 않는다. 사용자 행동 데이터는 서비스 운영에 필수적인 데이터가 아니기 때문에, 따로 요청하지 않으면 개발되지 않을 수 있다.

 

둘째, 로그 설계 없이 아무렇게나 데이터를 쌓으면 분석에 활용하기 어렵다. 로그 데이터를 어떻게든 전송하기만 하면 된다고 생각하고 체계 없이 개발하면, 이벤트 이름이나 속성 이름이 제각각이 되거나, 필요한 정보가 빠지거나, 같은 행동이 서로 다른 방식으로 기록될 수 있다.

 

예를 들어 같은 상품 클릭 이벤트가 다음처럼 제각각 쌓이면 분석이 어려워진다.

product_click
click_product
productClick
prd_click
item_click

 

이 경우 같은 행동을 의미하는 로그인데도 이벤트명이 다르기 때문에 데이터를 다시 정리해야 한다. 따라서 로그는 처음부터 목적과 기준을 가지고 설계해야 한다.

🔧로그 설계 프로세스

로그 설계 프로세스는 다음 순서로 진행된다.

1. 지표 기획
2. 로그 설계
3. 로깅, 로그 개발
4. QA

 

- 지표 기획

지표 기획은 특정 기능과 성과를 확인하기 위해 어떤 지표가 필요할지 기획하는 단계이다. 예를 들어 이커머스 앱의 메인 페이지 개편 효과를 확인하고 싶다면 다음과 같은 지표를 생각할 수 있다.

• 메인 페이지 방문 수
• 배너 노출 수
• 배너 클릭 수
• 배너 클릭률
• 상품 노출 수
• 상품 클릭 수
• 상품 클릭률
• 장바구니 담기 수
• 구매 전환율

지표를 먼저 정해야 어떤 로그가 필요한지도 정할 수 있다. 예를 들어 상품 클릭률을 계산하려면 상품 클릭 로그만 있어서는 부족하다. 클릭률은 보통 클릭 수 / 노출 수로 계산하기 때문에 상품 노출 로그도 필요하다.

- 로그 설계

로그 설계는 지표 기획을 바탕으로 어떤 로그를 어떻게 찍을지 계획하고 구조를 짜는 단계이다. 이 단계에서는 다음과 같은 내용을 정의한다.

• 어떤 이벤트를 기록할 것인가?
• 이벤트 이름은 무엇으로 할 것인가?
• 어떤 속성을 함께 기록할 것인가?
• 로그는 어느 시점에 발생시킬 것인가?
• 어떤 플랫폼에서 수집할 것인가?
• 어떤 버전부터 적용할 것인가?
• 기존 로그와 명명 규칙이 일관적인가?

로그 설계 단계에서는 Event, Attribute, Trigger를 정의하고, 이를 바탕으로 Tracking Plan을 작성한다.

- 로깅, 로그 개발

로깅 또는 로그 개발은 로그가 실제로 수집되도록 개발하는 단계이다. 로그 설계 문서가 만들어지면 개발자는 해당 문서를 기준으로 웹, 앱, 서버 등에 로그 수집 코드를 구현한다. 예를 들어 메인 페이지 상품 클릭 로그를 설계했다면, 개발자는 사용자가 메인 페이지에서 상품 영역을 클릭했을 때 해당 이벤트가 전송되도록 구현한다.

- QA

QA는 데이터가 로그 설계 단계에서 의도한 대로 잘 찍히는지 확인하는 단계이다. QA에서는 다음과 같은 내용을 확인할 수 있다.

• 이벤트가 의도한 시점에 발생하는가?
• 이벤트명이 설계 문서와 일치하는가?
• 필요한 속성이 빠지지 않고 들어오는가?
• 데이터 타입이 맞는가?
• 웹, Android, iOS 등 플랫폼별로 동일하게 수집되는가?
• 중복으로 찍히거나 누락되는 로그는 없는가?
• 특정 조건에서만 발생해야 하는 로그가 모든 상황에서 찍히고 있지는 않은가?

로그 QA는 매우 중요하다. 로그가 잘못 쌓이면 이후 분석 결과도 잘못될 수 있기 때문이다.

- 로그 설계 단계별 주체

각 단계별 주요 주체는 다음과 같다.

단계	주요 주체
지표 기획	데이터 분석가, PM/PO
로그 설계	데이터 분석가, PM/PO
로깅, 로그 개발	개발자
QA	PM/PO, QA팀

 

물론 실제 업무에서는 회사 구조에 따라 역할이 조금씩 달라질 수 있다. 다만 일반적으로 분석가와 PM/PO는 어떤 지표와 로그가 필요한지 정의하고, 개발자는 실제 수집을 구현하며, QA팀은 설계대로 동작하는지 확인한다.

📚로그 설계에 필요한 기초 지식

로그 설계를 잘하려면 어떤 데이터가 어디에서 발생하는지 이해해야 한다. 그래야 어떤 개발자에게 요청해야 하는지, 수정이 필요한 경우 얼마나 빠르게 반영할 수 있는지 파악할 수 있다. 로그 설계에 필요한 기초 지식은 다음과 같다.

• 클라이언트와 서버
• 웹과 앱
• 웹뷰
• 데이터베이스와 파일
• 데이터 레이크와 데이터 웨어하우스
• ETL

- 클라이언트와 서버

클라이언트와 서버는 다음과 같은 구조로 이해할 수 있다.

클라이언트 → 요청 Request → 서버
서버 → 응답 Response → 클라이언트

 

클라이언트는 사용자가 직접 보는 화면이고, 서버는 클라이언트의 요청을 받아 처리한 뒤 응답을 내려주는 역할을 한다.

- 클라이언트

클라이언트는 사용자들이 직접 상호작용하는 앱이나 웹 화면을 의미한다. 즉, 유저 인터페이스에 해당한다. 화면 내에서 발생하는 사용자 행동과 관련된 데이터는 보통 클라이언트에서 발생한다. 예시는 다음과 같다.

• 사용자가 어떤 화면에 진입했는지
• 사용자가 어떤 버튼을 클릭했는지
• 사용자가 어떤 배너를 봤는지
• 사용자가 어떤 상품 영역을 클릭했는지
• 사용자가 스크롤을 어디까지 내렸는지

클라이언트는 보통 다음 개발자가 담당한다.

• 프론트엔드 개발자
• 웹 개발자
• Android 개발자
• iOS 개발자

따라서 화면에서 발생하는 사용자 행동 로그를 설계할 때는 해당 화면을 담당하는 클라이언트 개발자와 협업하는 경우가 많다.

- 서버

서버는 사용자의 눈에 직접 보이지는 않지만, 클라이언트의 요청을 받아 응답을 내려주는 역할을 한다. 예를 들어 사용자가 앱에서 상품 상세 페이지를 열면, 클라이언트는 서버에 해당 상품 정보를 요청한다. 서버는 상품명, 가격, 할인율, 재고 상태 등의 정보를 응답으로 내려준다. 상황에 따라 화면에 표시되는 정보가 달라지는 경우, 대부분 클라이언트에서 서버를 통해 받아온 정보이다. 예시는 다음과 같다.

• 계속 변동하는 상품의 할인가 정보
• 사용자별 추천 상품 목록
• 로그인 여부에 따라 달라지는 화면 정보
• 사용자 등급에 따라 달라지는 혜택 정보
• 재고 상태에 따라 달라지는 구매 가능 여부

서버는 보통 백엔드 개발자가 담당한다.

- 웹뷰 WebView

웹뷰는 앱 안에서 웹으로 구현된 페이지를 띄우는 개념이다. 즉, 사용자는 앱을 사용하고 있다고 느끼지만, 실제 특정 화면은 웹 페이지로 구현되어 앱 안에서 보여질 수 있다. 웹뷰는 앱 안에서 웹으로 구현된 페이지를 띄우는 개념이므로, 보통 웹 개발자에 의해 구현된다. 로그 설계 시 웹뷰 여부를 확인하는 것이 중요한 이유는 다음과 같다.

• 해당 화면을 앱 개발자가 담당하는지 웹 개발자가 담당하는지 달라질 수 있다.
• 로그 수집 방식이 네이티브 앱 화면과 다를 수 있다.
• 수정 반영 속도도 달라질 수 있다.

따라서 어떤 화면의 로그를 설계할 때, 그 화면이 네이티브 앱 화면인지 웹뷰인지 확인하는 것이 좋다.

- 웹과 앱

클라이언트는 보통 웹과 앱으로 나뉜다. 웹은 일반적인 웹 사이트를 의미하고, 앱은 Android나 iOS 어플리케이션을 의미한다.

데이터가 어디에서 발생하는지 알아둬야 하는 이유는 배포의 용이성 때문이다. 데이터가 어디에서 발생하는지 알면 다음을 파악할 수 있다.

• 어떤 개발자에게 요청해야 하는지
• 로깅 이슈가 있을 때 어디를 수정해야 하는지
• 수정 사항을 얼마나 빠르게 반영할 수 있는지
• 플랫폼별로 로그 수집 방식이 달라지는지

- 웹, 서버, Android, iOS의 수정 반영 속도

웹과 서버는 상대적으로 재배포가 수월한 편이다. 반면 Android나 iOS와 같은 앱은 사용자가 앱 업데이트를 해야 하거나 앱스토어 심사 과정을 거쳐야 하므로 빠르게 수정하기 어렵다. 특히 iOS는 Android보다 승인이 엄격한 편이다.

구분	수정 반영 특징
웹	빠른 수정 가능
서버	빠른 수정 가능
Android	상대적으로 느린 수정 반영
iOS	느린 수정 반영

 

이 차이는 로그 설계와 QA에서도 중요하다. 예를 들어 웹 로그에 문제가 있으면 비교적 빠르게 수정할 수 있지만, 앱 로그에 문제가 있으면 수정 버전을 배포하고 사용자가 업데이트해야 하기 때문에 데이터 오류가 더 오래 남을 수 있다. 따라서 앱 로그는 설계와 QA 단계에서 더 신중하게 확인해야 한다.

📁데이터베이스와 파일

- 데이터베이스

서비스 운영 목적의 데이터는 보통 데이터베이스에 저장된다. 데이터베이스는 체계적으로 구조화되어 있어서 데이터를 빠르게 기록하고 조회할 수 있다. 회원 정보, 주문 정보, 상품 정보처럼 서비스 운영에 직접 필요한 데이터는 데이터베이스에 저장되는 경우가 많다. 흐름은 다음과 같다.

데이터 → 데이터베이스

 

해당 데이터는 주로 서비스 운영용 데이터이다. 예시는 다음과 같다.

• 회원 정보
• 상품 정보
• 주문 정보
• 결제 정보
• 배송 정보

- 파일

서비스 운영과 직접 관련이 없는 데이터는 일단 파일 단위로 쌓이는 경우가 많다. 로그 데이터는 대량으로 발생하고, 형식이 유연하게 변할 수 있으며, 서비스 운영용 데이터처럼 즉시 조회되어야 하는 데이터가 아닐 수 있다. 따라서 일단 파일 단위로 저장한 뒤, 이후 분석에 적합한 형태로 정리할 수 있다. 흐름은 다음과 같다.

데이터 → 파일 → 데이터 레이크

 

해당 데이터는 주로 서비스 운영과 관련 없는 데이터, 즉 로그 데이터이다.

- 데이터 레이크

데이터 레이크는 구조화되지 않은 대량의 데이터 파일을 쌓아둘 수 있는 보관소 개념이다. 로그 데이터는 처음부터 완전히 정제된 테이블 형태로 들어오기보다는, 파일 형태로 쌓인 뒤 나중에 정리되는 경우가 많다. 이때 원천 데이터를 보관하는 공간을 데이터 레이크라고 이해할 수 있다.

- 데이터 웨어하우스

데이터 웨어하우스는 분석에 활용하기 좋도록 정리된 데이터를 저장하는 공간이다. 서비스 운영과 관련 없는 로그 데이터는 보통 다음과 같은 흐름을 거칠 수 있다.

데이터 → 파일 → 데이터 레이크 → 데이터 웨어하우스

 

즉, 로그 데이터가 처음에는 파일 단위로 데이터 레이크에 보관되고, 이후 일정한 시간 주기로 정리되어 데이터 웨어하우스로 옮겨진다.

- ETL

데이터 레이크에 쌓인 데이터를 데이터 웨어하우스로 옮길 때 ETL 과정이 일어난다. ETL은 다음의 줄임말이다.

용어	의미	설명
Extract	추출	필요한 데이터를 꺼내는 단계
Transformation	변환	분석하기 좋은 형태로 가공하는 단계
Load	적재	변환한 데이터를 목적지에 저장하는 단계

 

즉, ETL은 데이터를 추출하고, 변환하고, 적재하는 과정이다. 로그 데이터는 보통 발생량이 많고 원천 형태가 복잡할 수 있기 때문에, 분석에 활용하려면 ETL 과정을 통해 정리하는 것이 중요하다.

🖌️이벤트 로그 설계하기

- User Property와 Event Property

로그 데이터는 크게 두 가지 정보를 담는다.

1. 어떤 특성의 유저가
2. 어떤 행동을 했는가

예시는 다음과 같다.

어떤 특성의 유저가	어떤 행동을 했는가
20대 로그인 유저가	주문 배송 페이지를 조회했다
페이스북 광고를 통해 유입된 유저가	A 상품의 상세 페이지를 조회했다
VIP 등급의 여성 유저가	3번 프로모션 배너를 조회했다

 

여기서 '어떤 특성의 유저가'에 해당하는 정보는 User Property이고, '어떤 행동을 했는가'에 해당하는 정보는 Event Property와 연결된다.

- User Property

User Property는 사용자의 특성을 나타내는 정보이다. 예시는 다음과 같다.

• 유저 ID
• 나이
• 성별
• 멤버십 등급
• 가입일
• 로그인 여부
• 유입 채널
• 기기 정보
• 앱 버전

User Property는 크게 두 가지로 나누어 생각할 수 있다.

 

첫째, 서비스 운영용 데이터에 이미 저장되어 있는 사용자 특성이다. 예를 들어 유저의 나이, 성별, 멤버십 정보 등은 회원 정보나 고객 정보 테이블에 이미 저장되어 있을 수 있다. 이런 정보는 로그 설계 시 매번 새롭게 고민할 필요가 적다.

 

둘째, 시점별로 달라질 수 있는 사용자 특성이다. 예를 들어 사용자가 특정 시점에 로그인 상태였는지, 어떤 유입 채널을 통해 들어왔는지, 어떤 앱 버전을 사용하고 있었는지는 이벤트 발생 시점에 함께 기록되어야 분석에 유용하다.

 

즉, User Property는 단순히 고정된 회원 정보만 의미하는 것이 아니라, 이벤트가 발생한 시점의 사용자 상태를 설명하는 정보까지 포함할 수 있다.

- Event Property

Event Property는 사용자가 어떤 행동을 했는지 설명하는 정보이다. Event Property는 육하원칙 중 다음 구조를 바탕으로 설계할 수 있다.

• 누가
• 언제
• 어디서
• 무엇을
• 어떻게

예시는 다음과 같다.

누가	언제	어디서	무엇을	어떻게
123번 유저가	6/18 2시 31분에	A 페이지에서	X 버튼을	클릭했다
451번 유저가	6/18 3시 17분에	B 페이지에서	Y 버튼을	확인했다

 

이벤트 로그는 사용자의 행동을 기록하는 데이터이므로, 최소한 누가, 언제, 어디서, 무엇을, 어떻게 했는지 설명할 수 있어야 한다.

- 이벤트 로그가 갖춰야 할 공통 정보

이벤트 로그에서 '누가'와 '언제'는 모든 데이터에 기록되어야 하는 공통 정보이다.

구분	예시
누가	User ID, Device ID
언제	클라이언트 접근 시각, 서버 접근 시각

 

'누가'와 '언제'는 신규 화면이나 기능을 만들 때마다 매번 새롭게 설계할 필요는 없다. 모든 로그에 공통적으로 들어가야 하는 정보이기 때문에, 필수 적재 규칙으로 관리하는 것이 좋다. 예를 들어 실제 로그에는 다음과 같은 공통 정보가 들어갈 수 있다.

• user_id
• device_id
• device
• app_version
• os
• client_access_timestamp
• server_access_timestamp

이러한 공통 정보가 있어야 특정 행동을 어떤 사용자가 언제 했는지 분석할 수 있다.

🔍Event, Attribute, Trigger

Event Property를 설계할 때에는 크게 세 가지를 고려해야 한다.

1. Event
2. Attribute
3. Trigger

- Event

Event는 어떤 행위에 대한 로그인지를 의미한다. 즉, 사용자가 한 행동의 이름이다. 예시는 다음과 같다.

• 상품 노출
• 상품 클릭
• 페이지 방문
• 배너 클릭
• 검색 실행
• 장바구니 담기
• 주문 완료

영문 이벤트명으로는 다음과 같이 표현할 수 있다.

• pageview
• visit
• click
• impression
• view
• add_to_cart
• purchase

Event는 분석의 가장 기본 단위가 된다. 따라서 이벤트 이름은 어떤 행동을 의미하는지 명확해야 한다.

- Attribute

Attribute는 Event의 부가 속성이다. 즉, 해당 이벤트와 관련해서 함께 저장해야 하는 정보이다. 예를 들어 '상품 클릭' 이벤트가 발생했을 때 단순히 상품을 클릭했다는 사실만 저장하면 분석에 한계가 있다. 어떤 상품을 클릭했는지, 어떤 화면에서 클릭했는지, 몇 번째 위치의 상품을 클릭했는지 함께 저장해야 더 유용하다. 예시는 다음과 같다.

Event	Attribute 예시
상품 노출	상품 ID, 상품명, 카테고리, 노출 위치, 할인율
상품 클릭	상품 ID, 클릭 위치, 페이지명, 섹션명
배너 클릭	배너 ID, 배너명, 배너 위치, 랜딩 URL
검색 실행	검색어, 검색 결과 수, 필터 적용 여부
장바구니 담기	상품 ID, 수량, 가격, 옵션

 

Attribute는 이벤트를 분석 가능한 수준으로 구체화하는 역할을 한다.

- Trigger

Trigger는 해당 로그 데이터를 어느 시점에 발생시킬 것인지를 의미한다. 즉, '언제 로그를 찍을 것인가?'에 대한 기준이다. 예를 들어 상품 노출 로그를 설계할 때 다음과 같이 모호하게 작성하면 문제가 생길 수 있다.

상품이 유저에게 보이면 노출 로그를 찍어주세요.

 

이 문장만으로는 기준이 명확하지 않다. 다음과 같은 질문이 생길 수 있다.

• 상품 이미지가 100% 보이면 전송해야 하는가?
• 상품 이미지가 1%라도 보이면 전송해야 하는가?
• 화면에 0.1초만 보여도 노출로 볼 것인가?
• 사용자가 빠르게 스크롤해서 지나간 것도 노출로 볼 것인가?
• 같은 상품이 다시 보이면 노출을 다시 찍을 것인가?

따라서 Trigger는 구체적으로 정의해야 한다. 예를 들어 다음과 같이 작성할 수 있다.

상품 이미지 영역의 60% 이상이 화면에 노출되었을 때 상품 노출 로그를 전송한다.

 

이렇게 작성하면 개발자와 분석자가 같은 기준으로 로그를 이해할 수 있다.

- Event, Attribute, Trigger 예시

항목	설명	예시
Event	어떤 행위에 대한 로그인지	product_impression
Attribute	이벤트와 함께 저장할 부가 정보	product_id, page_name, section_name
Trigger	로그가 발생하는 시점	상품 이미지의 60% 이상이 화면에 노출된 경우

 

정리하면 Event는 행동의 이름, Attribute는 행동에 대한 부가 정보, Trigger는 행동이 기록되는 시점이다.

🎈대표적인 이벤트 로그

대표적인 이벤트 로그에는 다음이 있다.

1. 방문
2. 클릭
3. 노출

- 방문 이벤트

방문 이벤트는 사용자가 특정 페이지나 화면에 진입했을 때 발생하는 로그이다. 예시는 다음과 같다.

• pageview
• visit
• screen_view

방문 이벤트는 사용자가 어떤 화면에 얼마나 들어왔는지 확인할 때 사용된다. 예를 들어 다음과 같은 분석에 활용할 수 있다.

• 메인 페이지 방문 수
• 상품 상세 페이지 방문 수
• 카테고리 페이지 방문 수
• 결제 페이지 진입 수
• 특정 화면까지 도달한 사용자 수

- 클릭 이벤트

클릭 이벤트는 사용자가 버튼, 배너, 상품, 메뉴 등 특정 요소를 클릭했을 때 발생하는 로그이다. 예시는 다음과 같다.

• click
• product_click
• banner_click
• button_click

클릭 이벤트는 사용자가 실제로 어떤 요소에 관심을 보였는지 확인할 때 사용된다. 예를 들어 다음과 같은 분석에 활용할 수 있다.

• 배너 클릭률
• 상품 클릭률
• CTA 버튼 클릭률
• 메뉴 클릭 수
• 필터 클릭 수

클릭률을 계산하려면 클릭 로그뿐만 아니라 노출 로그도 필요할 수 있다.

클릭률 = 클릭 수 / 노출 수

 

따라서 클릭 이벤트를 설계할 때는 해당 클릭의 기준이 되는 노출 이벤트도 함께 고려해야 한다.

- 노출 이벤트

노출 이벤트는 특정 요소가 사용자 화면에 보여졌을 때 발생하는 로그이다. 예시는 다음과 같다.

• impression
• view
• product_impression
• banner_impression

노출 이벤트는 사용자가 어떤 요소를 볼 기회가 있었는지 확인할 때 사용된다. 예를 들어 다음과 같은 분석에 활용할 수 있다.

• 상품 노출 수
• 배너 노출 수
• 추천 영역 노출 수
• 노출 대비 클릭률
• 노출 대비 구매 전환율

노출 이벤트는 Trigger 기준이 특히 중요하다. 어디까지를 '보였다'고 볼 것인지 명확히 정의하지 않으면 플랫폼이나 개발자마다 다르게 구현될 수 있기 때문이다.

- 서비스 도메인에 따라 달라지는 이벤트

이벤트 명칭은 회사나 서비스마다 달라질 수 있다. 또한 서비스 도메인에 따라 자주 사용하는 이벤트도 달라진다. 예를 들어 이커머스 서비스에서는 다음과 같은 이벤트를 자주 사용할 수 있다.

이벤트	예시 이벤트명
상품 찜	save_product
장바구니 담기	add_to_cart
상품 클릭	product_click
상품 노출	product_impression
주문 완료	purchase
결제 시작	begin_checkout

 

반면 콘텐츠 서비스에서는 콘텐츠 재생, 구독, 좋아요, 댓글 작성 등의 이벤트가 더 중요할 수 있다. 따라서 이벤트 로그는 서비스의 목적과 도메인에 맞게 설계해야 한다.

📝이벤트 로그 설계 시 고려할 점

로그를 설계할 때는 크게 세 가지를 고려해야 한다.

1. 목적성
2. 유용성
3. 통일성

- 목적성

목적성은 해당 로그가 어떤 지표 계산에 사용될지 고려하는 것이다. 로그는 많이 쌓는다고 무조건 좋은 것이 아니다. 불필요하게 많은 로그를 남기면 저장 비용과 관리 비용이 증가하고, 분석할 때도 복잡해진다. 반대로 너무 적은 로그만 남기면 필요한 지표를 계산할 수 없다. 따라서 로그를 설계할 때는 먼저 분석 목적과 지표를 명확히 해야 한다. 예를 들어 목표가 '할인율별 상품 클릭률 비교'라면 필요한 데이터는 다음과 같다.

• 상품 노출 로그
• 상품 클릭 로그
• 상품별 할인율 정보

이때 상품 클릭 로그만 있으면 클릭률을 계산할 수 없다. 클릭률을 계산하려면 분모인 노출 수가 필요하기 때문이다.

상품 클릭률 = 상품 클릭 수 / 상품 노출 수

 

또한 할인율별로 비교하려면 상품별 할인율 정보도 필요하다. 따라서 목적에 맞는 로그와 속성을 함께 설계해야 한다.

- 유용성

유용성은 로그가 분석에 활용하기 쉬운 형태로 설계되어야 한다는 의미이다. 유용한 로그는 다음 조건을 만족해야 한다.

• 이름이 이해하기 쉬워야 한다.
• 추출하기 쉬워야 한다.
• 가공하기 쉬워야 한다.
• 너무 복잡한 형태로 전송하지 않아야 한다.
• 이벤트명과 속성명이 의미를 명확히 담고 있어야 한다.

좋지 않은 예시는 다음과 같다.

product_interaction
123_product_click

 

product_interaction은 상품과 관련된 상호작용이라는 뜻은 있지만, 클릭인지 노출인지 장바구니 담기인지 명확하지 않다. 123_product_click은 이벤트명 앞에 숫자가 붙어 있어 의미를 파악하기 어렵고, 관리하기에도 좋지 않다. 더 명확한 이벤트명은 다음과 같이 작성할 수 있다.

product_click
product_impression
add_to_cart
main_banner_click

 

이처럼 로그 이름은 분석가, PM, 개발자가 모두 이해할 수 있도록 명확해야 한다.

- 통일성

통일성은 로그 설계 기준을 정하고, 전사적으로 일관된 방식으로 로그를 관리하는 것이다. 로그가 기능별, 팀별, 플랫폼별로 제각각 설계되면 분석이 매우 어려워진다. 예를 들어 같은 의미의 이벤트가 다음처럼 다르게 기록될 수 있다.

product_click
productClick
click_product
prd_click

 

이 경우 데이터를 합치거나 비교하기 위해 추가 작업이 필요하다. 따라서 로그 설계에서는 다음과 같은 기준을 정해야 한다.

• 이벤트명은 snake_case를 사용할 것인지 camelCase를 사용할 것인지
• 페이지명은 어떤 기준으로 작성할 것인지
• 클릭 이벤트는 어떤 접미사를 사용할 것인지
• 노출 이벤트는 impression으로 통일할 것인지 view로 통일할 것인지
• 속성명은 product_id로 할 것인지 item_id로 할 것인지
• 플랫폼별로 동일한 이벤트명을 사용할 것인지

예를 들어 명명 규칙을 snake_case로 정했다면 다음처럼 일관되게 작성해야 한다.

main_pageview
main_banner_impression
main_banner_click
main_product_impression
main_product_click

 

통일성을 위해서는 Event Plan이나 Event Taxonomy를 만들 수 있다. 이러한 문서는 전사적으로 로그 설계 기준을 맞추는 데 도움을 준다.

📒Tracking Plan

- Tracking Plan이란?

Tracking Plan은 전사적인 로그 통일성을 지키기 위해 로그 설계 내용을 체계적으로 정리해두는 문서이다. Tracking Plan은 다음과 같이도 불린다.

• Event Taxonomy
• 이벤트 정의서
• 로그 기획서
• 로그 명세서

Tracking Plan은 주로 다음 도구를 사용해서 정리한다.

• Google Sheet
• Notion
• Amplitude
• Mixpanel 등의 프로덕트 분석 솔루션

Tracking Plan은 단순히 로그 목록을 적어두는 문서가 아니다. 어떤 이벤트를, 어떤 이름으로, 어떤 속성과 함께, 어떤 시점에, 어떤 플랫폼에서 수집할 것인지 정리하는 기준 문서이다.

- Tracking Plan이 필요한 이유

Tracking Plan이 필요한 이유는 크게 두 가지이다.

1. 전사적인 로그의 통일성 유지
2. 효율적인 데이터 탐색 가능

Tracking Plan이 없으면 같은 기능을 두고도 사람마다 다른 이름으로 로그를 설계할 수 있다. 또한 나중에 데이터를 분석하려고 할 때 어떤 이벤트가 무엇을 의미하는지 파악하기 어렵다. Tracking Plan이 있으면 다음과 같은 장점이 있다.

• 이벤트의 의미를 쉽게 확인할 수 있다.
• 어떤 속성이 함께 들어오는지 알 수 있다.
• 로그 발생 시점을 확인할 수 있다.
• 플랫폼별 수집 여부를 확인할 수 있다.
• 버전 변경 이력을 관리할 수 있다.
• 개발자와 분석가가 같은 기준으로 소통할 수 있다.

- Tracking Plan을 작성해야 하는 시점

Tracking Plan은 다음과 같은 시점에 작성해야 한다.

1. 신규 기능을 출시할 때
2. 기존 기능 중 로깅이 되어 있지 않은 부분에 대해 새로 로깅이 필요할 때
3. 기존에 있던 기능을 수정하거나 삭제할 때

신규 기능을 출시할 때는 해당 기능의 성과를 측정하기 위해 어떤 로그가 필요한지 미리 정의해야 한다. 기존 기능에 로깅이 없다면 분석을 위해 새롭게 로그를 추가해야 한다. 기존 기능을 수정하거나 삭제할 때는 기존 로그도 함께 수정하거나 더 이상 사용하지 않도록 관리해야 한다. 기능은 바뀌었는데 로그는 그대로 남아 있으면, 데이터 해석에 오류가 생길 수 있다.

- Tracking Plan 작성 시 공통 정보 처리

'누가', '언제'와 같이 모든 로그에 공통적으로 들어가야 하는 정보는 Tracking Plan에 매번 별도로 정리하지 않아도 된다. 대신 필수적으로 적재하도록 규칙을 정해 둔다. 예를 들어 다음과 같은 정보는 공통 정보로 관리할 수 있다.

• user_id
• device_id
• device
• app_version
• timestamp
• client_access_timestamp
• server_access_timestamp

따라서 Tracking Plan에서는 주로 event와 event_attribute를 중심으로 설계한다. event와 event_attribute만 잘 설계해도 실제 유저의 이벤트 로그에는 공통 정보와 이벤트 정보가 함께 적재된다.

✏️Tracking Plan 작성 항목

Tracking Plan을 작성할 때는 보통 다음과 같은 항목을 정리한다.

항목	설명
이벤트 설명	어떤 이벤트인지 설명
기획서 혹은 디자인 문서	관련 문서 링크
event	이벤트명
event_attribute	이벤트 속성
Description	이벤트 속성 설명
Trigger	로그 발생 시점
State	상태
Platform	플랫폼
Last Update Version	마지막 업데이트 버전

 

각 항목을 자세히 보면 다음과 같다.

- 이벤트 설명

이벤트 설명은 해당 이벤트가 어떤 사용자 행동을 의미하는지 적는 항목이다. 예를 들어 main_banner_click이라는 이벤트가 있다면, 이벤트 설명에는 '메인 페이지에서 배너를 클릭했을 때 발생하는 이벤트'라고 작성할 수 있다.

- 기획서 혹은 디자인 문서

기획서 혹은 디자인 문서 항목에는 해당 이벤트와 관련된 문서 링크를 넣는다. 로그 설계는 보통 화면 개발 전에 진행되므로, 디자인 파일이나 기획서를 보면서 어떤 화면 요소에 로그를 심을지 결정한다. 관련 문서 링크가 있으면 개발자나 QA 담당자가 어떤 화면의 어떤 요소를 의미하는지 쉽게 확인할 수 있다.

- event

event는 이벤트명을 의미한다. 예시는 다음과 같다.

main_pageview
main_banner_impression
main_banner_click
main_product_impression
main_product_click
category_pageview
category_quick_menu_click

 

event는 사용자의 행동을 대표하는 이름이므로 명확하고 일관되게 작성해야 한다.

- event_attribute

event_attribute는 이벤트와 함께 수집할 속성이다. 예를 들어 main_product_click 이벤트라면 다음과 같은 속성을 함께 수집할 수 있다.

• product_id
• product_name
• product_category
• product_price
• product_discount_rate
• section_name
• product_index

속성이 있어야 이벤트를 더 세부적으로 분석할 수 있다. 상품 클릭 수만 아는 것보다 어떤 상품이 클릭되었는지, 어떤 위치의 상품이 클릭되었는지 아는 것이 훨씬 유용하다.

- Description

Description은 event_attribute가 무엇을 의미하는지 설명하는 항목이다. 예를 들어 product_id라는 속성이 있다면 Description에는 '클릭한 상품의 고유 ID'라고 작성할 수 있다. 속성명만 보고 의미가 명확하지 않을 수 있으므로 Description을 함께 작성하는 것이 좋다.

- Trigger

Trigger는 이벤트가 발생하는 시점이다. 예를 들어 다음과 같이 작성할 수 있다.

event	Trigger
main_pageview	사용자가 메인 페이지에 진입했을 때
main_banner_impression	배너 영역의 60% 이상이 화면에 노출되었을 때
main_banner_click	사용자가 메인 페이지 배너를 클릭했을 때
main_product_click	사용자가 메인 페이지 상품 영역을 클릭했을 때

Trigger는 개발자가 실제 로그를 구현할 때 기준이 되므로 구체적으로 작성해야 한다.

- State

State는 해당 로그의 상태를 의미한다. 예를 들어 다음과 같이 관리할 수 있다.

• 기획 완료
• 개발 중
• 개발 완료
• QA 중
• QA 완료
• 배포 완료
• 삭제 예정
• 사용 중단

State를 관리하면 현재 로그 설계와 개발 진행 상황을 파악하기 쉽다.

- Platform

Platform은 해당 로그가 수집되는 플랫폼을 의미한다. 예시는 다음과 같다.

• Web
• Android
• iOS
• Server
• WebView

플랫폼별로 로그 수집 여부가 다를 수 있기 때문에, Tracking Plan에 플랫폼을 명확히 적어두는 것이 좋다.

- Last Update Version

Last Update Version은 마지막으로 업데이트된 버전을 의미한다. 앱 서비스에서는 버전별로 로그가 다르게 동작할 수 있다. 따라서 어떤 버전부터 해당 로그가 적용되었는지 관리해야 한다. 버전 정보를 관리하면 특정 기간의 로그 누락이나 변경 사항을 추적할 때 유용하다.

📑Tracking Plan 예시

예를 들어 메인 페이지와 카테고리 페이지를 대상으로 Tracking Plan을 작성한다면 다음과 같은 이벤트를 정의할 수 있다.

- 메인 페이지 이벤트 예시

이벤트 설명	event	Trigger
메인 페이지 진입	main_pageview	사용자가 메인 페이지에 진입했을 때
메인 페이지 배너 노출	main_banner_impression	메인 배너가 기준 이상 화면에 노출되었을 때
메인 페이지 배너 클릭	main_banner_click	사용자가 메인 배너를 클릭했을 때
메인 페이지 상품 노출	main_product_impression	메인 페이지 상품이 기준 이상 화면에 노출되었을 때
메인 페이지 상품 클릭	main_product_click	사용자가 메인 페이지 상품을 클릭했을 때

- 카테고리 페이지 이벤트 예시

이벤트 설명	event	Trigger
카테고리 페이지 진입	category_pageview	사용자가 카테고리 페이지에 진입했을 때
카테고리 페이지 배너 노출	category_banner_impression	카테고리 배너가 기준 이상 화면에 노출되었을 때
카테고리 페이지 배너 클릭	category_banner_click	사용자가 카테고리 배너를 클릭했을 때
카테고리 페이지 퀵메뉴 노출	category_quick_menu_impression	퀵메뉴가 기준 이상 화면에 노출되었을 때
카테고리 페이지 퀵메뉴 클릭	category_quick_menu_click	사용자가 퀵메뉴를 클릭했을 때

- 실제 이벤트 로그 적재 예시

event와 event_attribute를 설계하면 실제 이벤트 로그에는 공통 정보와 이벤트 정보가 함께 적재된다. 공통 정보 예시는 다음과 같다.

• user_id
• device
• app_version
• client_access_timestamp

이벤트 정보 예시는 다음과 같다.

• event
• event_attribute

예를 들어 실제 로그에는 다음과 같은 이벤트가 들어올 수 있다.

main_pageview
main_banner_impression
main_product_impression
main_product_click

 

이때 각 이벤트에는 user_id, device, app_version, timestamp 같은 공통 정보가 함께 붙는다.

- Tracking Plan을 더 세분화한 예시

Tracking Plan을 더 세분화해서 작성할 수도 있다. 예를 들어 이벤트명을 하나로만 관리하는 대신, page, action, target 등으로 쪼개서 관리할 수 있다. Tracking Plan에 포함될 수 있는 항목은 다음과 같다.

• page
• action
• target
• target_section
• target_value
• target_index
• Trigger
• State
• Platform
• Version
• Update Date

실제 이벤트 로그에는 다음과 같은 항목이 들어올 수 있다.

• user_id
• device
• app_version
• timestamp
• page
• action
• target
• target_section
• target_value
• target_index

예를 들어 메인 페이지의 첫 번째 배너 클릭 로그라면 다음과 같이 기록할 수 있다.

항목	값 예시
page	main
action	click
target	banner
target_section	top_banner
target_value	spring_sale
target_index	1

 

이렇게 세분화하면 이벤트명을 너무 많이 만들지 않고도 구조적으로 로그를 관리할 수 있다.

📥데이터 타입을 표현하는 용어들

Tracking Plan을 작성할 때는 속성이 갖는 데이터 타입을 미리 규정해 두는 것이 좋다. 데이터 타입이 통일되어야 나중에 데이터를 조회하고 가공할 때 오류를 줄일 수 있다.

유형	용어	설명
정수	INT, INTEGER	1, 2, 3 등 정수 형태의 데이터를 표현할 때 사용하는 용어
소수	FLOAT	0.1, 1.2 등 소수 형태의 데이터를 표현할 때 사용하는 용어
숫자	NUMBER	정수와 소수 구분 없이 숫자 형태를 표현할 때 사용하는 용어
문자	VARCHAR, STR, STRING	“안녕”, “hi” 등 문자 형태의 데이터를 표현할 때 사용하는 용어
날짜	DATE	YYYY-MM-DD 형식의 날짜 데이터를 표현할 때 사용하는 용어
시간	TIME	HH:MM:SS 형식의 시간 데이터를 표현할 때 사용하는 용어
날짜와 시간	DATETIME	YYYY-MM-DD HH:MM:SS 형식으로 날짜와 시간을 모두 포함한 데이터를 표현할 때 사용하는 용어
리스트	LIST	[1, 2, 3], [“a”, “b”, “c”]처럼 여러 항목이 대괄호 안에 나열된 형태
불리언	BOOL, BOOLEAN	True/False 두 가지 값만 가지는 형태

 

예를 들어 product_id는 문자열로 관리할 수도 있고 숫자로 관리할 수도 있다. 이 기준이 명확하지 않으면 어떤 플랫폼에서는 숫자로 들어오고, 어떤 플랫폼에서는 문자로 들어올 수 있다. 따라서 Tracking Plan에서 속성별 데이터 타입을 정해두는 것이 좋다.

💣로그 설계 시 주의할 점

1. 지표에서 출발해야 한다

로그 설계는 '무엇을 다 기록할까?'가 아니라 '어떤 지표를 계산해야 할까?'에서 출발해야 한다. 예를 들어 배너 성과를 보고 싶다면 다음 지표가 필요할 수 있다.

• 배너 노출 수
• 배너 클릭 수
• 배너 클릭률
• 배너 클릭 후 구매 전환율

이 지표를 계산하려면 배너 노출 로그, 배너 클릭 로그, 구매 로그와 연결 가능한 정보가 필요하다.

2. 이벤트명은 명확해야 한다

이벤트명은 어떤 행동을 의미하는지 바로 알 수 있어야 한다. 좋지 않은 예시는 다음과 같다.

interaction
click_event
event_01
product_action

 

이런 이름은 구체적으로 무엇을 의미하는지 알기 어렵다. 더 명확한 예시는 다음과 같다.

product_click
banner_impression
category_pageview
add_to_cart

 

3. Attribute는 분석에 필요한 수준으로 남겨야 한다

Attribute가 너무 적으면 분석할 수 있는 범위가 좁아진다. 반대로 너무 많으면 관리가 복잡해진다. 예를 들어 상품 클릭 이벤트에 최소한 다음 정보는 필요할 수 있다.

• product_id
• page
• section
• index

상품별 클릭률을 보고 싶다면 product_id가 필요하고, 영역별 성과를 보고 싶다면 section이 필요하다. 위치별 성과를 보고 싶다면 index가 필요하다.

4. Trigger는 모호하지 않아야 한다

Trigger가 모호하면 개발자마다 다르게 구현할 수 있다. 예를 들어 '상품이 보이면'이라는 표현은 너무 모호하다. 다음처럼 구체적으로 작성하는 것이 좋다.

상품 이미지 영역의 60% 이상이 화면에 노출되었을 때

 

또는 클릭 이벤트라면 다음처럼 작성할 수 있다.

사용자가 상품 카드 영역을 클릭했을 때

 

Trigger는 로그의 기준이 되기 때문에 최대한 구체적으로 작성해야 한다.

5. 플랫폼별 차이를 고려해야 한다

웹, Android, iOS는 로그 수정 반영 속도가 다르다. 특히 앱은 배포와 업데이트 과정이 필요하기 때문에 로그 오류를 빠르게 고치기 어렵다. 따라서 앱 로그는 설계 단계에서 더 꼼꼼하게 확인하고, QA도 충분히 진행해야 한다.

6. 통일된 명명 규칙이 필요하다

명명 규칙이 없으면 로그가 제각각 쌓인다. 예를 들어 어떤 팀은 productClick을 쓰고, 다른 팀은 product_click을 쓰면 나중에 데이터를 합치기 어렵다. 따라서 다음과 같은 기준을 정해야 한다.

• snake_case를 사용할 것인가?
• camelCase를 사용할 것인가?
• 페이지명은 어떻게 쓸 것인가?
• 클릭 이벤트는 _click으로 끝낼 것인가?
• 노출 이벤트는 _impression으로 끝낼 것인가?
• 상품은 product로 부를 것인가 item으로 부를 것인가?

이 기준은 Tracking Plan에 함께 정리해두는 것이 좋다.

👏마무리

사용자 행동 로그 설계는 프로덕트 데이터 분석을 위한 기초 작업이다. 서비스 운영용 데이터만으로도 매출, 주문 수, 회원 수 같은 전반적인 비즈니스 현황은 볼 수 있다. 하지만 사용자가 실제로 서비스 안에서 어떤 행동을 했는지, 어떤 화면을 봤는지, 어떤 버튼을 클릭했는지, 어느 단계에서 이탈했는지를 분석하려면 사용자 행동 로그가 필요하다. 로그 설계는 단순히 데이터를 많이 쌓는 일이 아니다. 분석 목적과 지표를 먼저 정의하고, 그 지표를 계산하기 위해 필요한 이벤트와 속성을 설계하는 일이다. 전체 흐름은 다음과 같다.

문제 정의 → 지표 기획 → 로그 설계 → 로그 개발 → QA → 데이터 분석

 

로그 설계에서 중요한 개념은 다음과 같다.

개념	설명
User Property	어떤 특성의 유저인지 설명하는 정보
Event Property	사용자가 어떤 행동을 했는지 설명하는 정보
Event	어떤 행위에 대한 로그인지
Attribute	이벤트와 함께 저장할 부가 정보
Trigger	로그가 발생하는 시점
Tracking Plan	로그 설계 내용을 체계적으로 정리한 문서

 

특히 Event Property를 설계할 때는 Event, Attribute, Trigger를 명확히 정의해야 한다. 이벤트명은 이해하기 쉬워야 하고, 속성은 분석에 필요한 수준으로 포함되어야 하며, Trigger는 개발자가 동일하게 이해할 수 있도록 구체적이어야 한다. 또한 로그는 한 번 잘못 쌓이면 나중에 수정하기 어렵다. 특히 앱 로그는 배포와 업데이트 과정이 필요하기 때문에 처음 설계와 QA가 중요하다. 결국 좋은 로그 설계란 다음 조건을 만족하는 것이다.

• 분석 목적이 명확하다.
• 필요한 지표를 계산할 수 있다.
• 이벤트명과 속성명이 이해하기 쉽다.
• Trigger가 구체적이다.
• 플랫폼별 차이를 고려했다.
• 전사적으로 통일된 기준을 따른다.
• Tracking Plan으로 관리된다.

사용자 행동 로그는 프로덕트 개선의 근거가 된다. 따라서 로그 설계는 데이터 분석을 하기 전 단계이지만, 실제 분석의 품질을 결정하는 매우 중요한 과정이라고 볼 수 있다.