디자이너가 새로운 도메인을 빠르게 학습하는 법

저는 토스가 첫 금융권 회사예요. 그래서 입사하기 전에 굉장히 긴장을 했었죠. 왜냐하면 토스는 일이 굉장히 빠르게 돌아가는 조직이라고 들었는데, 금융이라는 새로운 분야를 빠르게 학습하고 따라갈 수 있을지 걱정이 됐거든요.

아니나 다를까, 1년 반 동안 무려 4개의 새로운 분야를 학습해야 했어요. 제한된 시간 안에서 결과물을 내려면 쏟아지는 정보를 빠르게 학습해야 했어요. 하지만 그게 어려운 상황들이 늘 있었죠.

문제

온보딩할 때 많은 정보를 빠르게 익히는 것이 어렵다.

4개의 분야를 만나며, 각 분야의 방대한 정보와 그것을 빠르게 익혀야 하는 상황은 정말 힘들었어요. 해야 할 일과 이해의 범위가 정해져 있고, 작았던 이전 조직과 다른 상황이었죠. 이후 회고했을 때 저는 주로 2가지의 실수를 반복하고 있었던 것 같아요.

실수 1 – 모든 정보를 사실로 받아들이기

설명해 주시는 분들도 간혹 오류가 있는 정보나, 개인의 생각이 반영된 정보를 주시는 경우도 많았어요. 처음 도메인을 만났을 때는 이런 부분들을 명확히 구분하기가 어려웠어요. 온보딩 과정 중 대부분을 ‘사실’로 인지하고 문제를 해결하려고 했어요. 결국 디자인 단계에서 채워지지 않은 근거나 이해하기 어려운 논리를 발견하고 다시 처음으로 돌아가고는 했어요.

실수 2 – 모든 것을 이해하려고 하기

‘개념부터 완벽히 이해하면, 답은 저절로 찾게 될 거야’

대한민국에서 교육과정을 겪었던 분이라면, 꼭 한번은 들었던 이야기일 것 같아요. 제가 당시 선택했던 전략이었고, 틀린 방법은 아니라고 생각해요. 하지만 저를 기다리는 동료들과, 그 상황에서도 커져가고 있을 문제를 두고 여유롭게 학습하는 것은 비효율이었어요. 당시 저는 이 상황을 이해하지 못하고, 데스크 리서치를 필요 이상으로 갖기 시작했어요. 무엇부터 이해해야 할지 모르니 전부 다 이해해 보겠다는 마음이었죠. 논문까지 찾아보며, 시간 비용을 그대로 낭비하고 있었어요.

이 문제를 해결하지 않으면 계속해서 병목이 될 것 만 같았어요. 항상 억지로 이해하고, 길게 다시 돌아가서 전제를 바로잡거나, 설명자의 주관적인 판단은 반박 or 싱크를 했어요. 혹은 대차게 실패를 경험한 후에 깊은 회고를 하기도 했죠.

이런 식으로 문제가 될 때마다 돌아가는 방법은 제 문제를 본질적으로 해결해 주지는 못했어요. 저는 되돌아가기 보다 나아가고 싶었기 때문인 것 같아요. 과거의 경험들을 바탕으로 문제를 정의하고 해결할 가설을 세웠어요.

가설

‘온보딩, 싱크, 일을 동시에 할 수 있지 않을까?’

처음부터 모든 것을 이해하기보다 필요한 것부터 이해할 방법을 찾고, 설명을 들으며 동시에 그 정보를 검증하는 것. 그리고 일까지 함께 할 방법이 있을 것 같았어요. 그리고 그 가설을 여러 방법으로 실행에 옮겨 보았어요.

해결책

1. 내가 모르는 부분을 관찰해 줄 조력자 만들기

처음부터 모든 것을 이해할 수 있는 것은 비효율임을 인정하고, 필요한 정보부터 이해할 필요가 있었어요. 하지만 제게 필요한 정보를 어떻게 찾을 수 있을까요? 초심자는 자신이 무엇을 모르는지 조차 알 수 없어요. 이에 도움받기 위해서는. 내 무지 상태를 지속적으로 관찰해 줄 조력자가 필요했어요. 동료를 활용한 메타인지인 것이죠. 동료들도 제게 기대하는 결과가 있기 때문에, 현재 상황에서 필요한 정보부터 강조하여 말해줄 가능성이 높아요. 이때는 몰랐지만, 이 방식이 토스의 코어 밸류인 Learn Proactively의 일환임을 알게 됐어요.

2. 들은 내용 그자리에서 직접 설명해보기

앞서 말씀드렸던 ‘설명 받는 정보에 오류가 있거나 개인의 생각이 담겨있을 때’의 어려움과 내가 모르는 부분을 더 발견할 수 있는 방법이에요. 저는 온보딩 중에 제가 직접 다시 설명해 보기로 했어요. 화이트보드를 이용해서요. 학생인 제가 직접 가르치는 입장이 돼보는 것이죠. 이 방식은 유대인의 교육 법인 ‘하브루타’와 유사한 방식이었어요.

*하브루타 – 짝을 이뤄 서로 질문을 주고받으면서 공부한 것에 대해 논쟁하는 정통 유대교 교리를 공부하는 유대인의 전통적인 토론 교육 방법

이 방식으로 제 생각과 설명자의 주장에 싱크를 맞추어 ‘정보의 오류’나 ‘가치 판단 영역’을 구분할 수 있었어요. 대부분 제 설명에서 부족한 정보는 바로바로 채워주시고, 논점이 발견되면 그 자리에서 이야기하고 싱크 할 수 있게 됐어요. 덧붙여서 이때 ‘설명이 막히는 곳’, ‘반박 당하는 곳’을 놓치지 않고 이야기하는 것이 중요한 것 같아요. 몰랐던 부분일 확률이 높고, 논쟁을 벌어야 하는 영역일 가능성이 높아요.

3. 틀릴 것을 전제로 디자인하기

아마도 2번이 제대로 진행된 이후라면 대부분의 제품디자이너 머릿속엔 어떤 그림이 나오기 시작할거에요. 2번 이후 간단히 문제와 가설을 정의한 후, 이해한 버전을 그대로 그림을 그려 관계자와 사용자에게 보여주는 방법이에요. 이전에 서로 이해가 달랐던 부분을 디자이너의 그림을 통해 빨리 맞춰갈 수 있어요.

제 경험상 이 때 나왔던 그림이 완전히 틀렸던 경우는 한번도 없었어요. 1~2번의 과정을 거쳐오며 많은 부분 싱크가 되었기 때문이죠. 수정하거나, 고민해야할 부분은 일부였고 전반적인 얼개는 맞았던 기억이 있어요. 이렇게 되었다면, 일은 거의 동시에 진행된거라 보아도 무관할 것 같아요.

결과

가설을 세우고, 새로운 방식으로 도메인을 이해하기 시작한 후와, 과거를 비교해 보았어요. 먼저 온보딩부터 첫 디자인 단계를 만나는 시점이 앞당겨졌어요. 그리고 다시 돌아가기보다는 나아가는 방식이 되었죠. 대부분의 단계를 동시에 하게 되니. 절대적인 시간도 줄어들고, 길었던 데스크 리서치 기간도 상당 부분 줄어들게 됐어요. 가장 좋았던 것은 오류 없는 가설로 만든 디자인을 사용자에게 더 빨리 테스트해 볼 수 있다는 점이었어요.

복잡한 도메인을 맞닥뜨리는 작업자라면 누구나 막막함을 경험하셨을 것 같아요. 이런 부분들을 적극적으로 채워주실 수 있는 동료분들이 있고, 몇 가지의 방법만 활용한다면 어떤 도메인을 만나도 필요한 정보를 빠르게 습득할 수 있을 것 같아요.

특히나 데이터 정합성이 중요한 도메인이라면, 초기에 얻은 정보에 bias가 생기지 않도록 관계자와 최대한 싱크를 하는 것이 중요한 것 같아요. 정확히 싱크 되지 않은 채로 탄생한 디자인은 결국 사용자의 문제를 뾰족하게 해결할 수 없게 되고, 개선하는 데에 많은 시간이 걸리게 되기 때문이에요.

적용해보기

진행하기 전에 꼭 염두 해야 할 점.– 모든 정보들이 ‘가치 중립적’인지 생각해 보기.– 많은 것을 이해하기 보다 필요한 것부터 이해하기.

1. 내가 모르는 부분을 관찰해줄 조력자 만들기.
   • 식사, 커피챗처럼 캐주얼한 자리에서 예고하기.
   • 팀 내에서 직무별로 조력자 만들기. (도메인, 테크)
   • 예 : ‘데이터 구조에 대해 모르는 것이 많아요. 앞으로 자주 물어보게 될 것 같은데 괜찮을까요?’ → 99%는 “언제든지 물어봐 주세요!”라고 답변 받음.
2. 들은 내용. 그자리에서 직접 설명해보기
   • 설명이 틀릴까 봐 긴장된다면, 말하기 전에 양해 구하기.
   • 예 : “처음 듣는 정보들이라, 많이 틀리겠지만. 들은 내용들을 설명해 볼게요.”
3. 틀릴 것을 전제로 디자인하기
   • 생각이 다른 부분을 중점으로 이야기달라고 말하기.
   • 이 디자인은 완성된 것이 아님을 공유하고, 논의 시작하기.

자꾸만 되돌아가게 되는 단계, 방대하고 어려워보이는 도메인 때문에 어려움을 겪고 계신다면, 이 방법들을 사용해보시면 어떨까요?