공유된 기술노트 · React

newlec · 2026. 9. 16.

기업에서 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 를 권하는 것은 비교 평가의 결과가 아니다.

  1. 최근 몇 년의 예제 코드 대부분이 Tailwind 이고, create-next-app 기본값이라 학습 데이터가 기울어 있다.
  2. AI 는 파일 하나를 통째로 생성하는 데 강하고, 두 파일(컴포넌트와 CSS)을 맞추는 데 약하다. 마크업 안에서 끝나는 방식이 AI 에게 편하다.
  3. 클래스 이름을 지을 필요가 없다. 이름 짓기는 AI 에게도 어렵다.

즉 "AI 가 편한 방식"이지 "여러분이 유지보수하기 좋은 방식"이 아니다.

확인하는 방법. 같은 AI 에게 "자체 디자인 시스템을 가진 기업 프로젝트인데 Tailwind 를 써야 하나"라고 물어보라. 답이 바뀐다. 질문 한 줄로 뒤집히는 추천은 원칙이 아니라 통계다.


Tailwind 가 맞는 경우

공정하게 말하면 Tailwind 가 유리한 상황도 있다.

  • 하루 만에 끝내는 프로토타입
  • 혼자 만들고 혼자 고치는 프로젝트
  • shadcn/ui 같은 킷을 그대로 쓰는 경우

이름 짓기와 구조화를 포기하는 대신 속도를 산다. 여러분이 기업에서 만들 것은 그런 프로젝트가 아니다.


이번 주 실습으로 확인할 것

  1. 카드 목록 페이지를 두 방식으로 만들고 브라우저 네트워크 탭에서 HTML 응답 크기를 비교하라. 그다음 다른 페이지로 이동했을 때 다시 받는 바이트를 비교하라.
  2. 카드 패딩을 바꾸는 데 몇 곳을 수정했는지 세어 보라.
  3. AI 에게 "왜 Tailwind 인가"를 세 번 캐물어 보라. "널리 쓰인다", "생산적이다" 이상의 근거가 나오는지 확인하라.

마지막 한 가지

AI 는 프로젝트에 규칙이 있으면 그 규칙을 따른다. 프로젝트 지침 파일에 "스타일은 CSS Modules 와 CSS 변수만 사용"이라고 적으면 AI 도 그렇게 답한다.

규칙을 정하는 것은 여러분이고, AI 는 규칙을 따르는 도구다. 이것이 기업에서 AI 를 쓰는 방식이다.

이 주소는 글의 저작자가 공개한 링크입니다. 뉴렉처 스터디의 다른 자료는 로그인 후 볼 수 있어요.