Foundations Terms

이 문서가 답하는 질문: 디자인 시스템을 이론적으로 말할 때 쓰는 용어들이 정확히 무엇을 가리키는가? 한 줄 답 (Pyramid Top): 이 카테고리는 “무엇을 만드는가”가 아니라 “왜·어떻게 만드는가” 의 어휘 — 원칙·계약·거버넌스를 다룬다.

카테고리 개요

키워드	한 줄 정의
Atomic Design	컴포넌트를 5계층(atom→template)으로 분해하는 방법론
Contract	디자인-개발 간 약속을 코드로 표현한 것
Single Source of Truth	한 값은 한 곳에만 정의하라는 원칙
Adoption	만든 시스템을 실제로 쓰게 만드는 일
Governance	변경을 통제하는 규칙·절차

본문 (알파벳 순)

Adoption (도입)

카테고리: Foundations 별칭: rollout, internal adoption

만든 디자인 시스템을 조직 내부 팀들이 실제로 쓰게 만드는 과정. 기술 문제(코드)보다 사회 문제(인센티브·교육·마이그레이션 비용)가 더 크다.

관련: Governance, Migration, Versioning 참고: 00-foundations

Atomic Design

카테고리: Foundations 별칭: Brad Frost methodology

Brad Frost(2013)가 제안한 5계층 분해 — atom → molecule → organism → template → page. UI를 화학에 비유했다는 점에서 영향력이 컸지만, 실제 코드 폴더 구조보다는 사고 프레임으로 더 많이 쓰인다.

Bedrock (기초석)

카테고리: Foundations 별칭: foundation layer

토큰·타입·색·간격 등 그 위에 모든 것이 얹히는 가장 아래 레이어를 가리키는 비공식 용어. Material Design이 즐겨 쓴다.

Component Library (컴포넌트 라이브러리)

카테고리: Foundations 별칭: UI kit

재사용 가능한 UI 부품 모음. 디자인 시스템 ⊃ 컴포넌트 라이브러리 — 시스템은 값과 규칙까지 포함하지만, 라이브러리는 코드 부품만 포함한다.

관련: Design System, Headless Component

Contract (계약)

카테고리: Foundations 별칭: API contract, design contract

디자인 결정을 기계가 검증 가능한 형태로 표현한 것. 예: color.primary가 존재해야 한다는 토큰 contract, <Button variant="primary">의 props contract. 깨지면 빌드가 실패해야 한다.

Design Language (디자인 언어)

카테고리: Foundations 별칭: visual language

브랜드의 시각적 표현을 언어처럼 규칙화한 것. Material, Fluent, Carbon이 대표적. 디자인 시스템보다 더 철학적·문서적인 상위 개념.

Design System (디자인 시스템)

카테고리: Foundations 별칭: DS, design platform

“디자인 결정을 코드로 직렬화한 5개 레이어 — Foundations · Tokens · Recipes · Theming · Distribution”의 총체. 컴포넌트 라이브러리·문서·거버넌스를 모두 포함한다.

Designer-Developer Handoff

카테고리: Foundations 별칭: handoff, design handoff

Figma·Sketch의 디자인 결과를 개발자가 코드로 옮기는 지점. 토큰 export(Tokens Studio, Figma Variables → DTCG JSON)가 이 지점을 자동화한다.

Foundations

카테고리: Foundations 별칭: primitives layer, foundation

토큰·색·타이포·spacing·radius 같은 값 그 자체의 레이어. 이 레포의 00-foundations 챕터에서 다룬다.

Governance (거버넌스)

카테고리: Foundations 별칭: design system governance

토큰·컴포넌트·문서가 바뀔 때 누가 승인하고 어떻게 배포되는가를 정한 규칙. RFC, breaking change policy, semver가 핵심 도구.

관련: RFC, Versioning, Changesets 참고: 08-pipeline-distribution

Living Documentation

카테고리: Foundations 별칭: living docs, docs as code

코드와 함께 변하는 문서. Storybook autodocs, MDX, Chromatic snapshot이 대표 도구. 별도 PDF·Notion 문서는 living이 아니다.

Migration (마이그레이션)

카테고리: Foundations 별칭: codemod, breaking-change migration

토큰 이름 변경·variant 정리 등으로 기존 코드가 깨질 때, 기계가 코드를 자동 변환하는 작업. jscodeshift, ts-morph 기반 codemod가 표준.

관련: Adoption, Versioning, Changesets

Primitive (프리미티브)

카테고리: Foundations 별칭: primitive component, low-level primitive

스타일이 없는 동작만 있는 컴포넌트. Radix Primitives가 대표. 디자인 시스템은 이 위에 시각만 입혀 만들기도 한다.

관련: Headless Component, shadcn pattern

RFC (Request for Comments)

카테고리: Foundations 별칭: design proposal

큰 변경을 공개적으로 토의하기 위한 문서 양식. IETF에서 유래. 디자인 시스템에서는 새 토큰·컴포넌트 도입의 표준 절차.

shadcn pattern

카테고리: Foundations 별칭: copy-paste components

shadcn/ui가 대중화한 패턴 — npm 설치가 아니라 코드를 복사해 자기 레포에 두고 자유롭게 수정. Radix Primitives + Tailwind 조합이 표준.

Single Source of Truth (SSOT)

카테고리: Foundations 별칭: 단일 출처, source of truth

한 값은 한 곳에만 정의하라는 원칙. 디자인 시스템에서 가장 자주 인용되는 원칙. 토큰 시스템의 존재 이유 그 자체.

Versioning (버전 관리)

카테고리: Foundations 별칭: semver, semantic versioning

라이브러리 변경을 major.minor.patch로 표현하는 규약. 디자인 시스템에서는 토큰 이름 변경 = major, 새 토큰 추가 = minor, 값 미세 조정 = patch가 관행.

관련: Changesets, Migration, Governance

Visual Regression Testing

카테고리: Foundations 별칭: VRT, snapshot test, Chromatic

컴포넌트 변경 후 픽셀이 바뀌었는지 자동 비교. Chromatic, Percy, Playwright의 toMatchSnapshot이 대표 도구.

요약 + Mermaid

이 카테고리는 디자인 시스템 왜·어떻게의 어휘다. 모든 값(Token)·규칙(Recipe) 이전에 “누가 무엇을 약속하는가” 가 먼저 정해져야 한다.

📖 개요 Token Terms