프론트엔드를 하다 보면 CSS를 어떻게 관리할지에 대한 고민이 끝이 없다.
그 중 하나가 바로 Tailwind CSS. 최근엔 거의 “프론트엔드의 표준”처럼 쓰이지만, 나는 처음엔 Tailwind가 너무 불편하게 느껴졌다.
🙅♀️ Tailwind, 처음엔 진짜 보기 힘들었다
Tailwind를 처음 접했을 때의 느낌은 이랬다
<div class="flex flex-col items-center justify-between px-6 py-4 bg-white text-gray-800 rounded shadow-md hover:bg-gray-100 transition duration-200 ease-in-out">
🤯 “이걸 어떻게 읽지?”
🤯 “로직과 스타일이 왜 이렇게 섞여있지?”
🤯 “이 상태에서 버튼 스타일 바꾸려면 어디를 건드려야 하지?”
Tailwind를 쓰다 보면 HTML과 로직 안에 스타일 클래스가 범벅돼서
가독성도 떨어지고,
UI 버그 추적도 어려워지고,
컴포넌트 재사용도 안 되고,
결국 유지보수 지옥이 되기 쉽다.
📈 그런데 왜 이렇게 인기일까?
이렇게 불편한 면이 있는데도, Tailwind는 왜 그렇게 인기 있을까?
한 마디로 말하면, “빠르고 실용적이기 때문”이다.
Tailwind의 장점 정리
장점 | 설명 |
⚡ 빠른 개발 속도 | 스타일 파일 없이도 바로 클래스만으로 디자인 가능 |
🎨 일관된 디자인 시스템 | spacing, color, font 등을 테마 기반으로 자동 정리 |
🧹 불필요한 CSS 제거 | 안 쓰는 클래스는 자동 제거(PurgeCSS/JIT) |
📦 빌드 크기 작음 | 필요한 유틸리티만 컴파일됨 |
📱 반응형, 상태 관리 쉬움 | hover:, md:, dark: 등 클래스 하나로 대응 가능 |
🛠 디자인 시스템 없이도 UI 구현 가능 | 작은 프로젝트나 MVP에 최적 |
😵 단점도 명확하다
Tailwind는 마법의 해결책은 아니다. 잘못 쓰면 오히려 더 지저분해질 수 있다.
Tailwind의 단점
단점 | 설명 |
😵 클래스 지옥 | 많은 속성을 가진 요소는 클래스가 너무 길어짐 |
🤷♀️ 추상화 어려움 | 같은 스타일을 반복해서 쓰게 됨 (컴포넌트 추출 없으면) |
🎓 학습 난이도 | pt-6, text-base, gap-4 등 익숙해지기까지 시간이 걸림 |
🧱 디자인 시스템 없이 사용하면 비일관성 | 팀 단위 사용 시 기준이 없으면 혼란 |
📈 잘못된 동적 클래스 사용 시 빌드 용량 폭증 | bg-${color}-500 같은 코드가 purge되지 않음 |
🔁 CSS-in-JS / CSS Modules와 비교
항목 | Tailwind | CSS-in-JS(styled-components등) | CSS Modules |
개발 속도 | 빠름 | 보통 | 느릴 수 있음 |
스타일 추상화 | 약함 (@apply 또는 컴포넌트 추출 필요) | 강함 (props로 분기 가능) | 강함 |
가독성 | 낮을 수 있음 | 좋음 | 좋음 |
재사용성 | 낮음 -> 직접 분리해야 | 높음 | 높음 |
유지보수 | 잘하면 쉬움 | 쉬움 | 쉬움 |
빌드 성능 | 빠름, 가볍다 | 런타임 존재로 느릴 수 있음 | 중간 |
러닝커브 | 약간 있음 | 적음 | 적음 |
디자인 시스템 지원 | 내장(theme) | 별도 구축 필요 | 없음 |
✨ Tailwind를 올바르게 사용하는 팁
Tailwind를 불편하지 않게 쓰기 위해선 “구조화”와 “정리”가 핵심이다.
1. 컴포넌트화
Tailwind 클래스가 많은 경우, 반드시 컴포넌트 단위로 추출해야 유지보수하기 쉽다.
// Before
<button class="px-4 py-2 bg-blue-500 text-white rounded hover:bg-blue-600">
저장
</button>
// After
<Button>저장</Button>
2. clsx, tailwind-variants로 클래스 정리
const btnClass = clsx(
"px-4 py-2 rounded",
variant === 'primary' && "bg-blue-500 text-white"
);
또는 더 구조적으로
const button = tv({
base: "px-4 py-2 rounded",
variants: {
variant: {
primary: "bg-blue-500 text-white",
secondary: "bg-gray-100 text-black"
}
}
})
3. @apply로 유틸리티 클래스 추출
.btn {
@apply px-4 py-2 bg-blue-500 text-white rounded;
}
4. JIT-safe 클래스만 쓰기
JIT에서는 문자열로 동적으로 만든 클래스는 제거되지 않음.
// ❌ 이런 식은 purge 안 됨
const btnClass = `bg-${color}-500`;
// ✅ 명시적 조건 분기
color === 'red' ? 'bg-red-500' : 'bg-blue-500';
🧭 결론: “Tailwind는 강력한 도구지만, 설계 없이 쓰면 독이 된다”
Tailwind는 MVP나 빠른 개발, 디자인 가이드가 없는 프로젝트에 엄청난 속도를 제공한다.
하지만 구조 없이 쓰면 지저분해지고, 유지보수가 어려운 스타일 스파게티가 된다.
Tailwind를 쓸 때 가장 중요한 건:
✅ “구조화된 컴포넌트 설계”
✅ “클래스 정리”
✅ “디자인 기준의 일관성 유지”
Tailwind가 처음엔 낯설고 보기 불편했지만,
지금은 오히려 “디자인 시스템이 없는 팀”이나 “빠르게 움직이는 팀”에서 가장 효율적인 선택지가 될 수 있다고 느낀다.
너무 많거나 무겁게 느껴진다면,
Tailwind를 “CSS 프레임워크”가 아니라 “디자인 규칙 도우미”로 생각해보자.
그 순간부터, Tailwind는 꽤 쓸만한 조력자가 될지도 모른다.
'IT 노트 > CSS&SCSS' 카테고리의 다른 글
디자인 시스템이 무너질 때, Tailwind로 유연하게 대응하는 법 (0) | 2025.04.08 |
---|---|
[CSS] 창사이즈에 맞춰서 height를 유연성있게 변경해야 할 경우 flex-grow, calc (0) | 2021.10.27 |