디자인 시스템

디자인 시스템이 해결할 것

• 스타일 가이드·컴포넌트 라이브러리·디자인 시스템을 구분한다
• 원시 값과 의미 토큰을 계층화한다
• 컴포넌트의 용도·상태·접근성을 문서화한다

토큰에서 운영까지

디자인 시스템의 역할

디자인 시스템은 화면 모음이 아니라 반복되는 결정을 줄이는 공통 언어입니다. 토큰은 값을, 컴포넌트는 사용 규칙을, 문서는 선택 기준을 설명합니다.

토큰 정의

색상 이름을 blue-500처럼 보이는 값으로만 정하지 말고 역할을 표현합니다.

1:root {2  --color-background: #ffffff;3  --color-foreground: #111827;4  --color-accent: #174ea6;5  --color-on-accent: #ffffff;6  --space-2: 0.5rem;7  --radius-control: 0.375rem;8}

색상, 타이포그래피, 간격, 크기, 모서리, 그림자부터 시작합니다. 실제로 반복되지 않는 값까지 미리 토큰으로 만들지 않습니다.

Variables와 Styles 선택

둘 다 전역 변경점이 될 수 있지만 같은 기능은 아닙니다. 색상 Style을 무조건 Variable로 옮기기보다 theme, alias, scope가 필요한지 먼저 확인합니다.

컴포넌트 API

버튼을 예로 들면 목적, 크기, 상태를 구분하고 조합 가능한 범위를 정합니다.

• 목적: primary / secondary / destructive
• 크기: small / medium / large
• 상태: default / hover / focus / disabled / loading
• 내용: 텍스트, 앞 아이콘, 뒤 아이콘

접근성 기준

컴포넌트 문서에는 키보드 조작, 포커스 표시, 의미 있는 이름, 오류 전달 방식을 포함합니다. 색만으로 상태를 구분하지 않고 버튼과 링크의 의미를 시각적 모양과 HTML 역할에서 일치시킵니다.

문서화 단위

각 컴포넌트 페이지에 다음 내용을 둡니다.

1. 언제 사용하고 언제 사용하지 않는가
2. 기본 예제와 최소 코드
3. 지원하는 상태와 변형
4. 콘텐츠 작성 규칙
5. 접근성·반응형 주의사항

디자인과 코드 동기화

Figma 이름과 코드 컴포넌트 이름을 최대한 맞추고 변경은 사용 중인 화면을 확인한 뒤 반영합니다. 시각적 차이보다 의미와 동작 차이를 먼저 해결합니다.

흔한 실수

• 한 번만 쓰는 화면 조각까지 공통 컴포넌트로 만듭니다.
• disabled와 loading을 같은 상태로 취급합니다.
• 토큰을 우회한 임의 값을 계속 추가합니다.
• 사용 예시 없이 속성 목록만 문서화합니다.

토큰과 컴포넌트의 경계

같은 숫자가 두 번 보인다고 모두 토큰이 되는 것은 아닙니다. 제품 의미를 갖고 여러 위치에서 함께 바뀌어야 하는 값만 토큰으로 승격합니다.

컴포넌트 문서 예시

Button

용도: 현재 화면에서 즉시 실행되는 행동에 사용합니다. 다른 URL로 이동하면 Link를 사용합니다.

참고: 컴포넌트 문서는 “가능한 props”보다 “언제 어떤 값을 선택해야 하는가”를 먼저 설명해야 합니다.

변경 절차

1. 현재 사용처와 깨질 수 있는 상태를 찾습니다.
2. Figma와 코드 중 기준이 되는 동작을 합의합니다.
3. 토큰 또는 컴포넌트를 한 곳에서 변경합니다.
4. 기본·hover·focus·disabled·오류 상태를 비교합니다.
5. 변경 이유와 마이그레이션 방법을 문서에 남깁니다.

시스템에 넣기 전 확인

• 여러 사용처에서 같은 의미로 반복되거나 일관된 규칙이 필요한 이유가 있습니다. 세 화면에 같은 숫자가 쓰였다는 사실은 참고 기준일 뿐 필수 조건이 아닙니다.
• 접근성 동작과 콘텐츠 규칙을 설명할 수 있습니다.
• 한 번만 쓰는 사례를 위해 불필요한 variant를 만들지 않았습니다.
• 삭제 또는 변경 시 영향을 받는 사용처를 찾을 수 있습니다.

작은 디자인 시스템 예제

1. 화면 감사

세션 신청 화면에서 반복되는 색, 글꼴, 간격, 버튼, 입력을 수집합니다. 비슷하지만 다른 사례를 먼저 찾고 시스템이 해결해야 할 불일치를 정합니다.

2. 최소 토큰 만들기

1:root {2  --color-background: #ffffff;3  --color-foreground: #101828;4  --color-action: #174ea6;5  --color-on-action: #ffffff;6  --space-control-gap: 0.5rem;7  --radius-control: 0.375rem;8}

숫자가 같다는 이유만으로 토큰을 합치지 말고 함께 바뀌어야 하는 의미를 기준으로 이름을 정합니다.

3. 컴포넌트 문서

Button과 Input 각각에 다음을 기록합니다.

• 언제 사용하고 언제 사용하지 않는가
• variant와 size를 선택하는 기준
• hover·focus·disabled·loading·error 상태
• 키보드 동작과 접근성 이름
• 실제 코드와 Figma 컴포넌트 연결

4. 변경 시뮬레이션

action 색과 기본 간격을 바꾸고 모든 화면이 토큰 변경을 따라가는지 확인합니다.

8주 세션: 실제 사용처에서 규칙 만들기

권장 100분: 화면 비교 20분, 최소 토큰 25분, Button·Input 사용 규칙 30분, 변경 검사 25분입니다. 6주의 화면과 7주의 명세에서 반복되는 결정만 가져옵니다.

버튼 문서 작성 예: ‘Primary는 한 영역의 핵심 제출에 사용한다. 이동은 Link를 사용한다. loading은 처리 중임을 문구로 알리고 중복 실행을 막는다. 오류는 입력 근처에서 원인과 수정 방법을 보여 준다. 키보드 포커스가 명확히 보여야 한다.’ 같은 색이어도 행동이 다르면 같은 컴포넌트로 억지로 합치지 않습니다.

토큰 색상은 배경색과 그 위 텍스트의 쌍으로 검토합니다. 위 CSS는 학습용 예시이며 실제 브랜드 팔레트의 모든 조합이 검증됐다는 뜻은 아닙니다. 기본·hover·focus·오류 상태에서 대비를 실제로 측정하고 기록합니다. 일반 본문의 명도 대비처럼 적용할 접근성 기준도 함께 확인합니다.

원본 간격이나 action 색을 한 곳에서 바꾸어 세 사용처에 반영되는지 검사합니다. 의도와 다르게 함께 변하는 요소가 있다면 토큰의 의미가 너무 넓은지 확인합니다.

완료 기준: Button·Input 각각의 사용/비사용 예, 상태, 키보드 동작, 실제 화면 사용처가 연결되고 토큰 변경 결과를 확인합니다. 새 Variant를 많이 만든 수보다 사용 기준의 명확성을 평가합니다.

더 읽어보기

• Figma Design systems course
• Figma Variables
• Atlassian Design System

다음 단계

8주 규칙을 프로토타입과 사용성 테스트에 적용하고 10주 개발 인계에서 실제 구현과 비교합니다.

연결된 PBL 미션과 VOD

PM은 ‘PM업무, 강의 하나로 정리하기’, Figma는 ‘Figma로 앱 디자인부터 포트폴리오까지’를 뜻합니다.

강좌 안내: 참고 강좌 1 · 참고 강좌 2. 이 문서는 영상 전체를 옮긴 전사 자료가 아닙니다. 세부 내용은 위 공식 문서에서 확인합니다.