몇 년 전까지, 프런트 엔드의 스타일링이라고 하면 BEM등의 명명 규칙에 따라 독자적인 클래스명을 생각해, CSS 파일에 가거나 오면서 디자인을 짜는 것이 주류였습니다. 그러나 현재, 그 풍경은 “Tailwind CSS"에 의해 일변했다. 유틸리티 퍼스트라는 개념은 왜 여기까지 많은 개발자를 매료시켰습니까?
이번은 Tailwind CSS의 도입을 검토하고 있는 분을 향해, 그 메리트와 굳이 말하는 단점을 감싸 숨기지 않고 분석합니다.
장점 1 : 클래스 이름에 대한 깊은 고민으로부터 해방
“이 버튼의 래퍼 요소, 뭐라고 명명하자… button-container? action-wrapper?”
이런 무익한 생각에 시간을 빼앗긴 경험은 없을까요? Tailwind는 미리 준비된 짧은 유틸리티 클래스(flex, p-4, text-center 등)를 HTML에 직접 부여해 나가기 때문에, 클래스명의 명명이라는 정신적 부담이 완전히 소멸합니다.
장점 2: 컨텍스트 스위치 제거
전통적인 개발에서는 HTML (또는 JSX)을 작성하여 CSS 파일을 열고 HTML로 돌아가는 화면 왕복을 피할 수 없었습니다. Tailwind는 마크업에 직접 스타일을 설명하므로 시선 이동과 파일 이동이 줄어들고 사고를 끊지 않고 구성 요소를 조립할 수 있습니다. 이것은 상상 이상으로 개발 속도를 가속시킵니다.
단점 1: HTML이 ‘더럽다’
Tailwind를 비판할 때 자주 나오는 것은 “HTML의 클래스 속성이 너무 길어져 가독성이 떨어진다"는 점입니다. 확실히, 복잡한 컴퍼넌트가 되면 수십개의 클래스가 늘어서, 초견에서는 무엇이 무엇인지 모르는 상태가 되는 일이 있습니다. 이를 피하기 위해서는 React나 Vue와 같은 프레임워크 측에서 컴포넌트 단위로 세밀하게 분할하여 하나의 파일이 비대화되지 않도록 설계의 궁리가 요구됩니다.
단점 2 : 자신의 CSS 지식을 익히기 어렵다
편리한 유틸리티 클래스에 의지해 버리기 위해(때문에), 근저에 있는 원시의 CSS(Flexbox의 사양이나 Grid의 구조 등)의 이해가 완만해지는 경향이 있습니다. Tailwind의 클래스 이름이 어떤 CSS 속성에 매핑되는지 이해하고 사용하지 않으면 복잡한 애니메이션과 레이아웃을 자작하는 장면에서 막힐 수 있습니다.
프로젝트에 대한 적성 진단
그렇다면 Tailwind CSS는 어떤 프로젝트에 적합합니까? 결론으로서는, 「컴퍼넌트 지향의 모던 프레임워크(React/Next.js/Vue/Nuxt등)를 채용하고 있는 프로젝트」이면, 거의 확실히 혜택을 받을 수 있습니다. 반대로, 오래된 HTML 파일만으로 구축된 정적 사이트나, 컴퍼넌트의 재이용이라는 개념이 없는 환경에서는, 단순히 코드가 길어질 뿐의 아픈 결과가 될 수 있습니다.
장점과 단점을 올바르게 이해하고 적재 적소에서 이 강력한 무기를 다루십시오.