08 — CSS Architecture
한 줄 답: 현대 CSS 아키텍처는 “색·간격·타이포를 어떻게 토큰으로 추상화하고 → 어떤 방법론(BEM·Tailwind·CSS Modules·CSS-in-JS)으로 컴포넌트에 분배하고 → 다크모드·성능까지 어떻게 한 시스템으로 통합하느냐” 의 문제다. CSS는 더 이상 문서 스타일이 아니라 디자인 시스템 언어다.
이 챕터가 답하는 질문
- 디자인 토큰은 정확히 무엇이고 W3C 명세는 어떻게 생겼나? (
01) - BEM·OOCSS·SMACSS·ITCSS — 5개 메서드는 무엇이 다르고, 모던 CSS(
@layer,@scope)는 왜 이걸 흡수하는가? (02) - Tailwind v4(2025)의
@layer/@utility/CSS-first config는 어떤 변화인가? (03) - CSS Modules의
composes와 build-time scoping은 어떻게 동작하나? (04) - styled-components vs vanilla-extract vs Panda — Runtime/Zero-runtime의 트레이드오프? (
05) - Open Props·Pico CSS·Web Components Shadow DOM — 클래스 없는 스타일링은 가능한가? (
06) light-dark()·color-scheme로 다크모드를 몇 줄에 끝낼 수 있는가? (07)- Critical CSS·
content-visibility·container query 비용 — 언제 무엇을 ship 하는가? (08)
챕터 지도 (Mermaid)
Why — 왜 아키텍처 챕터가 필요한가
CSS는 1996년 “문서를 꾸미는 한 줄짜리 선언” 이었다. 2025년의 CSS는 “수백 개 컴포넌트가 토큰을 공유하는 디자인 시스템의 인프라” 다. 그 사이 무엇이 변했나:
| 시대 | 단위 | 도구 | 문제 |
|---|---|---|---|
| 1996-2005 | 페이지 | style.css 하나 | 캐스케이드 충돌 |
| 2005-2015 | 사이트 | OOCSS·SMACSS·BEM | 클래스 이름 폭주 |
| 2015-2020 | 컴포넌트 | CSS Modules·styled-components | 런타임 비용·SSR 복잡도 |
| 2020-2025 | 토큰·시스템 | Tailwind·vanilla-extract·Panda·@layer | 빌드 타임 복잡도 |
이 챕터는 그 진화의 왜와 어떻게를 한 자리에 정리한다. “Tailwind를 쓸까 CSS Modules를 쓸까”라는 질문은 사실 “우리 팀의 토큰 전략과 컴포넌트 격리 전략이 무엇인가” 의 부분 질문이다.
How — 어떻게 읽나
의존성: 01(토큰)이 모든 후속 문서의 전제다. 02(메서드)는 0305의 문제 정의다. 0608은 06~07이 스타일링 패러다임, 08이 배포 단계다.
- 빠르게 훑고 싶다면:
01-design-tokens→03-tailwind→07-dark-mode-theming만으로도 70% 이해. - 새 프로젝트 기술 선택: 02·03·04·05를 모두 비교 → 팀 사이즈·SSR·RSC 호환성으로 결정.
- 레거시 마이그레이션:
02-methodologies(현재 어디인지)와03-tailwind/05-css-in-js(어디로) 비교. - 성능 최적화:
08-perf-and-shipping이 단독으로 읽힌다.
| # | 파일 | 읽는 데 | 핵심 키워드 |
|---|---|---|---|
| 01 | 01-design-tokens | 15분 | W3C DTCG, primitive/semantic/component, --token |
| 02 | 02-methodologies | 15분 | BEM, OOCSS, SMACSS, ITCSS, ECSS |
| 03 | 03-tailwind | 18분 | Atomic CSS, Tailwind v4, @utility, JIT |
| 04 | 04-css-modules | 12분 | :local, composes, hash 스코핑 |
| 05 | 05-css-in-js | 15분 | styled-components, Emotion, vanilla-extract, Panda |
| 06 | 06-modern-patterns | 12분 | Open Props, Pico, SFC, Web Components |
| 07 | 07-dark-mode-theming | 15분 | prefers-color-scheme, color-scheme, light-dark() |
| 08 | 08-perf-and-shipping | 12분 | Critical CSS, code splitting, content-visibility |
What — 다루는 표준과 범위
- W3C Design Tokens Format Module (DTCG, 2024 활성 Draft) — JSON 토큰 포맷
- CSS Cascade Level 5 —
@layer,revert-layer - CSS Cascade Level 6 —
@scope - CSS Color Module Level 5 —
light-dark()함수 - HTML Living Standard —
color-scheme - CSS Containment —
content-visibility: auto - 사실상 표준 — Tailwind v4, BEM, CSS Modules, styled-components(v6), vanilla-extract, Panda CSS, Open Props
Baseline 기준: @layer(2022), @property(2024), light-dark()(2024-Q2), content-visibility(Chromium 우선, Safari 18+).
What-if — 이 챕터를 건너뛰면
- 색상 200개를 하드코딩 → 다크모드 추가에 주 단위 작업이 든다.
- BEM·ITCSS 없이 50명 팀 → 1년 뒤 !important 지옥.
- Runtime CSS-in-JS를 React Server Components와 함께 → 빌드 깨짐.
- Critical CSS 미설정 → LCP 4초+ (모바일 3G 기준).
- 컴포넌트마다 다크모드 분기 → 토큰 30개 변경에 N개 파일 수정.
Insight — 문서 스타일에서 시스템 언어로
CSS가 변한 게 아니라, 우리가 CSS에 시키는 일이 변했다.
1996년 Håkon Wium Lie의 CSS1은 “신문 칼럼처럼 텍스트에 스타일을 입히자” 였다. 한 페이지·한 명·한 스타일시트.
2014년 Yandex의 BEM, 2009년 Nicole Sullivan의 OOCSS, 2013년 Jonathan Snook의 SMACSS, 2015년 Harry Roberts의 ITCSS — 이들은 수백 개 페이지·수십 명·CSS 캐스케이드가 적이 된 환경에서 캐스케이드를 코드 컨벤션으로 우회하려 했다.
2020년대의 흐름은 두 갈래로 나뉜다:
- 표준 진영 —
@layer·@scope·@property로 언어 수준에서 캐스케이드를 다스린다. - 도구 진영 — Tailwind·CSS Modules·CSS-in-JS로 빌드 타임에 캐스케이드를 회피한다.
흥미로운 점은 Tailwind v4가 두 진영을 합쳤다는 것이다 — CSS-first config, @utility, @layer 통합. Atomic CSS의 재림은 단순한 트렌드 회귀가 아니라, 모던 CSS가 따라잡은 결과다.
이 챕터의 모든 문서는 결국 한 질문에 답한다: “우리의 디자인 토큰을 어디서·언제·어떻게 컴포넌트에 주입할 것인가?” — 빌드 타임이냐 런타임이냐, 클래스냐 변수냐, 파일 단위냐 컴포넌트 단위냐.
한 단락 요약
CSS 아키텍처는 토큰(
01) → 메서드론(02) → 도구(03~05) → 패턴(06) → 테마(07) → 배포(08) 의 6단 스택이다. 이 챕터를 끝내면 “Tailwind vs CSS-in-JS” 같은 도구 비교를 넘어, “우리 팀의 디자인 시스템이 토큰 → 컴포넌트 → 배포까지 일관된 언어를 갖는가” 를 묻게 된다. 다음:01-design-tokens에서 W3C DTCG 명세부터 시작한다.