이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
BEM 네이밍 컨벤션은 팀 프로젝트에서 CSS 클래스 이름 충돌 문제를 겪은 이후 도입했습니다. 여러 사람이 동시에 스타일을 추가하다 보니 동일한 클래스 이름이 두 곳에 생기는 상황이 반복됐고, 블록·요소·수정자 구조로 이름 짓기 규칙을 통일했습니다.
예를 들어 카드 컴포넌트라면 .card, .card__title, .card__button--active 형태로 작성합니다. 블록은 독립 컴포넌트, 요소는 내부 구성, 수정자는 상태나 변형을 의미하기 때문에, 클래스 이름만 보고도 구조상 어디에 위치한 요소인지 파악할 수 있었습니다.
도입 후 이점은 클래스 이름만으로 컴포넌트 구조를 예측할 수 있게 된 것입니다. 특히 여러 개발자가 같은 코드베이스를 수정할 때 스타일 의도를 별도 설명 없이 이해할 수 있었고, CSS 특이성 충돌도 크게 줄었습니다.
BEM을 팀에 도입하고 나서 처음에는 클래스 충돌이 없어지는 효과가 좋았는데, 컴포넌트 안에 컴포넌트가 중첩될수록 클래스 이름이 길어지는 문제가 생겼습니다. .form__group__input--error 같은 이름이 자연스럽게 나타나면서, 어느 시점부터 클래스 이름을 짓는 데 더 많은 시간을 쓰는 결이 됐습니다. BEM의 원칙대로라면 중첩을 표현하려 하지 말고 요소는 블록 바로 아래로 평탄화해야 하는데, 그 규칙을 팀 전체가 지키는 것이 생각보다 어려웠습니다. 이 경험에서 BEM은 컴포넌트 구조가 단순할 때 잘 맞고, 중첩이 깊어지면 CSS Modules이나 CSS-in-JS가 더 적합할 수 있다는 것을 배웠습니다.
방법론을 선택할 때 현재 프로젝트의 복잡도와 팀 규모를 함께 고려해야 하는 결이 있었습니다.
BEM을 쓰다가 CSS Modules로 전환하는 프로젝트에 참여했습니다. BEM은 클래스 이름 규칙으로 충돌을 막는 방식이지만, CSS Modules는 빌드 도구가 자동으로 유니크한 클래스 이름을 생성하는 방식이었습니다. 전환 후 클래스 이름을 고민하는 시간이 줄었고, 컴포넌트 파일과 스타일 파일이 같은 폴더에 묶이니 유지보수가 편해졌습니다. 반면 BEM은 CSS 파일 하나로 전체 스타일을 관리할 수 있고, 빌드 도구 없이도 동작한다는 장점이 있었습니다. 두 방식을 모두 써보니 어느 방식이 더 좋다기보다 프로젝트 환경과 팀 선호에 따라 선택하는 결이라는 것을 이해했습니다. 한 방식에 익숙해지면 다른 방식의 장점이 보이는 것도 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.