CSS
스타일 작성 도구와 출력 비용
개발자가 스타일을 작성할 때의 편의성과 브라우저에 최종 전달되는 CSS·자바스크립트의 런타임 비용을 나누어 평가합니다.
이럴 때 필요해요
컴포넌트 재사용성, 다크 모드 같은 실시간 테마 전환, 그리고 초기 로딩·서버 렌더링 성능 요구에 맞는 스타일링 도구를 선택하기 위해 필요합니다.
어떻게 동작하나요?
SCSS(Sass)를 쓰면 변수($space), 선택자 중첩, 믹스인(@mixin)으로 스타일 코드를 짧고 깔끔하게 정리할 수 있습니다. 하지만 브라우저는 SCSS를 직접 읽지 못하고 빌드 과정에서 변환된 표준 CSS만 해석합니다. 따라서 SCSS 소스 코드가 아무리 짧아 보여도 중첩을 깊게 하거나 믹스인을 곳곳에 남발하면, 최종 컴파일된 CSS 파일에는 길고 복잡한 선택자와 중복된 규칙이 대량으로 생겨날 수 있습니다.
값을 변수로 관리할 때도 빌드 타임과 런타임을 구분해야 합니다. SCSS 변수($var)는 빌드할 때 고정된 값으로 치환되어 사라지지만, 표준 CSS 사용자 지정 속성(--text-color와 var())은 브라우저 DOM 트리를 따라 상속되며 실행 중에도 값을 바꿀 수 있습니다. 따라서 변하지 않는 고정 간격 계산에는 빌드 변수를 써도 되지만, 다크 모드 전환이나 동적 테마에는 CSS 사용자 지정 속성이 훨씬 적합합니다.
자바스크립트 안에서 스타일을 작성하는 CSS-in-JS 역시 내부 동작 방식에 따라 비용이 크게 다릅니다. 브라우저에서 컴포넌트가 렌더링될 때마다 스타일 문자열을 계산해 <style> 태그에 주입하는 런타임 방식은 동적 props 처리에 유연한 대신 자바스크립트 실행 비용과 SSR 설정 부담이 따릅니다. 반면 빌드 시점에 정적 CSS 파일로 뽑아내는 제로 런타임 방식은 초기 로딩에 유리하므로, 도구의 이름보다 실제 빌드 산출물과 런타임 동작을 확인해 선택해야 합니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
$space: 0.75rem;
.card { padding: $space; color: var(--text-color, #222); }padding에 쓰인 $space는 Sass 컴파일 시점에 0.75rem으로 고정되고, color에 쓰인 --text-color는 브라우저 런타임에 테마에 따라 동적으로 바뀔 수 있습니다.
자주 헷갈리는 포인트
- SCSS에서 HTML 구조를 그대로 본떠 중첩을 깊게 작성하면 작은 마크업 수정에도 쉽게 깨지는 무거운 선택자가 만들어집니다.
- 도구 이름(예: CSS-in-JS, 전처리기)만 보고 실제 출력되는 CSS 크기와 런타임 비용을 단정하면 안 됩니다.
내 말로 설명해 보기
사용자가 화면에서 즉시 바꾸는 다크 모드 색상과 고정된 레이아웃 브레이크포인트 값은 각각 어느 단계의 변수로 다루는 것이 좋을까요?
함께 읽으면 좋은 개념
관련 면접 질문 2개
SCSS는 어떤 기능을 제공하며 브라우저에는 최종적으로 무엇이 전달되나요?
SCSS는 표준 CSS 문법과 호환되는 Sass 전처리기의 구문으로, 변수($), 선택자 중첩, 믹스인(@mixin), 함수와 모듈 분리 같은 작성 편의 기능을 제공합니다. 브라우저는 SCSS 파일을 직접 해석하지 못하므로, 빌드 과정에서 반드시 표준 CSS 파일로 컴파일한 결과물을 브라우저에 전달해야 합니다. 반복 코드를 줄이는 데 유용하지만 중첩을 너무 깊게 쓰면 컴파일된 CSS의 선택자가 길어지고 파일 크기가 불필요하게 커질 수 있습니다.
꼬리질문과 참고자료 →CSS-in-JS의 장단점은 런타임 방식과 빌드 추출 방식에 따라 어떻게 달라지나요?
CSS-in-JS는 컴포넌트 파일 안에서 스타일을 함께 관리하고 props 기반 동적 스타일을 표현하기 편하다는 장점이 있습니다. 다만 브라우저 실행 중에 스타일을 계산해 삽입하는 런타임 방식은 직렬화 비용과 번들 크기, 서버 렌더링 순서 처리 부담이 따릅니다. 반면 빌드 시점에 정적 CSS 파일로 추출하는 방식은 런타임 비용을 크게 줄이는 대신 동적 표현에 제약이 있으므로 라이브러리의 출력 방식과 캐싱 구조를 보고 선택해야 합니다.
꼬리질문과 참고자료 →