# CSS는 유지보수의 지옥이다 디자이너든 개발자든, 웹을 다루는 사람이라면 누구나 한 번쯤 겪어봤을 경험이 있습니다. 분명 내 페이지만 수정했는데, 전혀 상관없는 옆 페이지의 레이아웃이 바뀌는 경험. 혹은 동료가 작성한 코드를 열었는데 `.wrapper`, `.box`, `.inner`, `.content` 같은 클래스명이 난무해서 유지보수 하기가 어려웠던 경험 말입니다. 이것은 비단 한두 사람만의 이야기가 아닙니다. **CSS는 배우기 쉽지만, 지키기는 어렵습니다.** 진입 장벽이 낮다는 건 큰 장점이지만, 프로젝트 규모가 커지는 순간 그 장점은 독이 되어 돌아옵니다. 바로 **전역 스코프(Global Scope)**와 **모호한 네이밍** 때문입니다. 이로 인해 현장에서는 보통 다음과 같은 3가지 재앙이 발생합니다. - **클래스 중복:** 내가 쓴 `.title`이 동료가 쓴 `.title`과 충돌한다. - **종속성 지옥:** 자식 요소만 바꿨는데 부모 레이아웃까지 틀어진다. - **구조 파악 불가:** 클래스 이름만 봐서는 이게 페이지 어디에 붙어있는지 알 수가 없다. 결국 우리는 서로의 코드를 덮어쓰기(Overwrite) 시작합니다. 당장의 문제를 해결하기 위해 금기시된 `!important`를 남발하고, 아무도 사용하지 않지만 지우기는 무서운 '유령 코드'들이 쌓여갑니다. **완벽한 스파게티 코드의 탄생**이죠. **욕먹지 않기 위한 생존 전략, '약속'** 협업에서 생산성과 유지보수는 타협할 수 없는 제1의 가치입니다. 내 코드가 동료에게 스트레스가 되지 않으려면, 우리에겐 강력한 **약속**이 필요합니다. 위에서 언급한 CSS의 고질적인 문제들을 해결하고, 평화로운 협업을 가능하게 해 줄 가장 유명하고 강력한 방법론. **BEM(Block Element Modifier)**을 소개합니다. ---
# BEM (Block Element Modifier) ## BEM이란? BEM은 **Block(블록)**, **Element(요소)**, **Modifier(수식어)**의 앞 글자를 딴 약어입니다. 러시아의 검색 엔진 기업 Yandex에서 유지보수 문제를 해결하기 위해 고안한 방법론입니다. 이 방법론의 핵심 목표는 간단합니다. **"클래스 이름만으로 마크업 구조를 상상할 수 있어야 한다."** 기존 방식은 웹페이지를 하나의 거대한 문서로 봤다면, BEM은 페이지를 독립적인 블록을 조립하는 형태로 봅니다. 레고처럼 블록을 쌓아올리죠.
## BEM의 3요소 BEM은 이름 그대로 세 가지 핵심 요소로 구성됩니다. 각 요소가 어떤 역할을 하는지 살펴보겠습니다. ### 1) Block (블록) 블록은 **그 자체로 의미가 있는 독립적인 컴포넌트**로, 페이지의 어느 위치에 놓더라도 기능이 정상적으로 작동해야합니다. - 특징: 문맥에 의존하지 않습니다. 즉, `margin`이나 `position`처럼 주변 요소에 영향을 주는 스타일을 블록 자체에 주지 않는 것이 좋습니다. - 예시: `header`, `menu`, `search-form`, `card` BEM의 개념중 가장 큰 컴포넌트 적인 요소로, 자동차로 비유하자면 **차체(Frame)**에 해당합니다. ### 2) Element (요소) 요소는 **블록을 구성하는 내부 단위**입니다. 블록 밖에서는 의미를 갖지 않고 반드시 블록 안에 속해 있어야 합니다. - 특징: 독립적으로 사용되지 않습니다. `search-form`이라는 블록 없이 `input`은 그저 입력창일 뿐 검색 입력 창이라는 의미를 갖지 못합니다. - 예시: `menu item`, `list item`, `checkbox caption`, `header title` Block에 속하는 개념으로 자동차의 구성요소인 바퀴, 엔진, 핸들 같은 세부 요소로 생각하면 좋습니다. ### 3) Modifier (수식어) 수식어는 **블록이나 요소의 외관, 상태, 동작을 변경**하는 데 사용합니다. - 특징: 기존 스타일을 덮어쓰거나 추가할 때 사용합니다. 어떤 게 변하거나 어떤 상태인지를 설명합니다. - 예시: `disabled`(비활성), `highlighted`(강조), `size-big`(큰 사이즈), `color-red`(빨간색) 같은 자동차더라도 고장난 자동차, 빨간색 자동차 등을 상세히 표현할 수 있다고 생각하면 좋습니다.
## BEM 작성 규칙 (Syntax) BEM을 이해하기 위해선 위의 3가지 요소가 가장 중요합니다. 그리고 그것들을 잘 파악하기 위해선 문법역시 중요합니다. 이제 이를 코드로 구현하기 위한 **약속(Naming Convention)**을 알아볼 차례입니다. BEM에서는 각 요소를 구분하기 위해 특정한 **구분자(Separator)**를 사용합니다. ### 1) 구분자의 역할 BEM의 클래스명은 다소 길고 복잡해 보일 수도 있습니다. 그것은 블록, 요소, 수식어 3가지를 전부 작성하기 때문이기도 하며, 바로 이 구분자 때문에 더욱 길어집니다. 그러나 이 규칙 덕분에 우리는 HTML의 구조를 보지 않고도 클래스명으로 그 역할을 명확하게 알 수 있습니다. - **`__` (Double Underscore):** Block과 Element를 연결할 때 - **`--` (Double Hyphen):** Block(또는 Element)과 Modifier를 연결할 때 - **`-` (Single Hyphen):** 단어와 단어 사이를 띄어쓰기할 때 (기존 CSS 방식) ### 2) 요소별 작성법 #### Block (블록) 가장 기본이 되는 이름입니다. 소문자를 사용하며, 두 단어 이상일 경우 하이픈(`-`)으로 연결합니다. ```css .card { } .profile-card { } /* 단어가 두 개일 때 */ ``` #### Element (요소) 블록 이름 뒤에 **언더바 두 개(`__`)**를 붙여서 요소를 선언합니다. ```css /* button 블록 안의 icon 요소 */ .button__icon { } /* profile-card 블록 안의 title 요소 */ .profile-card__title { } ``` #### Modifier (수식어) 블록이나 요소 뒤에 **하이픈 두 개(`--`)**를 붙여서 상태 변화를 표현합니다. ```css /* 버튼 블록의 active 상태 */ .button--active { } /* profile-card 블록 안의 image 요소가 round 모양 일 때 */ .profile-card__image--round { } ``` > [!tip] > > 왜 굳이 두 개(`__`, `--`)를 쓰나요? > > 이미 기본적으로 단어 띄어쓰기를 위해 하이픈은 사용되어 왔습니다. 만약 `site-search-button-active`라고 쓴다면 한 눈에 3요소가 파악되지 않으며, 각 요소들을 추정해야만 합니다. > > 그러나 `site-search__button--active`라고 명시적으로 표현한다면 한눈에 3요소를 파악할 수 있고 오해도 없습니다. > > 그리고 무엇보다도 두개씩 적혀있으니 하나가 적혀있는 것 보다 눈에 잘 들어오는 효과도 볼 수 있지요?
## BEM을 적용하지 않았을 때와 적용했을 때 우리가 흔히 만드는 **유저 프로필 카드**를 예로 들어보겠습니다. ### BEM을 적용하지 않았을 때 우리가 흔히 범하는 실수입니다. 클래스 이름을 대충 짓고, 구조를 CSS의 자손 선택자(Descendant Selector)로 해결하려는 방식입니다. **HTML** ```html

DevNathan

``` **CSS** ```css .card { ... } .card .photo { ... } /* 구조에 종속됨 */ .card .info .name { ... } /* 깊어지는 중첩 (Nesting) */ .btn.red { ... } /* 다른 .red 클래스와 충돌 가능성 높음 */ ``` 위와 같은 방식은 다음과 같은 문제점을 일으킵니다. 1. **구조 종속:** HTML 구조가 바뀌면 CSS도 다 고쳐야 합니다. (`.info` div를 없애면 `.name` 스타일이 깨짐) 2. **명시도(Specificity) 문제:** `.card .info .name`처럼 선택자가 길어지면, 나중에 이걸 덮어쓰기 위해 더 긴 선택자나 `!important`를 써야 합니다. 3. **이름 충돌:** `.photo`, `.name`, `.red` 같은 이름은 너무 흔해서 다른 컴포넌트의 스타일과 겹칠 확률이 100%입니다. ### BEM을 적용했을 때 이제 같은 UI를 BEM 문법으로 바꿔보겠습니다. **HTML** ```html ``` **CSS** ```css .profile-card { ... } .profile-card__img { ... } .profile-card__info { ... } .profile-card__name { ... } .profile-card__button { ... } .profile-card__button--danger { ... } ``` BEM을 사용하면 사용하지 않았을 때의 문제점이 해결됩니다. 1. **구조 독립:** HTML 구조가 바뀌어도(예: `.profile-card__info` 태그가 사라져도) `.profile-card__name`은 영향을 받지 않습니다. 2. **평평한 명시도:** 모든 클래스가 동일한 우선순위를 가집니다. 필요할 경우, 스타일 덮어쓰기가 매우 쉬워집니다. 3. **예측 가능:** `.profile-card__button--danger`라는 이름만 봐도 "프로필 카드에 있는 위험한 버튼이구나"라고 누구나 알 수 있습니다.
## BEM 사용 시 주의할 점 BEM은 협업 간 CSS문제를 해결해주는 좋은 방법론이지만, 적용시 애매한 상황들이 생깁니다. 가장 자주 하는 실수 3가지를 정리합니다. ### 1) 요소의 요소는 만들지 마세요. (Grandchild 금지) BEM을 시작할 때 가장 흔하게 범하는 실수입니다. "HTML 구조가 중첩되어 있으니까, 클래스 이름도 똑같이 중첩해야겠지?"라고 생각하는 것입니다. 하지만 이것은 서론에서 우리가 그토록 피하고 싶었던 **구조 종속성** 문제를 다시 불러오는 지름길입니다. ```css /* ❌ Bad: 구조를 그대로 따라간 이름 */ /* 만약 .info 태그가 사라지면 이 스타일은 깨지게 됩니다. (종속성 발생) */ .profile-card__info__text { } /* ⭕ Good: 블록의 직속 자식으로 취급 */ /* 구조가 어떻게 변하든 이 요소는 독립적으로 스타일을 유지합니다. */ .profile-card__bio { } ``` > [!tip] > > 왜 __info__text는 안 되나요? > > 1. **네이밍의 경직성:** 나중에 디자인이 바뀌어서 `text`가 `info` 박스 밖으로 나가야 한다면? 클래스 이름을 또 바꿔야 합니다. > 2. **우선순위 전쟁:** 클래스 이름이 길어질수록 선택자 우선순위(Specificity) 관리가 힘들어집니다. > [!important] > > '위치'가 아니라 '역할'을 이름으로 지으세요 > > `info` 안에 있는 `text`라고 부르지 마세요. 그 텍스트의 **역할**이 무엇인지 고민해 보세요. 자기소개글인가요? 그럼 **`.profile-card__bio`**가 됩니다. 직업인가요? 그럼 **`.profile-card__job`**이 됩니다. > > 애매모호한 네이밍은 피해야합니다. ### 2) 네이밍은 '모양'이 아닌 '목적'으로 짓습니다. 개발자가 현업에서 가장 흔하게 겪는 "디자인 변경" 상황을 생각해 봅시다. "버튼 색상을 빨강에서 파랑으로 바꿔주세요."라는 요청이 왔을 때, 클래스 이름을 모양(Shape) 기반으로 지었다면 지옥이 시작됩니다. ```css /* ❌ Bad: 모양을 묘사함 */ /* 디자인이 바뀌면 HTML의 클래스 이름까지 다 찾아가서 바꿔야 합니다. */ .btn--red { background-color: red; } ``` 이는 서론에서 언급한 **모호한 네이밍**과 **불필요한 수정 범위 확대**를 야기합니다. CSS만 고치면 될 일을 HTML까지 뒤지게 만들지 마세요. ```css /* ⭕ Good: 목적(의미)을 묘사함 */ /* 색상이 파랑으로 바뀌어도 '위험한 동작'이라는 목적은 변하지 않습니다. */ /* CSS 파일만 수정하면 끝납니다. */ .btn--danger { background-color: red; } ``` ### 3) 태그 선택자와 섞어 쓰지 마세요. BEM을 쓰면서도 습관적으로 태그 선택자를 섞어 쓰는 경우가 있습니다. 이는 우리가 그토록 피하고 싶었던 **종속성 문제**와 **명시도(Specificity) 문제**를 다시 야기하게 됩니다. ```css /* ❌ Bad: 태그에 의존적임 */ /* nav 태그가 div로 바뀌거나, li 구조가 사라지면 스타일이 와장창 깨집니다. */ /* 이를 덮어쓰기 위해 더 높은 점수의 선택자나 !important를 쓰게 됩니다. */ .nav > li > a { ... } ``` BEM의 철학은 **"스타일링을 오직 클래스 이름에만 위임하는 것"**입니다. ```css /* ⭕ Good: 독립적임 */ /* 태그가 무엇으로 변하든 이 클래스만 붙어있으면 스타일은 유지됩니다. */ .nav__item { ... } .nav__link { ... } ``` ---
# 마치며: 생산성을 위한 약속 다시 강조해도 모자란 것은, **팀 프로젝트에서 가장 중요한 가치는 '생산성'과 '유지보수성'입니다.** 혼자 코딩할 때는 자유롭게 해도 되지만, 협업 환경에서 약속(Convention) 없는 자유는 동료에게 혼란을 줄 뿐입니다. - **클래스 중복 고민 없이 코드를 짤 수 있는 자유** - **동료의 코드를 두려움 없이 수정할 수 있는 용기** - **`!important` 없이도 예측 가능한 스타일링** 이것이 CSS에서 BEM 기법을 사용하는 이유입니다. 앞으로 새로운 프로젝트에 CSS 사용을 기획하고 계시다면 BEM기법을 사용해보길 바랍니다. --- ### 참고 자료 - [Get BEM: Introduction (Official Docs)](https://getbem.com/introduction/)