[React] Tailwind-css를 써보면서 느낀점

개요

---

 Styled-Component로 개발을 하던 도중, Tailwind-CSS가 굉장히 좋다는 평을 듣고 간단한 웹사이트에 적용을 해봤다. 조금 더 큰 프로젝트에 적용하기엔 Tailwind-CSS를 잘 몰라서 우선은 전에 작업하던 프로젝트를 타입스크립트로 마이그레이션 할 겸 적용해보면서 Tailwind-CSS를 파악해보기로 했다.
 
 

전반적인 특징

---

Tailwind-CSS에 대해 설명하는 글은 이미 너무나도 많다.
그럼에도 간단하게 짚고 들어갈 것인데, 너무 뻔한 내용들이 많기에 핵심만 필요한 사람들은 아래의 사용해보면서 느낀 장점으로 넘어가면 된다.

 

Utility First

대부분의 특징은 Utilty First로부터 파생된다. Tailwind-CSS의 대부분의 장점과 단점 모두가 Utility First라는 특성에서 비롯된 것들이라고 해도 무방하다.

Utility First란?
재사용 가능한 작은 스타일 단위를 조합하여 UI를 구성하는 방식으로, CSS를 직접 작성하지 않고도 필요한 디자인을 즉각적으로 구현할 수 있도록 하는 것을 기본 철학으로 가지고 있다.

 
개별 스타일을 담당하는 유틸리티 클래스를 직접 HTML에 적용하여, 새로운 클래스를 만들 필요 없이 이미 존재하는 클래스들을 조합하는 방식으로 스타일을 구성할 수 있다. ▼

<button className="bg-blue-500 text-white font-bold py-2 px-4 rounded">
  고라니 버튼
</button>

 
 

생산성 증가

위와 같이 css를 직접 작성하지 않고도 필요한 디자인을 즉각적으로 구현할 수 있도록 시스템을 설계해 놨기에 전통적인 스타일링 방식대로 css파일을 만들지 않아도 된다. className에 스타일을 작성하면 빠르게 스타일링을 할 수 있기에 생산성이 증가된다.

<button className="bg-blue-500 text-white font-bold py-2 px-4 rounded">
  고라니 버튼
</button>

 
또한 스타일 변경도 쉽게 적용할 수 있어 위의 스타일을 아래와 같이 간단하게 적용할 수 있다.

<!--둥근 버튼에서 각진 버튼으로 교체했다.-->
<button className="bg-blue-500 text-black font-bold py-2 px-4">
  고라니 각진 버튼
</button>

className에 스타일을 작성 <- 이로 인해 한 파일로 css와 html 작성을 끝낼 수 있음
일관적인 스타일링 <- tailwind-css에서 제공하는 디자인 시스템을 통해 일관적인 스타일링이 가능해짐
 
 

사용해보면서 느낀 장점

---

기본제공된 디자인 시스템을 통해 일관적인 스타일링이 가능해진다.
여기는 padding 10 주고, 저기는 padding 11주고 하는 중구난방한 스타일링에서 벗어나 하나의 일관된 값으로 스타일링이 가능해진다.
미리 정의해둔 스타일 코드를 다 입력하고 사용할 수 있으니 기본 제공된 디자인 시스템에 잡혀있지 않게 된다.
 
개인적으로 텍스트 스타일이랑 색상, 그리고 간격 정도는 혼자서 개발할 때도 스타일 가이드를 작성하고 만드는 편이라 이 부분은 굉장히 좋았다. ▼

디자이너가 없거나, 디자인 시스템을 제공해주지 않아도 기본적인 디자인 시스템은 만들어두고 개발한다.

 
intellisence도 잘되어있고 이름 규칙도 일관적이어서 이름이 잘 기억나지 않으면 이름 규칙에 따라 일부만 쳐도 자동으로 나와서 사용하기 편했다.
 
 

하지만... 다시 롤백

---

하지만 사용하다가 불편함을 꽤 많이 느꼈고 이전에 작업하던 프로젝트에서는 다시 Styled-Component로 롤백했다. 핵심적인 원인은 Tailwind-CSS의 특징들이 특정 상황의 프로젝트에 굉장히 유용하게 작용하는 것이다.
 
 
Tailwind-CSS는 Styled-Component와는 다르게 어디서든 무난하게, 약간의 불편함을 감수하면 어떤 프로젝트에서든 무난하게 적용이 가능한 스타일링 라이브러리가 아니다. Tailwind-CSS가 효과적으로 작용하는 프로젝트들의 특징은 아래와 같다.
 
- 디자인 시스템이 있음
- 동적 스타일링이 적음
- 빠르게 개발해야하는 프로젝트
 
그리고 추가적으로 아래의 것들도 있다.
 
- 팀 구성원들이 Tailwind-CSS에 대해 잘 알고 있음
 

팀 구성원들이 Tailwind-CSS에 대해 잘 알고 있지 않음

Tailwind-CSS만의 디자인 시스템이나 구조들을 알아야하기 때문에 초기에 사용하기에 어려운 감이 어느정도 있다. 이전에 비슷한 구조의 라이브러리를 사용해봤다면 금방 적응하겠지만, Tailwind-CSS에서 제시하는 클래스 이름이 꽤나 많이 존재하기에 클래스 이름을 외우는 것부터 시간이 걸리게 된다.

디자인 시스템이 없음

디자인 시스템이 없는 프로젝트였다는 점이 결국 롤백을 결정하게 만든 가장 큰 요인이었다. 물론 디자인 자체는 존재했지만, 일관된 스타일 가이드나 디자인 시스템이 없었기 때문에 각 요소의 스타일이 중구난방으로 적용되었고, 이를 정리하고 통합하는 작업이 생각보다 만만치 않았다. 물론 간단하게 하는 프로젝트에서 디자인 시스템 자체를 바라는 것은 어렵지만, 이번에는 스타일 가이드 조차도 존재하지 않았다. 처음에는 나름대로 일관된 스타일을 정리해가며 적용할 수 있을 거라고 생각했지만, 개발 자체만으로도 벅찬 상황에서 별도의 스타일 가이드를 구축하는 것은 현실적으로 쉽지 않았다. 기존에 이런 상황이 종종 있었어서 템플릿 처럼 사용하던 스타일 가이드가 있긴 했으나, 이번 프로젝트에는 적합하지 않았다.

특히, Tailwind-CSS를 도입한 과정에서도 신중한 검토가 부족했다. 이 프레임워크가 어떤 상황에서 가장 적합하게 활용될 수 있는지 충분히 고민하지 않은 채, 단순히 시간이 부족하다는 이유로 생산성을 높여야겠다는 안일한 생각을 했던 것이 가장 큰 패착이었다. Tailwind-CSS가 제공하는 유틸리티 기반 스타일링 방식이 확실한 디자인 시스템과 함께라면 강력한 생산성을 발휘할 수 있지만, 기초적인 스타일 가이드조차 없는 상황에서는 오히려 더 많은 생각이 필요했고, 결국엔 스타일이 제각각으로 작성됐다. 결국, 효율성을 높이려는 시도가 오히려 개발 속도를 저해하는 결과로 이어졌고, 이런 시행착오 끝에 다시 원점으로 돌아갈 수밖에 없었다.

동적 스타일링에 적합하지 않음

또 다른 문제점은 동적 스타일링이 많았다는 점이었다. 프로젝트의 여러 페이지에서 화면 너비가 줄어들면 글자 크기와 컴포넌트 크기가 자동으로 조정되어야 하는 상황이 빈번했는데, 이를 Tailwind CSS로 구현하는 데 어려움이 많았다.

Tailwind-CSS는 기본적으로 반응형 디자인을 지원하지만, 복잡한 동적 스타일링을 적용하려면 `sm:`, `md:`, `lg:` 같은 반응형 유틸리티 클래스를 조합해야 했다. 하지만 프로젝트의 특성상, 화면 크기에 따라 세밀하게 조정해야 할 스타일이 너무 많았고, Tailwind의 정해진 브레이크포인트만으로는 원하는 수준의 유연성을 확보하기 어려웠다.

그 결과, Tailwind-CSS만으로 해결하려다 보니 코드가 점점 난해해졌고, 오히려 React의 인라인 스타일링을 더 많이 사용해야 하는 상황이 자주 발생했다. 예를 들어, 특정 조건에서 동적으로 `style={{ fontSize: dynamicSize, width: dynamicWidth }}` 같은 방식으로 크기를 조절해야 하는 경우가 많았는데, Tailwind의 클래스 기반 접근 방식과는 상충되는 부분이 많았다. 결국, Tailwind를 활용하려던 의도가 무색해졌고, 인라인 스타일링이 프로젝트에서 차지하는 비중이 점점 늘어났다.

게다가 필자가 CSS 파일을 따로 분리하지 않고, 컴포넌트 하나를 단일 파일로 유지하는 방식을 선호하는 개발 스타일도 문제를 심화시켰을 가능성이 있다. Tailwind는 기본적으로 클래스 이름을 활용하는 방식이므로, 스타일을 JavaScript 코드와 함께 다루려면 불편한 점이 많았다. Styled-Components나 Emotion 같은 CSS-in-JS 라이브러리는 동적인 스타일을 적용하는 데 더 적합한 반면, Tailwind CSS는 정적인 스타일링을 간편하게 처리하는 데 더 강점이 있는 도구였기 때문이다.

결국 해당 프로젝트에서 Tailwind-CSS를 활용하는 것이 React의 기본 인라인 스타일링으로 작업하는 것과 거의 다를 바 없는 수준이 되어버렸고, 오히려 코드가 불필요하게 복잡해지는 상황이 자주 발생했다. 생산성을 높이려는 목적으로 Tailwind-CSS로 마이그레이션을 시도했지만, 오히려 개발 속도가 저하되고 코드의 가독성이 떨어지는 결과로 이어졌다.

---

위의 문제들로 인해 Tailwind CSS 도입을 중단하고, 다시 Styled-Components로 돌아가기로 결정했다. Styled-Components는 JSX, TSX 내부에서 동적 스타일을 선언적으로 다룰 수 있고, 조건부 스타일링도 더 직관적으로 적용할 수 있기 때문이다. Tailwind CSS가 강력한 유틸리티를 제공하는 것은 분명하지만, 이 프로젝트처럼 동적 스타일이 많고, 컴포넌트 단위로 스타일을 관리하는 방식이 더 적합한 경우에는 오히려 CSS-in-JS 솔루션이 더 나은 선택일 수 있다는 점을 깨닫게 되었다.

마무리와 느낀점

---

Tailwind CSS가 나쁜 툴이라는 것은 아니다. 필자는 감히 개발할 엄두도 나지 않는 엄청난 라이브러리고 생산성을 획기적으로 높여주는 훌륭한 툴이다. 그저 이번 프로젝트와는 적합하지 않았던 것이 가장 큰 이유였고, 어쩌면 필자가 Tailwind CSS를 충분히 숙련되지 않은 상태에서 제대로 활용하지 못한 것일 수도 있다.

하지만 이번 경험을 통해 확실히 깨달은 것이 하나 있다. 라이브러리나 프레임워크를 프로젝트에 도입할 때, 현재의 프로젝트와 얼마나 적합한지를 철저하게 따져봐야 한다는 점이다. 이는 어찌 보면 당연한 이야기처럼 들릴 수도 있다. 하지만 현실에서는 필자를 포함한 많은 개발자가 “모두가 좋다고 극찬하는 도구“에 대한 신뢰를 너무 쉽게 가져버리는 경우가 많다.

이번 사례처럼 Tailwind CSS는 확실히 강력한 도구지만, 모든 프로젝트에 적합한 것은 아니었다. 그래서 앞으로는 단순히 유명한 라이브러리라고 해서 무조건 도입하는 것이 아니라, 해당 프로젝트의 특성과 요구사항을 먼저 분석하고, 정말 최적의 선택인지 검토하는 과정이 반드시 필요하다는 점을 다시 한번 실감했다.

그렇기에, 새로운 기술을 도입할 때는 단순히 “이 도구가 좋은가?” 가 아니라 “현재의 프로젝트와 얼마나 적합한가?”, 그리고 “더 적합한 대안은 없는가?”를 끊임없이 고민해야 한다. 기술의 우열이 아니라, 적절한 맥락에서의 선택이 더 중요하다는 점을 이번 경험을 통해 다시금 깨닫게 되었다.