📌 CSS-in-JS와 헤어지는 이유

Spot이라는 제품을 만드는 팀에서 Emotion을 버리고 Sass Modules(+Utility Class)로 바꾸게 된 이유를 다룬 글입니다. 저자는 CSS-in-JS의 장점과 단점 그리고 못난 점(Ugly)을 소개하고 성능 이슈로 Emotion과 헤어졌다고 말합니다. 장점은 세 가지. 스타일을 제한된 영역에서 관리한다는 점(Locally-scoped styles), 컴포넌트 코드와 스타일 코드를 한 곳에 모아 볼 수 있다는 점(Colocation) 그리고 자바스크립트 변수를 스타일에 적용할 수 있다는 점입니다. 단점도 세 가지입니다. 런타임에 스타일 직렬화하면서 성능에 부정적인 영향을 준다는 점, CSS-in-JS를 위한 라이브러리로 인해 번들 크기가 커진다는 점 그리고 React DevTools를 보기 어렵게 만든다는 점입니다. 여기서 문제가 됐던 부분은 첫번째 단점인 스타일 직렬화로 인한 성능 이슈입니다. 리액트가 렌더링하는 시점에 매번 스타일을 계산하는 경우 그렇지 않은 경우보다 속도가 느려진다는 점이죠. 이를 위해 런타임 비용이 없는 Sass를 도입한 것으로 결정합니다. 사실 개발자의 편의, 경험(DX)을 놓고 봤을 땐 CSS-in-JS의 장점이 훨씬 두드러집니다. 저자도 글의 말미에서 "Spot의 경우, Emotion의 런타임 성능비용이 DX의 이점을 훨씬 능가"했기에 Emotion을 버리는 결정을 했다고 말합니다. 개인적으로는 이 글이 많은 개발자가 CSS-in-JS를 더 좋은 방법으로 사용되었으면 하는 마음으로 쓰인 게 아닌가 싶습니다. 어떤 기술이든 오용하면 단점이 장점보다 극대화될 수 있으니까요. Spot 팀과 같은 상황이 아니라면 CSS-in-JS의 스타일 직렬화를 과도하게 발생시키고 있는지 반성하는 쪽으로 이 글을 이해하면 좋겠다는 생각이 듭니다.