
작은 오해가 만든 큰 비효율
토스에서 계좌를 연결할 때 앞으로 토스로 돈을 받고, 보내는 서비스를 사용할 것이라는 출금이체 동의를 해요. 그럼 은행에서 자동으로 문자가 오는데요. 
처음엔 아무 문제가 없을 것 같았지만, 은행 문자 속 '자동이체'라는 단어가 사용자에게 혼란을 줄 수 있다는 사실을 알게 됐어요. 사용자는 이 단어를 보고 "내 돈이 정기적으로 빠져나가는 건가?"라는 걱정을 하게 되죠. 사실 이 문자는 단순한 확인 절차일 뿐인데도, 사용자 입장에선 이 작은 단어 하나가 큰 불안으로 이어질 수 있었어요.
이 작은 오해 때문에 고객센터로 들어오는 문의가 급증했어요. 대부분은 "자동이체가 시작되는 건가요?"라는 질문이었죠. 사용자가 오해하지 않고, 토스 서비스를 편리하게 이용할 수 있도록 이 문제를 해결해야 했어요. 특히, 2019년부터 고객 문의 상위 3위 안에 들면서, 토스팀원들이 같은 안내를 반복해야 하는 비효율적인 상황이 계속되고 있었죠.



문제를 해결하는데 
프로덕트 디자이너가 아니고, 
플랫폼 디자이너가 한다고?
보통은 제품의 문제를 프로덕트 디자이너가 해결하지만, 이번엔 플랫폼 디자이너가 나섰어요. 플랫폼 디자이너는 디자인시스템만 만드는 게 아니라, 서비스 전반을 살피고 비효율을 찾아서 해결하는 데 중점을 둡니다. 이는 사용자뿐만 아니라, 토스 팀 전체가 효율적으로 일할 수 있도록 돕는 역할을 해요. 
토스팀원들의 비효율을 줄여주고, 사용자들에게 안심 경험을 줄 수 있는 화면으로 개선하기로 했어요.




문제 해결 과정

지금 보는 이 화면은 기존에 계좌 연결 후 보게 되는 화면이에요. 
이정도면 문자가 왔을 때 문자가 갈거라고 미리 안내도 해주고, 문자 내용을 보고 놀라지 말라고 해서 괜찮은 것 같은데 사용자들이 '자동이체'라는 단어에 왜 민감하게 반응하는지를 파악해야 했죠. 





1. 가장 먼저, 있는 그대로를 말하기
첫 번째로 중요했던 것은 사용자의 감정을 먼저 추측하기보다는, 사실 그대로를 전달하는 것이었어요. 토스는 따뜻하고 친근한 말투를 많이 쓰는데, 처음부터 '은행에서 문자가 와도 놀라지 마세요'라는 표현을 하면 오히려 사용자에게 불필요한 걱정을 줄 수 있었어요. 그래서 이번에는 사실 그대로를 전달하기로 했어요. "OO님이 출금이체 동의를 한 몇 개의 은행에서 문자가 발송될 것"이라고요.




2. 어려운 말은 더 자세하게 말하기
다음으로는 ‘자동이체’라는 단어를 쓰면서 더 친절하고 구체적으로 설명했어요. 그리고 감정에 대한 이야기를 했어요. ‘자동이체’ 라는 단어가 사용자에게 불필요한 걱정을 주고 있었기 때문에, 좀 더 명확하고 안전한 느낌을 주는 문구를 추가했죠. "이건 자동으로 돈이 빠져나가는 게 아니에요. 당신의 돈은 안전해요!"라고 말이죠. 또한, 자동이체가 무엇을 의미하는지도 상세히 설명했어요.
토스에서는 퍼널의 길이가 짧을수록 좋다는 러닝이 있었지만, 이번엔 그 러닝을 넘어 사용자에게 더 자세히 알려주는 것이 필요하다고 판단했어요. 내 돈이 빠져나갈 수도 있다는 불안을 안심시킬때는 너무 축약하기보다는, 사용자가 완전히 이해할 수 있도록 상세히 전달하는 것이 중요하다고 생각했거든요. 




3. 중간에 문자가 와도 다 읽을 수 있게 하기
마지막으로 문자 도착 시간에 집중했어요. 은행에서 문자가 발송되는 데는 최소 2초에서 최대 15분까지 걸릴 수 있어요. 사용자가 안내 화면을 보고 있는 동안 문자가 도착하면, 화면 상단에 푸시 알림이 안내 내용을 가려버리기 때문에 사용자가 내용을 볼 수 없어요. 그래서 제목과 전체 내용을 아래로 조금 내려서 문자메세지가 와도 끊김 없이 모든 내용을 볼 수 있는 디테일을 추가했어요.





결과와 배운 점
이렇게 만든 디자인을 바로 구현해서 문의량을 측정해기로 했어요. 
그 결과는 놀라웠어요. 이전에는 월평균 3,173건이던 문의가 무려 446건으로 줄어들었죠. 이 숫자는 단순한 통계 이상의 의미를 가지고 있어요. 플랫폼 디자이너가 토스팀의 효율성을 높이는 데 얼마나 큰 기여를 할 수 있는지 보여주는 사례였어요. 
마지막으로, 사용자에게 신뢰를 줄 수 있는 디자인이야말로 가장 중요한 디자인이라는 점을 강조하고 싶어요. 때로는 설명이 조금 길어지더라도 사용자가 충분히 이해할 수 있게 하는 것이 중요해요. 감정을 먼저 읽기보다는 사실 그대로를 전해주는 것이 가장 첫번째로 알려줘야 큰 안심을 줄 수 있고, 그 결과 서비스 전체에 긍정적인 영향을 미칠 수 있답니다.






작은 오해가 만든 큰 비효율
토스에서 계좌를 연결할 때 앞으로 토스로 돈을 받고, 보내는 서비스를 사용할 것이라는 출금이체 동의를 해요. 그럼 은행에서 자동으로 문자가 오는데요. 
처음엔 아무 문제가 없을 것 같았지만, 은행 문자 속 '자동이체'라는 단어가 사용자에게 혼란을 줄 수 있다는 사실을 알게 됐어요. 사용자는 

플랫폼 디자이너가 고객문의량 상위 3위에 들었던 비효율 문제를 해결했던 방법을 알려드릴게요.

비효율이 있는 곳엔 플랫폼 디자이너가 있다 

배경
토스 디자인 시스템에서 가장 많이 사용하는 컴포넌트는 테이블이에요. 테이블은 크게 두 가지를 고려해야 하는 복잡한 컴포넌트예요. 테이블을 구성하는 최소 단위인 셀, 그 셀들을 합쳐 만든 표. 각각을 사용하는 경우의 수를 고려하면 구현 난이도는 무한대로 높아져요. 
우리가 흔히 표를 만들 때 쓰는 엑셀은 말 그대로 표를 만들기 위해 만들어진 에디터 솔루션이기 때문에, 셀과 표를 처음부터 고려해서 만들어졌어요. 하지만 우리가 사용하는 대개의 디자인 에디터 툴들은 테이블 만을 위해 만들어진 솔루션이 아니기 때문에 컴포넌트 기능과, 테이블 제작 사용성 두가지 모두를 한번에 고려하여 반영 하는데에 한계가 있습니다. 그래서 토스의 초기 테이블은 (이하 테이블 1.0) 최소 구성 단위인 셀 형태의 컴포넌트로 구성되어 있었어요.


문제
테이블 컴포넌트는 표를 구성하는 작은 단위의 셀을 의미 하기도 하고. 큰 덩어리인 표 단위를 의미하기도 해요. 
TDS의 테이블 컴포넌트 역시 이를 모두 커버하기 위해 셀 단위의 기능과, 표 단위의 제작 사용성 솔루션이 필요로 했어요. 토스 팀에서는 제품에서 사용하는 형태에 따라 테이블 컴포넌트가 가지고 있어야 할 기능과 요구 되는 사항들은 천차만별로 달라서 여기에 다 쓸 수 없을 정도로 다양한 케이스를 다뤄야 했죠. 저희 팀은 그런 셀의 경험을 개선하는 것만으로도 정신이 없었어요. 


이렇게 셀의 기능이 대부분 채워갈 무렵, 자연스럽게 표 제작에 대한 사용성 관련한 문제들이 수면 위로 드러나기 시작 했어요. 테이블을 구성하는 최소 구성단위인 셀 기능만 포함 된 컴포넌트로 패턴 단위의 표를 만드려면 이런 과정을 거쳐야 했어요. 





우리는 이미 표를 만들기 위해 사용하는 엑셀과 같은 툴에 익숙해져있으니, 보기만 해도 너무 불편하다는 걸 느끼실 거예요. 실제로 PC 화면을 디자인하는 분들도 많은 피드백을 주셨고요.
👤 테이블을 내가 왜 이렇게 만들어야 하나…
👤 하나하나 쌓아 만드는거 너무 짜친다… 현타 온다
👤 다 모르겠고 누가 만들어 놓은거 복붙 해서 쓰는게 편해요


가설
하지만 앞에서 말씀 드렸듯이, 디자인 툴은 테이블을 만들기 위해 제작 된 에디터가 아니기 때문에 문제를 해결 하는데에는 기술적인 한계가 존재 했어요. 그래서 처음에는 지금 메이커들이 겪고 있는 문제 중 치명적인 비효율을 만드는 요소들을 제거 하는 것 부터 시작하자! 하고 반복되는 문제 패턴을 찾았죠. 예를 들면 이런 것들이 있었어요.
간단한 표를 구성하기 위해 필요한 툴과 관련된 사전 지식들
fixed ↔ fill ↔ fit-content
표를 만들고 난 후에도 필요에 따라 잦은 데이터 수정이 필요한 컴포넌트의 특수성
각 셀 마다 가지고 있는 패널 설정을 찾아 수정하는 과정이 번거로움 
열, 행 구성에 따라 제작 된 표는 추후 수정이 어려움

위와 같은 문제들을 테이블 베타라는 이름의 솔루션으로 개선하고 난 후, 단순한 리스트형 테이블을 쉽게 만들 수 있게 되었지만 아무리 이전보다 나아졌다고 해도, 툴에 종속되어 해결 된 솔루션이라 매우 제한적인 해결방법으로 도출 되어 제작 사용성을 완전히 해결했다고 보기 어려웠어요. 여전히 테이블 만을 위해 제작 된 솔루션들의 경험과 비교하여 생각한다면 불편하다고 생각할 수 밖에 없었죠.
이제는 컴포넌트의 경험을 개선하는 것을 넘어서, 디자이너분들이 실제로 어떻게 사용하는지 과정 전체에 대한 이야기를 듣고, 본질적인 사용 방식을 개선해야 겠다는 생각이 들었어요. 그래서 작업 방향을 잡기 위해 디자이너분들을 찾아가 심층 인터뷰를 하면서 테이블을 사용하시는 행태를 꼼꼼하게 조사했어요. 
이를 위해 가용 가능한 개발 리소스를 확보하고 설문+UT를 통해 3가지 방향성을 도출 했어요.

제로 베이스의 제작을 하지 않아도 되게 만든다
표 자체를 완성하는 환경을 쉽게 한다
잦은 수정이 일어나는 상태를 쉽게 수정하게 한다



UT, POC를 통해 차츰 방향성을 잡아 가면서 메이커들과 이격을 줄이는 작업들이 병행 되었어요. 


이렇게 정밀 진단을 통해 꼭 해결해야하는 큰 맥락을 설정해보니, 툴의 한계를 벗어나 빌더 수준의 완전히 새로운 형태의 제작이 필요하다는 판단을 하게 되었어요. 문제 해결의 한계를 만들고 있는 툴의 환경을 벗어나 사고 하고 해결책을 찾아야겠다 생각 했죠. 하지만 툴을 벗어나 해결책을 찾더라도 결국 툴 내부에 솔루션을 심어야 했기 때문에 완전히 환경을 벗어나긴 어려웠고 이에 우리는 크롬 플러그인을 활용하여 프레이머라는 툴 내에 붙여 활용 할 수 있는 방법을 찾아 활용해 보게 되었어요.



해결책
컴포넌트 단위의 솔루션이 아닌 에디터를 만드는 수준의 솔루션을 설계해야 하는 상황이었지만 완전히 바닥부터 시작하기엔 우리에게 주어진 시간이 많지 않았기 때문에 리소스를 효율적으로 쓰는 것이 가장 중요했어요.

메이커 리소스 및 물리적인 작업 환경 확보하기
한명의 개발자로 문의 대응과 테이블 혁신까지 이뤄내야 했기 때문에 응급 상황 제외 문의 최대한 손 떼고, UXE Assistant + Platform designer 조합으로 개발 구조체를 변경하지 않는 선의 간단한 대응을 모두 위임하는 등 한명의 개발자로 테이블 2.0을 만들어야 하는 상황에 필요한 물리적인 환경을 구축 하는데 신경 썼어요.

빠르게 도달 할 수 있는 방법 시도 하기
문제를 해결 하기 위해 방향성이 설정 되었다면 이제 달려나가야겠죠? 제로 베이스에서 시작하기에 리소스 및 시간이 턱 없이 부족 하다면 기반이 되어줄 타 제품을 찾아보고 무료 소스를 적극 차용하는 것도 좋은 방법이 될 수 있어요. 테이블만을 고민하고 솔루션을 구축해온 AG grid 라는 제품을 차용해 유료 기능을 제외한 무료 기능들을 가져와 뼈대를 만들고, 이후 필요한 기능들을 직접 개발 하면서 2.0의 모습을 갖춰나갔어요. 토스에서 필요한 기능들과 프레이머라는 환경을 고려해야 했기에 거의 새로 만드는 수준 이었지만 AG grid를 통한 뼈대를 구축하는 과정이 문제 해결 속도를 높이는데 큰 도움이 되었어요.


빠르게 검증하기
테이블 베타를 통해 성공적인 임팩트를 도모하지 못했던 것은 제작 과정에서의 검증을 놓쳤기 때문이라 생각했기 때문에 주어진 기간이 매우 짧아 검증할 시간이 충분하지 않더라도 실패를 줄이기 위해서는 무조건 진행하기로 했어요. 주 단위로 스프린트를 구성하여 스펙 구현 과 메이커 UT를 동시에 진행 하면서 제품을 실시간으로 깎아 나갔어요. 이 과정에는 한몸이 된 것처럼 밀도 있는 커뮤니케이션이 필수적이에요. 이 과정들을 통해 해결 해야하는 문제가 클 수록 투자 해야할 시간이 길어져 자칫 늘어질 수 있는 호흡을 잡아주는 역할도 할 수 있어요.




결과
그렇게 충분하지 않았던 리소스로 엄청난 효율을 추구하며 만들어낸 결과, 테이블 1.0과 비교했을 때 완전히 다른 방법으로 개선된 2.0이 나왔죠. 테이블2.0은 표 제작 및 생성 하는데 필요한 사용성을 개선 대부분 개선 할 수 있었어요. 특히 잦은 벨류 수정이 필요했던 케이스를 대응 할 수 있어 큰 반응이 있었어요. 
첫 배포 이후에도 필요로한 추가 기능들을 지속적으로 배포 하면서 테이블을 제작하는데 필요로한 기능들을 대응 했어요.










PD분들의 반응도 열광적이었어요.





적용해보기
문제의 근원을 해결하기 위해 시도했던 다양한 시도들을 통해 우리는 아래와 같은 러닝을 얻게 되었어요.
Question every assumption : 근본적인 해결을 위해 다시 사고하는 과정이 느려보여도 가장 빠른 해결책이 될 수 있어요
특히 시스템 관련해서 컴포넌트와 관련한 문제를 마주 하다보면 당장 산재한 문제들을 빠르게 해결하기 위해 정신 없이 1:1 대응 형태로 문제 해결을 하게 되는데요. 느리더라도 문제를 해결 하기 위해 근원적인 물음들을 제기 하면서 근본적인 문제를 해결을 위한 사고 과정에 시간을 투자 해보세요. 이 문제가 진짜 문제인지, 이 해결 방법으로 해결 할 수 있는 문제는 무엇인지 등 당연 했다고 생각한 것들에 질문하고 처음부터 다시 사고 하는 과정을 거치다 보면 근본의 가정까지 파고들어가 사고 할 수 있어요. 이렇게 느리지만 가장 빠른 해결책을 찾는 과정을 통해 여러 문제를 혁신적으로 해결 할 수 있을거에요. 한번의 시도에 완벽한 해결을 만들 수 없기 때문에 이 과정을 반복하는 것을 추천 드려요. 
Ask for feedback : 성장하는 시스템은 주요 원동력은 피드백이다
잘 만들어진 시스템은 잘 사용 되는 시스템이에요. 그렇기 때문에 메이커들의 솔직하고 주기적인 피드백이 중요해요. 시스템은 이를 사용하는 메이커들의 피드백을 통해 성장하고 고도화 되는 성장형 솔루션이어야 합니다. 때문에 우리는 시스템을 제작 하는 과정도 중요 하지만 의도 한대로 잘 작동 하고 있는지 지속적인 트래킹 하는 과정을 필수로 진행하고 있어요. 
사용자가 늘 적극적으로 피드백을 주지 않을 때에는 시스템이 의도대로 잘 작동하고 있구나 안심하지 말고 직접 찾아 다니면서 집착적으로 피드백 받고 문제를 발굴 하는 것도 중요해요. 시스템을 만드는 과정이 벅차서 이 부분을 놓치게 되면 언젠가 눈덩이처럼 커져버린 문제를 마주하게 될지도 몰라요. 
Focus on Impact : 혁신적인 임팩트를 생산 하기 위한 집중과 물리적인 확보는 반드시 필요하다
해야할 일은 사라지지 않고 문제는 늘 많은데 어떻게 혁신적인 임팩트를 생산 할 수 있을까요? 모든 문제를 해결 할 수 없다는 것을 인지하고 해결 하고자 하는 문제에 집중하여 몰입하는 과감한 투자가 필요해요. PC 시스템 팀에서는 PC TDS가 해결해야 하는 문제들 중 테이블과 관련한 문제가 가장 큰 이슈이자 풀기 어려운 숙제라고 판단했고, 2.0 이라는 솔루션을 만들어내기 위해서 매일 대응 하고 있는 시스템 운영 및 대응, 신규 컴포넌트 생산과 같은 업무를 줄여 리소스를 물리적으로 확보 하고자 했어요. 
완전히 끊어내고 몰입할수 있는 환경이라면 가장 좋겠지만, 시스템 팀은 토스 전 조직 대상으로 움직이는 팀이기 때문에 완전히 업무를 중단하기 어려웠어요. 하지만 테이블2.0을 만들어 내려면 리소스 확보가 꼭 필요했습니다 개발자가 1명 이었으니까요. 어려운 환경에 있더라도 방법은 어떤 형태로든 찾을 수 있습니다. 많은 일을 한꺼번에 처리하긴 어려워요. 집중 할 수 있는 환경과 기간을 설정하고 과감한 시도를 통해 문제를 해결 해보세요!

눈 앞의 문제들을 해결했음에도 여전히 불편함이 남아있다면, 본질적인 문제를 다룰 수 없을지 확인해보세요. 너무 당연했던 전제를 바꿀 수 있다고 상상해보면 완전히 다른 해결책이 떠오를 거예요.



배경
토스 디자인 시스템에서 가장 많이 사용하는 컴포넌트는 테이블이에요. 테이블은 크게 두 가지를 고려해야 하는 복잡한 컴포넌트예요. 테이블을 구성하는 최소 단위인 셀, 그 셀들을 합쳐 만든 표. 각각을 사용하는 경우의 수를 고려하면 구현 난이도는 무한대로 높아져요. 
우리가 흔히 표를 만들 때 쓰는 엑셀은 말 그대로 표

토스 디자인 시스템에서 가장 많이 사용하는 컴포넌트인 테이블 컴포넌트. 문제의 근원을 해결하기 위해 시도했던 다양한 시도와 러닝을 소개합니다.

문제의 근원을 해결 하기 위한 다양한 시도


저번 아티클에서 메뉴 컴포넌트 추가를 위해 가설을 세우고 실험했던 과정을 소개해 드렸어요. 이 방법으로 유용성이 검증되어 빠르게 새 컴포넌트를 결정해 출시할 수 있었답니다.
1편 보고 오기 >

문제
그러나 점차 새 컴포넌트가 대응할 수 없는 케이스들이 발견 되기 시작했어요. 컴포넌트를 사용할 수 있게 된 뒤 많은 디자

디자인 시스템은 제품의 어느 단계까지 기여할 수 있을까요? 더 이상 다른 것에는 신경쓰지 않아도 되는 Menu 컴포넌트를 만들었던 3가지 방법을 소개할게요.

토스 디자이너가 제품에만 집중할 수 있는 방법



이 화면은 토스 앱에서 여러 가지 옵션을 선택하는 방식이었어요.
어떤 문제가 있는지 느껴지시나요?
1️⃣ 잘 모르겠다.
2️⃣ 알 것 같다.

1번, 2번, 선택 안 하신 모든 분들! 어떤 문제가 있는지 알려드릴게요. 



바로 ‘물리적 거리 사용성’인데요
화면 위에서 버튼을 누른 후 아래에서 올라오는 바텀시트의 버

플랫폼 디자이너가 디자인 시스템에 새로운 컴포넌트를 만들 때 생기는 의심을 확신으로 만든 과정을 들려드릴게요.

이런 것도 컴포넌트로 만들어도 될까?

토스에는 디자인 플랫폼 팀이 있고, 그 안에 플랫폼 디자이너라는 직군이 있어요. 플랫폼 디자이너는 무슨 방법을 써서라도 메이커의 디자인 작업 과정의 비효율을 효율화하는 사람이에요. 디자인 시스템을 만들기도 하고, 디자인 툴을 바꾸기도 했죠.
오늘 소개해드릴 프로젝트는 툴을 바꾸면서 새로운 환경에 맞게 작업 과정을 효율화했

수많은 가짓수들을 단순히 더하기로 추가하는 것이 아니라 곱하기로 확장하면서 극단적인 효율과 심미성까지 챙겼던 과정들을 플로우차트 제작 프로젝트를 예시로 소개해드릴게요.

플랫폼 디자이너가 효율을 만들어내는 법


모닥불 10화 특집: 캠프파이어 에피소드 🔥
이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요.
"좋은 테스트 코드라고 하는 것은 무엇일까요?"
"ESLint Rule, 꺼도 괜찮을까요? 더 좋은 해결책은 없을까요?"
"useEffect, dependency 배열, 이렇게 설정해보세요!"
사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지!
토스 개발자들이 실무 경험에서 얻은 노하우와 인사이트를 아낌없이 공유합니다!  지금 바로 확인해보세요!

타임스탬프
00:00 인트로
00:46 첫 번째 코드 리뷰: 좋은 테스트 코드의 기준은?
02:50 ”it”절에 어떤 내용을 담아야 할까요?
04:48 단독으로 테스트 하기 어려운 경우
05:10 두 번째 코드 리뷰: Lint rule을 항상 지켜야만 하는 걸까요?
06:41 useEffect, dependency 배열이 고민이라면
09:39 모닥불 10화 특집: 캠프파이어 에피소드를 마무리하며

출연진
박서진, 토스 Head of Frontend
문동욱, 토스 Frontend Developer
박건영, 토스증권 Frontend Developer

Slash 라이브러리? 
; 토스에서 사용하는 TypeScript/JavaScript 패키지
@toss/react 패키지
usePreservedReference 
usePreservedCallback

다른 모닥불 회차 보러가기
EP.8 Next.js 그만 쓰세요! 면접관이 진짜 원하는 것!?
EP.9 프론트엔드 서비스 최적화? 토스에서는 '이렇게' 합니다!
EP.10 캠프파이어 특집 하편 | 무엇이든 물어보세요 (feat. 프론트엔드 코드, 디렉토리 관리)




모닥불 10화 특집: 캠프파이어 에피소드 🔥
이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요.
"좋은 테스트 코드라고 하는 것은 무엇일까요?"
"ESLint Rule, 꺼도 괜찮을까요? 더 좋은 해결책은 없을까요?"
"useEffect, dependency 배열, 이렇게 설정해보세요!"
사전에 접수된 

모닥불 10화 특집: 캠프파이어 에피소드 🔥
이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요.

사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지!
지금 바로 확인해보세요!

무엇이든 물어보세요 (feat. 테스트 코드, ESLint Rule) | EP.10 캠프파이어 특집 하편

이번 토스 피플에서는 Design Strategy Lead 김유라님의 인터뷰를 공유드려요. 유라님은 브랜드 디자이너로 입사해, 프로덕트 브랜딩 팀에서 추석 토끼, 눈사람 기부 이벤트, 장애인의 날 점자 카드 이벤트 등 다양한 시즈널 제품을 만들고, 오늘의 운세 제품을 리딩하셨어요. 지금은 시각 장애가 있는 사용자들을 위한 접근성 프로젝트에 몰입하고 계시죠. 프로젝트는 다양하지만, 이들을 관통하는 공통점은 지표를 중요하게 생각했던 토스에서 ‘정성적 경험’의 가치를 끌어올렸다는 점이에요.



Q. 유라님은 토스에 브랜드 디자이너로 입사하셨다고 들었어요. 언제부터 브랜딩에 관심을 갖게 되셨어요?
원래는 광고를 하고 싶었어요. 그래서 첫 회사로 광고 회사에 인턴으로 취업을 했었죠. 기대했던대로 크리에이티브한 아이디어를 계속 생각하고 스토리를 부여하고 이런 게 너무 재미있었거든요? 그런데 언제부터인가 만들어진 제품을 홍보하는 것이 아닌 제품 자체를 만드는 일에 가까워질순 없을까?라는 고민이 들었어요. 그러던 차에 브랜딩이라는 분야를 알게 됐죠.



Q. 아, 그럼 그 다음 회사는 브랜드 디자이너로 입사하시게 됐나요?
맞아요. 사실 회사가 교육 출판 쪽이어서 도메인이 제 관심사가 아니긴 했는데, 신입 공채가 진짜 어렵잖아요. 그래서 일단 합격했으니까 가보자! 하는 마음으로 갔었죠. 그런데 가보니까 회사가 브랜딩을 크게 중요시하는 분위기가 아니었고, 디자인 방향성도 공감하기가 어려웠어요. 그곳에 적응하는게 너무 힘들었는데, 신입이라 이직이나 재취업도 힘들 거고, 제게 맞는 일이나 회사에 대한 기준도 없어서 어떻게든 버텼어요. 그런데 무조건 버티기만 하는 게 답은 아닌 것 같더라고요. 결국 나오게 됐죠. 



Q. 지금 돌이켜 보면 그렇게 생각해도, 당시에는 엄청 고민했을 것 같아요.
맞아요. 실제로 그때 퇴사하고 엄동설한에 바닥에 내팽겨쳐져서 6개월 동안 취업 준비만 했거든요? 참 막막했죠. 아침에 눈 뜨면 카페 가서 포트폴리오 준비하고 카페 문 닫을 때 같이 나오고… 너무 힘들었지만 다음 단계를 준비한다는 마음으로 이어갔던 것 같아요.
그 때 가장 크게 배운게 있어요. 제가 그때까지만 해도 진짜 차가운 대문자 T였거든요. 힘들다고 내색도 잘 못했어요. 근데 자꾸 제 이야기를 들으면서 우는 친구가 있었어요. 제가 너무 힘들 것 같다면서... 그 친구 덕에 그 시기를 버틸 수 있었던 것 같아요. 실질적인 해결책을 주지 않아도, 공감만으로도 많은 위안과 용기를 줄 수 있다는 걸 그때 처음 알았어요. 사람의 마음을 움직이는 건 결국 애정과 공감이라는걸요. 그리고 대문자 F로 바뀌게 됐죠.

Q. 그 시기의 경험이 지금 하시는 업무와도 연결되는 것 같네요. 어쨌든, 결국 취업에 성공하셨어요.
진짜 너무 좋았어요. 사실 그때 다들 저한테 원하는 곳은 가기 힘들거라고 했거든요. 그 회사가 요구하는 포지션이 경력 3년이상 이기도했고요. 그런데도 합격을 해버린 거예요. 결국 ‘세상에 예외는 있구나’, ‘열심히 하면 되는구나’라는 걸 깨달았어요.
한 편 새로 입사하게 된 회사가 어떤 면에서 구원자이기도 했지만 또 마냥 좋기만 하진 않았어요. 주도권이 아예 없었거든요. 이런 저런 고민이 많았죠. 그런 찰나에, 저한테 토스라는 회사가 갑자기 혜성처럼 나타났어요. 

Q. 이직을 고민하던 차에 토스라는 회사가 눈에 들어왔나보군요.
아뇨. 그래도 같이 일하는 분들이 너무 좋아서 큰 불만이 있었던 건 아니었어요. 하지만 당시 저에게 토스라는 회사가 너무 멋져보였어요. 디자인도 진짜 잘하고 일하는 방식이나 문화도 너무 선진적인것 같고요. 게다가 그때 채용 사이트가 막 시간이 타이머로 뚝뚝 내려가는 디자인이었는데 마음이 진짜 조급해지더라고요. 밤낮으로 포트폴리오를 준비했죠.



Q. 결국 토스에 브랜드 디자이너로 입사하셨을 때 기분이 어떠셨어요?
하, 그래프 더 높게 그려야 되는데(웃음). 제일 좋았죠, 정말. 이 애자일이라는 문화와 업무 방식을 접했을 때 그냥 신세계였던 것 같아요. 사람들도 다 너무 똑똑한 것 같고, 나한테 왜 이렇게 많은 권한을 주는지 모르겠고, 저한테 다 알아서 해보라고 하고… 전사 위클리도 ‘어떻게 저런 내용을 다 공유하지’ 싶었고요.
그런 한편 주변에 잘하는 분들이 너무 많고 막 업계에서 유명한 사람들도 있고 그러니까 위축이 됐었죠. 그래서 그때 진짜 열심히 했던 거 같아요. 항상 부족하다는 생각에 밤도 많이 샜고, 긴장을 많이 해서 힘이 빡 들어가있었다고 할까요. 커뮤니케이션 할 때도 좀 장황하게 설명하고 옷도 막 슬랙스에 구두 신고 다니고요(하하) 지금은 뭐... 후리하게 다니죠.

Q. 그러셨구나. 전혀 몰랐어요. 그 이후엔 좀 괜찮아지셨나요?
어쨌든 열심히 하긴 했는데… 여전히 채워지지 않는 갈증이 있었어요. 이 회사의 핵심은 제품인데 내가 너무 제품이랑 멀다는 느낌이 들었거든요. 계속 표면에 머물러 있다는 생각이 들더라고요. 커리어 초반부터 했던 고민이 계속 이어진 거죠. 내가 더 소속감을 느끼면서 일하려면 어떻게 해야 할까 고민하던 중에, 프로덕트 브랜딩이라는 팀이 신설됐어요. 
당시 조직 규모가 점점 커지면서, 브랜딩도 세부적으로 분리해야 할 시기가 왔었어요. 그때 “저 해볼게요”한 거죠. 당시 희연님이 UX 헤드였는데 약간 당황하셨던 것 같기도 해요(웃음). 너무 다른 플랫폼이긴 했으니까. 그래도 희연님이 원래 좀 열린 분이라, “그래요, 해봐요!” 하셔서 직군을 전환하게 됐죠. 



Q. 저도 기억나요. 유라님이 제품하겠다고 하셔서 완전 대단하다고 생각했거든요.
와… 그런데, 플랫폼을 바꾼다는 게 진짜 뇌 구조를 바꾸는 기분이더라고요. 내가 지금까지 오프라인에서 전달했던 경험을 모바일로 전한다는게 너무 쉽지 않은 일이었어요. 툴도 익숙하지 않은데다, 아직 조직에서 신뢰를 쌓지 못한 상태인데 또 새로운 걸 해야 하니까 부담도 되고 그랬죠. 제가 너무 불안해하니까, 희연님이 매주 1:1 미팅하는 시간을 가져보자고 했었어요. 그때 어떤 문제에 대한 직접적인 솔루션을 주시진 않았지만, 혼자 생각하고 결정내리도록 도와주셨어요. 덕분에 너무 헤매지 않고 조금씩 적응해 나갈 수 있었죠. 마음에 안정감도 생기고요.



Q. 그럼 언제 처음으로 신뢰를 쌓게 된 거예요?
추석 토끼요. 추석 때 사용자들에게 따뜻한 내용의 편지를 주는 이벤트였는데요. 그게 반응이 너무 좋았던 거예요. “따뜻하게 말해줘서 고마워”하는 정성적 반응도 많았고, 클릭률이나 참여율도 굉장히 높았어요. 저는 그때 CTR이 뭔지도 몰랐던 상태였는데, 지금 생각하면 그 수치가 나온 게 정말 대단한 일이었죠.
더 좋았던 건 팀원 분들 반응이었어요. “사람들이 이런 걸 좋아할지 몰랐네?”이런 얘기들을 해주셨었거든요. 왜냐하면 그때까지만 해도 토스 팀에 재미나 감동을 위한 제품을 만드는게 익숙하지 않은 상태였어요. 그때 추석 토끼를 같이 제작하는 팀원 분들 조차도 공감을 잘 못하셨는데, 제가 딱 한번만 만들어보자고 겨우 부탁해서 만들었거든요. 다행히 잘된 거죠. 이 때 이후로 주기적으로 기부 이벤트 같은 시즈널 제품을 만들기 시작했어요. 정성적 가치 전달에 대한 공감대가 형성된 거죠.



Q. 시즈널 말고 다른 제품도 하셨던 걸로 기억해요.
시즈널 제품을 몇 번 성공시키다보니, 단기 제품이 아닌 장기로 운영되는 제품을 만들어보고 싶다는 생각이 들더라고요. 당시에 제가 개인적으로 사주를 좀 공부했었는데요, 기왕이면 내가 관심 있는 걸 파보자라는 생각으로 ‘오늘의 운세’라는 제품을 만들었어요. 저 혼자서 기획서도 쓰고, 같이 할 팀원 분들을 모았죠. 300개가 넘는 운세 콘텐츠를 하나하나 제가 직접 써 가면서요.
그런데 상시로 운영되는 제품을 만드는게 진짜 어렵더라고요. 제일 어려웠던 건, 제품 운영 자체보다도 팀원들의 동기가 떨어져 가는 걸 볼 때였죠. 그럴 때 진짜 제가 뭘 어떻게 해야할지 모르겠더라고요. 결국 운영 모드로 돌리고 사실상 운세 제품을 접게 됐죠. 목표를 달성하지 못했기 때문에 성공 실패 여부를 따지자면 실패긴하지만, 제품에 대한 이해도를 가장 많이 높일 수 있었던 값진 경험이었어요.
한편으론 토스에 감사하기도 하고요. 그때 제가 이 제품 만들겠다고 좀 막무가내로 나갔는데 막지도 않았고, 목표달성을 못했더라도 책임을 묻지 않았거든요. ‘이곳에선 정말 해보고 싶은걸 자유롭게 할 수 있구나’라는걸 새삼 느꼈어요. 이 과정에서 배운게 너무 많았기 때문에 이런 문화가 얼마나 뜻 깊은지 많이 생각하게 됐던 것 같아요. 



Q. 지금 집중하고 계신 접근성은 어쩌다 시작하게 되셨어요?
이런 것들을 다 해보고 나니까, 점점 일의 재미보다는 의미에 대해 생각해보게 되더라고요. 사실 저는 스스로가 재미 드리븐인 사람이라고 생각했는데, 여러 경험을 거치면서 재미만으로 일을 지속할 수 있는 사람은 아니라는 걸 깨달았어요. 여기서부터 제가 중간에 포기하지 않고 나아가야 할 이유를 찾아야겠다는 생각이 들었는데, 생각할수록 가장 기억에 남는 게 장애인의 날을 기념하며 제작했던 했던 시즈널 이벤트더라고요. 접근성이요. 
사실 그때 저도 처음 접근성 UX를 접하게 됐는데요, 그때 이후로 계속 접근성 이슈에 대해 관심을 가지게 됐어요. 근데 당시에는 팀원들이 접근성 이슈에 큰 관심이 있는 분위기는 아니었어요. 그러다보니 저 스스로도 ‘회사는 당장 매출이 중요한데 내가 너무 먼 세상 얘기하나?’라는 생각이 들기 시작하더라고요. 그런데 지영님이 UX 플랫폼 트라이브 헤드로 오시면서 많이 바뀌었어요. 지영님은 팀원이 어떤 관심사가 있으면 ‘더 파봐, 지지해줄게’하고 적극적으로 표현도 해주시는 타입이잖아요. 덕분에 저도 용기가 많이 생기더라고요. 그래서 접근성 관련 프로젝트를 꾸준히 진행할 수 있었죠. 

Q. 마지막으로, 5년 전 나에게 조언을 할 수 있다면 어떤 얘기를 하고 싶은가요?
속도보다는 방향이다! 저는 늘 많이 방황해왔던 것 같은데, 이제야 계속 나아갈 방향성을 좀 잡은 것 같거든요. 일뿐만 아니라 삶 전반으로요. 그런데 그런 방향성은 어디서 갑자기 만들어지는 게 아니라, 많이 고민하고 시도해보면서 ‘이거구나!’라는 느낌이 들 때 생기는 것이 더라고요. 이제는 옛날만큼 불안하지 않고, 챌린지가 들어와도 방향성 자체가 흔들릴 정도로 무너지지 않아요. 어차피 세상에 정답은 없으니까 내가 생각한대로, 해왔던대로 나아가면 되겠다라는 확신이 들어서인가 봐요.

유라님과 함께 해보고 싶다면?
유라님과 비슷한 커리어 패스를 밟아보고 싶거나, 유라님이 소속되신 UX Platform Tribe에서 일해보고 싶은 분들은 댓글을 남겨주세요! 정성스런 댓글을 남겨주신 분 중 추첨하여 유라님과 토스 오피스에서 1:1 커피챗(30분)에 초대해드려요. *발행일 1주일 뒤에, 그동안 달린 댓글을 기준으로 결과를 공유드려요.

Interviewee: 김유라
Interviewer & Editor: 김자유


이번 토스 피플에서는 Design Strategy Lead 김유라님의 인터뷰를 공유드려요. 유라님은 브랜드 디자이너로 입사해, 프로덕트 브랜딩 팀에서 추석 토끼, 눈사람 기부 이벤트, 장애인의 날 점자 카드 이벤트 등 다양한 시즈널 제품을 만들고, 오늘의 운세 제품을 리딩하셨어요. 지금은 시각 장애가 있는 사용자들을 위한

여러 분야의 방황을 통해 지금은 접근성 디자인을 맡고 계신 유라님. 지표를 중요하게 생각했던 토스에서 ‘정성적 경험’의 가치를 끌어올린 디자이너 유라님의 이야기를 들려드려요. 

토스 피플: 방황은 내게 방향을 제시해주었다


미스터리 디자인 클럽은? 
사용자 경험 속 크고 작은 궁금증을 사용자 리서치, 실험 등 다양한 방법으로 탐구하는 모임이에요. '왜 이렇게 디자인해야 할까?'라는 질문을 시작으로, 관성처럼 굳어진 UX 패턴의 진실을 파헤치며 더 나은 사용자 경험을 찾아가고 있어요. 

타임머신이 있다면 어디로 가보고 싶나요?

다들 고르셨나요? 오늘 미스터리 디자인 클럽에서는 ‘선택지를 고르는 화면’ 디자인에 대해 이야기해볼게요.
“화면 디자인을 하다보면 사용자가 선택지를 고르는 화면을 많이 구성하게 되는데요. 때에 따라 단 하나만 선택되거나, 여러 개를 선택할 수 있는 경우가 있어요. 그럴 때, ‘하나만 선택되는 화면은 당연히 *라디오 버튼으로 디자인 해야하지 않나?’라는 생각이 먼저 들어요. 사용자에게 ‘디자인적 증거’를 줘야겠다는 생각이 들기 때문이에요.” - 토스 프로덕트 디자이너 A
*라디오 버튼이란?  옵션을 선택할 때 사용되는 UI 컴포넌트인데요. 라디오의 물리적 버튼에서 따와 만들어진 PC UI 문법으로, 옵션 중 하나를 선택해야 할 때 PC와 모바일 모두에서 많이 이용되고 있어요. 


A씨를 비롯한 많은 메이커들이 토스의 모바일 디자인 시스템에 라디오 버튼 컴포넌트를 추가하자는 이야기를 꺼내곤 했어요. ‘너무 일반적인 공식이기 때문에’, ‘다른 곳에서 모두 이렇게 하기 때문에’가 그 이유였어요. 
그러나, 모바일 환경에서는 이 형태가 적합하지 않은 면이 있어요. 마우스 포인터로 버튼을 편하게 클릭할 수 있는 PC 환경에는 어울리지만, 손가락 끝으로 탭해야 하는 모바일 환경에서는 작은 원을 정확히 눌러야 할 것 같은 형태가 최선이라 하기 어렵기 때문이에요. 실제로는 레이블을 눌러서 선택할 수 있다고 해도요. 


iOS에서도 원형의 라디오 버튼은 존재하지 않아요. 대신 세그먼티드 컨트롤(Segmented Controls)이라는 컴포넌트를 이용하거나, 위 이미지처럼 체크박스를 사용해 PC의 라디오 버튼과 같은 기능을 구현하고 있어요. 탭 가능한 큰 영역을 제공하고, 미니멀한 스타일을 유지하기 위해 대안을 제시한 거죠. 
이렇듯 모바일에서 최선의 형태가 아님에도 불구하고, ‘하나만 선택되는 화면은 반드시 라디오 버튼을 써야하지 않을까?’라고 많은 분들이 생각했던 거에요. 

여러분은 앞서 어떤 선택을 하셨나요? 
그리고, 다른 사용자들은 어떻게 선택했을까요? 


세 가지 유형의 질문을 준비해 UT를 진행했어요. 
유형 1️⃣: 앞서 여러분이 선택한 ‘타임머신’ 질문처럼, 서로 배타적이어서 여러 개를 선택할 수 없는 것이 있어요. 
유형 2️⃣: ‘최근 1년간 감상한 콘텐츠를 선택하라’는 것처럼, 대부분 여러 개를 선택할 만한 질문이 해당돼요. 
유형 3️⃣: 단일 혹은 중복 모두 선택할 수 있는 질문이 해당돼요. 
질문에서는 ‘모두 선택’, ‘하나만 선택’ 등 선택 개수를 안내하지 않았어요. 또한, 일반적인 공식과는 반대로, ‘하나만 선택’일 땐 체크박스, ‘중복 선택’일 땐 라디오 버튼을 주어 사용자가 어떻게 선택하는지 관찰했어요. 

미스터리 디자인의 진실  
대부분의 사용자들은 버튼의 모양과 상관 없이 질문에 따라 답을 선택했어요 (15명 중 13명) 
유형 1에서는 하나를, 유형 2에서는 여러 개를, 그리고 유형 3에서는 선택하고 싶은 만큼 선택한 건데요. 
그렇게 선택한 이유가 무엇인지 물었을 때, 질문 자체에 집중해서 대답했어요. “나는 올빼미형 인간이다”, ‘”최근 1년간 영화, 드라마, 예능을 모두 봤다” 이렇게요. 유형 2나 3에서 ‘여러 개를 선택해도 되는지’ 묻는 분들이 계셨지만, 이들 또한 “질문에서 ‘중복 선택’이라는 말이 없어 헷갈린다”고 말했어요. 버튼의 모양을 언급하며 질문해도, 이 모양으로 인해 헷갈렸다고 말한 경우는 거의 없었어요. 
물론, 모든 사용자가 라디오 버튼의 역할을 모른다는 것은 아니에요. 인터뷰의 의도를 설명하고 버튼의 모양에 대해 물었을 때, ‘설문 조사, 시험’ 등에서 본 것 같다고 답한 분들도 계셨어요. 그럼에도 불구하고, 유형 1에서는 하나를, 유형 2에서는 여러 개를 선택했고 어색하게 느끼지 않았다고 했어요. 
결론: 동그란 라디오 버튼을 쓰지 않는다고 해서, 사용자의 선택에 문제가 되지 않아요. 
사용자는 버튼의 모양이 아닌 맥락에 더 큰 영향을 받기 때문이에요. 
위 예시에서는 단 하나의 질문이 전체 맥락이 되지만, 실제 제품 내에서는 이전 화면, 라이팅, 설명글 등 훨씬 다양한 것이 사용자의 맥락이 될 수 있어요. 중요한 것은 사용자가 선택해야 할 개수를 자연스럽게 이해할 수 있도록, 최선의 UI로 친절한 맥락을 제공하는 것이에요. 실제로 토스 앱 내 화면으로 UT를 진행했을 때, 사용자는 더욱 명확하게 선택했어요. 버튼의 모양과 상관 없이 하나를 묻는 질문에서 하나를, 여러 개를 묻는 질문에서 여러 개를 선택했죠.  
모바일에서도 반드시 동그란 라디오 버튼을 써야한다고 생각했다면, 오래된 공식에 따르고 싶었던 디자이너의 관성일 수 있어요. 중요한 것은, ‘반드시 그래야 하는 것’은 사실 그렇지 않을 수 있다는 거예요. 

여러분은 어떻게 생각하시나요? 댓글로 의견을 남겨주세요. 





미스터리 디자인 클럽은? 
사용자 경험 속 크고 작은 궁금증을 사용자 리서치, 실험 등 다양한 방법으로 탐구하는 모임이에요. '왜 이렇게 디자인해야 할까?'라는 질문을 시작으로, 관성처럼 굳어진 UX 패턴의 진실을 파헤치며 더 나은 사용자 경험을 찾아가고 있어요. 

타임머신이 있다면 어디로 가보고 싶나요?

다들 고르