왜 Tailwind css를 사용해야할까?

Tailwind CSS는 부트스트랩과 비슷한 역할을 한다고 말할수도 있지만 좀 자세히 알아보면 부트스트랩의 상위호환격이라도도 말할 수 있는 프레임워크이다.

그동안 tailwind외에도 styled component, sass를 다 써보았지만 왜 최종적으로 tailwind를 사용하게 되었는지에 대해 이 글에서 소개하려 한다.

tailwind의 가장 큰 장점은 사용이 편리하다는 점이다. 예를들어 16px의 padding을 주고 싶을 때 기존에는 클래스를 선언한 뒤 해당 클래스명을 불러와서 사용하는식으로 css를 사용했다면 tailwind는 class부분에 p-4와 같이 입력하면 tailwind프레임워크가 이를 확인하고 해당 부분에 알아서 16px의 padding을 적용시켜준다.
tailwind를 처음 사용하게 되면 tailwind만의 고유 css 문법에 대해 헷갈릴 수 있는데 이러한 부분을 VScode의 Tailwind CSS IntelliSense extension이 해결해줄 수 있다. 해당 extension을 설치하면 클래스 내부에서 p와 같이 입력하였을 때 해당 문자로 어떤 css를 불러올 수 있는지 나열해주기에 편하게 사용할 수 있다. 또한 tailwind 공식 홈페이지에서도 이러한 부분들을 검색을 통해 찾아볼 수 있다.

하지만 16px인데 왜 p-4인가 라는 의문이 들수도 있는데 이 부분에 대해서 tailwind 내부에서 어느 정도까지 웹 개발에 있어서 픽셀을 핸들링해야할지에 대하여 기준을 잡고 1~20px범위는 p-0.5 p-1과 같이, 20~100px 범위는 p-5,p-6 ~ p-20 등과 같이 점점 범위를 넓혀 정의를 해놓은 뒤 이를 불러와 사용하는 식으로 사용을 하게된다. 과거 tailwind 1.@ 버전까지는 이렇게 고정되어 애매한 픽셀과 같은 경우 사용이 불가능한 부분이 tailwind의 단점이라고 할 수 있었는데 2.0이상 버전부터 tailwind에서 JIT엔진을 사용하게 되면서 선언이 되어있지 않은 애매한 픽셀의 경우 p-[687px]과 같이 사용할 수 있게 하여 이러한 단점을 극복하였다.
이렇게 tailwind 내부에서 어느정도의 범위를 나누어놓은 부분에서는 tailwind 디자인, 개발팀의 고민이 느껴지며 어느 수준 이상으로 세세하게 CSS를 사용하는 경우 개발이나 디자인의 속도면에 있어서 오히려 anti-pattern이라고 생각하여 적절하게 범위를 나눠놓았다고 생각하며 이러한 부분에 있어서 100% 공감하고 있기에 이를 tailwind의 최대 장점이라고 말할 수 있을 것 같다.

어떻게보면 겹친다고도 말할 수 있는데 위에서 말한 장점으로 인하여 코드의 생산성이 엄청나게 증가하게되는데 이 또한 tailwind의 장점이라고 말할 수 있다. 모든 클래스부분에서 독립적으로 클래스가 선언되게 되므로 코드의 생산적인면에서 어떻게 클래스를 구성해야할지, 클래스명을 어떻게 해야할지, 어떻게 해야 클래스가 중복되지않을지에 대하여 고민할 필요가 없어지며 코드를 유지보수함에 있어서도 수정해야할 부분의 코드만 수정하면 다른곳과 연관되어있지 않기에 큰 고민을 하지 않고 쉽게 수정할 수 있다.

또한 성능적인부분도 tailwind의 장점중 하나라고 말할 수 있다. tailwind는 내부적으로 유틸리티 클래스를 생성하여 사용하며 코드 내에서 css를 사용하면 이 유틸리티 클래스들에서 해당 css를 가져와 사용하는 방식으로 동작하게된다.
그렇다면 이 유틸리티 클래스들을 생성하는 과정에서 오히려 성능상 손해를 보지 않을까? 라고 생각할수도 있다. 하지만 이러한 문제점은 tailwind의 purgeCSS기능이 해결해주게 된다.
purgeCSS란 tailwind에서 내부적으로 사용하는 핵심적인 라이브러리이다. purgeCSS는 사용하지 않는 css들을 알아서 제거해주며 이를 통하여 수많은 유틸리티 클래스들의 용량을 줄여 빌드타임을 빠르게 많들어주는 핵심적인 역할을 하게된다.

tailwindcss는 요즘 핫한 figma와도 매우 잘맞는 프레임워크이다. tailwind가 내부적으로 나눠놓은 css 기준들은 figma의 사용 방식과 매우 잘 맞는다고 말할 수 있으며 이로인하여 디자이너와 개발자가 협업을 함에 있어서 생길 수 있는 수많은 문제들을 tailwind가 많이 해결해주게된다.

현재 tailwind의 가장 큰 단점이라고 말할 수 있는 부분은 tailwind의 클래스명들을 html에 직접 때려박음으로써 어떠한 태그의 클래스가 반복되게 될 경우 몇 byte의 용량 손해를 볼 수 있다는 점이다. 하지만 nextjs를 사용한다면 이러한 부분들은 따로 @apply를 사용하여 css파일에 클래스를 선언한 뒤 사용한다면 쉽게 해결할 수 있게 된다.

추가적인 단점이 있다면 class명이 복잡하여 읽기 어려워질 수 있다는 점인데 이러한 부분은 tailwind 사용이 어느정도 익숙해진다면 크게 느끼지 못하는 단점이며 이것이 tailwind의 단점인것을 인지하고 classnames와 같은 라이브러리를 사용하여 코드를 각 break-point별로 분리하여 사용한다던가 팀 내부적으로 어떠한 규칙을 정하여 사용한다면 해결이 될 것이라고 생각한다.

얼마전에 tailwind 3.0 알파 버전을 공개하였는데 3.0알파버전부터는 기존 따로 선언해야 사용할 수 있는 JIT를 all time으로 사용하며 성능상 엄청난 이득이 있도록 새롭게 엔진을 만들고 JIT CDN build(개발자 환경에서만 사용 가능)를 사용하는 등 각종 feature들이 추가되었다.
참고링크

혹시 tailwind에 관심이 있다면 tailwind youtube, headless ui(무료) tailwind ui(유료)와 같은것도 찾아보거나 한번 쯤 사용해보길 바란다(유료) 나같은 경우 회사에서 구매하여 사용하고 있는데 웹 개발자가 참고할만한것들이 많이 있으므로 웹 개발을 하는 사람이라면 tailwind를 사용할 생각이 없더라도 웹 프론트의 정석적인 부분에 있어 많은 도움을 받을 수 있을것이니 꼭 사용해보길 바란다.