버튼 하나 만드는데 왜 회의를 두 번이나 해야 했을까. 디자인은 완성됐는데, 왜 구현된 화면은 제각각이었을까. 토스는 이런 반복적인 갈등과 누수를 줄이기 위해 디자인 시스템이라는 구조화된 해법을 꺼내 들었다.
이 글은 그 디자인 시스템이 어떤 문제들을 짚어내고, 어떻게 해결의 틀로 확장되었는지를 정리한 여정이다.
같은 버튼을 또 만들었다?! — 반복과 혼돈의 UI 시대
화면마다 조금씩 다른 버튼, 왜 그럴까?
어떤 앱을 쓰다 보면 이런 생각이 든다. “이 버튼, 저번 화면에선 더 둥글었던 것 같은데…?” “왜 이 페이지만 글꼴이 다르지?” 이런 미묘한 차이는 의외로 흔하다. 동일한 브랜드, 동일한 서비스인데도 화면마다 UI 요소가 조금씩 다른 이유는 단순하다. ‘통일된 기준’이 없었기 때문이다.
디자이너는 각자 스타일대로 그리고, 개발자는 전달받은 디자인을 본인의 기준에 맞춰 구현한다. 이런 과정이 반복되면 같은 버튼이라도 스크린마다 다른 얼굴을 가지게 된다. 겉으로는 별 문제 없어 보여도, 이건 브랜드 신뢰도와 유지보수 효율성에 영향을 미치는 조용한 누수가 될 수 있다.
디자이너가 남기고 간 설명서의 무게
이런 비일관성을 막기 위해 디자이너는 ‘설명’에 많은 시간을 들인다. 실제로 어떤 팀에서는 A4 수 페이지에 달하는 디자인 해설서를 함께 전달하는 경우도 있다. 이 버튼은 어떤 상황에서만 써야 하며, 여백은 몇 px로 고정하고, 예외 상황은 무엇인지 등…
하지만 문제는, 이런 문서를 매번 쓰기 어렵다는 것이고, 더 큰 문제는, 읽는 사람이 다 읽지 않는다는 것이다. 결국 개발자는 이전 작업을 기억에 의존해 구현하고, 디자이너는 “그건 제가 의도한 게 아닌데요…”라는 말을 속으로 삼킨다.
통일되지 않은 UI는 협업에도 균열을 만든다
디자인의 일관성 부족은 단순히 ‘예쁜 디자인이 아니다’라는 차원의 문제가 아니다. 이건 협업 전반에 영향을 미치는 구조적인 리스크다. QA는 같은 기능을 여러 화면에서 중복 테스트해야 하고
- 신규 디자이너는 기존 스타일을 파악하는 데만 수일이 걸리며
- 디자이너가 퇴사하면, 다음 사람은 UI 히스토리를 추리해야 한다
이런 경험이 쌓이면 팀 전체가 피로감을 느끼게 된다. 외부에서 봤을 때도, 해당 조직은 어느 시점에 이런 악순환을 멈추기 위해 근본적인 정리와 구조화에 나섰을 가능성이 크다.
디자인 시스템, ‘도입’은 시작일 뿐
그렇게 만들어진 TDS, Toss Design System
2018년 말, 토스는 이러한 문제를 해결하기 위해 자체 디자인 시스템을 정식 도입했다. 이 시기, 토스는 여러 서비스와 팀이 동시에 확장되던 시점이었다.
TDS(Toss Design System)라고 불리는 이 시스템은, 단순한 디자인 가이드가 아닌, 실제 UI 구현에 사용할 수 있는 재사용 가능한 규칙 체계로 보인다. 공식 발표를 보면, TDS의 도입 목적은 다음과 같은 문제들을 해결하는 데 초점이 맞춰져 있었다.
- 디자이너가 늘어날수록 컴포넌트 종류도 제각각 늘어났다
→ 한 기능을 위해 수십 개 버튼이 생겼고, 툴팁이나 카드 구성도 통일되지 않았다. - 디자인 자산의 재사용성이 떨어졌다
→ “지난번에 만든 카드, 다른 팀에서 또 만들고 있어요”라는 사례가 반복되었다. - 신규 디자이너의 온보딩 속도가 느렸다
→ 기존 디자인 기준이 명확히 정리되지 않아, 새로 들어온 디자이너가 화면의 논리를 파악하는 데 수일이 걸렸다.
이런 문제들은 단순히 ‘디자인 통일성’의 문제가 아니었다. 디자인과 개발 간 협업 속도를 떨어뜨리고, QA 비용을 높이며, 전체 생산성을 저하시킨 구조적인 병목이었을 것이다.
TDS는 단순한 매뉴얼이 아니었다
TDS는 ‘세 가지 축’으로 정리된 설계 체계로 구성돼 있었다.
- 컴포넌트 라이브러리
토스는 디자인 시스템을 만든 게 아니라, 누구나 같은 방식으로 만들 수 있는 환경을 만든 것에 가까웠다. 그 중심에는 ‘컴포넌트 라이브러리’가 있었다. 버튼, 카드, 모달, 툴팁 등 화면에 자주 등장하는 UI 요소들을 정형화된 컴포넌트로 코드화하고, 속성 조합만으로 다양한 형태와 상황에 대응할 수 있게 설계했다.
예를 들어 버튼 하나에도 기본, 비활성, 로딩 상태가 있고, 컬러나 크기 역시 용도에 따라 달라진다. 이걸 매번 새로 만들지 않고, 코드 속성만 바꿔서 바로 불러올 수 있도록 만든 것이 핵심이다. 개발자는 일관된 UI를 빠르게 구현할 수 있고, 디자이너는 이전에 썼던 요소를 다시 정의하지 않아도 된다. ‘디자인을 전달’하는 게 아니라 ‘같은 부품을 쓰는’ 방식으로 바뀐 셈이다. - 스타일 가이드
디자이너가 많아지면 자연스럽게 생기는 게 있다. 같은 요소인데도 다르게 생긴 버튼, 제목, 여백이다. 보기엔 큰 차이가 없지만, 화면이 늘어날수록 유지보수는 지옥이 된다. 그래서 토스는 디자인 툴 안에 스타일 토큰 시스템을 구축했다. 색상, 텍스트, 여백, 그림자 등을 역할 기반으로 토큰화한 것이다.
예쁘게 정리된 PDF 가이드는 필요 없었다. 디자이너가 선택하는 순간부터 시스템이 기준을 적용하도록 만들었다. 텍스트는Title 01,Body 03,Caption처럼 용도에 따라 정리됐고, 여백도spacing-4x,spacing-8x처럼 정해진 규칙이 있었다.
spacing은 8pt 단위로 통일돼 있었고, 컬러는 브랜드·중립·상태 기반으로 목적별 구분되어 있었다. 스타일을 ‘선택’하는 게 아니라 ‘결정된 것 중 고르는’ 방식으로 바뀌었다. 덕분에 디자이너끼리 충돌이 줄었고, 화면 간 톤앤매너가 안정되기 시작했다. - 디자인 원칙
디자인 시스템은 ‘어떻게 생겼는지’보다 사실 ‘언제, 왜 써야 하는지’가 더 중요하다. 예쁜 버튼이 있어도, 아무 데나 쓰면 오히려 더 혼란스럽다. 토스는 컴포넌트의 형태뿐 아니라, 사용하는 맥락까지 함께 정의했다. 어떤 상황에 어떤 요소를 써야 하는지, 실제 제품을 만들면서 반복된 경험을 기준으로 원칙을 만들고 공유한 것이다. 예를 들어 이런 규칙들이 있다.
▶ 주요 행동에는 항상 모달을 띄워 한 번 더 묻는다
▶ 화면에 버튼이 두 개 이상 있다면, 오른쪽이 primary다
▶ 정보 전달용 메시지는 토스트로 보여주되, 시간과 줄 수를 제한한다
이런 기준은 디자이너뿐 아니라 기획자와 개발자도 함께 참조했다. “왜 이렇게 만들었는지” 설명하는 대신, “토스는 원래 이렇게 해요”라는 합의된 룰이 생긴 셈이다. 그 결과, 팀마다 UI 스타일이 엇갈리는 일도 줄었고, 신규 입사자도 시스템 안에서 더 빠르게 적응할 수 있었을 것이다.
이 시스템이 “일관성 있는 UI를 위한 코딩 가능한 헌법”으로 작용했을 가능성이 높다고 해석할 수 있다.
토스는 이 시스템을 단순한 UI 통일 수단이 아니라, 조직 전체의 실행력을 높이는 생산성 도구로 정의 했다. ‘어떻게 생겼는가’를 정리하는 데 그치지 않고, ‘언제, 왜 이 컴포넌트를 써야 하는가’까지 디테일하게 규칙으로 만든 점, 그리고 이후 자동화 시스템(DST, DSL 등)과 연결될 수 있도록 구조적으로 설계한 점은 일반적인 디자인 시스템과 달랐던 토스 TDS만의 분명한 깊이있는 지점이었다.
“제품 개발 속도가 몇 배로 가속되고 사용자에게 일관된 UX를 제공하는 효과를 거두었다.”
— 전자신문, 2019년 보도
문제는 또 다른 곳에 있었다 — 툴의 단절
하지만 디자인 시스템이 도입되었다고 해서 모든 게 해결되지는 않았다.
실제 작업 흐름을 보면, 디자이너는 Sketch에서 디자인하고, Abstract로 버전 관리하고, Zeplin으로 개발자에게 전달하고, Storybook에서 구현 여부를 확인하는 식이다.
툴이 많아질수록 의도는 툴 사이에서 조금씩 증발하게 된다. 그리고 여전히 마지막엔 개발자가 그림을 해석해 코드를 짜야 했다. 이러한 도구 간 단절은 디자이너와 개발자 간 ‘해석 비용’을 유발하는 대표적인 지점이었을 것이다.
“Storybook을 통해서도 각 요소가 어떻게 작동하는지를 확인해야 했습니다.”
— 강수영, 토스 디자인 플랫폼팀 리더
그림에서 구조로, 구조에서 코드로
“디자인이 그림이 아니라 코드처럼 작동한다면?”
툴 사이의 단절과 해석 비용이 여전히 존재하던 당시, 토스는 내부적으로 새로운 방향을 모색한 것으로 보인다. 공식 발표를 통해 밝혀진 바에 따르면, 이 시점에서 도입된 도구가 바로 Framer였다. Framer는 기존의 Sketch 같은 정적 디자인 툴과 달리, 실제로 작동하는 인터랙션 UI를 설계할 수 있는 프로토타이핑 툴이다.
“디자이너가 코드를 모르더라도, 실제 코드 기반 컴포넌트를 가져다 놓기만 하면 바로 화면이 만들어지는 툴을 도입했습니다.”
— 토스 디자인플랫폼팀 공식 발표 (2021)
- 버튼을 누르면 애니메이션이 실행되고
- 리스트가 길어지면 스크롤이 발생하며
- 상태 변화(로딩, 오류 등)도 직접 구현할 수 있었다
이는 디자이너가 만든 결과물이 곧 ‘기능을 시뮬레이션하는 UI’가 되었다는 점에서 중요한 전환으로 해석된다.
디자인을 기계가 ‘읽을 수 있다면’ — DST와 TDSL
토스는 프레이머를 도입하면서 UI 구현 효율을 크게 끌어올렸다. 하지만 프레이머만으로는 여전히 ‘자동 코드화’에 이르지 못했다. 왜일까? 프레이머에서 만들어진 UI는 시각적으로 완성된 것처럼 보이지만, 그 아래에는 여전히 사람이 해석해야 하는 여백이 남아 있었다.
- 컴포넌트의 역할은 무엇인지
- 이 간격은 의미 있는 margin인지, 임시 배치인지
- 반복되는 요소인지, 단일 인스턴스인지
이런 정보들은 디자이너 머릿속에만 존재했고, 결국 개발자가 그림을 보고 다시 구조를 추론해야 했다.
이 시점에서 토스는 아마도 다음 단계의 자동화를 이룰 수 있는 방법을 고민했을 것이다. “디자이너가 만든 화면을 사람이 아닌 기계가 직접 읽고 코드로 바꿀 수 있다면 어떨까?” 이런 배경 아래 등장한 것으로 보이는 개념이 바로 DST(Design Syntax Tree)다.
DST는 UI 화면을 구성하는 모든 요소를 계층적 트리 구조로 직렬화한 데이터 포맷이다.
- 어떤 요소가 어떤 속성을 갖고
- 어디에 배치돼 있고
- 어떤 관계로 연결되어 있는지를
기계가 그대로 읽을 수 있도록 구조화한 것이다.
“DST는 결국 ‘사람 눈으로 보지 않아도 구조를 기계가 읽을 수 있게 하자’는 시도였습니다.”
— SLASH 22 발표 중
이렇게 기계가 이해한 디자인 시스템(DST)을 실제 코드로 구현하는 과정에서 새로운 과제가 발생했다. DST가 담고 있는 방대한 정보를 XML과 같은 데이터 형태로만 전달하면 그 양이 너무 많고 복잡하다. 그렇다고 React나 Swift와 같은 특정 프레임워크에 종속된 코드로 변환하면, 다른 언어를 사용하는 개발자(예: Java 개발자)는 그 코드를 다시 해석하고 변환해야 하는 비효율이 발생한다.
이러한 문제를 해결하기 위해 TDSL(Toss Domain Specific Language)이 탄생했다. TDSL은 DST, 즉 기계가 이해한 디자인을 **모든 개발자가 자신의 주력 언어와 상관없이 공통적으로 빠르고 직관적으로 이해할 수 있도록 만든 ‘중간 단계의 약속된 언어’이다.
결론적으로, 'DST가 '디자인을 기계가 이해할 수 있도록 정의한 상세 명세'라면, TDSL은 '기계가 이해한 내용을 여러 플랫폼의 개발자들이 공통적으로 이해하고 빠르게 코드로 구현할 수 있도록 만든 효율적인 소통 언어'라고 할 수 있다.
뿐만 아니라, 기존에는 수십 줄의 XML, 속성 나열이 필요했던 버튼 하나가 단 한 줄의 선언형 코드로 간결하게 끝나게 된다. 디자이너는 구조만 만들고, DST와 TDSL이 이를 자동으로 코드화하며, 개발자는 그 위에서 비즈니스 로직만 신경 쓰게 되는 구조가 된다.
쉽게 말해,
- 디자이너가 만든 UI → DST로 구조화
- DST → TDSL 문법에 따라 코드로 자동 변환
- 플랫폼(Android, iOS 등)에서 실제 UI로 출력
이라는 구조다.
이 흐름은 디자인 시스템의 실행력과 생산성에 근본적인 변화를 준 전환점으로 보인다.
"우리는 DST를 통해 디자이너가 만든 화면을 기계가 읽을 수 있게 바꿨습니다.
그리고 TDSL로 표현해서, 개발자가 바로 활용할 수 있게 했습니다."
— 강수영, Product Design Lead (Toss Slash 21 발표)
TDS Coverage: 디자인 시스템을 ‘정착’시킨 비결
디자인 시스템이 아무리 훌륭하게 설계되어 있어도, 실제 업무에서 모든 디자이너가 일관되게 사용하는 것은 또 다른 문제다. 특히 디자이너가 많고 화면도 많은 조직에서는, 시스템 도입보다 ‘정착’이 더 어렵다.
토스는 이 문제를 해결하기 위해 TDS Coverage라는 내부 도구를 도입했다. 말 그대로, 하나의 디자인 시안 안에 TDS 컴포넌트가 얼마나 쓰였는지를 자동으로 분석해주는 기능이다.
- 디자이너가 사용하는 컴포넌트 중 TDS에 포함된 비율을 실시간 수치로 환산
- 일정 기준 이하일 경우, 리마인더를 통해 개선 필요 메시지 노출
- 팀 내 커버리지 점수가 비교·공유되어 내부 동기부여 요소로도 작동
이 수치는 단순한 숫자 이상의 의미를 가진다. 디자인 시스템의 활용도가 높다는 것은 곧 재사용성과 일관성이 유지되고 있다는 증거이며, 이 데이터가 쌓이면 조직의 디자인 품질을 수치로 모니터링할 수도 있다.
“TDS Coverage 도입 이후 디자인과 코드의 일관성이 눈에 띄게 향상되었고, TDS의 활용도도 확실히 증가했다.”
— 토스 디자인팀 내부 발표, 「TDS Coverage 효과 분석」, 2022
이 기능은, 디자인 시스템을 한때의 캠페인이 아니라 ‘일상의 습관’으로 정착시키는 핵심 장치로 해석될 수 있다. 아무리 좋은 시스템도 쓰이지 않으면 소용없기 때문에, ‘얼마나 쓰이고 있는가’를 보여주는 메커니즘은 디자인 시스템의 지속성을 좌우하는 열쇠일 수 있다.
그 외: UX Writing, UX Acting
문장 하나로도 브랜드가 흔들린다 — Voicetone Maker의 역할
시각과 코드가 통일되었을 무렵, 토스는 UX에서 또 하나의 중요한 요소를 시스템화 한 것으로 보인다. 그건 바로 텍스트, 디자인이 아무리 통일되어도 화면마다 말투가 달라지면 전체 경험이 산만해질 수 있다.
- “회원 가입 완료되었습니다.”
- “가입이 완료됐어요!”
- “가입하셨습니다.”
뉘앙스 하나로 사용자 인식은 완전히 달라질 수 있다. 이 지점에서 등장한 것이 Voicetone Maker다. 공개된 설명에 따르면, 이 시스템은 다음과 같은 기능을 한다:
- 브랜드 어법과 맞지 않는 문장을 실시간 감지
- 어색하거나 어려운 단어에 대해 자연스러운 대안 제안
- 마침표, 문장 어미, 표현 방식까지 세밀하게 교정
이 도구가 디자이너와 기획자 모두가 ‘브랜드의 목소리’를 유지하도록 돕는 시스템으로 작동하고 있다고 평가할 수 있다.
감각까지도 시스템으로 — 인터랙션과 햅틱의 자동화
텍스트가 자동화되었다면, 그 다음은 감각이다. 디자인 시스템이 단순한 레이아웃 툴을 넘어 사용자 경험의 질감까지 규정하려 했다는 점은 주목할 만하다. 공개된 사례에 따르면 토스는 다음과 같은 인터랙션 피드백까지도 시스템에 포함시켰다:
- 버튼 클릭 시 짧은 진동(햅틱)
- 리스트 페이드 효과, 전환 시 애니메이션
- 스프링 물리값 기반의 부드러운 화면 이동
과거에는 개발자가 일일이 설정해야 했던 요소들이다. 하지만 이제는 컴포넌트 속성에서 몇 개의 값을 조정하는 것만으로 구현 가능한 것으로 보인다. 이는 디자인 시스템이 ‘디자인 언어’가 아닌 ‘감각의 언어’로 확장된 예시로 해석될 수 있다.
설명이 사라진 협업? — Deus가 만들 낯선 풍경
이 모든 여정의 끝에서, 토스는 또 하나의 내부 제작 도구를 개발 중인 것으로 알려져 있다. 이름은 Deus(데우스). 공식적으로는 디자인 편집기라고 소개되지만, 공개된 인터뷰와 기술 자료를 보면 이는 단순한 툴이라기보다 제작 환경 그 자체로 보인다.
- 디자이너가 만든 UI가 실제로 작동하며
- 렌더링과 코드는 동기화되고
- 디자이너와 개발자는 같은 화면을 실시간으로 다룬다
핸드오프, 문서 전달, 코멘트 정리… 이런 절차가 필요 없어질 수도 있다. Deus는 협업 과정의 ‘설명 비용’을 제거하려는 토스의 마지막 조각처럼 느껴진다.
디자인 시스템의 종착지는 ‘말하지 않아도 되는 팀’?
디자인 시스템은 단순히 UI를 예쁘게 통일하기 위한 도구가 아니다. 협업에서 발생하는 수많은 커뮤니케이션 비용을 구조적으로 제거하기 위한 도구다. 토스의 사례를 통해 알 수 있는 점은 다음과 같다:
- TDS는 룩앤필을 통일하는 도구에서 시작했지만
- DST와 TDSL로 구조와 코드를 자동화하고
- Voicetone Maker와 인터랙션 설정으로 감각과 언어를 통합하며
- TDS Coverage로 디자인과 코드의 일관성과 실무자의 활용도를 유지한다
- 심지어는 Deus를 통해 협업 자체의 방식을 재정의하려고 한다
물론, 모든 조직이 이런 도구를 직접 만들 수는 없다. 하지만 토스의 접근 방식은 하나의 중요한 질문을 던진다.
“우리는 아직도 서로 설명하느라 바쁘지 않은가?”
그렇다면, 그게 바로 디자인 시스템이 필요한 순간일지도 모른다.
