디자인 시스템 'Loop' 구축

배경

본업 외 사이드로 함께 진행하던 작은 SaaS 제품에서 UI 컴포넌트가 화면마다 미세하게 다르게 만들어지는 문제가 누적되고 있었습니다. 버튼 hover 색이 화면마다 다르고, 카드 모서리 반경이 4·6·8·10px이 섞여 있었으며, 디자이너-개발자 핸드오프 시 매번 같은 토론을 반복했습니다. 작은 팀이지만 "한 번 정리하면 다음부터 빨라진다"는 직관이 분명했습니다.

접근 — 토큰 우선, 컴포넌트는 그 다음

흔히 시작점으로 잡는 "버튼·카드·모달을 다 그려놓고 보자"가 아니라, 토큰 계층을 먼저 확정하는 순서로 갔습니다. 이유는 두 가지였습니다.

• 토큰이 흔들리면 컴포넌트 가이드도 흔들림 — 거꾸로 가면 재작업이 큼
• Figma 변수와 코드 토큰의 1:1 대응이 명확해야 디자인-개발 핸드오프가 의미 있어짐

핵심 결정

1. 2계층 토큰 — Primitive(색·간격·반경 원시값)와 Semantic(surface·border·ink 등 의미 단위)을 분리. 디자이너는 Semantic만 만지고, Primitive 변경은 시스템 PR로만
2. 이름 규칙 — color.surface.base, radius.md 같은 점-구분 네임스페이스 채택. Figma 변수와 CSS 변수가 동일 이름
3. Figma 변수 ↔ 코드 동기화 — Figma 변수를 JSON 으로 export → Style Dictionary 파이프라인으로 CSS·Tailwind 토큰을 자동 생성. 디자이너의 토큰 수정이 개발 PR을 자동 트리거
4. 컴포넌트는 토큰으로만 — 컴포넌트 안에 raw hex나 px 사용 금지. 토큰 위반 시 lint 단계에서 실패하도록 ESLint 룰 추가

운영 모델

시스템은 만드는 것보다 운영이 어렵습니다. 작은 팀에서도 지속 가능하도록 세 가지 룰을 두었습니다.

• Semantic 토큰 추가는 디자이너 PR + 시스템 리뷰 1명
• Primitive 변경은 전체 영향도 분석 + 코어 멤버 2명 리뷰
• 컴포넌트 신규는 사용처 2개 이상 발생 시점에만 시스템에 흡수 (조기 추상화 방지)

회고

토큰을 먼저 잡은 결정이 가장 큰 효과를 냈습니다. 컴포넌트 가이드라인이 후속으로 자연스럽게 정리되었고, 디자이너 입장에서도 "이 색이 surface 인지 background 인지"가 명확해져 의사결정 속도가 빨라졌습니다. 아쉬운 점은 — 도큐먼트 작성에 충분한 시간을 못 쓴 것. 토큰 이름은 직관적이지만 처음 합류하는 멤버에게는 여전히 학습 곡선이 있어, 다음 시즌엔 Storybook + 토큰 사용 예시 문서화에 더 시간을 들이려 합니다.