디자인 시스템은 규칙이 아니라 언어다

구글에는 머티리얼 디자인이 있고, 애플에는 휴먼 인터페이스 가이드라인이 있으며, IBM에는 카본 디자인 시스템이 있습니다. 이 세 거대 기업이 방대한 리소스를 투입해 디자인 시스템(Design System)을 구축하고 유지하는 이유는 무엇일까요. 단순히 화면을 예쁘게 만들기 위해서가 아닙니다. 수백 명의 디자이너와 개발자가 동시에 작업하면서도 일관된 경험을 보장하기 위한 구조적 장치입니다.

스타일 가이드와 디자인 시스템의 차이

디자인 시스템을 스타일 가이드와 혼동하는 경우가 많습니다. 스타일 가이드는 색상, 폰트, 로고 사용 규칙을 정리한 정적 문서입니다. 디자인 시스템은 그보다 훨씬 넓은 범위를 포괄합니다. 재사용 가능한 컴포넌트 라이브러리, 상호작용 패턴, 접근성 기준, 코드 스니펫, 그리고 이 모든 것을 관통하는 설계 원칙까지 포함합니다. 스타일 가이드가 사전이라면, 디자인 시스템은 문법서와 작문 교본을 겸합니다. 살아 있는 문서로서 제품과 함께 진화하며, 새로운 패턴이 발견되면 업데이트되고, 더 이상 유효하지 않은 컴포넌트는 퇴출됩니다.

어도비의 스펙트럼(Spectrum)은 디자인 시스템의 모범 사례로 자주 언급됩니다. 스펙트럼은 단순히 버튼과 입력 필드의 디자인을 규정하는 것이 아니라, 각 컴포넌트가 어떤 맥락에서 사용되어야 하는지, 다른 컴포넌트와 어떻게 조합되어야 하는지, 접근성 요구사항은 무엇인지까지 명시합니다.

토큰이라는 공용어

현대 디자인 시스템의 핵심 개념은 디자인 토큰(Design Token)입니다. 토큰은 색상, 간격, 타이포그래피 등의 디자인 속성을 추상화한 변수입니다. 예를 들어 브랜드의 기본 색상을 직접 #046BD2로 지정하는 대신 color-primary라는 토큰에 저장합니다. 이렇게 하면 브랜드 색상이 변경될 때 토큰 값 하나만 수정하면 전체 제품에 일괄 반영됩니다.

토큰은 디자이너와 개발자 사이의 번역 비용을 제거합니다. 디자이너가 Figma에서 사용하는 토큰 이름과 개발자가 CSS에서 참조하는 변수 이름이 동일하면, “이 회색은 정확히 어떤 회색이죠?”라는 커뮤니케이션 비용이 사라집니다. 토큰을 JSON 형태로 관리하면 디자인 변경사항이 코드에 자동 반영되는 파이프라인도 구축할 수 있습니다. 이전 글에서 다룬 크로스 플랫폼 디자인 일관성의 실현 방법이 바로 여기에 있습니다. 토큰 기반 시스템은 웹, iOS, 안드로이드 각각의 플랫폼에 동일한 설계 의도를 전달하는 공용어 역할을 합니다.

제약이 창의성을 만든다

디자인 시스템이 창의성을 억압한다는 비판이 있습니다. 정해진 컴포넌트와 규칙 안에서만 설계해야 하니 자유가 줄어든다는 것입니다. 그러나 소네트가 14행이라는 제약 안에서 탄생한 걸작들을 떠올려 보십시오. 제약은 방향을 제한하는 것이 아니라 에너지를 집중시킵니다. 디자인 시스템이 버튼의 모양과 색상을 규정해 주면, 디자이너는 그 시간을 정보 구조와 사용자 흐름이라는 더 본질적인 문제에 투자할 수 있습니다.

다이터 람스가 브라운(Braun)에서 보여준 설계 철학도 같은 맥락입니다. 그는 제품 라인 전체에 일관된 설계 언어를 적용하면서도 각 제품의 고유한 기능적 아름다움을 훼손하지 않았습니다. 디자인 시스템은 람스의 원칙을 디지털 제품의 규모에서 구현하는 도구입니다.

디자인 시스템은 제품이 성장할수록 그 가치가 기하급수적으로 커집니다. 영국 디자인 카운슬(Design Council)의 연구에 따르면, 체계적인 디자인 투자는 기업의 매출 성장과 강한 상관관계를 가집니다. 디자인 시스템은 그 투자의 구조적 기반입니다. Mimi Artz는 개별 화면의 미학을 분석하는 것에서 나아가, 그 화면을 가능하게 하는 시스템의 구조 자체를 비평의 대상으로 확장할 것입니다.