design-systemlisted

# 디자인 시스템 프로젝트의 디자인 규칙(색·타이포·컴포넌트·레이아웃·UX 원칙)을 한 곳에서 관리하고, 새 UI를 만들거나 바꿀 때 기존 규칙과 맞는지 확인한다. 규칙이 없으면 현재 코드에서 추출해 초안을 만들거나, 새 규칙을 제안해 팀이 일관성을 유지하도록 돕는다. **언제 쓰나:** 새 화면·컴포넌트·UI 요소를 추가하거나 기존 UI를 변경할 때, 디자인 규칙·스타일 가이드를 만들거나 확인할 때 발동한다. UI 작업이 아닌 순수 로직·API·DB 작업에는 사용하지 않는다. --- ## 0. 규칙 소스 탐색·해석 (항상 가장 먼저) UI 작업을 시작하기 전, 프로젝트에 이미 디자인 규칙 파일이 있는지 먼저 확인한다. **스캔할 흔한 이름·위치:** - 마크다운 문서: `DESIGN.md`, `STYLEGUIDE.md`, `design-guidelines.md`, `docs/design*.md` - 코드형 권위: `tailwind.config.*`, theme 파일, 토큰 파일(`tokens.js`, `variables.css`, `design-tokens.*`, `*.tokens.json`), styled-components/emotion `theme.ts`, MUI `createTheme`, Chakra theme, Vanilla Extract, Panda CSS 설정 - 컴포넌트 문서: `.storybook/` 디렉터리 - README 내 Figma 링크 (피그마가 공식 소스인 경우) > **"못 찾음"을 성급히 결론짓지 말 것.** 위 목록에 안 잡혀도 `package.json`에 UI 프레임워크/디자인 라이브러리 의존성(MUI·Chakra·Tailwind·styled-components·Ant Design 등)이 있으면 이미 디자인 시스템이 있을 가능성이 크다. 초안을 새로 만들기 전에 "기존 디자인 시스템을 못 찾았는데 정말 없나요? 어디에 있나요?"라고 한 번 더 확인한다. (경쟁하는 두 번째 규칙 파일이 생기면 규칙이 갈라진다.) > **오탐 가드 — 설계 문서 ≠ 디자인 규칙.** `2026-01-01-기능-design.md`처럼 이름 중간에 `design`이 든 파일은 보통 **브레인스토밍 spec(설계 문서)**이지 디자인 규칙이 아니다. 위 패턴 `docs/design*.md`는 `design`으로 **시작**하는 파일만 잡으므로 안전하지만, `*design*`처럼 넓게 매칭하지 말 것. 매칭된 파일을 채택하기 전 내용이 실제 디자인 규칙(토큰·컴포넌트·UX)인지 한 번 확인한다. **상황별 처리 방식:** - **파일이 있으면:** 그 파일을 진실의 원천(Single Source of Truth)으로 채택한다. 이름이 달라도 내용이 디자인 규칙이면 그걸 쓴다. 새 파일을 만들지 않는다. - **부분만 덮는 파일이 있으면:** "빠진 층(예: 토큰은 있는데 UX 원칙이 없음)만 보완 문서로 만들까요?" 사용자에게 확인한 뒤 처리한다. 자동으로 추가 파일을 생성하지 않는다. - **여러 파일이 있어