테일윈드를 권하지 않는 이유: 실무자가 따져봐야 할 비용

테일윈드 CSS는 웹 개발자 사이에서 폭넓게 자리 잡은 유틸리티 우선(Utility-First) 프레임워크다. 디자인 지식이 부족한 개발자에게도 여백과 색상, 크기의 표준화된 척도를 제공하고, 작은 유틸리티 클래스를 조합해 큰 구조를 만들도록 강제한다. 검색이 잘 되는 문서와 에디터 자동완성까지 더해지면서 UI를 빠르게 찍어내는 데 유리하다. 그런데 원문의 저자는 여러 프로젝트에서 테일윈드를 써 본 경험을 바탕으로, 중대형 프로젝트에서는 도입 전에 한 번 더 고민하라고 권한다. 도구 자체가 나쁘다는 주장이 아니라, 지금 아끼는 초기 비용을 미래에 이자까지 붙여 갚게 될 수 있다는 경고다.

관심사의 분리는 사라지지 않고 방향을 바꾼다

테일윈드에 대한 대표적 비판은 HTML에 수십 개의 클래스가 쌓이면서 구조와 디자인의 분리가 무너지고 가독성과 재사용성이 떨어진다는 것이다. 이에 대해 창시자 애덤 웨이던은 설득력 있는 반론을 남겼다. 관심사의 분리는 없어지는 게 아니라 화살표의 방향이 바뀔 뿐이라는 것이다. 시맨틱 CSS에서는 CSS가 HTML에 의존해 마크업은 다시 스타일링할 수 있지만 CSS는 재사용이 어렵다. 반대로 유틸리티 방식에서는 HTML이 CSS에 의존해 CSS는 재사용되지만 HTML은 다시 스타일링되지 않는다. 결합은 어느 쪽이든 존재하며 방향만 다르다는 논리다.

다만 이 논리는 리액트나 뷰처럼 로직·마크업·스타일을 한 파일에 모으는 컴포넌트 세계에서 성립한다. 그런 환경에서는 파일 단위의 분리가 이미 개발자 스스로 깨져 있기 때문이다. 반면 템플릿과 전통적 CSS로 서버에서 렌더링하는 프로젝트라면 파일별 분리는 여전히 의미가 있다. 결국 이것은 보편 법칙이 아니라 아키텍처에 따라 달라지는 선택의 문제라는 점을 저자는 강조한다.

시스템은 돕지만 당신을 구해주지 않는다

테일윈드가 일관성을 강제한다는 것도 흔한 장점으로 꼽힌다. 정해진 여백·색상 척도를 쓰다 보면 통일성이 생긴다는 것이다. 하지만 여기에는 임의값이라는 탈출구가 있다. w-[347px], text-[#1a2b3c], p-[5.5rem] 같은 값을 아무 경고 없이 쓸 수 있고, 같은 프로젝트에서 sky-400과 blue-400을 섞어도 막아주지 않는다. 일관성은 여전히 프레임워크가 아니라 개발자의 규율에 달려 있다. 네이밍의 비일관성도 지적된다. items-center와 justify-center, text-center, place-content-center는 이름만으로 차이를 알기 어렵고, border는 1px인데 border-2는 2px가 되는 식의 작은 마찰이 쌓인다.

더 미묘한 문제는 흔히 '테일윈드가 캐스케이드를 무시한다'고 표현되는 지점이다. 정확히는 leaky abstraction, 즉 새는 추상화의 사례다. 일반 CSS에서 어떤 선택자가 이기는지는 스타일시트 내 정의 순서로 결정되며, HTML의 클래스 나열 순서로 바뀌지 않는다. 그런데 테일윈드에서는 마크업의 클래스 순서를 바꿔도 승부를 뒤집을 수 없다. 최종 스타일시트에서 클래스가 생성되는 순서를 컴파일러가 통제하기 때문이다. class="mt-4 mt-0"이 이름 순서와 다르게 동작하는 것처럼, 마크업만 읽어서는 결과를 알 수 없다. 남는 선택지는 !important를 쓰거나 충돌하는 유틸리티를 피하는 것뿐이다. 단순함을 약속하지만 결국 내부 동작을 알아야 하는 구조인 셈이다.

학습의 착각과 디버깅 비용

저자가 특히 우려하는 지점은 CSS 경험이 적은 개발자에게 테일윈드가 '배우고 있다는 착각'을 심어준다는 점이다. pt-4는 머릿속에서 padding-top: 1rem으로 번역해야 하는데, 이 과정에서 얻는 것은 CSS 실력이 아니라 추상화에 대한 숙련도다. 미리 만들어진 클래스에 의존할수록 CSS 자체를 제대로 익히기 어렵고, 클래스 이름을 짓는 데 아낀 시간은 프레임워크를 효율적으로 쓰는 법을 배우는 데 다시 들어간다. 그래서 저자는 학생과 동료에게 테일윈드보다 CSS를 먼저 배우라고 권하며, 이미 숙련된 개발자라면 프레임워크 자체가 굳이 필요 없을 수도 있다고 본다.

흥미로운 사실 하나는 가독성을 회복하려 @apply로 클래스를 묶는 방식이 오히려 테일윈드의 철학과 충돌한다는 점이다. 웨이던 본인이 @apply는 '사실상 사람들을 속이려고 존재할 뿐'이며 처음부터 다시 만든다면 넣지 않았을 거라고 인정했다. @apply를 쓰지 않으면 HTML 속 클래스 수프를 감수해야 하고, 쓰면 철학과 모순된다. 디버깅 국면에서도 비용이 드러난다. 수많은 클래스로 만든 컴포넌트는 인스펙터에서 무엇이 이기고 무엇이 덮이는지 확인하기 위해 스크롤을 반복해야 한다. 에디터 확장이 작성 시점의 불편은 줄여주지만, 운영 환경 브라우저에서 디버깅할 때 클래스 수프는 그대로 남는다.

진짜 논쟁은 '네이티브 CSS 대 유틸리티 계층'

저자가 가장 신선하다고 보는 논쟁은 더 이상 '유틸리티냐 수작업 CSS냐'가 아니다. 네이티브 최신 CSS와 그 위에 얹은 유틸리티 계층 사이의 대결이다. 오늘날 플랫폼은 캐스케이드 레이어, @property, 컨테이너 쿼리, OKLCH 색상 같은 기능을 설치 없이 제공하는데, 아이러니하게도 테일윈드 자체가 바로 이 네이티브 기능들 위에 세워져 있다. 플랫폼이 이미 그만큼을 준다면 테일윈드에서 정말 필수적인 부분은 얼마나 남는가라는 불편한 질문이 생긴다. 물론 네이티브 CSS는 기능은 주지만 제약의 시스템, 마크업 옆에 스타일을 두는 코로케이션, 자동완성까지 주지는 않는다. 소규모나 서버 렌더링 프로젝트라면 최신 CSS만으로 충분하고, 컴포넌트 기반의 큰 제품에서 여러 사람이 손대는 상황이라면 테일윈드는 여전히 논거를 가진다. 보편적 승자는 없고 맥락이 있을 뿐이다. 결론은 명료하다. 선택하기 전에 CSS를 먼저 익히고, 그다음 지식을 가지고 판단하라는 것이다.