크로스 플랫폼 디자인 시스템, 1.5년의 기록

1. 제품 언어 vs 범용 디자인 시스템

Chakra UI·MUI 같은 범용 라이브러리는 최대한 많은 사용 케이스를 지원하기 위해 유연성을 극대화합니다. 반면 회사 고유의 제품 언어는 '당근다운 느낌'처럼 브랜드 정체성을 담은 디자인 의사결정의 집합입니다. 범용 라이브러리는 이 의사결정을 그대로 반영할 수 없어 자체 디자인 시스템이 필요합니다. 제품 언어의 핵심: 'UI 컴포넌트를 만드는 것'이 아니라 '우리 서비스가 어떤 느낌이어야 하는지 결정하고 코드로 표현하는 것'입니다.

핵심 용어

2. 디자인 토큰: 크로스플랫폼 일관성의 핵심

디자인 토큰은 색상·폰트·간격 등 디자인 값을 이름 있는 변수로 추상화합니다. 레이어 구조: (1) Primitive 토큰 — `color-blue-500: #0064FF` (원시값), (2) Semantic 토큰 — `color-primary: {color-blue-500}` (의미 부여). Style Dictionary 같은 도구로 동일한 토큰 정의에서 Web(CSS 변수), iOS(Swift enum), Android(XML resource)를 자동 생성합니다. 다크모드 지원도 Semantic 토큰 레벨에서 `color-background`를 모드별로 다르게 매핑하면 됩니다.

핵심 용어

3. 컴포넌트 API 설계: 유연성과 일관성의 균형

디자인 시스템 컴포넌트는 너무 유연하면 일관성을 잃고(무엇이든 할 수 있으면 어떤 것도 강제할 수 없다), 너무 경직되면 실제 제품 요구사항을 수용하지 못합니다. 균형 방법: (1) 핵심 결정은 숨기고 표면만 노출 — `<Button variant='primary'>` OK, 버튼 색상 직접 오버라이드는 차단, (2) Composition 패턴 — 복합 컴포넌트를 분리해 사용 측이 조합 가능하게, (3) Escape Hatch 제공 — 예외적 케이스를 위한 `className/style` props는 허용.

핵심 용어

4. 디자인 시스템 팀의 흔한 함정

함정 1: 잘못된 참고 대상 — 반응형 웹 시스템(Bootstrap)을 모바일 앱에 그대로 적용하면 맞지 않습니다. 자신의 제품이 어떤 플랫폼과 유형인지 먼저 정의해야 합니다. 함정 2: 완벽한 범용 시스템 — 모든 팀의 모든 케이스를 커버하려다 아무것도 완성하지 못합니다. '80% 케이스를 커버하는 시스템 + 반복 가능한 확장 방법론'이 더 효과적입니다. 함정 3: 기술만 집중 — 디자이너·PM과의 협업 없이 만든 디자인 시스템은 채택율이 낮습니다.

핵심 용어

Q1. 디자인 시스템을 도입할 때 가장 먼저 정의해야 할 것은 무엇인가요?

힌트

[감점 답변] 정의만 반복하거나 "디자인 시스템을 도입할 때 가장 먼저 정의해야 할 것은 무엇인가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 세 가지를 순서대로 설명하세요: (1) 설계 목표 — 일관성 강화인지 개발 속도인지 (2) 대상 — 웹 전용인지 크로스플랫폼인지, (3) 범위 — 전사 공통 시스템인지 특정 제품 언어인지. '외부 라이브러리를 쓸지 자체 제작할지'는 이 세 가지를 정의한 후에 결정해야 한다는 점을 언급하면 됩니다.

Q2. 디자인 토큰이란 무엇이고, Primitive 토큰과 Semantic 토큰의 차이는 무엇인가요?

힌트

[감점 답변] 정의만 반복하거나 "디자인 토큰이란 무엇이고, Primitive 토큰과 Semantic 토큰의 차이는 무엇인가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 토큰을 '디자인 값의 이름 있는 변수'로 정의하고, 두 레이어를 예시로 설명하세요: Primitive — `blue-500: #0064FF` (단순 값), Semantic — `color-primary: blue-500` (역할 명시). 다크모드 지원 시 Semantic 레벨에서 `color-background`를 light/dark별로 다르게 매핑하는 예시를 들면 실용적인 답변이 됩니다.

Q3. 디자인 시스템 컴포넌트의 API를 설계할 때 유연성과 일관성을 어떻게 균형 잡나요?

힌트

[감점 답변] 정의만 반복하거나 "디자인 시스템 컴포넌트의 API를 설계할 때 유연성과 일관성을 어떻게 균형 잡나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] tradeoff를 먼저 설명하세요: 너무 유연하면 일관성 없는 UI가 나오고, 너무 경직되면 실제 요구사항을 수용 못함. 균형 방법: variant 패턴으로 허용된 변형만 노출, Composition으로 조합 가능하게, 예외를 위한 Escape Hatch(className) 제공. 'API를 작게 시작해 필요 시 확장'하는 전략이 처음부터 모든 케이스를 예측하는 것보다 낫다는 점도 언급하면 됩니다.

Q4. 디자인 시스템을 팀에 도입할 때 실제 채택율을 높이려면 어떻게 해야 하나요?

힌트

[감점 답변] 정의만 반복하거나 "디자인 시스템을 팀에 도입할 때 실제 채택율을 높이려면 어떻게 해야 하나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 기술적 완성도보다 사용자(개발자) 경험이 중요하다는 관점에서 설명하세요: Storybook으로 문서화해 사용 방법을 쉽게 찾을 수 있게 하기, Figma 컴포넌트와 코드를 연결(Code Connect)해 디자이너-개발자 간 소통 비용 줄이기, 초기 채택팀과 함께 빠르게 피드백 반영하기. 강제가 아닌 '쓰고 싶게 만드는' 접근이 효과적임을 강조하면 됩니다.

Q5. 기존 서비스에 이미 MUI 같은 외부 라이브러리를 쓰고 있을 때 자체 디자인 시스템으로 교체하는 전략은?

힌트

[감점 답변] 정의만 반복하거나 "기존 서비스에 이미 MUI 같은 외부 라이브러리를 쓰고 있을 때 자체 디자인 시스템으로 교체하는 전략은?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 점진적 교체 전략을 설명하세요: 신규 컴포넌트는 자체 시스템으로 만들고, 기존 컴포넌트는 수정 필요 시 교체. MUI 위에 Wrapper 컴포넌트를 만들어 API를 통일하면 나중에 내부 구현만 교체 가능. 완전 교체보다 Strangler Fig 패턴으로 점진적 전환이 리스크가 적습니다. 비용 대비 효과: 가장 많이 쓰이는 컴포넌트(Button, Input, Modal)부터 교체하는 것이 ROI가 높습니다.