몇 년 전만 해도 스타일을 자바스크립트 안에 직접 쓰는 방식이 프런트엔드의 세련된 정답처럼 여겨졌다. 그런데 지금 CSS 진영의 분위기는 사뭇 다르다. 스타일 계산을 브라우저 실행 시점에서 빌드 시점으로 앞당기는 흐름, 이른바 제로 런타임 CSS(Zero-runtime CSS)가 대세로 떠올랐다.
제로 런타임 CSS는 컴포넌트 안에서 편하게 스타일을 작성하되, 실제 CSS 파일은 빌드 과정에서 미리 뽑아내 브라우저에서는 스타일을 계산하는 자바스크립트가 전혀 실행되지 않게 하는 접근이다. 개발할 때의 편의는 지키고, 실행할 때의 비용은 없앤다.
스타일을 짜는 편의는 남기고, 브라우저가 치르던 비용은 지운다.
제로 런타임은 스타일 계산을 빌드 단계로 옮긴다.
실행 시점에 스타일을 만들어 내던 방식에서, 정적 CSS를 미리 추출해 순수 CSS의 성능을 되찾는 방향으로 무게추가 이동했다.
런타임0 스타일 계산 JS 실행 없음 |
추출 빌드 때 정적 CSS 생성 |
토큰 디자인 변수 일관 관리 |
타입안전 스타일도 타입 검사 |
런타임 방식이 남긴 숙제
스타일을 자바스크립트로 다루는 방식이 인기를 끈 데는 이유가 있었다. 컴포넌트와 그 스타일을 한 파일에 두니 응집도가 높았고, 조건이나 속성에 따라 스타일을 동적으로 바꾸기가 자연스러웠으며, 이름 충돌 걱정이 사라졌다. 개발 경험은 분명 좋았다.
문제는 대가였다. 이런 방식의 상당수는 브라우저에서 컴포넌트가 그려질 때마다 스타일 문자열을 조립하고, 그걸 스타일 태그로 문서에 밀어 넣는 일을 실시간으로 한다. 이 작업을 담당하는 라이브러리가 번들에 실려 오고, 화면이 그려지는 매 순간 스타일 계산이 함께 돈다. 앱이 커지고 컴포넌트가 많아질수록 이 보이지 않는 비용이 쌓였다. 서버 렌더링과 함께 쓸 때 생기는 복잡함도 만만치 않았다. 나는 이 지점에서 "편의를 위해 우리가 뭘 내주고 있었나"를 다시 묻게 됐다.
빌드 시점으로 옮기면
제로 런타임 방식의 발상은 단순하다. 스타일이 실행 중에 만들어질 필요가 정말 있나? 대부분은 아니다. 어떤 컴포넌트가 어떤 스타일을 갖는지는 코드를 보면 빌드 시점에 이미 결정돼 있다. 그렇다면 그때 미리 계산해 진짜 CSS 파일로 뽑아내면 된다.
정적 추출
빌드 도구가 코드를 분석해 스타일 정의를 찾아내고, 이를 평범한 CSS 클래스로 변환해 별도 파일로 추출한다. 브라우저에 도착하는 건 익숙한 링크된 CSS와, 각 요소에 붙은 클래스 이름뿐이다. 스타일을 만들어 내던 자바스크립트는 흔적도 없다. 브라우저는 그저 순수 CSS를 적용할 뿐이니, 우리가 오래전부터 알던 CSS의 빠르기를 그대로 되찾는다.
// 작성은 컴포넌트 곁에서 편하게
const box = style({ padding: 16, color: vars.text });
// 빌드 결과: .box_x7 { padding:16px; color:var(--text) }
// → 브라우저엔 클래스만, 계산 JS는 0디자인 토큰과 타입
덤으로 얻는 것도 있다. 색·간격 같은 값을 디자인 토큰으로 정의해 일관되게 참조하고, 스타일 정의에 타입을 붙여 오타나 잘못된 속성값을 컴파일 단계에서 잡는다. 스타일이 그저 문자열이 아니라 검사받는 코드가 되는 것이다.
비교로 정리
| 항목 | 제로 런타임 | 런타임 방식 |
|---|---|---|
| 스타일 계산 | 빌드 시점 | 브라우저 실행 중 |
| 번들 비용 | 거의 없음 | 런타임 라이브러리 포함 |
| 동적 스타일 | 변수 기반으로 제한적 | 자유롭게 계산 |
| 서버 렌더링 | 단순 | 추가 처리 필요 |
절충과 방향
물론 공짜는 아니다. 모든 스타일을 빌드 시점에 확정하려면, 실행 중에 임의의 값으로 스타일을 마구 바꾸는 자유는 어느 정도 포기해야 한다. 정말로 동적인 부분은 CSS 변수로 넘겨 표현하는 식으로 우회하는데, 이 제약이 어떤 화면에선 답답하게 느껴질 수 있다. 또 빌드 파이프라인에 분석·추출 단계가 들어가니 도구 설정의 복잡함이 늘어난다.
그럼에도 큰 방향은 분명해 보인다. CSS 자체가 변수, 중첩, 컨테이너 쿼리 같은 기능을 흡수하며 강력해지면서, "굳이 실행 중에 자바스크립트로 스타일을 만들 이유"가 줄었다. 편의는 빌드 도구가 챙기고 실행은 순수 CSS에 맡기는 이 분업이, 지금으로선 성능과 개발 경험을 모두 붙잡는 가장 균형 잡힌 답에 가깝다고 나는 생각한다.
자주 묻는 질문
제로 런타임 CSS면 자바스크립트가 전혀 없나요?
스타일을 만들어 내는 런타임 자바스크립트가 없다는 뜻이다. 애플리케이션 로직의 자바스크립트는 그대로 있고, 다만 스타일은 빌드 때 추출된 정적 CSS로 적용되어 실행 중 스타일 계산 비용이 사라진다.
동적으로 바뀌는 스타일은 어떻게 처리하나요?
테마 색이나 사용자 설정처럼 실행 중 바뀌는 값은 대개 CSS 변수로 넘겨 표현한다. 스타일의 뼈대는 빌드 때 확정하고, 변하는 값만 변수로 주입하는 방식이라 상당수 동적 요구를 감당할 수 있다.
기존 런타임 방식 프로젝트를 꼭 바꿔야 하나요?
반드시는 아니다. 잘 돌아가고 성능 문제가 없다면 유지해도 된다. 다만 번들 크기나 렌더링 비용이 부담되는 대규모 앱이라면 전환의 이득이 크므로 점진적 이전을 검토할 만하다.
순수 CSS나 유틸리티 방식과 비교하면 어떤가요?
목표가 겹치는 부분이 많다. 셋 다 실행 중 스타일 계산을 피하려 한다. 제로 런타임 방식은 컴포넌트 곁에서 타입 지원을 받으며 스타일을 작성하는 개발 경험을 유지한다는 점이 특징이다.
댓글 0