- Published on
디자인 토큰 기반 설계
- Authors
- Name
왜 디자인 토큰 기반 설계인가?
Design Token Based UI Architecture
디자인 토큰은 데이터로서의 디자인 결정이며, 디자인과 엔지니어링을 위한 SSOT 역할을 합니다. 배포 파이프라인을 활용하여 플랫폼 간에 자동화된 코드 생성을 가능하게 하여 더 빠른 업데이트와 디자인의 일관성을 개선할 수 있습니다. 토큰을 계층으로 구성하면(사용 가능한 옵션에서 적용 방법을 포착하는 토큰으로 진행) 확장성과 더 나은 개발자 경험이 보장됩니다.
일관성 보장
- 여러 플랫폼과 애플리케이션 전반에 걸쳐 디자인 일관성 유지
- 디자인 결정에 대한 단일 진실 원천(Single Source of Truth) 제공
효율적인 디자인 변경 관리
- 디자인 업데이트를 신속하게 전파 가능
- 자동화된 배포 파이프라인을 통한 빠른 변경 적용
- 여러 팀과 플랫폼에 걸쳐 디자인 변경 사항을 효율적으로 관리
협업 개선
- 디자이너와 개발자 간의 원활한 커뮤니케이션 지원
- 공통된 디자인 언어 제공
- 여러 팀 간의 효과적인 협업 가능
확장성
- 대규모 프로젝트나 다중 플랫폼 환경에서 효과적
- 체계적인 디자인 시스템 구축 가능
- 유지보수가 용이
다중 플랫폼 환경과 빈번한 디자인 변경이 필요한 경우 디자인 토큰 기반 아키텍처가 도움이 될 수 있습니다.
디자인 토큰의 역할이란
서비스가 커지면 커질수록 UI 디자인 변경 결정으로 인해 디자이너와 개발자간의 소통 비용이 많이 발생해집니다.
예를들어 버튼안에 들어가는 텍스트의 사이즈 변경이 필요하다고했을떄 타이포그라피도 함께 변경되어야한다고 생각하는 경우가 많습니다.
// AS-IS
const buttonStyle = {
fontSize: '16px'
}
const typographyStyle = {
fontSize: '16px'
}
// TO-BE
const token = {
typography: {
size: {
md: '16px'
}
}
}
const buttonStyle = {
fontSize: token.typography.size.md
}
const typographyStyle = {
fontSize: token.typography.size.md
}
이러한 문제는 디자인 토큰으로 디자인 결정을 통일하고 디자인 변경 사항을 효율적으로 관리할 수 있습니다.
위의 디자인 토큰은 애플리케이션에서 사용할 수 있는 값의 집합을 나타내며, typography.size.md는 개발자에게 토큰을 어디에 사용할지에 대해 좋은 아이디어를 제공합니다. 동시에 디자이너와 개발자간의 소통 비용도 감소시킬 수 있습니다.
이런 토큰 작업은 디자이너의 워크플로우에 통합될수도있으며, 각 플랫폼에 요구하는 형식으로 코드를 제너레이팅 하는 좋은 방법이 되기도합니다.
:root {
--typography-size-md: 16px;
/* ...그외의 토큰들 */
}
const token = {
typography: {
size: {
md: 'var(--typography-size-md)'
}
}
}
디자인 토큰은 디자이너, 개발자 그리고 프로덕트 팀 모두가 소통하는 언어로 사용됩니다. 디자인 결정에 대한 SSOT 역할을 하기도하며 모든 사용자가 같은 경험을 가지는것을 보장합니다.
디자인 단일 진실 공급원 구축
디자인의 일관성 유지와 프론트엔드 개발자 리소스 투입없이 Figma에서 변경된 디자인이 프론트엔드에 적용되는것을 목표로합니다. 그리고 커뮤니케이션의 비용 절약 및 각자의 역할에 집중하는것을 목표로합니다.
피그마에서 디자이너가 정의한 local variables 혹은 local styles을 많이 볼 수 있습니다. 이러한 값은 피그마에서 정의되고 피그마에서만 사용되는 값입니다. 이 값들이 어떠한 파이프라인을 타고 개발자의 코드에도 적용될수있는 설계가 가능해진다면 디자인 토큰 기반 아키텍처를 구축할 수 있습니다.
design-tokens 라이브러리를 통해 피그마에서 정의된 토큰을 깃허브 레포지토리에 이벤트 생성이 가능합니다.
디자이너가 토큰을 변경하면, 토큰이 변경되었다고 개발자에게 알려야합니다. 하지만 파이프라인을 만들어둔다면 개발자에게 구두로 전달할 필요없이 파이프라인이 자동으로 토큰을 변환하고 풀리퀘스트를 생성합니다.
파이프라인(깃허브 워크플로우)은 링크에서 확인 가능합니다.
위의 이미지는 사내에서 테스트로 만들었던 파이프라인이 토큰을 변환하고 풀리퀘스트를 생성한 모습입니다.
토큰은 JSON 형식으로 저장되며, 토큰 파일을 개발자가 사용가능한 형태로 만들어야합니다. Style Dictionary와 같은 도구를 사용하여 디자인 토큰 파일을 플랫폼에 맞게 변환해야합니다. 그리고 변환된 토큰은 스토리북과 같은 문서화 도구를 사용하여 생성된 코드를 테스트해야합니다.
토큰의 모니터링
완전 자동화된 파이프라인은 떄로는 온전한 품질을 기대하기 어려울때가 있습니다. 토큰이 빌드되어 개시되기 전 수동검토가 필요한 경우 최신 디자인 토큰이 포함된 업데이트 버전을 임시환경에 배포하여 테스트해보는 것도 좋은 방법이 될수있습니다.
- 스토리북과 같은 문서화 도구를 사용하여 토큰이 적용된 코드를 테스트해보는것도 좋은 방법이 될수있습니다.
- 임시환경(개발환경)에 배포하여 테스트해보는것도 좋은 방법이 될수있습니다.
그럼 지금까지 토큰이 어떻게 디자이너의 영역인 피그마에서 개발자의 영역인 코드에 적용되어야 하는지에 대해서 알아보았습니다.
토큰 잘 구성하기
디자인 토큰은 데이터입니다. 개발자가 모든 변수를 동일한 수준에서 사용하지 않는것처럼 디자인 토큰도 동일한 수준의 세부 사항에서 작동하는 것이 아닙니다.
토큰을 다양한 계층으로 구성하면 디자이너가 적절하게 토큰을 추상화하여 결정을 내려 일관성과 확장성을 지원할 수 있습니다.
Option Token
예시 들어, blue와 gray 9가지의 음영이 있는 색상 팔레트가 있다고 가정해봅시다. 매우 밝은것부터 채도가 높은것까지 매우 다양합니다. 이를 토큰으로 정의하면 아래와 같은 형태입니다.
{
"colors": {
"$type": "color",
"options" : {
"blue100": {"$value": "#e0f2ff"},
"blue200": {"$value": "#cae8ff"},
"blue300": {"$value": "#b5deff"},
"blue400": {"$value": "#96cefd"},
"blue500": {"$value": "#78bbfa"},
"blue600": {"$value": "#59a7f6"},
"blue700": {"$value": "#3892f3"},
"blue800": {"$value": "#147af3"},
"blue900": {"$value": "#0265dc"},
"gray100": {"$value": "#f8f8f8"},
"gray200": {"$value": "#e6e6e6"},
"gray300": {"$value": "#d5d5d5"},
"gray400": {"$value": "#b1b1b1"},
"gray500": {"$value": "#909090"},
"gray600": {"$value": "#6d6d6d"},
"gray700": {"$value": "#464646"},
"gray800": {"$value": "#222222"},
"gray900": {"$value": "#000000"},
"white": {"$value": "#ffffff"}
}
}
}
위와 같은 토큰은 합리적인 옵션을 갖고있지만, 옵션 토큰만으로는 개발자가 옵션을 어떻게 어디에 적용해야할지는 알 수 없습니다.
Decision Token
Decision Token은 Option Token이 UI에서 상황에 맞게 어떻게 적용되어야 하는지 지정합니다.
- gray100 색상은 배경색으로 사용됩니다.
- gray200 색상은 비활성화된 요소의 배경색으로 사용됩니다.
- gray400 색상은 비활성화된 요소의 텍스트 색상으로 사용됩니다.
- gray900 색상은 텍스트의 기본 색상으로 사용됩니다.
{
"colors": {
"$type": "color",
"decisions" : {
"surface": {
"$value": "{colors.options.gray100}",
"$description": "배경색으로 사용됩니다."
},
"background-disabled": {
"$value": "{colors.options.gray200}",
"$description": "비활성화된 요소의 배경색으로 사용됩니다."
},
"text-disabled": {
"$value": "{colors.options.gray400}",
"$description": "비활성화된 요소의 텍스트 색상으로 사용됩니다."
},
"text-primary": {
"$value": "{colors.options.gray900}",
"$description": "텍스트의 기본 색상으로 사용됩니다."
}
}
}
}
이러한 토큰은 개발자가 옵션을 어떻게 어디에 적용해야할지 알 수 있습니다. 색상 토큰은 목록이 정말 많지만, 이러한 옵션 중 실제로 우리가 사용해야하는 옵션은 매우 적습니다. 적용할 스타일을 결정할 때 실제로 관련성이 있는 토큰은 일반적으로 Decision Token입니다.
Decision Token은 Option Token에 대한 참조를 사용하기때문에 이러한 방식이 Token Based Architecture를 구축하는데 도움이 됩니다.
토큰 계층 구성
마틴 파울러의 블로그에서 몇 계층을 사용해야하는 가이드합니다.
- 3계층 아키텍처는 최고의 개발자의 경험을 제공하는 반면, 새로운 컴포넌트와 토큰이 도입되므로 유지보수와 관리포인트가 증가합니다.
- 2계층 아키텍처는 주요 디자인 결정이 이미 자리 잡고 있거나 비교적 안정적인 프로젝트의 경우 좋은 선택입니다.
디자인 토큰 기반 아키텍처는 단순히 디자인 시스템을 구축하는 것 이상의 가치를 제공합니다. 이는 디자이너와 개발자 간의 효율적인 협업을 가능하게 하고, 일관된 사용자 경험을 보장하며, 디자인 변경 사항을 효과적으로 관리할 수 있게 해줍니다.
Option Token과 Decision Token의 계층화된 구조를 통해 우리는 더 체계적이고 확장 가능한 디자인 시스템을 구축할 수 있습니다. 특히 자동화된 파이프라인과 결합하면, 디자인 변경사항이 코드로 자연스럽게 흘러들어가는 효율적인 워크플로우를 만들 수 있습니다.
마틴 파울러가 제시한 것처럼, 프로젝트의 상황과 요구사항에 따라 2계층 또는 3계층 아키텍처를 선택할 수 있습니다. 중요한 것은 팀의 현재 상황과 미래의 확장성을 고려하여 적절한 구조를 선택하는 것입니다.
이러한 토큰 기반 설계는 단순히 기술적인 선택이 아닌, 더 나은 제품을 만들기 위한 전략적 결정이 될 수 있습니다. 디자인 시스템을 구축하고 관리하는 방식을 개선하고 싶다면, 디자인 토큰 기반 아키텍처의 도입을 진지하게 고려해볼 만한 가치가 있습니다.