PO
구루님, 요즘 제품에 뭔가 자신이 없어요. 문제는 분명히 있는 것 같은데, 어디서 잘못됐는지를 모르겠어요.
구루
팀 안에서만 이야기하면서 방향을 잡으려고 하다 보면 종종 그런 벽을 만나지. 그래서 제품팀이 자주 묻는 말이 있지. “이건 사용자도 그렇게 느낄까?”
PO
저도 그런 질문을 자주 하게 돼요. 그런데 사용자에게 물어보는 게 생각보다 어렵더라고요. 막연하달까…
구루
음, 그렇다면 질문을 바꿔보자. “사용자에게 무엇을 물을 것인가?”부터 시작해보면 어때?
PO
아… 막연하게 물을 게 아니라, 묻기 전에 정해야 할 게 있다는 뜻인가요?
구루
바로 그거야. 모든 사용자 피드백 수집에는 ‘가설’이 먼저 있어야 해. 단순히 ‘어떻게 생각하세요?’라고 묻는 건 거의 쓸모가 없어. ‘이런 문제가 있을 것이다’, ‘이런 기능은 잘 쓰이지 않을 것이다’처럼 너희 팀이 먼저 예측한 내용을 검증하는 게 목적이 되어야 해.
PO
그럼 가설부터 세우고, 그걸 검증하는 방식으로 인터뷰나 테스트를 구성해야 한다는 거네요?
구루
맞아. 인터뷰든, 설문이든, A/B 테스트든 가설이 없으면 방향이 없는 배와 같아. 자, 하나씩 살펴보자.
PO
사용자 인터뷰는 정성적 피드백을 수집하는 방법이죠?
구루
그렇지. 사용자의 감정, 맥락, 언어를 듣는 방법이지. 하지만 여기서도 가설이 선행되어야 해. 예를 들어, “온보딩 과정에서 이탈이 많다”는 데이터가 있다면, 가설은 “초기 기능 설명이 불친절해서 사용자가 포기한다”일 수 있어. 이걸 검증하기 위해 인터뷰를 설계하는 거야.
PO
그냥 “어떤 점이 불편하셨어요?”라고 묻는 것보다 훨씬 더 구체적이네요.
구루
맞아. 막연하게 물으면 막연한 답이 돌아오고, 그건 실무에 적용되지 않아. 가설 → 질문 설계 → 깊이 듣기, 이 흐름이 중요해.
PO
질문은 어떻게 짜야 할까요?
구루
개방형이 기본이야. 그리고 ‘왜’를 반복해서 묻다 보면 본질이 나와.
예를 들어, “이 단계에서 어려움을 느끼셨나요?” → “왜 그렇게 느끼셨나요?” → “그 상황에서 기대하신 건 뭐였나요?”
한 명 한 명을 깊게 파는 게 목적이니까, 경청은 필수야.
PO
인터뷰가 끝나면 어떻게 정리하죠?
구루
처음엔 말 그대로 받아들이고, 그다음엔 공통된 흐름을 정리해. 세 명만 인터뷰해도 반복되는 인사이트가 보일 수 있어. 처음엔 숫자보다 밀도에 집중해봐.
PO
그런데 소수의 깊은 이야기도 중요하지만, 전체적인 분위기를 알고 싶을 땐요?
구루
그럴 땐 설문조사지. 사용자 집단 전체의 정량적인 경향을 파악할 수 있지.
다만 여기서도 역시 가설이 필요해. 예를 들어, “알림 설정 기능이 어렵다”는 의견이 있었다면, 가설은 “전체 사용자의 30% 이상이 알림 설정을 불편해한다”처럼 세울 수 있지.
PO
그러면 그 가설을 검증할 수 있는 형태로 질문을 짜야겠네요?
구루
그렇지. 그럴 땐 객관식 질문이 핵심 지표가 되고, 주관식은 보완 역할을 해. 그리고 모든 질문은 가설 검증과 연결되어야 해.
“불편한 점을 적어주세요”는 너무 막연하지. “알림 설정 과정에서 어떤 단계가 가장 어렵다고 느끼셨나요?”처럼 맥락이 있어야 해.
PO
설문 응답을 많이 받기 어려운데, 어떻게 해야 할까요?
구루
몇 가지 방법이 있어.
제품 내에 자연스럽게 삽입하기 (예: 기능 사용 직후)
작은 보상을 제안하기
참여 동기를 명확히 설명하기 (“이 설문은 제품 개선에 직접 반영됩니다”)
무엇보다, 응답률보다 응답의 질과 설계가 더 중요해. 열 명이 정확히 답한 설문이 천 명의 대충 한 설문보다 훨씬 유의미할 수 있어.
PO
인터뷰로 이유를 듣고, 설문으로 전체 흐름을 보고… 그럼 이제 실제 행동을 보겠다는 게 A/B 테스트인가요?
구루
정확해. 인터뷰와 설문은 “왜 그랬는가”를 묻는다면, A/B 테스트는 “정말 그렇게 행동하는가”를 보는 방법이야.
PO
A/B 테스트에도 가설이 필요한가요?
구루
당연하지. 예를 들어, “버튼 문구를 바꾸면 클릭률이 올라간다”는 게 가설이야. 이걸 실험을 통해 증명하거나 반박하는 거지.
PO
그런데 한꺼번에 여러 걸 바꾸면 헷갈리던데요.
구루
그래서 핵심은 변수를 하나로 고정하는 것. UI도, 문구도, 기능도 동시에 바꾸면 어떤 변화가 효과를 낸 건지 알 수 없어.
또 충분한 데이터 수집 기간도 필요해. 트래픽이 적은 서비스라면 최소 며칠, 많게는 몇 주가 걸릴 수도 있어.
PO
테스트 결과는 어떻게 활용하죠?
구루
단순히 승자를 정하는 게 아니라, 왜 A가 B보다 나았는지에 대한 해석이 필요해. 그래야 그다음 가설로 이어질 수 있어. A/B 테스트는 단발성 이벤트가 아니라 지속적인 개선의 루프야.
PO
이 모든 걸 통해 피드백을 모았다고 해도, 결국 다 반영할 순 없잖아요?
구루
그래서 PO는 피드백을 의사결정 가능한 형태로 정리해야 해.
단순히 의견을 모으는 걸로 끝나면 안 되고,
문제의 빈도,
사용자에게 미치는 영향,
제품 목표와의 정합성 이 세 가지 기준으로 우선순위를 판단해야 해.
PO
결국 가설로 시작해서, 피드백으로 검증하고, 다시 다음 가설로 나아가는 거군요.
구루
그래. 제품 개선은 가설-검증-전환의 반복이야. 그 과정에서 사용자의 목소리를 가장 정확히 활용할 수 있는 사람이 PO고. 너는 지금 그 첫걸음을 잘 디뎠어.
PO
피드백이 무섭게 느껴졌는데, 이젠 그 안에서 방향을 찾을 수 있을 것 같아요.
구루
사용자에게 물어보는 건 약함이 아니라 실력의 표현이야. 기억해, 사용자 피드백은 답이 아니라 질문에 다시 질문을 더하는 도구라는 걸.