테일윈드를 떠나는 개발자들 — 다시 CSS 구조화로 돌아가는 이유

몇 년 전만 해도 “Tailwind 안 쓰면 시대에 뒤처진다"는 분위기가 있었습니다. 그런데 2026년에 들어서면서 분위기가 미묘하게 바뀌고 있습니다. 시니어 개발자들 사이에서 “다시 클래식한 CSS 방법론으로 돌아가고 있다"는 고백이 심심치 않게 나오고 있거든요. 왜일까요?

한때는 모두가 환호했던 Tailwind

Tailwind CSS는 등장 이후 프론트엔드 생태계를 빠르게 장악했습니다. flex items-center justify-between p-4 rounded-lg shadow-md처럼 클래스만 나열하면 디자인이 완성되는 직관성, 그리고 CSS 파일을 따로 관리하지 않아도 된다는 편리함이 결정적이었죠.

특히 스타트업과 1인 개발자에게는 축복이었습니다. 디자이너 없이도 적당히 예쁜 UI를 만들 수 있었고, 클래스 이름을 고민할 필요도 없었으니까요. Next.js, Remix 같은 메이저 프레임워크가 기본 템플릿에 Tailwind를 넣으면서 사실상 표준이 됐습니다.

그런데 왜 이탈이 시작됐을까

문제는 프로젝트가 커지면서 드러나기 시작했습니다. 처음엔 깔끔해 보였던 코드가, 6개월 뒤에는 이런 모습이 되어 있는 거죠.

<div className="flex flex-col md:flex-row items-center md:items-start justify-between gap-4 md:gap-8 p-4 md:p-6 lg:p-8 rounded-lg md:rounded-xl bg-white dark:bg-gray-800 shadow-sm hover:shadow-md transition-all duration-200">

이걸 한 컴포넌트마다 반복해서 쓰고 있다는 사실을 깨닫는 순간이 옵니다. 개발자들이 호소하는 핵심 불만은 크게 세 가지입니다.

첫째, 가독성 붕괴입니다. HTML이 클래스 이름으로 도배되면서 마크업의 의미를 읽기가 어려워집니다. 둘째, 재사용성의 함정입니다. @apply로 묶으면 결국 CSS 파일로 돌아가는데, 그럴 거면 처음부터 CSS를 쓰는 게 낫지 않냐는 회의가 들기 시작합니다. 셋째, 디자인 시스템과의 충돌입니다. 디자인 토큰을 체계적으로 관리하려면 Tailwind의 설정 파일을 깊이 파야 하는데, 그 학습 비용이 만만치 않습니다.

다시 떠오르는 정공법들

흥미로운 건, 떠나는 개발자들이 “그냥 인라인 스타일 쓰자"가 아니라 기존의 CSS 방법론으로 회귀하고 있다는 점입니다.

BEM(Block-Element-Modifier) 같은 네이밍 컨벤션은 여전히 견고합니다. .card, .card__title, .card--featured처럼 이름만 봐도 구조가 읽히죠. CSS Modules는 컴포넌트 단위로 스타일을 캡슐화해 충돌을 막아주고, 최근에는 Vanilla Extract나 PandaCSS처럼 타입 안전한 CSS-in-JS 도구도 주목받고 있습니다.

여기에 네이티브 CSS의 진화도 한몫합니다. CSS Nesting, Container Queries, :has() 셀렉터, 그리고 CSS Variables가 모든 브라우저에서 안정적으로 지원되면서, “이제 굳이 프레임워크 안 써도 되는 거 아냐?“라는 목소리가 커지고 있습니다. 디자인 토큰을 CSS 커스텀 프로퍼티로 관리하면 다크모드 전환부터 테마 시스템까지 깔끔하게 처리할 수 있습니다.

그래서 Tailwind는 끝났나

결론부터 말하면 그렇지 않습니다. Tailwind는 여전히 빠른 프로토타이핑과 소규모 팀에서는 최고의 선택지입니다. 디자인 시스템이 확실히 잡혀 있고 컴포넌트 라이브러리(shadcn/ui 같은)와 함께 쓰면 폭발적인 생산성을 보여주죠.

다만 개발자들이 깨달은 건 “도구는 맥락에 따라 다르다"는 진리입니다. 50명 규모의 엔지니어링 조직이 5년 운영할 제품을 만든다면, 유틸리티 클래스의 무한 나열보다 잘 설계된 CSS 아키텍처가 결국 이긴다는 거죠. Tailwind를 떠난다기보다, 도구의 한계를 인식하고 적재적소에 쓰자는 성숙한 논의가 시작된 셈입니다.

마무리하며

프론트엔드 생태계는 항상 진자 운동을 합니다. CSS → CSS-in-JS → Utility-first → 다시 구조화된 CSS로. 이번 회귀의 본질은 “Tailwind가 나쁘다"가 아니라, 우리가 코드를 어떻게 오래 유지할 것인가라는 근본적인 질문입니다.

여러분의 프로젝트는 지금 어느 지점에 서 있나요? 빠른 출시가 우선인 단계인가요, 아니면 장기적 유지보수를 고민할 때인가요? 도구는 답을 주지 않습니다. 답은 결국 우리가 만드는 제품의 수명과 팀의 규모에서 나옵니다.