사용자 인터뷰 제대로 하는 법: 유도질문 없이 진짜 문제를 캐내는 질문 설계

1. 인터뷰 목표를 ‘아이디어 검증’에서 ‘행동 복원’으로 바꾸기

사용자 인터뷰를 시작할 때 가장 흔한 실수는 내 아이디어를 설명하고 반응을 묻는 것입니다. “이런 서비스가 있으면 쓰실 건가요?”라는 질문은 대체로 예의 바른 칭찬을 끌어냅니다. 하지만 칭찬은 사용 의사나 결제 의사와 다릅니다.

조코헌트에는 현재 프로덕트 250개가 출시되어 있고, 이를 만든 메이커는 194명입니다. 아이디어의 분야와 배경이 다양한 만큼 인터뷰에서도 “좋은 아이디어인가?”보다 “이 사람이 실제로 어떤 문제를 반복해서 해결하고 있는가?”를 확인하는 편이 유용합니다.

칭찬은 증거가 아니다

인터뷰의 목표를 다음처럼 바꿔 보세요.

• 나쁜 목표: 내 아이디어가 괜찮다는 확인
• 좋은 목표: 사용자가 최근에 겪은 문제와 해결 방식을 이해
• 더 좋은 목표: 그 문제가 반복되고, 비용이나 시간 손실을 만들며, 현재 해결책에도 불만이 있는지 확인

출시 후 반응도 비슷합니다. 조코헌트에서 출시 첫 24시간 안에 업보트나 댓글을 하나라도 받은 프로덕트는 61%지만, 댓글을 하나라도 받은 프로덕트는 35%입니다. 공개적인 반응과 구체적인 대화는 다를 수 있다는 뜻으로 읽을 수 있습니다. 인터뷰에서는 숫자 하나보다 문제를 설명하는 행동의 디테일을 얻어야 합니다.

질문 전에 정할 것

인터뷰 전에 검증하려는 가설을 한 문장으로 적으세요. 예를 들어 “프리랜서가 고객 요청을 정리하기 어려워한다”처럼 문제만 적습니다. 해결책, 기능, 화면은 잠시 빼 둡니다. 그래야 답변을 제품에 맞춰 해석하는 실수를 줄일 수 있습니다.

2. 좋은 질문과 나쁜 질문을 나란히 놓기

더 모브 테스트(The Mom Test)의 핵심은 상대가 나를 기쁘게 하려고 답하기 어렵게 만드는 것입니다. 미래의 의향보다 과거의 행동을 묻고, 일반적인 의견보다 구체적인 사건을 파고드세요.

가설을 숨긴 질문

“이 기능이 있으면 편리할까요?” 대신 “최근에 비슷한 일을 처리한 마지막 사례를 처음부터 설명해 주실 수 있나요?”라고 묻습니다. “이 문제에 돈을 낼 수 있나요?”보다는 “지금은 이 문제를 해결하기 위해 어떤 도구나 사람에게 비용을 쓰고 있나요?”가 낫습니다.

과거 행동에서 증거 찾기

답변이 추상적이면 “왜요?”를 반복하기보다 장면을 좁히는 후속 질문을 사용하세요. “그다음에는 무엇을 했나요?”, “어디에 기록했나요?”, “마지막으로 이 문제를 해결한 방법은 무엇이었나요?”처럼 묻습니다. 불편하다는 감정만 듣지 말고, 복사·붙여넣기, 엑셀 관리, 수작업 문의, 임시 메모 같은 현재의 우회 행동을 찾는 것이 핵심입니다.

3. 30분 인터뷰를 대화가 아닌 조사로 운영하기

친절한 대화만으로 끝나면 기억에 남는 말은 많지만 비교할 수 있는 자료는 적습니다. 질문 순서를 미리 정하고, 답변을 제품 설명으로 유도하지 않도록 진행 역할을 나눠 생각해 보세요. 혼자 진행한다면 메모와 질문을 번갈아 처리하지 말고 핵심 표현만 짧게 기록합니다.

오프닝: 경험 범위 맞추기

“정답은 없고, 제품을 소개하려는 시간이 아닙니다. 최근 실제 경험을 이해하고 싶습니다”라고 먼저 말합니다. 인터뷰 대상의 직무나 상황을 확인한 뒤, 문제를 겪은 최근 사건 하나를 골라 달라고 요청하세요.

본문: 사건 하나를 끝까지 복원하기

문제가 발생한 계기, 당시 목표, 사용한 도구, 막힌 지점, 임시 해결책, 결과를 순서대로 묻습니다. 중간에 “그 기능을 넣으면 해결될 것 같다”는 말을 꺼내지 마세요. 상대가 먼저 대안을 요청하거나 현재 해결책의 한계를 설명할 때까지 기다리는 편이 좋습니다.

마무리: 다음 행동을 확인하기

“제가 놓친 부분이 있나요?”로 끝내지 말고, “이 문제를 다시 겪으면 다음에는 어떻게 하실 것 같나요?”라고 묻습니다. 후속 대화를 요청할 수는 있지만, 인터뷰 중에 사전예약이나 사용 약속을 억지로 받아내지는 마세요.

4. 기록을 제품 결정으로 바꾸는 정리법

인터뷰 직후 녹취나 메모를 그대로 쌓아 두면 인상적인 문장만 기억에 남습니다. 답변을 세 칸으로 나눠 정리하면 해석과 사실을 분리하기 쉽습니다.

사실·해석·가설을 분리하기

• 사실: 지난주 고객 요청을 여러 문서에서 찾아 다시 정리했다.
• 해석: 요청 관리가 번거롭다.
• 가설: 요청을 한곳에 모으는 기능이 반복 사용될 수 있다.

첫 번째 줄은 들은 행동이고, 두 번째와 세 번째 줄은 내가 붙인 의미입니다. 여러 인터뷰에서 같은 행동이 반복되는지 확인하기 전까지는 가설을 사실처럼 다루지 마세요. 아이디어 검증의 전체 흐름은 코딩 전에 멈추는 30분: 잘못된 MVP를 피하는 아이디어 검증 체크리스트와 함께 보면 좋습니다.

기록을 기획으로 연결하기

반복되는 문제를 발견했다면 바로 기능 목록으로 늘리지 말고, 사용자·상황·문제·현재 대안·원하는 결과를 한 문장으로 정리하세요. 그다음에야 PRD(제품 요구사항 문서)란 무엇인가: 1인 개발자를 위한 가벼운 PRD 작성 가이드를 참고해 첫 실험 범위를 좁힐 수 있습니다.

5. 인터뷰 후 만들지 말지 결정하는 기준

인터뷰의 결론이 항상 “만들자”일 필요는 없습니다. 오히려 만들지 않을 근거를 얻는 것도 좋은 결과입니다.

진행 신호

비슷한 상황에서 같은 문제가 반복되고, 사용자가 이미 임시 해결책을 쓰고 있으며, 그 해결책에 시간이나 비용을 투입하고 있다면 다음 실험으로 넘어갈 만합니다. 이때도 전체 제품보다 한 가지 상황을 줄이는 작은 프로토타입부터 시작하세요.

보류 신호

문제가 막연한 불편에 머물고, 최근 사례가 나오지 않으며, 현재 해결책을 바꿀 이유도 없다면 인터뷰를 더 하거나 가설을 바꾸는 편이 낫습니다. 인터뷰는 내 아이디어를 설득하는 무대가 아니라, 사용자의 실제 생활이 내 가설과 어디에서 어긋나는지 확인하는 조사입니다. 그 차이를 정확히 기록할수록 다음 제품은 더 작고 선명해집니다.