토스 최초의 Product Designer(Tools)의 일하는 방식

저는 2020년 초부터 토스팀 최초의 Product Designer(Tools)로 일하기 시작했어요. 새 직무를 만들어 가면서 배운 점을 들려드릴게요.

Product Designer(Tools) 직무가 뭐예요?

Product Designer(Tools)라는 직무가 생소하실 텐데요. 토스에서 기존에 Internal Product Designer라는 직무명으로 알려져 있어요. 제품 경험을 책임지는 Product Designer 중에서도 업무용 툴을 만드는 일에 집중하고 있어요. 토스 팀원이나 저희 고객들이 업무시간 동안 많은 일을 정확하고 빠르게, 효율적으로 할 수 있도록 돕는 역할이지요. 저희가 만드는 도구를 이용해 업무시간에 하는 불필요한 일을 최대한 줄이고 더 중요한 일에 집중하도록 돕고 있어요. 반복되는 일을 자동화하거나 더 효율적인 워크플로우를 제공해서 사용자가 더 중요한 일에 집중하도록 만드는 것이 이 직무로 일하면서 얻는 보람이에요. ChatGPT 같은 생성 AI의 등장 때문에 업무 효율화에 대해서 공감대가 생겨서 반가운 요즘이에요.

저희 직무 팀원들의 자세한 얘기를 보고 싶으시면 Simplicity 23, Simplicity 21의 스토리를 봐주세요.

• 사용자의 공감 얻으면서 제품 뜯어고치기 (오지은 님)
• 100가지 문제를 한번에 해결하는 방법 (하승주 님)
• 3,250개의 요구사항을 해결한 1개의 제품 (윤종구 님)
• 우리가 효율적으로 일할 수 있는 이유 (강영화 님)

처음 시작한 이야기를 들려주세요.

‘아, 여기 디자이너 없어서 진짜 큰일났네’

2020년 초 업무 생산성 담당하는 팀에서 일하면 어떻겠냐는 제안을 받았어요. 최초의 디자이너로 일하는 거죠. 솔직히 매우 빡셀 것 같아서 고민이 되기도 했어요. 하지만 임팩트의 크기가 클 거라고 생각해서 가기로 결정했어요. 제가 낼 수 있는 임팩트의 크기가 0 to 1 단계, 그러니까 아무것도 없는 시작하는 단계에서 극대화될거라고 생각했죠.

팀을 옮기고 처음 일을 시작했는데, 최초의 디자이너로 일하는 일은 생각보다 더 힘들었어요. 일단… PC 환경에서 쓰는 TDS(토스에서 쓰는 디자인 시스템)도 없다시피 하고, 디자이너 1명에 10명의 풀스택 엔지니어가 있는 등, 생각보다도 더 열악한 환경이었어요. 그래서 어떻게 일할지를 정의하는 일을 먼저 했어요. 그러면서 배운 점이 정말 많았어요. 일하는 방식에 대해서 관심을 많이 가지면서 배움이 극대화됐고요.

크게는 세 가지를 배웠어요.

1. 기초공사의 중요성
2. 팀 구성에서 디자이너의 역할
3. 어떻게 일하는 게 잘 일하는 걸까

기초 공사의 중요성

TDS를 활용할 수 없는 거의 없다시피한 환경이었어요. TDS 없이 디자인한다는걸 토스 디자이너는 상상조차 하기 어려운데요. 초반에는 디자이너가 없고, 심지어 PC 제품 디자인하는 사람도 전사에 저 혼자였기 때문에 힘들었어요. 디자인 QA도(UI 디자인이 잘 구현됐는지 점검하는 일) 해야 했으니 업무 시간은 부족하고 이걸 왜 해야 하나 현타도 왔어요. 저는 모바일 TDS를 썼던 경험이 있으니, 그것과 자꾸 비교되더라고요. TDS PC의 기초공사를 하는 과정에 참여했어요.

그래서 당시 플랫폼 디자이너였던 강수영 님을 찾아갔어요. 수영 님과 원래 있던 없다시피했던 PC 디자인 시스템의 초안을 가지고 어떤 걸 자주 쓰는지, 컴포넌트별로의 최소 요구사항을 정의하고 시스템에 적용하고 제품에 구현하는 걸 시간 내서 진행했어요.

이렇게 기초공사를 한 벌 끝내고 나니까 당연하게도 업무 효율이 늘어났어요. 효율을 높이기 위해는 가장 작은 단위로 쪼개고 그것부터 점검하고 처리해야한다는 걸 적용해 본 시간이었어요. 시스템의 힘을 체감하기도 했고요!

팀 구성에서 디자이너의 역할

또, 한 개의 팀이 어떤 구성을 갖춰야 하는지에 대해서도 배웠어요. 업무용 툴도 디자이너의 역할이 매우 중요해요. 보통 회사에서 백앤드만 있는 어드민 제품은 디자이너 없이 PM이나 PO와 엔지니어분들끼리 착수하잖아요? 디자이너 없이 하면 더 빨리 할거로 생각하는 의사결정인 거죠. 그런데 디자이너가 없으면 쉽게 갈 길을 더 돌아가게 되더라고요.

디자이너 없이 만든 제품의 모양이 이렇다면,

디자이너가 처음부터 투입되기 시작하면 이런 도표로 그릴 수 있어요.

제가 팀에 합류하기 전 엔지니어분들이 디자이너 없이 만들어 두신 제품과, 디자이너가 투입되고 처음부터 만드는 제품의 걸린 시간을 비교하면 극적으로 달라졌어요. 고객에게 잘 닿으면서도 빨리 만들어냈어요. 사용자에 대한 이해도가 높은 상태로 디자인을 하기 때문에 점점 불필요한 일을 줄이고 사용자들도 만족하는 제품을 내보냈고요. 저와 인터널 팀의 시행착오가 전사에 큰 도움이 된 것 같아요.

어떻게 일하는 게 잘 일하는 걸까

시간이 흘러 같은 일을 하는 사람이 두 명이 되면서 2020년 하반기에 직무가 분화된 것으로 기억해요. 직무 자체를 만들어 가는 일, 면접에 참여하는 과정을 통해서도 어떻게 잘 일해야 하는지 배웠어요. 채용 과정에 참여하는 건 면접관에게도 도움이 되는 시간이에요. 우리가 어떤 사람이며, 어떻게 일하며, 어떤 사람과 일하고 싶은지 자꾸 보고 학습하거든요. 혹시 내가 그렇게 일하고 있지 않다면 점검하는 시간이 되기도 하고요. JD(직무 설명)를 여러 번 바꾸면서 어떻게 일해야 하는지 진지하게 고민해보고, 면접 과정에서 그 기준을 다시 생각하며 반복학습 했어요.

이 모든 과정은 토스 앱을 만드는 PD 분들이 아닌 우리 직무에 핏한 분을 뽑을 수 있는 채용의 스펙트럼을 만드는 과정이었죠. 확장하고 넓히고, 더 포텐셜을 발견할 수 있는 질문을 넣었어요. 토론하면서 정말 많은 이야기를 나눴던 기억이 생생해요. 이렇게 스펙트럼을 넓히는 설계를 하면서 역설적으로 인재상이 뾰족해지기도 했답니다.

이 과정을 통해 더 많은 분들을 모실 수 있었어요. PD가 인터뷰를 볼 때보다 저희 직무가 직접 인터뷰했을 때 더 깊은 이해도로 채용할 수 있었거든요.

저 한 명이었던 직무는 이제 챕터로 발전했어요. 15명이 넘도록 많아졌기 때문에 더 자주 양질의 배움을 공유하고 있어요. 우리는 도구를 만드는 일을 하는 사람들이잖아요. 그만큼 도구에 대해서 이야기를 많이 나눠요. 서두에도 썼지만 생성 AI가 등장하고 업계 전반에서 일하는 방식에 대해서 이야기를 나누는 트렌드가 생겼는데요. 요새 함께 나눌 이야기 거리가 정말 많아져서 즐거워요. 산업 전반에 정말 많은 변화가 있을 텐데 앞으로 우리에게 어떤 배움이 있을지 기대 되기도 해요.

당시의 나에게 해주고 싶은 조언이 있다면요?

“더 자주 물어보고 피드백을 받으면 좋겠어요.” 제가 처음 몇 개월 동안 가장 실수했던 건 피드백 받는 걸 두려워했던 거예요.

3년 전으로 돌아간다면 더 자주 피드백 받았을 거에요. 피드백을 자주 받고 빠르게 방향을 수정해서 더 시행착오를 줄이면 좋았겠다는 아쉬움이 있거든요. 피드백 루프가 길어지는 것의 또 다른 단점은 내가 잘하고 있는 점에 대해 피드백 받을 기회도 적어진다는 거예요. 그러면 자기효능감 느낄 기회가 적어져요. 결과적으로 실제 내가 할 수 있는 것보다 퍼포먼스를 못 냈던 것 같아 아쉬워요.

직무든, 프로젝트든 뭐든 처음 하는 건 쉽지 않아요. 근데 처음 하는 일은 “잘”하기 더 어려워요. 하지만 도움을 받기 시작하면 잘하는 상태까지 빠르게 만들 수 있어요. 그리고 예상보다 도움을 주고 싶어 하는 사람들은 많더라고요. 도움을 적극적으로 받기 시작하면서 점점 피드백에 대한 두려움도 없어졌어요.

모르는 길을 헤쳐 나가는 데 두려움이 있으신가요? 동료들과 함께 두려움을 이겨내고 조금씩 앞으로 가면서 성장하는 과정을 함께 밟아가면 좋겠어요. 그러면 그 시간을 커리어에서 잊을 수 없는 날들, 빛나는 순간으로 기억할거예요. 제가 그랬던 것처럼요.