큰 코드베이스에 도움이 되는 CSS 아키텍처 방법론에는 어떤 것들이 있나요?

Question

Accepted Answer

프로젝트가 커지면 일반 CSS는 **전역 스코프** 때문에 고통받습니다 — 모든 selector가 전역에서 경쟁하고, specificity 전쟁이 일어나며, 아무도 규칙을 감히 삭제하지 못합니다. 방법론은 CSS를 유지보수 가능하게 유지하기 위해 구조와 명명 규칙을 부과합니다. ## BEM (Block Element Modifier) 관계를 명시적으로 만들고 specificity를 평평하게 유지하는(모두 단일 클래스) 명명 규칙입니다. ```css .card { } /* Block — 독립적인 컴포넌트 */ .card__title { } /* Element — 블록의 일부 (밑줄 두 개) */ .card__button { } .card--featured { } /* Modifier — 변형 (대시 두 개) */ ``` ```html

...

``` BEM의 가치: 클래스 이름이 자기 문서화되고, 규약으로 스코프가 지정되며, 균일하게 낮은 specificity를 갖습니다(중첩/id 전쟁 없음). ## 유틸리티 우선 (Tailwind) 작은 단일 목적 클래스를 마크업에 직접 조합합니다. ```html

...

``` 장점: 명명 불필요, 미사용 CSS 없음(purge됨), 일관된 디자인 토큰. 단점: 장황한 HTML. 속도와 일관성으로 크게 인기 있습니다. ## 스코프 지정 / CSS Modules & CSS-in-JS 컴포넌트 프레임워크에서의 최신 접근 — 스타일을 컴포넌트에 스코프 지정해 **새어 나갈 수 없게** 합니다. ```jsx import styles from "./Card.module.css"; // 클래스 이름이 해시/지역화됨

...

// → .Card_card__a1b2 (고유) ``` 이는 규약이 아니라 메커니즘으로 전역 스코프 문제를 해결합니다. ## 그 외 시스템 ```text OOCSS — 구조와 스킨 분리, 객체 재사용 SMACSS — 규칙 분류 (base, layout, module, state, theme) ITCSS — specificity로 CSS 계층화 (generic → explicit), 낮은 것에서 높은 것으로 ``` ## 공통 목표 이들 모두 같은 적과 싸웁니다: **specificity 증가**, **명명 충돌**, **죽은 코드**, **예측 불가능한 cascade**. 명명(BEM), 유틸리티(Tailwind), 스코프 지정(Modules) 중 무엇을 통하든, CSS를 예측 가능하고 규모가 커져도 안전하게 변경할 수 있게 유지합니다. ## 왜 중요한가 큰 CSS 코드베이스는 규율이 없으면 전역 스코프와 specificity 전쟁 아래 무너집니다. 방법론(오늘날 흔히 BEM, Tailwind, 또는 스코프 지정 CSS Modules)을 고르고 일관되게 적용하는 것이 팀과 코드베이스가 성장하면서도 스타일을 모듈화되고 삭제 가능하며 충돌 없게 유지하는 비결입니다.