theming

2 개의 포스트

figma

Headspace와 함께 살아 (새 탭에서 열림)

Headspace는 제품·파트너십·브랜드 확장에 대응하려면 수작업과 플러그인 중심의 디자인 시스템을 확장 가능한 구조로 전환해야 했다. 이를 위해 Figma의 변수와 디자인 토큰을 도입하고, 단일 브랜드용 시스템을 여러 브랜드와 플랫폼을 지원하는 시스템으로 재구축했다. 그 결과 디자인·엔지니어링 팀이 공유할 수 있는 소스 오브 트루스를 마련하고, 반복적인 색상·타이포그래피 변경 작업을 크게 줄일 수 있었다. ## 확장에 한계가 있던 기존 디자인 시스템 - Headspace는 앱, 웨어러블, VR, 다양한 브랜드 협업 등 100개국 이상에서 여러 접점을 운영하고 있었다. - 기존 시스템은 수작업과 플러그인에 크게 의존해 규모가 커질수록 유지보수가 어려웠다. - 색상이 고정된 hex 코드로 관리되어 동일한 색상에 여러 값이 생겼고, 화면과 제품 간 사용자 경험이 일관되지 않았다. - 색상 팔레트처럼 단순한 변경에도 디자인 시스템 담당자가 몇 시간에서 며칠을 소비해야 했다. - 플러그인은 임시 해결책이었지만 다음과 같은 문제가 있었다. - 디자이너가 자주 사용하지 않으면 학습 비용이 높았다. - Figma의 스타일을 수정할 때마다 플러그인을 다시 설정해야 했다. - 디자인·엔지니어링 팀이 신뢰할 수 있는 단일 기준점을 제공하지 못했다. ## 여러 브랜드를 위한 시스템으로 전환 - 2021년 Ginger와의 합병이 발표되면서 Headspace는 단일 브랜드용 시스템의 한계를 해결해야 했다. - 새 시스템은 Headspace뿐 아니라 Headspace Care와 향후 파트너 브랜드까지 수용할 수 있어야 했다. - 기존 시스템을 감사한 뒤 컴포넌트와 패턴을 다시 구축해 디자이너와 엔지니어가 쉽게 찾고 참조할 수 있도록 했다. - 이 과정에서 Headspace 최초의 디자인 토큰 시스템을 만들었다. - 색상, 타이포그래피 등 반복적으로 사용되는 디자인 속성을 추상화해 브랜드별로 재사용하고 변경할 수 있는 기반을 마련했다. ## Figma 변수와 디자인 토큰 도입 - Headspace는 기존 플러그인 중심 워크플로를 Figma의 네이티브 변수 기능으로 대체했다. - 색상 값을 직접 입력하는 대신 의미 기반 토큰으로 관리했다. - 예: 특정 hex 코드가 아니라 배경색, 텍스트색, 강조색과 같은 역할 중심 이름을 사용 - 변수에 값을 연결하면 하나의 값을 변경해 이를 사용하는 여러 컴포넌트와 화면에 일괄 반영할 수 있다. - 테마와 브랜드가 달라져도 같은 컴포넌트 구조를 유지하면서 변수 값만 교체할 수 있다. - Steven은 약 2년 동안 플러그인 기반 시스템을 구축했지만, 변수 도입 후 색상 토큰과 타이포그래피를 하루 만에 변수로 구현했다고 설명한다. - 변경 사항은 한 달 이내에 디자이너와 엔지니어에게 배포되었다. ## 디자인·엔지니어링 협업 개선 - 토큰과 컴포넌트를 명확하게 구조화해 디자인과 코드 사이의 대응 관계를 쉽게 만들었다. - 디자이너는 반복적인 스타일 수정 대신 제품 경험과 시스템 개선에 집중할 수 있게 되었다. - 엔지니어는 임의의 색상값이나 스타일을 해석하는 대신 공유된 토큰을 기준으로 구현할 수 있다. - 디자인 시스템이 브랜드 가이드 문서에 머무르지 않고 실제 제품 제작 과정에서 작동하는 소스 오브 트루스가 되었다. - 여러 제품과 플랫폼이 늘어나도 동일한 원칙과 컴포넌트를 재사용할 수 있는 확장성을 확보했다. Headspace 사례는 디자인 시스템을 단순히 컴포넌트 모음으로 관리하기보다, 변수와 토큰을 활용해 브랜드·테마·플랫폼 변화를 흡수하는 구조로 설계해야 한다는 점을 보여준다. 특히 제품과 조직이 빠르게 성장한다면 하드코딩된 스타일과 플러그인 의존성을 줄이고, 의미 기반 토큰과 네이티브 변수부터 정비하는 것이 실용적인 출발점이다.

figma

코드에서 영감 얻기 | Figma (새 탭에서 열림)

디자인 시스템이 복잡성과 규모를 감당하려면 코드의 설계 원칙에서 배울 필요가 있다. 특히 고정된 컴포넌트와 과도한 변형 조합 대신 구성(composition), 구조와 표현의 분리, 체계적인 변경 관리가 중요하다. 궁극적으로 디자인 시스템은 창의성을 제한하는 규칙 모음이 아니라, 유연성과 일관성을 함께 제공하는 제품처럼 운영되어야 한다. ### 디자인의 복잡성과 코드에서 얻는 교훈 - 과거에는 디자인 파일이 개인 컴퓨터에 저장되어 협업이나 파일 간 의존성을 크게 신경 쓰지 않아도 됐다. - 오늘날에는 여러 팀과 기여자가 서로 연결된 시스템을 동시에 다루므로 일관성, 품질, 확장성을 관리해야 한다. - 디자인 시스템은 복잡성을 줄이는 데 도움을 주지만, 구조가 지나치게 강해지면 자유로운 탐색과 표현을 방해할 수 있다. - Figma는 이러한 문제에 대응하기 위해 디자인이 코드의 엔지니어링 프레임워크를 차용하고 있다고 설명한다. ### 중첩 컴포넌트로 유연한 레이아웃 구성 - 단순한 시스템에서는 하나의 컴포넌트에 몇 가지 변형(variant)만 정의하면 된다. - 카드처럼 가로형·세로형 등 레이아웃이 다양해지면 모든 경우를 variant로 만드는 방식은 유지보수가 어려워진다. - 컴포넌트 속성으로 이미지, 인용문 등 선택적 요소를 제어할 수 있지만, 구조 자체가 크게 다른 레이아웃에는 한계가 있다. - 작은 하위 컴포넌트를 만든 뒤 이를 큰 컴포넌트 안에 중첩하는 **구성(composition)** 방식을 사용할 수 있다. - 이미지, 제목, 가격, 버튼 같은 하위 컴포넌트를 다양한 방식으로 조합하면 시스템 관리자가 미리 예상하지 못한 레이아웃도 유연하게 만들 수 있다. - 이는 코드에서 재사용 가능한 모듈을 조합해 여러 기능을 구현하는 방식과 유사하다. ### 구조와 표현의 분리 - 초기 디자인 시스템은 컴포넌트에 특정 색상을 직접 지정하는 단순한 형태로 시작하는 경우가 많다. - 이후 다크 모드가 필요해지고, 제품·브랜드별 색상까지 추가되면서 테마 관리가 복잡해진다. - 제품과 하위 브랜드가 늘어날수록 각 컴포넌트에 색상과 스타일을 직접 넣는 방식은 조직의 관리 부담을 키운다. - 이러한 문제를 해결하려면 컴포넌트의 구조와 시각적 표현을 분리하는 새로운 아키텍처가 필요하다. - 글에서는 그 대안으로 **헤드리스 디자인 시스템(headless design system)**을 소개하려 하지만, 제공된 본문은 해당 설명 중간에서 끝난다. ### 실용적인 결론 컴포넌트의 모든 경우를 미리 variant로 만들기보다, 재사용 가능한 하위 컴포넌트를 조합하는 구조를 우선 고려하는 것이 좋다. 또한 색상·테마 같은 표현 요소를 구조와 분리하면 다크 모드, 멀티브랜드, 하위 제품 확장에 더 효과적으로 대응할 수 있다.