[G1-Sync] Manual knowledge update
This commit is contained in:
@@ -2,103 +2,171 @@
|
||||
id: wiki-2026-0508-css-modules
|
||||
title: CSS Modules
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [CSS Module, Locally-Scoped CSS]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [css, frontend, scoping, build-tool]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: css
|
||||
framework: webpack/vite
|
||||
---
|
||||
|
||||
# [[CSS Modules|CSS Modules]]
|
||||
# CSS Modules
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
CSS Modules는 표준 CSS 문법을 사용하면서도 빌드 단계에서 클래스명을 고유하게 변환하여 컴포넌트 단위로 스타일을 자동으로 스코핑(scoping)하는 CSS 아키텍처 접근법입니다 [1-3]. 전역 네임스페이스 충돌을 방지하기 위해 BEM과 같은 수동 규칙에 의존하는 대신, 도구를 통해 고유한 해시 클래스명을 생성함으로써 유지보수성을 극대화합니다 [4, 5]. 런타임 오버헤드가 없는 정적 CSS를 생성하므로 성능이 뛰어나며, React 및 [[Next.js|Next.js]]와 같은 최신 프레임워크 환경에서 전역 오염 없이 안전하게 UI를 구축할 수 있게 해줍니다 [6-8].
|
||||
## 매 한 줄
|
||||
> **"매 class 가 file-locally scoped"**. CSS Modules 매 build-time transform 으로 매 class name 을 unique hash 로 rewriting — 매 global namespace pollution 의 elimination + component-level encapsulation 의 enable. 매 2026 현재 Vite/Webpack/Next.js 매 native support, 매 CSS-in-JS runtime cost 의 alternative 로 주류.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동작 방식 및 특징:**
|
||||
CSS Modules를 사용하면 개발자는 익숙한 표준 CSS 문법을 그대로 작성할 수 있습니다 [6, 9]. 작성된 CSS 파일(`.module.css`)을 [[JavaScript|JavaScript]] 컴포넌트에 임포트하면, 빌드 도구가 `.button`과 같은 클래스명을 `Button_button__x9KdL`과 같은 고유한 식별자로 자동 변환합니다 [3, 9]. 또한, `composes` 기능을 통해 기존 스타일을 쉽게 확장할 수 있으며 [1], Sass([[SCSS|SCSS]])나 PostCSS와 같은 기존 CSS 도구와도 완벽하게 통합됩니다 [1, 10].
|
||||
## 매 핵심
|
||||
|
||||
* **장점:**
|
||||
* **완벽한 스코핑 및 충돌 방지:** 클래스명이 자동으로 컴포넌트에 스코핑되므로, 스타일이 의도치 않게 다른 곳에 영향을 미치는 전역 충돌(global namespace collision) 문제를 원천적으로 차단합니다 [5, 6, 9, 11].
|
||||
* **제로 런타임 오버헤드 (Zero Runtime Overhead):** 스타일이 빌드 타임에 처리되어 정적 CSS로 출력되므로, 런타임에 스타일을 파싱하는 [[CSS-in-JS|CSS-in-JS]] 방식과 달리 브라우저 성능에 악영향을 주지 않으며 브라우저 캐싱을 최대한 활용할 수 있습니다 [6, 7, 12].
|
||||
* **기존 CSS 생태계 및 유연성 활용:** 복잡한 애니메이션, 미디어 쿼리, 가상 요소(pseudo-elements) 및 복잡한 선택자 등 CSS의 모든 기능을 제한 없이 자연스럽게 사용할 수 있습니다 [7, 9]. 특정 프레임워크에 종속되지 않습니다 [7].
|
||||
* **개발자 경험 향상:** TypeScript와 결합하여 모듈 클래스명에 대한 타이핑을 생성함으로써 오타를 빌드 타임에 잡아낼 수 있습니다 [13].
|
||||
### 매 작동 원리
|
||||
- `Button.module.css` 매 import 시 매 bundler 가 매 class 를 `Button_primary__a3fG2` 로 rename.
|
||||
- 매 import 결과 매 object — `{ primary: 'Button_primary__a3fG2' }`.
|
||||
- 매 component 매 `styles.primary` 로 reference — 매 collision-free.
|
||||
|
||||
* **단점 및 한계:**
|
||||
* **파일 전환 (Context Switching):** 스타일을 수정할 때 JavaScript/JSX 파일과 `.module.css` 파일을 번갈아 가며 작업해야 하는 번거로움이 있습니다 [7].
|
||||
* **동적 스타일링의 어려움:** CSS-in-JS와 달리 CSS와 JavaScript 간에 데이터를 공유하거나 컴포넌트 상태(Props)에 따른 동적인 스타일을 직접 부여하는 과정이 까다로우며, 이를 위해 조건부 문자열 연결(string concatenation) 작업이 필요합니다 [1, 7, 10].
|
||||
* **네이밍 피로 (Naming Fatigue):** 유틸리티 클래스를 제공하는 [[Tailwind CSS|Tailwind CSS]]와 달리 개발자가 여전히 요소마다 의미 있는 클래스 이름을 고민하고 지어주어야 합니다 [14].
|
||||
### 매 vs alternatives
|
||||
- **vs global CSS**: 매 scoping 자동, 매 BEM 매 manual convention 의 replacement.
|
||||
- **vs CSS-in-JS**: 매 zero runtime, 매 build-time only — 매 bundle size + perf 우위.
|
||||
- **vs Tailwind**: 매 component-local custom design 매 적합, Tailwind 매 utility-first.
|
||||
|
||||
* **실무 활용 전략:**
|
||||
CSS Modules는 탄탄한 CSS 역량을 갖춘 팀이나, 복잡한 애니메이션 및 세밀한 CSS 제어가 필요한 프로젝트에 가장 적합합니다 [14]. 특히 2025년 기준 [[Next.js App Router|Next.js App Router]]와 같은 [[React Server Components|React Server Components]](RSC) 환경에서는 런타임 CSS-in-JS 라이브러리의 호환성 문제로 인해 Tailwind CSS나 CSS Modules를 사용하는 것이 강력히 권장됩니다 [8, 15]. 대규모 프로젝트의 실무에서는 레이아웃과 간격에는 빠르고 일관된 Tailwind CSS를 사용하고, 복잡한 커스텀 로직이나 애니메이션이 필요한 컴포넌트 스타일에는 CSS Modules를 사용하는 방식으로 두 기술의 장점을 결합한 하이브리드 아키텍처를 채택하기도 합니다 [16-18].
|
||||
### 매 응용
|
||||
1. Component library (Button, Input) 매 encapsulated styling.
|
||||
2. Next.js 매 default-supported pattern — `*.module.css` 매 convention.
|
||||
3. Design system 매 token + component 매 layered structure.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[BEM|BEM]], Tailwind CSS, CSS-in-JS, [[SCSS|SCSS]]
|
||||
- **Projects/Contexts:** [[컴포넌트 기반 아키텍처|컴포넌트 기반 아키텍처]], React Server Components, [[Next.js App Router|Next.js App Router]]
|
||||
- **Contradictions/Notes:** 소스 문헌들은 BEM이 개발자의 수동적인 명명 규칙 준수에 의존해 휴먼 에러가 발생하기 쉬운 반면, CSS Modules는 빌드 도구를 통해 "자동화된 캡슐화"를 제공하여 BEM이 풀고자 했던 문제를 더 깔끔하게 해결한다고 비교합니다 [4, 5, 11, 13]. 또한, Tailwind CSS는 클래스명을 짓는 수고와 파일 전환의 피로를 없애주지만 마크업 코드가 길어지고 자의적인 값이 쌓일 수 있는 반면, CSS Modules는 깔끔한 HTML을 유지하지만 파일 전환과 네이밍 피로가 존재한다는 트레이드오프 관계를 가집니다 [7, 14, 19, 20].
|
||||
## 💻 패턴
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
### Basic usage
|
||||
```css
|
||||
/* Button.module.css */
|
||||
.primary {
|
||||
background: #0070f3;
|
||||
color: white;
|
||||
padding: 8px 16px;
|
||||
border-radius: 4px;
|
||||
}
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
.disabled {
|
||||
opacity: 0.5;
|
||||
cursor: not-allowed;
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
```tsx
|
||||
// Button.tsx
|
||||
import styles from './Button.module.css';
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
export function Button({ disabled, children }: Props) {
|
||||
return (
|
||||
<button
|
||||
className={`${styles.primary} ${disabled ? styles.disabled : ''}`}
|
||||
disabled={disabled}
|
||||
>
|
||||
{children}
|
||||
</button>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Composition (`composes`)
|
||||
```css
|
||||
/* base.module.css */
|
||||
.button {
|
||||
font: inherit;
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
/* Button.module.css */
|
||||
.primary {
|
||||
composes: button from './base.module.css';
|
||||
background: #0070f3;
|
||||
}
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### `clsx` 와 conditional classes
|
||||
```tsx
|
||||
import clsx from 'clsx';
|
||||
import styles from './Card.module.css';
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
export function Card({ variant, active }: Props) {
|
||||
return (
|
||||
<div className={clsx(styles.card, styles[variant], active && styles.active)}>
|
||||
...
|
||||
</div>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
### TypeScript typed module
|
||||
```ts
|
||||
// Button.module.css.d.ts (auto-generated by typescript-plugin-css-modules)
|
||||
declare const styles: {
|
||||
readonly primary: string;
|
||||
readonly disabled: string;
|
||||
};
|
||||
export default styles;
|
||||
```
|
||||
|
||||
### `:global` escape hatch
|
||||
```css
|
||||
/* Layout.module.css */
|
||||
.root :global(.markdown) h1 {
|
||||
/* unscoped — for third-party HTML */
|
||||
font-size: 2rem;
|
||||
}
|
||||
```
|
||||
|
||||
### Vite config
|
||||
```ts
|
||||
// vite.config.ts
|
||||
export default {
|
||||
css: {
|
||||
modules: {
|
||||
localsConvention: 'camelCaseOnly',
|
||||
generateScopedName: '[name]__[local]__[hash:base64:5]',
|
||||
},
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Component-scoped styling, zero runtime | **CSS Modules** |
|
||||
| Dynamic styles (props-driven) | CSS-in-JS (vanilla-extract, styled-components) |
|
||||
| Utility-first, rapid prototyping | Tailwind |
|
||||
| Server Components 매 styling | CSS Modules (Tailwind 도 OK) |
|
||||
|
||||
**기본값**: Next.js / Vite 매 component-level styling 의 first choice 로 **CSS Modules**.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[CSS]] · [[Build Tool]]
|
||||
- 변형: [[CSS-in-JS]] · [[Tailwind CSS]] · [[BEM]]
|
||||
- 응용: [[Next.js]] · [[Vite]] · [[React]]
|
||||
- Adjacent: [[Vanilla-Extract]] · [[PostCSS]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: component encapsulation 매 필요, runtime cost 의 회피, TypeScript-friendly typing.
|
||||
**언제 X**: 매 dynamic theming 매 heavy (variant explosion), 매 design token 매 runtime mutation 매 필요 — vanilla-extract / CSS variables.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **`:global` 매 남용**: 매 scoping benefit 의 nullification.
|
||||
- **String concatenation 매 raw**: 매 `clsx` 의 사용 — 매 readability + falsy handling.
|
||||
- **`styles['kebab-case']` access 매 unnecessarily**: 매 `localsConvention: 'camelCaseOnly'` 매 설정.
|
||||
- **Module 1개 매 100+ classes**: 매 split — 매 component-per-module.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Next.js docs 2026, Vite CSS Modules guide).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — CSS Modules build-time scoping + composition + Vite/Next 통합 |
|
||||
|
||||
Reference in New Issue
Block a user