공유된 기술노트 · React
기업에서 Tailwind를 사용하지 않고 CSS Modules 를 쓰는 이유
결론
요즘 NextJS 프로젝트를 진행할 때 AI 를 이용하는 기업에서는 Tailwind를 이용해서 스타일을 입히는 경향이 두드러지는 것 같다. 그럼에도 불구하고 최근에는 NextJS 가 제공하는 CSS Modules 를 이용하려는 움직임이 있는 것 같은데, 그 이유를 간단히 정리해보려고 한다.
1. 스타일에 이름이 있어야 의도가 남는다
<!-- Tailwind -->
<button class="flex items-center gap-2 px-4 py-2 rounded-md bg-blue-600 text-white hover:bg-blue-700">
<!-- CSS Modules -->
<button className={styles.primaryButton}>위의 예제를 보면 첫 번째는 "무슨 속성을 적용할 것인지"만 나열하고, 두 번째는 "어떤 스타일의 모양인지"를 말해주고 있다. 6개월 뒤 이 첫 번째 코드는 그것을 만든 사람도 어떤 스타일을 만든건지 파악하려면 시간이 오래 걸리거나 실행해봐야 아는 경우가 일반적이다.
따라서 스타일 클래스의 나열이 아니라 모양을 명명한 스타일 클래스가 더 좋은 코드라고 할 수 있다.
잘 작성된 스타일 클래스 이름은 의도를 남기고, 유틸리티 나열은 의도를 남기지 않는다.
2. 공통 스타일은 한 곳에 있어야 한 번에 고친다
카드 20개의 패딩을 바꾸는 상황을 생각해 보자.
| 방식 | 수정 범위 |
|---|---|
| CSS Modules | .card { padding: ... } 한 줄 |
| Tailwind | 20개의 p-4 를 찾아서 수정, 하나라도 놓치면 화면이 어긋남 |
Tailwind 도 컴포넌트로 묶으면 해결된다고 말한다. 맞다. 그런데 CSS Module 방식은 "이름을 붙인 공통 스타일"이 이미 있을 것이고 그 이름만 가져다 사용하면 끝이다.
3. 스타일은 한 번 내려받고 캐시되어야 한다
이 부분은 직접 측정할 수 있다.
- CSS Modules: 스타일은 CSS 파일에 한 번만 들어가고 브라우저가 캐시한다. 다음 페이지부터는 다시 받지 않는다. HTML 에는 짧은 클래스 이름만 실린다.
- Tailwind: 반복되는 요소마다 긴 클래스 문자열이 HTML 에 그대로 들어간다. HTML 은 페이지를 열 때마다 새로 받으므로 같은 스타일 정보를 매 페이지마다 다시 전송한다. Next.js App Router 는 HTML 외에 RSC 페이로드에도 같은 문자열을 한 번 더 싣는다.
주의. Tailwind 의 CSS 파일 자체는 작다. 사용한 클래스만 남기기 때문이다. 커지는 것은 CSS 가 아니라 HTML 과 RSC 페이로드이며, 문제의 본질은 **"반복 전송되고 캐시되지 않는다"**이다. 이 표현을 정확히 쓸 것.
4. 디자인 토큰의 출처는 하나여야 한다
기업 프로젝트에는 색, 간격, 글꼴 크기를 정의한 디자인 토큰이 있다.
- CSS 변수로 두면 CSS Modules 는 그 변수를 그대로 쓴다.
- Tailwind 는 자기 토큰 체계를 따로 가지고 있어서 회사 토큰을 설정 파일에 다시 매핑해야 하고, 그 순간 진실이 두 곳이 된다.
- 다크 모드도 변수만 바꾸면 끝나는 구조와 요소마다
dark:접두사를 붙이는 구조의 차이다.
5. HTML 구조가 읽혀야 한다
클래스 문자열이 길어지면 태그의 부모 자식 관계가 눈에 들어오지 않는다. 마크업은 구조를, CSS 는 표현을 맡는다는 분리는 오래된 원칙이지만 이유가 사라진 적은 없다.
AI 는 왜 Tailwind 를 추천하는가
AI 가 Tailwind 를 권하는 것은 비교 평가의 결과가 아니다.
- 최근 몇 년의 예제 코드 대부분이 Tailwind 이고,
create-next-app기본값이라 학습 데이터가 기울어 있다. - AI 는 파일 하나를 통째로 생성하는 데 강하고, 두 파일(컴포넌트와 CSS)을 맞추는 데 약하다. 마크업 안에서 끝나는 방식이 AI 에게 편하다.
- 클래스 이름을 지을 필요가 없다. 이름 짓기는 AI 에게도 어렵다.
즉 "AI 가 편한 방식"이지 "여러분이 유지보수하기 좋은 방식"이 아니다.
확인하는 방법. 같은 AI 에게 "자체 디자인 시스템을 가진 기업 프로젝트인데 Tailwind 를 써야 하나"라고 물어보라. 답이 바뀐다. 질문 한 줄로 뒤집히는 추천은 원칙이 아니라 통계다.
Tailwind 가 맞는 경우
공정하게 말하면 Tailwind 가 유리한 상황도 있다.
- 하루 만에 끝내는 프로토타입
- 혼자 만들고 혼자 고치는 프로젝트
- shadcn/ui 같은 킷을 그대로 쓰는 경우
이름 짓기와 구조화를 포기하는 대신 속도를 산다. 여러분이 기업에서 만들 것은 그런 프로젝트가 아니다.
이번 주 실습으로 확인할 것
- 카드 목록 페이지를 두 방식으로 만들고 브라우저 네트워크 탭에서 HTML 응답 크기를 비교하라. 그다음 다른 페이지로 이동했을 때 다시 받는 바이트를 비교하라.
- 카드 패딩을 바꾸는 데 몇 곳을 수정했는지 세어 보라.
- AI 에게 "왜 Tailwind 인가"를 세 번 캐물어 보라. "널리 쓰인다", "생산적이다" 이상의 근거가 나오는지 확인하라.
마지막 한 가지
AI 는 프로젝트에 규칙이 있으면 그 규칙을 따른다. 프로젝트 지침 파일에 "스타일은 CSS Modules 와 CSS 변수만 사용"이라고 적으면 AI 도 그렇게 답한다.
규칙을 정하는 것은 여러분이고, AI 는 규칙을 따르는 도구다. 이것이 기업에서 AI 를 쓰는 방식이다.
이 주소는 글의 저작자가 공개한 링크입니다. 뉴렉처 스터디의 다른 자료는 로그인 후 볼 수 있어요.