기묘한 유저 인터뷰 1/3 - 유저 인터뷰 망하는 방법

사용자 인터뷰가 오염될 수 있다는 사실을 모르면 시간과 돈만 쓰고 망한다.

우리가 사용자 인터뷰를 하는 이유가 뭘까요? 재미없는 이론을 이야기하기 보다는 잠깐 친구 이야기를 해볼께요.

여기까지가 내가 볼 수 있는 전부입니다. 이 신호들로 알 수 있는 건 무언가 잘못됐다는 사실뿐입니다. 나는 이유를 모릅니다. 대신 추측을 시작합니다.

추측은 계속 늘어나는데 확인할 방법이 없습니다. 그래서 날을 잡습니다. 만나자고. 직접 물어보려고. 이게 바로 사용자 인터뷰를 하는 이유입니다.

친구의 답장 속도는 우리가 보는 지표와 사용자 로그와 같습니다. 응답 시간, 이탈 지점, 재방문 주기, 어떤 화면에서 멈췄는지. 정보는 정확하지만 이유를 말해주지 않습니다. 이유를 모르는 상태에서 우리는 계속 추측합니다.

‘결제 단계가 복잡해서일 거야. 이 기능을 몰라서 안 쓰는 거야.’

‘회원가입을 강제로 시키니까 그렇지. 나 같아도 그러면 가입 안 하는데. 분명 그 이유일 거야.’

또는 반대로 아예 감을 못 잡을 수도 있습니다.

‘중간에 사용자가 복잡해할 것들을 모두 제거했는데 왜지?’

‘무료 체험에선 반응이 좋았고 유료 전환 시 혜택도 더 주는데 왜 구독을 안 하지?’

인터뷰는 그 추측들을 확인하고, 지우고, 새로 발견하는 자리입니다.

추측이 맞았다면 가설이 검증된 겁니다. 이제 짐작이 아니라 근거를 들고 움직일 수 있습니다. 틀렸다면 잘못된 방향으로 몇개월의 시간을 쓰는 일을 막은 겁니다. 그리고 둘 중 어느 것도 아닌, 내 목록에 아예 없던 이유가 나올 때가 있습니다. 이 경우가 가장 값집니다. 고칠 대상이 화면에서 정책으로, 기능에서 문제 정의로 바뀌기 때문입니다.

다만 사용자를 그냥 만나러 가는 것만으로는 부족합니다. 인터뷰는 세 군데에서 오염되기 때문에 만나도 별로 건질게 없을 수 있기 때문입니다. 하나씩 보겠습니다. 내가 던지는 질문에서, 사용자가 내놓는 답에서, 그리고 내가 하는 해석에서. 오염을 방지하기 위해선 세 가지를 모두 통과해야 합니다.

오염 가능성 01 : 내가 던지는 질문.

원칙 1 : 질문에 내 답을 심지 말아야 합니다

친구를 만나서 이렇게 묻는다고 해보겠습니다.

친구는 그렇다고 할 가능성이 높습니다. 진짜 이유가 아니어도요. 내가 답을 정해서 물었고, 친구는 그 자리를 어색하게 만들고 싶지 않고, 마침 그것도 조금은 서운했으니까요.

인터뷰도 똑같습니다. “결제 과정이 좀 복잡하셨죠?”라고 물으면 대부분 그렇다고 답합니다. 사용자는 예의 바르고, 인터뷰어가 원하는 답을 빠르게 읽어냅니다. 그렇게 받은 “네, 복잡했어요”는 검증이 아닙니다. 내가 심어놓은 답을 내가 회수한 것뿐입니다. 그러니 같은 걸 확인하더라도 이렇게 물어야 합니다.

가설을 검증하는 것은 인터뷰의 정당한 목적입니다. 문제는 방법입니다. 답을 확인하러 가는 것과 답을 유도하러 가는 것은 다릅니다. 가설은 질문에 넣는 게 아니라 답을 듣고 나서 대조하는 겁니다. 그러니 첫 번째 오염의 가능성을 제거하려면 질문에 내 답을 심지 않아야 합니다.

오염 가능성 2 : 사용자가 내놓는 답.

질문을 잘 던져도 답이 오염될 수 있습니다. 사용자가 거짓말을 해서가 아니라 자기도 진짜 이유를 모르기 때문입니다. 친구를 만나서 조심스럽게 물었다고 합시다.

둘 다 사실이 아닙니다. 그런데 거짓말도 아닙니다. 친구는 질문을 받은 그 순간에 설명을 만들어냅니다. 본인도 그게 진심이라고 믿습니다. 사람은 자기 행동의 진짜 이유에 잘 접근하지 못합니다. 대신 그럴듯한 이유를 즉석에서 지어냅니다. 사용자도 마찬가지입니다. “왜 안 쓰셨어요?”라고 물으면 “복잡해서요”라는 답이 나옵니다. 그 자리에서 만들어진 문장입니다. 그러면 어떻게 진짜에 가까워질까요? 이유를 캐묻는 대신, 상황을 물어야 합니다.

그러자 친구가 이렇게 답합니다.

그제서야 나는 눈치챕니다. 너는 나 만난다고 시간 쓰고 마음 썼는데 내가 당일날 갑자기 별 다른 설명 없이 약속 취소해서 서운했구나.

의견은 지어낼 수 있습니다. 기억은 지어낼 수 없습니다. 아래 표에 있는 왼쪽 질문은 사용자를 평론가로 만듭니다. 오른쪽 질문은 목격자로 만듭니다. 우리에게 필요한 건 그 상황을 목격한 목격자입니다. 사건이 일어난 상황을 물어야 합니다

오염 가능성 3 : 내가 하는 해석

원칙 3 : 마음에 드는 답이 아니라 진짜 문제에 집중해야 합니다

질문을 잘 던지고 사건까지 들었어도 마지막에 한 번 더 틀어집니다. 듣고 온 것을 내가 해석하는 단계입니다.

원칙 2에서 ‘상황 묻기’를 하지 않았다고 치고 ‘너 나한테 서운한거 있잖아. 빨리 말해’라고 다그친 상황이라고 해보겠습니다. 친구가 마침내 이유를 말했습니다.

“지난번에 단톡방에서 네가 내 말 자르고 넘어갔잖아.”

여기서 대화를 끝내면 결론은 하나입니다. ‘앞으로 친구의 말을 자르지 말자.’ 그런데 정말 그것뿐일까요? 상황을 더 물어보면 다른 게 나올 수 있습니다. 최근 몇 달간 모임에서 자기 얘기가 계속 지나쳐졌다든가, 그날 유독 기분 나쁜 일이 따로 있었다든가. 또는 그 전부터 나에게 서운한게 쌓여있었다든가.

친구가 말한 건 본인을 서운하게 한 많은 사건 중 가장 선명하게 기억나는 한 장면이지, 원인 전체가 아닙니다.

사용자 인터뷰도 같습니다. 특히 사용자가 해결책을 제안할 때 조심해야 합니다. “이런 기능이 있으면 좋겠어요”는 요구사항이 아니라 불편의 증거입니다. 우리가 만들어야 할 것은 그 기능이 아니라 그 사람이 그걸 떠올리게 만든 상황의 해결입니다.

그리고 이 단계에서 가장 많이 하는 실수가 있습니다. 내 가설과 맞아떨어진 발언만 골라내는 것입니다. 8명을 만나 7명이 다른 말을 해도 내 생각과 일치한 1명의 문장이 내 디자인의 근거가 되곤 합니다.

우리가 사용자 인터뷰로 도출해야 하는 결과는 ‘내 마음에 드는 답’이 아닌 ‘진짜 문제 발견’입니다. 그걸 하기 위해 어피니티 다이어그램과 같은 방법론을 이용하여 패턴을 발견하고 인사이트를 내는 것 입니다.

PART 2. AI로 인터뷰를 연습하는 이유

앞에서 인터뷰의 오염을 막기 위해 세 가지가 필요하다고 했습니다. 질문에 내 답을 심지 않아야 하고, 의견이 아니라 실제 사건을 물어야 하며, 마음에 드는 답이 아니라 진짜 문제를 찾아야 합니다.

그런데 말이죠. 처음 인터뷰하는 사람이 이 세 가지를 동시에 해낼 수 있을까요?

“당신은 할 수 있어요!”라고 말하고 싶지만, 처음부터 안정적으로 해내기 어려운게 현실입니다. 사용자 인터뷰는 준비한 질문을 순서대로 읽는 일이 아니기 때문입니다. 참여자의 말을 들으면서 의미를 이해하고, 더 파고들 지점을 판단하고, 적절한 후속 질문을 만들고, 동시에 대화의 흐름과 시간까지 관리해야 합니다. 이 모든 일이 실시간으로 일어납니다. 무슨 말인지 한 번 보겠습니다.

사용자 인터뷰, 이런 모습을 기대하시나요?

지금 어떤 상황을 상상하고 계신가요? 준비한 질문을 매끄럽게 던지고, 참여자가 술술 이야기를 풀어놓고, 중간중간 “아 그건 왜 그러셨어요?” 하고 자연스럽게 파고들고, 끝나고 나면 팀에 들고 갈 인사이트가 노트에 촤라라락 정리되어 있는 그림. 대충 이런 장면 아닐까요?

하지만 실제 내 생애 최초 인터뷰는 이와 상당히 다르게 흘러갈 수 있습니다.

사용자 인터뷰는 실제로는 이런 모습입니다.

사용자를 만나서 1번 질문을 던집니다.

참여자가 “음… 그냥 전반적으로 불편했어요. 버튼 누르는 것도.”라고 짧게 답합니다. 무엇을 더 물어야 할지 몰라 준비한 질문 2번으로 넘어갑니다.

두 번째 질문의 답은 애매하면서도 장황합니다. 정확히 무슨 뜻인지는 모르겠지만 일단 ‘대답을 들은 것 같은 느낌’이 들어 다음 질문으로 넘어갑니다.

질문 3번을 던졌더니 이번에는 엉뚱한 이야기가 시작됩니다. 대화는 그대로 삼천포로 빠집니다. 어떻게 본론으로 돌려야 할지 몰라 계속 맞장구를 치다 보니 시간이 의미 없이 흘러갑니다.

이대로는 안 되겠다 싶어 다음 질문으로 부자연스럽게 넘어갑니다. 그런데 참여자가 말합니다.

“그건 아까 대답했는데요?”

‘어…? 그랬나?’

당황한 채 다시 다음 질문으로 넘어갑니다. 그렇게 준비한 질문을 모두 읽고 나면 인터뷰가 끝납니다. 시간이 어떻게 흘렀는지조차 잘 기억나지 않습니다.

인터뷰 종료 후 인사이트를 정리하려고 기록한걸 확인합니다. 그러나 ‘뻔한 답변’과 ‘왜를 알 수 없는 답변’ 투성이입니다. 준비한 질문은 모두 했지만 의사결정에 사용할 수 있는 근거는 손에 남아 있지 않습니다.

준비한 질문을 다 하긴 했는데 손에 남은 게 없습니다.

이상한 일이 아닙니다. 내 생애 첫 인터뷰는 배우는 자리니까요.

인터뷰 스크립트를 만드는 것과 실제 인터뷰를 진행하는 것은 전혀 다른 일입니다. 스크립트는 무엇을 물을지 준비하게 해주지만 사용자가 예상하지 못한 답을 했을 때 무엇을 해야 하는지는 알려주지 않습니다.

실제 인터뷰에서는 네 가지 일을 동시에 해야 합니다.

초보 인터뷰어가 이 네 가지를 처음부터 능숙하게 처리하지 못하는 것은 당연합니다. 문제는 실제 사용자와의 인터뷰를 그 연습의 자리로 사용하고 있다는 것입니다.

실제 사용자 인터뷰는 연습용으로 쓰기에는 너무 비싼 자원입니다

사용자 인터뷰는 한 번 지나가면 되돌릴 수 없는 자원입니다. 참여자를 섭외하는 데 들어간 시간과 비용이 있습니다. 참여자가 따로 내어준 60분이 있습니다. 그 사람의 기억이 가장 생생한 시점에 질문할 수 있는 한 번뿐인 기회도 있습니다.

인터뷰가 끝난 뒤 중요한 질문을 놓쳤다는 사실을 깨달아도, 같은 조건으로 다시 돌아갈 수는 없습니다. 참여자를 다시 만난다고 해도 첫 번째 대화에서 형성된 관계와 학습 효과 때문에 완전히 같은 인터뷰를 반복할 수 없습니다.

그런데 많은 팀이 이 귀한 자원을 처음 인터뷰하는 사람의 실전 연습에 사용합니다.

날린 기회비용은 인터뷰어가 아니라 제품이 치릅니다

인터뷰를 제대로 하지 못했다고 해서 곧바로 문제가 드러나는 것은 아닙니다. 얕게 파고든 답, 질문에 의해 유도된 답, 앞뒤 맥락이 사라진 발언이 리서치 결과로 정리됩니다. 사용자가 직접 한 말이라는 이유로 강한 근거처럼 보이기도 합니다. 그리고 그 결과가 제품 의사결정에 사용됩니다.

버튼의 위치가 바뀌고, 새로운 기능이 추가되고, 정책이 수정됩니다. 인터뷰를 잘못했다는 사실은 아무도 모르는 채, 잘못된 해석을 바탕으로 만들어진 화면과 기능만 남습니다.

인터뷰어 개인에게는 한 번의 서툰 경험일 수 있습니다. 하지만 제품은 그 경험의 대가를 개발 비용, 운영 비용, 전환율 하락과 같은 형태로 지불합니다.

인터뷰 실력이 단순한 리서치 스킬이 아니라 비즈니스 리스크인 이유가 여기에 있습니다.

그러니 망쳐도 되는 인터뷰를 먼저 해야 합니다

이제는 순서를 바꿔야 합니다. 실제 사용자를 만나면서 인터뷰를 연습하는 것이 아니라, 먼저 망쳐도 되는 환경에서 충분히 연습한 뒤 실제 사용자를 만나야 합니다.

첫 질문이 막혀도 다시 시작할 수 있어야 합니다. 유도 질문을 던졌다면 그 자리에서 고쳐볼 수 있어야 합니다. 중요한 후속 질문을 놓쳤다면 같은 상황으로 돌아가 다시 시도할 수 있어야 합니다.

그러나 현실에서는 이런 연습 환경을 만들기가 쉽지 않습니다. 지인에게 매번 인터뷰 참여를 부탁할 수는 없습니다. 부탁한다고 해도 지인은 대체로 지나치게 협조적입니다. 질문의 의도를 알아서 이해하고, 길게 답해주고, 묻지 않은 이유까지 친절하게 설명합니다. (반대로 내 지인이 내가 만드는 제품의 직접 사용자가 아니라면 답변을 제대로 해주지 못할수도 있습니다.)

하지만 실제 사용자는 그렇지 않습니다. 짧게 답하기도 하고, 질문과 관계없는 이야기를 하기도 합니다. 앞에서 한 말과 뒤에서 한 말이 달라지기도 합니다. 자신의 행동을 정확히 기억하지 못하거나, 경험 대신 의견과 해결책만 말하기도 합니다.

그렇기에 인터뷰 스크립트를 혼자 백 번 읽는 것도 충분한 연습이 되지 않습니다. 인터뷰에서 어려운 것은 질문을 읽는 일이 아니라 예상 밖의 답을 받은 다음 무엇을 할지 결정하는 일이기 때문입니다.

AI는 ‘망쳐도 되는 인터뷰’를 만들어줍니다

실제 사용자를 만나기 전에 AI를 인터뷰 참여자로 앉혀 연습할 수 있는 가이드를 만들었습니다.

이 AI는 질문을 받을 때마다 친절하고 완벽하게 대답하지 않습니다. 짧고 모호하게 답하거나, 질문과 조금 어긋난 이야기를 하거나, 필요 이상으로 장황하게 말하기도 합니다. 자신의 행동은 기억하면서도 왜 그렇게 행동했는지는 명확하게 설명하지 못할 수도 있습니다.

일부러 그렇게 설계했습니다. 실제 인터뷰에서도 참여자가 언제나 질문의 의도를 정확히 이해하고, 자신의 경험을 논리적으로 정리해 설명해주는 것은 아니기 때문입니다.

연습자는 AI의 답변을 들으며 다음 행동을 선택해야 합니다.

짧은 답변에서는 더 파고들 지점을 찾아 후속 질문을 만듭니다. “그냥 불편했어요”와 같은 추상적인 답변은 구체적인 사건과 행동으로 되묻습니다. 대화가 옆길로 새면 참여자의 말을 끊지 않으면서도 원래의 주제로 돌아옵니다. 참여자가 의견이나 해결책을 말할 때는 그 생각이 떠오른 실제 상황을 다시 확인합니다.

이 과정에서 질문을 잘못 던져도 괜찮습니다. 후속 질문을 놓치거나 대화의 흐름을 잃더라도 다시 시작할 수 있습니다. 시간에 쫓길 필요도 없고, 같은 인터뷰를 몇 번이고 반복할 수도 있습니다. 그러니 여기에서는 실컷 망쳐도 됩니다. 오히려 망쳐야 합니다.

유도 질문도 던져보고, 예상하지 못한 답 앞에서 말문도 막혀보세요. 참여자의 말에 성급하게 결론을 내리거나, 중요한 후속 질문을 놓치는 경험도 해보세요. 중요한 것은 한 번에 완벽한 인터뷰를 하는 것이 아닙니다. 인터뷰가 끝난 뒤 대화를 되짚어보며 다음을 확인하는 것이 이 연습의 목적입니다. 연습에서는 마음껏 실패하고, 실제 사용자와의 인터뷰에서는 그 실패를 반복하지 않는 것. 그게 이 가이드의 존재 이유입니다.

⚠️ 주의할 점이 있습니다. AI와의 대화 결과를 실제 제품 개선에 써서는 안된다는 것입니다. AI는 실제 사용자를 대신하지 않습니다. AI가 만들어낸 답변을 사용자 인사이트나 리서치 근거로 사용해서도 안 됩니다. 지금 우리는 사용자를 만나기 전에 인터뷰어의 질문과 대응을 훈련하는 것임을 잊으면 안됩니다.