오늘은 실무에서 대규모 프로젝트의 성패를 가르는 CSS 아키텍처에 대해 이야기해볼게. 많은 주니어들이 Tailwind CSS나 CSS-in-JS 같은 편리한 도구만 쓰면 스타일링 고민이 끝나는 줄 알지만, 실제 서비스가 커질수록 아키텍처 설계 없이는 스파게티 코드가 되기 십상이거든. 내가 9년차로 일하면서 겪은 CSS 구조화의 핵심 노하우를 몇 가지 공유해 줄게.
1. 테일윈드는 도구일 뿐, 아키텍처가 아니다
많은 개발자들이 Tailwind CSS를 쓰면 CSS 아키텍처가 필요 없다고 오해하곤 해. 하지만 유틸리티 클래스가 화면을 가득 채우기 시작하면 코드 가독성이 급격히 떨어지고 유지보수가 불가능해지더라.
- 테일윈드는 스타일을 입히는 수단일 뿐, 컴포넌트를 어떻게 나누고 스타일의 일관성을 어떻게 유지할지 결정하는 아키텍처가 될 수 없어.
- 클래스명이 너무 길어질 때는 무작정
@apply를 남발하기보다, 컴포넌트를 더 작은 단위로 쪼개는 구조적 해결책을 먼저 고민해봐야 해.
2. Tailwind v4.0의 변화와 CSS-first 접근법
최근 Tailwind CSS v4.0으로 넘어오면서 아주 흥미로운 변화가 생겼어. 기존의 tailwind.config.js 같은 자바스크립트 기반 설정 대신, CSS-first 방식으로 CSS 파일 내에서 설정을 제어하도록 바뀌었거든.
- 이제는 테마 정의나 커스텀 설정을
@theme지시어를 사용해 CSS 파일 안에서 직접 처리하게 돼. - 이러한 변화는 자바스크립트 의존성을 줄이고 CSS 본연의 힘을 극대화하려는 현대 웹 표준의 흐름과 맞닿아 있어. 설정을 관리할 때도 스타일 시트 자체의 구조를 먼저 설계하는 능력이 더 중요해진 셈이지.
3. 대규모 코드베이스에서의 클래스 정리 기술
실무에서 테일윈드를 쓸 때 가장 골치 아픈 게 바로 컴포넌트 상태에 따른 클래스 분기 처리야. 이럴 때는 단순히 문자열 더하기를 쓰지 말고 도구의 도움을 받는 것이 좋아.
tailwind-merge와clsx를 조합해서 중복 클래스를 깔끔하게 정리하는 유틸리티 함수를 만들어봐.- 디자인 시스템처럼 다양한 변형(Variant)이 필요한 컴포넌트는
cva(Class Variance Authority) 라이브러리를 도입하는 걸 강력히 추천할게. 상태별 스타일을 객체 형태로 구조화할 수 있어서 코드 가독성이 놀라울 정도로 좋아지거든.
💡 핵심 정리
- 도구에 의존하지 말 것: 테일윈드는 유틸리티일 뿐, 컴포넌트 구조화와 설계는 개발자의 몫이다.
- 트렌드 파악하기: Tailwind v4.0의 CSS-first 설정처럼 변화하는 CSS 표준 흐름을 놓치지 말자.
- 도구 활용 극대화:
cva나tailwind-merge같은 라이브러리로 복잡한 클래스 분기를 구조화하자. 스타일링 코드가 깨끗해야 비즈니스 로직도 눈에 잘 들어오는 법이야. 오늘 이야기한 구조화 고민들을 지금 만드는 프로젝트에 딱 하나씩만 먼저 적용해봐. 코드가 한결 가벼워지는 걸 직접 느끼다 보면 개발이 훨씬 재밌어질 거야.