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 컴포넌트 가이드를 제작 할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.

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

언더커버 사일로

토스의 서바이벌 예능 <언더커버 사일로>의 비하인드 스토리

아티클 시리즈