지난 몇 달간 개인 프로젝트에 TailwindCSS를 적용해보았습니다. TailwindCSS가 Next 프로젝트에서 권장되는 이유는 크게 세 가지입니다:
- 사용하지 않는 클래스 제거: 빌드 시 사용하지 않는 클래스가 제거되어 번들 크기가 줄어듭니다.
- 효율적인 스타일 관리: Atomic한 특성으로 인해 프로젝트가 커져도 스타일시트의 크기가 비례하여 늘어나지 않습니다.
- SSR(서버 사이드 렌더링) 적합성: 런타임에 스타일시트를 생성하지 않고 빌드 타임에 스타일시트를 가져오는 방식이기 때문에 SSR에서도 추가적인 설정 없이 작동할 수 있습니다.
CSS module이나 Sass도 빌드 타임에 스타일시트를 생성하지만, selector 기반 CSS의 한계를 극복하지 못해 TailwindCSS를 특히 추천하는 것 같습니다.
권장되는 이유가 많음에도 불구하고, 개발 용이성은 매우 떨어진다는 것이 제 결론입니다. 가독성과 유지보수성 측면에서 다양한 불편함이 있었습니다. 스타일 정의가 너무 복잡해지고, 코드가 어지러워지는 경향이 있었습니다.
결국, 몇 달간 적용했던 TailwindCSS를 버리고 CSS-in-JS로 전환하기로 결정했습니다. 향후 개발 일정을 고려한다면 현명한 판단이라 생각했습니다.
주변에서는 Emotion, Styled Components, Chakra UI, Vanilla Extract, PandaCSS 등 다양한 라이브러리를 사용하고 있습니다. 그 중, Emotion은 Next의 최신 트렌드를 따라가지 못한다는 의견이 많았습니다. 결국 가장 개발 편의성이 높다고 판단한 Styled Components로 돌아가기로 결정했습니다.
RSC(React Server Component)가 표준화된다면 Zero Runtime CSS-in-JS에 대해 학습할 필요성을 느끼고 있습니다.