"제로 런타임"이라는 단어를 외워 왔는지, 아니면 런타임 CSS-in-JS와의 트레이드오프·동적 스타일 한계·디자인 시스템 결합도까지 풀 수 있는지를 가른다.
런타임 CSS-in-JS(styled-components·Emotion 기본 모드)는 컴포넌트가 렌더링될 때마다 JS로 스타일을 만들어 <head>에 주입한다. 제로 런타임 CSS(vanilla-extract·Linaria·Panda·CSS Modules 등)는 같은 작성 경험을 주면서도 빌드 단계에서 스타일을 추출해 정적 CSS 파일로 만든다. 덕분에 초기 JS 실행 비용·번들 크기·캐시 효율이 좋아지고 SSR 하이드레이션 부담도 줄어든다. 단 "런타임 값으로 스타일을 매번 다르게 계산하는" 자유도는 사라져, 동적 테마·사용자 입력 기반 스타일은 CSS 변수 같은 별도 전략으로 풀어야 한다.
런타임 CSS-in-JS에서 제로 런타임으로 옮기며 번들 크기나 LCP가 개선된 경험이 있다면 "비용을 어느 시점으로 옮길지"의 결정으로 풀어낼 수 있다
다크 모드 같은 동적 스타일을 CSS 변수 + 빌드 추출 조합으로 풀어 본 경험이 있다면 한계 우회 전략의 사례로 보여 줄 수 있다
디자인 토큰을 코드 생성으로 동기화한 경험이 있다면 "제로 런타임 + 디자인 시스템" 결합 이야기로 이어갈 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.