IT 노트/CSS&SCSS

Tailwind가 불편했던 나에게 – 왜 인기 있고, 어떻게 잘 써야 할까?

czecze 2025. 4. 7. 18:13
반응형

프론트엔드를 하다 보면 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는 꽤 쓸만한 조력자가 될지도 모른다.

반응형