Tailwind CSS는 정말 훌륭합니다. 하지만 저는 이제 다른 걸 쓰려 합니다.

MMaximilian Schwarzmüller
컴퓨터/소프트웨어창업/스타트업자격증/평생교육AI/미래기술

Transcript

00:00:00요즘 제가 새로 시작한 프로젝트들 중 상당수, 아니 거의 대부분의 프로젝트에서
00:00:05사실 테일윈드(Tailwind)를 더 이상 사용하지 않기로 했습니다. 이제 그런 프로젝트에는 테일윈드를 쓰지 않고,
00:00:11당연히 섀드씨엔(Shadcn)도 쓰지 않죠. 여기에는 이유가 있습니다. 테일윈드가 나빠서가
00:00:18절대 아닙니다. 오히려 그 반대죠. 정말 놀라운 라이브러리라는 점을 분명히 말씀드리고 싶어요.
00:00:22사실 이 영상을 찍으면서 마음이 좀 불편하기도 합니다. 왜냐하면
00:00:27불과 몇 주 전만 해도 테일윈드가 겪고 있던 심각한 재정적 문제에 대해 이야기했었거든요.
00:00:32다행히 그 이후 상황이 훨씬 좋아졌습니다. 많은 새로운 스폰서들이 참여했고, 이제는
00:00:38재정적으로 훨씬 안정적인 상태라고 생각합니다. 당연히 테일윈드는 훌륭하니까요.
00:00:43그리고 그 프로젝트에는 정말 열정과 에너지를 다해 일하는 분들이 계십니다. 제 요점은
00:00:49테일윈드가 별로라거나 쓰지 말라고 설득하려는 게 아닙니다. 그저 이 채널을 통해
00:00:56제 생각과 의견, 그리고 제가 일하는 방식에 대한 인사이트를 나누고 싶을 뿐입니다. 흥미로운 주제가 될 것 같아서요.
00:01:01그럼 테일윈드가 훌륭하다고 생각하면서 왜 안 쓰는 걸까요? 자, 잠시 과거로 돌아가 보죠.
00:01:07AI 혁명이 일어나기 전, 혹은 AI의 코딩 실력이 지금처럼 좋지 않았던 몇 년 전만 해도
00:01:15저도 다른 개발자들처럼 테일윈드를 사용했습니다. 주로 한 가지 핵심적인 이유 때문이었죠.
00:01:21바로 코드를 빠르게 반복해서 수정하고 개선할 수 있게 해주었기 때문입니다. 전 피그마(Figma) 같은
00:01:28디자인 도구를 거의 사용하지 않았거든요. 제가 주로 혼자 작업하는 환경이라 더 그렇기도 했죠.
00:01:34혼자 프로젝트를 할 때는 굳이 그런 디자인 도구를 거칠 필요가 없었습니다. 저에게는
00:01:40코드에서 직접 디자인을 수정하는 게 항상 더 빨랐습니다. 코드를 바로 써 내려갈 수 있으니까요.
00:01:45테일윈드를 쓰면 DOM이나 JSX 코드 안에 클래스가 인라인으로 들어가 있어서,
00:01:50코드를 즉시 업데이트하고 스타일을 바꾸거나 여백을 조절해 보며 다양한 시도를 할 수 있었습니다.
00:01:57그건 정말 효율적인 흐름이었죠. 그게 제가, 그리고 아마 다른 많은 개발자가 테일윈드를 썼던 주된 이유일 겁니다.
00:02:04물론 꽤 많은, 어쩌면 대다수의 개발자에게는 또 다른 강력한 이유가 있을 텐데,
00:02:10바로 CSS를 싫어한다는 점이죠. 웹 개발자들 사이에서 CSS가 인기 없다는 건 저도 잘 압니다.
00:02:17이유는 이해합니다. 매우 복잡해 보일 수 있거든요. 수백, 수천 개의 속성과 값이 존재하니까요.
00:02:23네, 위압감이 느껴질 수 있습니다. 하지만 현대의 CSS는
00:02:31정말 많이 발전했습니다. 예전보다 훨씬 쉬워진 것들이 많아요. 플렉스박스(Flexbox)는 이제
00:02:37전혀 새로운 기술이 아니지만, 많은 것들을 단순하게 만들어줬죠. 색상을 추출하는 방식 같은
00:02:44다른 영역들도 예전보다 훨씬 쉬워졌습니다. 이제 CSS에는 상대적 색상(Relative colors) 기능도 있죠.
00:02:51참고로 제 아카데마인(Akatamine) 채널에 최신 브라우저와 CSS 기능들에 대한 영상을 몇 개 올렸습니다.
00:02:55색상이나 상대적 색상, 혹은 컨테이너 쿼리(Container queries) 같은 것들인데, 뷰포트가 아니라
00:03:01컴포넌트에 가용 가능한 공간에 따라 크기가 동적으로 조절되는 컴포넌트를 만들 때 정말 환상적입니다.
00:03:08이처럼 CSS는 비약적인 발전을 이뤘습니다. 사실 이런 최신 CSS 기능들을
00:03:14테일윈드와 함께 사용할 수도 있지만, 그냥 순수(Vanilla) CSS로 작성할 수도 있습니다.
00:03:23심지어 이제는 AI 덕분에 훨씬 더 쉬워졌죠. CSS 작성을 싫어하시더라도,
00:03:28특정 기능과 브라우저 지원 여부만 알고 있으면 충분합니다. AI에게 원하는 기능을 지목하고,
00:03:34관련 문서나 MDN 아티클을 참고 자료로 주면 AI가 코드를 대신 짜줍니다.
00:03:39그럼 굳이 왜 그렇게 하느냐고 물으시겠죠? 테일윈드도 이런 최신 기능을 다 지원하는데 말이죠.
00:03:45저에게는 한두 가지 정도의 이유가 있습니다.
00:03:51덜 중요한 이유는 테일윈드가 항상 최신 기능을 모두 즉각 지원하지는 않을 수 있다는 점이고,
00:03:58더 중요한 건 AI가 테일윈드의 모든 기능을 완벽히 알지 못한다는 점입니다. 테일윈드에는
00:04:05수많은 기능이 있지만, AI는 늘 쓰던 몇 가지 클래스만 사용하거나 심지어 옛날 문법을 쓰기도 해서
00:04:13특정 기능을 놓치게 되는 경우가 많습니다. 물론 이런 일은
00:04:17순수 CSS를 쓸 때도 일어날 수 있죠. AI에게 특정 기능을 쓰라고 지시하지 않으면
00:04:22그냥 넘어가 버릴 수 있습니다. 하지만 가장 중요한 CSS 기능 몇 가지만 익혀서
00:04:29AI에게 시키면 됩니다. 물론 테일윈드도 똑같이 AI에게 특정 기능을 쓰라고
00:04:34명령할 수 있다는 점은 저도 인정합니다. 다만 테일윈드 클래스 이름보다는 핵심 CSS 기능
00:04:40몇 개를 언급하는 게 더 쉬울 수도 있다는 거죠. 하지만 이것 역시 제 주된 요점은 아닙니다.
00:04:48제 진짜 요점은, 저는 항상 프로젝트에서 사용하는 외부 라이브러리 개수를 줄이려 노력해 왔다는 겁니다.
00:04:53이유는 두 가지입니다. 첫째로, 저는 교육 콘텐츠를 제작하기 때문에
00:05:01외부 라이브러리가 늘어나는 걸 경계하는 편입니다. 예를 들어 리액트 강의를 만드는데
00:05:07강의 중에 테일윈드를 사용했다고 칩시다. 그런데 테일윈드에 중대한 변경 사항(Breaking change)이 생기면,
00:05:12강의 코드의 많은 부분이 갑자기 작동하지 않게 되고 학생들로부터 수많은 질문을 받게 됩니다.
00:05:17정작 핵심 주제인 리액트는 변한 게 없는데 말이죠. 이건 저처럼 교육하는 사람에게만 해당되는 특수한 문제일 수도 있습니다.
00:05:23하지만 일반적인 웹사이트를 구축할 때도, 제 생각엔 타사 라이브러리를
00:05:29최소한으로 유지하는 게 합리적이고 좋은 아이디어라고 봅니다.
00:05:38물론 모든 라이브러리를 무조건 배제하라는 뜻은 아닙니다. 특정 라이브러리를 써야 할 좋은 이유들도 분명 있죠.
00:05:44예를 들어 서식 있는 텍스트 에디터(Rich text editor)가 필요한 웹사이트를 만든다면,
00:05:50팁탭(TipTap) 같은 라이브러리를 쓰는 게 훨씬 합리적입니다. 에디터를 직접 만드는 건 너무 힘드니까요.
00:05:54AI 덕분에 어느 정도 쉬워졌다고는 하지만, 여전히 수많은 예외 상황과
00:05:59직접 해결해야 할 문제들에 직면하게 될 겁니다. AI도 모든 걸 완벽하게 해내지는 못하니까요.
00:06:06직접 써보셨다면 아실 겁니다. 그래서 타사 라이브러리를 써야 할 이유들은 분명히 존재합니다.
00:06:11다만 스타일링은 앞서 설명했듯이 충분히 대체 가능한 영역이라는 게 제 생각입니다.
00:06:16다시 말씀드리지만 모든 분께 권하는 건 아닙니다. 하지만 저에게는 이 방식이 잘 맞았습니다.
00:06:21덕분에 라이브러리 하나를 줄일 수 있었죠. 저는 AI가 준 CSS 코드를 검토하고
00:06:28문제가 생겼을 때 순수 CSS로 직접 수정하는 것을 번거롭게 생각하지 않습니다.
00:06:37AI를 쓰다 보면 당연히 언젠가는 문제가 생기기 마련이니까요.
00:06:44하지만 저는 괜찮습니다. 만약 여러분이 CSS 코드를 보는 것조차 정말 싫어하신다면,
00:06:50당연히 이 방식은 선택지가 될 수 없겠죠. 하지만 저는 테일윈드 라이브러리를 걷어낼 수 있었고,
00:06:56직접 컴포넌트를 만들기 때문에 섀드씨엔 같은 것도 필요 없게 되었습니다. 섀드씨엔은
00:07:00전형적인 라이브러리는 아니지만 내부적으로 라딕스 UI(Radix UI)를 사용하는데,
00:07:08제가 알기로 현재 라딕스 UI의 유지보수 상태가 조금 불투명하다고 들었습니다. 여기서
00:07:16교육 콘텐츠가 아닌 일반적인 상황에서도 제가 라이브러리를 피하려는 진짜 이유가 나옵니다.
00:07:21프로젝트에 추가하는 모든 라이브러리는 유지보수가 중단되는 순간 부채가 될 수 있습니다.
00:07:29그 시점부터 보안 문제는 더 이상 해결되지 않고, 버그도 방치됩니다. 스타일링 버그도 마찬가지죠.
00:07:35새로운 기능도 추가되지 않을 겁니다. 새로운 CSS 기능이 나왔는데 테일윈드가 유지보수되지 않는다면
00:07:41(물론 지금은 잘 되고 있지만요), 여러분은 영영 그 기능을 쓰지 못할 수도 있습니다.
00:07:46실제로 테일윈드도 그런 위기에 처할 뻔한 적이 있었죠. 제가 언급했던 그 영상에서
00:07:52테일윈드 제작자가 쓴 글을 보면, 재정 문제를 해결하지 못하면 테일윈드가
00:07:58방치된 소프트웨어(Abandonware)가 될 수도 있다고 말했습니다. 조금 극단적인 표현이었을 수도 있고
00:08:03관심을 끌기 위한 전략이었을지도 모르지만요. 어쨌든 대부분의 타사 라이브러리가 가진 공통적인 문제는
00:08:11누가 작업하느냐에 따라 미래에 유지보수가 중단될 가능성이 늘 존재한다는 것입니다.
00:08:17그게 제가 다시 순수 CSS를 선호하게 된 이유이기도 합니다. 전에도 늘 써왔던 방식이니까요.
00:08:22다시 한번 강조하지만, 저는 테일윈드가 잘 되길 진심으로 바라고
00:08:28여전히 많은 프로젝트에서 테일윈드를 사용하고 있습니다. 테일윈드를 싫어하는 게 절대 아닙니다.
00:08:35단지 몇몇 프로젝트에서 테일윈드 없이 작업해보는 실험을 하고 있는 것뿐입니다.
00:08:41그게 테일윈드든 전혀 다른 무엇이든, 저는 AI 시대 이전부터도 그랬지만
00:08:46타사 라이브러리를 쓰기 전에 항상 두 번은 생각해보시길 권합니다. 라이브러리를 써야 할 좋은 이유는 많습니다.
00:08:53예를 들어 인증을 위한 Better Auth 같은 라이브러리는 정말 훌륭하죠. 저라도 꼭 쓸 겁니다.
00:08:57하지만 충분히 대체 가능한 라이브러리라면, 한 번쯤 다시 고민해 볼 가치가 있다고 생각합니다.
00:09:04it might be worth a second look or thought, I guess.

Key Takeaway

AI 기술의 발전과 현대 CSS의 강력한 기능을 활용하여 외부 라이브러리 의존성을 줄이고, 장기적인 유지보수 안정성을 위해 순수 CSS로 회귀하려는 개발 전략의 변화입니다.

Highlights

테일윈드(Tailwind)가 훌륭한 도구임에도 불구하고 최근 프로젝트에서 사용을 중단함

AI의 발전으로 인해 복잡한 CSS 작성이 쉬워졌으며, 더 이상 테일윈드의 인라인 클래스 방식에 의존할 필요가 없어짐

플렉스박스, 상대적 색상, 컨테이너 쿼리 등 현대 CSS 기능이 비약적으로 발전하여 순수 CSS만으로도 충분한 구현이 가능함

외부 라이브러리 의존도를 줄여 향후 발생할 수 있는 유지보수 중단 및 기술 부채 위험을 최소화하려는 전략

강의 제작자로서 라이브러리의 대규모 업데이트(Breaking changes)가 교육 콘텐츠의 유효성에 미치는 부정적 영향 고려

모든 라이브러리를 배제하는 것이 아니라, 스타일링처럼 직접 제어 가능한 영역에서 불필요한 도구를 걷어내는 과정

Timeline

테일윈드 사용 중단 선언과 배경

발표자는 최근 시작한 대부분의 프로젝트에서 테일윈드와 섀드씨엔(Shadcn)을 더 이상 사용하지 않기로 결정했다고 밝힙니다. 이는 테일윈드가 나쁜 라이브러리여서가 아니라, 오히려 그 우수성을 인정하면서도 본인의 작업 방식에 변화가 생겼기 때문입니다. 최근 테일윈드가 겪었던 재정적 위기가 해소되어 안정화되었다는 점을 언급하며 제작자들에 대한 존중을 표합니다. 이 영상의 목적은 특정 도구를 비난하는 것이 아니라, 개발자로서 변화하는 생각과 인사이트를 공유하는 데 있습니다. 개발 방식의 전환을 고민하는 이들에게 흥미로운 화두를 던지며 시작합니다.

과거 테일윈드를 선택했던 이유와 디자인 흐름

AI가 코딩에 본격적으로 활용되기 전에는 빠른 프로토타이핑을 위해 테일윈드가 필수적이었습니다. 발표자는 피그마와 같은 별도의 디자인 도구를 쓰지 않고 코드에서 즉시 디자인을 수정하는 방식을 선호했습니다. 테일윈드의 인라인 클래스 방식은 JSX 코드 내에서 즉각적으로 스타일과 여백을 조절할 수 있게 해주어 작업 효율을 극대화했습니다. 혼자 작업하는 환경에서 디자인과 개발의 경계를 허무는 데 테일윈드는 최고의 도구였습니다. 이러한 생산성 덕분에 오랫동안 테일윈드를 주력 도구로 활용해 왔음을 설명합니다.

현대 CSS의 발전과 AI의 역할

많은 개발자가 CSS의 복잡성 때문에 테일윈드를 선택하지만, 현대의 CSS는 플렉스박스 도입 이후 비약적으로 발전했습니다. 최근에는 상대적 색상(Relative colors)이나 컨테이너 쿼리(Container queries) 같은 강력한 기능들이 브라우저에 기본 탑재되었습니다. 이제는 AI에게 MDN 문서나 특정 기능을 지시하는 것만으로도 복잡한 CSS 코드를 손쉽게 생성할 수 있습니다. 뷰포트가 아닌 컴포넌트 크기에 반응하는 디자인을 순수 CSS로 작성하는 것이 과거보다 훨씬 단순해졌습니다. 결과적으로 AI의 도움을 받으면 굳이 테일윈드라는 추상화 레이어를 거치지 않아도 스타일링이 가능해진 환경입니다.

외부 라이브러리 최소화의 중요성

발표자가 순수 CSS로 돌아간 가장 결정적인 이유는 프로젝트 내 외부 라이브러리 개수를 줄이기 위함입니다. 특히 교육 콘텐츠 제작자로서 라이브러리의 버전 업데이트나 변경 사항이 발생하면 기존 강의 자료 전체가 무용지물이 될 위험이 큽니다. 리액트 자체는 변하지 않았는데 테일윈드의 문법 변화로 인해 학생들에게 혼란을 주는 상황을 경계하는 것입니다. 일반적인 웹사이트 개발 시에도 타사 라이브러리를 최소화하는 것이 소프트웨어 아키텍처 측면에서 합리적이라고 주장합니다. 이는 도구에 휘둘리지 않고 핵심 기술에 집중하려는 개발 철학을 보여줍니다.

기술 부채와 라이브러리 유지보수의 불확실성

모든 라이브러리를 거부하는 것은 아니며, 에디터 기능을 위한 팁탭(TipTap)처럼 직접 구현이 힘든 영역은 라이브러리 사용이 현명합니다. 하지만 스타일링은 충분히 대체 가능한 영역이기에 직접 제어권을 갖는 것이 유리합니다. 섀드씨엔이 의존하는 라딕스 UI(Radix UI)의 불투명한 유지보수 상태를 예로 들며, 외부 도구가 방치될 경우 겪게 될 위험을 경고합니다. 라이브러리가 유지보수 중단(Abandonware) 상태가 되면 보안 취약점과 버그 수정이 불가능해져 결국 프로젝트의 거대한 부채가 됩니다. 따라서 스타일링처럼 핵심적인 부분은 외부 의존성을 낮추는 것이 장기적으로 안전합니다.

결론: 유연한 도구 선택과 신중한 고민

테일윈드가 과거에 재정적 문제로 방치될 뻔했던 사례를 언급하며, 어떤 훌륭한 도구라도 미래의 연속성을 보장할 수 없음을 강조합니다. 발표자는 여전히 테일윈드를 사랑하며 많은 프로젝트에서 사용 중이지만, 일부 프로젝트를 통해 의존성 없는 작업 방식을 실험하고 있습니다. 인증을 위한 Better Auth처럼 꼭 필요한 라이브러리는 적극 활용하되, 대체 가능한 경우에는 다시 한번 고민해 볼 것을 권장합니다. 기술 선택에 있어 맹목적인 추종보다는 프로젝트의 성격과 유지보수 가능성을 따지는 태도가 필요합니다. 마지막으로 충분히 대체 가능한 라이브러리라면 순수 기술로의 회귀를 고려해보라는 조언으로 마무리합니다.

Community Posts

View all posts