Tailwind vs styled-components, 어떤 것을 선택해야 할까?
프론트엔드 개발자라면 누구나 한 번쯤 이런 고민을 해봤을 것이다.
“이번 프로젝트엔 Tailwind가 나을까, styled-components가 나을까?”
나 역시 예외는 아니었다.
styled-components로 개발을 이어오던 중, 지난 회사에서 새로운 프로젝트를 시작하게 되었다.
그 시점에 Tailwind는 이미 많은 팀이 사용하고 있는 기술 스택이었고, 나 또한 직접 사용해보며 어떤 점이 그렇게 편리한지, 왜 그렇게 선호되는지 경험해보고 싶었다.
그래서 새로운 프로젝트에 Tailwind를 도입했지만, 프로젝트의 특성상 상태 변화가 잦고 동적인 UI가 많은 구조였던 탓에 Tailwind로 상태별 스타일을 제어하는 과정은 예상보다 훨씬 번거로웠다.
처음에는 단순한 클래스 조합으로도 충분할 줄 알았는데, 요소가 복잡해질수록 코드의 가독성이 떨어지고 유지보수가 어려워졌다.
결국 styled-components로 다시 돌아왔고, 그 경험을 통해 두 도구가 지향하는 방향과 강점이 근본적으로 다르다는 점을 명확히 느낄 수 있었다.
이 글은 그 경험을 바탕으로, 두 스타일링 방식이 실제 개발 과정에서 어떤 차이를 보이는지, 그리고 어떤 상황에서 더 적합한 선택이 될 수 있는지를 정리해본 글이다.
1. Tailwind, 이미 완성된 구조
Tailwind는 기본적으로 “유틸리티 퍼스트(Utility-first)” 철학을 가지고 있다.
HTML 클래스 이름만으로 스타일을 완성하는 방식이다.
<button className="px-4 py-2 bg-emerald-600 text-white rounded-lg hover:bg-emerald-700"> 저장 </button>이 한 줄이면 끝이다.
CSS 파일을 만들 필요도, styled-components처럼 컴포넌트를 따로 선언할 필요도 없다.
처음엔 굉장히 빠르고, 시각적인 결과가 즉시 나오기 때문에 개발 속도도 올라간다.
Tailwind의 장점은 명확하다.
장점
- 개발 속도가 빠르다. — 스타일 정의 없이 바로 클래스만 조합하면 된다.
- 디자인 일관성이 유지된다. — 모든 색상, 간격, 폰트 등이 tailwind.config.js로 중앙관리된다.
- 협업이 쉽다. — 클래스 이름만 봐도 스타일이 바로 읽히고, 누구나 동일한 결과를 낼 수 있다.
- 성능이 좋다. — 빌드 시 실제로 사용된 클래스만 CSS로 추출하기 때문이다.
하지만 단점도 명확하다.
단점
- 동적 스타일링이 불편하다. — 상태나 props에 따라 스타일을 바꾸는 로직이 복잡해진다.
- className 문자열이 길어진다. — 복잡한 컴포넌트일수록 한눈에 보기 힘들다.
- 새로운 클래스 규칙을 외워야 한다. — 자주 쓰는 건 익숙해지지만, 초반엔 진입장벽이 있다.
2. 실제 경험 — Tailwind를 도입했다가 되돌아온 이유
나는 마케팅 매체 비교 프로젝트에서 Tailwind를 사용했다.
처음엔 좋았다. 빠르게 결과가 나오고, 반응형도 쉽게 적용됐다.
그런데 프로젝트가 조금 커지고, 상태값에 따라 스타일이 바뀌기 시작하자 문제가 생겼다.
예를 들어, 버튼이 눌렸을 때 색이 달라져야 하는 간단한 상황이었다.
하지만 Tailwind로 구현하려면 이런 식이 되어버린다.
<button className={clsx( "px-4 py-2 rounded-lg font-medium transition-colors", isActive ? "bg-emerald-600 text-white" : "bg-gray-200 text-gray-700", )} > 저장 </button>
보기에도 복잡하고, 스타일 로직이 길어질수록 눈에 잘 들어오지 않았다.
게다가 클래스 문자열이 길어지면서 코드 가독성이 급격히 떨어졌다.
결국 “동적 스타일이 많은 페이지에서는 Tailwind가 너무 비효율적이다”라는 결론을 내렸다.
styled-components로 다시 옮긴 뒤, 같은 로직은 훨씬 간결해졌다.
const Button = styled.button<{ $active: boolean }>` padding: 10px 16px; border-radius: 8px; font-weight: 500; background: ${({ $active }) => ($active ? "#3A5A40" : "#ccc")}; color: ${({ $active }) => ($active ? "#fff" : "#555")}; `;CSS처럼 읽히고, 로직도 명확했다.
3. styled-components, 자유롭지만 구조는 스스로 세워야 한다
styled-components의 세계는 Tailwind와 정반대다.
여기서는 구조가 주어지지 않기 때문에 디자인 시스템, 색상 토큰, 여백 규칙 등 모든 것을 직접 세워야 한다.
이건 장점이자 단점이다.
장점
- JS 상태 기반 스타일링이 자연스럽다.
→ props, state, theme을 이용한 분기 처리가 직관적이다. - 가독성이 좋다.
→ CSS 문법 그대로 쓰니까 디자인이 코드처럼 읽힌다. - 구조적이다.
→ 컴포넌트 단위로 스타일을 관리할 수 있다.
단점
- 초기 설정이 귀찮다.
→ theme 파일, Provider, 타입 설정 등 직접 구성해야 한다. - 팀마다 구조가 다르다.
→ 새로운 개발자가 왔을 때 그 팀의 스타일 시스템을 다시 파악해야 한다. - 디자인 시스템 일관성 유지가 어렵다.
→ 강제 규칙이 없으니 사람마다 다르게 쓸 수 있다.
4. 결국 차이는 “틀이 주어지느냐, 직접 짜느냐”
이게 두 도구의 본질적 차이다.
| 구분 | Tailwind | styled-components |
| 기반 구조 | 이미 정의된 시스템을 가져다 쓴다 | 직접 디자인 시스템을 만들어야 한다 |
| 일관성 | 매우 높음 (클래스 기준 통일) | theme 설계에 따라 달라짐 |
| 동적 스타일링 | 다소 복잡 (clsx, cva 필요) | 자연스럽고 직관적 |
| 개발 속도 | 초기 빠름 | 구조 잡을 땐 느림 |
| 협업/인수인계 | 쉬움 (공용 규칙) | 어렵다 (팀별 구조 상이) |
| 적합한 상황 | 큰 팀, 일관된 UI, 디자인 시스템 기반 | 개인 프로젝트, 브랜드 감성, 동적 UI |
5. 그럼 어떤 걸 선택해야 할까?
이건 결국 프로젝트의 성격과 팀 구성에 따라 달라진다.
| 상황 | 추천 |
| 스타트업, 빠른 프로토타이핑 | Tailwind |
| 디자인 시스템이 확립된 중대형 팀 | Tailwind |
| 개인 브랜드/감성 프로젝트 | styled-components |
| 상태 기반 UI가 많은 페이지 | styled-components |
| 새로운 개발자 유입이 잦은 조직 | Tailwind |
당시 내가 만들던 마케팅 매체 비교 서비스는 매체별 데이터를 한눈에 비교할 수 있도록 필터링, 정렬, 툴팁 등 여러 인터랙션 기능이 복잡하게 얽혀 있었다. 즉, 매우 동적이고 상태 변화가 많은 페이지를 구현해야 했다.
이런 구조에서는 Tailwind보다 styled-components의 자유로운 스타일 제어가 훨씬 잘 맞았다.
하지만 만약 여러 명이 함께 같은 화면을 만들어야 하는 환경이었다면, 디자인 일관성과 협업 효율을 위해 Tailwind를 선택했을지도 모른다.
6. 마무리 — 기술은 취향이 아니라 맥락이다
결국 Tailwind와 styled-components는 무엇이 더 좋은가의 문제가 아니다.
어떤 맥락에서 더 적합하냐가 핵심이다.
Tailwind는 빠르고 일관되며, 협업에 유리하다. 반면 styled-components는 자유롭고, 동적이며, 감각적이다.
나는 다시 styled-components로 돌아왔지만, Tailwind를 써본 경험 덕분에 '팀 구조와 디자인 시스템이 왜 중요한가'를 더 깊이 이해하게 되었다.
기술은 결국 도구이기 때문에, 그 도구가 지금의 나와 프로젝트의 목적에 맞느냐가 가장 중요할 것이다.
