우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›라인›프론트엔드›질문 상세
    問
    라라인프론트엔드직무 역량2026년 출제

    BEM 명명 규칙을 사용하여 CSS를 작성한 경험이 있나요? 예시를 들어 설명해 주세요.

    답변 미리보기

    팀 프로젝트에서 여러 사람이 CSS를 나눠 쓰다 보니 클래스명이 충돌하는 문제가 생겼고, BEM 명명 규칙을 처음 도입했습니다. Block은 독립적인 UI…

    예상 답변 시간
    60초
    예상 꼬리질문
    3회
    난이도
    난이도 중
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    원칙 결을 분별하는가?
    한 결로 답하는지, Block·Element·Modifier 결로 가른 명명 흔적이 답에 있는지 보는 자리입니다. 한 결로 묶는 답은 깊이가 약해지는 자리입니다.
    骨
    02
    본인 사례가 있는가?
    이론 결만 답하는지, 본인이 실제 굴린 BEM 결의 흔적이 답에 묻어 있는지 살피는 자리입니다. 책에서 본 결은 실무 감각이 약해지는 자리입니다.
    語
    03
    장단을 의식하는가?
    장점만 답하는지, 길이·중복·학습 비용 결로 가른 단점이 답에 있는지 살피는 자리입니다. 만능 결은 신뢰감이 약해지는 자리입니다.
    本
    04
    팀을 의식하는가?
    본인 결만 답하는지, 가이드·리뷰·자동 검사 결로 가른 확산이 답에 있는지 보는 자리입니다. 확산 없는 결은 자리가 흐려지는 자리입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    라인 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    클래스 충돌 문제 해결 + Block/Element/Modifier 실제 예시 + CSS Modules 비교약 65초stylelint-bem CI 통합으로 BEM 규칙 자동 강제, 팀 네이밍 분쟁 반복 제거, 애매한 패턴 가이드 문서화 — CSS 컨벤션은 도구로 강제해야 지속성 높다약 65초CSS Modules가 BEM 충돌 문제를 자동 해결 — React 컴포넌트에는 Modules가 자연스러움, 빌드 없는 환경은 BEM 현실적, 클래스명 길이 단점은 구조 가독성 이점으로 상쇄약 65초
    BEM 명명 규칙 CSS 작성 경험
    약 65초

    클래스 충돌 문제 해결 + Block/Element/Modifier 실제 예시 + CSS Modules 비교

    팀 프로젝트에서 여러 사람이 CSS를 나눠 쓰다 보니 클래스명이 충돌하는 문제가 생겼고, BEM 명명 규칙을 처음 도입했습니다. Block은 독립적인 UI 컴포넌트, Element는 블록을 구성하는 부분, Modifier는 상태나 변형을 나타내는 방식이라, `.card__title--highlighted` 처럼 이름만 봐도 구조를 알 수 있게 됐습니다. 처음엔 이름이 길어진다는 부담이 있었는데, 클래스명이 길어도 의미가 명확하면 CSS를 읽는 시간이 줄어든다는 걸 실제로 경험했습니다. BEM을 쓰면 특정 컴포넌트에 관련된 스타일이 한 곳에 모이는 효과가 생겨서 수정 범위를 예측하기 쉬워졌습니다. 단점은 컴포넌트 구조가 바뀌면 클래스명도 전부 바꿔야 하는 경우가 있어서, CSS Modules처럼 스코프가 보장되는 방법과 비교해보기도 했습니다.

    BEM은 팀에서 CSS 충돌을 줄이는 가장 진입 장벽이 낮은 컨벤션이라고 봅니다.

    이 결의 특징
    마주한 기술적 문제와 그것을 풀어낸 구체적 과정이 단계별로 드러나는 흔적입니다.
    이 결이 통하는 자리
    이론이 아닌 실제 손에 잡은 기술 경험이 담길 때 면접관이 후속 질문을 던지는 자리입니다.
    예시 답변 2
    약 65초

    stylelint-bem CI 통합으로 BEM 규칙 자동 강제, 팀 네이밍 분쟁 반복 제거, 애매한 패턴 가이드 문서화 — CSS 컨벤션은 도구로 강제해야 지속성 높다

    BEM을 개인 프로젝트에서 써보고 팀에 도입할 때 구두 가이드만으로는 일관성이 유지되지 않는다는 것을 경험했습니다. 팀원마다 Block과 Element 경계를 다르게 해석해서, 같은 컴포넌트를 서로 다른 방식으로 작명하는 경우가 생겼습니다. 이후 stylelint-bem 플러그인을 CI에 추가해서 BEM 규칙에 맞지 않는 클래스명이 있으면 PR에서 자동으로 오류가 나도록 했습니다. 자동 검사가 붙으니 팀원들이 규칙을 확인하고 수정하는 부담이 줄었고, 리뷰에서 네이밍을 지적하는 횟수도 줄었습니다. 가이드 문서도 만들었는데, 자주 헷갈리는 패턴을 예시와 함께 정리했습니다. Block 안에 Block이 들어가는 경우나 여러 Modifier를 동시에 쓰는 경우처럼 규칙이 애매한 부분을 팀에서 명시적으로 결정해두니 코드 리뷰에서 같은 논쟁이 반복되지 않았습니다.

    CSS 컨벤션은 합의보다 도구로 강제하는 것이 지속성이 높다는 것을 이 경험에서 배웠습니다.

    이 결의 특징
    초기 시행착오에서 출발해 해결책을 찾아가는 문제 해결의 과정이 드러나는 흔적입니다.
    이 결이 통하는 자리
    문제 인식과 해결책이 일대일로 대응될 때 논리적 사고가 검증되는 자리입니다.
    예시 답변 3
    약 65초

    CSS Modules가 BEM 충돌 문제를 자동 해결 — React 컴포넌트에는 Modules가 자연스러움, 빌드 없는 환경은 BEM 현실적, 클래스명 길이 단점은 구조 가독성 이점으로 상쇄

    BEM을 쓰다가 CSS Modules가 BEM이 해결하는 문제를 자동으로 처리한다는 것을 알게 된 경험이 있습니다. BEM의 긴 클래스명이 클래스 충돌을 막기 위한 수단인데, CSS Modules는 빌드 타임에 클래스명을 자동으로 고유하게 만들어줘서 BEM 없이도 충돌을 방지할 수 있었습니다. React 컴포넌트 단위로 스타일을 격리하는 프로젝트에서는 CSS Modules가 더 자연스럽게 맞았습니다. 그렇다고 BEM이 필요 없는 것은 아니었는데, 서버 렌더링 위주이거나 JavaScript 빌드 단계가 없는 환경에서는 BEM이 여전히 가장 현실적인 선택이었습니다. 클래스명 길이 문제는 BEM의 실제 단점이지만, 클래스명이 길어도 HTML을 보면 컴포넌트 구조가 바로 드러난다는 점은 큰 코드베이스에서 가독성 이점이 됐습니다.

    CSS 방법론 선택은 프로젝트 환경과 팀의 JavaScript 의존도에 따라 달라진다는 것을 이 경험에서 배웠습니다.

    이 결의 특징
    BEM 없이도 충돌을 방지이라는 시스템적 접근으로 근본 해결에 이른 성숙한 사고의 과정입니다.
    이 결이 통하는 자리
    'BEM 없이도 충돌을 방지'같은 원칙을 경험에서 도출해낸 면접자의 사고 높이가 드러날 때 심화 질문으로 이어지는 자리입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹왜 그 원칙 결을 고르셨나요?
    貳막힌 적용 경로 결도 있었나요?
    參본인만의 명명 결이 있나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 라인 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    호텔신라 · 디자인 일반
    HTML과 CSS를 사용해 본 경험에 대해 구체적으로 설명해 주세요.
    이 질문 보기
    라인 · 프론트엔드
    HTML5와 CSS3를 사용해 본 경험에 대해 구체적으로 설명해줄 수 있나요?
    이 질문 보기
    유진그룹 · 프론트엔드
    HTML과 CSS를 사용하여 만든 프로젝트에 대해 설명해 주세요.
    이 질문 보기
    PTKOREA · 서비스 오너
    HTML/CSS에 대한 기본 이해가 필요하다고 했는데, 어떤 부분을 특히 강조하고 싶으신가요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 라인 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기