PM/PO에게 데이터 분석은 대시보드에서 전환율이나 리텐션을 확인하고, SQL로 필요한 숫자를 뽑는 일로 생각하기 쉽다. 하지만 데이터 분석의 본질은 숫자를 계산하는 데 있지 않다. 무엇을 결정해야 하는지 정의하고, 막연한 문제를 검증할 수 있는 질문으로 구체화한 뒤, 그 질문에 답할 데이터를 찾아 제품 의사결정으로 연결하는 과정에 가깝다. 따라서 분석의 최종 산출물은 차트나 대시보드가 아니다. 무엇을 결정해야 하는지, 그 판단을 뒷받침하는 근거가 무엇인지 명확해지는 것이 분석의 결과다.
또한 이 과정은 한 번 끝나는 체크리스트가 아니라 반복되는 학습 과정이다.
데이터 분석은 무엇을 결정해야 하는지에서 시작한다
1. 질문 정의 — 무엇을 결정해야 하는가?
분석은 “데이터를 찾아보자”가 아니라 “어떤 결정을 내려야 하는가?”에서 시작한다. “리텐션이 왜 낮지?”라는 질문은 너무 넓다. 이를 “첫 주에 핵심 행동 X를 수행한 신규 사용자의 4주차 잔존율이 그렇지 않은 사용자보다 높은가?”로 바꾸면 분석 대상과 비교 기준이 명확해진다. 좋은 질문에는 의사결정 대상, 사용자 집단, 기간, 핵심 지표, 비교 기준이 들어간다. 질문이 구체적일수록 분석의 범위도 자연스럽게 좁아진다.
2. 데이터 수집 — 질문에 답할 데이터를 확보한다.
질문이 정해졌다면 이를 검증할 데이터를 찾아야 한다. 제품 분석에서는 행동 이벤트, 거래 데이터, VOC, 설문, 실험 배정값 등이 활용될 수 있다. 중요한 것은 데이터의 양이 아니라, 질문에 필요한 데이터가 제대로 기록되고 측정되어 있는가다. 데이터가 아무리 많아도 핵심 행동이 측정되지 않았다면 분석에는 한계가 있다.
3. 데이터 검증 — 이 숫자를 믿어도 되는가?
분석에서는 숫자를 계산하는 것만큼 그 숫자를 믿을 수 있는지 확인하는 일이 중요하다. 중복 데이터, 결측값, 봇 트래픽, 시간대 차이, 사용자 식별자 변경, 이벤트 정의 변경 등은 같은 지표를 전혀 다른 결과로 만들 수 있다. 따라서 데이터의 정확성, 완전성, 그리고 현재 분석 목적에 적합한지를 확인해야 한다. 측정 기준이 불명확하거나 데이터 정의가 바뀌었다면 정확해 보이는 숫자도 잘못된 의사결정으로 이어질 수 있다.
4. 패턴과 변화 확인 — 무슨 일이 일어났는가?
데이터를 사용자군, 시간, 행동 등 다양한 관점에서 나눠 보며 눈에 띄는 변화와 패턴을 찾는다. 세그먼트, 퍼널, 코호트, 시간대별 추이 등을 비교해 변화가 발생한 지점과 영향을 받은 사용자 집단을 구체적으로 확인한다. 기술통계는 현상을 전체적으로 이해하기 위한 출발점이고, 진단 분석은 차이나 변화가 어디에서 비롯됐는지를 살펴보는 과정이다. 다만 데이터에서 함께 나타나는 현상이 반드시 원인과 결과를 의미하는 것은 아니다. 특정 기능을 많이 사용하는 사용자의 리텐션이 높더라도, 그 기능이 리텐션을 높였다고 바로 결론 내릴 수는 없다. 원래 충성도가 높은 사용자가 해당 기능도 많이 사용하는 것일 수 있기 때문이다. 따라서 이 단계에서는 발견한 패턴을 원인으로 단정하기보다, 추가로 검증할 가설로 발전시키는 것이 중요하다.
5. 해석 — 숫자의 의미를 제품 관점에서 이해한다. 분석 결과가 나왔다고 바로 의사결정을 내릴 수 있는 것은 아니다. 중요한 것은 숫자의 차이를 제품 맥락에서 해석하는 것이다. 효과의 크기는 어느 정도인지, 특정 사용자에게 결과가 치우쳐 있지는 않은지, 계절성이나 신규·기존 사용자 구성 변화가 영향을 미치지는 않았는지, 측정 오류는 없는지 등을 함께 살펴야 한다. 한 지표가 좋아지는 대신 다른 지표가 악화되는지도 확인해야 한다. 결국 “전환율이 3% 올랐다”에서 끝나는 것이 아니라 왜 올랐는지, 누구에게서 올랐는지, 제품 가치와 연결되는지, 그래서 무엇을 해야 하는지까지 해석해야 한다.
6. 의사결정 — 그래서 무엇을 할 것인가?
분석의 마지막은 보고서가 아니라 결정이다. 출시할 것인지, 중단할 것인지, 추가 실험을 할 것인지, 혹은 먼저 필요한 데이터를 측정할 수 있도록 측정 체계를 보완할 것인지를 선택해야 한다. 이후 실제 결과를 다시 데이터로 확인하면서 새로운 질문을 만든다.
결국 데이터 분석은 질문 → 데이터 → 검증 → 분석 → 해석 → 결정 → 학습의 순환이다. 이 순환이 반복되면서 제품에 대한 이해가 깊어진다.
PM/PO에게 왜 중요한가
PM/PO의 핵심 업무는 데이터를 분석하는 것이 아니라, 불확실한 상황에서 제품의 방향과 우선순위를 결정하는 것이다. 데이터 분석은 그 판단에 필요한 근거를 마련하고, 무엇을 먼저 검증할지 결정하는 데 도움을 준다.
첫째, 데이터는 우선순위를 정하는 근거가 된다.
“이 기능이 중요하다”는 의견을 “어떤 문제가 더 많은 고객에게 영향을 주는가?”, “해결했을 때 어떤 효과를 기대할 수 있는가?”라는 질문으로 바꿔볼 수 있다. 데이터의 가치는 특정 의견을 증명하는 것이 아니라, 여러 선택지를 비교하고 무엇을 먼저 검증할지 판단하는 데 있다.
둘째, 행동 데이터는 사용자가 말하는 것과 실제 행동 사이의 차이를 보여준다.
사용자 인터뷰와 VOC는 문제를 발견하는 중요한 출발점이지만, 사용자가 말한 요구가 실제 행동으로 이어지는지는 별개의 문제다. 예를 들어 사용자는 “결제 과정이 불편하다”고 말할 수 있다. 하지만 퍼널을 살펴보면 실제 이탈은 결제수단 선택 단계에 집중되어 있을 수 있다. 퍼널은 이탈 지점을, 코호트는 시간에 따른 사용자 변화를, 세그먼트는 사용자군별 차이를 보여준다. 따라서 데이터는 사용자의 목소리를 대체하는 것이 아니라, 사용자의 말과 실제 행동을 함께 이해하기 위한 또 하나의 근거가 된다.
셋째, KPI와 OKR은 보고용 숫자가 아니라 제품 학습을 위한 장치가 될 수 있다.
지표를 정하는 것만으로 데이터 기반 조직이 되는 것은 아니다. 중요한 것은 무엇을 측정하고, 변화를 어떻게 해석하며, 그 결과를 다음 행동에 어떻게 연결하느냐다. 예를 들어 가입 전환율만 높이면 전환율은 개선되지만 활성화율이나 리텐션이 떨어질 수 있다. 따라서 핵심 지표와 함께 품질, 오류율, 취소율, CS 문의량 같은 가드레일 지표도 함께 봐야 한다. 이렇게 구성한 지표 체계는 단순히 성과를 보고하는 것을 넘어, 제품의 변화가 어떤 결과를 만들었는지 확인하고 다음 가설에 반영하는 학습 시스템이 된다.
넷째, 실험은 가설을 검증한다.
과거 데이터를 보는 것만으로는 “이 변화가 실제로 결과를 만들었는가?”를 판단하기 어려울 수 있다. A/B 테스트처럼 두 집단을 비교하는 실험을 통해 변화가 실제 결과에 영향을 주었는지 확인할 수 있다. 중요한 것은 필요한 경우 큰 개발에 앞서 작은 규모로 실험하고, 데이터를 통해 가설을 검증하는 것이다. 물론 실험 결과도 표본이나 기간, 측정 방법에 따라 달라질 수 있으므로 결과를 그대로 받아들이기보다 맥락을 함께 살펴봐야 한다.
결국 PM/PO에게 데이터 분석이 중요한 이유는 데이터를 많이 다루기 위해서가 아니다. 더 나은 우선순위를 정하고, 사용자를 이해하고, 목표 달성 여부를 확인하고, 아이디어를 검증하기 위해서다.
데이터 분석과 데이터 사이언스는 무엇이 다른가
데이터 분석과 데이터 사이언스를 단순히 ‘쉬운 분석과 어려운 분석’으로 나누기는 어렵다. 실제 현장에서는 사용하는 도구와 방법도 상당 부분 겹친다. 중요한 차이는 어떤 문제를 해결하려는가에 있다.
제품 관점에서 데이터 분석은 현재 제품에서 무슨 일이 일어나고 있는지 파악하고, 그 원인을 찾아 의사결정을 돕는 데 초점이 있다. 반면 데이터 사이언스는 이를 넘어 미래를 예측하거나 사용자를 분류·추천하고, 이를 모델로 만들어 제품이나 운영에 활용하는 데 더 큰 비중을 둔다. 예를 들어 “최근 결제 전환율이 떨어진 이유가 무엇인가?”라면 SQL, 퍼널, 세그먼트 분석만으로도 원인을 찾을 수 있다. 반면 “이탈 가능성이 높은 사용자를 미리 찾아 리텐션 액션을 제공하자”는 문제라면 머신러닝 모델과 학습 데이터, 모델 평가와 운영까지 필요할 수 있다.
물론 두 직군의 경계가 항상 명확한 것은 아니다. 조직에 따라 한 사람이 SQL 분석부터 머신러닝까지 담당하기도 한다. 따라서 PM/PO에게 중요한 것은 누가 어떤 일을 하는가보다, 제품 문제를 해결하기 위해 어느 수준의 분석이 필요한지를 판단하는 것이다.
PM/PO가 머신러닝 모델을 직접 개발할 필요는 없다. 대신 “AI로 이탈 사용자를 예측해 주세요”라고 요청하기보다, 다음처럼 문제와 목표를 구체적으로 정의할 수 있어야 한다.
“최근 30일 동안 이탈 가능성이 높은 사용자를 찾아 개인화된 리텐션 메시지를 제공하고 싶다. 예측 정확도뿐 아니라 실제 리텐션 개선 효과가 중요하고, 잘못된 알림으로 인한 사용자 경험 저하도 최소화해야 한다.”
이렇게 문제와 목표를 구체적으로 정의하면 데이터 사이언티스트도 적절한 모델과 평가 방법을 설계할 수 있다. 결국 PM/PO의 역할은 두 직군 사이에서 업무를 전달하는 것이 아니다. 비즈니스 문제를 데이터로 확인할 수 있는 질문으로 구체화하고, 필요한 분석 수준을 판단하며, 그 결과를 다시 제품 의사결정으로 연결하는 것에 가깝다.
실제 프로젝트에서는 ‘가설 → 측정 → 실험 → 결정’이 하나의 흐름이어야 한다
실제 프로젝트에서 데이터 분석은 분석 단계에서 시작하지 않는다. 어떤 가설을 검증할 것인지 정의하는 순간부터 시작된다. 예를 들어 신규 사용자의 4주차 잔존율을 높이는 프로젝트라면 다음과 같은 가설을 세울 수 있다.
“가입 후 24시간 이내에 친구를 초대한 신규 사용자는 그렇지 않은 사용자보다 4주차 잔존율이 높을 것이다.”
가설을 검증하려면 먼저 무엇을 측정하고 성공을 어떻게 판단할지 정해야 한다. 핵심 지표는 초대 완료율과 4주차 잔존율, 가드레일은 초대 거부율이나 스팸 신고율 등으로 설정할 수 있다. 중요한 것은 지표의 이름만 정하는 것이 아니다. 분모와 분자, 관측 기간, 제외 조건, 성공 기준을 미리 정의해야 한다. 예를 들어 초대 완료율도 전체 가입자를 기준으로 할지, 초대 화면에 진입한 사용자를 기준으로 할지에 따라 의미가 달라진다. 기준을 사전에 정해야 결과에 따라 판단 기준을 바꾸는 일을 막을 수 있다.
기록·측정은 분석보다 먼저 설계되어야 한다. 분석에 필요한 사용자 행동이 실제 제품에서 정확하게 기록되고 있는지 먼저 확인해야 한다. 어떤 이벤트를 수집할지, 그 이벤트가 무엇을 의미하는지, 누가 정의를 관리할지 명확해야 한다. 도구보다 중요한 것은 데이터의 정의와 일관성이다. 같은 이벤트와 지표를 조직의 모든 사람이 같은 의미로 이해하고 있어야 한다. 데이터의 품질과 최신성, 접근 권한 같은 기본적인 운영 기준도 필요하다. 이렇게 준비된 데이터를 바탕으로 사용자 행동을 분석하고, 필요하다면 인터뷰나 VOC 같은 정성 데이터와 함께 결과를 해석한다.
실험은 가설을 검증한다. 기록·측정이 준비되면 가설을 검증하기 위한 실험을 설계할 수 있다. 실험에는 A/B 테스트, 사용자 그룹을 나누는 비교 실험, 프로토타입 테스트 등 다양한 방법이 있다. A/B 테스트는 제품 개선에서 널리 활용되는 대표적인 방법으로, 사용자를 무작위로 나누어 개선안을 적용한 실험군과 기존 경험을 유지하는 대조군의 결과를 비교한다. 목적은 단순히 “새 기능이 더 좋은가?”를 확인하는 것이 아니다. 변경 사항이 실제 결과에 영향을 주었는지 검증할 수 있는 환경을 만드는 것이다. 따라서 실험은 아이디어를 승인하기 위한 절차라기보다 아이디어가 틀렸음을 빠르게 발견하고, 다음 의사결정에 필요한 근거를 얻는 장치로 보는 편이 적절하다.
결정은 데이터 하나로 내려지지 않는다. 실험 결과가 나왔다고 의사결정이 자동으로 이루어지는 것은 아니다. 효과의 크기, 세그먼트별 차이, 가드레일 지표, 구현·운영 비용 등을 함께 살펴봐야 한다. 그 결과에 따라 전면 출시, 수정 후 재실험, 중단 등을 결정한다. 이 과정을 반복하면 제품 개선은 하나의 순환으로 이어진다. 가설 → 측정 → 데이터 → 실험 → 해석 → 결정 → 다시 가설.
각 단계는 따로 떨어져 있지 않다. 가설이 명확해도 필요한 데이터가 제대로 기록되지 않았다면 검증할 수 없고, 데이터가 정확해도 성공 기준이 없다면 결과에 따라 판단이 흔들린다. 따라서 데이터 분석은 프로젝트 마지막에 숫자를 확인하는 작업이 아니다. 가설을 세우는 순간부터 무엇을 측정하고, 어떻게 검증하고, 그 결과에 따라 무엇을 결정할지 함께 설계하는 제품 개발 과정이다.
데이터 기반 PM/PO는 숫자를 해석한다
좋은 PM/PO는 대시보드를 많이 보는 사람이 아니다. 무엇을 결정해야 하는지 정의하고, 그 결정에 필요한 데이터를 설계하는 사람이다. 결정 전에 질문과 가설을 세우고, 출시 전에 필요한 이벤트와 지표를 정의한다. 분석 결과를 해석할 때는 숫자뿐 아니라 가정과 한계, 사용자 맥락까지 함께 살펴본다.
데이터의 역할은 직관을 없애는 것이 아니다. 직관을 검증 가능한 가설로 바꾸는 것이다. 하지만 숫자가 모든 질문에 답해주는 것은 아니다. 정량 데이터는 무슨 일이 얼마나 일어났는지 보여주는 데 강하고, 정성 연구는 왜 그런 일이 일어났는지 이해하는 데 강하다. 따라서 데이터 기반 제품 관리는 둘 중 하나를 선택하는 것이 아니라, 서로 다른 근거를 함께 해석하는 과정이다.
이를 실제 업무에 적용한다면 주요 제품 과제마다 다음 일곱 가지를 한 장으로 정리해볼 수 있다.
- 의사결정 — 무엇을 결정해야 하는가?
- 가설 — 어떤 변화가 어떤 결과를 만들 것인가?
- 핵심·가드레일 지표 — 성공과 부작용을 무엇으로 측정할 것인가?
- 이벤트 명세 — 어떤 행동을 어떤 기준으로 기록할 것인가?
- 분석·실험 계획 — 어떤 데이터를 어떻게 비교할 것인가?
- 결과와 한계 — 무엇을 확인했고 무엇은 아직 알 수 없는가?
- 후속 행동 — 출시, 수정, 추가 실험, 중단 중 무엇을 할 것인가?
그리고 회고에서는 “예측이 맞았는가?”보다 “이번 프로젝트에서 얻은 학습이 다음 의사결정을 더 빠르고 정확하게 만들었는가?”를 묻는 것이 중요하다.
결국 데이터 기반 PM/PO의 역량은 SQL이나 대시보드의 개수로 결정되지 않는다. 숫자가 무엇을 말해주는지, 무엇을 말해주지 않는지를 구분하고, 데이터와 사용자 경험, 비즈니스 목표를 함께 고려해 다음 의사결정으로 연결하는 능력이 핵심이다.