UI component architecture, design tokens, and semantic theming Compiled for immediate developer deployment.
calendar_todaysummarizeWeek 8-2026
article
Design Token 명명 모범 사례
TAG: 토큰
Design token의 이름 짓기는 단순한 표기 문제가 아니라 시스템 아키텍처의 핵심입니다. Mary Achinger는 IBM Carbon을 참조 사례로 삼아 global, alias, component 세 계층 구조를 설명합니다. color-blue-60 같은 global token은 원시 값을 보유하고, color-primary 같은 semantic alias는 테마 전환을 가능하게 하며, button-background 같은 component token은 로컬 override를 지원합니다. 멀티 브랜드 시스템에서는 color-brand-primary처럼 안정적인 alias 구조를 유지하되 브랜드별 값을 별도 theme으로 분리해 중복을 최소화하도록 권장합니다. elevation-medium-ios처럼 플랫폼 컨텍스트를 이름에 포함시키면 global namespace 오염 없이 플랫폼별 요구사항을 명확히 표현할 수 있습니다. Tokens Studio, Style Dictionary, CI/CD linting을 통해 naming 일관성을 자동으로 유지하는 tooling 전략도 소개합니다.
아무도 사용하지 않는 design system은 디자인 실패가 아니라 governance 실패입니다. Mary Achinger는 가장 흔한 adoption 장애물을 정리합니다. 실제 수요 검증 없이 출시부터 모든 component를 만드는 과도한 엔지니어링, 명확한 ownership 부재로 인한 문서 부패와 버그 수정 지연, 디자인 에셋·문서·코드가 각기 다른 사일로에 흩어진 tool fragmentation이 대표적입니다. 이해관계자 참여 없이 고립적으로 개발된 시스템은 팀의 buy-in을 잃고 shadow component와 parallel workaround를 양산하여 기술 부채를 키웁니다. 기사는 일부 component만 사용하는 부분 adoption과 처음부터 다시 만드는 완전한 breakdown을 구분하며, 핵심 결론으로 '컴포넌트보다 문화'를 강조합니다. 사용자와 함께 만들어지고 governance와 피드백 루프로 뒷받침되는 시스템이 기술적으로 완벽하지만 외면받는 라이브러리보다 오래 살아남습니다.
Victor Ayomipo는 streak 디자인을 세 가지 심리적 메커니즘으로 설명합니다. 손실 회피(잃는 것이 얻는 것보다 두 배 더 아프다 — Duolingo 데이터는 사용자가 투자한 노력을 잃을 두려움으로 긴 streak을 보호한다는 것을 확인), BJ Fogg의 B=MAP 모델(행동은 Motivation·Ability·Prompt가 동시에 정렬되어야 발생 — Duolingo의 빨간 뱃지 A/B 테스트가 DAU 6% 향상), Zeigarnik 효과(미완성 작업이 더 많은 정신 공간을 차지 — 진행 중인 streak은 끊임없는 열린 루프로 작동). UX 측면에서는 행동 마찰 최소화(한 레슨, 1분), GitHub contribution graph나 Duolingo의 마일스톤 애니메이션 같은 시각적 피드백, 일괄 스케줄 대신 사용자 행동 패턴에 맞춘 push notification 타이밍, streak freeze·2~3시간 연장·decay 모델 같은 grace mechanism으로 가혹한 리셋을 방지할 것을 권장합니다. 엔지니어를 위해서는 서버 권위 아키텍처(사용자별 IANA timezone 저장, UTC timestamp로 서버 사이드 이벤트 검증, 버그로 인한 부당한 리셋 복구를 위한 관리자 백도어)를 상세히 설명합니다.
ARIA Authoring Practices Guide(APG)는 w3.org에 호스팅되어 있고 '디자인 패턴과 기능적 예제'를 제공한다고 명시하기 때문에, 개발자들이 이를 접근성의 절대적 기준으로 취급하는 것은 자연스러운 일입니다. Stefan Judis는 Eric Eggert의 분석을 인용하며 APG는 ARIA의 기능을 *시연*하기 위해 만들어진 것이지 pattern library나 단일 진실의 출처로 설계된 것이 아님을 지적합니다. 시연이 목적이었기 때문에 예제는 네이티브 HTML로 충분한 경우에도 ARIA를 과도하게 사용하며, 브라우저·스크린 리더 지원 격차는 가이드의 범위 밖입니다. Judis가 인정하는 실제 유용한 부분은 표준화된 패턴 명칭, 'About This Pattern' 설명, Keyboard Interaction 명세입니다. 실용적 규칙 세 가지: 항상 네이티브 HTML을 먼저 사용할 것(<button>이 <div role="button">보다 낫다), 직접 보조 기술로 테스트할 것, Adrian Roselli처럼 실제 screen reader 호환성 결과를 발표하는 실무자를 팔로우할 것.
스포츠 티케팅 스타트업 Jump(Minnesota Timberwolves 팬 앱 플랫폼으로 최근 발표)의 리드 프로덕트 디자이너 Cornelius가 두 명의 디자인 팀이 하나의 Figma 라이브러리로 50개 이상의 스포츠 브랜드를 지원하는 방법을 설명합니다. 이 시스템은 표준 light/dark 패러다임을 넘어 Figma modes를 활용합니다. 각 팀은 5가지 브랜드 컬러(brand-core, brand-light, brand-dark, interactive, inverted-interactive), 팀별 크기와 letter-spacing을 가진 커스텀 display 폰트, border-radius 같은 선택적 UI override를 포함하는 mode 항목을 가집니다. 단일 team ID 변수만 변경하면 전체 화면 플로우가 North Carolina Courage에서 Bucknell Bison(또는 Minnesota 전용 'wolf mode')으로 전환됩니다. Figma 파일은 엔지니어용 PM 섹션(스펙, 상태, token 문서)과 디자이너용 섹션(component, 탐색, graveyard)으로 분리됩니다. Interaction token은 hover-scale과 press-state overlay(보정된 불투명도의 mode-agnostic black/white)를 추상화하며, 개발 앱의 커스텀 debug 메뉴와 web의 Storybook으로 검증되어 컴포넌트별 scale 협의를 interaction-scale-700 같은 단일 token 참조로 대체합니다.
Design token의 이름 짓기는 단순한 표기 문제가 아니라 시스템 아키텍처의 핵심입니다. Mary Achinger는 IBM Carbon을 참조 사례로 삼아 global, alias, component 세 계층 구조를 설명합니다. color-blue-60 같은 global token은 원시 값을 보유하고, color-primary 같은 semantic alias는 테마 전환을 가능하게 하며, button-background 같은 component token은 로컬 override를 지원합니다. 멀티 브랜드 시스템에서는 color-brand-primary처럼 안정적인 alias 구조를 유지하되 브랜드별 값을 별도 theme으로 분리해 중복을 최소화하도록 권장합니다. elevation-medium-ios처럼 플랫폼 컨텍스트를 이름에 포함시키면 global namespace 오염 없이 플랫폼별 요구사항을 명확히 표현할 수 있습니다. Tokens Studio, Style Dictionary, CI/CD linting을 통해 naming 일관성을 자동으로 유지하는 tooling 전략도 소개합니다.
스포츠 티케팅 스타트업 Jump(Minnesota Timberwolves 팬 앱 플랫폼으로 최근 발표)의 리드 프로덕트 디자이너 Cornelius가 두 명의 디자인 팀이 하나의 Figma 라이브러리로 50개 이상의 스포츠 브랜드를 지원하는 방법을 설명합니다. 이 시스템은 표준 light/dark 패러다임을 넘어 Figma modes를 활용합니다. 각 팀은 5가지 브랜드 컬러(brand-core, brand-light, brand-dark, interactive, inverted-interactive), 팀별 크기와 letter-spacing을 가진 커스텀 display 폰트, border-radius 같은 선택적 UI override를 포함하는 mode 항목을 가집니다. 단일 team ID 변수만 변경하면 전체 화면 플로우가 North Carolina Courage에서 Bucknell Bison(또는 Minnesota 전용 'wolf mode')으로 전환됩니다. Figma 파일은 엔지니어용 PM 섹션(스펙, 상태, token 문서)과 디자이너용 섹션(component, 탐색, graveyard)으로 분리됩니다. Interaction token은 hover-scale과 press-state overlay(보정된 불투명도의 mode-agnostic black/white)를 추상화하며, 개발 앱의 커스텀 debug 메뉴와 web의 Storybook으로 검증되어 컴포넌트별 scale 협의를 interaction-scale-700 같은 단일 token 참조로 대체합니다.
아무도 사용하지 않는 design system은 디자인 실패가 아니라 governance 실패입니다. Mary Achinger는 가장 흔한 adoption 장애물을 정리합니다. 실제 수요 검증 없이 출시부터 모든 component를 만드는 과도한 엔지니어링, 명확한 ownership 부재로 인한 문서 부패와 버그 수정 지연, 디자인 에셋·문서·코드가 각기 다른 사일로에 흩어진 tool fragmentation이 대표적입니다. 이해관계자 참여 없이 고립적으로 개발된 시스템은 팀의 buy-in을 잃고 shadow component와 parallel workaround를 양산하여 기술 부채를 키웁니다. 기사는 일부 component만 사용하는 부분 adoption과 처음부터 다시 만드는 완전한 breakdown을 구분하며, 핵심 결론으로 '컴포넌트보다 문화'를 강조합니다. 사용자와 함께 만들어지고 governance와 피드백 루프로 뒷받침되는 시스템이 기술적으로 완벽하지만 외면받는 라이브러리보다 오래 살아남습니다.
Victor Ayomipo는 streak 디자인을 세 가지 심리적 메커니즘으로 설명합니다. 손실 회피(잃는 것이 얻는 것보다 두 배 더 아프다 — Duolingo 데이터는 사용자가 투자한 노력을 잃을 두려움으로 긴 streak을 보호한다는 것을 확인), BJ Fogg의 B=MAP 모델(행동은 Motivation·Ability·Prompt가 동시에 정렬되어야 발생 — Duolingo의 빨간 뱃지 A/B 테스트가 DAU 6% 향상), Zeigarnik 효과(미완성 작업이 더 많은 정신 공간을 차지 — 진행 중인 streak은 끊임없는 열린 루프로 작동). UX 측면에서는 행동 마찰 최소화(한 레슨, 1분), GitHub contribution graph나 Duolingo의 마일스톤 애니메이션 같은 시각적 피드백, 일괄 스케줄 대신 사용자 행동 패턴에 맞춘 push notification 타이밍, streak freeze·2~3시간 연장·decay 모델 같은 grace mechanism으로 가혹한 리셋을 방지할 것을 권장합니다. 엔지니어를 위해서는 서버 권위 아키텍처(사용자별 IANA timezone 저장, UTC timestamp로 서버 사이드 이벤트 검증, 버그로 인한 부당한 리셋 복구를 위한 관리자 백도어)를 상세히 설명합니다.
ARIA Authoring Practices Guide(APG)는 w3.org에 호스팅되어 있고 '디자인 패턴과 기능적 예제'를 제공한다고 명시하기 때문에, 개발자들이 이를 접근성의 절대적 기준으로 취급하는 것은 자연스러운 일입니다. Stefan Judis는 Eric Eggert의 분석을 인용하며 APG는 ARIA의 기능을 *시연*하기 위해 만들어진 것이지 pattern library나 단일 진실의 출처로 설계된 것이 아님을 지적합니다. 시연이 목적이었기 때문에 예제는 네이티브 HTML로 충분한 경우에도 ARIA를 과도하게 사용하며, 브라우저·스크린 리더 지원 격차는 가이드의 범위 밖입니다. Judis가 인정하는 실제 유용한 부분은 표준화된 패턴 명칭, 'About This Pattern' 설명, Keyboard Interaction 명세입니다. 실용적 규칙 세 가지: 항상 네이티브 HTML을 먼저 사용할 것(<button>이 <div role="button">보다 낫다), 직접 보조 기술로 테스트할 것, Adrian Roselli처럼 실제 screen reader 호환성 결과를 발표하는 실무자를 팔로우할 것.
이번 주 design system은 반복적인 긴장을 드러냈습니다. 아키텍처적으로 견고한 것을 만드는 것과 실제로 사용되도록 하는 것 사이의 간극입니다. 주요 기사인 token 명명 규칙은 기반 레이어를 직접 다루며, IBM Carbon 모델을 따르는 global-alias-component 3계층 구조가 단순한 표기 관행이 아니라 load-bearing 아키텍처임을 주장했습니다. 특히 color-brand-primary 같은 단일 alias가 namespace를 중복하지 않고 theme별 다른 값으로 해석되어야 하는 멀티 브랜드 시스템에서 더욱 그렇습니다. 함께 소개된 Figma 영상은 이 원칙이 실규모에서 적용되는 모습을 보여줬습니다. Jump 스포츠의 2인 팀이 팀당 Figma mode를 활용해 단 하나의 라이브러리로 50개 이상의 브랜드를 관리하며, team ID 변수 하나만 바꾸면 전체 UI가 브랜드 간에 전환됩니다.
ARIA Authoring Practices Guide 비판은 중요한 접근성 수정을 제시했습니다. APG는 ARIA의 기능을 시연하기 위해 설계된 것이지 프로덕션 pattern library가 아니며, 예제는 네이티브 HTML로 충분한 상황에서도 ARIA를 과도하게 사용합니다. Stefan Judis의 규칙 — 네이티브 HTML 우선, 보조 기술로 직접 테스트, 실무자 팔로우 — 은 design system 컴포넌트 문서화에도 동등하게 적용됩니다. adoption 장애물 기사는 문화적 요소를 강조했습니다. 거버넌스와 피드백 루프가 팀이 우회하는 기술적으로 완벽한 라이브러리보다 오래 살아남습니다.
참여 심리학에 관한 streak UX 심층 분석은 카테고리를 마무리하며 상기시켜 줬습니다. 손실 회피, Zeigarnik 효과, grace mechanism과 같은 행동 설계 레이어는 design system이 사용자 대면 기능을 출시할 때 컴포넌트 레이어만큼이나 중요합니다.
Key Takeaways
Token 명명은 아키텍처입니다. global-alias-component 3계층 구조로 멀티 브랜드 중복을 방지하고 단일 변수 theme 전환을 구현하세요
ARIA APG는 ARIA를 시연하기 위해 만들어졌으며 pattern library가 아닙니다. 항상 네이티브 HTML을 먼저 사용하고 실제 보조 기술로 테스트하세요
Design system adoption 실패는 컴포넌트 품질이 아니라 거버넌스와 문화 격차에서 비롯됩니다. 사용자와 함께 만들고 피드백 루프를 유지하세요
