by
Sep 18. 2022
우리 팀은 페르소나가 뭔지 몰라요.
우당탕탕 UX리서처의 회고.
제로부터 시작하는 UX리서처 생활
UX리서처로 조직에 합류한 지 일 년이 넘었다.
입사할 때 조직이 작았다. 엔지니어를 포함해서 여덟, 엔지니어를 제외하곤 셋(사업 PM, 개발 PM, 그리고 나)이 전부였다. ’ 딥러닝 기술로 시장에 나가보자’는 막연한 목표를 가졌었고, 아이템도 시장도 뚜렷하지 않았다.
IT업계에서 ‘인공지능, 딥러닝으로 성공해보자’는 직장인의 ‘유튜브로 대박 나보자’와 별로 다를 바 없다 생각한다. 듣기 좋은 말이지만 실제로 해내는 것은 엄청나게 어렵기 때문이다. 이제는 20-30명대 규모를 가지고, 쓸만한 기술도 만들었고, 초기 프로토타입으로 ‘진짜 고객’을 찾아 핵심 가설에 대한 검증도 마쳤고, 출시일을 확정하며 시장에 나갈 도화선에 불을 붙였다.
제품도 사용자도 없는 조직에서 UX리서처가 무슨 일을 한단 말인가? 짧게 말하면, 온갖 일을 다한다, 가설만 검증할 수 있다면. 팀이나 제품도 문제지만, 아무것도 없는 팀에서 UX리서처로 합류해서 지금에 이르는 과정이 결코 쉽지 않았다. (너무 x 10000) 어려웠다. 리서처로 초기 기반을 마련하기까지 있었던 일들을 회고해본다.
Multi-GPU에 작동하도록 코드 업데이트하고 BatchSize와 GPU 개수 바꿔가며 성능 확인하려고요.
진심..이 무슨 괴이한 말인가. 합류 후 몇 달 동안은 낯선 땅에 교환학생 온 기분을 느껴야 했다. 당시 조직은 음성합성 기술을 연구하고 있었고, 제품은 커녕 아직은 시장과 고객에 대한 탐색을 하고 있었다. 그렇기 때문에 미팅의 절반은 기술 개발 현황과 토론, 시장에 대한 탐색 내용을 다뤘다.
극초기에는 조직에서도 비공개 조직이었고, 여섯 명이 들어가는 작은 방에 자리를 배치받았다. 네 명의 딥러닝 엔지니어가 나를 둘러싸고 하루 종일 무슨 말을 하는데, 뭐라 말하는지도 모르겠고, 약간의 소외감마저 느꼈다. 아무것도 정해지지 않은 상태에서 전혀 말이 통하지 않는 사람들과 일해야 한다니, 잘할 수 있을까.. 딥러닝 공부를 해야 하나.. 하는 생각이 매일 들었다.
다행히, 나는 호기심이 많은 사람이고, 팀원들은 친절했다. 조직의 기술이 어떻게 만들어졌으며, 어떤 방향을 향해 가고 있는지, 내가 모르는 단어는 어떤 뜻인지 하나하나 알게 되었다. 안개처럼 흐릿했던 영역을 하나하나 헤쳐나가면서 조직의 상황을 이해할 수 있었다.
그러나, 내가 당황했던 것은 딥러닝의 난해함이 아니었다. (차라리 그랬다면 좋았겠다.) 가장 큰 문제는 사람들이 내가 하는 일이 무엇인지 모른다는 것이었다.
포스트잇으로 뭘 하는 거예요? 진짜 궁금해서 그래요.
어느 날, 열심히 포스트잇으로 어피니티를 하던 나에게 엔지니어 한 분이 이런 질문을 했다."포스트잇으로 뭘 하시는 건가요?" 그 이후로도 악의 한 방울도 없는, 순수한 이 질문(혹은 유사한 질문)을 몇 번이나 받았는지 모르겠다.
처음에 고객군과 시장에 대한 방향성을 잡고, 초기 페르소나를 빠르게 디벨롭해서 C 레벨에게 공유한 적이 있었다. 어떤 특성을 가지고 있는지, 어떤 니즈를 가지고 있고 어떤 어려움을 가진 고객인지 우리가 시장에 대해 이해하고 있는 바와 잠재 고객군에 대해 이해하고 있는 바를 녹여서 페르소나를 만들었다. 예상 질문도 몇 개 생각해갔는데, 다음과 같았다.
인접 고객군은 왜 다루지 않았나요?
그 고객이 정말 우리가 노리는 시장의 잠재고객을 가장 잘 대표할 수 있나요?
이 페르소나의 한계는 무엇인가요?
하지만 C레벨의 첫 번째 질문은 예상을 전부 깨버렸다.
“이거 진짜 사람인가요?”
내가 딥러닝 용어를 몰라서 허덕였던 것처럼, IT업계에 일한다고 UX에 대해서 잘 아는 것은 아니다. 체감상 절반은 ‘뭔가 요즘 유행하고, 멋진 것’ 정도로 추상적으로 이해하고 있다. 나머지 절반 중 UX에 직접적으로 관련 없는 직군은 UX와 UI를 구분하지 못한다. 그리고 제일 안타까운 사실은 ‘UX’ 혹은 ‘Product’ 직함을 단 사람 중에 적지 않은 사람조차 ‘경험’이나 ‘인터페이스’가 뭔지 설명해보라고 하면 ‘음..’으로 시작해서 ‘.. 가 아닐까요?’로 대답한다는 것이다. UX와 UI를 구분할 줄 아는 게 정말 중요하다거나, 개념을 기깔나게 설명해야 일을 잘한다는 것은 아니다. 요지는 ‘사용자 경험’이 뭔지 모르는 팀은 ‘사용자 경험 중심’ 테스크를 만들거나 제품을 만들기 쉽지 않다는 것이다. 그리고 나는 UX의 수호자로 발탁되어 황량한 땅에 떨어진 것이었다.
슬픈 사실 하나를 공유해주자면, 초기 조직에는 ‘나의 중요함’을 지원하고 지지해줄 사람이 별로 없다. ‘사람들이 잘 모르는 직군’일수록 더욱. 내가 하는 일이 무엇인지도 모르고, 왜 필요한지 모르는데 어떻게 나를 지지할 수 있겠는가? 냉정하게 사람들은 당신이 왜 조직에 필요한지 잘 모른다. ‘(고용주가 혹은 누군가가) 필요하니까 뽑았겠지’라고 생각을 하지.
상상해보자
성배님은 무슨 일 해요?’
‘음.. 고객일지도 아닐지도 모르는 사람을 만나서 전화도 하고, 그 사람들 평소에 무슨 생각하나 들어보기도 하고요, 그런 걸 포스트잇에 붙여서 이리저리 옮기면서 정리한 다음에 당신한테 보여주는 일이요.’
“음, 그렇군요, 조직에 꼭 필요한 인재가 들어와서 정말 다행이에요, 당신 같은 사람이 오기를 기다렸어요!”
이렇게 대답해주는 사람이 몇 명이나 있을까. 이렇게 대답하는 사람 열에 여덟은 거짓말쟁이다. 나머지 둘은 채용공고 올리고 나를 면접 본 사람이고. 모든 문제가 그렇듯이, 불평만 한다고 저절로 해결되는 것은 없다. 사실 따지고보면, 이 문제를 해결하라고 내가 월급을 받는 것이 아닌가.
나 이런 일.. 하는 사람이거든요?
합류 후 몇 달이 지나고 팀원들에게 UX 리서치가 무엇인지 소개하는 자료를 만들어서 공유할 기회가 있었다. 리서치가 무엇이고, 왜 필요하며, 여러분이 어떤 부분을 도와 주어야 하는지 알리는 내용이었다. (일부 편집해서 브런치에 올렸다.) 조직 규모가 10~15명이 되어 그럴싸한 모양새가 갖춰질 즈음이었다.
UX리서처가 아니더라도, 조직에 새로운 역할을 하게 된 사람들에게서 나와 비슷한 고민을 많이 듣는다. 그리고 그들도 나처럼 자신의 존재를 조직에 열심히 드러내고자 한다.
“제 역할을 사람들이 잘 모르는 것 같아요, 열심히 일을 해도 제 직군의 임팩트를 잘 모르는 것 같아서 속상해요. 일단 발표 자료를 하나 만들어서 제가 왜 조직에 필요한지 어필하려고요.”
나는 그 사람이 조직에 합류한 시기가 이를 경우, ‘존재 알리기’ 발표를 만류한다. 내가 무슨 일을 하는지 설명한다고 해서 필요한 존재가 되는 것이 아니다. 마치, 모든 어린이에게 ‘어른이 된다고 전부가 아니야’라는 말을 이해시키는 것만큼이나 어렵다. 적어도 ‘작은 성공 몇 개’를 조직에 안겨준 후에 설명해도 늦지 않다. 내가 이러한 발표를 한 것은 크고 작은 리서치를 5-10개 정도로 수행한 이후였다.
논문 연구와 제품 조직에서 리서치의 다른 점
대학원 연구와 UX리서처의 리서치는 무엇이 다르냐는 질문을 종종 받는다. 하는 ‘일’은 본질적으로 다르지 않다. ‘문제를 정의하고, 관련된 배경 지식(논문이든 무엇이든)을 파악하고, 적절한 방법론을 선택하고, 수행(인터뷰, 서베이 등)해서 분석하고 리포트를 쓴다는 측면에서 말이다. 대학원에서 하면 결과물이 논문 형태로 (영어로), 회사에서는 더욱 다양한 형태(리포트, 발표, 가끔은 슬랙 메시지로)로 나온다는 점만 빼면.
정말 다른 것은 리서치를 하는 목표에 있다. ‘무언가를 앎, 지식 체계의 확장’에 초점을 둔 논문 연구와는 달리 제품 조직에서 리서치는 ‘의사결정 성과를 높이기’ 위해 수행된다. 다른 말로 바꿔 말하면, ‘어떻게 결정할지 모르겠는지 사안’을 결정하기 위해 진행된다. 리서치의 엄밀함도 좋고, 방법론이나 예산 문제도 중요하지만 가장 중요한 것은 ‘리서치 결과가 어떤 의사결정으로 이어지는가’이다.
UX리서처에 대한 대부분의 글이 ‘고객 이해에 대한 내용’으로 도배되는 것이 가끔은 안타깝다. 물론 사용자와 시장을 이해하는 것은 중요하다. 간과되고 있는 사실을 말해주자면, 의사결정은 사람이 한다. 그러므로 UX리서처의 고객은 사용자가 아니라 당신의 팀원이다. 조직의 의사결정자가 가장 고민하고 있는 전략은 무엇인지, 가장 의사결정 내리기 어려워하는 것은 무엇인지, 전략적 임팩트가 가장 큰 의사결정에 어떤 정보가 비어있는지 파악하는데 ‘실제 리서치를 수행하는 만큼’ 리소스를 써야 한다. 진지하게 말해서, 고객 인터뷰를 한 명 더 하는 것보다 가장 높은 의사결정자와 커피 한 잔을 마시는 것이 일의 성과를 높일 수 있다. (부정한 리서치를 하라는 것은 절대 아니다.)
목표가 바뀌면 모든 것이 달라진다. 엄밀함도 중요하지만, 초기 조직은 속도가 더 중요할 때가 있다. 70%만 완성하고 나머지는 개발 이후 보완할 수 있도록 해야 한다. 이 경우에는 속도를 희생하지 않는 리서치를 하는 것이 중요하다. 개발 조직의 특성을 이해하고 항상 한 발자국 빠른 리서치를 수행하는 편이 성과가 좋았다. (덕분에 00 피쳐가 전혀 급하지 않다는 사실을 알아서 기획에서 과감히 빼서 리소스를 크게 아낄 수 있었어요.) 반대로 약간 늦게 진행한 리서치는 모두의 발목을 잡기도 했다. (이거 기다리느라 개발 못하는 거 아닌가요?)
이 둘의 차이는 설명하자면 끝도 없다. 언젠가 따로 정리해볼 기회가 있으면 좋겠다.
리서치에 대한 팀원의 불만을 잠재우기
리서치 결과.. 믿을 수 있는 거죠?팀원들, “왜 6명만 인터뷰를 했나요?”, “ 왜 남자와 여자 비율이 다른가요?, 고연령자도 인터뷰해야 하는 거 아닌가요?”, “서베이는 왜 안 했나요?”, “인터뷰한 5명 중 같은 발언을 한 사람이 몇 퍼센트인가요?”
나, “실제로 새로운 지식을 얻는 데는 평균적으로 5명이면 충분하기 때문에.. , 이 경우 남녀의 차이를 알려고 한 것은 아니었기 때문에.. ,.. “
김새는 이야기지만, 한동안 나의 리서치(대부분 인터뷰)는 항상 반쪽 짜리 리서치였다. 하나의 리서치를 마칠 때마다 ‘변명 타임’을 가져야 했기 때문이다. 리서치의 한계나 설계 방법에 대한 설명을 보충하는 것은 새로운 일이 아니다. 대학원에서 지도교수님한테 혹은 논문 리뷰어에게 하던 일이 팀원으로 바뀌었을 뿐이다. 다른 점은, 그들이 리서치 전문가가 아니라는 점, 그리고 그들이 리서치 결과를 믿지 않는다면 아무런 행동으로 옮기지 않는다는 점이다.
이들에게 어떻게 리서치의 한계를 설명하고, 납득시킬 것인가? 어떤 이는 인터뷰 방법론에 대해 잘 알지만, 어떤 이는 전혀 모른다. 왜 정량 리서치가 아닌 정성 리서치를 진행했는지, 혹은 그 반대인 지부터 설명하다 보면 끝도 없다. 이해관계자가 한 명이 아니라 열 명이라면? 가장 도피처는 ‘내 역할과 일을 잘 아는 사람’만 찾아서 일을 하는 것이다. 주로 경험 있는 PM이나 디자이너와 일하면서 내 업무 영역을 UX 조직에 국한시키는 것이다.
나는 더 큰 임팩트를 내고 싶었고, 조직이 리서치의 임팩트를 직접 느끼게 하고 싶었다. 그래서 전략을 완전히 바꾸기로 했다. 중요한 것은 한계점을 잘 설명하는 것이 아니라 한계점에도 불구하고 우리가 리서치 목적을 달성할 수 있다는 사실에 공감하는 것이다. 패러다임을 ‘수집, 분석, 설득’에서 ‘참여, 공감’으로 바꿨다.
‘직접 시키는 것’ , 이보다 확실한 것은 없다.
사람들은 자신이 믿고 싶은 것만 믿는다. 다음 리서치에 어떤 것을 하면 좋을지 함께 이야기하고 (”요즘 고민하는 의사결정이 있으실까요?”), 리서치 킥오프에도 참가해서 이미 알고 있는 사실과 염려하는 사실을 공유하고 (”이런 이런 부분은 굳이 인터뷰지에 안 넣어도 될 것 같아요.”), 인터뷰 세션에도 같이 참여시키고, 필요하면 노트 테이킹도 시키고, 분석할 때 어피니티 다이어그램도 함께 하고, 필요하면 엑셀 노가다도, 가위질도 시켜라.
직접 인터뷰 과정과 분석에 참여한 사람들은 분석과정이 어떻고, 리크루팅의 아쉬운 점이 어떻고에 대해 이야기하지 않는다. 모든 발견점이 다 녹아든 몇 페이지나 되는 분석 리포트를 쓰고 ‘프레젠테이션’ 하는 대단한 과정도 필요 없다. 그들은 리서치 결과가 의미하는 바를 이미 알고 있다. 곧바로 우리가 이 결과를 통해 ‘무엇을 할 것인가’를 이야기한다.
사진은 처음 모든 직군(프런트, 백엔드 개발자, 딥러닝 엔지니어, PM, 기획자, 디자이너..)을 모아 두고 아이디어 워크숍을 진행했던 당시다. 제품의 방향성에 대해 서로 ‘전혀 다른’ 생각을 가지고 있는 시점이었고, 이를 모아놓고 이야기하기 위해 코디자인 워크숍을 진행했다. 정말 필요하다고 느껴서 진행했지만, 내심 워크숍을 마치고 ‘시간 아까웠다’는 피드백이 잔뜩 돌아올까 봐 굉장히 쫄아있었다. 그러나 가장 많이 들은 피드백은 ‘젠장, 진작에, 더 빨리 이걸 했어야 했어요.’였다. 그 후로 종종' 다음 워크숍은 언제 해요?’라는 질문에 ‘지금은 다른 일 때문에 바빠서요. ㅠㅠ’라고 답하느라 곤혹을 치르기도 했다.
그 후로 ‘정말 큰 의사결정’, ‘서로 다른 생각의 얼라인’이 필요할 때마다 워크숍을 진행한다. 워크숍은 단순히 ‘재밌는 아이디어 내는 시간’이 아니다. 고도의 수렴과 발산의 과정이 필요하고, 직군 간 전문성을 존중하면서 빠르게 커뮤니케이션하는 스킬이 필요하다. 수 차례 워크숍을 진행하며 조직 전체가 서로 다른 의견을 맞춰가고 한 발자국 나아가는 과정을 볼 때마다 놀랍다. 조직 전체가 리서처로 성장하고 있는 것이다. 정말 리서처라면 엔지니어까지 인터뷰에 들어오고, 같이 포스트잇을 붙였다가 뗐다가 하는 모습을 보면서 가슴이 웅장해지지 않을 수가 없다. (이 장면을 볼 때마다 웅장해져서 죽을 것 같다..)
‘무조건 참여시킨다고’ 좋은 것은 절대 아니다. 페르소나나 유저저니를 만드는, 핵심 고객을 정의하는 리서치는 주요 이해관계자가 모두 필요하다. 한 두 개의 시나리오를 테스트하는 UT에는 디자이너나 기획자, 개발자 한 명 정도가 짧게 참여해도 된다. 요지는, 그들이 시간을 투자할 만큼 중요한 리서치를 해야 하고, 시간을 투자한 만큼 보다 두 배 이상 도움이 되어야 한다. (그렇지 않다면 엔지니어가 왜 기꺼이 가위질을 할 것인가)
UX리서처 커뮤니티에서는, ‘Research Democratization’ (리서처가 아닌 사람도 리서치를 하게 하는) 물결에 대해 조심스러운 목소리가 종종 나오는 것 같다. (https://www.nngroup.com/articles/democratize-user-research/ ) 내 입장은 ‘무진장 어렵지만, 잘 해내면 임팩트를 10배 낼 수 있다.’는 것이다. 리서처는 조직의 규모에 비례해서 숫자가 늘어나지 않는다. 한두 명의 리서처가 어떻게 30명과 일하면서 임팩트를 낼 수 있는가? 답은 간단하다. 30명을 리서치에 참여시켜라.
역할 확장하기, ‘인터뷰 진행자’에서 ‘조직 전략의 의사결정 파트너’로
자신의 JD를 6-12개월마다 새로 쓰고, 이를 매니저와 조직과 이야기하라.
