프로덕트 데이터 분석: 지표, 로그, 실험

프로덕트 데이터 분석이란

서비스를 운영하며 쌓이는 사용자 데이터로 서비스를 계속 고쳐 나가는 일이다. 데이터 과학자가 되거나 머신 러닝을 정복하는 것과는 목표가 다르다. 그래서 첫걸음도 Python 책이 아니라 「우리 서비스는 어떤 도메인에 있고, 사용자는 어떻게 들어와 무엇을 하다 떠나는가」를 정리하는 것이다. 통계와 코드는 질문이 생긴 뒤에 필요해진다. 질문 대부분은 SQL 집계만으로도 답할 수 있다.

데이터 분석가의 직무 전체는 데이터 직군에 있다. 이 노트는 그 핵심 업무인 지표·로그·실험을 다룬다.

네 단계 분석 프로세스

1. 서비스를 보는 틀 만들기   사용자 여정: 들어옴 → 핵심 기능 → 상태 변화 → 결제·이탈
2. 로그를 지표로            사람·돈 지표를 정의하고, 지표 사이 관계와 선행 지표를 찾는다
3. OMTM 정하기              지금 단계에서 가장 중요한 지표 하나에 팀이 합의한다
4. 쪼개서 들여다보기         코호트·퍼널·A/B 테스트로 원인을 찾고 행동으로 옮긴다

1. 서비스를 보는 틀(operation framework) 은 사용자 여정 지도와 비슷하다. 앱 다운로드 → 계정 생성 → 본인 인증 → 튜토리얼 → 정회원 → 활동 회원 → 결제 회원, 그리고 이탈까지 상자와 화살표로 그린다. 그러면 질문이 세 종류로 정리된다. 화살표의 전환율은 얼마인가, 상자의 값(인원·매출)은 얼마인가, 둘에 영향을 주는 변수는 무엇인가. 잘 짠 틀은 사용자를 데려오기(get users), 안착시켜 핵심 기능을 쓰게 하기(drive usage), 그 과정에 수익 모델을 붙이기(make money)를 모두 담고, 단계가 퍼널처럼 이어진다.

AARRR

가장 널리 쓰는 틀은 스타트업 투자자 데이브 매클루어의 AARRR(해적 지표)이다. 단계마다 핵심 지표를 하나씩 정한다.

순서를 꼭 지킬 필요는 없다. 사이드 프로젝트에서 유지·수익부터 보는 변주는 사이드 프로젝트 팁에 있다.

지표

지표(metric)는 서비스에서 생기는 로그를 의미 있고 분석할 수 있는 형태로 요약한 값이다.

정의를 아는 것은 기본이다. 중요한 것은 그다음이다.

조작적 정의: 누구나 같은 숫자를 떠올리게

「활동 회원이 두 배 늘었다」, 「상반기에는 리텐션을 높이자」는 말은 정의가 없으면 사람마다 다른 숫자를 떠올린다. 활동의 기준(로그인? 핵심 행동?), 리텐션의 측정 방식과 유형, 현재값과 목표값, 기간의 경계를 오해 없이 정해 둔다(조작적 정의, operational definition). ARPU의 「User」가 가입자 전체인지 활동 사용자인지에 따라 같은 매출도 다른 값이 된다.

게임처럼 서버 점검 시각(예: 수요일 06시)을 경계로 하루·한 주가 도는 서비스는 「6월 첫째 주」도 달력이 아니라 서비스의 시간으로 정의해야 한다.

저량과 유량

모니터링 대시보드는 「사용자 데려오기 · 안착 · 수익」 세 영역마다 저량과 유량을 나란히 두는 구조가 기본이다.

허무 지표

허무 지표(vanity metric)는 보기 좋고 쉽게 움직일 수 있지만 무엇을 해야 할지 알려 주지 않는 지표다. 다운로드·설치·페이지뷰, 고객 문의 처리 건수, 버그 개수, 기능 개선 건수가 대표적이다. 보고서에 쓰면 열심히 일한 것처럼 보이지만 실제로 중요한 숫자와 상관이 약하다. 다만 같은 지표도 도메인에 따라 핵심이 된다. 소개팅 서비스나 LinkedIn처럼 다른 회원이 곧 상품인 서비스는 총 회원 수가 중요하다.

비교의 기준점

• 모든 도메인에서 무조건 중요한 지표는 매출뿐이다. DAU가 중요하지 않은 서비스도 많다.
• ARPU 2,000원이 높은지 낮은지는 같은 서비스의 추세나 같은 카테고리 안에서만 판단한다. 쇼핑과 게임의 리텐션, 오픈마켓과 큐레이션 쇼핑의 리텐션을 직접 비교하는 것은 의미가 없다.
• 가장 기본은 추세다. 지난달 대비 무엇이 달라졌는지를 한 달이 끝나기 전에 알 수 있게 만든다.

지표를 조합해 읽기

선행 지표와 후행 지표

매출, ARPU, 가입자 수, DAU, 리텐션 같은 지표 대부분은 결과로 보이는 후행 지표다. 「리텐션을 올리자」보다 「어떤 지표를 관리하면 결과적으로 리텐션이 오르는가」가 훨씬 중요하다. 승리를 예측하는 데 타율보다 출루율·장타율이 낫다는 것을 먼저 발견한 야구단처럼, 남들이 아직 모르는 좋은 선행 지표를 찾는 것 자체가 경쟁력이다. GA 같은 범용 도구가 자동으로 주지 못하는 부분이라, 서비스 로그를 직접 분석해야 하는 이유이기도 하다.

OMTM과 KPI

모든 지표가 모든 시기에 같은 무게를 갖지 않는다. 매출·가입자·체류 시간·결제자 수·재방문율을 똑같은 비중으로 관리하면 자원이 낭비되고 방향을 정할 수 없다(ARPPU를 올릴지 결제 비율을 올릴지 같은 선택). OMTM(One Metric That Matters) 은 외부 환경, 성장 단계, 내부 역량, 이용 패턴을 고려해 지금 꼭 집중할 지표 하나다.

KPI(핵심 성과 지표)를 아직 정하지 않은 조직에서는 분석가가 KPI를 설계하기도 한다. 수치가 오르거나 내리면 「왜」를 분석하는 것이 기본 업무다.

로그 설계와 데이터 품질

남기지 않으면 분석할 수 없다

현업의 로그는 대개 없거나, 있어도 쓸 수 없다. 무엇을, 어떤 형식으로, 어떻게 보내, 어디에 저장할지 정하기 어려워 아예 남기지 않는다. 데이터가 있다고 해도 DB에 현재 상태(state)만 있고 이력(history)이 없는 경우가 많다. 잔고 100만 원도 1,000만 원을 벌어 900만 원을 쓴 사람과 110만 원을 벌어 10만 원을 아낀 사람은 다르다. 그래서 다음을 갖춘다.

• 고민 없이 가져다 쓰는 로그 레시피: 로그를 남기고 중앙 저장소로 보내는 과정을 표준화해 개발자가 쉽게 남기게 한다. 이벤트 스펙과 수집 도구는 Segment에 있다.
• 분석가가 바로 쓰는 테이블과 SQL: 날것의 로그 파일은 몇 번째 필드가 무엇인지 스스로 설명하지 못한다. 메타 정보와 묶어 테이블로 만들어 SQL로 조회하게 한다. 분석가가 분산 처리 코드를 짜고 있으면 하루에 몇 번밖에 반복하지 못한다. 파이프라인 구조는 데이터 파이프라인에 있다.
• 질문마다 테이블을 새로 쌓지 않는다. 「지난주 카테고리별 퀘스트 완료 Top 10과 획득 재화」 같은 질문마다 전용 로그를 만들면 비효율적이다. 분석과 모니터링에 필요한 최소한의 로그를 남기고, 테이블을 조인해 필요한 모양을 만든다.

로그를 어떻게 설계하고, 어떤 원인으로 품질이 깨지며, 출시 전에 무엇을 맞춰 둘지는 이벤트 로그 설계와 수집에 정리했다. 분석가는 서비스를 사용자처럼 전부 써 보며 로깅 항목을 정리하고, 수집이 시작되면 본격 분석 전에 품질부터 확인한다.

쪼개서 보기

심슨의 역설

전체로 볼 때와 나눠 볼 때 결론이 뒤집히는 현상이 심슨의 역설(Simpson's paradox)이다.

전체로는 B가 낫지만 질환별로는 두 경우 모두 A가 낫다. A가 치료가 어려운 간질환 환자를 더 많이 받았기 때문이다. 1973년 UC 버클리 입학 통계(전체로는 남성 44%, 여성 35%였지만 학과별로는 차이가 거의 없거나 반대)도 같은 구조다. 「요즘 누가 이메일을 읽나」 싶던 쇼핑몰 이메일도 전체 오픈율 5.2%가 지난달 한 번이라도 방문한 사용자만 보면 15.4%였다. 분석이 만족스럽지 않다면 충분히 나누지 않았기 때문이다.

쪼개는 도구

퍼널을 볼 때는 다음을 지킨다.

• 서비스 유형마다 경로가 다르다. 고정된 선형 경로, 순서가 바뀌는 선형 경로, 비선형 경로를 구분한다. 지연 전환(delayed conversion)도 고려한다.
• 단계를 독립적으로만 재지 말고 이전 단계에 조건을 건 전환으로도 잰다. 사용자 세그먼트와 함께 볼 때 효과가 크다.
• 서비스의 핵심 기능마다 퍼널을 따로 만든다. 아무리 단순한 단계도 전환율 100%는 없으니, 단계 수를 줄이는 것을 먼저 고려한다.

SQL에서 코호트·퍼널·「다음 방문 월」 같은 계산은 윈도 함수(LEAD, LAG, PARTITION BY user_id ORDER BY visit_month)와 날짜 함수(DATE_TRUNC, DATE_DIFF)로 한다. BigQuery 같은 웨어하우스에서는 날짜로 파티션한 테이블을 조회해야 스캔 비용이 줄고, 반복 집계는 예약 쿼리로 돌린다.

고객 군집화의 쓰임과 한계

고객 유형을 나눌 때는 k-평균 군집화(k-means)를 많이 쓴다. 예를 들어 주간 플레이 시간과 획득 경험치로 「적게 하고 느리게 성장」, 「적게 하지만 빠르게 성장」 같은 네 유형을 만든다. 유형은 주기적으로 갱신하되, 처음 구한 군집 중심을 기억해 새 데이터를 가장 가까운 중심에 배정하면 매번 다시 군집화하지 않아도 된다. 주기마다 쌓인 유형 이력을 시퀀스로 보고 계층적 군집화로 다시 묶으면(sequence clustering) 「처음엔 같은 유형이었지만 시간이 지나며 갈라진 고객」을 찾을 수 있다. 같은 기간 같은 유형이었어도 순서가 다르면(전투 없음 → 길드전 vs 길드전 → 전투 없음) 다른 고객이다.

다만 군집화는 탐색 도구이지 분석의 결론이 되기 어렵다. 고객은 시간이 지나며 변하고 스펙트럼이 넓어서, 교과서처럼 깔끔한 세그먼트가 나온다는 기대는 버린다.

실험

관측 → 가설 → 실험

데이터 과학이 「과학」인 이유는 관측하고 가설을 세우고 실험하는 방법론을 따르기 때문이다. 그런데 많은 조직이 분석만 많이 하고 실험(행동)을 하지 않는다. 공이 30분 뒤에 돌아오는 테니스 연습으로는 실력이 늘지 않듯, 이 순환이 느리면 아무것도 배우지 못한다. 기존 데이터만 수동적으로 분석하면 결과가 너무 당연해 임팩트가 없다. A/B 테스트뿐 아니라 기획 단의 큰 실험(동기 부여 방식 바꾸기, 강의 방식 바꾸기)으로 비교군을 만들어 새로운 양상의 데이터를 생성해야 좋은 인사이트가 나온다.

A/B 테스트

A/B 테스트는 두 변형 A와 B를 무작위로 나눈 사용자에게 보여 주고 반응을 비교하는 통제 실험이다. 상식을 믿지 말고 실험으로 검증해야 하는 이유를 보여 주는 사례가 있다. 한 쇼핑몰이 손님 10%를 세 집단으로 나눠 크고 화려한 배너, 얇은 배너, 배너 없음을 비교했더니 크고 화려한 배너 < 배너 없음 < 얇은 배너였다. 단골 비중이 높은 곳이라 단골에게 큰 배너는 매번 스크롤만 늘리고 상품 자리를 빼앗았던 것이다.

배포 관점에서 실험 대상을 통제하는 방법(피처 토글, 해시 샘플링)은 배포 전략에 있다.

다중 슬롯 머신(MAB)

A/B 테스트는 충분한 사람이 테스트될 때까지 오래 걸리고, 그동안 나쁜 안에 보낸 사용자는 손해다. 다중 슬롯 머신(multi-armed bandit) 알고리즘은 여러 안을 돌아가며 시도하다가 조짐이 좋은 안에 더 자주 보낸다. 더 빨리 찾고, 찾는 동안의 이득도 키운다. 알고리즘의 종류는 실시간 추천과 실험에 있다.

분석 결과를 사용자별로 적용하기

「사흘 이상 접속하지 않은 사용자 전체에게 푸시」는 매일 오던 사용자의 사흘 공백과 주말에만 오던 사용자의 나흘 공백을 같게 본다. 이탈 지수 = 휴면 기간 ÷ 고유 접속 주기로 보면 매일 오던 사용자는 3, 주말 사용자는 0.57이다. 휴면 사용자와 결제 사용자 관리는 개인화하고, 운영용 데이터는 일·주·월뿐 아니라 시간대별로도 본다(9시마다 오던 사용자가 9시에 오지 않았다는 것도 신호다).

결과를 행동으로

공유하는 법

• 분석 기간, 가설, 데이터에서 나온 결론을 적는다. 다음에 무엇을 하면 더 나아질지 제시하면 가장 좋다.
• 단순하고 이해하기 쉬운 그래프를 쓴다. 보기에 멋지지만 이해에 오래 걸리는 시각화는 상대를 움직이지 못한다. 고급 방법론이 늘 나은 것도 아니다. 차트 고르기는 데이터 시각화에 있다.
• 가설 검증에 실패해도 분석이 실패한 것은 아니다. 실패한 분석도 정리해 공유하면 동료가 데이터 오류, 통계 방법론의 잘못, 무리한 가설을 찾아 가설을 되살린다. 작게 자주 공유하면 처음 목적을 계속 떠올리게 돼 분석이 딴 길로 새지 않는다.
• 대조군을 빼먹지 않는다. 과거 데이터를 보는 관찰 분석도 「대조군 대비 실험군의 효과 크기(effect size)」를 말할 수 있어야 한다. 대조군을 정하기 어려우면 무작위로라도 뽑는다.

정기 리포트와 모니터링

모니터링은 인과를 검증하는 일이 아니라 상관관계를 빨리 확인해 이상 징후를 일찍 알리는 일이다. 누가 불을 냈는지 분석하기 전에 「불이야」를 외치는 것이다. 일·주·월 리포트는 아래에 해당하면 필요성을 의심한다.

• 놀지 않았다는 것을 증명하는 데 쓰인다.
• 6개월 동안 형태가 전혀 바뀌지 않았다.
• 팀 막내가 관성으로 작성한다.

잘 쓴 리포트는 받는 사람이 궁금해하는 내용을 그가 알아들을 형태로 담고, 현재 상태(AS-IS)를 정확히 보여 준다. 대책까지 기대하지 않는다. 작성은 최소한의 자원으로, 해석은 꼼꼼하게 한다.

데이터가 돈이 되려면

• 지금 어려운 부서와 일한다. 잘나가는 부서는 인사이트를 줘도 심드렁하다. 힘든 부서는 아이디어를 주고 실행도 함께한다. 작은 성공을 쌓아 큰 부서로 넓힌다. 회사의 약점을 공략하면 작은 인사이트도 주목받는다.
• 「현업이 이미 아는 것」이 나와도 정상이다. 분석의 힘은 기적이 아니라 정량화에 있다. 돌을 던지면 날아간다는 것은 누구나 알지만, 힘·각도·거리를 재야 달에 갈 수 있다. 양을 정확히 알아야 예측하고 행동할 수 있다.
• 마지막 단계는 자동화다. 데이터 → 인사이트 → 행동 → 자동화로 갈수록 사람이 신경 쓰지 않아도 계속 효과를 낸다(예: 고객마다 다른 내용을 기계가 골라 보내는 개인화 뉴스레터).

정리

• 프로덕트 분석은 서비스를 보는 틀 → 로그를 지표로 → OMTM → 쪼개 보기 순서로 한다. 도구 공부는 질문이 생긴 뒤에 한다.
• 지표는 조작적 정의로 모두가 같은 숫자를 떠올리게 하고, 저량과 유량, 선행과 후행을 구분하며, 허무 지표에 속지 않는다.
• 로그는 이력으로, 표준 레시피로, 최소 단위로 남기고, 분석 전에 품질부터 확인한다.
• 전체만 보면 심슨의 역설에 빠진다. 코호트·퍼널·세그먼트로 나누고, 군집화는 탐색에만 쓴다.
• 상식은 A/B 테스트로 검증하되 유의 기준, 신기 효과, 유효 기간, 국지적 최적화를 챙긴다.
• 결론: 분석은 행동과 실험으로 이어질 때만 가치가 있고, 끝은 자동화다.

관련 노트: 데이터 직군, 데이터 파이프라인과 저장소 용어, 데이터 시각화, Segment로 사용자 데이터 수집하기, 배포 전략, 실시간 추천과 실험, 사이드 프로젝트 팁