달리는 기차 바퀴 칠하기: 7년만의 컬러 시스템 업데이트
안녕하세요, 토스 디자인 플랫폼팀 UX Engineer 윤민석, Platform Designer 권윤입니다.
디자인 시스템은 변화하는 서비스 속에서도 일관성과 확장성을 지켜주는, 보이지 않는 인프라예요. 토스팀도 미세한 균형 속에서 더 넓은 세상으로 확장할 준비를 해왔는데요. 그 여정의 출발점이자, 더 큰 변화를 위한 기반이 된 것이 바로 컬러 시스템 개편이었어요.
이번 글에서는 TDS(Toss Design System)의 핵심 중 하나인 컬러 시스템을 7년 만에 전면 개편하며 마주했던 문제들과, 이를 해결하기 위해 토큰 시스템을 처음부터 다시 만들어간 과정을 공유하려고 해요.
7년간 외면해온 문제들
TDS 컬러 시스템은 2018년 디자인 시스템이 처음 만들어졌을 때부터 큰 변화 없이 유지되어 왔어요. 7년 동안 컬러 토큰을 사용하면서 여러 문제를 마주했는데요, 특히 컬러 팔레트에서 발견한 문제가 많았어요.
첫 번째 문제는 컬러끼리 명도가 다 달랐다는 거예요. 같은 100인데 Grey 100, Blue 100, Red 100의 명도가 다 달라서, 리스트에서 같이 썼을 때 전부 100으로 통일해도 얼룩덜룩해 보이는 문제가 있었어요. 실제로 Grey 100은 1.1:1 대비인데, Red 100은 1.34:1이었죠.
라이트모드와 다크모드의 명도 기준도 많이 달랐어요. 같은 Teal 50을 썼는데도 라이트모드에서는 1.06:1이고 다크모드에서는 1.36:1이어서, 다크모드에서만 너무 튀는 색이 되었어요. 그래서 디자이너들은 보통 라이트모드를 기준으로 디자인하다가 다크모드에서 의도치 않은 색이 나와서 당황하고, 다크모드 색을 커스텀하는 경우도 많았어요.
즉, 2가지 색상만 써도 4가지 케이스(라이트 Grey, 라이트 Blue, 다크 Grey, 다크 Blue)를 모두 고려하며 만들어야 하는 상황이 지속적으로 반복되었죠.
두 번째로는 접근성 문제가 있었어요. TDS 컬러들은 해상도가 낮은 디바이스나 가상환경에서도 쓰이게 되는데요, 이때 밝은 컬러들이 다 날아가서 보이지 않는 경우도 있었어요.
이런 문제들이 사실 디테일하고 작은 문제들처럼 보이지만, 모여서 결국 디자인 완성도와 업무 효율성을 떨어뜨리고, 커뮤니케이션 비용을 높이고 있었어요.
왜 개선하지 못했을까
앞선 문제들을 해결하기 위한 첫 번째 시도는 간단해 보였어요. 같은 100인데 Blue 100이 더 진해서, Blue 100을 더 밝게 바꿔보는 거예요.
그런데 사실 Grey 100, Blue 100은 큰 팔레트의 일부잖아요. 부분의 변경사항이 있을 때, 팔레트를 구성하는 다른 컬러 토큰들에서 문제가 발생하기 쉬워요. Blue 100만 고쳤더니 Red 100, Yellow 100, Green 100도 같이 봐야 하고, Blue 컬러 전체의 명도 진행도 다시 고려해야 했어요. 게다가 다크모드 팔레트까지 하면, 고려할 점이 곱하기 2가 돼요.
결국 컬러 팔레트의 문제를 해결할 때는 작은 부분의 문제를 해결할 때에도 전체 팔레트를 건드려야 해요.
TDS 토큰에 있었던 또 하나의 문제는, 토큰이 수많은 사용처에서 각각 따로 관리되고 있었다는 거예요. 보통 Single Source of Truth를 추구하지만, 정확히 그 반대의 상황이었어요. 웹, 네이티브, 서버, 데우스(Design Editor) 등에서 각자 컬러를 관리하고 있고 스펙이 조금씩 달라서 추적이 어려웠어요.
이런 구조 때문에 새로운 토큰을 추가한다고 가정했을 때, 모든 플랫폼의 개발자, 다른 계열사의 플랫폼 디자이너, 디자인 에디터인 데우스팀까지 불러모아 소통해야 하는 엄청난 비효율이 생겼어요. 그리고 이 과정에서 플랫폼별로 이격이 발생하기 쉬웠죠. 실제로 "데우스에는 있고 iOS에는 없는 토큰이 있는데 뭐예요?" 같은 문의가 많았어요.
모든 플랫폼의 토큰이 다른 곳에서 관리되고 있다면 하나의 소스를 바라보게 하면 되잖아요. 근데 그러기 위해서는 되게 많은 기반 작업이 필요했어요.
그래서 앞의 두 가지 문제들을 해결하기 위한 솔루션은 리소스가 꽤 많이 드는 작업들이었어요. 근데 리소스에 비해서, 사실 드러나는 임팩트는 좀 작아 보였어요. 엔드유저가 느끼는 것만 본다면, 거의 달라지는 게 없어 보이잖아요. 그래서 토큰의 문제를 해결하는 일은 계속 우선순위에서 밀리게 되었어요.
비즈니스 확장이 만든 전환점
그런데 비즈니스가 성장하면서 TDS는 새로운 문제를 마주했어요.
간편 송금앱에서 금융앱이 되며 일관성과 효율성을 위해 디자인 시스템이 필요해졌던 것처럼, 이제는 새로운 도메인, 슈퍼앱, 글로벌 진출, POS기 같은 다양한 기기들을 지원해야 했어요. 새로운 화면과 패턴이 생겨나는 속도가 급격히 빨라졌고, 디자인 시스템의 컴포넌트를 제작하는 속도가 그 속도를 따라잡지 못하게 되었어요.
그냥 컴포넌트를 더 열심히 찍어내면 될까요? 이건 너무 지속 가능하지 않은 선택이었어요.
그래서 저희는 확장 가능한 디자인 시스템을 만드는 게 필요하다고 판단했고, 확장 가능한 디자인 시스템을 토큰 시스템을 통해 만들어 보기로 했어요. 비즈니스 확장을 계기로 토큰 시스템을 처음부터 다시 만들게 되었고, 그 과정에서 앞서 언급했던 7년간 쌓인 문제들도 해결하며, 완성도 높은 토큰 시스템을 완성할 수 있었어요.
이때 가장 많은 부채를 가지고 있으면서도, 직접적인 레이아웃 변화는 적은 컬러 시스템을 중점적으로 작업해보기로 했습니다.
OKLCH: 인지적으로 균일한 색공간
가장 먼저, 명도 시스템을 구축했는데요, 이를 위해서 인지적으로 균일한 색공간의 개념을 활용했어요.
인지적으로 균일한 색공간은 OKLCH나 HSLuv 같은 색공간을 말하는데요. 지금까지 우리가 익숙했던 HSL 같은 색상 모델에서는 같은 명도를 가지더라도 색깔마다 인지되는 밝기가 달라요. 그런 차이를 보정한 것이에요.
OKLCH를 기준으로 명도를 통일하면 훨씬 균일한 색대비를 가지게 돼요. 이전의 컬러 팔레트에서는 컬러마다 명도의 차이가 이렇게 컸는데, 이제는 균일한 명도를 가지도록 했어요.
이렇게 명도 단계를 맞추니, 같은 스케일의 컬러를 쓰면 같은 명도로 보이도록 쉽게 맞출 수 있었고, UI에서 사용되는 주요 컬러 조합들이 접근성 기준을 충족할 수 있도록 보장할 수 있었어요.
그리고 시스템에 정의된 컬러 토큰에서 더 나아가서, 아무 색이나 넣어도 TDS 기준에 맞는 명도의 컬러 조합을 추출해주는 자동화 로직도 만들 수 있었어요. 예를 들어 Fill/Weak의 배경과 텍스트 컬러 색조합, 에셋(리소스)의 색상과 어울리는 색들을 자동으로 만들어 줄 수 있어요. 앱인토스와 같이 다양한 브랜드를 지원하면서도 디자인 퀄리티를 유지해야 할 때 꼭 필요한 기능이었어요. 이 로직을 활용해, 미니앱에 입점한 여러 브랜드의 브랜드 컬러를 TDS 컴포넌트에 입혔을 때도 접근성 문제 없이 적절한 명도의 컬러를 보여줄 수 있도록 만들 수도 있었습니다.
이때 많은 기기에서는 RGB를 사용하기 때문에, OKLCH의 색상을 그대로 표현하기 어려워요. Chroma(채도)를 clamp 하면 색조와 명도를 유지하면서도 비슷하게 보여줄 수 있어요.
수치를 넘어 시각보정까지
그렇게 해서 수치적으로는 아름다운 컬러 팔레트를 만들었는데요, 아쉽게도 여기서 끝은 아니었습니다. 다음으로 지난한 시각보정의 과정을 거치며 심미적으로 아름다운 컬러를 만들어 나갔습니다.
특히 노란색에서 시각보정이 필요했어요. 아까 만들었던 수치적으로 일정한 팔레트에서 노란색을 보면, 밝은 컬러는 다른 컬러들에 비해 너무 진해 보이고, 어두운 색들은 너무 탁해서 노란색같이 보이지도 않았어요.
UI에 얹어봤을 때도 텍스트 컬러가 너무 탁해서 노란색이라는 느낌이 들지 않거나, 같은 명도인데도 노란 배경만 진해 보이는 문제가 있었어요. 이것이 바로 디자인 시스템에서 자주 언급되는 어두운 노란색 문제(The Dark Yellow Problem)예요.
저희는 수치적으로 일정한 팔레트에서 더 나아가서, 시각적으로 더 적절해 보이는 팔레트를 만드는 게 중요하다는 걸 알게 되었어요. 노란 텍스트는 노란색이 주는 심상을 전달하면서도 접근성을 충족하도록, 그리고 밝은 노랑은 다른 컬러들과 같은 밝기로 보이도록 보정했어요. 그렇게 해서 노란색만 조금 다른 명도 진행을 가지게 되었죠.
다음으로는 다크모드를 위한 시각보정이 필요했어요. 인간의 눈에서는 늘 착시와 왜곡이 일어나요. 흰 배경에 요소가 올라갈 때와 어두운 배경에 요소가 올라갈 때, 같은 밝기 차이라도 후자의 시인성이 더 떨어지는 현상이 있었어요. 이건 APCA(Advanced Perceptual Contrast Algorithm) 같은 최신 명도대비 메트릭에서도 이야기하고 있는 내용이에요.
화면 밝기를 낮춰서 봤을 때 더 도드라졌어요. 그래서 다크모드에서 적절한 명도를 찾아, 다크모드만의 명도 기준을 세우게 되었어요. 다크모드에서는 명도대비를 더 강하게 가지도록 설계했어요.
시맨틱 토큰으로 일관성 보장하기
시맨틱 컬러 토큰들도 정비했어요. 다양한 시맨틱 토큰들을 제공해 디자인 결정에 들어가는 시간을 단축하고, 동일한 의도라면 같은 색상을 보여줄 수 있어 일관성을 보장할 수 있게 됐죠.
디자이너가 직접 제어하는 자동화 시스템
흩어진 토큰의 소스를 통합하는 것만으로는 충분하지 않았어요. 저희는 단순한 통합을 넘어 디자이너가 쉽게 제어하고 실험할 수 있는 시스템을 구축하고자 했습니다. '쉽게 제어하고 실험 가능하다'는 것에서 바로 자동화를 떠올릴 수 있지요.
먼저 “사람과 기계가 모두 읽을 수 있는 구조”로 규약을 정했어요.
그리고 디자이너는 Token Studio라는 Figma 플러그인을 통해 GitHub에 커밋하고 PR을 생성하면, 전처리된 토큰과 각 플랫폼별 코드가 자동으로 생성됩니다. 이를 통해 개발자에게 별도 요청을 하는 것보다 훨씬 빠르게 실험해볼 수 있어요.
다만 디자이너가 직접 커밋하고 PR을 생성하는 과정에서 오류나 실수가 발생하기 쉬워요. 예를 들어 토큰의 참조 오류가 발생하는 경우도 있죠. 하지만 빌드 시점에 에러를 감지하고 알려주기 때문에 디자이너가 직접 수정한 후 리뷰를 요청할 수 있습니다. 오류가 없으면 코드가 자동 생성되므로 개발자는 리뷰하기 쉽고 빠르게 배포할 수 있어요.
실제 생성 과정을 살펴보면, 먼저 전처리 단계에서 Token Studio에서 생성된 값을 Style Dictionary라는 변환 도구에 적합하도록 변환합니다. Token Studio 및 Figma 중심적으로 만들어진 원본 데이터를 그대로 사용하기에는 "Blue 50"과 같은 UI 표시 위주의 이름, 중첩된 구조, 서로 다른 포맷 등의 문제가 있었어요. 전처리 과정을 통해 완전히 일관된 값과 구조를 가지도록 정규화하여 변환을 용이하게 만들었습니다.
// == 생성 코드 ===================================================================
import { tokengen } from "@tds/token-utils";
import * as settings from "./settings.js";
tokengen({
src: settings.TOKEN_SYNC_PATH,
dest: settings.TOKEN_PREPROCESSED_PATH
});
// == 원본 데이터 ==================================================================
// figma/token.json
{
"Colors/color-dark-v2": {
"Base": {
// UI 표시 위주의 이름
"Blue 50": {
"$type": "color",
"$value": "#1c2331"
},
"Blue 100": {
"$type": "color",
"$value": "#212b41"
},
"Blue Opacity": {
// 의미는 이해되지만 중첩된 구조
"Blue Opacity 50": {
"$type": "color",
"$value": "rgba(71, 134, 235, 0.11)"
},
"Blue Opacity 100": {
"$type": "color",
"$value": "rgba(67, 122, 223, 0.205)" // hex와 rgba처럼 서로 다른 포맷
}
}
}
}
}
// == 정규화된 데이터 ================================================================
// data/color/color-dark-v2.json
{
"base": {
// kebab-case 로 일관된 이름
"blue-50": {
"$type": "color",
"$value": "rgb(28, 35, 49)"
},
"blue-100": {
"$type": "color",
"$value": "rgb(33, 43, 65)"
},
// 동일한 레벨의 구조
"blue-opacity-50": {
"$type": "color",
"$value": "rgba(71, 134, 235, 0.11)"
},
"blue-opacity-100": {
"$type": "color",
"$value": "rgba(67, 122, 223, 0.205)" // rgb/rgba로 통일된 포맷
}
}
}코드 생성 과정에서는 Style Dictionary를 통해 CSS, TypeScript, Deus Variable Collection Schema, Server Driven Format 등 다양한 형태로 변환돼요. 특히 Server Driven Format의 경우 앱에서 하위호환성을 지키면서도 새로운 버전을 지원하게 만들기 위해 디자이너, Android, iOS, 사일로 개발자등과 함께 스펙을 재정의해야 해서 어려웠어요.
각종 커스텀 포맷과 복잡한 요구사항을 반영하려면 변환과정을 완전히 재정의하다시피 했어야 했어요. 플랫폼에 따른 빌드 타겟 필터링, 테마 및 모드 지원, 모드와 변형을 위한 토큰 참조 재구현, 토큰 타입 매핑, 복합 토큰 변환, 토큰 오버라이딩 지원, 각각의 파일 포매팅 등 많은 작업이 필요했어요.
하지만 덕분에 매우 간단하고 선언적인 코드로 다양한 옵션에 따라 생성해낼 수 있었어요.
import { PLATFORMS, codegen, cssConfig, cssFile, typescriptConfig } from "@tds/token-utils";
import * as settings from "./settings.js";
codegen({
src: settings.TOKEN_PREPROCESSED_PATH,
defaultTheme: {
color: "light"
},
platforms: {
css: cssConfig({
buildPath: cwd(),
files: [cssFile({ destination: "token.css" })],
options: {
defaultTheme: {
sizing: "android",
blur: "web",
typography: "mobile"
},
target: PLATFORMS.web,
mode: {
color: {
dark: ':root[data-tds-color-scheme="dark"], :root [data-tds-color-scheme="dark"]'
}
}
},
}),
typescript: typescriptConfig({
// 동일한 방식
})
}
});확장 가능한 디자인 시스템: 테마 시스템
비즈니스적으로 다양한 요구사항에 직면했다고 말씀드렸는데요. 그 결과 확장 가능한 디자인 시스템을 만들기로 결심했어요.
형태적으로 확장 가능한 디자인 시스템은 바로 테마 시스템입니다.
테마란 특정한 “규약“에 따라 스타일을 적용하거나 변경하는 것으로, 단순히 Light/Dark 컬러만 바뀌는 것이 아니에요. 브라우저 테마처럼 배경 이미지, 그라디언트 등 모두 규약으로 정의하기만 하면 변경할 수 있어요. 때문에 중요한 것은 어떻게 규약을 정하고 어떤 규약을 정하느냐에요. 앞서 시멘틱 토큰에서 규칙을 정했고, 토큰자체도 “사람과 기계가 모두 읽을 수 있는 구조”를 만들었던 것도 디자인 의사결정을 인코딩해 모두가 동일한 멘탈 모델을 가지기 위해서였어요.
테마 시스템을 활용하면 커스터마이징을 하면서도 품질과 일관성을 유지할 수 있고, 컴포넌트의 중복 구현을 방지할 수 있어요. 대표적인 예로 앱인토스의 Brand 컬러 토큰 오버라이드와 TDS POS의 Sizing/Spacing 토큰 오버라이드를 들 수 있어요.
즉, 테마 시스템은 커스터마이징의 시스템화를 의미하며, 동일한 기능을 하면서 다양한 형태를 지원하게 돼요.
그런데 다른 기능이 필요하다면 어떨까요? 예를 들어 TDS Desktop은 B2B용 어드민 화면을 만드는 데 주로 사용되는 반면, TDS WTS는 B2C용이며 트레이딩 화면을 만들 때 사용되기 때문에 서로 다른 기능이 필요해요. 루이스 설리번이 말했듯 형태는 기능에 따르므로(Form follows function) 다른 기능을 하면 다양한 형태가 필요해요. 그래서 다른 기능을 할때도 커스텀을 지원하기 위한 System of System으로서 파생 가능한 테마 시스템을 만들었어요.
파생 가능한 테마 시스템은 파운데이션 요소들을 공유하면서 전용 시맨틱, 컴포넌트 토큰들을 오버라이드하여 사용할 수 있어요. 이를 통해 다른 기능을 구현하면서도 최소한의 형태적 일관성은 보장하게 됩니다. 전용 시맨틱 토큰을 사용하는 대표적인 예시로, 일반적인 화면에서는 파란색이 긍정적이고 Primary 컬러로 사용되지만 TDS WTS에서는 빨간색이 긍정적인 의미이며 Primary 컬러로 사용되는 경우가 있죠.
앞서 만들어놓은 토큰 코드젠 패키지를 통해 각자만의 토큰을 확장해 사용할 수 있어요.
import { PLATFORMS, codegen, cssConfig, cssFile } from "@tds/token-utils";
import { tdsWtsTokenLight, tdsWtsTokenDark } from "./tdsWtsToken.js";
codegen({
src: "@tds/token/data",
defaultTheme: {
color: "light"
},
pickTheme: {
color: [
{
fileName: "color-light-v2",
tokenLevel: ["base", "wts-semantic"],
override: tdsWtsTokenLight
},
{
fileName: "color-dark-v2",
tokenLevel: ["base", "wts-semantic"],
override: tdsWtsTokenDark
}
]
}
platforms: {
css: cssConfig({
// 동일한 방식
})
}
});달리는 기차의 바퀴를 칠하다
그런데 디자인 시스템은 만드는 것도 중요하지만 적용이 그 이상으로 중요해요. 저희는 거대한 레거시 시스템이라는 달리는 기차의 바퀴를 칠해야 했습니다. 디자인 토큰은 토스의 모든 곳에서 다양한 형태로 사용되기 때문에 마이그레이션을 위해 많은 리소스가 필요했어요.
커다란 마이그레이션을 진행하기 위해 총 3가지 단계로 나누어 진행하기로 계획했어요.
1. 내부 프로세스 통합
먼저 2가지의 Token 패키지를 만들었어요. 흩어져 있는 토큰 관련 패키지를 통합해 값 변화 없이 구조만 변경된 Token v1과, Token v1과 동일한 구조지만 값이 변경된 Token v2입니다. 두 패키지가 동일한 구조를 가지도록 만들기 위해 Token v1의 레거시 토큰들을 Token v2에서도 사용 가능하게 하고, Token v2에서 추가된 토큰들을 Token v1에서도 사용 가능하게 했어요.
이후 TDS의 새로운 메이저 버전인 TDS v3에서는 서비스와 동일한 의존성을 사용하도록 토큰 패키지를 peerDeps로 설정했습니다. 레거시 버전의 TDS에도 적용해서 최대한 토큰의 적용 범위를 넓혔어요. 물론 마이그레이션을 수월하게 할 수 있도록 CLI도 제공했습니다.
이와 비슷한 작업은 Web 뿐만아니라 React Native, Android, iOS, Server Driven UI 등에서도 모두 진행되어야 했어요.
2. 서비스에 토큰 시스템 적용
가장 먼저 고려할 것은 토스의 디자인 에디터인 Deus예요. Deus에는 스타일 격리를 위한 ShadowDOM을 적용하고, 이를 바탕으로 Variable Collection 시스템을 만들었어요. System/Light/Dark와 같이 컨텍스트도 전환할 수 있도록 했습니다.
스타일 격리가 없던 구형 컴포넌트 마이그레이션, 컬렉션 등록과 사용을 위한 정의, 7년간 인터페이스 변경이 없던 덕분에 레거시 토큰 내부구현에 잔뜩 의존한 코드, 분기로 처리하기 까다로운 코드젠등 한발한발 내딛을 때마다 고난이 기다리고 있었어요.
한편 토큰 패키지가 적용된 TDS는 Frontend Platform/Android/iOS의 모노레포 버전관리를 통해 일괄적으로 전파할 수 있었어요. Server Driven UI의 경우 앱버전의 분기에 따라 역매핑을 한 컬러를 내려주는 등의 작업이 필요했어요.
3. 함께 컬러 버전 높이기
이제 컬러 버전을 높여야겠죠? Token v1과 Token v2의 컬러 구조는 동일했지만 동일한 키가 동일한 의미를 가지게 매핑되지는 않았습니다. 명도 시스템이 바뀌며 완전히 1:1 매핑이 되는 구조는 아니었거든요.
때문에 저희는 시맨틱 토큰과 컴포넌트을 활용해 동일한 의미를 가지는 구조를 만들고 각각의 컴포넌트에 적용하기로 했어요. 만들어진 시맨틱/컴포넌트 토큰에 따라 TDS v3에 점진적으로 적용하고, 준비가 되면 Token v2를 허용하는 방식으로 진행했습니다. 이때 TDS에서 의존하는 인터렉션 패키지부터, TDS를 의존하는 주요 라이브러리까지 모두를 챙겨야 했어요.
실제 서비스에 적용할 때는 테스트로 몇가지 서비스에 적용해본뒤, 우선순위를 정해 중요한 화면부터 신규 컬러를 전파했어요. 이후 일반적인 화면들은 또 다시 모노레포 버전 관리를 통해 일괄 적용해요. 이는 다른 계열사에도 마찬가지로 적용할 수 있는 프로세스지요.
글로는 간단하게 보이지만, 실제로는 Web, RN, Android, iOS, Server Driven과 같은 다양한 플랫폼, 의존하는 패키지들, 디자인 에디터, 다양한 계열사와 사일로까지 엄청나게 많은 것들을 고려해서 진행해야 했어요.
가끔은 기차가 아니라 비행기가 아닐까 싶을 정도였습니다.
앞으로 더 나은 디자인 시스템을 향해
지금까지 컬러 시스템을 업데이트하며 4가지의 문제를 만나고 해결했어요.
이렇게 저희는 아무리 복잡해 보여도 가로막는 문제가 된다면, 풀어요. 바닥부터 다시 쌓아올리게 되더라도요. 그래서 오늘의 선택이 내일의 한계가 되지 않도록, 100명을 위한 시스템에서 100만 명을 위한 시스템이 되었으면 합니다.
하지만 여기서 끝이 아니라, 앞으로 더 개선해보고 싶은 과제들이 많아요.
탄탄한 기초공사 먼저 기초공사를 탄탄히 하고 싶습니다. 타이포그래피, 스페이싱, 상태 등 더 많은 파운데이션들이 정교한 규약하에 토큰화되고 Theme 시스템으로 사일로나 계열사에서 형태의 변화가 필요하다면 쉽게 형태를 커스텀하면서도 퀄리티가 지켜지도록 만들고 싶어요. 기능에 대해서도 커스텀이 가능하면서도 퀄리티가 지켜지도록 TDS Headless를 잘 가꾸고 싶어요.
메트릭과 AI의 활용 이외에 관심 있는 분야는 디자인 시스템을 위한 메트릭 구축과 AI의 활용입니다. 디자인 시스템 메트릭은 디자인 시스템에서 데이터 기반의 의사결정을 도우며, 유지보수 및 리서치가 가능한 시스템을 기대하고 있어요.
AI를 사용하면 TDS의 맥락을 이해하면서 화면을 디자인하고, 만들어진 화면을 코드로 옮기고, 필요한 도메인 컴포넌트도 쉽게 만들 수 있도록 해 생산성을 올려보고 싶어요.
TDS가 잘 만들어진 디자인 시스템이기는 하지만 아직도 할 것이 많고, 하고 싶은 것도 많은 것 같아요.
디자인 시스템을 도입하고자 하는 분들께
마지막으로, 디자인 시스템을 도입하고자 하는 현직자 분들께 드릴 수 있는 팁을 공유하려고 해요.
디자인 시스템은 개발자 혼자서는 도입하기도 어렵고 유지하기도 어려워요. 결국 컴포넌트를 디자인하고 화면을 디자인하는 것은 디자이너이기 때문에, 좋은 제약을 가지면서 효율적이고 실제로 사용 가능한 디자인 시스템을 구축하려면 꼭 디자이너가 참여하고 시스템이 작동할 수 있도록 전파가 필요해요. 그렇지 않다면 수십 개의 커스텀이 생기고, 디자인 시스템이 달성하고자 하는 일관성과 효율성이 퇴색될 수 밖에 없습니다.
만약 불가능한 상황이라면 오픈소스 Headless 컴포넌트들을 활용해 필수적으로 구현해야 하는 기능과 접근성이라도 챙겨볼 수 있을 듯 해요.
디자인 시스템을 만들고 유지보수하는 일이 쉬운 일은 아니겠지만, 팀의 규모가 크다면 도입을 고려해볼 만하다고 생각해요. 디자인 시스템에 관심 있는 모든 개발자들 화이팅입니다!! ✨
*이 글은 지난 10월 31일에 진행된 토스 UX Insight Club Vol.2의 발표 내용을 바탕으로 재구성 되었습니다.
