시작하기 앞서…
최근 프론트엔드 개발자 취업 공고를 많이 보고 있다. 여러 기업들에서는 어떤 기술들을 많이 사용하는지, 어떤 것들을 주목하면 좋을지 알아보고 싶었다.
그래서 우리나라 서비스 기업의 최고봉이라고 하는 “네카라쿠베당토” 에서는 어떤 기술을 사용하는지 궁금했다. 그 중 눈에 들어왔다.
Toss는 워낙 UX/UX가 이쁘기로 소문이나있기 때문에 Toss 채용 공고에서 알려준 CSS 기술이 궁금했다.
나는 요즘 가장 인기있는 Tailwind CSS를 많이 사용하고 있지만, Web 개발을 처음 관심을 가지고 공부했던 2021년 당시에 CSS Module, Styled-Components를 많이 사용하는 것으로 보았고, 나도 자주 다뤘던 기억이 있다.
그런데 생각해보면 요즘은 이런 CSS-in-JS 이야기를 많이 못들어 본 것 같다. 그래서 오늘은 왜 그런지 생각해볼겸 CSS-in-JS의 등장배경부터 현재까지 티타임겸 ****가볍게 알아보려고 한다.
💡 CSS in JS 정의
“Javascript 코드안에서 CSS 를 작성하여 관리하는 전략”
CSS in JS의 등장 배경
1️⃣ 컴포넌트 기반 UI의 등장
React와 같이 프론트엔드 개발에서 “컴포넌트 중심” 개발 방식이 자리를 잡으면서, 스타일링도 컴포넌트 단위로 관리하고자 하는 요구가 커졌다.
2️⃣ 기존 CSS의 한계
기존의 CSS는 모듈화 되지 못하고, 전역으로 적용되어 사용되고 있었다. 이로 인해 생기는 여러가지 문제가 있었다.
- 스타일 충돌
- 복잡한 네이밍 규칙 필요
- 유지보수 어려움
3️⃣ 동적 스타일링의 필요성
Ajax의 등장 이후 단순한 UI 개발이 아니라, 데이터를 다루는 것으로 프론트엔드 개발의 범위가 확장 되었다. 동시에 클라이언트 사이드 렌더링(CRA)에서 다뤄지는 상태(State) 를 관리하면서 이런 데이터들 활용하여 동적인 스타일링에 대한 필요를 느끼게 되었다.
하지만, 이런 동적인 스타일링은 CSS 만으로는 구현하기가 번거로운 측면이 많이 있었다.
크게 위와 같은 3가지의 배경을 가지고 컴포넌트 단위로 스타일을 관리하고자 나온 것이 CSS-in-JS 이다.
현재 대표적으로 사용되고 있는 도구는 CSS Module, Styled components, Emotion 등이 있다. 위 라이브러리들은 과거부터 지금까지 CSS-in-JS 도구 중 꾸준한 인기를 얻고 있다.
이래서 CSS-in-JS 를 썼다.
1️⃣ 스타일과 컴포넌트 로직의 결함 (Co-location)
관점을 “관심사의 분리”보다는 “통합”의 관점을 두었다고 생각하면 좋다.
스타일과 컴포넌트 로직을 함께 관리함으로써 유지보수성을 높이고, 컴포넌트의 재사용성을 높이 활용할 수 있었다.
2️⃣ 동적/조건부 스타일링
앞서 등장 배경에서 다뤘던 것 처럼 다루는 데이터들을 통해, 그리고 JS의 로직을 통해 동적인 스타일링이 가능하다.
CSS만으로는 할 수 없는 복잡한 스타일링 들을 쉽게 구현 할 수 있다. CSS 만으로 구현하는 것이 완전히 불가능한 것은 아니다. 하지만, 개발 하는 과정이 조금은 복잡하기 때문에 이러한 부분에서 간편하게 큰 강점을 가질 수 있다.
3️⃣ CSS Scope 자동 관리
해시 기반으로 고유 클래스 생성를 “자동으로” 생성해줌으로서 문제가 되었던 전역 스코프의 CSS 의 특징으로 인한 작명의 어려움을 해결해주었다.
특히 이러한 점은 다른 사람들과 협업하는 과정에서 더욱 효과를 발휘할 수 있었다.
하지만, 그럼에도 명확한 단점이 존재했다.
CSS in JS 가 처음 등장하면서 많은 사람들이 정말 많이 사용하였다. 특히 CSS Module은 React 프로젝트를 생성하는데 많이 사용했던 Create React App (CRA) 에 기본으로 탑재가 되었고, Styled Components를 사용하는 개발자가 많아짐에 따라 많이 도입하는 것을 보게 되었다.
나도 처음 React 강의를 들을 당시에 강사분들도 저 두가지 도구를 많이 사용하여 알려주시는 것을 보았기에 아주 익숙하게 사용해왔던 것 같다.
그렇지만, 점차 많은 개발자분들이 CSS-in-JS 방식에 대해 많은 우려를 표명하게 되면서 그 인기는 점차 시들어가게 되었다. 특히 성능 문제가 크게 발생했던 것이 큰 이슈가 되었다.
1️⃣ 오버헤드가 큰 런타임 성능
1세대 CSS in JS 중 특정 라이브러리들에서 컴포넌트가 로드되고, 리렌더링이 일어나는 시간이 오래걸린다는 문제가 있었다.
이러한 단점의 이유는 렌더링 과정에서 스타일이 파싱되고 주입되는 시간이 오래걸린 것이다.
또한 아무래도 클라언트 사이드 렌더링으로 동작하는 프레임워크에서 많이 사용되었기에 동적인 스타일 변화가 생길 때마다 스타일을 다시 적용하는 비용이 많이 들었다.
2️⃣ 커진 번들 사이즈
이 방식의 특징이 CSS를 Javascript 내부에 작성하여 만드는 것이다보니, 빌드시 생성되는 Javascript 번들 파일이 아주 많이 커지게 되었다.
이러한 특징은 초기 접속 시 받아오는 번들링의 사이즈를 키우게 되면서, 초기로딩성능(FCP) 에 안좋은 영향을 미치게 되어, 결과적으로 성능에 큰 영향을 미치게 되었다.
3️⃣ 많은 메모리 사용량
CSS in JS는 런타임에 스타일이 자주 변화되면서 스타일이 적용된 구성 요소가 많은 복잡한 애플리케이션에서 메모리 사용량을 증가시킬 수 있었다.
2025년 이제는 어떻게 발전하고 있나?
빌드타임(Zero-runtime) CSS-in-JS 확산
→ 런타임 대신 컴파일 시 CSS 파일 추출 → 퍼포먼스 개선
예: vanilla-extract, Linaria, Astro Scoped CSS
SSR 및 React Server Components 대응 강화
CSS-in-JS도 서버에서 스타일을 미리 생성하거나, 스트리밍에 맞춘 방식으로 최적화 중
네이티브 CSS 발전과 공존
Toss 는 왜 Emotion을 사용할까?
왜 Emotion을 사용하고 있는지에 대해서 열심히 탐방하며 찾아보았다. Toss의 테크 블로그에 올라온 토스 프론트엔드 챕터를 소개합니다! 게시글에서 짧게나마 이유를 찾을 수 있었다.
Reference
CSS in JS: The Good, the Bad, and the Future
CSS Modules vs CSS-in-JS vs Tailwind CSS: A Comprehensive Comparison
