Design System

Tech

회사에서 디자인 시스템과 관련된 논의가 있었고, 추후 디자인 시스템 구축을 위한 작업이 진행될 수 있다는 내용을 전달받았다. 이전에도 작은 서비스 단위나 조직 내에서 디자인 시스템을 구축하려는 시도는 있었지만, 큰 효과를 보지 못한 채 마무리되는 경우가 많았던 것 같다. 이번에는 많은 사람이 함께 협력하여 탄탄한 디자인 시스템을 구축할 수 있기를 바라며, 디자인 시스템이 어떻게 발전해 왔고 현재는 어떤 형태로 활용되고 있는지 조사해 보려 한다.

사실 디자인 시스템은 이렇게 만들어져야 한다는 정답이 있는 분야는 아니다. 디자인 시스템에 대한 개념과 원칙은 존재하지만, 이를 구축하고 운영하는 방식에는 하나의 정답이 있는 것이 아니다. 그렇기에 지금 정리하려는 내용 역시 정답이라기보다는, 과거에는 디자인 시스템이 어떤 방식으로 만들어졌는지 참고하는 정도로 보면 좋겠다. 이전에는 어떻게 만들어져 왔고 어떤 문제를 겪었는지 살펴본다면, 앞으로 만들어 나갈 디자인 시스템을 더욱 좋은 방향으로 설계하는 데 도움이 되지 않을까 기대해 본다.



Design System 2.0?

자료를 조사하던 중 Design System 2.0이라는 표현을 자주 접하게 되었다. 처음에는 내가 모르는 디자인 시스템의 공식 정의나 표준 명칭이 있는 것인가 싶어 찾아보았지만, 이는 공식 용어나 표준 명칭은 아니었다.

Design System 2.0은 기존의 정적으로 관리되던 디자인 요소와 컴포넌트 중심의 체계에서 벗어나, Design Token을 중심으로 디자인 자산을 관리하고 자동화 파이프라인을 구축하며, Figma와 코드 간 동기화를 통해 디자인과 개발을 더욱 긴밀하게 연결하는 구조적 변화를 설명하기 위해 업계에서 비공식적으로 사용하는 용어에 가깝다. 최근에는 여기에 AI를 활용한 컴포넌트 생성, 문서화, 코드 생성 등의 흐름까지 더해지면서 이러한 표현이 자주 사용되고 있다.



문서

디자인 시스템이 등장하기 전에는 디자이너가 만든 스타일 가이드를 참고하여 개발자가 직접 코드를 작성하는 방식이 일반적이었다. 디자이너가 정의한 색상, 여백, 폰트 등의 값을 그대로 코드에 옮겨 구현하는 것이 전부였던 것이다.


jsx
// features/checkout/SubmitButton.tsx
export function SubmitButton() {
  return (
    <button style={{
      backgroundColor: '#0066FF',   // 디자인 문서에 정의된 값을 그대로 사용
      color: '#FFFFFF',
      padding: '12px 24px',
      borderRadius: 4,
    }}>
      결제하기
    </button>
  )
}

위와 같이 요소 내에서 색상이나 여백과 같은 스타일 값이 직접 관리되는 구조였다. 이러한 방식에서는 프로젝트 내 여러 곳에서 동일한 파란색 값을 반복해서 사용하거나, 조금씩 다른 파란색이 혼재되어 사용되는 일이 쉽게 발생한다. 또한 #0066FF와 같은 값만으로는 이것이 브랜드의 기본 색상인지, 강조 색상인지와 같은 디자인 의도를 알기 어렵다. 결국 동일한 스타일 값이 여러 곳에 중복되고, 디자인 변경 시 수정 범위가 커지는 등 유지보수 측면에서 구조적인 한계를 가지고 있었다.

이러한 문제를 해결하기 위해 스타일 값을 의미 있는 이름으로 추상화하여 관리하려는 시도가 등장했고, Salesforce Lightning Design System과 같은 사례를 통해 Design Token 개념이 널리 알려지기 시작했다. 이후 W3C 표준으로 정의된 CSS Custom Properties가 주요 브라우저에서 네이티브로 지원되면서, 웹 환경에서는 Design Token을 구현하는 핵심 기술로 자리 잡게 되었다.



컴포넌트

이 시기에는 현대적인 디자인 시스템의 기반이 마련되기 시작했다. UI 요소를 서비스(프로젝트) 내부에서 각각 구현하는 대신, 별도의 라이브러리나 프로젝트에서 공통 컴포넌트로 관리하고 서비스에서 이를 설치하여 사용하는 방식이 자리 잡기 시작했다. 또한 실제 화면과 독립적으로 컴포넌트를 개발하고 Storybook을 통해 문서화하는 문화도 널리 확산되었다.

이와 함께 Design Token을 빌드 파이프라인에 포함하는 방식도 활용되기 시작했다. JSON 형태로 관리되는 Design Token을 Style Dictionary와 같은 도구를 통해 각 플랫폼에서 사용할 수 있는 형태로 자동 생성함으로써, 디자인 값을 일관되게 관리할 수 있게 되었다.


jsx
// 사용하는 쪽
import { Button } from '@acme/ui'

export function SubmitButton() {
  return <Button variant="primary" size="md">결제하기</Button>
}

jsx
// @acme/ui/Button.tsx
import { tokens } from '@acme/tokens'

const VARIANTS = {
  primary: {
    backgroundColor: tokens.color.primary,
    color: tokens.color.onPrimary,
  },
  secondary: {
    backgroundColor: tokens.color.secondary,
    color: tokens.color.onSecondary,
  },
}

export function Button({ variant = 'primary', ...props }) {
  return <button style={VARIANTS[variant]} {...props} />
}

이러한 구조를 통해 디자인 시스템을 사용하는 서비스에서는 공통 컴포넌트를 간편하게 사용할 수 있었고, 디자인 값 역시 Design Token을 통해 일관성 있게 관리할 수 있게 되었다. 다만 토큰을 컴파일한 결과를 컴포넌트 내부에서 소비하는 방식이 일반적이었기 때문에, 런타임에서 테마를 전환하거나 플랫폼별 스타일을 유연하게 변경하는 데에는 여전히 제약이 있었다.



토큰 계층

Design Token이 널리 활용되기 시작하면서, 많은 디자인 시스템에서는 토큰을 역할에 따라 여러 계층으로 나누어 관리하기 시작했다. 대표적으로 Primitive, Semantic, Component의 3계층 구조가 많이 사용되며, 각 계층은 다음과 같은 역할을 담당한다.

  • Primitive: 실제 디자인 값을 정의한다. (color.blue.500 → #0066FF)
  • Semantic: 디자인 의도를 표현한다. (color.action → color.blue.500)
  • Component: 특정 컴포넌트에서 사용할 토큰을 정의한다. (button.background.primary → color.action)

이러한 구조에서는 컴포넌트가 Primitive 토큰을 직접 참조하지 않고, Semantic과 Component 계층을 거쳐 실제 디자인 값을 사용하게 된다. 이를 통해 동일한 디자인 의도를 여러 컴포넌트에서 일관되게 사용할 수 있으며, 실제 값이 변경되더라도 상위 계층만 수정하면 전체 컴포넌트에 반영된다.


Design Token의 포맷은 W3C Design Tokens Community Group(DTCG)에서 표준화를 진행해 왔으며, 2025년 10월 28일 Design Tokens Format Module v2025.10이 Community Group Report로 발행되었다. 이 규격은 토큰의 데이터 구조와 참조 방식 등을 정의하며, 현재 대부분의 Design Token 도구가 이를 기반으로 발전하고 있다.


DTCG v2025.10

json
{
  "color": {
    "$type": "color",
    "blue-500": {
      "$value": {
        "colorSpace": "srgb",
        "components": [0, 0.4, 1],
        "hex": "#0066ff"
      }
    },
    "blue-300": {
      "$value": {
        "colorSpace": "srgb",
        "components": [0.3, 0.58, 1],
        "hex": "#4d94ff"
      }
    },
    "action": {
      "$value": "{color.blue-500}",
      "$description": "주요 동작 버튼·링크에 사용"
    }
  },
  "space": {
    "$type": "dimension",
    "md": {
      "$value": { "value": 12, "unit": "px" }
    },
    "lg": {
      "$value": { "value": 24, "unit": "px" }
    }
  }
}

토큰은 빌드 과정에서 참조를 해석하고 플랫폼별 형식으로 변환된다. 이 과정에서 토큰 간의 참조 관계는 유지하면서도 최종적으로 사용할 실제 값을 획득할 수 있다.

jsx
color.action = "{color.blue-500}"
        ↓ Alias Resolve
color.blue-500 = {
  colorSpace: 'srgb',
  components: [0, 0.4, 1],
  hex: '#0066ff'
}
        ↓
color.action = { ... } + 참조 정보(['color', 'blue-500'])

웹 플랫폼에서는 이러한 토큰이 CSS Custom Properties로 변환되며, 토큰 계층 역시 CSS 변수의 참조 관계로 그대로 표현된다.

css
:root {
  --color-blue-500: #0066ff;
  --color-blue-300: #4d94ff;
  --color-action: var(--color-blue-500);

  --space-md: 12px;
  --space-lg: 24px;
}

컴포넌트는 Primitive 토큰을 직접 사용하는 대신 Component Token을 통해 스타일을 정의한다.

css
/* components/button.css */
:root {
  --button-bg-primary: var(--color-action);
  --button-padding-y: var(--space-md);
  --button-padding-x: var(--space-lg);
}

.btn {
  padding: var(--button-padding-y) var(--button-padding-x);
}

.btn--primary {
  background-color: var(--button-bg-primary);
}

tsx
// Button.tsx
export function Button({ variant = 'primary', ...props }) {
  return <button className={`btn btn--${variant}`} {...props} />
}

이처럼 컴포넌트는 색상이나 여백과 같은 구체적인 스타일 값을 직접 정의하지 않고, Component Token을 통해 스타일을 적용하게 되었다. 그 결과 디자인 값의 변경은 토큰 계층에서 관리되고, 컴포넌트는 디자인 의도만을 소비하는 구조로 발전하게 되었다.


이후 Figma Variables가 2023년 Config에서 공개되면서 디자인 도구에서도 토큰을 직접 관리할 수 있게 되었다. 이를 계기로 Figma를 Design Token의 Source of Truth로 사용하는 사례가 크게 늘어났으며, Figma에서 관리하는 토큰을 DTCG 형식으로 내보내고 Style Dictionary와 같은 도구를 통해 CSS, Android, iOS 등 각 플랫폼의 코드로 자동 변환하는 파이프라인이 널리 사용되기 시작했다.

txt
Figma Variables
        ↓ Export
tokens/*.json (DTCG)
        ↓
Style Dictionary
        ↓
variables.css
        ↓
Component CSS

기존에는 디자인 값을 코드로 옮기는 것이 목적이었다면, 이제는 Design Token 자체가 디자인과 개발을 연결하는 하나의 데이터(Source of Truth) 역할을 하게 된 것이 가장 큰 변화라고 볼 수 있다.



Tailwind

Tailwind CSS는 2017년에 등장했으며, 스타일을 CSS에 작성하는 대신 유틸리티 클래스를 마크업에서 직접 조합하는 방식을 제안했다. 전통적인 Design Token의 계층 구조를 따르지는 않았지만, 디자인 값을 한곳에서 관리하고 이를 기반으로 스타일을 생성한다는 점에서는 비슷한 철학을 가지고 있었다.

jsx
<button className="bg-blue-500 px-6 py-3 rounded">
  결제하기
</button>

Tailwind v3까지는 tailwind.config.js의 theme 설정에서 색상, 간격, 폰트 등의 디자인 값을 관리했다.

jsx
// tailwind.config.js
export default {
  theme: {
    extend: {
      colors: {
        mint: {
          500: "#3dd9c5"
        }
      }
    }
  }
}

이후 2025년 1월 공개된 Tailwind CSS v4.0에서는 CSS-first 설정 방식이 도입되면서, 기존 JavaScript 설정보다 CSS에서 디자인 값을 정의하는 방식이 중심이 되었다.

css
@import "tailwindcss";

@theme {
  --color-mint-500: oklch(0.72 0.11 178);
}

빌드 결과는 다음과 같이 네이티브 CSS Custom Properties를 기반으로 생성된다.

css
:root {
  --color-mint-500: oklch(0.72 0.11 178);
}

또한 --color-*, --spacing-*, --radius-*, --font-*, --shadow-*와 같은 네임스페이스를 기반으로 CSS 변수와 유틸리티 클래스를 함께 생성한다. Tailwind가 DTCG 기반의 Design Token 구조를 따르는 것은 아니지만, 디자인 값을 CSS 변수 중심으로 관리하고 이를 다양한 스타일에 재사용하는 방향으로 발전했다는 점에서는 Design Token 중심 설계와 유사한 흐름을 보여준다.



AI

최근에는 AI가 디자인 시스템 구축 과정에도 적극적으로 활용되면서, 디자인에서 코드로 이어지는 작업이 점차 자동화되고 있다. Figma MCP Server나 shadcn/ui MCP Server와 같은 도구를 통해 AI는 Design Token, 컴포넌트 명세, 디자인 정보 등을 직접 조회하고 이를 기반으로 프로젝트에 맞는 코드를 생성할 수 있게 되었다.

예를 들어 Figma Variables에서 관리되는 Design Token은 tokens.json 형태로 내보내고, 이를 Style Dictionary와 같은 도구를 통해 variables.css로 변환한다. AI는 여기에 Figma Node 정보와 프로젝트의 컴포넌트 구조를 함께 참고하여 화면을 구성하는 코드를 생성한다. 생성된 결과는 AGENTS.md와 같은 프로젝트 규칙이나 프롬프트를 참고하며, 결과적으로 이전에 살펴본 Design Token 계층이나 Tailwind CSS 기반 구조와 유사한 형태의 코드를 생성하는 경우가 많다.

이 과정에서 Registry의 존재는 매우 중요한 역할을 한다. AI는 레지스트리를 통해 프로젝트에서 제공하는 컴포넌트와 사용 방법을 이해할 수 있으며, AGENTS.md와 registry.json을 명확하게 정의할수록 프로젝트에 일관된 코드를 생성할 가능성이 높아진다.

json
// registry.json — AI가 조회하는 컴포넌트 명세
{
  "name": "Button",
  "import": "import { Button } from '@acme/ui'",
  "props": {
    "variant": {
      "type": "enum",
      "values": ["primary", "secondary", "ghost"],
      "default": "primary"
    }
  },
  "styling": {
    "method": "token-driven",
    "tokens": [
      "--button-bg-primary",
      "--button-text-primary"
    ],
    "doNot": "style/className으로 색상이나 간격을 직접 지정하지 않는다."
  },
  "whenToUse": "사용자가 동작을 실행할 때 사용한다. 페이지 이동은 Link를 사용한다."
}


tsx
// ❌ 레지스트리가 없는 경우
<button className="bg-blue-600 px-6 py-3 rounded-lg text-white">
  결제하기
</button>

// → 프로젝트의 디자인 시스템과 무관한 일반적인 UI를 생성할 수 있다.

// ❌ 존재하지 않는 토큰을 추측하는 경우
<button style={{ background: "var(--color-primary-action-main)" }} />

// → 정의되지 않은 CSS 변수이므로 의도한 스타일이 적용되지 않는다.

// ✅ 레지스트리를 참고한 경우
<Button variant="primary">
  결제하기
</Button>

과거에는 디자인 시스템이 사람이 참고하기 위한 문서였다면, 이제는 AI가 이해하고 활용할 수 있는 데이터와 명세의 역할도 함께 수행하게 되었다. Design Token, Registry, AGENTS.md와 같은 정보는 단순한 개발 문서가 아니라, AI가 프로젝트의 규칙을 이해하고 일관된 코드를 생성하기 위한 중요한 컨텍스트가 되어가고 있다.



Design System

이번 내용을 정리하며 가장 크게 느낀 점은, 이전에는 디자인 시스템을 디자이너가 정의한 디자인을 개발자가 구현하기 위한 시스템 정도로만 생각했다는 것이다. 하지만 지금의 디자인 시스템은 디자이너와 개발자가 함께 만들어 가는 공통의 시스템에 가깝다. 서로의 결과물이 일관성을 유지하고 있는지 지속적으로 확인하며, Design Token을 비롯한 디자인 시스템의 개념과 구축 방식에 대해 같은 이해를 바탕으로 협업해야 한다고 생각하게 되었다.

최근 새로운 프로젝트를 진행하면서도 디자이너가 전달한 Figma를 기반으로 Figma MCP Server와 AI를 활용해 컴포넌트를 생성하는 작업을 경험했다. 당시에는 각자의 영역에서 맡은 결과물을 만드는 데 집중했지만, 디자인 시스템 전체의 구조와 디자인에서 코드까지 이어지는 생성 과정을 함께 고민했다면 더 좋은 결과물을 만들 수 있었을 것이라는 아쉬움이 남는다.

이번 글을 작성하며 디자인 시스템이 지금과 같은 형태로 발전하기까지의 과정을 살펴보니, 그동안 알지 못했던 개념과 과거의 한계를 다시 돌아볼 수 있었다. 물론 디자인 시스템의 구축 방식이나 운영 방법에 하나의 정답은 없을 것이다. 하지만 과거의 시행착오를 이해하고 현재의 흐름을 바탕으로 설계한다면, 앞으로 만들어 갈 디자인 시스템은 이전보다 더 일관되고 유연하며, 사람과 AI가 함께 활용할 수 있는 방향으로 발전해 나갈 수 있지 않을까 기대해 본다.

Design-System-1

"Coming together is a beginning. Keeping together is progress. Working together is success." - Henry Ford -