brunch

라이킷 20 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김뽀로리 Aug 11. 2022

처음 팀을 빌딩하며 느낀 이야기들

새싹 UX Researcher의 직업 일지!

자, 이제 팀을 잘 굴러가게 세팅해보세요.

안타깝게도 UX 리서치 팀은 모든 회사에 있는 필수 팀이 아니다. 내 업무에 자부심을 가지고 있긴 하지만, 사실이 그렇다. 기획, 개발, 디자인, 마케팅, 데이터 분석가 등을 모두 채용하고 나서야 뒤늦게 찾는 경우가 많다. 뭐, 회사의 입장도 이해는 간다. 리서치 팀이 없다고 해서 프로덕트가 만들어지지 않는 건 아니니까. (물론 만든다는 행위 자체에만 포커스를 맞춘다면 말이다.) 때문에 취업시장에 들어선 리서처들이 신생 UX 리서치 팀에 들어가게 되는 일이 적지 않다. 그러니까, “사용자들이 자꾸 어렵다고 하는데, 우리도 UX 리서치 라는 거 해봐야 하지 않겠어?” 라는 생각만 가진 채 대뜸 만들어진 팀 말이다. 나 역시 그런 경우였다.

생각해보면 ‘이상적인 UX 리서치 팀’ 이라는 환상이 존재하는 것 같다. 개발, 디자인, 기획 팀과 떨어져 있는 독립적인 팀으로, 이들과 소통하되 어떤 그룹의 산하에 있지 않는 위치 말이다. 때문에 다른 팀들과 동등하게 의견을 조율할 수 있고, 제작자 입장에서는 마음 상할 수 있는 결과를 잘 전달할 수도 있게 된다. 각 팀은 궁금한 사항을 리서치 팀에 물어보고, 리서치 팀 역시 필요한 리서치를 제안할 수 있다. 물론 이를 환상이라고 표현한 이유는, 말처럼 쉽지 않기 때문이다. 회사는 실무 담당자들처럼 UX 리서치에 대한 이해가 높지 않을 수 있다. 때문에 개발 팀과 어느 정도 거리가 있다면 어디에 개설하든 상관없겠지 라는 마음을 먹을 수도 있다. 소통이 안 될 수도 있다. 나의 비극은 바로 이 지점에서 시작되었다.

대외적인 이유는 달랐으나 개발 팀과 너무 붙어있으면 팔이 안으로 굽을까봐, 라는 게 실제 이유였던 것 같다. 개발도 디자인도 기획도 아니되 독립적인 팀도 아닌 위치가 우리 팀의 첫 주소지였다. 브랜딩과 마케팅 팀 사이에 덩그러니 놓였다. 그룹 내 누구도 우리 팀에 대해 제대로 정의를 내리지 못했다. 대체 뭘 하는 팀인가요. 그 질문을 가장 많이 들었다. 개발팀에게는 부디 결과 전달 시에 주의해 달라는 말을 팀 구축도 전에 들었다. 이럴수가. 망망대해에 나룻배 하나 던져준 채 떨어트리면 이런 기분일까.

이미 세팅이 끝난 팀에 들어가는 것과 새로 팀을 세팅해야 하는 건 천지차이가 있다. 거기다가 이제 막 회사에 들어온 나에게 “기다리고 있었어요! 그런데 업무는 어떻게 해야 할까요?” 라는 질문 폭격이 떨어지기 시작했다. 물론 흔쾌히 답변을 하고 의견을 조율해 나갔지만, 혼란스러운 건 혼란스러운 것이었다. “이전 회사에서는 이렇게 했어요.” 라는 대응도 한계가 있었다. 이전 회사의 방식을 언제까지 차용할 수는 없었다. 기준이 필요했다. 나룻배 하나 던져줬다고 탓만 하면서 그대로 침몰할 수는 없지 않은가.

신입이 들어와도 가이드만 본다면 일 할 수 있도록

부끄러운 일이지만 소위 ‘인터뷰에는 숙련된 기술과 교육이 필요하다’라는 환상에 사로잡혔던 것 같다. 나 뿐만 아니라, 팀 전체가 말이다. UT나 IDI를 진행하기 위해서는 일종의 인증마크가 필요하다고 생각했다. UX 리서치에 대해서 잘 알고, 교육도 받고 경험도 있는 사람에게 부여하는 마크 말이다. 솔직하게 말하자면 누구나 할 수 없는 일을 하는 게 나의 전문성이라고 착각을 했다. “그건 이렇게 진행해야 ‘정석’ 아니야?” 라고 생각하기도 했다. 각자는 각자의 전문성을 신앙처럼 믿었다. 그러니 같은 팀이 된 사람들끼리 얼마나 많은 소통의 오류가 있었을까. 엉망이었다고 생각한다.

다행히도 이 문제는 오래가지는 않았다. 문제가 있다고 느낀 팀장님은 교통정리를 시작했다. 그리고 했던 말이, “누구나 가이드를 보면 일을 할 수 있어야 한다.” 였다. 그 순간 나는 머리를 맞은 것 같았다. 그래, 서로 내 말이 옳고 내가 전문가라고 믿는 집단이 무슨 협업을 할 수 있단 말인가. 나는 바로 마음가짐을 고쳐먹을 수 있었다.

그렇다면, 신입이 들어와도 바로 업무를 할 수 있는 가이드란 무엇일까? 우리 팀은 그 가이드를 업무 객관화로 풀어냈다. 일을 하는 과정과 산출물을 명확하게 정의하자는 것이었다. 서비스 모니터링부터 VOC 모니터링, Customer Journey map, 인터뷰 진행 계획서, 진행 후 보고서까지. 아주 사소한 진행 과정까지 모두 꺼내어 작성했다. 활동은 크게 Plan, Do, Check, Action으로 나누어 구분 할 수 있었다. 각 단계에서 필요한 업무 설명, 소요 시간, 매뉴얼, 관리 대장과 산출물, 관리 툴과 담당자까지 모두 작성했다.

팀 빌딩 시절의 대화들

과정은 더블 다이아몬드를 기준으로 세팅할 수 있었다. 예전의 이론이고 이제는 많이 변경되기도 했지만, 서로 과정 싱크를 맞추는 데는 이만한 게 없다고 생각했다. 팀 내부가 아닌 외부 사람에게도 설명하기 쉬웠다. 우리 팀은 익히 알고있는 Discover, Define, Develop, Deliver를 UX 리서치 버전으로 수정했다. 실제 프로덕트를 만드는 것이 아니라, 해결책을 적용하여 피드백을 받는 것까지를 Deliver 과정으로 보았기 때문이었다. 각 단계에서 사용할 수 있는 방법론을 작성하고, 각 리서치 주제에 맞춰 좋은 방법론을 선택하기로 합의했다. 이를 업무 로드맵에 녹였다. 누구나 들어와서 팀 업무에 쉽게 적응할 수 있도록 말이다. 이는 반복적인 리서치를 잘 진행할 수 있도록 바퀴를 만든 것과 같았다.

업무 진행 과정의 예시

서로 다른 생각을 하나씩 맞추다보니 업무 로드맵이 생겼다. 때문에 이후 소통에서도 ‘이 단계를 보시면~’ 이라고 설명 할 수 있게 되었다. 커뮤니케이션 시간이 매우 단축되었다. 과정을 맞추니 서로 어떤 일을 하고 있는지도 알았다. 또, 각자 어떤 분야에서 좋은 결과를 보여줄 수 있는지도 알 수 있었다. 시간은 조금 걸렸지만 반드시 해야 했던 일이라고 생각한다.

이 과정을 거치며, 회사에서 나만 할 수 있는 일이라고 생각하는 게 얼마나 나쁜 영향을 주는지 알게 되었다. 정보 독식은 하면 할수록 서로에게 독이다. 그게 나의 전문성을 보여주는 일이라고 믿으면 안된다. 새로운 사람이 온다면 빠르게 일에 적응할 수 있도록 해야한다. 내부에서조차 소통이 되지 않으면 문제가 크다. 커뮤니케이션이 가장 중요한 능력 중 하나로 뽑히는 팀 아니던가. 남들을 이해시키지도 못한 채로 일을 잘 한다고 해서 도움이 될 수 있을까? 나만 잘하면 되는 일은 세상에 없다.

커뮤니케이션의 시작은 ‘말 맞춤’부터

일하는 단계를 맞췄으니 이제 모든 사람이 행복했습니다 같은 결말을 바랐으나, 아쉽게도 그렇지가 않았다. 초기 팀을 만드는 것이 그렇게 쉬운 일일리가 있을까. 단계를 맞추니 이후에는 언어에서 문제가 생겼다.

지금 생각해보면 참 어처구니 없는 나의 실수...

서로 생각하고 정의내리고 있는 용어가 달랐기 때문이었다. UX 리서치 관련 언어를 세밀하게 알고있는 사람들이긴 했지만, 소통을 할 때는 말이 다르게 나올 수도 있었다. 거기다 우리 팀의 결과물을 확인하는 건 팀 외부의 사람들이었다. 인터뷰나 사용성 테스트나 같은 말 아닌가요. 라고 물을 수 있는 사람들 말이다. 팀 내부에서도 혼란이 있는데, 외부의 사람을 어떻게 이해시키고 설득시킨단 말인가.

설상가상으로, 말만 오류가 나면 참 다행이었다. 결과 보고서 내에서도 서로 사용하는 용어가 달랐다. 결과 보고를 할 때, “여기서는 인터뷰라고 했는데, 저기서는 리서치라고 했네요. 둘은 다른건가요?” 같은 질문도 들어왔다. 좀 더 세세하게 말해보자면, 2p에서는 Drag&Drop으로 썼는데, 12p에서는 드래그앤드롭으로 한글 표기를 했다. 어떤 사람은 대쉬보드라는 단어를 썼고, 또 다른 사람은 대시보드라고 적어두었다. 관리자를 어드민으로 쓰는 사람, 그냥 어드민으로 쓰는 사람. 모든 리서치를 인터뷰라고 작성하는 사람 등등. 각자 다른 이유로 다른 표현을 사용했다. 서로 너무 당연하게 사용하던 말들이라 소통 문제가 생길 수 있다는 걸 알지 못했기 때문이었다. 이 역시 가이드가 필요한 순간이었다.

이러한 이유로 우리 팀은 용어집을 만들었다. 눈치껏 알아들었던 말들이 없어야 한다는 게 주 포인트였다. 영문 표기는 모두 삭제하고, 한글 표기로 맞춰 작성했다. 관리자는 너무 많은 관리자가 있었으므로 어드민으로 통일했고, 팝업 화면은 그냥 팝업으로, 인터뷰, 리서치는 모두 테스트로 정의하기로 했다. 그 외에도 다양한 소통 오류를 만들어냈던 용어들을 하나로 통일했다. 용어집을 따라 움직이니 의사소통 문제가 생기는 일이 적어졌다. 모든 기준은 용어집이 되었다. 언어가 통일되자 다른 팀 역시 혼란을 덜 겪었다. 사소한 단어를 묻는 질문들도 거의 사라졌다. 팀을 처음 빌딩한다면 이렇게 작은 일도 모두 맞춰나가야 한다는 걸 알게 된 경험이었다. 진취적이지 않은가!

테스트 장비부터 개인정보 보호까지!

사소한 맞춤은 이후에도 계속되었다. 테스트를 진행하는 데 필요한 장비부터 툴, 개인정보 약관까지 모두 세팅이 되어야 했다. 2시간 이상 녹화할 수 있는 캠코더, 삼각대, 컴퓨터에 설치할 미니 캠(고프로)까지. 상황에 맞춰 하나씩 준비해 나갔다. PC가 2시간 이상 화면을 녹화하면 뻗을 수도 있다는 사실을 몸소 체감하기도 했다. 당시에는 비명을 질렀으나 몇 번 시행착오를 거치고 나니 자연스럽게 클라우드를 연결할 수 있었다. 인터뷰 내용을 날린 적이 한 두 번이 아니었다. 전부 예상치도 못한 상황들 때문이었다. 이런 일이 있을 때마다 이전 회사에서는 모두 세팅이 되어있었는데 싶은 아쉬움이 있었지만, 이런 것까지 필요하다는 걸 알게 된 좋은 기회이기도 했다. 뭐든 배우기만 했으면 된 것 아닌가. 결과 보고는 모두 무사히 진행되기도 했다!

장비 세팅에서 가장 시간이 오래 걸린 일은 인터뷰 툴 사용이었다. Usability나 User testing, Hot jar, methinks 등 세상에는 많은 인터뷰 툴이 존재하고 있었다. 하지만 이름을 보면 알다시피, 전부 영어를 기반으로 했다. 내게만 영어로 보이면 상관이 없었으나, 사용자에게 날아가는 안내 메일, UI에서도 전부 영어였다. 시험삼아 다른 툴을 사용해 봤을 때, 영어가 나와서 복잡하고 어렵다는 이유로 노쇼 비율이 높아졌다. 해외 유명 툴들을 사용할 수 없겠다는 판단이 든 건 이때였던 것 같다. 인터뷰 참가자들이 기본적으로 영어를 평균 이상으로 할 것이란 생각으로 접근하면 안 되었다. 링크 클릭만 하면 접속이 되어야 했고, 그 과정에서 영어가 장벽이 되어서는 안되었다. 때문에 카드소팅이니, A/B 테스트이니 하는 기능들을 제공해 준다는 인터뷰 툴들을 모두 포기하게 되었다. 그리고 많은 시행착오를 걸쳐, 지금은 Zoom으로 정착한 상태다. 툴 하나 고르는 것도 이렇게 쉽지가 않았다.

그 밖에도 신경을 써야 하는 일이 계속해서 생겨났다. 녹화한 인터뷰 영상에 개인정보가 노출된다면 모두 블러처리를 해서 가려야했고, 직접적인 얼굴 노출이 되면 안 되었다. 이메일이나 아이디 등을 입력하는 화면에서는 촉각을 곤두세웠다. 혹시 URL에 메일주소라도 보일까봐 전전긍긍해하며, 검수에 검수를 반복했다. 어쩌다가 영상 편집까지 하게 되었는지 모르겠다며 한탄을 한 적도 있으나, 나는 이 과정이 반드시 필요했다고 생각한다. 인터뷰 진행뿐만 아니라 후처리까지 신경을 써야만 앞으로도 좋은 인터뷰 참가자분들이 올 것 아닌가. 문제가 생기게 만들 수는 없었다.

결과보고 프로세스도 잘 챙겨갈게요

팀 내에서 사용하는 결과보고서는 매번 양식이 바뀌었다. 입사한지 꽤 시간이 흐른 지금도 바뀌는 경우가 많다. 어떤 결과보고 양식이 문제점을 가장 잘 보여주고 있는지 고민하는 사람들이 모여 있기 때문이었다. 고정된 양식에 정보를 입력하기만 하면 얼마나 좋겠는가. 이렇게 매번 바뀌는 방법이 실무자 입장에서는 아주 피곤한 일이지만, 더 좋은 결과를 얻기 위한 끊임없는 발전이라고 생각하기로 했다. 안정된 상태라고 해서 안주하지 않는 게 우리 팀의 기조인 듯싶다.

결과보고서를 제출하고, 개발팀과의 소통과 트래킹을 하는 과정도 팀 첫 빌딩에서는 아주 중요한 문제다. 보고는 전체 보고로 진행되었고 이후 질문 폭탄 시간을 갖게 되었다. 이 모든 과정을 마치고는 인터뷰 결과에서 나타난 문제점을 티켓으로 발행했다. 우리 팀은 지라를 사용하고 있는데 프로덕트 제작자들에게 팀의 제대로 의견이 받아들여지고 있는지를 확인하는 과정이 매우 험난했다. 이건 아마도 모든 UX 리서처들의 고민과 걱정거리일 것이다. 개발 팀과의 소통의 장이라. 이에 대해서는 눈물이 날 정도로 할 말이 많다. 말이 길어질 듯하여 다음 편에서 설명하고자 한다.

길어진 글을 요약해보자면, ‘내부 프로세스와 말 맞춤을 반드시 진행하자.’와 ‘상상 이상으로 사소한 것까지 모두 챙겨야 한다.’ 정도가 되겠다. 말은 쉽지. 그렇게 생각할 수도 있다. 위에서 나열한 내용을 읽는 데는 5분이면 되지만, 모두 구축하는 데는 정말 오랜 시간이 걸렸다. 시간만 걸렸는가. 스트레스도 많이 받았다. 그 사이에 의견 분쟁은 얼마나 많았는지는 말 할 필요도 없었다. 하지만 누군가 처음 팀 빌딩을 한다면 반드시 해보라고 권해주고 싶은 시간들이기도 했다. 이 모든 것들이 힘든 과정일 수 있지만, 팀 첫 빌딩을 위해서는 반드시 거쳐가야 하는 항구이기도 하다. 마음가짐을 단단히 하자. 나 또한 그러고 있으니까.

이 글이 닻을 올리고 첫 항해를 시작하는 팀의 팀원들에게 조금이나마 도움이 되기를 바란다. 힘들고 혼란스러움을 느끼는 건 당연하니까 너무 걱정하지 말라는 말을 전하며, 여러분의 무사 출항을 기원한다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari