7월 12일 금요일. 원래 금요일이라면 많은 팀원들이 재택해서 사무실이 썰렁하기 마련인데, 웬일로 아침부터 사무실은 북적북적하고 평소에 듣지 못한 대화가 들려와요. 
“12시간만에 끝낼 수 있을까요? 24시간도 모자란데”
”근데 지금 DB가 없어서…”
금요일 아침부터 토스 팀원들은 왜 모였을까요?
바로 제1회 토스 해커톤, 토커톤(Tockerthon)에 참여하기 위해서입니다. 토스 개발자, 디자이너, PO(Product Owner) 등 다양한 직군의 팀원들이 토커톤에 참여하려고 금요일 아침에 사무실을 찾아왔어요. 해커톤은 ‘해킹’과 ‘마라톤’의 합성어인데요. 정해진 시간 안에 팀원들과 집중해서 MVP(minimum viable product)를 만드는 과정이에요. 
토커톤은 아래 4개 주제 중 하나를 선택해서 팀을 만들고, 오전 10시부터 밤 10시까지 12시간 동안 집중해서 제품을 만들기로 했어요. 
토스 CSR(Corporate Social Responsibility, 기업의 사회적 책임)에 기여할 수 있는 것
토스 서비스를 개선할 수 있는 것
직장인 삶의 질을 높일 수 있는 것
자유주제
  
토커톤 함께 참여해요
아무리 MVP를 만든다고 해도, 제품은 혼자 만들 수 없죠. 그래서 토커톤은 7월 12일 훨씬 전부터, 팀을 구성할 때부터 시작된 셈이죠. 이번 토커톤은 토스의 혁신과 one team 정신을 다시 한번 강조하기 위해 주최된 만큼 2개 이상 법인 구성원이 속한 팀에는 가산점을 부여했어요. 그리고 이 가산점이 수상 팀을 정하는 중요한 역할을 하게 됐어요.

또 토커톤에서 더 안전하고 혁신적인 서비스가 만들어질 수 있도록 보안 팀에서는 팀원들께 보안 및 컴플라이언스 측면 가이드라인을 공유했어요. 하루만 진행되는 해커톤에서도 보안, 개인정보 보호는 중요하니깐요. 실제로 토스에서 서비스가 출시될 때는 다양한 법무, 보안, 개인정보 검토 과정을 거쳐요. 오늘 토커톤에서 나온 아이디어도 실제로 출시되기 위해서는 이런 과정이 필요하고요.  
토커톤을 시작합니다!
팀별로 주제를 선정하고 참가 신청하면 준비는 끝. 그리고 대망의 토커톤 당일, 팀원 하나둘씩 모니터부터 칠판, 선풍기, 조명까지 들고 나타나기 시작했어요. 각 팀원의 자리에는 토스 수건과 토커톤 레고 피규어가 웰컴 키트로 준비되어 있었는데요. 수건은 보통 24시간 동안 진행되는 해커톤에서 씻고 다시 제품을 만드는 정신을 상징하고,  레고는 블록을 맞추듯이 팀원 한 명 한 명이 해커톤을 만들고 토스 역사를 함께 만들어간다는 의미가 담겨있답니다.
토커톤 시작과 함께 토스 리더 승건님이 팀원들의 사기를 충전해주는 한 말과 토스를 창업하기 전에 참여했던 첫 해커톤에서 든든한 공동 창업자를 만난 경험을 공유해주셨어요. 이런 도전 정신을 팀원분들께도 공유하고자 승건님에게 질문하고 조언을 받을 수 있는 ‘승건 찬스’도 마련했어요. 

이렇게 본격적으로 제1회 토스 해커톤, 토커톤을 시작했습니다. 21개의 팀, 72명의 팀원이 함께 해주셨는데요. 토스 커뮤니티의 다양한 팀원분들의 함께해주신 만큼 많은 재미있는 주제가 나왔어요. 개발자 없이 인공지능으로 개발하는 서비스, ChatGPT로 법무 검토하는 서비스, 토스 포인트로 소액기부할 수 있는 서비스, 똑똑하게 재무설계를 추천하는 서비스 등 다양한 아이디어를 가진 팀들이 토커톤에 도전했어요.
이번 '토커톤'은 이래서 좀 특별합니다! (feat. 팀 빌딩)
토커톤이 다른 해커톤과 다른 점은 바로 팀 빌딩인데요. 토커톤에 참여한 팀원분들은 다양한 피드백을 받아서 더 즐겁고 생산적인 하루를 보낼 수 있었어요. 팀 빌딩을 잘 보여준 팀의 이야기를 공유드려요.

8번의 창업 후 9번째 도전에 토스를 만들어낸, 토스팀 리더 승건님의 피드백
점심 먹고 나른한 시간, 오후 2시에 ‘승건 찬스’가 시작됐어요. 서비스의 방향성, 시장에서의 가치를 조금 더 명확하게 살펴볼 수 있도록 승건님은 기획 측면에서 신청 팀들에게 진심 어린 조언을 해주셨는데요. 기억에 남는 ‘승건 찬스’ 하나를 공유드려요.
패기 넘치게 팀 이름도 ‘토스’라고 지은 토스팀. 토스의 만보기만큼 사용자를 끌어모을 수 있는 제품을 만들겠다는 포부와 함께 야심 차게 준비한 서비스는 ‘하루에 물 2L 마시기’였는데요. 멋진 애니메이션까지 마무리한 순간, ‘승건 찬스’에서 날벼락을 맞게 됩니다. 승건님이 “풀어야 할 중요한 문제가 아닐 수 있다”라는 조언을 해주시기 때문인데요. 마감까지 남은 시간은 단 5시간… 

팀이 더 유능하게 작동할 수 있도록 돕는 애자일 코치, 희열님의 피드백
토스팀의 해결책은 ‘희열 찬스’에서 옵니다. 희열님은 오늘 이루고 싶은 게 무엇인지 다시 생각할 기회를 마련해주셨고, 토스팀은 목표를 ‘즐거움’과 ‘재미’로 다잡게 돼요. 다시 동기부여를 받고 토스팀은 남은 시간 동안 엄청난 회고를 하면서 팀원들과 라포를 형성하는데 대성공하고 오늘 세운 목표도 얻어 갑니다. 
발표시간에 토스팀은 이런 과정을 모두 공유해주셨는데요. 유쾌한 발표에 현장은 웃음바다가 되었고, 심사위원은 제품 기획, 실행, 실패를 경험하려면 몇 달 또는 몇 년이 걸리는데 이 모든 성장 과정을 하루 만에 이룬 걸 축하하기도 했습니다. 때로는 참여와 과정이 결과물보다 중요하다는 걸 몸소 보여준 팀이었습니다.

결과만을 위해 달리는 것이 아닌, 과정 자체를 즐기는 우리의 자세
또 다른 재미로 모두가 배꼽 잡으면서 들은 발표는 바로 매치사일로의 <내게 맞는 사람 찾기>였어요. 귀여운 캐릭터와 간단한 조건 선택 과정이 인상적인 데이팅 서비스였는데요, 획기적인 만큼 심사위원들의 반응도 뜨거웠어요. 만우절 이벤트로 한 번 열어보면 어떨까라는 의견도 있을 만큼 많은 팀원들에게 재미를 주었던 것 같아요.
팀을 이끌었던 Frontend Developer 성준님의 한마디
사실 전날 트라이브 내에서 워크샵을 진행해, 팀원들이 많이 피곤한 상황이었거든요. 그런데도 모두가 각자의 역할을 너무 잘 담당해서, 팀워크로 느끼는 쾌감이 정말 컸어요. 고려사항이 많은 기획과 요구사항을 UI로 깔끔하게 풀어내는 디자이너, 복잡한 로직을 설계하고 구현하는 테크 리드, 필요한 부분들을 캐치해서 챙기는 풀스택 엔지니어 팀원들 덕분에 ‘실패할 수가 없는 드림팀’ 을 경험할 수 있었어요. 

'토커톤'을 통해 무엇을 얻었냐고요?
늦은 저녁에 대망의 발표 시간이 시작됐는데, 모두가 자리를 지키고 귀를 기울어 발표에 집중했어요. 서로의 발표, 아이디어를 기대하고 응원하는 축제의 장이 열렸는데요. 토커톤에서 수상한 팀의 발표와 협업 과정을 공유드려요.
3위. 리모태 없인 일모태 <사장님들은 이렇게 리뷰관리에 빠지게 됩니다>

바쁜 사장님은 매일 홀 관리, 직원 관리, 매출 관리, 배달 관리를 해야 되는데요. 여기에 리뷰 관리까지 해야 됩니다. 컴퓨터 들여다볼 시간도 없는 사장님, 하루 종일 보고 있는 곳은? 바로 POS입니다. 
그래서 리모태 없인 일모태 팀은 POS 시스템에 리뷰 관리 서비스를 넣었습니다. 배달 앱, 쇼핑앱 등 다양한 플랫폼을 연결하고, 각 플랫폼에 AI로 답글을 만들 수 있어요. 실제로 발표 시간에 리뷰와 답글을 남기는 실시간 시연을 보여주셨는데요, 매끄러운 유저 경험에 모두가 놀랐습니다. 사장님의 불편함을 명쾌히 해결해준 리모태 없인 일모태 팀은 3위를 차지했어요. 
팀을 이끌었던 Product Manager 민주님의 한마디
같은 목표를 향한 열정적인 팀워크가 큰 동기부여가 되었어요. 부족한 리소스였는데, 팀원들 덕에 서로 보완하면서 즐거운 분위기 속에서 성과를 만들 수 있었던 것 같아요.
약 10시간이라는 제한된 시간 안에 프로덕션 수준의 결과물을 만들어내는 경험이 짜릿했어요. 
창의적인 아이디어를 내고 팀원들과 같이 고민할 수 있는 시간을 따로 만들기가 힘든데, 해커톤 덕분에 색다른 성취감과 재미를 느낄 수 있었어요!
2위. 토스랑산악회 <진짜 결혼해요? 모바일 청첩장>

실제 새신랑이 되신 팀원의 험악하고 어려운 결혼 준비 과정을 바탕으로 토스랑산악회 팀에서는 토스에서 무료로 모바일 청첩장을 만들고, 토스페이로 축의금도 받을 수 있는 서비스를 기획했어요. ATM 가서 현금 뽑는 시대, 엑셀로 축의금 내역을 관리하는 시대를 대체할 수 있는 똑똑하고 편리한 축의금 관리 방법을 제시해주신 것이죠. 토스랑산악회 팀은 발표 도중에 실제로 축의금을 보낼 수 있는 모바일 청첩장도 공유해주셨어요. 
매끄럽게 작동하는 모바일 청첩장에 모두가 감탄했고 몇 시간 만에 서비스를 발전시키고 실현해낸 팀원들에게 찬사를 보냈습니다. 심사위원은 시연을 위해 만든 모바일 청첩장으로 실제로 몇 백원을 보내기도 했고요. 사업성이 좋아서 축의금뿐만 아니라 다양하게 활용할 수 있을 거 같다는 호평도 받았어요. 정말 아쉬운 점수 격차로 2위를 차지했습니다.
팀을 이끌었던 Head of Frontend 서진님의 한마디
저는 과거에 같이 일하면서 손발이 척척 맞았던 팀원들과 함께했는데요,
이번 해커톤에서 다시 모여 뚝딱뚝딱 제품을 만들면서, 여전히 마음이 잘 맞아 너무 즐거웠어요. 뛰어난 역량을 가진 팀원들과 평소에 만들고 싶었던 제품을 개발하니, 훨씬 신나게 개발할 수 있었던 것 같아요.
1위. 토스철학관 <프론트는 당신의 운명을 알고 있다>

‘결제’만 하는 단말기는 토스에서 너무 평범하죠? 고객의 운명과 천명 정도는 알려줘야죠! 대망의 1위를 차지한 토스철학관 팀은 토스플레이스 단말기에서 생년월일 입력하면 사주를 볼 수 있는 서비스를 기획했답니다. 고객에게 개인화된 경험과 재미있는 이벤트를 제공하는 일석이조 서비스죠. 
토스철학관 팀은 서비스가 충분히 상품성이 없다는 걱정을 했다는데, 실제로는 심사위원의 호평이 쏟아졌습니다. 승건님은 토스철학관의 상품성은 큰 ‘재미’라고 말씀해주셨어요. 
팀을 이끌었던 Node.js Developer 보미님의 한마디
실제 업무 시간에는 회의나 여러 이슈로 하나의 작업에 집중하기가 어려웠는데, 12시간 동안 여러 개발자가 모여 하나의 제품을 집중해서 개발하니까 생각보다 제품이 금방 나오더라고요. 모두 다 같이 몰입해서 짧은 시간에 깊은 유대감을 쌓은 것 같아서 너무 행복한 경험이었어요!
팀에서 함께했던 Android Developer 세희님의 한마디
저는 ‘토스’ 소속이었는데 이번에 처음 ‘토스플레이스’ 팀원분들과 협업해 보았거든요. 이런 계기로 협업을 확장할 수 있어서 좋았고, 토스플레이스 기기도 만져보는 새로운 경험을 해서 재미있었어요.
팀에서 함께했던 Server Developer 동현님의 한마디
1-2시간 단위의 작업 목표를 세우고, 상태를 체크하면서 구현해나가는 과정이 제한된 시간 내에 속도감 있게 목표를 달성하는데 적절한 전략이었던 것 같아요. 오랜만에 재밌는 서비스를 팀원들과 만들 수 있어서 좋았어요!
마무리하며
이렇게 절찬리에 마무리된 첫 번째 토커톤이었습니다. 참여한 모든 팀원이 각자 원했던 목표를 이루고 토스에서 잊지 못할 또 하나의 추억을 적립했어요. 마지막으로 참여한 팀원의 소감과 기억에 남는 에피소드를 들으면서 마무리해볼게요.
Q. 오늘 토커톤 참여하신 소감 한 마디 해주세요.
평소에 협업하지 못한 동료들과 함께 서비스를 만드는 기회가 있어서 너무 재밌었습니다. 일할 때는 우선순위에 따라서 업무를 하는데 오늘은 하고 싶은 게 하고 있어서 재밌지 않았나 싶습니다. 주제도 팀에서 떠오른 아이디어 중에서 가장 재미있는 걸 기준으로 선택했어요. - 간바레 오또상
1회 토커톤에 참여하게 돼서 감회가 새로워요. 내가 1회라니! 그리고 정말 해커톤처럼 아무것도 준비하지 않고 왔는데 아이디어가 잘 나와서 신기했어요. 아무것도 없는 상태에서 바닥부터 다 만들어야 되니까 신선한 경험이었고, 10시간 동안 오로지 제품을 만드는 것에만 집중할 수 있어서 재밌었어요. - 토네이션
맨날 정해진 일만 하다가 완전히 다른 걸 하니까 리프레시됐어요. 저는 이 제품 잘 되면 진짜 창업하고 싶어요! - 대한수면연구학회
Q. 가장 기억에 남는 순간이 있으신가요?
저희 제품이 유기견 또는 유기묘를 위해 기부금을 내면 고양이나 강아지랑 메시지를 주고받을 수 있는 컨셉이었는데요. 시현을 위해서 저희 개발자가 고양이, 강아지 페르소나로 채팅을 만들어내야 돼서 토커톤 마지막 3시간은 고양이로 살았어요. 그 모습이 너무 웃겼어요.  - 제로코딩단
저희 팀은 재무 설계를 도와주는 제품을 만들었는데요. 전문가가 아니어도 어떻게 포트폴리오를 굴려나갈지 알려주고 실시간으로 발생하는 금융 이벤트에 의해서 포트폴리오를 재구성하라는 넛지도 주는 아이디어였어요. ‘승건 찬스’를 썼는데 저희에게 제품에 와우 포인트가 없다는 혹평을 주셔서 조금 멘붕이 왔어요. 다들 좀 무너졌는데 새로운 걸 하기엔 시간이 없어서 그냥 밀고 나갔어요. 다행히 발표에서는 충분히 제품으로써 가치가 있다는 평가를 받았습니다! - 금융웃음클럽
희열님께 1등을 어떻게 하면 되는지 여쭤봤어요. 희열님은 평가 항목을 모두 잘 하려고 하지 말고, 잘할 수 있는 항목을 선택해서 잘 해보라는 조언을 해주셨어요. 근데 저희 팀은 모든 항목이 욕심났어요. 그래도 조금 기준이 모호하다고 생각한 항목을 조금 포기했어요. - 토스철학관



7월 12일 금요일. 원래 금요일이라면 많은 팀원들이 재택해서 사무실이 썰렁하기 마련인데, 웬일로 아침부터 사무실은 북적북적하고 평소에 듣지 못한 대화가 들려와요. 
“12시간만에 끝낼 수 있을까요? 24시간도 모자란데”
”근데 지금 DB가 없어서…”
금요일 아침부터 토스 팀원들은 왜 모였을까요?
바로 제1회 토스 해커톤

토스 개발자, 디자이너, PO(Product Owner) 등 다양한 직군의 팀원들이 토커톤에 참여하려고 금요일 아침부터 사무실을 찾아왔는데요. 토커톤에서 도대체 무슨 일이 일어났을까요?

제 1회 토스 해커톤, 토커톤(Tockerthon)

300명이 넘는 개발자와 디자이너를 위한 디자인 시스템을 4명의 디자이너가 운영하고 있어요. 이 과정에서 컴포넌트의 유려함뿐만 아니라, 가이드의 효율적인 제작도 중요함을 깨달았어요. 이번 아티클에서는 TDS 컴포넌트 가이드를 제작할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.


문제 
컴포넌트를 개선하려고 할 때, 기존 가이드로는 동료 플랫폼 디자이너 및 개발자분들과 소통하기 어려웠어요. 컴포넌트 가이드 작성에 대한 규칙이 없으니 디자이너마다 작성된 방식이 제각기였고, 이 때문에 기존에 작성된 가이드를 읽는 데에도 컴포넌트를 온전히 파악하기 어려웠기 때문이에요.
기존 컴포넌트의 가이드에서 어떤 부분들이 문제였길래, 컴포넌트를 만드는데 메이커들이 어려움을 겪었을까요? 그리고 플랫폼 디자이너들은 이 문제들을 어떻게 해결했을까요?


해결책
가이드 읽는 방향성 정하기
기존에는 한눈에 스펙을 확인할 수 있도록 정사각형에 가까운 형태로 가이드를 배치했어요. 


각 옵션이 한 눈에 보이고, 깔끔하게 정리된 가이드를 보며, 이 완벽한 가이드만 있으면 더 이상의 커뮤니케이션은 필요 없을 줄 알았어요. 하지만 개발자분들이 이미 가이드에 정의된 스펙을 보지 못한 채 따로 요청해주시기도 하고, 컴포넌트를 구현하면서 누락된 옵션들도 종종 나타났죠.
이유를 개발자와 이야기해보니 가이드를 어떤 순서로 읽어야 하는지 파악하기 어려웠다는 걸 알게 됐어요. 그래서 어떤 구조로 컴포넌트를 만들어야 하는지 이해하기 힘들었다고 하더라고요.


그래서 정보를 단순히 그룹핑만 하는 것이 아니라, 읽는 방식부터 누구나 같은 방향으로 읽을 수 있게끔 그룹핑된 가이드 내용을 위에서 아래로 흐르게끔 배치했어요. 

이로써, 가이드를 어떤 순서로 읽어야 하는지 알기 쉬워졌고, 그 결과 컴포넌트의 스펙을 단계별로 쉽게 소화할 수 있게 됐어요.


큰 구조부터 자세한 요소로
가이드의 방향성을 정한 이후로 순서에 대해서 고민하고 있을 때, 때마침 컴포넌트 스펙맞추기 해커톤이 예정되어있었어요. 안드로이드 iOS, 웹 세 플랫폼이 모이는 시간에 저도 아예 옆에 앉아서 가이드는 어떻게 기록되어야 좋은 가이드가 될 수 있을지, 신속하게 피드백을 구하며 빠르게 의사결정을 해나갔어요. 
그 과정에서 발견한 것은 개발도 그림을 그리듯이 큰 구조부터 자세한 요소로 진행된다는 점이었어요. 전체적인 스케치를 한 다음 묘사를 하는 것처럼요.

그래서, 토스트 컴포넌트 가이드에서는 가장 먼저 컴포넌트의 상위 옵션인 상단과 하단 타입을 보여주어 개발자가 구조를 이해할 수 있도록 하고, 그다음으로 각 타입에 포함된 요소들을 정리했어요. 마지막으로는 컴포넌트의 다양한 상태 변화(예를 들어 다크모드나 텍스트가 두 줄이 됐을 때)의 상세 스펙을 추가했어요. 
이처럼 큰 옵션 정의부터 내부 변경될 수 있는 자세한 스펙들 순으로 점층적으로 가이드를 구성해 원하는 스펙을 찾아 방황할 필요 없이 효율적으로 가이드를 읽을 수 있게 했어요.


최악의 케이스 그리기
컴포넌트의 정보 위계가 생긴 것은 좋았지만, 그 정보 위계의 지도를 한 눈에 볼 수 없다는 점이 아쉬웠어요. 컴포넌트 안에도 다양한 요소들이 있어서, 어떤 요소는 쓰고 어떤 요소는 안 썼을 때 등등 굉장히 다양한 경우의 수가 있었거든요. 
예를 들어 토스트에서 주로 쓰는 형태는 왼쪽이지만, 오른쪽처럼 버튼을 넣는 케이스도 있었어요.

이런 케이스를 하나하나 살펴볼 수 없으니, 오른쪽처럼 모든 요소를 최대한으로 썼을 때의 모습을 가이드의 제일 위에 첨부해두었어요. 모든 옵션을 다 사용한 사례를 먼저 보고 나면, 어떤 옵션이 있는지 전체적으로 지도를 그린 다음 하나씩 살펴볼 수 있으니까요.


접근성 영역 나누기
기존 가이드에선 접근성 스펙을 컴포넌트 레이아웃에 대한 설명할 때 포함하기도 하고, 별도의 페이지에 작성하기도 했어요. 그렇다 보니 ‘음! 새로운 A컴포넌트를 만들 땐 B컴포넌트의 접근성 가이드를 참고해야지! ‘라고 떠올리기 쉽지 않았어요. 그래서 접근성을 챙기기 위한 여러 가지 장치들을 새로운 컴포넌트를 설계할 때 참고하기 어려웠죠.
그래서 접근성에 대한 기존의 의사결정들을 비슷한 컴포넌트를 새롭게 설계할 때도 빠르게 참고할 수 있도록 선형으로 설계된 가이드에 가장 하단에 위치시키기로 약속했어요.

이를 통해서 디자이너가 가이드를 설계할 때 이 옵션을 의식적으로 챙길 수 있었고, 이러한 구조 변경으로 더 큰 텍스트 뿐만 아니라 보이스오버 사용성, 동작 줄이기와 같은 조건들을 조금씩 쌓아나갈 수 있었어요.


수십개의 컴포넌트 가이드에 적용하기
토스트, CTA, 리스트 등 여러 요소를 조합해 사용하는 대다수 컴포넌트는 앞서 정한 구성을 그대로 적용할 수 있게 했어요. 이를 위해, 큰 구조부터 시작해 타입, 영역, 상세 스펙, 더 큰 텍스트, 다크모드까지 포함하는 체크리스트를 정의했죠. 이 체크리스트를 바탕으로 가이드를 작성하도록 했어요. 타입이 나뉘어있지 않거나, 상세 스펙을 따로 정의할 필요가 없는 경우에는 생략했어요.


에셋, 버튼, 체크박스와 같은 아토믹 컴포넌트들은 구성요소가 단순해서 일반적인 컴포넌트 가이드와 비슷한 구조로 짜다 보면, 불필요한 정보를 넣게 되더라고요. 그래서 컴포넌트 자체의 특성에 맞게 뒤따라올 옵션들이 예측할 수 있게끔만 가이드를 구성했어요.


그리고 화면을 덮으며 나타나는 다이얼로그나, 바텀시트와 같은 컴포넌트들은 화면 안에서 어디에 위치해야 하는지에 대해 정의할 수 있도록 position이라는 항목을 체크리스트에 추가했어요.


또한 각 스펙을 가이드에 작성할 때는, 정확한 스타일 값과 결과물을 한 번에 볼 수 있도록 왼쪽에는 예시 이미지를 오른쪽에는 정확한 값을 꼭 작성하도록 했고, 이 작업을 최대한 효율화하기 위해 디자인 스펙을 표기하는 몇 가지 형태를 복붙해서 사용할 수 있도록 만들어두기도 했어요



결과 
이러한 해결책들을 통해서 기존 가이드의 많은 문제의식을 해결할 수 있었어요.
가이드 작성에 대한 규칙이 없을때는 하나의 컴포넌트 가이드를 작성하는 데에만 일주일이 걸렸는데, 가이드 작성하는 규칙이 생긴 이후로는 컴포넌트 3개를 하루 만에 가이드를 작업할 수도 있었어요. 또한 팀에 새로 합류한 플랫폼 디자이너들이 기존 시스템을 빠르게 이해하고 바로 기여할 수 있었어요. 
하지만 시스템이 성장하면서 가이드가 길어진 것들은 지금의 방식으로는 원하는 스펙을 찾아가기 힘들어져, 구조에 맞게 가이드를 끊거나 목차를 만드는 등의 새로운 방식들을 고민하고 있어요.
앞으로 시스템의 규모가 성장함에 따라 기존 가이드를 개선했던 것처럼 팀원들과 함께 논의해가며 가이드를 개선해 나가려고 해요.




300명이 넘는 개발자와 디자이너를 위한 디자인 시스템을 4명의 디자이너가 운영하고 있어요. 이 과정에서 컴포넌트의 유려함뿐만 아니라, 가이드의 효율적인 제작도 중요함을 깨달았어요. 이번 아티클에서는 TDS 컴포넌트 가이드를 제작할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.


문제 
컴포넌트를 개선하려

디자인 시스템을 운영하면서, 컴포넌트의 유려함뿐만 아니라 가이드의 효율적인 제작도 중요하다는 것을 깨달았어요. 이번 아티클에서는 TDS 컴포넌트 가이드를 제작 할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.

제품이 커지면 디자인 시스템 가이드는 어떻게 개선돼야 할까?


모닥불 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 패턴의 진실을 파헤치며 더 나은 사용자 경험을 찾아가고 있어요. 

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

다들 고르