SQL은 곧잘 짜는데, 면접에서 "코호트 분석 해보신 적 있나요?"라는 질문에 말문이 막힌 적 있으신가요? 아니면 실무에서 "이번 온보딩 개편, 진짜 효과 있었던 거예요?"라는 질문에 매출 그래프 하나 보여주는 것 말고는 딱히 할 말이 없었던 경험은요?
리포트를 뽑아내는 것과, 왜 지표가 움직였는지를 구조적으로 설명하는 것은 완전히 다른 역량이에요. 그리고 그 차이를 가르는 지점에 코호트 분석, 퍼널 분석, A/B 테스트라는 세 가지 방법론이 있습니다. 이 세 가지는 실무에서도, 면접에서도 반복적으로 등장하는 데이터 분석가의 기본기예요. 이번 글에서는 각 방법론이 무엇인지, 언제 쓰는지, 어떤 예시로 활용되는지, 그리고 실무에서 자주 발생하는 실수는 무엇인지 정리해볼게요.
코호트 분석 — 사용자를 그룹으로 나눠서 봐야 보이는 것들
코호트 분석은 같은 시점에 특정 행동을 시작한 사용자 그룹(코호트)을 묶어서, 시간이 지나며 그들이 얼마나 돌아오는지 추적하는 방법이에요. 예를 들어 "이번 달 가입한 사용자 그룹"을 하나의 코호트로 놓고, 1주 후·2주 후·1개월 후 몇 %가 다시 서비스를 사용했는지 살펴보는 식이죠[1].
전체 사용자를 대상으로 한 평균 리텐션율만 보면 놓치는 게 많아요. 예를 들어 지난달 전체 리텐션이 30%로 나왔다고 해도, 신규 유입 채널이 바뀌었거나 특정 프로모션 시기에 가입한 사용자군이 유난히 이탈이 심할 수 있거든요. 코호트로 쪼개서 보면 이런 시점별 차이가 뚜렷하게 드러납니다[1].
코호트를 나누는 대표적인 3가지 기준은 다음과 같아요[1].
획득 코호트: 가입일(주간/월간)처럼 서비스에 처음 유입된 시점 기준
행동 코호트: 온보딩 완료처럼 특정 행동을 한 시점 기준
매출 코호트: 구독 등급 등 수익화 관련 속성 기준
언제 쓰면 좋을까요? 특정 시점 이후 사용자가 얼마나 남아있는지, 또는 특정 정책 변경 전후로 리텐션 패턴이 달라졌는지 확인하고 싶을 때 코호트 분석이 유용해요. 예를 들어 "3월에 온보딩 UX를 개편했는데, 3월 이후 가입한 코호트의 리텐션이 그 전보다 좋아졌는가?" 같은 질문에 답할 수 있습니다.
코호트 분석에서 흔히 하는 실수는 이렇습니다[1].
지저분한 이벤트 데이터: 추적 불일치나 중복 로그, 봇 트래픽이 섞이면 사용자가 엉뚱한 코호트에 잡혀버려요.
너무 작은 표본 크기: 코호트 크기가 작으면 리텐션 비율이 노이즈에 취약해져서, 몇 명만 이탈해도 수치가 크게 요동칩니다.
지표 오정렬: '아무 활동'처럼 지나치게 포괄적인 이벤트를 리텐션 기준으로 잡으면, 실제 제품 가치를 반영하지 못하는 숫자만 보게 돼요. 리텐션 정의는 실제 제품 가치와 맞닿아 있어야 합니다[1].
퍼널 분석 — 사용자가 어디서 이탈하는지 추적하기
퍼널 분석은 사용자가 목표(가입, 구매 등)에 도달하기까지 거치는 단계를 순서대로 정의하고, 각 단계에서 다음 단계로 넘어가는 전환율과 이탈률을 측정하는 방법이에요. 예를 들어 "상품 조회 → 장바구니 담기 → 결제 → 구매 완료"처럼 단계를 나눠서, 어느 지점에서 사용자가 가장 많이 빠져나가는지 확인합니다[2].
퍼널을 설계할 때는 전환 창(conversion window)도 함께 정해야 해요. 사용자가 각 단계를 어느 정도 시간 안에 완료해야 '전환'으로 인정할지 기준을 잡는 거예요. 이 기준에 따라 전환율 수치가 달라질 수 있습니다[2].
퍼널 분석의 목적은 명확해요. "가장 많은 사용자가 마지막 단계를 완료하기 전 어디서 빠져나가는지" 확인하는 것[2]. 예를 들어 회원가입 퍼널을 보면 "이메일 입력 → 인증 → 프로필 작성 → 가입 완료" 중 인증 단계에서 유난히 많은 사용자가 이탈한다면, 인증 절차 자체가 문제일 가능성이 높다는 걸 데이터로 짚어낼 수 있죠.
다만 퍼널 분석에는 태생적인 한계도 있어요. 사전에 정의한 단계 순서는 실제 사용자의 행동 경로와 다를 수 있고, 도구는 "어디서" 이탈했는지는 보여줘도 "왜" 이탈했는지까지 설명해주지는 못해요[2]. 사람들은 우리가 예상한 그대로 움직이지 않거든요[2].
퍼널 분석에서 흔히 하는 실수는 세그먼트 없이 평균 전환율에만 의존하는 것이에요[3]. 전체 퍼널의 평균 전환율만 보면 오해하기 쉬워요. 예를 들어 전체 전환율은 정상 범위인데, 특정 유입 채널이나 특정 디바이스에서 유입된 사용자만 유독 전환율이 낮을 수 있거든요. 세그먼트별로, 또는 코호트별로 쪼개서 봐야 특정 사용자 그룹이 왜 그 단계를 통과하지 못했는지 더 깊이 파악할 수 있습니다[3].
A/B 테스트 — 추측이 아니라 검증으로 의사결정하기
코호트와 퍼널 분석이 "지금 무슨 일이 일어나고 있는가"를 보여주는 관찰형 분석이라면, A/B 테스트는 "이 변경이 실제로 지표를 개선하는가"를 인과적으로 검증하는 방법이에요. 사용자를 무작위로 대조군(control, 기존 버전을 보는 그룹)과 실험군(treatment, 새 버전을 보는 그룹)으로 나누고, 두 그룹의 지표 차이를 비교합니다.
여기서 핵심 개념이 통계적 유의성(statistical significance)이에요. 실험군과 대조군의 성과가 실제로는 동일했다고 가정했을 때, 지금 관측된 차이가 얼마나 이례적인 결과인지를 나타내는 지표예요[6]. 표본 크기를 계산하려면 기준 전환율(baseline conversion rate), 최소 감지 가능 효과(MDE, 얼마나 작은 개선까지 감지하고 싶은지), 유의수준(보통 95%), 검정력(보통 80%)이 필요합니다[6]. 유의수준을 높게 잡을수록 더 큰 표본과 더 긴 실험 기간이 필요하고, 낮게 잡으면 결과는 빨리 나오지만 거짓양성(실제로는 차이가 없는데 있다고 잘못 판단하는 것) 가능성이 커져요[6].
예를 들어 "가입 버튼의 문구를 '무료로 시작하기'에서 '지금 시작하기'로 바꾸면 클릭률이 오를까?"라는 질문을 검증하고 싶다면, 두 문구를 각각 다른 사용자 그룹에 무작위로 노출시키고 클릭률 차이가 통계적으로 유의한지 확인하는 게 전형적인 A/B 테스트예요.
A/B 테스트에서 가장 흔하고 치명적인 실수는 'peeking'이에요. 실험 도중 결과를 반복적으로 들여다보다가, 유의해 보이는 순간 테스트를 조기 종료하는 겁니다. Evan Miller의 유명한 아티클에 따르면, 유의성 계산은 표본 크기가 사전에 고정되어 있다는 가정 위에서만 성립해요. "유의한 차이가 보일 때까지 계속 돌린다"는 방식으로 실험을 진행하면 보고되는 유의수준 자체가 무의미해집니다[4]. 실제로 실험 도중 결과를 여러 번 반복해서 들여다보면, 원래 설계했던 유의수준이 실질적으로는 훨씬 느슨한 수준으로 왜곡될 수 있다고 해요[4]. 해법은 단순해요. 표본 크기를 실험 시작 전에 정하고, 실험이 끝날 때까지 결과를 들여다보지 않는 것(no peeking)입니다[4].
이 외에도 실무에서 자주 나오는 실수들이 있어요[5].
평균에만 집중하기: 전체 평균 지표만 보고 세그먼트별 반응 차이를 놓치는 것
테스트 기간이 너무 짧은 것: 시간이 지나며 사용자 반응이 달라질 수 있다는 점을 고려하지 않는 것
한 번에 너무 많은 요소를 동시에 테스트하는 것: 어떤 변경이 실제로 효과를 냈는지 분리해내기 어려워짐
요약 — 세 방법론, 언제 무엇을 써야 할까
방법론 | 무엇을 알 수 있나 | 언제 쓰나 | 흔한 실수 |
|---|---|---|---|
코호트 분석 | 같은 시점에 시작한 사용자 그룹의 시간 경과에 따른 리텐션 패턴 | 특정 시점/정책 변경 전후 사용자 유지율을 비교하고 싶을 때 | 표본이 작은 코호트를 그대로 신뢰하거나, 제품 가치와 무관한 지표를 리텐션 기준으로 삼는 것[1] |
퍼널 분석 | 다단계 전환 프로세스에서 어느 단계 이탈이 가장 큰지 | 가입, 결제 등 여러 단계를 거치는 전환 흐름의 병목을 찾고 싶을 때 | 세그먼트 없이 평균 전환율만 보고 특정 그룹의 문제를 놓치는 것[3] |
A/B 테스트 | 특정 변경이 지표에 인과적으로 미치는 영향 | 새로운 기능·문구·디자인이 실제로 효과가 있는지 검증하고 싶을 때 | peeking(중간 결과를 보고 조기 종료), 표본 크기 부족, 지나치게 많은 변수 동시 테스트[4] [5] |
세 방법론은 서로 대체재가 아니라 상호보완적인 도구예요. 코호트 분석으로 "요즘 리텐션이 떨어지고 있다"는 걸 발견했다면, 퍼널 분석으로 "어느 단계에서 이탈이 늘었는지" 좁히고, 그 원인으로 추정되는 변경사항을 A/B 테스트로 검증하는 흐름이 실무에서는 자연스럽게 이어집니다.
마무리
세 방법론 모두 개념 자체는 어렵지 않아요. 진짜 어려운 건 "이 상황에서 어떤 방법론을 써야 할지"를 판단하고, 그 결과를 SQL로 직접 구현해내는 실전 감각이에요. 코호트 테이블을 짜보고, 퍼널 전환율 쿼리를 직접 만들어보고, A/B 테스트 결과를 표본 크기까지 고려해서 해석해보는 연습이 쌓일수록 "숫자만 뽑는 사람"에서 "인사이트를 설계하는 사람"으로 한 걸음씩 가까워질 수 있어요.
이런 방법론은 한 번에 완성되는 지식이 아니라 꾸준히 실무에서 부딪히며 다듬어가는 스킬이에요. 트리업의 기술 가이드에서 관련 스킬을 찾아보고, 스킬 관리 기능으로 내가 어떤 방법론을 얼마나 다뤄봤는지 정리해두면 다음 커리어 스텝을 준비할 때도 도움이 될 거예요.
