사용자 행동 로그 분석: 원천 로그에서 지표까지의 경로

사용자 행동 로그 분석이란?
사용자 행동 로그 분석은 앱과 웹에서 발생한 원천 이벤트 기록을 정제, 세션화, 집계 단계로 가공해 전환율과 리텐션 같은 의사결정용 지표로 바꾸는 작업이다.

같은 회의실에서 두 사람이 다른 전환율을 말한다. PM은 4.4%라 하고, 개발팀은 서버 원장 기준 4.2%라 한다. 둘 다 틀리지 않았다. 원천 로그에서 지표까지 오는 길에 정제 규칙이 서로 달랐을 뿐이다.

행동 로그 분석이 어려운 지점은 분석 기법이 아니다. 원천 데이터가 지표가 되기까지 거치는 변환 단계가 문서화되지 않은 채 각자의 SQL 안에만 숨어 있는 구조다. 이 글은 가상의 국내 구독형 커머스 팀 하나를 세워두고, 로그 한 줄이 대시보드 숫자 하나가 되기까지의 경로를 실제 숫자를 대입해 따라간다. 각 단계의 변수는 그대로 두었으니 자기 서비스 숫자를 넣어 계산해 보면 된다. 기준 시점은 2026년 8월이다.

원천 로그와 지표 사이에는 네 개의 층이 있다

로그가 지표가 되는 경로는 네 층으로 나뉜다. 층마다 데이터가 줄어들고, 줄어드는 비율을 아무도 모르면 숫자 논쟁이 시작된다.

층을 나눠 보는 이유는 단순하다. 지표가 이상할 때 어느 층을 열어봐야 하는지 알기 위해서다.

변수부터 정의한다

• D = 일 활성 사용자 수
• E = 사용자 1인당 하루 평균 이벤트 수
• R = 정제 후 유효 이벤트 비율
• S = 세션 구분 기준 (무활동 시간)
• C = 퍼널 각 단계 전환율

1단계: 원천 로그 볼륨을 먼저 계산한다

가상의 팀 조건을 잡는다. 구독형 커머스 앱, D = 30,000명, E = 25건. 전부 가정한 숫자다.

• 일 원천 이벤트 = 30,000 × 25 = 750,000건
• 월 원천 이벤트 = 750,000 × 30 = 22,500,000건

월 2,250만 건이라는 숫자가 왜 먼저 필요한가. 분석 도구 요금제, 웨어하우스 스토리지 비용, 쿼리 시간이 전부 이 숫자에서 출발하기 때문이다. 도구를 고르기 전에 이 계산부터 해야 견적이 현실과 맞는다. 주요 도구의 플랜별 이벤트 한도는 수시로 바뀌므로 공식 요금 페이지에서 직접 확인하는 편이 안전하다.

2단계: 정제하면서 얼마가 빠지는지 기록한다

이 팀이 제외 규칙을 세 개 걸었다고 하자.

R = 21,604,875 ÷ 22,500,000 = 96.0%. 4%가 사라졌다. 문제는 4%라는 값이 아니라, 이 값이 팀 전체에 공유되는지 여부다. 마케터가 만든 대시보드는 봇만 걸렀고 분석가의 쿼리는 세 개를 다 걸렀다면, 두 숫자는 영원히 만나지 않는다.

정제 규칙은 개인 쿼리가 아니라 파이프라인 단계나 도구 안의 공통 필터로 올라가야 한다. 도구 선택의 기준도 사실 여기서 갈린다. 정제된 데이터셋 위에서 비개발 직군이 직접 조합해 볼 수 있는 구조인지, 아니면 매번 분석가에게 요청해야 하는 구조인지가 조직의 분석 속도를 결정한다.

3단계: 세션화와 사용자 결합

S = 30분 무활동으로 잡는다. 이 팀의 하루 세션 수를 사용자당 2.1개로 관측했다면 일 세션은 63,000개다. 여기서 자주 터지는 사고가 익명 ID와 로그인 ID의 분리다.

계산해 보면 심각성이 보인다. 비로그인 상태로 탐색하다 결제 직전 로그인하는 사용자가 전체의 40%라고 하자. 이들의 세션이 병합되지 않으면 일 사용자 수가 30,000명이 아니라 30,000 + (30,000 × 0.4) = 42,000명으로 계산된다. 사용자 기준 전환율의 분모가 40% 부풀고, 전환율은 실제의 71% 수준으로 낮게 나온다. 지표가 나빠 보여서 개선 과제를 잡았는데 원인이 ID 병합 설정이었던 경우가 실제로 흔하다.

4단계: 퍼널을 산출하고 검증한다

정제된 월 2,160만 건 안에서 구매 퍼널 4단계를 뽑는다.

여기서 멈추면 절반만 한 것이다. 마지막 작업은 원장 대조다. 결제 서버가 기록한 실제 주문이 51,000건이라면 로그 기준 52,800건과 1,800건, 3.5% 차이가 난다. 이 격차의 통상적 원인은 세 가지다. 결제 완료 화면에 다시 들어와 이벤트가 또 발사되는 경우, 부분 취소 건 미반영, 앱 백그라운드 전환 시 재시도 로직의 중복 전송이다.

3.5%는 대시보드를 못 쓸 정도의 오차는 아니다. 다만 이 값을 측정해 두었는지가 중요하다. 오차 범위를 모르는 팀은 A/B 테스트에서 2% 개선을 관측했을 때 실제 개선인지 측정 노이즈인지 판단할 근거가 없다.

자기 팀 숫자로 옮기는 방법

1. D와 E를 곱해 월 원천 볼륨을 낸다. 요금제와 스토리지 견적의 출발점이다.
2. 제외 규칙을 문서 한 장에 모으고 R을 측정한다. 분기마다 다시 잰다.
3. 익명 ID 병합 설정을 확인하고, 병합 전후 사용자 수 차이를 기록한다.
4. 핵심 퍼널 하나를 골라 단계별 전환율과 누적 전환율을 분리해 본다.
5. 마지막 단계를 서버 원장과 대조해 오차율을 상수로 관리한다.

케이스: 로그는 쌓았는데 답이 안 나오던 팀

국내 이커머스 팀 하나를 가정한다. 실명 사례가 아니라 위 계산을 그대로 이어간 시나리오다.

이 팀은 이벤트 스키마 40종을 정의해 2년간 적재했다. 그런데 "장바구니 이탈이 왜 늘었나"라는 질문에 답하는 데 매번 4일이 걸렸다. 원인을 뜯어보니 세 가지였다.

• 정의된 40종 중 실제 볼륨의 82%를 상위 12종이 차지했고, 나머지 28종은 프로퍼티 규격이 제각각이라 조합 분석에 쓸 수 없었다.
• 정제 규칙이 분석가 3명의 개인 쿼리에 흩어져 있어 같은 지표가 회의마다 다르게 보고됐다.
• 익명 ID 병합이 꺼져 있어 사용자 기준 지표가 실제보다 낮게 유지됐다.

정리 후 달라진 것은 분석 기법이 아니라 질문에서 답까지의 시간이었다. 4일 걸리던 질문이 PM이 직접 화면에서 세그먼트를 조합해 30분 안에 확인하는 형태로 바뀐다. 티맵 CDO가 공개 인터뷰에서 "자판기에서 버튼 누르듯 데이터가 나오는 환경"이라고 표현한 상태가 이 지점이다.

도구가 이 경로에 개입하는 방식

4층 경로 중 어디까지를 도구가 대신해 주는지에서 차이가 갈린다. GA4는 트래픽 소스와 광고 성과를 보는 데 특화된 도구다. 반면 제품 안에서 벌어지는 행동 경로를 파고들 때는 구조에서 제약이 드러난다. Exploration 리포트에서 대량 이벤트 구간에는 샘플링이 걸리고, 리포트 반영에 하루 이상 걸리며, 원천 로그에 직접 닿으려면 BigQuery를 연동해야 한다. 기본 데이터 보관 기간도 짧게 설정돼 있어 장기 코호트 추적에는 별도 설계가 필요하다.

이 제약은 "GA4가 나쁘다"는 이야기가 아니라, 위에서 계산한 3단계와 4단계 작업을 GA4 화면 안에서 끝내기 어렵다는 뜻이다. 프로덕트 애널리틱스 도구는 정제와 세션화를 파이프라인 단계에서 처리한 뒤, 샘플링 없는 전체 데이터 위에서 퍼널과 코호트를 드래그앤드롭으로 조합하는 구조를 택한다. SQL 없이 비개발 직군이 4층에 직접 닿게 하는 것이 설계 목적이다.

도구를 고를 때 기능 개수보다 먼저 봐야 할 질문은 하나다. 도입 3개월 뒤 이 화면을 스스로 여는 사람이 몇 명인가. 개념을 처음부터 정리하려면 프로덕트 애널리틱스란? 글이 출발점으로 적당하고, 후보군을 좁히는 단계라면 사용자 분석 툴 비교에서 믹스패널·앰플리튜드·포스트호그의 구조 차이를 확인해 볼 만하다. 특정 도구의 설정 절차가 궁금하다면 믹스패널 완벽 입문 가이드를 참고하면 된다.

더 읽어보기

• 프로덕트 애널리틱스란?
• 믹스패널 완벽 입문 가이드
• 사용자 분석 툴 비교 (믹스패널·앰플리튜드·포스트호그)

자주 묻는 질문

원천 로그를 전부 보관해야 하나?

전부 쌓되, 분석용 데이터셋과는 분리하는 편이 낫다. 원천 로그는 정제 규칙을 바꿨을 때 과거를 다시 계산하기 위한 안전장치다. 다만 4층 지표는 정제된 데이터셋 위에서만 산출하도록 고정해야 숫자가 하나로 유지된다. 보관 비용이 부담이면 상위 볼륨 이벤트만 원천 보관하고 나머지는 집계 후 폐기하는 기준선을 두면 된다.

이벤트 스키마는 몇 개가 적당한가?

개수보다 사용률이 기준이다. 위 시나리오처럼 40종을 정의해도 12종이 볼륨의 대부분을 차지한다면, 나머지는 관리 비용만 늘리고 있을 가능성이 높다. 새 이벤트를 추가할 때 "이 이벤트로 어떤 결정을 내릴 것인가"에 한 문장으로 답하지 못하면 보류하는 규칙이 효과적이다.

GA4가 이미 붙어 있는데 왜 별도 도구가 필요한가?

두 도구가 답하는 질문이 다르기 때문이다. GA4는 어떤 채널에서 얼마나 유입됐는지에 강하다. 반대로 유입 이후 제품 안에서 왜 이탈했는지, 어떤 행동을 한 사용자가 4주 뒤에도 남는지는 GA4 화면 안에서 파고들기 어렵다. 샘플링, 리포트 반영 지연, 원천 로그 접근 제약이 겹치기 때문이다. 위 4층 경로에서 GA4가 담당하는 구간은 사실상 1층과 2층 일부이고, 3층과 4층을 실무 속도로 돌리려면 그 목적으로 만들어진 도구가 필요하다.

숫자 하나가 아니라 경로를 문서화한다

행동 로그 분석의 성패는 분석 기법에서 갈리지 않는다. 원천 이벤트가 지표가 되기까지 몇 퍼센트가 어디서 빠졌는지, 그 규칙이 팀 전체에 공유돼 있는지에서 갈린다. R값을 아는 팀과 모르는 팀의 차이는 회의 시간의 길이로 나타난다.

오늘 할 수 있는 일은 작다. 핵심 퍼널 하나를 골라 위 다섯 단계를 자기 숫자로 채워보고, 마지막 단계를 서버 원장과 대조해 오차율을 적어두는 것이다. 그 한 장이 다음 분기의 지표 논쟁을 대부분 끝낸다.

Nitrox 블로그에서 관련 가이드 더 보기