CSS는 언제 동작하나

브라우저 기준으로 CSS는 대략 이렇게 동작한다.

HTML 다운로드
→ CSS 다운로드
→ CSSOM 생성
→ DOM + CSSOM 결합
→ Render Tree 생성
→ Layout
→ Paint
→ Composite

즉 CSS는 최종적으로 브라우저 렌더링 과정에서 항상 사용된다.

그런데 CSS 방식마다 차이가 나는 지점은 여기다.

CSS 파일이 언제 만들어지는가?
CSS 클래스명이 언제 결정되는가?
CSS가 HTML에 언제 붙는가?
브라우저가 JavaScript를 실행해야 스타일이 완성되는가?

핵심 구분

크게 두 종류로 나눌 수 있다.

1. 빌드 타임 CSS
   → 빌드할 때 CSS 파일이 만들어짐
   → 브라우저는 CSS 파일을 다운로드해서 적용

2. 런타임 CSS
   → 사용자의 브라우저에서 JavaScript가 실행되면서 CSS 생성/삽입
   → JS 실행이 스타일 완성에 관여

여기서 말하는 “런타임”은 사용자가 페이지를 실제로 열었을 때 브라우저에서 JavaScript가 실행되는 시점이다.

1. 일반 CSS 파일 import

import './globals.css';

body {
  margin: 0;
}

.button {
  padding: 12px;
}

이 방식은 빌드 타임 CSS에 가깝다.

빌드할 때 Next.js가 CSS 파일을 번들링하고, 최종적으로 브라우저에 CSS 파일로 전달한다.

개발자가 CSS 작성
→ next build
→ CSS 파일 생성
→ 브라우저가 CSS 파일 다운로드
→ 렌더링에 적용

브라우저에서 JavaScript가 CSS를 새로 만들어내는 구조가 아니다.

그래서 런타임 비용이 낮다.

단점은 CSS가 전역으로 적용된다는 점이다.

.button {
  ...
}

이 클래스는 프로젝트 어디서든 영향을 줄 수 있다.

즉 성능 관점에서는 단순하지만, 유지보수 관점에서는 충돌 위험이 크다.

2. CSS Modules

import styles from './Button.module.css';

export function Button() {
  return <button className={styles.button}>저장</button>;
}

.button {
  padding: 12px;
  background: black;
}

CSS Modules도 빌드 타임 CSS에 가깝다.

차이는 빌드할 때 클래스명이 변환된다는 점이다.

개발자가 작성한 클래스

.button

빌드 후 실제 클래스

Button_button__a1b2c

대략 이런 식으로 고유한 이름이 된다.

흐름은 이렇다.

Button.module.css 작성
→ next build
→ 클래스명 해싱
→ CSS 파일 생성
→ JS에서는 styles.button이 해싱된 클래스명을 가리킴
→ 브라우저는 완성된 CSS 파일 적용

중요한 점은 브라우저에서 CSS 클래스명을 계산하는 게 아니라는 것이다.

클래스명 변환은 빌드 시점에 끝난다.

그래서 런타임 비용이 낮고, Server Component와도 잘 맞는다.

app router로 바뀌고나서는 개인적으로는 tailwind css 다음으로 이방식이 좋은것같다.

3. Tailwind CSS

<div className="flex items-center rounded-xl p-4 text-sm">
  내용
</div>

Tailwind도 기본적으로 빌드 타임 CSS 방식이다.

개발자는 className에 utility class를 적는다.

p-4
text-sm
rounded-xl
flex

그러면 빌드 과정에서 Tailwind가 실제로 사용된 class를 분석하고 필요한 CSS를 만든다.

소스 코드 분석
→ 사용된 Tailwind class 추출
→ 필요한 CSS 생성
→ CSS 파일로 번들링
→ 브라우저가 CSS 다운로드

즉 브라우저에서 Tailwind가 p-4를 보고 즉석에서 CSS를 만드는 게 아니다.

이미 빌드된 CSS 안에 이런 규칙이 들어 있다.

.p-4 {
  padding: 1rem;
}

그래서 Tailwind도 런타임 CSS-in-JS와 다르다.

브라우저 입장에서는 그냥 CSS 클래스다.

Next.js 공식 문서도 Tailwind를 CSS 사용 방식 중 하나로 안내하고, global CSS에 Tailwind를 import한 뒤 utility class를 사용하는 흐름을 설명한다.

Tailwind의 장점은 런타임 비용이 낮으면서도 디자인 토큰을 강제하기 쉽다는 점이다.

단점은 className이 길어지고, 반복 패턴을 컴포넌트로 추상화하지 않으면 유지보수가 어려워진다는 점이다.

4. Sass / SCSS

예를 들면

.card {
  padding: 16px;

  .title {
    font-size: 20px;
  }
}

Sass는 브라우저가 직접 이해하지 못한다.

빌드 과정에서 일반 CSS로 변환된다.

SCSS 작성
→ next build
→ 일반 CSS로 컴파일
→ CSS 파일 생성
→ 브라우저가 CSS 적용

예를 들어 위 SCSS는 빌드 후 이런 CSS가 된다.

.card {
  padding: 16px;
}

.card .title {
  font-size: 20px;
}

즉 Sass도 빌드 타임 CSS다.

브라우저에서 Sass 문법을 해석하지 않는다.

런타임 비용은 일반 CSS와 비슷하다.

단점은 중첩을 과하게 쓰면 선택자가 복잡해지고, 전역 Sass를 쓰면 일반 CSS처럼 충돌 위험이 생긴다는 점이다.

그래서 실무에서는 보통

Card.module.scss

처럼 CSS Modules와 같이 쓰는 편이 안전하다.

5. styled-components

여기서 “런타임에 동작한다”는 말이 가장 중요해진다.

예를 들면

'use client';

import styled from 'styled-components';

const Button = styled.button`
  padding: 12px;
  background: black;
  color: white;
`;

export function SubmitButton() {
  return <Button>저장</Button>;
}

이 코드는 CSS 파일을 직접 import하지 않는다.

JavaScript 안에 CSS가 들어 있다.

브라우저에서 이 컴포넌트 코드가 실행되면 styled-components가 className을 만들고, CSS를 <style> 태그로 삽입한다.

대략 이런 흐름이다.

브라우저가 JS 다운로드
→ JS 실행
→ styled-components 코드 실행
→ 고유 className 생성
→ CSS 문자열 생성
→ <style> 태그를 DOM에 삽입
→ 컴포넌트에 className 연결
→ 브라우저가 스타일 적용

즉 CSS 생성 과정에 JavaScript 실행이 필요하다.

이게 “런타임 CSS”라는 말의 의미다.

브라우저 결과물은 결국 CSS다.

하지만 그 CSS가 처음부터 CSS 파일로 존재하는 게 아니라, JavaScript가 실행되면서 만들어진다.

CSS-in-JS는 JavaScript로 스타일을 작성하고, JS가 파싱될 때 CSS가 생성되어 보통 <style> 요소로 DOM에 붙는 방식이다.

styled-components는 SSR이면 어떻게 되나

Next.js에서 styled-components를 쓰면 서버에서 미리 스타일을 수집해서 HTML에 넣을 수도 있다.

즉 처음 HTML에 이런 식으로 들어갈 수 있다.

<style data-styled>
  .abc123 {
    padding: 12px;
    background: black;
  }
</style>

하지만 여기서 끝이 아니다.

클라이언트에서도 React가 hydration을 하면서 styled-components 런타임이 다시 연결되어야 한다.

서버에서 style 태그 생성
→ HTML에 포함
→ 브라우저가 초기 스타일 적용
→ 클라이언트 JS 다운로드
→ styled-components 런타임 실행
→ 기존 style과 연결
→ 이후 동적 스타일 처리

이 과정이 필요하다.

그래서 styled-components는 SSR을 지원해도 런타임 비용이 완전히 사라지는 것은 아니다.

Next.js 공식 문서도 App Router에서 CSS-in-JS를 사용할 때 styled-components registry를 두고 서버 렌더링 중 스타일을 수집해 head에 flush하는 패턴을 안내한다. 또한 Server Components 스타일링에는 CSS Modules나 Tailwind처럼 CSS 파일을 출력하는 방식을 권장한다.

그러면 CSS는 결국 언제 적용되나

모든 방식에서 최종 적용은 브라우저 렌더링 시점이다.

하지만 차이는 “적용 전 준비 과정”이다.

빌드 타임 CSS:
이미 만들어진 CSS 파일을 브라우저가 다운로드해서 적용

런타임 CSS:
브라우저가 JS를 실행해서 CSS를 만들거나 연결한 뒤 적용

그래서 App Router에서 이 차이가 중요해진다.

App Router의 방향은

서버에서 최대한 렌더링
클라이언트 JS 최소화
hydration 최소화

이다.

그런데 런타임 CSS-in-JS는 스타일을 위해 클라이언트 JS 런타임이 필요해지는 경우가 많다.

그래서 Server Component 중심 프로젝트에서는 CSS Modules, Tailwind, Sass처럼 빌드 타임에 CSS 파일을 출력하는 방식이 더 잘 맞는 경우가 많다.

내 생각

정적이고 반복적인 UI
→ Tailwind / CSS Modules

컴포넌트 단위로 안전하게 격리하고 싶음
→ CSS Modules

디자인 토큰 기반으로 빠르게 만들고 싶음
→ Tailwind

전역 reset, font, CSS variable
→ Global CSS

CSS의 종류와 동작