October 13, 2022

Tailwind가 단지 인라인 CSS가 아닌 이유

원문: The Pros and Cons of TailwindCSS

Tailwind는 최근 프런트엔드 생태계에서 그 어떤 CSS 프레임워크보다 빠르게 떠오르는 프레임워크가 되었습니다. 그럼에도 불구하고, Tailwind를 반대하는 사람들도 존재합니다.

Tailwind의 전제는 코드를 스타일링하기 위해서 (20년 동안 일반적인 관행이었던) 일련의 선택자와 맞춤형 클래스를 만드는 것 대신에, 각각 한 가지 작업을 수행하는 대규모 단일 목적 유틸리티 클래스를 사용합니다. 본질적으로 거의 모든 스타일을 HTML, React 또는 Vue 같은 프런트엔드 영역 코드에 바로 추가할 수 있습니다.

전통적인 클래스와 선택자를 통한 스타일링은 아래와 같습니다.

<div class="card-body">
  <h1 class="card-title pricing-card-title">$29 <span class="text-muted">/ mo</span></h1>
  <ul class="list-unstyled">
    <li>30 users</li>
    <li>15 GB</li>
  </ul>
  <button type="button" class="btn btn-primary">Buy</button>
</div>

Tailwind를 이용한 스타일링은 아래와 같습니다.

<div class="mt-12 space-y-4 sm:mt-16 sm:space-y-0 sm:grid sm:grid-cols-2 sm:gap-6 lg:max-w-4xl lg:mx-auto xl:max-w-none xl:mx-0 xl:grid-cols-4 border border-gray-500">
  <h1 class="text-lg leading-6 font-medium text-gray-900">$20 <span class="text-sm">/ mo</span></h1>
  <ul class="mt-6 space-y-4">
    <li class="flex space-x-3 text-sm text-gray-500">30 users</li>
    <li class="flex space-x-3 text-sm text-gray-500">15 GB</li>
  </ul>
  <button type="button" class="mt-8 block w-full bg-gray-800 border border-gray-800 rounded-md py-2 text-sm font-semibold text-white text-center hover:bg-gray-900">
  Buy</button>
</div>

Tailwind를 사용해 본 적이 없다면 첫 번째 반응은 “이 복잡한 클래스 리스트들이 과연 나의 콘텐츠를 더 낫게 스타일링해줄 수 있을까?”일 것입니다.

• 이상해 보입니다.
• 클래스 이름 중 일부는 너무 깁니다.
• 많은 반복이 있습니다. (페이지에 이러한 블록이 여러 개 있다고 상상해보세요.)
• 많은 경우, 이것은 엘리먼트에 style 태그와 함께 인라인 스타일을 사용하는 것과 매우 유사해 보이고, 유사하게 작동합니다.

이러한 명백한 단점에도 불구하고, Tailwind가 제공하는 접근 방식에는 많은 이점이 있습니다. 그리고 장담하건대, Tailwind는 단순히 인라인 스타일링하는 것 이상을 제공합니다.

다음은 Tailwind CSS를 사용하는 주된 이점입니다.

1. 스타일 클래스의 이름을 더 이상 생각할 필요가 없습니다.

기존의 스타일링 방법을 사용하려면 어떤 유형의 콘텐츠와 스타일을 가질 수 있는지 고려하고, 이러한 스타일을 적용할 수 있도록 클래스를 만들어야 합니다. 또는 대부분의 경우 작동하는 기본 스타일이 있지만 때때로 재정의해야 할 수도 있습니다. 이는 상당히 압도적이며, 다음과 같은 질문이 생길 수도 있습니다.

• 이 클래스를 한 번 이상 사용할 것인가요?
• 이 클래스를 다시 사용한다면, 어떤 면에서 조금 달라져야 하나요?
• 어떠한 명명 규칙을 사용해야 하나요?
• 외관이나 기능 또는 다른 것들을 따서 이름을 붙여야 할까요?
• CSS의 이름을 지정하고 구성하기 위해 어떤 규칙을 사용해야 할까요?

이름을 짓는 것은 그렇게 어렵게 들리지 않을 수 있지만, 위의 모든 것을 고려한다면 시간이 지남에 따라 팀원들 간에 일관성을 유지하려고 노력해야 합니다. 사실 그것은 매우 어렵습니다! 엄청난 양의 인지 부하가 발생하며, 이는 종종 팀원들이 가장 좋은 이름에 대해 논쟁할 때, “바이크 쉐딩(bikeshedding)“으로 이어집니다. (역자 주 : “bikeshedding”은 중요한 요소들을 미뤄둔 채, 덜 중요한 것들에 대해 깊이 의논하고 시간 보내는 것을 의미합니다.)

Tailwind CSS를 사용할 때는 문서에 지정된 유틸리티 클래스를 적용하기만 하면 되므로 클래스 이름을 지정할 필요가 훨씬 줄어듭니다. 일단 Tailwind를 사용하기만 하면 대부분의 클래스 이름은 상당히 직관적이게 되고, 상대적으로 덜 사용된 것들은 Tailwind의 우수한 문서에서 쉽게 찾을 수 있습니다.

2. CSS 파일/스타일 블록과 HTML 코드 사이의 컨텍스트 전환이 훨씬 적습니다.

일반적으로 핵심 웹 페이지 구조를 작성할 때 HTML과 JS를 작성하고, 다음과 같은 생각을 하게 됩니다.

• “여기에 약간의 여백만 추가하면 됩니다.”
• “이 텍스트는 더 커야 합니다.”
• “이 새로운 유형의 엘리먼트에 대한 클래스를 만들어야 합니다.”

이렇게 할 때마다 CSS를 사용하여 IDE의 다른 탭으로 전환하거나 <style> 블록이 있는 문서 상단으로 스크롤해야 할 수 있습니다.

이 작업을 수행할 때마다 컨텍스트 전환이 발생하고, CSS를 변경한 다음 다시 문서로 돌아가면서 이동하는 데 시간을 보내야 합니다.

Tailwind CSS를 사용할 때, 대부분의 경우 클래스 속성의 CSS에서 인라인으로 스타일링하기 때문에 코드의 다른 섹션으로 전환할 필요가 없습니다. 그렇게 하면 훨씬 빨라집니다. 이미 경험이 풍부해서 전자의 방식의 작업이 익숙하다면, 문서를 전환하고 위치를 찾는 데 얼마나 많은 시간을 소비하는지 인식하지 못할 수도 있지만 이것은 CSS와 함께 작업하는 유틸리티 우선 접근 방식에 엄청난 이점이 됩니다.

3. 미디어 쿼리, 의사 클래스 및 자식 선택자와 함께 변형(variant)을 사용할 수 있습니다.

인라인 스타일은 미디어 쿼리를 사용할 수 없습니다. 예를 들어, 한 엘리먼트가 작은 화면에서 한 방향으로 표시되고 큰 화면에서 다른 방향으로 표시되기를 원하는 경우, 일반적으로 CSS의 다른 부분에 다른 선택자 세트를 만들어야 합니다. 스타일 시트의 여러 섹션을 찾아서 편집해야 하므로 이 작업은 상당히 번거로울 수 있습니다.

다행히도 Tailwind는 각 변형(variant)에 대해서 다른 선택자를 만들지 않고도 이런 모든 종류의 스타일링을 인라인으로 수행할 수 있도록 해줍니다. 다음은 몇 가지 예시입니다.

• 사이즈 클래스 (sm, md, lg, xl)
• hover
• focus
• active
• 다크(dark) 모드 (부모 클래스 또는 미디어 쿼리를 통한)
• first, last, odd, even
• required, invalid, disabled와 같은 폼(form) 상태
• 하위 엘리먼트 또는 인접 엘리먼트의 항목을 수정하기 위한 그룹화 및 피어링
• 의사 엘리먼트를 수정하기 위한 before, afterEach
• placeholder (채워지지 않은 폼 엘리먼트의 경우)
• 목록의 글머리 기호 스타일을 지정하는 마커

수많은 변형(variant)이 있고, 이러한 변형(variant)들은 항상 추가되고 있습니다. 가이드 문서에서 예제와 함께 전체 목록을 확인할 수 있습니다.

4. Tailwind는 일관성 있는 디자인 시스템을 적용하도록 돕습니다. (너무 제한적이지 않도록)

크고 복잡한 사이트를 디자인하려고 시도하거나, 회사에서 사용할 수 있는 디자인 시스템을 만든 적이 있는 경우, 오랜 시간에 걸쳐 팀 또는 여러 페이지에 디자인 결정을 적용하는 것이 까다로울 수 있다는 것을 알 수 있습니다.

Tailwind는 모든 것을 가능한 값의 무한한 범위로 설정하지 않고, 특정 값만 허용하도록 Tailwind를 설정할 수 있기 때문에 이 작업에 정말 도움이 됩니다.

• 색상 팔레트는 음영 사이의 적절한 단계로 정의됩니다.
• 간격(Spacing) 값은 특정 간격에만 허용되므로 간격이 일정해 보입니다. 가능한 모든 값이 아닌 12, 14, 16, 20 등 중에서 선택해야 하므로 매우 유사한 요소 사이에 약간 다른 간격이 생길 가능성이 적습니다.
• 사용할 글꼴, 두께, 폰트 크기 세트가 있습니다.
• 너비 중단점(breakpoints)은 반응형 디자인에 미리 정의되어 있으므로 중단점이 적습니다. (쉽게 추가할 수 있습니다.)

물론 필요에 따라 이러한 값을 사용자 정의할 수 있고, 그렇게 할 것입니다. 하지만 요점은 “음, 여기에 18픽셀 또는 19픽셀의 간격이 필요한가요?” 또는 “이 색상이 #1122FF 또는 #1128F0여야 하나요?”와 같은 생각을 할 필요가 없다는 것입니다. 선택할 수 있는 정의된 값 목록이 있으므로, 이를 통해 스타일을 더욱 간단하게 만들고 일관성을 더 쉽게 유지할 수 있습니다.

5. 프로덕션 CSS에는 실제로 사용하는 스타일만 존재합니다.

만약 여러분이 거대한 스타일 시트를 유지한 적이 있다면, 시간이 지남에 따라, 여러분은 결국 많은 양의 쓸데없는 것들을 갖게 된다는 것을 알 수 있습니다. 일부 스타일은 많이 사용될 것으로 예상되어 삽입되었지만, 적용된 코드는 제때 코드 베이스에 존재하지 않을 수도 있습니다. 그런 일이 발생하면 해당 클래스들과 엘리먼트들을 찾고 사용되지 않는 스타일을 제거하는 것은 많은 작업이 될 수 있습니다. 혹은 더 나쁜 것은, 무언가 잘못될까 봐 두려워 그것들을 그냥 거기 놔두곤 합니다.

Tailwind에서는 빌드 프로세스를 사용하여 CSS를 자동으로 생성하므로 스타일시트는 실제로 코드에 있는 유틸리티 클래스만 포함합니다. 이것은 소규모 사이트의 경우, CSS가 꽤 작고 컴팩트하게 유지된다는 것을 의미합니다. 더 큰 사이트의 경우에도 여전히 합리적입니다.

6. 유틸리티 클래스는 잘 캐시 됩니다.

인라인 스타일은 HTML 콘텐츠와 함께 다시 로드되어야 하므로 실제로 캐시 될 수 없습니다. CSS 파일은 더 적극적으로 캐시 되어, 페이지 로딩 속도를 향상할 수 있습니다.

이것의 단점은 복잡함을 스타일 시트로 추출하는 큰 클래스를 만드는 것과 비교하여, 내용에 있는 모든 유틸리티 클래스로 인해 Tailwind에서 실제 HTML이 더 커질 수 있다는 것입니다. 그러나 유틸리티 클래스의 반복적인 특성은 웹 페이지를 전송하는 데 사용되는 전송 계층에서 상당히 잘 압축되기 때문에 결과적으로 데이터 전송 속도와 페이지 로드 성능의 차이는 완전히 무시할 수 있기 때문에 이는 꽤 좋은 절충안이 됩니다.

7. 오버라이드(override)하지 않고 스타일을 쉽게 변경할 수 있습니다.

유틸리티 전용 접근 방식을 사용하면 CSS 우선순위 때문에 발생하는 문제나, 복잡하고 성가신 스타일 충돌에 대해 거의 걱정할 필요가 없습니다. 중첩된 선택자가 있는 스타일의 큰 계층 구조가 있는 경우, 변경하기 위해 !important를 사용해야 하는 경우가 있습니다. 이 방법은 좋은 방법은 아닙니다. 나중에 다시 오버라이딩 할 수 없기 때문입니다.

Tailwind를 사용하면 일반적으로 스타일링하고 있는 대상 엘리먼트에 직접 스타일이 적용되며, 변경하려는 항목이 있으면 변경하기만 하면 됩니다. 아래의 예시와 같이 체인의 어딘가에서 더 높은 우선순위의 스타일을 찾고 싸울 필요가 없습니다.

form.master input {
  padding: 8px;
}

/* 스타일 시트의 좀 더 나중에 */

/* 위의 클래스가 더 높은 특정성을 가지므로 이 스타일은 "master" 클래스가 있는 form에는 적용되지 않습니다.*/
form input {
  padding: 4px;
}

8. 컴포넌트에 대한 추출을 통해 코드 DRY(Don’t Repeat Yourself)를 유지하는 데 도움이 됩니다.

Tailwind의 반복적인 성격은 어떤가요? 예를 들어, 스타일 된 목록 아이템이 여러 개 있다면 매번 많은 클래스 목록을 적용해야 할까요?

그럴 수도 있고 아닐 수도 있습니다. 큰 문서를 완전히 직접 코딩하는 경우에는 확실히 지루할 수 있습니다. 하지만 이럴 때 최신 IDE를 사용하면 어쨌든 모든 문서를 동시에 선택하고 편집할 수 있습니다. (다중 커서 편집은 절대적인 신의 선물입니다) 그러나 대부분의 실제 웹 사이트에서 문서의 매우 반복적인 부분은 일반적으로 루프를 통해 프로그래밍 방식으로 생성됩니다. 따라서 이러한 코드는 한 번만 작성하면 됩니다.

코드 블록을 재사용해야 할 경우 프레임워크의 재사용 가능한 컴포넌트(React, Vue, 또는 Blade)에 이를 추출하는 것이 더 합리적입니다. 이 방법을 사용하면 관련 구조적 HTML을 모든 스타일과 결합할 수 있으며, 많은 페이지에 나타날 수 있는 이 코드 조각에 대한 하나의 원천 소스를 가질 수 있습니다.

마지막으로, 컴포넌트로 추출하는 것이 불가능하다면, Tailwind의 @apply 기능을 사용할 수 있습니다. 이 기능을 사용하면 여러 Tailwind 클래스를 하나의 사용자 정의 클래스로 결합하고 Tailwind의 이점을 기존 CSS 접근 방식과 결합할 수 있습니다. 이 기능은 자주 사용되지만, 컴포넌트에 추출하는데 필요한 복잡성이 없을 수 있는 버튼이나 폼 엘리먼트에 매우 유용할 수 있습니다.

9. Tailwind 스타일링은 유지 관리하기 훨씬 쉽습니다.

이것은 Tailwind의 가장 큰 이점일 수 있습니다. Tailwind를 사용하는 프로젝트가 있는 경우 스타일을 변경하는 것은 대부분 매우 간단합니다. 특히 스타일링 된 컴포넌트를 많이 사용하는 경우엔 더욱 그렇습니다. 컴포넌트로 들어가서 클래스를 변경하거나, 조정하려는 코드의 클래스를 변경하기만 하면 됩니다.

더욱 일반적인 CSS 환경에서는 큰 CSS 파일을 변경해야 할 수 있으며, 이렇게 변경할 때 해당 스타일이 정확히 어디에 사용되는지 명확하지 않으므로 변경 사항을 테스트하고 검증하는 것은 상당히 어렵고 분명하지 않은 연쇄 효과를 가져올 수 있습니다. 유틸리티 우선 접근 방식을 사용하면 지저분한 CSS 파일을 파헤칠 필요가 없으며, 무언가 문제를 일으키거나 충돌을 발생하는 걱정을 줄일 수 있습니다.

Tailwind의 단점

입에 거품을 물고 있는 Tailwind의 광팬처럼 보이지 않기 위해, Tailwind에 몇 가지 단점이 있다는 것을 인정하고자 합니다. 모든 시나리오에 항상 완벽한 것은 아닙니다. 다음은 몇 가지 주요한 우려 사항입니다.

1. 빌드 단계가 필요합니다.

원래 Tailwind는 가져올 수 있는 스타일 시트에 불과했지만, 최신 버전에서는 CSS를 생성하기 위해 빌드 프로세스를 실행해야 합니다. 이것은 웹 페이지를 만드는 과정에 약간의 추가 오버헤드가 있음을 의미합니다. 만약 프런트엔드 빌드 프로세스를 잘 모르는 경우, 새로운 개발자에게 엄청난 복잡성을 가중 시킬 수 있습니다. 다행히 이 프로세스는 이미 많은 프런트엔드 프레임워크에서 사용하는 빌드 프로세스에 잘 통합되어 있으며, Tailwind CLI를 사용하면 매우 쉽게 사용할 수 있습니다.

2. 설치 및 학습 곡선

만약 이미 CSS를 알고 있다면, Tailwind도 충분히 배울 수 있습니다. 그것을 설치하고, 여러분이 원하는 방식으로 그것을 구성하는 방법을 알아내야 합니다. (기본값만 받아들일 수 없다면) 그리고 규칙과 클래스 이름, Tailwind의 다른 부분들이 어떻게 작동하는지 배워야 합니다.

다행히 Tailwind에는 필요한 것을 쉽게 찾을 수 있는 훌륭한 문서가 있으며, 사용할 수 있는 많고 좋은 튜토리얼과 예제가 있습니다. 보통 며칠간의 학습과 실습이 능숙해지는 데에 필요한 전부입니다.

3. 더 큰 HTML 크기

유틸리티 우선 접근 방식은 종종 HTML에 많은 클래스를 추가하는 것을 포함하기 때문에, HTML의 다운로드 크기가 증가할 수 있습니다. 이것의 장점은 이러한 유형의 추가 반복 데이터는 매우 쉽게 압축되는 경향이 있기 때문에 사용자 경험의 순 차이는 크지 않을 수 있습니다. Algolia의 Sarah Dayan은 그녀의 강연인 “유틸리티 우선 CSS에 대한 방어(Defense of Utility-First CSS)”에서 이 문제를 다루었습니다. 이 강연에서 그녀는 유틸리티 우선 접근 방식과 기존 페이지에서 사용하는 컴포넌트 접근법의 차이점을 시연했으며, 압축되지 않은 크기가 유틸리티 우선 방식일 때 약 20% 더 크다는 것을 발견했습니다. 하지만 일단 압축되면 그 차이는 단지 몇 퍼센트에 불과했습니다.

또한 CSS 문서는 컴포넌트 접근 방식으로 크기가 더 커졌고, 브라우저가 탐색하고 적용하기 위해 더 많은 처리가 필요한 더 복잡한 문서가 되었습니다.

그러나 매우 최적화된 콘텐츠를 만들려면 이름이 매우 짧은 맞춤형 클래스를 사용하는 것이 잠재적으로 더 효율적일 수 있습니다.

4. Tailwind가 모든 것을 할 수는 없습니다.

Tailwind의 기능은 계속 증가하고 있지만, 일부 CSS 속성과 고급 기술을 구사하는 데는 한계가 있습니다. 즉, 작업을 완료하기 위해 때때로 인라인 스타일을 추가하거나 Tailwind와 함께 사용자 정의 클래스를 만들어야 할 수 있습니다. 끔찍한가요? 그렇지는 않지만, Tailwind가 모든 필요를 충족시키는 만병통치약은 아니라는 것을 의미합니다.

5. CSS를 제대로 배우는 것을 막을 수 있습니다.

만약 CSS가 매우 처음이라면, Tailwind를 사용하는 것을 추천하지 않습니다. 왜냐하면 먼저 CSS가 어떻게 작동하는지를 배우고 이해해야 하기 때문입니다.

• 대부분의 선택자 (id, class, element, spaces, adjacent element 등)
• CSS 우선 순위 - 어떤 순서로 CSS가 적용되는지?
• 특수성 - 브라우저가 어떤 CSS를 적용하고 (어떤 CSS가 적용되지 않는지) 계산하는 방법
• 일반적이고 자주 사용되는 CSS 속성의 작동 방식
• CSS 박스 모델의 작동 방식
• flexbox의 작동 원리와 사용 방법
• CSS 그리드의 기본 작동 방식

이 모든 것을 마스터하는 데 몇 년이 걸릴 수 있으므로 Tailwind와 같은 프레임워크를 바로 사용하기 시작하면 웹 디자인을 능숙하게 수행하는 능력에 영향을 미치고 일자리를 찾는 데 부정적인 영향을 미칠 수 있는 몇 가지 큰 지식 격차가 발생할 수 있습니다. CSS를 이미 이해하고 있다면 Tailwind를 사용하는 것은 편리하지만, CSS에 대한 부족한 이해를 보완하기 위해 Tailwind에 의존하는 것은 좋지 않은 생각입니다.

6. 콘텐츠와 스타일 간의 관심사 분리를 줄입니다.

CSS의 원래 철학은 문서 구조와 내용(HTML)에서 스타일(CSS)을 분리해야 한다는 것이었습니다. 이렇게 하면 디자이너는 HTML을 건드리지 않고 내용에 영향을 주지 않으면서 문서의 스타일을 쉽게 바꿀 수 있습니다.

이에 대한 표준 예는 CSS Zen Garden로, 서드파티 스타일 시트 덕분에 근본적으로 다양한 모양을 가진 웹사이트입니다.

Tailwind의 창시자인 Adam Wathan은 관심사의 분리가 현실 세계에서는 성립하지 않는 주장인지 설명하는 글을 작성했습니다. 문제는 복잡한 실제 프로젝트에서 CSS가 HTML에 의존하거나 HTML이 CSS에 의존하며 분리하기가 매우 어렵다는 것입니다.

CSS를 변경하지 않고 HTML을 완전히 리팩터링한 대규모 프로젝트를 해본 적이 있습니까? 아니면 HTML을 조정하지 않고 사이트를 완전히 다시 디자인해볼 예정입니까? 그럴 리는 없습니다!

실제로 이것은 Tailwind를 반대하는 강력한 주장은 아니지만, 만약 이것이 작업 방식에 중요하다고 생각하면, 고려해볼 가치가 있습니다.

결론

만약 Tailwind를 시도하는 것에 대해 확신이 서지 않거나, 어떤 이유로든 Tailwind를 반대했다면, 이 글이 왜 Tailwind의 팬들이 이것을 왜 그렇게 좋아하는지에 대해 약간의 빛을 비추기를 바랍니다. Tailwind는 개발 속도 및 유지 보수 및 효율성 측면에서 많은 이점을 제공합니다. 그 외에도 우리가 가져와 사용할 수 있는 UI 컴포넌트와 기존 디자인, 훌륭한 문서를 가지고 있으며, 유튜브에서 무료로 이용할 수 있는 튜토리얼 등의 훌륭한 생태계를 가지고 있습니다.

이 글이 마음에 들면 트위터에서 @jdlien을 팔로우해 주세요.

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article(https://kofearticle.substack.com/)을 구독해주세요!