이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 CSS를 한 파일에 쌓았다가, 팀원이 같은 클래스명을 다른 컴포넌트에 사용하면서 스타일이 충돌하는 문제가 발생했습니다. 그때부터 SCSS와 BEM 네이밍 규칙을 도입했습니다. .card__title, .card__body--highlight처럼 블록·요소·수정자를 명확히 나누니 어느 클래스가 어디에 사용되는지 바로 알 수 있었습니다. SCSS에서는 중첩 선택자로 BEM을 깔끔하게 표현할 수 있어 좋았으나, 처음에는 중첩을 4단계까지 사용하여 컴파일된 CSS가 너무 길어지는 문제가 있었습니다. 이후 2단계로 제한하는 팀 규칙을 만들었습니다. 컴포넌트별로 파일을 나누니 새 기능을 추가할 때 기존 스타일이 망가지는 일이 없어졌습니다.
사이드 프로젝트에서 디자인 시스템 없이 작업하다 보니 버튼 색상이 페이지마다 조금씩 달라지는 문제가 있었어요. 색상값을 하드코딩했기 때문이었어요. SCSS 변수($primary-color, $text-muted)로 디자인 토큰을 정의하고, `_variables.scss` 파일 하나에서 전체 관리하도록 바꿨습니다. 반응형 브레이크포인트도 믹스인으로 추출했어요.
@include respond-to('mobile') 형태로 쓰니까 미디어 쿼리 값을 직접 기억하지 않아도됐고, 나중에 값을 바꿀 때 한 곳만 수정하면 됐습니다. 팀원에게 넘겨줄 때 "변수 파일 먼저 보면 전체 색상 체계가 보인다"는 피드백을 받았어요.
일관성은 코드에서 강제하는 것이라는 걸 배웠습니다.
Vue 프로젝트에서 scoped style을 쓰다가 SCSS로 전환한 경험이 있어요. scoped가 충돌은 막아줬지만, 공통 스타일을 컴포넌트 간에 공유하기가 번거로웠습니다. SCSS의 @use와 partial 파일 구조로 전환하면서 공통 변수와 믹스인을 src/styles/ 폴더에 모았어요. 처음엔 @import와 @use의 차이를 몰라서 변수가 전역으로 퍼지는 문제가 있었습니다.
@use는 네임스페이스로 접근해야 해서 기존 @import 방식보다 명시적이더라고요. 전환 후 스타일 파일이 어디 있는지 찾기 쉬워졌고, 새 컴포넌트 추가 시 기존 스타일을 import만 하면되는 구조가 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 incross 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.