다시 읽는 큰 그림

여기까지 오셨다면 DESIGN.md를 외우는 수준이 아니라 다시 설계할 수 있는 수준이에요. 마지막으로 큰 그림을 한 번 더 정리해요.

7개 모듈의 한 줄 교훈

M1. 포맷 철학 — "AI를 1등 독자로 두면 포맷이 바뀐다"

• 한 파일짜리 일반 텍스트라서 어느 도구·AI에서도 같은 방식으로 읽혀요
• YAML(기계용) + 마크다운(사람·AI용) 이중 구조로 두 쪽이 어긋나지 않게
• 토큰이 정답, 본문이 근거 — 어긋나면 토큰이 이겨요

M2. 토큰 스키마 — "형식은 좁게, 이름은 넓게"

• 최상위 키 6개는 고정이지만 그 안의 이름은 자유
• 색은 sRGB hex만, 길이는 px·em·rem만 — 검증·변환 단순
• 참조 {path.to.token}로 값 복붙 없애고, 의미 연결을 구조로 표현

M3. 섹션 구조 — "추상 → 원자 → 조합 → 가드레일"

• Overview → Colors → Typography → Layout → Elevation → Shapes → Components → Do's and Don'ts
• 순서 어기면 경고, 중복은 에러 — 강제와 관용의 균형
• Do's and Don'ts로 "하지 마" 목록을 명시

M4. 실제 예시 — "같은 기법, 다른 서사"

• Atmospheric Glass: 밝은 유리 + 다채로운 배경
• Paws & Paths: 모던 코퍼레이트, 의미별 색 분리
• Totality Festival: 어두운 유리, 천문학 모티프로 일관성

M5. CLI — "스펙이 자동화에 바로 꽂히도록"

• lint: CI에 맞는 심각도·종료 코드
• diff: AI가 자기 수정의 품질 변화를 스스로 재는 도구
• export: Tailwind·DTCG로 기존 생태계와 연결
• spec: 포맷 자체를 AI 컨텍스트에 바로 주입

M6. 검사 규칙 — "AI가 메울 수 있는가로 심각도를 나눈다"

L256The linter runs seven rules against a parsed DESIGN.md. Each rule produces findings at a fixed severity level.

에러 1 · 경고 5 · 정보 2 분포 — 빌드를 막는 건 "기능이 망가진 경우"뿐. 나머지는 사람·AI가 판단할 여지를 남겼어요.

M7. 확장성 — "새 것에는 관대, 모호함에는 엄격"

• 처음 보는 섹션·토큰 이름은 그대로 보존
• 처음 보는 컴포넌트 속성은 받되 경고
• 중복 섹션만 에러 — 어느 쪽을 믿어야 할지 모르니까

여러분의 작업에 가져갈 원리 10개

이 커리큘럼을 다 끝냈다면 할 수 있는 것

• DESIGN.md 파일을 직접 쓰고 읽어낼 수 있어요
• 8개 검사 규칙이 각각 어떤 실패를 막는지 설명할 수 있어요
• 세 공식 예시의 기법과 서사를 비교할 수 있어요
• 같은 원리를 여러분의 API 스펙·AI 시스템 프롬프트·팀 문서에 옮겨 심을 수 있어요

그럼 우리는 이 파일을 어떻게 운영해야 할까

DESIGN.md는 특정 직군 한 명이 관리하는 문서가 아니라, 우리 팀이 함께 쓰는 디자인 의사결정의 원본 파일이에요. Figma에 있는 색상 값을 복사해 두는 문서가 아니라, 왜 이 색을 쓰는지, 어디까지 허용되는지, 어떤 느낌은 피해야 하는지까지 남기는 살아있는 운영 기준이에요.

디자이너가 맡을 일

• Figma 값만 옮기지 않기 — 값보다 중요한 건 그 값을 쓰는 이유와 판단 기준이에요
• 새 화면에서 반복 패턴 발견하기 — 폼·카드·버튼 같은 패턴이 두 번 이상 나오면 컴포넌트 규칙 후보로 올려요
• 사용 맥락과 예외 기록하기 — 언제 쓰고, 언제 쓰지 말아야 하며, 언제 예외를 허용하는지 남겨요
• 금지 규칙을 명확히 쓰기 — AI에게는 "잘 만들어"보다 "이건 하지 마"가 훨씬 강력해요
• 브랜드 감각을 언어로 고정하기 — 차분함·전문성·밀도·여백 같은 감각을 다음 사람이 따라 할 수 있게 문장으로 남겨요

개발자가 맡을 일

• DESIGN.md와 코드 토큰 연결하기 — CSS 변수, Tailwind theme, 컴포넌트 스타일이 문서의 토큰과 어긋나지 않게 맞춰요
• 반복 구현을 컴포넌트로 고정하기 — 문서에 올라온 버튼·카드·폼 패턴을 실제 재사용 가능한 UI로 만들어요
• lint·diff·export 자동화 붙이기 — DESIGN.md 변경이 PR에서 검증되고, 필요한 파생 파일이 자동 생성되게 해요
• 접근성과 반응형을 검증하기 — 문서의 색 조합·타입 스케일·간격이 실제 화면에서 읽히고 깨지지 않는지 확인해요
• AI 작업 전에 DESIGN.md를 컨텍스트로 넣기 — 새 컴포넌트나 페이지를 만들 때 AI가 팀의 시각 언어를 먼저 읽게 해요

함께 리뷰할 일

• DESIGN.md 변경을 PR처럼 리뷰하기 — 색 하나, radius 하나도 브랜드 전체에 영향을 줄 수 있어요
• 문서와 실제 화면의 차이 줄이기 — Figma·CSS·운영 화면 중 하나만 앞서 나가지 않게 맞춰요
• 규칙으로 올릴지, 한 번의 예외로 둘지 결정하기 — 모든 디자인 결정을 토큰으로 만들 필요는 없어요

다음에 해볼 것

• 여러분이 쓰는 디자인 시스템을 DESIGN.md로 바꿔 보기 (Figma 변수 → DTCG → DESIGN.md 순서)
• Cursor·Claude에 DESIGN.md를 컨텍스트로 넣고 컴포넌트 생성 품질을 비교해 보기
• lint·diff를 GitHub Actions에 붙여 PR 자동 리뷰 만들기
• 이 스펙의 설계 원리를 팀의 "AI용 가이드 문서"에 이식해 보기