[서비스 기획 입문] 3 : 가설 수립 & 검증

**오늘 포스팅 목차**
-해결방안도출
-가설수립
-가설검증

 

1. 가설 수립부터 검증까지: 정답이 아닌 가능성에서 시작하기

우리가 드디어 3단계, 가설 수립과 검증의 과정에 대해 배우게 되었다.

앞서 우리는 총 3단계로 이루어진 목표 수립 → 문제 정의 단계를 배웠고,
이제는 그 과정을 통해 도출된 문제를 어떻게 ‘해결’할 것인가를 고민하는 시점에 도달했다.

 

그런데 여기서 중요한 사실 하나.
우리가 생각한 해결안이 정답일지는 아무도 모른다.
그 해결안은 어디까지나 **가설(Hypothesis)**이다.

 

그래서 PM은 해결안을 가설로 먼저 정의하고, 이 가설이 정말로 문제를 해결할 수 있는지를
검증 가능한 방법으로 계획한 후, 직접 실험하고 결과를 바탕으로 개선해나간다.

이 일련의 과정이 바로 가설 수립 → 검증 → 개선이라는 사이클이다.

 

그럼 왜 굳이 그렇게 해야할까?

"그냥 해결안 떠올랐으면 바로 실행하면 되는 거 아냐?"
라고 생각할 수 있다.

하지만 PM이라는 직무가 지향해야 할 본질은 다르다.
우리는 ‘잘 만든 제품’을 만드는 것이 아니라, ‘잘 작동하는 해결책’을 만드는 사람들이기 때문이다.

 

실제로 PM 채용 공고를 보면

“가설을 세우고 실험을 통해 검증합니다.”
“가설 기반 사고로 문제를 해결할 수 있는 분”
이라는 문장이 자주 등장한다.

 

포트폴리오 작성 시에도

“문제 해결을 위한 가설 수립 및 실험 과정을 포함해주세요.”
라는 요청이 많다.

 

이건 단순히 겉멋 든 표현이 아니다. PM이 일하는 방식 자체를 보여주는 실무 프레임워크다.

왜냐하면 결국 우리가 이 과정을 반복하는 이유는 단 하나.
프로젝트의 성공 확률을 높이기 위해서다.

 

우리는 그래서

- 애자일이라는 점진적인 개선 방식을 따르고,
- 데이터 기반 의사결정을 강조한다

 

모두 같은 이유다.

 

‘정답’이 아닌 ‘가설’을 바탕으로, 작은 실패를 빠르게 경험하고
그 안에서 더 나은 방향을 찾기 위해서.

 

그렇기에 이 성공확률을 높히는 실무 사례에 대해 이야기하고 포스팅을 시작하겠다.

예시_뱅크 샐러드
https://blog.banksalad.com/tech/birth-of-a-genuine-experiment-organization/

가설을 수립했으면 그 다음엔?
실험을 해야 한다.
이건 누구나 알고 있는 이야기처럼 보이지만,사실 실무에서는 이런 질문을 자주 마주하게 된다.

“이건 누가 봐도 답 뻔한데, 굳이 실험까지 해야 해?”
“시간 아깝지 않아?”
“어차피 예상 결과인데?”

하지만, PM이라면 반드시 이렇게 답해야 한다.
“그래도 해야 한다.”
뱅크샐러드에서는 이 질문에 이렇게 답한다.

“실험은 고객이 마주하는 변화의 임팩트를 가장 정확하게 측정하는 방법이다.”

즉, 우리가 제품이나 기능을 만들면서 세운 **가설이 실제로 맞는지를 가장 정확하게 확인할 수 있는 수단이
바로 ‘실험’**이라는 것이다.

여기서 말하는 실험은 흔히 말하는 A/B 테스트를 의미한다.
예상했던 결과와 실제 결과를 비교해보며“어떤 것이 더 효과적인가?”를 정량적으로 검증하는 방식이다.
가끔은 이렇게 생각할 수도 있다.

ㅣ“이건 당연히 B가 좋겠지. A는 너무 명확하게 별로야.”
ㅣ“굳이 이걸 또 실험으로 확인해야 하나?”

하지만 그럴수록 더더욱 실험은 필요하다.
왜냐하면 우리가 ‘당연히’라고 여겼던 가설이사용자에게는 전혀 다른 방식으로 받아들여질 수도 있기 때문이다.

실험이라는 단어를 **‘측정’ 또는 ‘검증’**으로 바꿔보면 더 명확해진다.
우리가 만든 제품을 사용자 앞에 내놓을 때,그들이 어떤 반응을 보이는지를 측정하고 검증하지 않는다면
우리는 다음 방향으로 나아갈 근거를 가질 수 없다.
PM의 역할은 방향성을 만드는 사람이지, 직감을 믿는 사람이 아니다.
실험은 방향성을 만들어주는 가장 중요한 나침반이다.

정리하자면,가설이 아무리 ‘당연히 맞을 것 같은’ 내용이라도,실험은 반드시 해야 한다.
실험을 통해서만 우리는 정확하게 고객 반응을 측정할 수 있고,그 반응을 바탕으로 진짜 방향성을 정의할 수 있다.

 

이 내용은 가설 수립과 검증에서
실험이 왜 꼭 필요한지에 대한 핵심 개념이었다.
다음 글에서는 가설을 어떻게 구조화해서 정리하고,
실험은 어떻게 설계해야 하는가로 이어가 보려 한다.

 

---

 

2. 본격적으로 가설 수립과정

-

2- 1. 해결방안 도출

 

우리가 지난 포스팅에서 핵심 문제 정의에 대한 이야기를 했던 걸 기억하는가?

앞서 말했듯 문제를 정의하는 이유는 올바른 방향으로 문제를 해결할 해결방안을 도출하고, 더 나아가 성공 여부를 판단하기 위함이다. 

물론! 이때의 해결방안은 아직 확정된 해결방안이 아니라 검증되지 않은 가설이라고 생각을 해야한다.

(앞의 포스팅인 가설 수립에서 해당 내용을 다루었다.)

 

해결방안을 도출했다고 해서 바로 실행에 들어가는 게 아니라,
**"정말 이게 효과적일까?"**를 먼저 의심해야 한다.

 

해결방안이 여러 개 도출되었다면,
그중에서도 가장 실행 가능성이 높은 아이디어부터 우선순위를 매겨야 한다.

이때 사용하는 것이 바로 임팩트 / 노력(Impact / Effort) 매트릭스다.

이 해결방안이-,
-얼마나 **높은 기대 효과(임팩트)**를 줄 수 있는지
-실제로 구현하는 데 얼마나 노력이 드는지 (리소스, 시간 등)

** 이 두 기준을 비교해서 현실적이면서도 가장 효율적인 선택지를 추려낼 수 있다.

 

문제 정의에서도 문제의 심각도와 우선순위를 기준으로 문제를 정리했다면,

해결방안 단계에서도 기대효과와 실행 가능성을 기준으로 우선순위를 정하는 것이 핵심이다.

 

지난번에 들어둔 간단한 예시

https://ljyljy0813.tistory.com/39

5whys 와 로직트리를 활용해서 문제를 정의 쉽게하기

 

따로 올린 포스팅 처럼

목표 수립-문제정의-원인 찾기-해결방안 가설을 도출하는 방법을 도출하는 방법을 이전에 보여줬는데

이 해결방법과 관련된 예시로 더 자세히 알아볼까한다.

---

예시_토스

https://toss.im/career/article/growth-domain

그로스 도메인이 토스를 성장시키는 방법

 

토스의 해당 케이스는 그로스 도메인에서 일한 PM분의 인터뷰이다. 이분은 토스의 유저수를 늘리는 일을 하신다. 이 PM분께서 맡으신 그로스 도메인에 과제가 떨어졌다고 한다. 

그 과제의 내용은 바로 : 
"토스의 월간 활성 사용자수를 늘려라"

이 과제를 처음 받으시곤, 이분이 가장 처음 느끼신 감정은 난감함 이었다고 한다. 
토스 앱은 MAU 1600만명이 넘는 제품이다. 토스는 이미 우리나라에서 사람들이 가장 많이 사용하는 앱 10위 안에 든다. 게다가 이미 mau가 굉장히 높고 이 정도로 규모가 큰데 이 상황에서 유저 그로스 (성장) 을 더 만들어내? 싶었다고.  
그러나 이분은 유저수를 늘리기 위한 방법을 고심하시다가, 해결방향성을 찾으셨고 그 방법이 바로
"문제를 잘게잘게 쪼개면, 가능하지 않을까?" 였다고 한다.

더 쪼개서 보고, 더 정확히 분석하자.

지난번에 내가 포스팅 했던 로직트리와 5 whys 사례처럼.
토스의 실무자였던 이 PM도 사용자 분석을 할 때도 ‘쪼개서 보기’ 프레임을 그대로 적용했다는 것이다. 토스의 월간 활성 사용자(MAU)는 약 1,600만 명.그런데 이 수치를 ‘전체’로만 바라보면 의미 있는 인사이트를 얻기가 어렵다. 그래서 이분은 이렇게 쪼개서 보기 시작했다.

-한 달에 1번 방문하는 사용자
-한 달에 30번 방문하는 사용자

이들 간의 방문 빈도 차이비율은 각각 어떻게 나뉘는지 이렇게 사용자를 분리해서 보니 자주 방문하는 사용자와 거의 방문하지 않는 사용자 사이에 명확한 행동 패턴과 차이점이 보이기 시작했다.
그리고 여기서 문제의 실마리를 찾아냈다. 더 쪼개서 보자라는 말은 지난번에 문제정의를 조금 더 쉽게 만드는 프레임 워크인 로직트리와 5why를 소개를 하면서 어떤 문제를 봐도 범위를 좁혀서 쪼개서 살피면 좋다고 말했는데. 이 pm 분 같은 경우에는 사용자 분석을 할때 사용자를 쪼개서 살펴보았다고 한다.

토스 앱이 성장하기 위해선 신규 유저를 유입하는 것도 중요하지만,
기존 유저의 앱 ‘관여도’를 높이는 것도 하나의 해법이라는 결론에 도달했다.

결국 이 PM은 기존 사용자에게 집중해 관여도를 높이는 방향으로 해결방안을 구체화시킨 셈이다.

이 방식은 우리가 매출을 올릴 때 기존 사용자 기반의 매출을 키울지, 아니면 신규 사용자를 유입시킬지를 나눠보던 접근과도 매우 닮아 있다. 그래서 문제를 정의할 때든, 해결방안을 도출할 때든, 이렇게 더 쪼개서 보는 태도는 생각보다 강력한 힘을 발휘한다. 범위를 좁히고 나눠서 살펴보는 것만으로도 전혀 보이지 않던 인사이트들이 드러나는 경우가 많기 때문에, 앞으로도 계속 이런 방식의 사고를 의식적으로 훈련해나가는 게 좋겠다.

-
그리고 여기서 다음 단계로 넘어가면 바로 가설 수립이다.
가설이란 사실 ‘예상되는 인과관계를 설명하는 하나의 문장’이라고 보면 되는데,

가장 기본적인 형태는
“만약 ~~하면 ~~할 것이다”
구조라고 보면 된다.

이 문장 속에는 우리가 문제를 해결하기 위해 어떤 변화를 줄 건지(변수)와, 그 변화가 어떤 영향을 줄 것인지(결과)를 함께 담아야 한다. 중요한 건 이 가설이 반드시 검증 가능해야 한다는 것이다. 정량적이든 정성적이든 실제로 실험이나 데이터를 통해서 확인할 수 있어야 하고, 그렇지 않다면 그건 더 이상 가설이 아니다.

예를 들어, “만약 무료 배송 옵션을 제공하면, 구매 전환률이 15% 증가할 것이다” 같은 가설은 변수와 결과가 명확하고 측정도 가능하다. 

 

또는 “배달의민족 앱에서 예상 배달시간을 실시간으로 표시하면 사용자 만족도가 증가할 것이다”는 가설도 좋은데, 이 경우 ‘사용자 만족도’라는 결과 지표를 어떻게 측정할 것인지까지 고려해야 완성된 가설이 된다. 

사용자 인터뷰를 통해 정성적으로 확인할 수도 있고, 예를 들어 만족도를 대체하는 지표로 주문 취소율의 감소를 설정할 수도 있다. 그래서 가설을 세울 때는 단순히 아이디어 차원이 아니라, ‘이걸 실제로 어떻게 검증할 것인지’까지 반드시 포함해서 생각하는 습관이 필요하다. 그래야 진짜 의미 있는 가설이 될 수 있다.

 

 

 

예시_오늘의 집

https://www.bucketplace.com/post/2021-05-27-첫-tv-광고의-성과-오늘의집은-어떻게-측정하고-분석했을까/

첫 TV 광고의 성과, 오늘의집은 어떻게 측정하고 분석했을까? - 오늘의집 블로그

오늘의집이 가수 소녀시대의 윤아를 모델로 첫 TV 광고를 진행했던 사례가 있다.
TV광고는 보통 마케팅 예산이 굉장히 많이 들어가는 채널인데, 이 캠페인에서 특히 인상적이었던 점은
**“TV광고의 성과를 어떻게 측정할 것인가?”**에 대한 고민이었다.

사실 온라인 광고라면 클릭 수, 전환율 등으로 어느 정도 정량적인 분석이 가능하지만, TV광고는 시청률을 확인한다고 해도 그걸 본 사람이 실제 구매나 행동으로 이어졌는지 확인하는 게 쉽지 않다.

그럼에도 불구하고 오늘의집은
‘어쨌든 액션을 했으니, 그것이 어떤 영향을 미쳤는지 확인하자’는 태도로 접근했고, 이는 굉장히 바람직한 가설 기반의 사고의 예시가 되었다.

먼저 이 팀은 (1)분석의 방향성을 먼저 잡았다.
TV광고는 개인별 추적이 불가능하다는 명확한 특성을 갖고 있기 때문에, 유저 단위 분석은 포기하고 대신 ‘증분 계산’을 활용한 방법을 선택했다.
**
증분이라는 개념이 다소 생소하게 느껴질 수 있지만, 쉽게 말하면
-TV 광고 이후 앱 설치 수, 유입량의 증가분을 확인하고,
-해당 증가치에 대응하는 비용이나 전환율 등의 지표를 계산해
실제 광고 성과를 판단하는 방식이다. 이때 핵심은 증분을 계산해서 어떤 방식으로 성과를 측정했는가보다, 측정하기 어려운 광고 채널에서도 성과를 ‘어떻게든’ 측정하려는 태도 자체가 중요하다는 점이다.
**

 

여기서 자연스럽게 이어지는 질문이 바로 “그렇다면 우리는 가설을 어떻게 검증할 수 있을까?”라는 것이다. 이 질문에 답하기 위해 가장 많이 쓰이는 대표적인 방식이 바로 A/B 테스트다. 

A/B 테스트는 두 가지 안(A안, B안)을 만들어 사용자 그룹을 나눈 뒤 각각에게 노출시키고,

우리가 설정한 주요 지표(예: 클릭률, 전환율 등)의 변화를 비교해서 어느 쪽이 더 성과가 좋은지를 확인하는 방식이다.

비교적 정량적인 방식이며, 명확한 지표 차이를 확인할 수 있는 장점이 있다. 다만, 실험 설계를 위해 개발이나 리소스가 더 필요하고, 어느 정도 사용자가 확보된 서비스에서 수행해야 유의미한 결과를 얻을 수 있다.

 

사용자 인터뷰는 정성적인 방식으로, 직접 사용자를 만나 대화하며 숨겨진 니즈나 새로운 인사이트를 발견하는 데 적합하다. 다만 인터뷰 대상자를 목적에 맞게 리크루팅해야 하고, 이 과정에서 많은 시간이 소요된다는 단점이 있다.

 

유저 테스트는 사용자가 실제로 제품을 사용하는 모습을 관찰하면서 문제를 발견하는 방식인데, UX/UI 관점의 개선 아이디어를 얻는 데 유용하지만 이 역시 사용자 모집이 필요하다.

 

마지막으로 오픈 후 결과 데이터를 분석하는 방법은 빠르고 비용이 적게 드는 장점이 있다. 앞선 테스트들을 진행하기 어려운 경우에는 기능을 우선 출시하고, 그 이후 수치 변화를 비교하는 방식으로 간단하게 검증할 수 있다. 단점은 정성적인 맥락이나 사용자의 세밀한 반응을 읽기 어렵다는 점이다.

 

요약하면, A/B 테스트는 두 버전 중 어떤 것이 더 효과적인지 판단할 때 유리하고,

사용자 인터뷰는 니즈 탐색이나 아이디어 검증에 적합하다.

유저 테스트는 실제 사용성 개선에 초점을 둘 때 좋고,

오픈 후 데이터 분석은 빠른 성과 확인에 유리하다.

 

상황마다 각 방법의 장단점을 고려해서 가장 적절한 방법을 선택하면 되고, 무엇보다 중요한 건 
“이 가설이 맞는지 아닌지를 반드시 검증하겠다는 태도” 자체다. 그것이 PM으로서 성공 확률을 높이는 첫 걸음이다.

 

---

 

예시_당근 

https://about.daangn.com/blog/archive/당근-프로덕트디자이너-채용-인터뷰/

하나의 가설로 극한의 성과를 | 당근 블로그

당근마켓의 프로덕트 디자이너 분께
"당근에서는 A/B 테스트나 여러 실험을 어떻게 활용하고 있나요?"라는 질문을 했을 때, 이 디자이너 분이 말하길 당근에서는 A/B 테스트를 거의 하루에 하나씩 진행할 정도로 다양한 가설을 빠르게 실험하고 있다고 하신 인터뷰이다.

실제로 UI 하나가 바뀔 때마다 시간 단위로 사용자 반응을 바로 확인할 수 있고, 그 실험 결과에 따라 즉시 개선할 수 있는 데이터 기반 환경이 잘 마련되어 있다고 한다.

개인적으로 이 이야기가 굉장히 인상 깊었던 이유는 A/B 테스트라는 게 생각보다 실행 환경이 까다로운 테스트 방식인데, 당근처럼 트래픽이 많은 서비스에서는 이 실험이 자연스럽게 가능하다는 점이었다. 특히 당근처럼 트래픽이 안정적으로 확보되어 있는 서비스에서는 A/B 테스트를 돌리는 데 큰 비용이 들지 않고도 사용자 반응을 빠르게 수집하고 분석할 수 있는 구조가 되어 있기 때문에 가설 검증에 A/B 테스트를 적극적으로 활용할 수 있다는 것이 장점이다.

결국 이 디자이너 분이 말한 핵심은, “우리는 기능을 바꿀 때 그냥 바꾸지 않는다. 작게라도 실험을 해본다. 그리고 그 결과를 보고 개선을 반복한다”는 태도였는데, 이게 바로 PM이든 디자이너든 실험 기반 사고가 정착된 조직의 방식이라는 생각이 들었다.
실험을 잘 하기 위해서는 데이터 인프라도 중요하고, 트래픽도 중요하지만 그보다 더 중요한 건 **“우리가 만드는 변화가 어떤 영향을 주는지를 직접 확인하려는 태도”**라는 걸 다시 한번 느끼게 해준 사례였다.

 

예시_당근

https://about.daangn.com/blog/archive/당근-중고차-직거래-실험문화-사용자경험-팀문화/

고민보다 실행하라, 성장 궤도를 달리는 중고차 직거래  | 당근 블로그

중고차 직거래 팀의 담당 팀원분의 사례다.
“중고차 팀은 제품 개발 속도가 엄청 빠르다고 들었는데 진짜 그런가요?”라고 질문을 했더니,
실제로 그렇다고 하면서 올해 초에 진행했던 ‘대리 출장 서비스’ 테스트가 좋은 예시라고 이야기해주셨다는 인터뷰.

그 테스트는 정말 말 그대로 기획부터 테스트 버전이 나오기까지 딱 3일이 걸렸다고 한다. 랜딩 페이지 작업까지 포함해서 3일 안에 끝낸 케이스였는데, 이 페이지를 통해 실제로 제품을 개발하지 않은 상태에서 먼저 ‘관심 있는 사용자 반응’을 확인한 거다. 가설은 있었지만, 바로 기능을 만들지 않고 최소한의 기능(MVP)만으로 먼저 실험을 해본 것이다. 구체적으로는 실제 대리 출장 서비스를 만들지 않은 상태에서, 이 서비스가 있다고 가정하고 서비스를 설명하는 랜딩 페이지를 만들었다.
-> 드롭 박스 사례와 비슷한 사례같다.

그리고 “이 서비스에 관심 있으시면 이메일을 남겨주세요” 같은 방식으로 유저 반응, 즉 전환율을 측정했다. 이건 사실상 제품 없이 제품을 실험한 거라고 볼 수 있다. 애자일에서 말하는 MVP, 최소 기능 제품의 개념을 정말 잘 활용한 사례라고 느꼈다.

실제 기능 없이도 수요나 반응을 검증할 수 있는 방법이 있다는 걸 보여준 셈이다. 이 방식은 당근뿐만 아니라 굉장히 많은 스타트업에서 활용하는 방법인데, 아직 제품이 완성되지 않은 상태에서 사용자의 니즈나 관심도를 미리 확인하기 위해 쓰인다. 빠르게 실험하고, 빠르게 개선하는 이 방식은 특히 초기 기획 단계에서 가설 검증의 효율을 극대화하는 데 정말 효과적이다. 이걸 보면서 ‘실험은 꼭 복잡하고 무거운 형태여야 하는 게 아니구나’라는 걸 다시 한번 느꼈다. 중요한 건 기능이 아니라, 

"그 기능을 진짜 필요로 하는 사람이 있는가"를 먼저 확인해보는 일이라는 걸 배웠다.

예시 3_드롭박스

https://ljyljy0813.tistory.com/manage/posts/

티스토리

스타트업에서 초기 제품을 검증하기 위해 활용하는 방식 중 가장 대표적인 사례는 드롭박스다.

드롭박스는 우리가 아는 것처럼 파일을 공유하고 저장하는 서비스인데, 실제로 이들이 처음 투자 유치를 받을 당시에는 제품이 완성되어 있지도 않았다.

드롭박스 팀은 먼저 제품을 만들기보다는,
사람들이 이 제품을 어떻게 사용할 수 있는지를 보여주는 영상 하나를 만들었다. 영상 안에는 드롭박스의 기능과 사용 방식이 실제처럼 시연되는 내용이 담겨 있었고, 이걸 통해
-사람들이 얼마나 흥미를 보이는지,
-얼마나 이 서비스에 니즈가 있는지
를 먼저 확인했다. 이 영상 하나만으로 드롭박스는 VC로부터 투자를 유치해냈고, 그 이후에 제품을 본격적으로 만들기 시작했다. 이건 결국 우리가 앞서 이야기한 ‘랜딩 페이지 방식의 MVP 실험’과도 굉장히 유사한 방식이다.

꼭 제품을 먼저 만들지 않아도, 제품의 가치와 기능을 사용자에게 설명하고, 반응을 측정할 수 있다면 그것만으로도 강력한 가설 검증이 가능하다는 걸 보여주는 사례다. 실제로 스타트업에서는 이런 식으로 영상이나 랜딩 페이지, 혹은 이메일 구독 신청 폼만으로도 사전 수요를 검증하고, 유저의 반응을 미리 체크해서 다음 의사결정에 반영하는 경우가 많다. 그래서 앞서 소개했던 A/B 테스트, 유저 테스트, 사용자 인터뷰, 오픈 후 데이터 분석 외에도 꼭 기억해둬야 할 건 **“가설을 검증하는 방식은 정해져 있지 않다”**는 점이다. 중요한 건 어떤 방식이든 "가장 효율적으로, 그리고 빠르게 우리가 세운 가설이 맞는지를 확인할 수 있느냐" 는 거다.

실험의 형태보다 더 중요한 건 실험을 하겠다는 사고방식 자체고, 그 실험을 통해 사용자의 실제 반응을 확인하고 그 결과를 다음 단계로 연결시킬 수 있는 구조를 갖추는 것이다.

 

예시_쿠팡디자인 

가설을 검증할떄 다양한 방법을 쓰는 게 왜 중요한가에 대한 예시

https://brunch.co.kr/@coupangdesign/53

관찰하는 정성 리서처 추적하는 정량 리서처

 

쿠팡 디자인팀의 리서치 실무자 분 인터뷰를 보면서 정말 공감됐던 이야기가 하나 있었다.

사용자 인터뷰는 정말 유용한 방법이지만, 인터뷰 답변만 그대로 믿는 건 위험할 수도 있다는 것이다. 실제로 어떤 고객들은 본인이 깊게 고민해보지 않은 상황에 대해 질문을 받으면 "모르겠다"라고 답하기보다는 “음… 아마 나라면 이렇게 했을 것 같아요”처럼 추측해서 답변을 해버리는 경향이 있다고 한다.

그런데 이렇게 추측성으로 나온 답변은 당연히 신뢰도가 낮고, 이걸 그대로 실험 설계나 제품 개선에 반영해버리면 잘못된 판단을 할 수도 있다. 그래서 쿠팡에서는 이런 정성적 리서치 결과가 정말 맞는지를 반드시 정량적 데이터로 교차 검증한다고 한다. 실제 고객이 그렇게 행동했는지, 로그 데이터나 전환 지표 등을 통해 행동 기반으로 확인하는 방식이다.

이걸 보면서 느낀 건, 우리가 가설을 검증할 때 절대 하나의 방식만 고집하면 안 된다는 점이다.

사용자 인터뷰든,
A/B 테스트든,
데이터 분석이든

각 방식은 장단점이 분명하기 때문에 가장 좋은 방법은 서로 다른 방식으로 교차 검증하면서 **“이 가설이 정말 맞는가?”**를 다각도로 확인하는 것이다. 그렇게 해야만 가설의 신뢰도와 리서치 정확도가 훨씬 높아지고, 그걸 기반으로 만든 제품도 실제로 사용자에게 더 의미 있게 다가갈 수 있다고 생각한다.

그래서 나는 앞으로 어떤 방식이든 하나의 수단에 집착하지 않고, 항상 “이걸 다른 방식으로도 확인할 수 있을까?”를 질문하며 실험 설계를 해야겠다고 마음먹었다.

 

 

 

예시_스파르타 PM공고

1) 문제 정의 – 진짜 원인을 찾기까지 쪼개서 묻기
공고에서는 ‘매출이 떨어졌다’라는 현상을 단순히 결과로 보는 것이 아니라, 그 이유가 무엇인지 끝까지 파고드는 방식을 보여준다. 예를 들어 "결제 전환율이 떨어졌다"는 현상에서 멈추지 않고,
"어떤 퍼널에서 떨어졌는가?", "결제한 사람들의 특성은 무엇인가?", "왜 지난 주에는 결제했을까?"라는 질문을 계속 던진다.

이 과정을 통해 "주요 결제자인 개발 초보자 대상의 혜택 프로모션이 종료되었기 때문에 전환율이 떨어졌다"는 인사이트에 도달한다.

→ 실제로 토스의 한 Growth PM은 "MAU를 더 늘려라"는 막연한 과제를 받았을 때도 비슷한 접근을 했다. 이미 MAU 1600만인 앱에서 더 늘리는 건 어려운 일이다. 그래서 그는 문제를 쪼개서 한 달 1회 방문자와 30회 방문자를 나눠보며 사용자 행동을 분석했고, 이탈율이 높은 그룹을 정리해 기존 유저의 관여도를 높이는 방향으로 전략을 전환했다. 이처럼 좋은 PM은 ‘쪼개서 보는 힘’이 강하다.

2) 가설 설정 – 정량 근거와 예측치를 갖춘 설계
좋은 가설은 단순히 "~하면 ~할 것이다" 형태의 문장을 넘어서야 한다.
공고에서는 "지원동기 예시 문구를 바꾸면 전환율이 늘어날 것이다"라는 단편적인 가설보다, "90% 이탈 유저가 직장인이었고, 직장인 맞춤형 예시가 이들의 불안을 줄일 수 있다면, 이 중 30%는 전환할 것이다"라는 정량적 가설을 제시한다. 그리고 A/B 테스트로 실험까지 계획한다.

→ 이건 실제로 당근마켓에서 하루에 하나씩 A/B 테스트를 돌릴 수 있는 환경을 갖추고, UI의 작은 변화부터 기능 단위 실험까지 데이터 기반으로 검증하는 방식과 유사하다. 트래픽이 있는 서비스에서는 가설을 정량적으로 검증할 수 있고, 그 과정에서 효과적인 가설은 빠르게 살아남고 비효율적인 가설은 폐기된다. 이처럼 Growth PM은 가설의 이유, 목표 수치, 검증 방법까지 같이 설계하는 사고가 필요하다.

3) 실험 설계 및 검증 – MVP든 데이터든 빠르게, 작게
공고에서는 디자인+개발 리소스를 들이지 않고, 노코드 툴이나 백오피스로 빠르게 MVP를 만들고 실험하는 방식을 예로 들고 있다. 이게 바로 실행력을 갖춘 PM의 역할이다. 하루 만에 랜딩 페이지를 만들고, 광고 효율·PV·CTA 클릭률·전환율을 추적하는 것까지 하나의 흐름으로 잡는다.

→ 이와 유사한 예시로는 중고차 직거래 팀에서 3일 만에 기획부터 랜딩 페이지까지 제작해 대리 출장 서비스를 테스트한 케이스가 있다. 실제로 서비스를 만들지 않고도, 사용자에게는 서비스가 있는 것처럼 보여주고 이메일 수집을 통해 수요를 테스트했다. 이것이 진짜 실험이고, 진짜 MVP다.
→ 드롭박스도 마찬가지다. 제품을 만들지 않고, 제품을 사용하는 영상만 제작해 VC로부터 투자를 유치했다. ‘실제로 돌아가는 제품’보다 사람들이 이 제품에 관심이 있는가를 검증하는 데에 실험이 초점이 맞춰져야 한다는 점에서 Growth PM의 사고방식을 잘 보여준다.

4) 실험 결과 분석 – 정량 지표는 목적과 연결되어야 한다
검증할 지표를 설정할 때도 주의할 점이 많다. 가설의 결과를 직접 설명할 수 있는 지표인지, 상위 OKR이나 비즈니스 목표와 연결되어 있는지, 그 지표가 오르거나 내릴 때 해석 가능한 배경이 있는지, 측정 기간은 명확히 정의되어 있는지 등을 모두 고려해야 한다. 이건 KPI를 설정할 때와도 유사하다.

→ 쿠팡 디자인팀의 인터뷰에서 이런 말이 있다. 사용자 인터뷰에서 나온 말만 믿을 수는 없다. 사람들이 잘 모르는 주제에 대해 추측성 발언을 하는 경우가 많기 때문이다. 그래서 반드시 행동 데이터로 교차 검증을 한다고 한다. 이처럼 정성+정량의 교차 검증은 실험의 정확도를 높이고, PM의 의사결정의 근거가 된다.

5) 실패한 실험은 낭비일까?
마지막으로 중요한 건, 실험이 꼭 성공하지 않아도 괜찮다는 태도다. 진짜 안타까운 건 실험을 했지만 아무 인사이트도 얻지 못한 경우다. 반대로 결과가 좋지 않아도, 거기서 얻은 인사이트로 가설을 수정하고 실험을 반복하면 결국 개선할 수 있다. Growth PM의 핵심은 성공률이 아니라 실험으로부터 배움을 계속 쌓는 것이다.

[요약]
이 공고는 단순한 ‘채용 요건’이 아니라, Growth Product Manager라는 직무가 어떤 사고방식으로 일하고, 어떤 문제를 다루고, 어떤 기준으로 판단하는지를 보여주는 실전 가이드에 가깝다. 문제를 분석하고, 가설을 세우고, 실험을 설계하고, 데이터로 검증하고, 실패해도 배운다. 이 사이클을 빠르고 치밀하게 반복할 수 있는 사람, 그게 바로 성장 중심 PM이라는 것을 공부하기 좋은 공고이다.

 

 

 

예시_배달의 민족 외식업광장

PM의 업무 사이클 전체 흐름

비전 정렬부터 목표 설정, MVP 실행, 지표 트래킹, 그리고 실패 시 피드백 루프

https://techblog.woowahan.com/12417/

PM이 사용자가 아닌 서비스는 어떻게 만들까? : 배민외식업광장 ‘장사캘린더’ 오픈부터 개선까

이 아티클의 앞부분에서는
비전과 프로덕트 목표를 어떻게 설정하고, 애자일하게 일하면서 어떤 방식으로 MVP의 범위를 좁혀가는지를 다룬다. 목표를 설정할 때는 단순히 하나의 지표를 찍는 것이 아니라, 어떤 사용자 문제를 해결할 것인지, 그 해결을 통해 어떤 행동 변화를 이끌어낼 것인지를 먼저 정의하고 나서, 그에 맞는 정량 목표를 세운다.

그리고 그 목표를 바탕으로 최소한의 기능(MVP)을 빠르게 정의하고 개발한다.

실제 사례에서는 기능을 오픈한 뒤 4주 동안의 지표를 살펴봤는데, 순 방문자 수는 목표를 초과 달성한 반면, 사용자당 세션 수는 목표에 미달했다. 즉, 방문은 많았지만 재방문하거나 서비스를 더 깊이 사용하는 사용자는 예상보다 적었던 것이다. 이때 중요한 포인트는, 하나의 목표 지표가 달성되지 않았다고 해서 실험이 실패했다고 단정 짓지 않는다는 점이다. 오히려 이 결과를 통해 초기 가설이 어느 정도 증명되었지만, 사용자 관여도를 높이기 위한 추가 개선이 필요하다는 인사이트를 얻는다.

그래서 바로 다음 단계로 사용자 인터뷰를 계획했고, 실제로 장사캘린더를 사용할 가능성이 높은 외식업 사장님들을 대상으로 정성적 리서치를 진행했다. 그 과정에서 유저들의 니즈와 불편을 더 구체적으로 파악하고, 그 인사이트를 기반으로 서비스를 점차적으로 개편해 나가면서 지표를 점진적으로 끌어올리는 개선 활동을 진행했다.

결국 이 사례에서 보여주는 핵심은, 서비스가 처음부터 엄청난 성공을 하거나 모든 목표를 100% 달성할 필요는 없다는 것이다. 오히려 중요한 건, 지표가 기대에 못 미쳤을 때 그 원인을 분석하고, 새로운 인사이트를 도출해서, 다음 실험과 개선으로 연결시키는 피드백 루프를 운영할 수 있는가다.

PM의 일은 단발적인 성과보다, 이런 사이클을 꾸준히 반복해서 제품을 더 나아지게 만드는 데에 있다는 걸 다시 한번 느끼게 해주는 사례였다.

 

두번째 사례_토스

리서치 기반 인사이트 도출 사례

가설 수립 → 사용자 인터뷰 → 가설 반례 발견 → 인사이트 도출 → 핵심 과제 재정의

https://blog.toss.im/article/user-research-team-interview

UX 리서처 인터뷰 - 토스가 '사용자 경험' 에 '집착'하는 방법은? - 금융이 알고 싶을 때, 토스피드

토스 UX 리서처의 인터뷰 프로젝트 중 하나에서는
"토스라는 브랜드가 사용자들에게 어떤 인상을 주고 있을까?"라는 질문을 중심으로 진행된 케이스가 있었다.

리서처는 프로젝트 초반에 “토스는 혁신적인 브랜드이고, 그래서 사용자들이 좋아할 것이다”라는 가설을 세우고 조사를 시작했다. 하지만 실제 인터뷰를 통해 사용자들의 반응을 들어보니, 전혀 다른 이야기가 나왔다.

사람들은 토스가 분명히 편리하고 잘 만든 서비스이기 때문에 자주 사용하고 있긴 하지만, 동시에 “아직까지 완전히 신뢰할 수 있는 브랜드는 아니다”라고 말했다고 한다. 즉, '혁신'이라는 이미지와 '신뢰'라는 감정 사이에 간극이 있었던 것이다.

이 리서치를 통해 리서처는 우리가 세운 가설이 언제나 맞는 것은 아니며, 정성적인 사용자 인터뷰를 통해 예상치 못한 반례가 드러날 수 있다는 사실을 다시금 체감했다고 한다. 그리고 바로 그 간극이 토스 브랜드 경험을 개선하기 위한 핵심 과제로 설정되었고, 이후의 전략 방향성에도 영향을 주었다.

이처럼 PM이든 UX 리서처든 가장 중요한 건 "내가 맞을 것이다"라는 전제를 의심하고, 사용자로부터 진짜 이야기를 듣는 태도다. 그리고 그 반례에서 진짜 중요한 인사이트가 도출되기도 한다는 걸 이 사례는 잘 보여준다.

 

 

 

예시_오늘의집

교과서적인 PM & UX 리서치 플로우 예시

: 프로모션 이후 특정 지표 하락 → 부정적 시그널 감지 → 사용자 테스트 → 가설 검증과 인사이트 도출 → 넥스트 스텝 설정

https://www.bucketplace.com/post/2023-11-29-bx-디자인-팀은-고객의-목소리를-어떻게-들을까/

BX 디자인팀은 고객의 목소리를 어떻게 들을까? - 오늘의집 블로그

오늘의집에서 진행한 ‘오시즌 위크’라는 프로모션은 한 번쯤 눈에 띄었을 법한 대형 캠페인인데,
실제로 이 프로모션을 론칭한 후 특정 지표가 오히려 하락하는 현상이 발생했다고 한다.

이 부정적인 시그널의 이유를 정확히 파악하기 위해 팀은 곧바로 UT(유저 테스트)를 기획했고,
이 테스트에서 두 가지 질문을 중심에 뒀다.

첫 번째는
“이 프로모션 페이지의 퍼포먼스를 어떻게 하면 더 개선할 수 있을까?”라는 비즈니스적 가치의 질문이었고,

두 번째는
“우리는 어떻게 하면 더 효율적이고 긍정적인 오시즌 위크 경험을 사용자에게 제공할 수 있을까?”
라는 사용자 가치 중심의 질문이었다. 이 두 질문을 바탕으로 유저테스트를 진행했고, 유저의 행동을 직접 관찰하며 클릭 히트맵 같은 정량 지표도 함께 분석했다.

(유저테스트) 사용자가 페이지 내에서 실제로 어떤 부분을 많이 클릭했는지를 보며, "왜 여기서 이탈했을까?", "어떤 영역이 주목받지 못했을까?"에 대한 가설을 세웠다.

그런데 이 과정에서 처음 세운 가설이 틀린 경우도 있었고, 일부만 맞는 경우도 있었다. 그런데 오늘의집 팀에서는 이걸 ‘틀렸다’는 관점으로 보지 않고, 오히려 ‘이 가설을 통해 인사이트를 하나 더 얻었다’는 시선으로 해석했다. 결국 중요한 건 가설이 맞았냐 틀렸냐가 아니라, 그 가설을 통해 다음 실험을 어떻게 더 낫게 가져갈 수 있느냐 는 점이었다.

사용자 가치와 비즈니스 가치를 동시에 생각하면서 넥스트 스텝을 설정해 나가는 이 접근은, 실무자에게 정말 중요한 태도라는 걸 다시 한번 느끼게 해주는 사례였다.