UX 현직자 인터뷰 ep.7 쏘카 PM 전이준님(1/2)

이번 유터뷰는 쏘카의 전이준 PM님께서 자리를 빛내주셨습니다 :) 

쏘카는 로그 분석과 A/B 테스트를 중심으로 문제를 정의하고 실험으로 개선하는 데이터 기반 제품 조직입니다. 이런 환경 속에서 쏘카플랜팀을 이끄는 이준님은 사용자 문제를 정의하고 해결해온 과정을 PM의 시선에서 들려주셨어요.

쏘카 팀에는 아직 전담 UX리서처가 없지만, 이준님은 PM의 역할 안에서 직접 유저리서치를 설계하고 실행하며 “왜 이 서비스를 쓰는가?”, “진짜 문제는 무엇인가?”라는 질문에 다가가고자 하셨는데요,
UT, FGD, 설문조사 등 다양한 방법을 활용해 현업에서 리서치를 어떻게 시도했는지, 어떤 고민과 시행착오를 겪었는지 알 수 있었습니다. 

실험 중심 조직에서 리서치가 어떻게 보완적으로 작동하는지, 그리고 PM이 직접 리서치를 수행할 때 무엇을 고민하게 되는지 이야기를 통해 함께 살펴보시죠!

Q. 요즘처럼 A/B 테스트, 로그 분석이 잘 되는 환경에서도, UX 리서치가 꼭 필요하다고 느낄 때가 있나요? 쏘카플랜팀처럼 실험과 로그 기반 의사결정이 활발한 환경에서, UX 리서치는 어떤 방식으로 보완 역할을 하나요?

쏘카에는 따로 ‘UX리서처’ 직무는 없어요.

대신, 프로덕트 기획을 위해 캐주얼 UT는 주로 프로덕트 디자이너분들이 내부 인원을 대상으로 진행하고, “이 상황에서는 왜 그렇게 쓰신거예요?”, “어떤 생각을 토대로 그 버튼을 누르신 거예요?” 하는 식으로 의견을 구하고는 해요.

근데 PM 입장에서 정말 궁금한 건, 조금 더 본질적인 질문들이에요.
예를 들면, 우리 서비스는 왜 필요한가? 우리가 생각하는 가망 고객들은 왜 이 서비스를 쓰고 있을까? 어떤 상황에서 어떤 필요 때문에 이걸 쓰게 될까? 이런 질문들이 항상 머릿속에 있어요.

그래서 이런 근본적인 궁금증을 해결할 때는 UX 리서치가 필요하다고 생각해요.

예를 들면 현재 담당하고 있는 건 쏘카플랜이라는 장기 렌트 서비스인데요, UX 리서치를 하면서 장기 렌트 이용 경험이 있는 사람들에게 직접 물어볼 수 있었어요.
“왜 장기로 차량을 빌리시나요?”, “어떤 점에서 만족을 느끼셨어요?”, “이용하면서 어떤 점이 불편했나요?” 같은 질문들을 던질 수 있었고, 그 과정에서 우리가 놓치고 있던 사용자들의 맥락을 많이 알게 됐죠.

Q. 그렇다면 그러한 질문들을 사용자에게 하기 위해서, 실제로 어떤 과정을 거쳐 리서치를 진행하셨나요?

전에 유저스푼을 통해서 FGD(Focus Group Discussion)를 진행한 적이 있었어요.
그때 직접 사용자들에게 우리가 가지고 있던 질문들을 던져보고, 그 자리에서 바로 피드백을 받을 수 있었죠.
사용자들이 실제로 어떤 생각을 갖고 있는지, 어떤 맥락에서 서비스를 사용하는지를 생생하게 들을 수 있어서 도움이 많이 됐습니다.

그리고 반대로, 아예 유저 수가 거의 없는 초기 상황에서는*내부 UT(사용성 테스트)*가 최선이라고 생각해요. 저는 개인적으로 UT를 검증보다는 가설 수립에 더 자주 활용하는 편이에요.

사용자 행동을 관찰하면서 “아, 이 서비스에서 이런 기능이 있으면 더 좋겠구나”, “이런 흐름이면 도움이 되겠구나” 하는 식의 아이디어가 떠오르거든요.
그래서 아이디에이션 단계에서 자주 UT를 활용하게 되는 것 같아요.

Q. 아하, 그렇다면 UT를 주로 가설 검증보다는 수립을 위한 아이디에이션 단계에서 사용을 하시는거죠?

네, 맞아요. 사실 이게 정석적인 접근인지 정확히는 모르겠지만요(웃음).

다만 제가 항상 경계하는 게 하나 있어요. 바로 ‘원오버(One-over)’에 빠지지 말자는 거예요.
쏘카는 사용자 수가 정말 많다 보니까, 어떤 한 사람의 피드백이나 행동을 가지고
“이게 좋다더라” 혹은 “이건 문제다”라고 판단하기가 굉장히 어려워요. 사용자 한 명의 이야기를 너무 크게 받아들이면 전체 판단이 왜곡될 수도 있으니까요.

그래서 저희는 작은 규모의 관찰이나 테스트는 가설 수립의 출발점으로만 보고, 정말 유의미한지 여부는 데이터 기반으로 정량 검증하려고 해요.

예를 들어, 어떤 행동을 관찰하고 나서 “이거 효과가 있을지도 모르겠네?”라는 가설이 생기면 그 다음에는 실제 로그 데이터를 확인하거나 A/B 테스트로 수치화를 시도해요. 결과적으로 검증은 정량 데이터가 담당하는 구조라고 보시면 될 것 같아요. 

Q. 정리해보면 테스트, 로그 분석은 ‘검증’을 위해 사용하고, 그 다음에 이걸 실제 고객에게 물어보는 UT와 같은 UX 리서치 과정은 오히려 아이디에이션을 위한 가설 수립/설정 단계게 더 적합한거네요.

맞아요. 가설 수립 단계에서 많이 써요. 아이디에이션으로요.

모더레이터: 현재 쏘카에는 UX리서처가 없는 걸로 알고 있는데, 그런 상황에서 UX 리서치를 직접 진행하시기가 어렵진 않으세요?

그래서 DA 툴에 많이 의존하고 있어요. 예를 들면 앰플리튜드에서는 세션 리플레이 같은 기능을 자주 보면서 특정 화면에서 사용자가 어떻게 행동하는지를 녹화해서 관찰하기도 해요. 이런 툴들을 통해 직접 유저 리서치를 수행하지 못하는 부분을 어느 정도 대체하는 거죠. 사용자가 실제로 어떻게 서비스를 사용하고 있는지를 간접적으로나마 볼 수 있으니까요.

Q. UX 리서처라는 직무가 있는 팀이 있고, 없는 팀이 있어요. 쏘카는 사용자 경험에 신경을 많이 쓰는 팀이고, 쏘카 이외에도 UX에 신경쓰시는 많은 기업에서 아직 정식으로 UX리서치 팀을 상설하지는 않잖아요. 이준님이 생각하시기에 쏘카에 UX리서처라는 직무가 따로 없는 이유는 뭐라고 보시나요?

음... 이건 제가 단정적으로 말씀드릴 수 있는 부분은 아닌 것 같고요.
개인적인 의견을 말씀드리자면, 두 가지 이유가 있는 것 같아요.

하나는, 조직에서 유저 리서치의 활용도가 떨어지는 경우고요.
다른 하나는, “우리 조직에 유저 리서치가 필요해!”라고 명확하게 이야기한 사람이 없었던 경우예요.

유저 리서치의 활용도와 필요성을 주장하는 것도, 그리고 실제 리서치를 통해 어떤 결과가 나왔고
그게 비즈니스에 어떤 임팩트를 줬는지까지 설명하는 일 자체가 어려운 일이잖아요.
“리서치 했더니 매출이 얼마 늘었어요”처럼 정량적인 연결고리를 만드는 게 쉽지 않으니까요.

 결국 양쪽 다 어려운 상황인 것 같아요.
유저 리서치가 필요 없다고 단정하기도 어렵고,  그렇다고 리서치의 명확한 ROI(투자 대비 성과)를 설명하기도 어렵고요.

그래서 UX리서처라는 직무가 쉽게 만들어지거나 자리잡기 힘든 게 아닐까 생각해요.

Q. 그렇다면 지금까지의 커리어에서 UX 리서치 결과를 보면서 “이거 좀 괜찮은데?”라고 느꼈던 케이스가 있으신가요? 

네, 있어요. 아마 이전 회사에서 더 자주 그런 경험을 했던 것 같아요. 그땐 한우 도매 서비스를 운영했었는데요, 유저 수가 굉장히 적었어요.

근데 거꾸로 생각하면, 그런 환경이 오히려 리서치에는 더 유리한 조건이었어요.
우리가 직접 만난 고객 한 명, 한 명의 목소리가 제품에 미치는 영향력이 훨씬 컸거든요.

그래서 정육점 사장님이나 고깃집 사장님들을 직접 찾아가 인터뷰했어요.
현장에서 실제 서비스 이용 장면을 보고, 어떤 니즈가 있는지를 직접 듣고,
그걸 바로 제품에 반영했더니 변화가 눈에 보였어요.

예를 들어, CS 수가 실제로 줄었고, 서비스 사용 빈도도 확실히 증가했어요.
그래서 “아, 이런 환경에서는 리서치가 진짜 강력하게 작동할 수 있구나”를 실감했죠.

Q. 혹시 쏘카에서 하셨던 리서치 중에도 기억에 남는 사례가 있을까요?

기억이 가물가물하긴 한데요 (웃음).
유저스푼으로 처음 FGD를 진행했을 때였어요.

그때 한 동료가 FGD 직후에 “즉시 수요가 정말 중요한가?”라는 이야기를 꺼냈거든요. 실제로 패널 분들이 “지금 당장 탈 수 있는 차가 필요하다”고 말했던 게 인상적이었는데, 그 피드백을 기반으로 실제 로그 데이터를 더 깊게 들여다보게 됐어요. 그리고 정말 그런 행동 패턴이 보이더라고요.

또, 같은 인터뷰에서 누군가 “차종을 더 보여줄 수 없느냐”고 질문하셨던 것도 기억나요. 그 의견 하나만으론 근거가 부족하다고 느꼈는데, 이후 데이터를 보니까 차종 선택 영역의 클릭 빈도가 매우 높다는 걸 발견했어요.
그걸 계기로 “이건 진짜 개선 포인트다”라는 논의를 시작하게 됐고, 이후 여러 아젠다로 이어졌던 기억이 납니다.

Q. 실제로 FGD의 결과가 제품 방향성에 영향을 미쳤나요? 

네, 있었어요.
예를 들어 “쉽다”는 게 사용자에게 어떤 의미인지 FGD를 통해 고민해볼 수 있었어요.‘쉽게 쓴다’는 게 중요하다는 건 누구나 알지만,
도대체 그 ‘쉽다’는 게 각 사용자군에게는 구체적으로 어떤 의미일까? 이걸 정의하게 된 거죠.

• 차량 렌트에 관심이 많은 사용자에게 ‘쉽다’는 건 차종을 다양하게 볼 수 있는 것이었고,

• 관심이 적은 사용자에게는 요금 확인이나 결제가 빠르게 되는 것이었어요.

이런 식으로 ‘쉽다’의 정의를 사용자별로 다르게 정리하게 됐던 건 정말 흥미로웠어요.

Q. 쏘카에서는 유저 리서치를 인사이트를 검증하기보다는, 새로운 인사이트를 도출하기 위한 도구로 많이 사용하시는 것 같아요.

네, 맞아요. 인사이트 도출을 위한 수단으로 활용하는 경우가 많아요.
근데 이걸 반대로 이야기하면, 하나의 리서치를 실제로 실행하기까지 시간이 꽤 오래 걸리기도 해요.

“정말 이 인사이트를 찾아내야 할까?”,
“리서치를 지금 해야 할 이유가 충분한가?”를 먼저 검토하게 되는 거죠.

왜냐하면 리서치를 통해 나온 인사이트가 제품 개발이나 프로세스에 반영될 경우,
그만큼 리소스와 비용이 들어가는 일이잖아요.
그래서 그걸 감안하면, 리서치를 결정하기까지도 일종의 내부 의사결정 과정이 필요한 거죠.

Q. 그렇다면 반대로, 리서치 결과가 다소 아쉽거나 애매하게 느껴졌던 경험도 있으실까요?

사실 제가 리서치 경험이 아주 많은 편은 아니라서 이런 질문은 좀 어렵기도 한데요ㅎㅎ
그래도 기억에 남는 사례가 하나 있어요.

처음에 쏘카 플랜 관련해서 서베이를 했는데, “가격이 싸면 좋겠어요”, “잠깐 타는 거예요” 같은 답변들이 있었는데,
이런 이야기를 봤을 때 “그래서 우리가 어떤 액션을 취해야 하지?”라는 생각이 들더라고요.

물론 다 맞는 말이긴 한데,
그걸 바로 액션 플랜으로 연결하기가 어렵고,
리서치 결과가 기존에 우리가 알고 있던 지식 베이스랑 크게 다르지 않은 경우엔
오히려 “그 다음엔 뭘 해야 하지?”라는 고민이 생겼던 것 같아요.

실제로 그렇게 도출된 인사이트를 가지고 뭔가 시도해도
이 결과를 해석할 때 좀 당황했던 적이 있어요.
예를 들면, 사용자 응답 중에 “기대한 만큼의 차별점이나 결과가 안 나오기도 하고요.
그래서 리서치를 할 때는, “무엇을 알고 싶은지”가 정말 선명해야 한다는 걸 많이 느꼈어요.

Q. 사실 가격 관련 피드백은 제대로 된 수요 조사 설계가 아니면 해석이 정말 어렵죠. 오히려 그런 답변이 안 나오게 질문을 설계하는 게 중요하잖아요. 그런데 실무에서는 리서치 설계에 충분한 시간을 쓰기 어려운 경우도 많을 것 같아요.

맞아요. 그 부분은 내부적으로도 아쉬움이 많이 남았어요.
예를 들어 설문을 보내거나, 만족도 조사를 하면 피드백은 어느 정도 받아요.
그런데 나중에 인사이트를 뽑으려고 보면, 질문 수준이 너무 낮았던 거예요.

“이걸로 뭘 해석하지?” 싶은 질문들이 많았고, 결국은 돌고 도는 결과만 나오는 거죠.
“이건 좀 애매하긴 한데… 그럼 다음에는 이렇게 해보자” 하면서 늘 “다음엔 유저 리서치를 제대로 해보자”**는 말이 반복됐던 것 같아요.

근데 여기서 가장 큰 문제는,“어떻게 해야 더 좋은 질문을 할 수 있을까?”**에 대한 경험이 없다는 점이었어요.저희가 리서치 전문가는 아니잖아요. 그러다 보니 실제로 질문을 정제하거나 구조화하는 것도 쉽지 않았고, 그게 참 어려웠던 것 같아요.

Q. 그렇다면 PM 입장에서 좋은 리서치란 어떤 조건을 갖춰야 한다고 생각하시나요?

저는 액션 플랜이 나오는 리서치가 좋은 리서치라고 생각해요.
결국 가장 중요한 건 문제를 정확하게 찾는 것이잖아요.
그래서 리서치를 통해 명확하게 문제 정의가 되었을 때, 그게 가장 이상적인 결과라고 생각해요.

사실 제 일 자체도 결국은 문제를 찾는 게 핵심이기 때문에,
그걸 도와줄 수 있는 리서치가 제일 좋다고 느껴요.

예를 들어, 쏘카 내에서 “이 서비스에서 이런 문제가 있다”는 걸
리서치를 통해 명확하게 정의해줄 수 있다면, 그건 정말 좋은 협업 파트너로서의 리서치라고 생각합니다.

✍️ 다음 이야기

유저 리서치를 직접 설계하고 실행하는 것만큼,
그 인사이트를 조직 안에서 문제로 정의하고, 실행으로 옮기는 일도 PM의 중요한 역할입니다.

2부에서는 전이준 PM님이 생각하는
좋은 리서치란 무엇인지,
협업에서 신뢰 자산을 어떻게 쌓아가는지,
그리고 PM이라는 직무를 지속 가능하게 만드는 북극성은 무엇인지에 대해 들어봅니다.

PM이라는 역할에 조금 더 가까이 다가가고 싶은 분들이라면,
2부도 꼭 이어서 읽어보세요.