데이터 기반 프로덕트 개선 프로세스 | 지표 진단부터 A/B 테스트까지

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

💡데이터로 프로덕트를 개선하는 과정

이번 글에서는 데이터 기반 프로덕트 개선 프로세스에 대해 정리해보려고 한다. 프로덕트 데이터 분석은 단순히 데이터를 확인하는 것에 그치지 않고, 데이터를 근거로 프로덕트의 현재 상태를 진단하고, 문제를 발견하고, 원인을 탐구한 뒤, 개선안을 실제 서비스에 반영하고 그 성과를 다시 평가하는 과정까지 포함한다.

 

프로덕트가 점점 다양해지고 서비스 구조도 복잡해지면서 단순히 경험이나 직관만으로 의사결정을 내리는 방식에는 한계가 생긴다. 사용자가 어떤 기능을 사용하는지, 어느 단계에서 이탈하는지, 어떤 개선안이 실제 성과로 이어지는지 확인하기 위해서는 객관적인 데이터가 필요하다. 따라서 프로덕트를 개선하기 위해서는 데이터를 기반으로 문제를 바라보고, 지표를 통해 상태를 판단하며, 실험을 통해 개선 효과를 검증하는 과정이 중요하다.

 

이번 내용은 크게 두 부분으로 나눌 수 있다. 첫 번째는 프로덕트 데이터 분석이 무엇인지에 대한 내용이고, 두 번째는 프로덕트 성장을 위해 데이터를 어떻게 활용하는지에 대한 프로세스이다.

📑프로덕트 데이터 분석이란?

- 프로덕트란?

프로덕트란 고객의 문제 상황을 해결해줄 수 있는 서비스를 의미한다. 대표적으로 웹 서비스와 앱 서비스가 있다. 예를 들어 사용자가 음악을 듣고 싶을 때 사용하는 스트리밍 앱, 영상을 보고 싶을 때 사용하는 동영상 플랫폼, 운동 기록을 관리하기 위해 사용하는 헬스케어 앱, 업무를 관리하기 위한 협업 툴 등이 모두 프로덕트에 해당할 수 있다. 즉, 프로덕트는 단순히 만들어진 앱이나 웹사이트를 의미하는 것이 아니라, 사용자가 겪는 불편함이나 필요를 해결하기 위해 제공되는 서비스라고 볼 수 있다. 사용자가 어떤 문제를 가지고 있고, 그 문제를 서비스가 어떤 방식으로 해결해주는지가 프로덕트의 핵심이 된다.

 

예를 들어 운동 관리 앱이 있다면 사용자의 문제는 '혼자서는 운동 계획을 세우기 어렵다', '운동 기록을 꾸준히 관리하기 어렵다', '내 상태에 맞는 운동 루틴을 찾기 어렵다'와 같은 것일 수 있다. 이때 운동 관리 앱은 사용자의 운동 목표를 입력받고, 현재 상태를 확인하고, 맞춤형 플랜을 제안함으로써 사용자의 문제를 해결하는 프로덕트가 된다.

- 프로덕트 데이터란?

프로덕트 데이터란 프로덕트의 사용성과 성과를 분석하기 위해 수집된 데이터를 말한다. 사용자가 웹이나 앱 서비스를 이용하는 과정에서는 다양한 행동 데이터가 발생한다. 예를 들어 사용자가 어떤 화면에 들어왔는지, 어떤 버튼을 클릭했는지, 어느 단계에서 이탈했는지, 회원가입을 완료했는지, 결제를 했는지와 같은 정보가 모두 프로덕트 데이터가 될 수 있다. 프로덕트 데이터의 예시는 다음과 같다.

구분	예시
방문 데이터	사용자가 서비스에 접속한 횟수, 방문 경로, 유입 채널
행동 데이터	버튼 클릭, 화면 조회, 검색, 스크롤, 특정 기능 사용
전환 데이터	회원가입 완료, 구독 신청, 결제 완료, 문의 제출
이탈 데이터	특정 단계에서 나간 사용자 수, 장바구니 이탈, 온보딩 중단
유지 데이터	재방문율, 재구매율, 구독 유지율, 리텐션
성과 데이터	매출, 결제 전환율, 유료 회원 수, 활성 사용자 수

 

이러한 데이터를 분석하면 사용자가 프로덕트를 어떻게 사용하고 있는지 파악할 수 있다. 예를 들어 사용자가 특정 화면에서 많이 이탈한다면 그 화면이 복잡하거나 다음 행동이 명확하지 않을 수 있다. 특정 버튼 클릭률이 낮다면, 버튼 위치나 문구가 사용자의 행동을 유도하기에 적절하지 않을 수 있다. 회원가입 전환율이 낮다면, 회원가입 과정이 길거나 사용자가 회원가입의 필요성을 충분히 느끼지 못하고 있을 수 있다. 결국 프로덕트 데이터는 사용자의 행동을 수치로 확인하게 해주는 자료이며 프로덕트의 문제를 발견하고 개선 방향을 찾는 근거가 된다.

- 프로덕트 데이터 분석이란?

프로덕트 데이터 분석이란 데이터를 기반으로 프로덕트를 개선하고 의사 결정하는 것을 말한다. 서비스가 단순했던 과거에는 경험과 직관만으로도 어느 정도 의사결정을 할 수 있었을 수 있다. 그러나 현재의 프로덕트는 기능도 다양하고, 사용자 그룹도 세분화되어 있으며, 경쟁 서비스도 많다. 이런 상황에서 단순히 '이 기능이 좋아 보인다', '이 화면이 더 예쁜 것 같다', '사용자들이 아마 이렇게 행동할 것 같다'와 같은 감에만 의존하면 잘못된 결정을 내릴 가능성이 커진다.

 

데이터 기반 의사결정이 중요한 이유는 경험과 직관에 의존한 의사결정이 가져다주는 리스크와 비용이 커졌기 때문이다. 하나의 기능을 잘못 개선하면 개발 리소스가 낭비될 수 있고, 사용자의 불편을 키울 수 있으며, 매출이나 전환율에도 부정적인 영향을 줄 수 있다. 따라서 프로덕트 데이터 분석은 단순히 데이터를 보는 일이 아니라, 데이터를 바탕으로 다음과 같은 질문에 답하는 과정이라고 볼 수 있다.

질문	데이터 분석을 통해 확인할 수 있는 내용
사용자는 어떤 기능을 많이 사용하는가?	핵심 기능 사용률, 클릭률, 화면 조회 수
사용자는 어느 단계에서 이탈하는가?	퍼널 단계별 이탈률, 전환율
어떤 사용자 그룹에서 문제가 두드러지는가?	세그먼트별 전환율, 리텐션, 행동 차이
개선안이 실제로 효과가 있었는가?	A/B 테스트 결과, 개선 전후 지표 변화
프로덕트가 비즈니스 목표에 기여하고 있는가?	매출, 유료 전환율, 회원가입 수, 유지율

 

즉, 프로덕트 데이터 분석은 프로덕트를 더 나은 방향으로 개선하기 위한 근거를 제공하는 역할을 한다.

📋프로덕트 데이터 분석의 역할

프로덕트 데이터 분석은 크게 세 가지 역할을 한다. 첫 번째는 프로덕트 방향성 설정, 두 번째는 프로덕트 성과 수치화, 세 번째는 비용 절감 및 업무 효율성 향상이다.

- 프로덕트 방향성 설정

프로덕트 데이터 분석은 앞으로 프로덕트를 어떤 방향으로 개선해야 하는지 판단하는 데 도움을 준다. 예를 들어 사용자가 특정 기능을 많이 사용한다면, 해당 기능은 프로덕트 내에서 중요한 가치가 있을 가능성이 높다. 반대로 사용자가 거의 사용하지 않는 기능이 있다면, 기능 자체가 필요 없거나, 사용자가 해당 기능을 발견하지 못하거나, 사용 방법이 어렵게 설계되어 있을 수 있다. 또 특정 화면에서 사용자가 많이 이탈한다면, 그 화면은 개선이 필요한 지점일 수 있다. 이처럼 데이터를 보면 사용자가 프로덕트 안에서 어떤 행동을 하는지 알 수 있고, 이를 바탕으로 어떤 기능을 강화해야 하는지, 어떤 부분을 줄이거나 수정해야 하는지 판단할 수 있다.

 

예를 들어 온보딩 과정에서 사용자가 중간에 많이 이탈한다면, 온보딩 단계가 너무 길거나 복잡할 수 있다. 이 경우 프로덕트 팀은 온보딩 단계를 줄이거나, 설명을 더 명확하게 만들거나, 사용자가 서비스의 가치를 더 빨리 이해할 수 있도록 화면을 개선하는 방향을 고려할 수 있다.

- 프로덕트 성과 수치화

프로덕트 데이터 분석은 프로덕트의 성과를 감이나 느낌이 아니라 수치로 확인하게 해준다.

 

예를 들어 '이번에 바꾼 화면이 더 좋아진 것 같다'라고 말하는 것만으로는 실제 성과를 판단하기 어렵다. 하지만 개선 전후의 회원가입 전환율, 클릭률, 결제 전환율, 재방문율 등을 비교하면 실제로 성과가 좋아졌는지 확인할 수 있다. 성과를 수치화할 수 있는 대표적인 지표는 다음과 같다.

지표	의미
회원 가입자 수	일정 기간 동안 회원가입을 완료한 사용자 수
회원가입 전환율	서비스에 들어온 사용자 중 회원가입을 완료한 비율
결제 전환율	상품이나 서비스를 본 사용자 중 결제를 완료한 비율
클릭률	특정 버튼이나 배너를 본 사용자 중 클릭한 비율
이탈률	특정 단계에서 다음 단계로 넘어가지 않고 나간 비율
재방문율	한 번 방문한 사용자가 다시 방문한 비율
리텐션	일정 기간이 지난 후에도 서비스를 계속 사용하는 비율

 

이처럼 프로덕트 성과를 수치화하면 현재 상태를 객관적으로 파악할 수 있고, 개선 전후의 변화를 비교할 수 있다. 또한 팀원들이 같은 지표를 기준으로 논의할 수 있기 때문에 의사소통도 더 명확해진다.

- 비용 절감 및 업무 효율성 향상

데이터를 기반으로 의사결정을 하면 불필요한 시도나 잘못된 방향의 개선을 줄일 수 있다. 프로덕트를 개선할 때는 기획, 디자인, 개발, 배포, 마케팅 등 여러 리소스가 들어간다. 만약 명확한 근거 없이 기능을 만들거나 화면을 수정한다면, 많은 시간과 비용을 들였음에도 성과가 나지 않을 수 있다.

 

반대로 데이터를 활용하면 우선순위를 정하기 쉬워진다. 예를 들어 여러 문제 중에서 어느 지점의 이탈률이 가장 높은지, 어떤 기능이 매출에 더 큰 영향을 주는지, 어떤 사용자 그룹에서 문제가 심각한지 확인할 수 있다. 이를 통해 가장 먼저 해결해야 할 문제를 정하고, 리소스를 더 효율적으로 사용할 수 있다. 즉, 프로덕트 데이터 분석은 단순히 데이터를 확인하는 활동이 아니라, 잘못된 의사결정으로 인한 비용을 줄이고 업무 효율성을 높이는 역할을 한다.

🗣️데이터 기반 의사 결정

- 데이터 기반 의사 결정이란?

데이터 기반 의사 결정, 즉 Data-Driven Decision Making은 의사 결정의 효율성을 위해 직관이나 경험보다 객관적인 데이터를 기반으로 의사 결정하는 방식을 말한다.

 

물론 경험과 직관이 항상 의미 없는 것은 아니다. 경험이 많은 사람은 사용자의 문제를 빠르게 감지하거나 좋은 가설을 세울 수 있다. 하지만 최종 의사결정은 가능한 한 객관적인 데이터로 확인하는 것이 중요하다. 예를 들어 다음과 같은 두 가지 의사결정 방식이 있다고 할 수 있다.

구분	설명
직관 기반 의사결정	'이 디자인이 더 좋아 보인다', '사용자가 이 기능을 좋아할 것 같다'처럼 감이나 경험을 중심으로 판단
데이터 기반 의사결정	실제 사용자의 클릭률, 전환율, 이탈률, 재방문율 등을 확인하고 판단

 

데이터 기반 의사결정은 실제 사용자 행동을 근거로 하기 때문에 의사결정의 설득력을 높일 수 있다. 또한 의사결정 이후에도 결과를 다시 측정할 수 있기 때문에, 개선이 실제로 효과가 있었는지 확인할 수 있다.

- 데이터 기반 의사결정이 필요한 이유

데이터 기반 의사결정이 필요한 이유는 다음과 같다.

 

첫째, 사용자의 실제 행동은 예상과 다를 수 있다. 팀 내부에서는 좋은 기능이라고 생각했지만, 실제 사용자는 거의 사용하지 않을 수 있다. 반대로 사소해 보이는 기능이 사용자에게는 매우 중요한 기능일 수도 있다.

 

둘째, 서비스가 복잡해질수록 문제의 원인을 직관만으로 파악하기 어렵다. 회원가입 수가 줄었다고 해서 단순히 온보딩 화면만 문제라고 단정할 수 없다. 유입 사용자가 줄었을 수도 있고, 특정 기기에서 오류가 발생했을 수도 있으며, 특정 단계의 설명이 부족했을 수도 있다.

 

셋째, 데이터는 팀 내 의사소통의 기준이 된다. 데이터를 기준으로 논의하면 “내 생각에는”이 아니라 “지표를 보면”이라는 방식으로 논의할 수 있다. 이를 통해 의사결정 과정에서 불필요한 의견 충돌을 줄이고, 더 명확한 기준을 세울 수 있다.

🏃‍♂️프로덕트 성장을 위한 데이터 활용 프로세스

프로덕트 성장을 위한 데이터 활용 프로세스는 다음과 같은 흐름으로 진행된다.

1. 지표 기반 상태 진단
2. 문제 발견
3. 데이터 기반 원인 탐구
4. 해결 방안 도출
5. 기능 구현
6. 배포
7. 개선안의 성과 평가

이 과정에서 필요한 경우 로그 설계 후 로깅을 진행하고, 분석 결과를 다시 서비스에 반영한다. 이 흐름은 한 번 진행하고 끝나는 것이 아니라 반복되는 구조이다. 개선안을 배포한 뒤 성과를 평가하고, 그 결과를 다시 다음 개선 과정에 반영하면서 프로덕트를 점진적으로 성장시킨다.

🔍프로세스 1 - 지표 기반 상태 진단

- 지표란?

지표, 즉 Metric은 비즈니스와 프로덕트의 상태를 나타내는 정량적 수치이다.

 

프로덕트의 상태를 제대로 이해하기 위해서는 핵심 지표를 설정하고, 이를 지속적으로 모니터링해야 한다. 지표를 보면 현재 프로덕트가 정상적으로 작동하고 있는지, 어떤 부분에서 문제가 발생하고 있는지, 개선이 필요한 지점이 어디인지 빠르게 파악할 수 있다.

대표적인 지표는 다음과 같다.

지표	설명
신규 유입자 수	새롭게 서비스에 들어온 사용자 수
회원 가입자 수	회원가입을 완료한 사용자 수
회원가입 전환율	유입 사용자 중 회원가입까지 완료한 비율
구매 전환율	상품을 본 사용자 중 구매까지 완료한 비율
클릭률	특정 버튼이나 배너를 본 사용자 중 클릭한 비율
이탈률	특정 단계에서 다음 단계로 이동하지 않은 비율
재방문율	서비스를 다시 방문한 사용자 비율
리텐션	일정 기간 이후에도 계속 서비스를 사용하는 사용자 비율

 

지표 기반 상태 진단은 프로덕트 개선 프로세스의 출발점이다. 현재 상태를 정확히 알아야 문제를 발견할 수 있고, 문제를 발견해야 원인을 탐구하고 개선안을 만들 수 있기 때문이다.

- 핵심 지표를 정하는 방법

핵심 지표를 정할 때는 다음 두 가지를 고려해야 한다.

 

첫째, 기능이 잘 작동하는지 판단하는 기준이 되는가?

둘째, 비즈니스의 핵심 목표와 연결되는가?

 

여기서 중요한 것은 단순히 보기 좋은 숫자를 선택하는 것이 아니라, 해당 기능의 성과를 판단할 수 있고 비즈니스 목표와도 연결되는 지표를 선택해야 한다는 점이다. 예를 들어 어떤 지표가 높아졌다고 해서 무조건 좋은 것은 아니다. 그 지표가 실제 비즈니스 목표와 관련이 없다면 핵심 지표로 보기 어렵다. 반대로 비즈니스 목표와 연결되어 있더라도 특정 기능의 성과를 판단하기 어렵다면, 해당 기능의 핵심 지표로 적절하지 않을 수 있다. 핵심 지표를 정할 때는 다음과 같이 생각해볼 수 있다.

질문	의미
이 지표가 기능의 성공 여부를 설명할 수 있는가?	기능이 잘 작동하는지 판단할 수 있어야 한다
이 지표가 비즈니스 목표와 연결되는가?	서비스 성장, 매출, 유지율 등 핵심 목표와 관련 있어야 한다
사용자의 행동 변화를 반영하는가?	사용자의 실제 행동이 지표에 나타나야 한다
개선 전후 비교가 가능한가?	개선안의 효과를 평가할 수 있어야 한다

📱온보딩 기능 예시로 보는 핵심 지표 선정

- 온보딩 기능이란?

온보딩은 사용자가 서비스를 처음 접했을 때, 서비스의 핵심 가치를 이해하고 주요 행동까지 이어지도록 돕는 과정이다. 예를 들어 운동 관리 앱의 온보딩 과정은 다음과 같이 구성될 수 있다.

1. 신규 유입
2. 환영 인사
3. 운동 목표 설정
4. 현재 상태 확인
5. 플랜 설정
6. 회원 가입 완료

온보딩의 목적은 단순히 사용자를 여러 화면에 통과시키는 것이 아니라, 사용자가 서비스의 가치를 이해하고 계속 사용할 수 있도록 만드는 것이다. 따라서 온보딩 기능을 평가할 때는 사용자가 온보딩을 끝까지 완료했는지, 회원가입까지 이어졌는지, 이후에도 서비스를 사용하는지 등을 확인할 수 있다.

- 핵심 목표: 유료 회원 증가를 통한 수익 극대화

온보딩 기능에 관심이 있고, 프로덕트의 핵심 목표가 유료 회원 증가를 통한 수익 극대화라고 가정해볼 수 있다. 이때 어떤 지표를 핵심 지표로 정하면 좋을지 고민해야 한다. 후보 지표는 다음과 같다.

후보 지표	설명
정보 수집량	온보딩 과정에서 사용자에게 입력받은 정보의 양
신규 유입자 수	새롭게 서비스에 들어온 사용자 수
회원 가입자 수	온보딩 후 회원가입을 완료한 사용자 수

 

이 세 가지 지표는 모두 의미가 있어 보이지만, 핵심 지표로 적절한지는 따로 판단해야 한다.

- 정보 수집량

정보 수집량은 온보딩 과정에서 사용자에게 얼마나 많은 정보를 입력받았는지를 의미한다. 운동 관리 앱이라면 사용자의 성별, 나이, 운동 목표, 운동 경험, 현재 체중, 선호 운동 방식, 운동 가능 시간 등 다양한 정보를 입력받을 수 있다. 많은 정보를 수집하면 사용자에게 더 정교한 추천을 제공할 수 있다는 장점이 있다.

 

하지만 정보 수집량을 늘리기 위해 온보딩 과정이 복잡해지면 오히려 사용자가 중간에 이탈할 수 있다. 사용자는 아직 서비스의 가치를 충분히 경험하기 전이기 때문에, 너무 많은 정보를 요구받으면 부담을 느낄 수 있다. 따라서 정보 수집량은 온보딩 기능의 핵심 목표인 유료 회원 증가를 직접적으로 반영하기 어렵다. 정보 수집량이 많다고 해서 반드시 유료 회원이 증가하는 것은 아니며, 오히려 전환율을 낮출 수도 있다. 즉, 정보 수집량은 참고 지표로는 볼 수 있지만, 온보딩 기능의 핵심 지표로 삼기에는 한계가 있다.

- 신규 유입자 수

신규 유입자 수는 서비스에 새롭게 들어온 사용자의 수를 의미한다. 신규 유입자 수가 많다는 것은 서비스에 관심을 가진 사용자가 많다는 의미일 수 있다. 하지만 신규 유입자 수는 온보딩 기능 자체가 잘 작동하는지 판단하기에는 어렵다.

 

예를 들어 광고를 많이 집행하거나 외부 이벤트를 진행하면 신규 유입자 수는 증가할 수 있다. 하지만 사용자가 온보딩을 잘 완료하는지, 회원가입까지 이어지는지, 유료 회원으로 전환되는지는 별개의 문제이다. 즉, 사용자가 많이 들어왔다고 해서 온보딩이 잘 설계되었다고 볼 수는 없다. 신규 유입자 수는 마케팅이나 유입 채널의 영향을 크게 받을 수 있기 때문에, 온보딩 기능의 성과를 판단하는 핵심 지표로는 부족하다.

- 회원 가입자 수

회원 가입자 수는 온보딩 기능의 핵심 지표로 적절해 보인다. 온보딩 과정의 목적이 사용자를 서비스에 정착시키고 회원가입까지 연결하는 것이라면, 회원 가입자 수는 기능의 성과와 비즈니스 목표를 함께 반영할 수 있다. 특히 유료 회원 증가가 최종 목표라면, 회원가입은 유료 전환으로 이어지기 위한 중요한 중간 단계이다. 사용자가 회원가입을 완료해야 이후 구독, 결제, 플랜 선택 등 다음 행동으로 이어질 가능성이 생기기 때문이다.

 

다만 회원 가입자 수만 보면 전체 유입자 수의 영향을 받을 수 있으므로, 함께 보면 좋은 지표는 회원가입 전환율이다. 회원가입 전환율은 다음과 같이 볼 수 있다.

회원가입 전환율 = 회원가입 완료자 수 / 신규 유입자 수

 

예를 들어 신규 유입자가 1,000명이고 회원가입 완료자가 200명이라면 회원가입 전환율은 20%이다. 이 지표를 보면 단순히 회원가입자 수가 많고 적은 것뿐만 아니라, 들어온 사용자 중 얼마나 많은 사용자가 회원가입까지 도달했는지를 확인할 수 있다. 따라서 온보딩 기능을 분석할 때는 회원 가입자 수와 회원가입 전환율을 핵심 지표로 볼 수 있다.

🔧프로세스 2 - 문제 발견

문제 발견은 지표를 지속적으로 모니터링하다가 이상 징후를 확인하는 단계이다. 예를 들어 온보딩 기능을 분석하는 상황에서 회원 가입자 수가 감소하거나, 회원가입 전환율이 떨어진다면 온보딩 과정에 문제가 있을 수 있다고 판단할 수 있다. 문제 발견 단계에서 중요한 것은 단순히 숫자가 낮아졌다는 사실만 보는 것이 아니다. 어떤 지표에서 이상이 발생했는지, 언제부터 변화가 나타났는지, 특정 사용자 그룹에서만 문제가 발생했는지 등을 함께 확인해야 한다.

 

예를 들어 회원가입 수가 줄었다고 해서 곧바로 온보딩 화면을 수정해야 하는 것은 아니다. 회원가입 수가 줄어든 이유는 신규 유입자 수가 줄었기 때문일 수도 있고, 특정 유입 채널의 품질이 낮아졌기 때문일 수도 있으며, 실제로 온보딩 과정에서 이탈이 증가했기 때문일 수도 있다. 따라서 문제를 발견할 때는 다음과 같은 질문을 해볼 수 있다.

질문	확인해야 할 내용
어떤 지표가 하락했는가?	회원가입 수, 전환율, 클릭률, 리텐션 등
언제부터 하락했는가?	특정 날짜, 배포 이후, 캠페인 종료 이후 등
전체 사용자에게 나타나는 문제인가?	전체 평균 기준 문제인지 확인
특정 그룹에서만 나타나는 문제인가?	연령대, 기기, 유입 채널, 신규/기존 사용자 등
다른 지표도 함께 변했는가?	유입 수, 이탈률, 결제율 등 연관 지표 확인

 

이처럼 문제 발견은 이후 원인 탐구를 위한 출발점이 된다.

🎞️프로세스 3 - 데이터 기반 원인 탐구

- 데이터 기반 원인 탐구란?

데이터 기반 원인 탐구란 가설을 세우고 문제의 원인을 탐구하는 과정이다. 지표를 통해 문제가 발견되었다고 해서 곧바로 해결책을 만들면 안 된다. 문제의 원인을 제대로 파악하지 않고 개선안을 만들면, 실제 원인과 맞지 않는 방향으로 개선할 가능성이 있기 때문이다.

 

예를 들어 회원 가입자 수도 감소하고, 회원가입 전환율도 감소하는 경우 온보딩 기능에 문제가 있을 수 있다고 진단할 수 있다. 하지만 이때 바로 화면을 줄이거나 문구를 바꾸는 것이 아니라, 왜 사용자가 회원가입까지 도달하지 못하는지 원인을 탐구해야 한다. 데이터 기반 원인 탐구에서는 정량 데이터 분석을 먼저 활용할 수 있다. 하지만 정량 분석만으로 원인을 완전히 알기 어려운 경우에는 유저 인터뷰와 같은 정성 조사를 함께 활용할 수 있다.

- 원인 탐구를 위한 질문

회원가입 전환율이 떨어졌다면 다음과 같은 질문을 해볼 수 있다.

• 서비스에 대한 소개가 부족한가?
• 온보딩 화면이 너무 많은가?
• 최근에 디자인을 바꿔서 사용자가 혼란을 느끼는가?
• 특정 사용자 그룹에서만 전환율이 떨어지는가?
• 특정 단계에서 이탈이 많이 발생하는가?
• 사용자가 다음 행동을 이해하지 못하는가?
• 입력해야 하는 정보가 너무 많거나 부담스러운가?
• 회원가입을 해야 하는 이유가 충분히 전달되지 않았는가?

이 질문들은 모두 가설이 될 수 있다. 예를 들어 '최근 디자인 변경 이후 사용자가 혼란을 느껴 전환율이 떨어졌을 것이다'라는 가설을 세울 수 있고, 실제로 디자인 변경 시점 전후의 지표를 비교해볼 수 있다. 또 '특정 연령대에서 온보딩 과정이 복잡하게 느껴져 전환율이 낮아졌을 것이다'라는 가설을 세우고, 연령대별 전환율을 비교할 수도 있다.

 

즉, 원인 탐구 단계에서는 데이터를 통해 문제의 원인을 추정하고, 가설을 세우고, 그 가설을 검증하는 과정이 필요하다.

💻원인 탐구 방법

데이터 기반 원인 탐구는 여러 가지 방법으로 진행할 수 있다. 대표적으로 다음 네 가지 방법이 있다.

1. 시간의 흐름에 따른 변화 확인
2. 세그멘테이션을 통한 그룹별 비교
3. 퍼널 분석
4. 유저 인터뷰

- 시간의 흐름에 따른 변화 확인

시간의 흐름에 따른 변화 확인은 핵심 지표가 시간에 따라 어떻게 변화했는지 보는 방법이다.

 

예를 들어 회원가입 전환율을 일별, 주별, 월별로 확인하면 특정 시점부터 지표가 하락했는지 확인할 수 있다. 만약 UI 변경 시점 이후 회원가입 전환율이 하락했다면, 최근 디자인 변경이 원인인지 의심해볼 수 있다. 이 방법은 특정 이벤트나 변경 사항이 지표에 영향을 주었는지 확인할 때 유용하다. 예를 들어 다음과 같은 상황에서 사용할 수 있다.

상황	확인할 수 있는 내용
UI 변경 이후 전환율 하락	디자인 변경이 사용자 행동에 영향을 주었는지 확인
가격 정책 변경 이후 결제율 변화	가격 변경이 구매 행동에 영향을 주었는지 확인
광고 캠페인 시작 이후 유입 증가	캠페인이 신규 유입에 영향을 주었는지 확인
배포 이후 오류 증가	특정 배포가 문제를 만들었는지 확인

 

다만 시간의 흐름에 따른 변화만으로 원인을 확정할 수는 없다. 같은 시점에 다른 요인도 함께 작용했을 수 있기 때문이다. 따라서 시간 흐름 분석은 원인을 의심하는 출발점으로 활용하고, 다른 분석 방법과 함께 보는 것이 좋다.

- 세그멘테이션을 통한 그룹별 비교

세그멘테이션은 사용자를 여러 그룹으로 나누어 비교하는 방법이다. 전체 평균만 보면 문제가 잘 보이지 않을 수 있다. 특정 사용자 그룹에서는 문제가 심각하지만, 다른 그룹에서는 문제가 없어서 전체 평균으로는 변화가 작게 보일 수 있기 때문이다. 따라서 사용자를 여러 기준으로 나누어 지표를 비교하면 문제가 발생한 구체적인 대상을 찾을 수 있다. 세그멘테이션 기준은 다음과 같을 수 있다.

세그멘테이션 기준	예시
인구 통계학적 특성	연령대, 성별, 지역
유입 시점	신규 사용자, 기존 사용자
유입 채널	검색, 광고, SNS, 추천
행동 특성	특정 기능 사용 여부, 구매 경험 여부
기기/환경	모바일, PC, iOS, Android, 브라우저
고객 상태	무료 회원, 유료 회원, 휴면 사용자

 

예를 들어 회원가입 전환율을 봤을 때 전체적으로는 큰 변화가 없어 보이지만, 40대 이상 사용자 그룹에서 전환율이 크게 떨어졌다면 해당 연령대가 사용하기에 온보딩 과정이 너무 복잡할 수 있다. 또 모바일 사용자에게서만 이탈률이 높다면 모바일 화면에서 버튼이 잘 보이지 않거나, 입력 과정이 불편할 수 있다. 특정 광고 채널에서 유입된 사용자만 전환율이 낮다면, 광고에서 기대한 내용과 실제 서비스 첫 화면이 다를 수 있다.

 

즉, 세그멘테이션을 통한 그룹별 비교는 전체 평균만으로는 찾기 어려운 문제를 발견하는 데 유용하다.

- 퍼널 분석

퍼널 분석은 사용자가 특정 목표에 도달하기까지의 과정을 여러 단계로 나누고, 각 단계별 사용자 수와 전환율을 확인하는 분석 방법이다. 온보딩 과정에서는 다음과 같이 퍼널 단계를 나눌 수 있다.

1. 신규 유입
2. 환영 인사
3. 운동 목표 설정
4. 현황 체크
5. 플랜 설정
6. 회원 가입 완료

각 단계별 사용자 수가 다음과 같다고 가정할 수 있다.

단계	사용자 수	이전 단계 대비 전환율
신규 유입	1,000명	-
환영 인사	800명	80%
운동 목표 설정	400명	50%
현황 체크	300명	75%
플랜 설정	200명	67%
회원 가입 완료	100명	50%

 

이 표를 보면 어느 단계에서 사용자가 많이 이탈하는지 확인할 수 있다. 예를 들어 신규 유입에서 환영 인사로 넘어가는 전환율이 80%라면, 처음 진입한 사용자 중 20%는 다음 단계로 넘어가지 않은 것이다. 운동 목표 설정 단계로 넘어가는 전환율이 50%라면, 환영 인사 단계 이후 절반의 사용자가 이탈한 것이다.

 

퍼널 분석의 핵심은 전체 회원가입 완료자 수만 보는 것이 아니라, 어느 단계에서 이탈이 많이 발생하는지를 보는 것이다.

예를 들어 환영 인사 단계에서 다음 단계로 넘어가는 전환율이 낮다면, 첫 화면이 사용자의 관심을 충분히 끌지 못했을 수 있다. 서비스의 가치가 잘 전달되지 않았거나, 다음 버튼이 눈에 잘 띄지 않았거나, 사용자가 왜 이 과정을 진행해야 하는지 이해하지 못했을 수 있다. 또 플랜 설정 단계에서 이탈이 많다면, 사용자가 플랜의 차이를 이해하지 못했거나, 가격 정보가 부담스럽게 느껴졌거나, 서비스에 대한 정보가 충분하지 않았을 수 있다.

 

이처럼 퍼널 분석은 사용자가 목표 행동에 도달하기까지의 흐름을 단계별로 살펴보고, 병목 지점을 찾는 데 유용하다.

- 유저 인터뷰

유저 인터뷰는 데이터만으로 원인을 파악하기 어려울 때 활용할 수 있는 정성 조사 방법이다. 정량 데이터는 사용자가 어디에서 이탈했는지는 알려줄 수 있지만, 왜 이탈했는지는 명확하게 알려주지 못할 때가 많다. 예를 들어 퍼널 분석을 통해 플랜 설정 단계에서 이탈이 많다는 것을 알 수는 있지만, 사용자가 가격이 비싸다고 느꼈는지, 서비스 설명이 부족하다고 느꼈는지, 선택지가 너무 많아서 어려웠는지는 데이터만으로 알기 어렵다. 이때 유저 인터뷰를 통해 사용자의 실제 의견을 들을 수 있다. 예를 들어 사용자가 다음과 같이 말할 수 있다.

• 환영 인사가 너무 밋밋해서 서비스가 무엇을 해주는지 잘 모르겠다.
• 플랜 설정 단계에서 서비스에 대한 정보가 충분하지 않았다.
• 어떤 선택을 해야 하는지 이해하기 어려웠다.
• 입력해야 하는 정보가 많아서 부담스러웠다.
• 회원가입을 해야 하는 이유가 잘 느껴지지 않았다.

이러한 의견을 바탕으로 구체적인 해결책을 고민할 수 있다. 예를 들어 환영 인사가 너무 밋밋하다는 의견이 있다면, 단순한 환영 메시지 대신 서비스의 핵심 가치와 사용자가 얻을 수 있는 이점을 보여주는 안내 화면을 추가할 수 있다. 플랜 설정 단계에서 서비스 설명이 부족하다는 의견이 있다면, 각 플랜의 차이와 추천 기준을 더 명확하게 보여줄 수 있다.

 

즉, 유저 인터뷰는 정량 데이터에서 발견한 문제를 더 깊이 이해하기 위한 방법이다. 데이터 분석과 유저 인터뷰를 함께 활용하면 문제의 위치와 원인을 더 정확하게 파악할 수 있다.

🔭프로세스 4 - 해결 방안 도출

원인을 탐구한 뒤에는 문제를 해결하기 위한 개선안을 도출한다. 해결 방안은 반드시 앞에서 발견한 문제와 원인에 연결되어야 한다. 단순히 '화면을 예쁘게 바꾸자', '단계를 줄이자'처럼 막연하게 접근하는 것이 아니라, 어떤 원인을 해결하기 위한 개선안인지 명확해야 한다.

 

예를 들어 온보딩 과정에서 사용자가 서비스의 가치를 충분히 이해하지 못하고 이탈한다면, 단순한 환영 인사 대신 서비스의 핵심 기능과 장점을 설명하는 안내 화면을 추가할 수 있다. 또 특정 단계가 너무 복잡해서 이탈이 발생한다면, 입력 항목을 줄이거나 단계를 간소화할 수 있다. 사용자가 어떤 선택을 해야 할지 몰라서 이탈한다면, 추천 옵션을 제공하거나 예시를 보여줄 수 있다. 특정 연령대에서 전환율이 낮다면, 해당 그룹이 이해하기 쉬운 문구와 화면 구조로 개선할 수 있다. 문제 원인과 해결 방안을 연결하면 다음과 같이 정리할 수 있다.

발견된 문제	추정 원인	해결 방안
환영 인사 단계에서 이탈이 많음	서비스 가치가 충분히 전달되지 않음	서비스 안내 화면 추가
운동 목표 설정 단계에서 이탈이 많음	선택지가 많고 기준이 모호함	추천 옵션 제공, 설명 문구 추가
플랜 설정 단계에서 이탈이 많음	플랜 차이를 이해하기 어려움	플랜별 혜택 비교표 추가
40대 이상 사용자 전환율 하락	화면이나 입력 과정이 복잡함	단계 간소화, 문구 명확화
모바일 사용자 이탈률 증가	모바일 화면에서 사용성이 낮음	버튼 위치, 입력 UI 개선

 

해결 방안을 도출할 때는 개선안의 목적도 함께 정리해야 한다. 예를 들어 '환영 인사 화면을 서비스 안내 화면으로 변경한다'는 개선안의 목적은 '사용자가 서비스의 가치를 더 빠르게 이해하게 하여 다음 단계 전환율을 높이는 것'이다. 이렇게 목적을 명확히 해야 이후 성과 평가 단계에서 어떤 지표를 봐야 하는지도 정할 수 있다.

🕹️프로세스 5 - 기능 구현

해결 방안이 정해지면 실제 기능을 구현한다. 기능 구현 단계에서는 기획한 개선안을 실제 프로덕트에 반영할 수 있는 형태로 만든다. 예를 들어 온보딩 화면을 수정하거나, 서비스 안내 문구를 추가하거나, 단계 수를 줄이거나, 버튼 위치를 바꾸거나, 입력 항목을 조정할 수 있다. 하지만 이 단계에서 중요한 것은 단순히 기능을 만드는 것만이 아니다. 이후 개선안의 성과를 측정할 수 있도록 로그 설계와 데이터 수집 방식도 함께 고려해야 한다. 예를 들어 온보딩 화면을 개선했다면 다음과 같은 로그를 수집할 수 있어야 한다.

로그	설명
온보딩 시작	사용자가 온보딩을 시작했는지 확인
각 단계 진입	사용자가 어떤 단계까지 도달했는지 확인
다음 버튼 클릭	단계별 전환 행동 확인
이탈 발생	어느 단계에서 이탈했는지 확인
회원가입 완료	최종 목표 행동 완료 여부 확인
플랜 선택	사용자가 어떤 플랜을 선택했는지 확인

 

로그가 제대로 설계되어 있지 않으면 개선안을 배포한 뒤 성과를 평가하기 어렵다. 예를 들어 사용자가 어느 단계에서 이탈했는지 로그가 없다면, 개선 후에도 어떤 단계가 좋아졌는지 확인할 수 없다. 따라서 기능 구현 단계에서는 '무엇을 만들 것인가'뿐만 아니라 '무엇을 측정할 것인가'도 함께 생각해야 한다.

📲프로세스 6 - 배포

기능 구현이 완료되면 사용자에게 개선안을 배포한다. 배포는 개선된 기능을 실제 사용자가 사용할 수 있도록 서비스에 반영하는 단계이다. 다만 모든 사용자에게 바로 배포하기보다는, 먼저 일부 사용자에게만 적용하거나 A/B 테스트를 통해 성과를 확인할 수 있다. 특히 프로덕트 개선안이 사용자 행동이나 매출에 큰 영향을 줄 수 있는 경우에는 전체 배포 전에 신중하게 검증하는 것이 좋다. 개선안이 반드시 좋은 결과를 낸다는 보장은 없기 때문이다. 오히려 기존보다 전환율이 낮아지거나, 사용자가 혼란을 느끼거나, 예상하지 못한 문제가 발생할 수도 있다. 따라서 배포 단계에서는 다음과 같은 방식을 고려할 수 있다.

배포 방식	설명
일부 사용자 대상 배포	전체 사용자가 아니라 일부 사용자에게만 먼저 적용
A/B 테스트	기존안과 개선안을 나누어 성과 비교
단계적 배포	일정 비율의 사용자에게 순차적으로 확대
전체 배포	검증이 끝난 개선안을 모든 사용자에게 적용

 

배포는 단순히 기능을 공개하는 단계가 아니라, 개선안이 실제 환경에서 잘 작동하는지 확인하기 위한 과정이기도 하다.

📜프로세스 7 - 개선안의 성과 평가

- A/B 테스트란?

개선안의 성과를 평가하기 위해 A/B 테스트를 진행할 수 있다. A/B 테스트란 기능을 전체 유저에게 배포하기 전에, 기존안을 A안, 개선안을 B안으로 설정하고 유저를 랜덤하게 배정하여 두 안의 차이를 비교하는 방식이다. 예를 들어 온보딩 환영 인사 화면을 개선한다고 가정할 수 있다.

구분	설명
A안	기존 환영 인사 화면
B안	서비스 안내가 추가된 개선 화면

 

이때 일부 사용자는 A안을 보고, 일부 사용자는 B안을 보게 된다. 그리고 두 그룹의 회원가입 전환율, 다음 단계 전환율, 이탈률 등을 비교한다. A/B 테스트에서 사용자를 랜덤하게 배정하는 이유는 두 안의 차이 외 다른 요인의 영향을 최소화하기 위해서이다. 만약 A안은 기존 사용자에게만 보여주고, B안은 신규 사용자에게만 보여준다면 두 그룹의 차이가 화면 때문인지 사용자 특성 때문인지 알기 어렵다. 따라서 A/B 테스트에서는 가능한 한 두 그룹이 비슷한 조건을 가지도록 무작위로 나누고, 두 안의 성과 차이를 비교한다.

- A/B 테스트에서 확인할 지표

A/B 테스트를 할 때는 어떤 지표를 기준으로 성과를 판단할지 미리 정해야 한다. 온보딩 개선안이라면 다음과 같은 지표를 볼 수 있다.

지표	확인 목적
다음 단계 전환율	사용자가 다음 온보딩 단계로 넘어가는지 확인
회원가입 전환율	최종적으로 회원가입까지 이어지는지 확인
단계별 이탈률	어느 단계에서 이탈이 줄었는지 확인
유료 전환율	회원가입 이후 유료 결제로 이어지는지 확인
온보딩 완료율	온보딩 전체 과정을 완료했는지 확인

 

개선안의 목적이 '서비스 가치를 더 잘 전달해 회원가입 전환율을 높이는 것'이라면, 핵심 지표는 회원가입 전환율이 될 수 있다. 만약 개선안의 목적이 '첫 화면에서 다음 단계로 넘어가는 사용자를 늘리는 것'이라면, 첫 단계의 다음 단계 전환율이 핵심 지표가 될 수 있다. 중요한 것은 실험을 시작한 뒤에 마음대로 지표를 바꾸는 것이 아니라, 실험 전에 핵심 지표를 정하고 그 기준으로 결과를 판단하는 것이다.

- A/B 테스트 결과에 따른 의사결정

A/B 테스트 결과에 따라 다음과 같은 의사결정을 할 수 있다.

1. 전체 유저 대상 배포
2. 기존안으로 롤백
3. 재실험

- 전체 유저 대상 배포

개선안인 B안이 기존안인 A안보다 더 좋은 성과를 보인다면, B안을 전체 유저에게 배포할 수 있다. 예를 들어 B안에서 회원가입 전환율이 더 높아졌다면, 개선안이 효과가 있다고 판단할 수 있다. 이 경우 기존 환영 인사 화면보다 서비스 안내가 추가된 화면이 사용자에게 더 도움이 되었을 가능성이 있다. 전체 유저 대상 배포는 개선안이 실제 지표 개선에 기여한다고 판단될 때 선택할 수 있는 방식이다.

- 기존안으로 롤백

개선안인 B안이 기존안보다 성과가 좋지 않다면 기존안으로 되돌릴 수 있다. 예를 들어 B안을 적용한 사용자 그룹에서 회원가입 전환율이 오히려 낮아졌다면, 개선안이 문제를 해결하지 못했거나 새로운 문제를 만들었을 가능성이 있다. 서비스 안내를 추가했지만 화면이 길어져 사용자가 더 부담을 느꼈을 수도 있고, 문구가 오히려 혼란을 주었을 수도 있다. 이 경우에는 개선안을 전체 배포하지 않고 기존안으로 롤백하는 것이 적절하다. 롤백은 실패가 아니라, 데이터를 통해 효과가 낮은 개선안을 걸러내는 과정이라고 볼 수 있다.

- 재실험

A안과 B안의 성과 차이가 명확하지 않거나 결과가 애매한 경우에는 재실험을 진행할 수 있다. 예를 들어 B안의 전환율이 조금 더 높아 보이지만 차이가 매우 작거나, 실험 기간이 짧아 충분한 데이터가 쌓이지 않았거나, 특정 사용자 그룹에서는 효과가 있었지만 전체적으로는 차이가 뚜렷하지 않을 수 있다. 이럴 때는 개선안을 다시 수정하거나, 실험 기간을 늘리거나, 다른 사용자 그룹을 대상으로 다시 테스트할 수 있다. 재실험이 필요한 경우는 다음과 같다.

상황	재실험 방향
결과 차이가 거의 없음	개선안의 차이를 더 명확하게 수정
데이터가 부족함	실험 기간 연장 또는 대상 확대
특정 그룹에서만 효과 있음	세그먼트별로 나누어 추가 분석
예상과 다른 결과 발생	원인 가설을 다시 세우고 실험 재설계

 

재실험은 더 정확한 의사결정을 하기 위한 과정이다. 한 번의 실험으로 모든 답을 얻기 어렵기 때문에, 실험 결과를 바탕으로 다시 가설을 세우고 개선 과정을 반복할 수 있다.

📃데이터 활용 프로세스 전체 흐름 정리

데이터 기반 프로덕트 개선 프로세스는 다음과 같은 흐름으로 정리할 수 있다.

단계	의미	예시
지표 기반 상태 진단	핵심 지표를 통해 현재 프로덕트 상태를 확인한다	회원가입 수, 전환율, 이탈률 모니터링
문제 발견	지표의 하락이나 이상 현상을 통해 문제를 찾는다	회원가입 전환율 감소 확인
데이터 기반 원인 탐구	문제의 원인을 데이터와 유저 인터뷰로 파악한다	퍼널 분석, 세그먼트 분석, 인터뷰 진행
해결 방안 도출	원인에 맞는 개선안을 만든다	서비스 안내 화면 추가, 단계 간소화
기능 구현	개선안을 실제 기능으로 만든다	온보딩 화면 수정, 로그 설계
배포	사용자에게 개선안을 적용한다	일부 사용자 대상 배포, A/B 테스트
개선안의 성과 평가	A/B 테스트 등을 통해 개선 효과를 확인한다	전체 배포, 롤백, 재실험 결정

 

이 과정은 한 번만 진행되는 것이 아니라 반복된다. 개선안을 배포하고 성과를 평가한 뒤, 다시 지표를 모니터링하고 새로운 문제를 발견하며 다음 개선으로 이어진다. 즉, 데이터 기반 프로덕트 개선은 다음과 같은 순환 구조를 가진다.

지표 확인 → 문제 발견 → 원인 분석 → 개선안 도출 → 구현 및 배포 → 성과 평가 → 다시 지표 확인

 

프로덕트는 한 번에 완성되는 것이 아니라, 데이터를 바탕으로 계속 개선되면서 성장한다.

👏마무리

마지막으로 이번 내용을 핵심 개념 중심으로 정리하면 다음과 같다.

개념	설명
프로덕트	고객의 문제 상황을 해결해줄 수 있는 서비스
프로덕트 데이터	프로덕트의 사용성과 성과를 분석하기 위해 수집된 데이터
프로덕트 데이터 분석	데이터를 기반으로 프로덕트를 개선하고 의사 결정하는 것
데이터 기반 의사결정	직관이나 경험보다 객관적인 데이터를 근거로 의사 결정하는 방식
지표	비즈니스와 프로덕트의 상태를 나타내는 정량적 수치
핵심 지표	기능의 성과와 비즈니스 목표를 판단하는 데 중요한 지표
문제 발견	지표의 변화나 이상 현상을 통해 개선이 필요한 지점을 찾는 과정
원인 탐구	가설을 세우고 데이터를 통해 문제의 원인을 찾는 과정
세그멘테이션	사용자를 그룹별로 나누어 지표를 비교하는 방법
퍼널 분석	사용자가 목표에 도달하기까지의 단계를 나누어 분석하는 방법
유저 인터뷰	정량 데이터만으로 알기 어려운 사용자의 생각과 이유를 파악하는 정성 조사
A/B 테스트	기존안과 개선안을 나누어 성과를 비교하는 실험 방법
롤백	개선안의 성과가 좋지 않을 때 기존안으로 되돌리는 것
재실험	결과가 명확하지 않을 때 실험 조건이나 개선안을 수정해 다시 실험하는 것

 

데이터 기반 프로덕트 개선 프로세스는 프로덕트의 상태를 지표로 진단하고, 문제의 원인을 데이터로 분석한 뒤, 개선안을 만들고 실험을 통해 효과를 검증하는 과정이다.