2021년, 토스피드에 올라온 '지금, 툴이 아닌 틀을 바꿔야 할 때'라는 글을 기억하시나요? 토스의 디자인 시스템에 관심 있는 분이라면 한 번쯤 읽어보셨을 겁니다.
왜 우리 팀은 토스의 생산성을 가지지 못할까?
혹시 "우리 팀도 토스처럼 일할 순 없을까?"라는 생각, 한 번쯤 해보지 않으셨나요? 많은 팀이 토스의 폭발적인 생산성을 부러워하며 그들의 디자인 시스템(TDS)을 연구하고 도입합니다. 하지만 결과는 어떤가요? 아마 90% 이상은 기대했던 만큼의 효율을 얻지 못했을 겁니다.
그 이유가 디자인 시스템을 잘못 만들어서, 혹은 최신 툴을 사용하지 않아서라고 생각하셨다면, 이 글을 끝까지 읽어보시길 바랍니다.
토스 생산성의 진짜 비밀은 단순히 '디자인 시스템'과 '툴'에만 있지 않습니다. 바로 토스의 DST(Design Syntax Tree)를 이해하고, 이를 작업에 내재화해야 합니다.
토스 생산성의 핵심: DST 파헤치기
놀랍게도, 그 강력한 힌트는 우리가 여러 번 읽었던 바로 그 토스피드 글에 숨어있었습니다.
Hand-off 도구에서 디자인 시안을 코드로 바로 확인할 수 있다면, 애초에 요소를 일일이 선택해가며 간격과 속성값을 확인할 필요도 없어지죠.
이것을 구현하기 위해서는 디자인 시안을 기계가 해석할 수 있는 형태로 표현해야 했습니다. 그래서 TDS를 이용해 만들어진 화면을 기계가 해석할 수 있게 구조적으로 표현하는 DST(Design Syntax Tree)라는 자료구조를 고안했습니다. 프레이머를 통해 디자인된 화면을 실시간으로 해석하여 DST로 표현하고, 이것을 다시 코드로 번역할 수 있게 만든 겁니다.
핵심은 DST입니다.
토스는 디자인을 '기계가 읽을 수 있는 구조화된 데이터'로 정의했고, 이것이 코드의 구조로 손쉽게 전환되어 폭발적인 생산성을 만들어낸 것입니다.
하지만 아쉽게도 DST에 대한 자세한 정보는 찾아보기 어렵습니다.
우리가 알 수 있는 정보는 아래 이 정도가 전부입니다.
DST는 UI 화면을 구성하는 모든 요소를 계층적 트리 구조로 직렬화한 데이터 포맷이다.
· 어떤 요소가 어떤 속성을 갖고
· 어디에 배치돼 있고
· 어떤 관계로 연결되어 있는지를
기계가 그대로 읽을 수 있도록 구조화한 것이다.
토스의 DST는 전체적으로 가지를 뻗어 나가는 ‘트리(Tree)’와 같은 계층 구조를 가집니다. 이는 웹에서 <div> 태그를 중첩하여 레이아웃의 뼈대를 잡는 원리와 유사합니다. 그리고 그 계층 구조의 각 노드(node)에는 '박스(Box)'라는 객체 단위가 배열됩니다.
이 ‘박스’ 안에는 HTML의 클래스명 같이 약속된 규칙에 따른 명시적인 이름(Naming)과, 기존 디자인 데이터에서는 찾아볼 수 없던 구체적인 레이아웃 속성 값(flex, 정렬 방식 등)이 표현됩니다.
토스는 DST라는 이 고유한 방법론을 직접 고안했으며, 이것이 체계적으로 올바르게 활용되기 위한 상세한 규칙(Rule)을 정의했습니다.
여기서 더 나아가, 정의된 규칙들이 실제 작업에서 쉽게 지켜지도록 ‘DST 사전 셋업’을 구축해 디자인 시스템의 핵심 요소로 통합했습니다.
일반적인 '디자인 원칙'처럼 토스에는 잘 설계된 ‘DST 원칙’이 존재합니다. 이 원칙들은 최대한 컴포넌트 자체에 내장하여 자동화하고, 컴포넌트로 해결되지 않는 부분은 디자이너들이 직접 원칙을 익혀 디자인에 적용하는 방식으로 완성됩니다.
토스가 아닌 우리를 위한 현실적인 대안
그렇다면 토스가 아닌 우리는 어떻게 DST와 같은 효과를 얻을 수 있을까요?
우리만의 DST를 처음부터 설계하고 구축해야만 생산성을 높일 수 있는지 막막하게 느끼는 분들이 많을 겁니다.
실제로 자체적인 DST를 정의하고, 구조화하고, 규칙을 만드는 것은 기존에 우리가 고민했던 디자인 시스템 구축보다 훨씬 더 어렵고 많은 리소스가 드는 일입니다. 토스가 그들의 노하우를 상세히 공개할 가능성도 현재로서는 낮아 보입니다.
하지만 방법이 없는 것은 아닙니다. 해답은 의외로 우리에게 이미 친숙한 기능에 있습니다. 바로 피그마의 오토레이아웃(Auto Layout)을 체계적으로 활용하는 것입니다.
최근 주목받는 바이브 코딩 서비스나 또는 웹빌더, 디자인 투 코드 서비스들을 살펴보면 이 사실을 더 명확히 알 수 있습니다.
Lovable, Framer, 볼트에이아이, 커서 같은 서비스들은 피그마 디자인을 코드로 변환할 때, 좋은 품질의 결과물을 위해 몇 가지 사항을 공통적으로 요구합니다. 바로 '오토레이아웃의 적극적인 사용'과 '명확한 레이어 이름 규칙(Naming Convention)' 등 입니다.
내용을 정리해 보면 다음과 같습니다.
- 체계적인 오토레이아웃 사용 (모든 요소에 '잘' 사용할 것)
- 명확한 레이어 이름 지정
- 일관된 스타일 사용
- 디자인 시스템 사용
눈치채셨나요?
여기서 가장 중요한 1번(체계적인 오토레이아웃)과 2번(명확한 네이밍)에 대한 규칙을 명확히 정의하고, 이를 구조적으로 잘 활용하는 것이 바로 토스의 DST와 같은 결과를 만들어내는 핵심 열쇠입니다.
진짜 생산성을 위한 다음 단계
물론, 이 규칙들을 어떻게 토큰, 컴포넌트처럼 디자인 시스템의 한 요소로 만들지에 대해서는 더 상세한 설명이 필요합니다.
또한 오토레이아웃을 체계적으로 사용해 본 디자이너라면, 이 작업이 얼마나 꼼꼼함을 요구하며 리소스가 많이 드는지 잘 아실 겁니다.
저희는 이 복잡하고 반복적인 규칙 적용을 효율화하고 손쉽게 하는 명쾌한 해답을 가지고 있습니다. 여러분의 팀이 겪는 어려움을 해결할 방법에 대해 궁금하시다면, 주저 말고 저희에게 연락 주세요.
다음 콘텐츠에서는 오늘 강조한 1번(오토레이아웃 규칙)과 2번(레이어 네이밍 규칙)을 어떻게 구체적으로 정의하고 시스템화할 수 있는지에 대한 상세한 가이드를 제공해 드리겠습니다.
