달리는 기차 바퀴 칠하기: TDS 컬러 시스템 업데이트

이 게시물은 토스 디자인 시스템(TDS)의 컬러 시스템을 7년 만에 전면 개편하며, 컬러 토큰과 생성/배포 체계를 처음부터 재구축한 과정을 설명합니다.

7년간 누적된 컬러 팔레트/토큰의 문제

• 같은 단계(예: 100)라도 색상별 명도가 달라 UI가 얼룩덜룩해 보이고, 라이트/다크 모드 간에도 명도 기준이 달라 추가 커스텀이 빈번했습니다.
• 저해상도 디바이스/가상환경에서 밝은 컬러가 날아가는 등 접근성·가독성 문제가 있었습니다.
• 웹/네이티브/서버/디자인 에디터(Deus) 등 플랫폼별로 토큰이 분산 관리되어 Single Source of Truth가 깨지고 추적·동기화 비용이 컸습니다.

OKLCH 기반 명도 통일과 시각보정

• 인지적으로 균일한 색공간(OKLCH)을 활용해 명도 단계를 통일하고, 접근성 기준을 만족하는 조합을 더 쉽게 만들도록 했습니다.
• RGB 환경 제약을 고려해 채도(Chroma) clamp 등으로 근사 표현을 적용했습니다.
• 수치적 균일함을 넘어 ‘어두운 노란색 문제(The Dark Yellow Problem)’와 다크모드 시인성(APCA 관점)을 반영해 시각보정을 수행하고, 다크모드는 더 강한 대비 기준을 갖도록 설계했습니다.

디자이너가 제어하는 자동화된 토큰 파이프라인

• Token Studio(Figma)에서 디자이너가 GitHub에 커밋/PR을 만들면, 전처리(정규화) 후 Style Dictionary 기반으로 CSS/TypeScript/Deus 스키마/Server Driven 포맷 등 플랫폼별 코드가 자동 생성되도록 했습니다.
• 빌드 시점 오류 감지로 토큰 참조 오류 등을 빠르게 수정하고, 개발자는 리뷰·배포를 단순화할 수 있게 했습니다.

테마 시스템과 마이그레이션 전략

• 규약 기반의 테마 시스템으로 브랜드 컬러/사이징·스페이싱 등 오버라이드를 지원하고, 파생 가능한(System of System) 구조로 도메인별 전용 시맨틱 토큰도 확장 가능하게 했습니다.
• 마이그레이션은 (1) 내부 프로세스 통합(Token v1/v2 병행) (2) 서비스 적용(Deus/모노레포/Server Driven 대응) (3) 시맨틱·컴포넌트 토큰을 통한 점진적 컬러 버전 업의 3단계로 진행했습니다.