design-tokens

2 개의 포스트

달리는 기차 바퀴 칠하기: 7년만의 컬러 시스템 업데이트 (새 탭에서 열림)

토스 디자인 시스템(TDS)은 서비스의 글로벌 확장과 다양한 플랫폼 대응을 위해 7년 만에 컬러 시스템을 전면 개편했습니다. 인지적으로 균일한 색공간인 OKLCH를 도입하여 시각적 일관성과 접근성을 확보하고, 디자이너가 직접 제어하는 자동화된 토큰 관리 체계를 구축했습니다. 이번 개편을 통해 TDS는 단순한 디자인 가이드를 넘어, 비즈니스 성장을 뒷받침하는 확장 가능한 기술 인프라로 진화했습니다. ### 기존 컬러 시스템의 한계와 부채 - **명도 불일치**: 동일한 명도 단계(예: 100)임에도 색상(Grey, Blue, Red 등)에 따라 실제 느껴지는 밝기가 달라 UI가 얼룩덜룩해 보이는 문제가 있었습니다. - **모드 간 이격**: 라이트모드와 다크모드의 명도 기준이 달라 다크모드에서 특정 색이 너무 튀거나 가독성이 떨어지는 현상이 발생했습니다. - **관리 체계의 파편화**: 웹, iOS, 안드로이드, 디자인 에디터 등 각 플랫폼에서 컬러를 개별 관리하면서 싱글 소스 오브 트루스(SSOT)가 무너지고 커뮤니케이션 비용이 증가했습니다. ### OKLCH 색공간을 통한 인지적 균일함 확보 - **지각적 평등성**: 수치상 명도와 인간이 느끼는 밝기가 다른 HSL 모델 대신, 인지적으로 균일한 OKLCH 및 HSLuv 색공간을 활용해 모든 색상의 명도를 통일했습니다. - **접근성 자동화**: 정의된 명도 체계를 바탕으로, 외부 브랜드 컬러를 입력하더라도 TDS 기준에 맞는 배경-텍스트 대비를 자동으로 추출하는 로직을 구현했습니다. - **디바이스 최적화**: RGB 환경에서 표현하기 어려운 OKLCH 색상을 위해 채도(Chroma)를 클램핑(Clamp)하여 색조와 명도를 유지하면서도 기기 호환성을 높였습니다. ### 심미성과 접근성을 위한 시각 보정 - **Dark Yellow 문제 해결**: 수치적으로만 맞춘 노란색은 탁해 보이거나 너무 진해 보일 수 있어, 노란색 계열에 한해 별도의 명도 진행 단계를 적용하는 시각 보정을 거쳤습니다. - **다크모드 시인성 강화**: 인간의 눈이 어두운 배경에서 대비를 더 낮게 인식하는 특성을 고려하여, 최신 명도대비 메트릭인 APCA를 참고해 다크모드의 대비를 더 강하게 설계했습니다. - **시맨틱 토큰 정비**: 색상의 값(Primitive)이 아닌 사용 의도(Semantic)에 집중한 토큰 체계를 정립하여 디자인 결정 시간을 단축하고 일관성을 보장했습니다. ### 디자이너 중심의 토큰 자동화 시스템 - **통합 파이프라인**: Figma 플러그인(Token Studio)과 GitHub를 연동하여 디자이너가 컬러를 수정하고 커밋하면 모든 플랫폼의 코드가 자동으로 생성되도록 구축했습니다. - **실험적 환경**: 개발자의 수동 작업 없이도 디자이너가 직접 토큰을 변경하고 빠르게 실험할 수 있는 환경을 만들어 디자인 시스템의 운영 효율을 극대화했습니다. 성공적인 디자인 시스템 개편을 위해서는 단순한 심미적 수정을 넘어, 데이터 기반의 색공간 설계와 엔지니어링 관점의 자동화가 필수적입니다. 특히 비즈니스가 확장되는 시점이라면 컬러 시스템을 개별 컴포넌트가 아닌, 모든 플랫폼을 관통하는 하나의 '코드'이자 '인프라'로 접근하는 태도가 필요합니다.

디자인시스템이 AI를 만났을 때: FE 개발 패러다임의 변화 (새 탭에서 열림)

디자인 시스템과 AI의 결합은 단순한 도구의 조합을 넘어 프론트엔드(FE) 개발의 마크업 작업 방식을 근본적으로 혁신하고 있습니다. 네이버파이낸셜은 체계적으로 구축된 디자인 시스템을 기반으로 AI를 활용해 마크업 과정을 자동화함으로써 반복적인 코딩 시간을 단축하고 개발 효율성을 극대화했습니다. 다만, AI가 생성한 결과물을 실무에 즉시 투입하기 위해서는 디자인 토큰의 정교한 관리와 개발자의 세밀한 조정 작업이 반드시 병행되어야 한다는 점을 시사합니다. **네이버파이낸셜 디자인시스템의 근간: 토큰과 컴포넌트** * 디자인 시스템의 핵심인 '디자인 토큰'을 통해 색상, 간격, 폰트 등의 시각적 요소를 정의하고 디자이너와 개발자가 동일한 언어를 사용하도록 환경을 구축했습니다. * 재사용 가능한 UI 컴포넌트 단위를 명확히 정의하여, AI가 일관성 있는 코드를 생성할 수 있는 구조적 토대를 마련했습니다. * 단순한 UI 라이브러리를 넘어, 디자인 시스템 자체가 AI가 학습하고 참조할 수 있는 '신뢰할 수 있는 단일 소스(Single Source of Truth)' 역할을 수행합니다. **AI 마크업 효율을 극대화하는 Code Connect와 인스트럭션** * Figma의 'Code Connect' 기능을 활용해 디자인 도구 내의 컴포넌트와 실제 리액트(React) 코드를 직접 연결하여 AI가 맥락에 맞는 코드를 제안하도록 설계했습니다. * 디자인 시스템의 고유한 규칙과 코딩 컨벤션을 담은 상세한 '인스트럭션(Instruction)'을 AI에게 제공함으로써, 범용적인 코드가 아닌 팀의 표준에 부합하는 결과물을 얻어냈습니다. * 이 과정을 통해 개발자는 빈 화면에서 시작하는 대신, AI가 생성한 초안을 바탕으로 비즈니스 로직 구현에 더 집중할 수 있게 되었습니다. **현실적인 개발 도입 과정에서의 한계와 극복** * AI가 존재하지 않는 컴포넌트를 만들어내거나 잘못된 속성을 사용하는 '할루시네이션(환각)' 현상이 여전히 발생하여 개발자의 검토 과정이 필수적입니다. * 복잡한 레이아웃이나 고도의 인터랙션이 포함된 화면의 경우, AI가 단번에 완벽한 마크업을 생성하기 어렵다는 점을 확인했습니다. * 마크업 자동화가 성공하기 위해서는 단순히 AI 툴을 쓰는 것을 넘어, 디자인 시스템의 코드 품질과 문서화 수준이 먼저 뒷받침되어야 함을 실증했습니다. **마크업 자동화 이후의 FE 개발자 역할 변화** * 과거에 직접 태그를 입력하고 스타일을 잡던 수동적인 마크업 작업의 비중이 줄어들고, 생성된 코드를 조립하고 검증하는 '오케스트레이터'로서의 역할이 강조됩니다. * 단순 반복 작업에서 벗어나 더 복잡한 비즈니스 문제 해결과 사용자 경험(UX) 고도화에 개발 자원을 투입할 수 있는 환경이 조성되었습니다. * 결과적으로 AI는 개발자의 대체제가 아니라, 디자인 시스템이라는 약속된 규칙 위에서 함께 협업하는 강력한 동료로서 기능하게 됩니다. 성공적인 AI 기반 개발 환경을 구축하려면 디자인 시스템을 단순한 가이드가 아니라 **AI가 읽을 수 있는 데이터 구조**로 정교화하는 선행 작업이 가장 중요합니다. AI에게 맡길 영역과 개발자가 직접 제어할 영역을 명확히 구분하고, 코드 리뷰 단계를 강화하여 코드 품질을 유지하는 전략이 권장됩니다.