Tailwind, 솔직히 전 싫습니다: '수제 CSS' 장인의 고집스러운 변론

유틸리티 클래스 세상 속, 직접 만든 CSS에 대한 10년 차 개발자의 단호한 변론

네, 결국 해버렸습니다. 저를 ‘구닥다리’라 부르든, ‘원리주의자’라 칭하든, 시대의 흐름을 거스른다고 비난하든 상관없습니다. 저는 제 자리에서 아름답고, 사려 깊으며, 온전히 저만의 CSS를 만들어나갈 겁니다. 그 모든 순간을 즐기면서 말이죠.

Tailwind CSS가 엄청난 인기를 누리고 있다는 사실은 부인할 수 없습니다. 수많은 개발자가 프로젝트마다 이를 선택하고 있죠. 훌륭한 툴링, 방대한 커뮤니티, 그리고 진심으로 뛰어난 문서화까지. 이 모든 것을 존중합니다. 그럼에도 불구하고, 저는 Tailwind가 제 프로젝트 근처에도 오지 않기를 바랍니다.

지금부터 그 이유를 차근차근 풀어볼까 합니다.

펌킨 파이 문제

머릿속에서 떠나지 않는 비유가 하나 있습니다.

펌킨 파이를 처음부터 끝까지 직접 만든다는 것은 이런 의미입니다. 통 호박을 구워 속을 파내고 으깬 다음, 크림과 달걀, 그리고 따뜻한 향신료(육두구, 시나몬, 약간의 생강)를 넣어 커스터드를 만듭니다. 반죽도 손수 만들며 손끝으로 밀가루와 버터가 하나 되는 감각을 느끼고, 가장자리를 아름답게 주름 잡고, 미리 구워낸 파이 껍질에 속을 채워 넣습니다. 그리고 온 집안에 믿을 수 없는 향기가 퍼질 때까지 굽는 거죠.

Tailwind를 사용하는 것은 대략 이렇습니다. 슈퍼마켓에서 미리 만들어진 파이 껍질을 사고, 통조림 호박 퓨레를 딴 다음, 향신료 믹스를 저어 넣고 굽는 겁니다. 그리고 모든 사람에게 "내가 펌킨 파이를 처음부터 만들었다!"라고 말하는 것과 다름없습니다.

그리고 펌킨 파이에 대해서는 한 가지 특징이 있습니다. 사과 파이와는 달리, 숨길 것이 거의 없습니다. 속 재료는 통조림에서 나오고, 껍질은 봉지에서 나왔습니다. 썰거나 겹겹이 쌓는 과정도, 특별한 기술도 필요 없습니다. 사실상 오븐을 조작한 것뿐이죠. 물론 마지막엔 파이가 나오긴 할 겁니다. 맛도 괜찮겠죠. 사람들은 먹을 겁니다. 하지만 당신이 만든 게 아닙니다. 진짜로요. 그저 조립했을 뿐입니다.

이미 몇몇 분들은 반박의 댓글을 쓰고 계실 겁니다. "최종 사용자는 어떻게 만들었는지 신경 안 써요!" "효율성이 중요하죠!" "더 빨리 출시하고, 더 빠르게 반복해야죠!"

틀린 말은 아닙니다. 그런 점들도 분명 중요합니다. 하지만 그것만이 전부는 아니죠. 더 빨리 출시하려는 조급함 속에서, 우리는 중요한 무언가를 놓치고 있다고 생각합니다. 물론 속도와 효율성도 중요합니다. 빠르게 결과물을 내고 시장의 피드백을 받는 것도 현대 개발의 미덕이죠. 하지만 제가 실무에서 유틸리티 클래스 위주로 작업된 프로젝트를 맡아봤을 때, 단순히 '조립'된 코드에서는 예상치 못한 유지보수 비용이나 새로운 기능을 추가할 때의 진입 장벽이 명확히 보이곤 했습니다. 사용자에게 보이지 않는다고 해서 그 '만드는 과정'의 질까지 무시할 수는 없다는 게 제 생각입니다.

CSS는 공예입니다. 그렇게 대우해주세요.

CSS를 잘 작성하는 것은 기술입니다. 진정으로 힘들게 얻어지는, 제대로 숙련하는 데 수년이 걸리는 진짜배기 기술이죠.

캐스케이드를 이해하고, 커스텀 속성을 언제 왜 사용해야 하는지 아는 것. 전체 디자인에 일관되게 '숨 쉬는' 응집력 있는 간격 시스템을 구축하는 것. 자신의 역할을 충분히 수행하면서도 과도하지 않은 셀렉터를 작성하는 것. clamp()를 활용하여 브라우저가 반응형 작업을 처리하도록 맡기는 것. 디자인에 자연스럽게 녹아드는 듯한 애니메이션을 직접 만드는 것.

이것은 목공예나 요리와 같은 '공예'와 다름없습니다. 나무의 결을 이해하고 이음새를 능숙하게 다루는 가구 제작자와, 육각 렌치로 조립식 가구를 조립하는 사람의 차이죠. 둘 다 테이블을 만들어내지만, 그중 한 명만이 진정으로 테이블을 만든 겁니다.

Kevin Powell – 혹시 그의 유튜브 채널을 구독하지 않았다면, 이 글을 잠시 멈추고 그의 비디오를 몇 개 보고 오세요, 그리고 다시 돌아와서 이어서 읽으세요 – 은 수년 동안 바로 이 점을 정확하게 보여주고 있습니다. 그의 채널은 CSS를 제대로 배우면 무엇을 할 수 있는지에 대한 마스터클래스입니다. 그가 CSS를 즐겁게 보이게 만드는 이유는, CSS를 이해하면 정말로 즐겁기 때문입니다. 그는 우아하고, 반응형이며, 유지보수 가능한 레이아웃을 만들기 위해 유틸리티 클래스가 필요 없습니다. 그는 그저 언어를 사용할 뿐입니다.

그의 콘텐츠를 보면서 저를 가장 놀라게 하는 점은 바로 그 '확신'입니다. 툴링과 씨름하거나, 어떤 임의의 클래스 이름이 어떤 픽셀 값을 만들어내는지 기억하기 위해 문서를 뒤적거릴 필요가 없습니다. 그저 자신의 매체를 이해하는 개발자가 그것을 직접 다루는 모습뿐이죠.

그러한 확신은 오직 연습에서 나옵니다. 그리고 당신이 아웃소싱하는 것은 연습할 수 없습니다.

우리가 포기하는 것들

기본적으로 Tailwind를 사용하기 시작하면, 의식하든 못 하든 다음과 같은 일들이 벌어집니다.

CSS 학습을 멈추게 됩니다. 디자인 의도를 항상 유틸리티 클래스로 번역한다면, 직접 규칙을 작성하는 직관력을 개발할 기회가 없습니다. '내가 원하는 모습이 뭔지 안다'와 '그것을 구현할 CSS를 어떻게 작성해야 하는지 안다' 사이의 간극은 절대 좁혀지지 않죠. 특히 주니어 개발자들은 이 부분에서 어려움을 겪습니다. Tailwind로는 빠르게 결과물을 낼 수 있지만, 스태킹 컨텍스트 문제를 디버깅하거나 flexbox가 왜 원하는 대로 정렬되지 않는지 설명해보라고 하면 꼼짝 못 할 때가 많습니다. 제가 과거 한 프로젝트에서 복잡한 레이아웃 버그를 디버깅할 때, Tailwind 클래스로 덕지덕지 붙은 HTML 속에서 본질적인 문제를 찾아내는 데만 며칠을 허비한 경험도 있습니다. 이처럼 과도한 추상화는 단기적인 효율성 뒤에 장기적인 학습과 유지보수 부담을 숨길 수 있습니다.

HTML이 노이즈 덩어리가 됩니다. Tailwind로 작성된 컴포넌트를 자세히 보세요. 정말로 보세요. className="flex items-center justify-between px-4 py-2 text-sm font-medium text-gray-900 bg-white border border-gray-200 rounded-lg hover:bg-gray-50 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500" – 이건 버튼입니다. 의미론적 신호는 완전히 묻혀 버렸습니다. HTML은 더 이상 문서가 아니라, 엉뚱한 곳에 작성된 스타일시트나 다름없습니다.

모든 프로젝트가 똑같이 보입니다. Tailwind는 고유의 하우스 스타일을 가지고 있습니다. 기본 스케일과 팔레트가 정해져 있죠. 커스터마이징을 하더라도 뼈대는 같습니다. 저는 업계 여러 회사의 코드베이스를 검토했는데, Tailwind를 사용하는지 거의 즉시 알아챌 수 있습니다. 디자인이 나쁘다는 뜻이 아닙니다. 오히려 꽤 훌륭한 경우가 많죠. 하지만 어떤 '획일성'이 있습니다. 서로 교체해도 무방할 것 같은 품질이랄까요. 제품이 '생성된' 것이 아니라 '디자인된' 것처럼 느끼게 하는 개성, 특이성, 의도적인 기발함 같은 것들이 사라지는 경향이 있습니다.

추상화에 종속됩니다. Tailwind의 API가 변경되면 어떻게 될까요? class-variance-authority가 유행을 타지 않고 모두가 다음 유틸리티로 갈아타면 어떻게 될까요? 당신은 특정 도구의 특정 방식에 단단히 결합된 수만 라인의 코드를 작성한 셈입니다. 직접 작성한 CSS는 이런 문제가 없습니다. CSS는 그저 CSS일 뿐입니다. Tailwind가 등장하기 전부터 있었고, Tailwind가 사라진 후에도 여전히 존재할 겁니다.

"하지만 대규모 팀에서는요?"

이것이야말로 Tailwind를 옹호하는 진지한 주장이며, 저는 이 점을 존중합니다. 대규모 팀에서는 공유된 규칙이 중요합니다. 모두가 자신만의 스타일로 CSS를 작성한다면 혼란이 야기됩니다. 일관성 없는 간격, 충돌하는 이름 규칙, 특정성 전쟁, 아무도 감히 삭제하지 못하는 죽은 코드 등이 생겨나죠.

Tailwind는 여기서 실질적인 문제를 해결해줍니다. 팀들이 이를 선택하는 이유를 이해합니다.

하지만 일관성 없는 CSS에 대한 해결책은 CSS 작성을 멈추는 것이 아니라, 함께 더 나은 CSS를 작성하는 것입니다. 잘 관리된 디자인 토큰 시스템, 합리적인 컴포넌트 아키텍처, 팀이 실제로 따르는 스타일 가이드. 이러한 것들은 패키지를 설치하는 것보다 구축하기 어려운 일입니다. 맞습니다. 하지만 훨씬 더 나은 결과물을 만들어냅니다. 어떤 개발자든 text-slate-700이 무엇을 의미하는지 알 필요 없이 열어보고 이해할 수 있는 코드베이스를 만드는 것이죠.

좋은 CSS를 작성하는 기분

이런 기술적인 논의에서 충분히 다뤄지지 않는, 주관적이라서 무시당하기 쉬운 한 가지 감정에 대해 이야기하며 마무리하고 싶습니다.

CSS를 잘 작성하는 데는 특별한 기분이 있습니다. 컴포넌트를 처음부터 만들어 그것이 노래하듯이 완벽하게 작동할 때. grid와 사려 깊은 min() 및 max()를 사용하여 올바르게 설정했기 때문에, 뷰포트 크기에 따라 레이아웃이 우아하게 반응하는 것을 볼 때. 직접 만든 애니메이션이 이징, 타이밍 등 모든 면에서 정확하게 구현되는 것을 보며 '내가 이걸 만들었어'라고 느낄 때의 만족감.

이는 빵 껍질이 완벽하게 구워졌을 때 제빵사가 느끼는 기분과 같습니다. 두 개의 이음새가 빈틈없이 딱 맞아떨어졌을 때 목공예가가 느끼는 기분과도 같죠.

Tailwind는 아주 훌륭한 '미리 만들어진 파이 껍질'입니다. 하지만 저는 제 손으로 직접 만드는 법을 배우고 싶습니다.

CSS라는 언어에 다시 사랑에 빠지고 싶다면, Kevin Powell의 YouTube 채널부터 시작해 보세요. 그는 오늘날 활동하는 CSS 교육자 중 가장 인내심 있고, 철저하며, 진정으로 열정적인 사람입니다. 그의 콘텐츠를 보는 것은 당신을 더 나은 개발자로 만들어 줄 겁니다.

원문: https://dev.to/freshcaffeine/i-dont-like-tailwind-sorry-not-sorry-50b5 수집일: 2026-05-02 01:26:06