(번역) 확장 가능한 CSS의 진화
January 30, 2023
대규모 프로젝트에서 CSS를 확장할 때 발생하는 문제에 대해 자세히 알아보면서, CSS 모범 사례의 진화를 이해해 봅니다.
우리가 CSS를 작성하고 생각하는 방식은 웹이 시작된 이래로 크게 바뀌었습니다.
우리는 테이블 기반 레이아웃에서 반응형 웹 디자인에 이르기까지 먼 길을 왔으며, 이제 최신 CSS 기능으로 구동되는 적응형 레이아웃의 새로운 시대에 접어들었습니다.
CSS를 관리하고 구성하는 것은 매우 도전적이며, 그 합의점을 찾기도 어려운 일입니다.
이 글에서는 확장을 어렵게 하는 근본적인 문제에 대해 자세히 살펴보면서 CSS에 대한 더 깊은 이해를 발전시킬 것입니다.
그리고, 새롭게 등장하고 변화한 여러 CSS 모범 사례의 진화를 이해해 보겠습니다.
마지막으로, 우리는 대규모 프로젝트에서 CSS를 확장하는 과거의 접근 방식을 살펴보겠습니다. 또한, Tailwind 처럼 인기 있는 다양한 도구들이 직관적이지는 않지만 이런 문제를 어떻게 해결하는지 살펴보도록 하겠습니다.
CSS 이전의 시대
처음에는 웹에 HTML만 존재했습니다. 모두 대문자로 작성하고, 마크업에 직접 속성을 사용하여 페이지를 스타일을 지정했었습니다.
<body>
<p SIZE="8" COLOR="RED">LOUD NOISES</p>
</body>세련된 페이지를 원하는 사람들에게는 암흑기였습니다.
사용할 수 있는 스타일의 수가 제한되어 있다는 점 외에도, 스타일을 중복해서 사용해야 한다는 분명한 한계가 있었습니다.
이 시기 웹의 전형적인 예는 오래된 스페이스 잼이라는 웹사이트였습니다.
이제 어떤 사람들은 “이것이 컴포넌트 라이브러리에 전달하는 프로퍼티처럼 보인다”라고 생각할 수 있습니다. 나중에 살펴보겠지만, 혁신의 주기가 뒤틀리면서 모든 것이 원점으로 돌아가는 경우가 많습니다.
스타일시트 및 관심사의 분리
CSS가 새롭게 등장한 뒤 이전의 문제점에서 비롯되었던 많은 혁신처럼 CSS는 모든 중복을 제거하였습니다.
스타일시트를 사용하면 선언적으로 페이지의 스타일을 지정할 수 있어, 매우 적은 코드로 방대한 요소들에 영향을 미칠 수 있었습니다.
p {
color: red;
}이제 콘텐츠의 구조와 눈으로 보여지는 모습 그리고 레이아웃을 분리하여 생각할 수 있습니다. HTML에서 테이블을 사용한 레이아웃 요소를 CSS로 옮길 수 있었습니다.
CSS는 실제 탁상 출판(Desktop Publishing)에서 크게 영감을 받아, 처음에는 적은 양이었으며, 텍스트 열의 형식을 지원하는 “float”와 같은 용어를 사용하였습니다.
시간이 지남에 따라 CSS Zen Garden이라는 사이트에서 예제를 수집하기 시작했습니다.
CSS Zen garden은 사람들이 CSS를 창의적으로 사용할 수 있는 방법을 보여주는 허브가 되었습니다. 사람들은 흥미롭고 독특한 방식으로 동일한 HTML을 스타일링한 CSS 파일들을 제출했습니다.
이는 스타일링에서 콘텐츠를 분리하고, 다시 스타일링 할 수 있는 HTML, 그리고 핵심 골격에 테마를 입히는 “스킨”같은 아이디어를 전파하는 데 큰 영향을 미쳤습니다.
모범 사례 파악
우리는 더 복잡한 사이트와 애플리케이션을 구축하기 시작했고, CSS의 진화에 대한 새로운 요구들이 생겨났습니다.
종종 새로운 기술은 몇 주기 동안 여러 다른 접근 방식을 거친 뒤 모범 사례가 나타나게 됩니다.
Less 및 Sass와 같은 도구가 네이티브 CSS 기능을 확장하는 것을 보았습니다. 변수 및 계산 함수와 같은 기능을 제공하여 개발자 경험을 크게 향상시켰습니다.
이렇게 스타일시트에 더 많은 시간을 할애함에 따라 이러한 모든 규칙과 선택자를 구성하는 방법을 모색했습니다.
CSS 확장을 위한 다양한 패턴이 나타났습니다. 이들은 유지 관리, 성능 및 가독성 간의 균형을 맞추려고 시도했으며 “CSS 아키텍처”라고 불립니다.
CSS 아키텍처에 대해 알아보기 전에, 대규모 프로젝트에서 CSS를 관리하다 보면 왜 빠르게 복잡해지는지 그 이유를 알아보겠습니다.
CSS를 대규모로 관리하기 어려운 이유
“대규모”는 사람, 도구, 프로세스 및 성능을 비롯한 여러 항목의 교차점을 나타냅니다.
효과적으로 확장하기 위해서는 복잡도 증가를 신중하게 관리해야 합니다. 시스템이 커지더라도 여전히 이해할 수 있고 변경할 수 있으며 성능이 우수해야 합니다. 새 코드를 추가하는 비용이 가능한 한 낮게 유지되며, 사람들이 자신 있게 이전 코드를 변경하고 삭제할 수 있어야 합니다.
캐스케이딩(CSS의 C)은 웹 초기부터 시작되었습니다. 브라우저는 이러한 새로운 전자 문서에 기본 스타일을 적용할 수 있습니다. 그런 다음 문서 작성자는 개별 사용자 환경 설정으로 재정의될 수 있는 고유한 스타일을 제공할 수 있습니다.
캐스케이딩 규칙의 컨셉은 CSS를 이해하는 데 핵심입니다. 동일한 속성은 CSS를 강력하게 만들고 또한 대규모 프로젝트에서 이러한 속성을 확장하기 어렵게 만듭니다. 특히 전역 네임스페이스, 캐스케이딩 규칙 및 선택자 특정성이 그러한 특징입니다.
전역 네임스페이스
전역 CSS 네임스페이스는 신중하게 활용하면 강력할 수 있습니다. 그러나 대규모 프로젝트에서는 종종 골칫거리가 될 수 있습니다.
모든 것이 전역적일 때 어떤 것이든 예기치 않게 다른 것에 영향을 미칠 수 있습니다. 지금도 그렇고 언젠가 무언가 바뀔 때도 그렇습니다.
이것은 꽤 빨리 문제가 됩니다. 다른 언어의 전역 네임스페이스에 모든 것을 넣지 않는 이유가 있습니다. 더 많은 코드가 추가될수록 상황을 예측하기 어렵고 유지 관리가 어려워집니다.
CSS 캐스케이딩 레이어가 기본적으로 이 문제를 해결하는 데 도움이 될 수 있는 떠오르는 기능이라는 점은 주목할 가치가 있습니다.
이름을 짓기는 어렵습니다
종종 CSS를 빠르게 반복해 사용하다 보면, 일련의 시맨틱 클래스 이름을 만드는 것이 크게 장점이 없는 귀찮은 일처럼 느껴집니다.
많은 정보를 정확한 라벨로 압축하려고 하므로 적절한 이름을 생각해 내기가 어렵습니다. 모든 것이 글로벌로 선언되었을 때는 이름을 잘 짓는 것이 훨씬 더 중요해집니다.
너무 빠르게 이름을 정하는 것은 성급한 추상화의 한 유형입니다. 종종 명명하고 있는 것들이 충분히 구성되지 않았고 아직 재사용할 수 없는 경우가 많기 때문입니다.
디자인 변경은 프런트엔드에서 일반적이며 이러한 레이블은 주기적으로 구식이 되고, 스타일과 마크업 모두를 리팩토링해야 합니다.
CSS 리팩토링은 어렵습니다
디자인과 최신 소프트웨어 개발은 모두 매우 반복적인 작업입니다. 우리는 몇 번의 반복이 누적된 후에야 명확한 모습으로 개발하기 시작하곤 합니다.
이를 위해, 우리는 해결하고 있는 문제에 대해 우리가 이해하고 있는 것을 정기적으로 재평가해야 합니다. 코드에서는, 우리의 이해가 변화하고 굳어짐에 따른 리팩토링을 의미합니다.
리팩토링은 어려울 수 있지만, 이론보다는 실제 요구 사항에 기반하여 시간이 지남에 따라 좋은 추상화에 도달하기 위한 검증된 진정한 방법입니다.
CSS에서 리팩토링은 꽤 어렵습니다. 견고한 시각적 회귀 테스트가 없으면 많은 CSS 오류가 “침묵” 되어 예기치 않은 버그와 부작용이 쉽게 생성됩니다. 이에 따라 몇 가지 일반적인 시나리오가 발생합니다.
- 스타일시트만 추가
프로젝트는 관리하기 쉬운 스타일시트로 시작합니다. 그러나 나중에 몇 번의 반복과 버그 수정 후에 새 코드가 파일 끝에 붙는 것이 일반적입니다.
규칙을 안전하게 변경하거나 삭제할 수 있는 시기를 알기는 어렵습니다. 그래서 우리는 파일의 끝에서 이전에 캐스케이딩 해 온 것을 무시하고 재정의합니다.
이것이 명시도 충돌의 원인입니다. 우리는 모두 아마도 다른 스타일을 재정의해야 하는 경험이 있을 것입니다. !important가 나타나기 시작하는 것은 유지 관리 부담이 심화하도록 하는 지름길입니다.
- 죽은 코드
실제로는 동일한 CSS 속성을 반복적으로 사용하는 경우가 많습니다. 전역 네임스페이스에서 대량의 CSS를 리팩토링하는 위험을 감수하는 것보다 규칙을 지속적으로 복제하는 것이 일반적으로 훨씬 안전합니다.
이에 따라 그것에 의존하고 있는지 알기 어려운 사용되지 않는 많은 CSS가 발생하게 됩니다. 결국 다양한 파일에 CSS가 퍼져 나가게 됩니다.
CSS 디버깅은 어렵습니다
디버깅의 큰 부분은 컴퓨터가 무엇을 하는지 우리의 머릿속에서 시뮬레이션하는 것입니다.
복잡한 CSS에서는 소스 순서를 고려하면서 캐스케이딩을 마음속으로 계산하고 최종 규칙을 계산하기 때문에 디버깅이 어렵습니다.
특히 위치, 정렬, 문맥 쌓기, 여백 및 높이에 대한 CSS의 많은 뉘앙스가 있습니다. 체계적으로 접근하지 않는다면, 일부 값을 조정해 가며 어떤 일이 발생하는지 확인하는 작업을 CSS 디버깅 워크플로에 추가해야 합니다. 페이지를 새로고침 했는데 전혀 변경된 사항이 없거나 또는 무언가가 완전히 깨질 수 있습니다.
이는 제어할 수 없는 코드나 브라우저 관련 버그가 있을 때 특히 어렵습니다.
CSS 아키텍처로 복잡성 다듬기
CSS는 단순한 모델을 가지고 있지만, 빨리 엉망이 되기 쉽습니다. 우리는 결국 소프트웨어 엔지니어링 원칙을 적용하여 관리하도록 지원하기 시작했습니다.
이러한 아키텍처는 CSS 파일과 해당 규칙 및 선택자를 구성하기 위한 상위 수준의 청사진에 가깝습니다.
더 영향력 있고 인기 있는 CSS 아키텍처와 주요 아이디어에 대한 간략한 개요를 살펴보겠습니다.
OOCSS(Object Oriented CSS): 객체 지향 CSS
OOCSS는 우리가 실제로 작성하는 다양한 유형의 CSS와 구별됩니다. 레이아웃을 수행하면서 색상, 글꼴 등과 같은 테마와 “스킨”을 HTML에 입히는 CSS입니다.
OOCSS의 “객체”는 추상화하고 재사용할 수 있는 반복되는 시각적 패턴입니다. 이 아이디어는 일반적인 시각적 패턴을 식별하고 중복 코드 블록을 재사용 가능한 클래스로 추출하는 것입니다.
이러한 아이디어를 활용하는 가장 널리 사용되는 CSS 프레임워크 중 하나는 Bootstrap입니다.
SMACSS: 확장 가능한 모듈형 CSS
실제로 큰 단일 CSS 파일은 빠르게 관리할 수 없고 디버깅하기 어려워집니다.
SMACSS는 다양한 유형의 CSS를 분류하기 위한 가이드였으며, OOCSS와 같은 접근 방식과 호환되었습니다.
주요 아이디어는 이러한 모든 클래스 이름을 가져와서 별도의 버킷으로 구성하고, CSS 파일에 매우 필요한 구조를 제공하는 것입니다. 또한 클래스의 이름 짓는 것에 대한 몇 가지 컨벤션도 제공합니다.
BEM: 블록(Block), 요소(Element), 수정자(Modifier)
BEM은 사물을 컴포넌트, 하위 요소 및 다양한 별개의 상태로 분해하는 방법에 대한 모델입니다.
원래 Yandex에서 생성되었으며, (하위 선택자 없이) 모든 선택자를 평평하게 유지하여 스타일 지정되는 모든 요소가 고유한 클래스 이름을 가져옴으로써 명시도 충돌을 피하는 체계적인 명명 규칙을 제공합니다.
BEM은 플랫 CSS 선택자로 컴파일되는 중첩 규칙이 있는 Sass와 같은 인기 있는 CSS 전처리기와 잘 어울립니다.
.nav {
// 블록 스타일
&__link {
// 부모 블록에 의존하는 요소 스타일
&--active {
// 수정자 스타일
}
}
}ITCSS: 역삼각형(Inverted Triangle)
ITCSS의 주요 아이디어 중 하나는 캐스케이딩을 길들일 수 있도록 레이어링 렌즈를 통해 스타일 시트에 대해 생각하는 것입니다.
ITCSS는 다른 시스템과 호환되는 CSS의 “메타 프레임워크”와 같습니다.
이 아이디어는 증가하는 특수성의 명시적인 레이어를 제공하여 예측할 수 없이 서로를 덮어쓰는 모든 것의 혼돈을 길들이는 것입니다.
“역 삼각형”은 역피라미드 모양을 형성하는 각 점진적인 레이어에서 유래되었습니다.
이것은 대규모 프로젝트에서 CSS 파일을 관리하기 위한 영향력 있는 방법론입니다. 더 깊게 알고 싶다면 작성자의 담화를 확인해 보세요.
큐브 CSS
큐브 CSS는 전역 네임스페이스와 캐스케이딩을 사용하여 CSS 코드를 구성합니다.
큐브 CSS는 CSS를 분류하는 잘 정의된 버킷 세트를 제공합니다. 큐브는 구성(Composition), 유틸리티(Utility), 블록(Block), 예외(Exception)의 줄임말입니다.
큐브 CSS의 문서는 원칙들을 아주 훌륭하게 설명합니다. 이것은 CSS를 구성하기 위한 멘탈 모델과 같은 느슨한 방법론입니다.
큐브 CSS는 ITCSS와 마찬가지로 다양한 접근 방식과 호환되는 영향력 있는 “메타 CSS 프레임워크”입니다.
관심사의 분리에 대한 재고
SPA 및 컴포넌트 주도 개발의 부상으로 CSS에 대한 새로운 접근 방식을 보기 시작했습니다.
이 세계에서는 컴포넌트가 이제 소스 순서에 대한 보장 없이 비동기적으로 로드되기 때문에 CSS 관리가 훨씬 더 어려워졌습니다.
일반적인 문제는 페이지 A에서 B로 SPA 전환을 수행할 때 페이지의 일부 요소가 다르게 보이지만 B로 직접 로드하면 문제가 없는 경우입니다. 이것은 몇 가지 흥미로운 디버깅 세션으로 이어졌습니다.
우리는 프런트엔드를 구조화하는 이 새로운 컴포넌트 중심 접근 방식을 활용한 CSS 관리를 위해, 더 구체적인 해결책을 찾기 시작했습니다.
이러한 도구들은 종종 우리가 지금까지 구축하고 생각했던 많은 확립된 모범 사례를 깨뜨렸습니다. 이제 그것들을 살펴보며 이해해 봅시다.
인라인 스타일
컴포넌트 기반 프레임워크로의 전환은 종종 컴포넌트 내부에 인라인 스타일이 적용되는 경우가 많았습니다. React와 같은 프레임워크에서는 JavaScript 객체를 style 프로퍼티에 전달하여 그것을 인라인 스타일로 변환합니다.
이는 외부 스타일시트가 없었을 때의 시작으로 돌아가 기존 모범 사례를 버리고 있는 것과 같기 때문에 많은 사람에게 생각보다 큰 반응을 불러일으켰습니다.
컴포넌트의 맥락에서 인라인 스타일은 스타일이 컴포넌트 내부에 캡슐화되어 있기 때문에 대량 중복의 문제를 겪지 않습니다. 스타일이 오직 그 요소에만 영향을 미치는 것은 컴포넌트 내부에서 CSS를 안전하게 추가하고 수정할 수 있는 좋은 방법입니다.
인라인 스타일의 주요 문제는 의사 선택자(pseudo selector) 및 미디어 쿼리와 같은 보다 강력한 CSS 기능에 접근하기 어렵다는 것입니다. 공유된 디자인 토큰, 캐싱, 정적 분석, 그리고 전처리를 사용하기 어렵다는 것도 문제입니다.
CSS in JS
React의 초기 단계에서 Veujx는 Facebook의 CSS 접근 방법에 대한 토크를 했습니다. 표면상은 인라인 스타일과 비슷해 보였지만 스타일시트의 힘을 사용할 수 있었습니다.
이 토크는 CSS에 대한 JavaScript 기반 접근 방식을 취하는 오픈 소스 라이브러리의 확산으로 이어졌습니다.
CSS in JS의 첫 번째 CSS 물결은 Styled Components, Emotion등 React 생태계에서 다양한 라이브러리와 함께 인기를 끌었습니다.
이들은 컴포넌트를 사용하는 대규모 프로젝트에서 발생하는 바닐라 CSS가 가지고 있던 대부분의 문제를 해결하여 JS에서 동적 값으로 사용하는 것이 매우 쉬워졌습니다.
문제는 최종 사용자가 지불하는 성능 비용이었습니다. 서버 사이드 렌더링의 효율성 문제, 캐싱 문제, 그리고 클라이언트 런타임 비용이 있었습니다.
이에 따라 앱 시작 시간이 느려지고 JavaScript가 하이드레이션 된 후에도 여러 번 다시 렌더링이 필요했습니다. 대용량 앱의 경우 많은 작업이 빠르게 추가되었습니다.
최근 CSS in JS 라이브러리의 두 번째 물결은 런타임 비용 없이 최고의 개발자 경험을 제공하는 것을 목표로 합니다.
Vanilla extract, Linaria 및 Compiled와 같은 도구는 컴파일 단계의 컴포넌트에서 스타일시트를 추출합니다. 이렇게 하면 사용자 브라우저에서 런타임에 발생하는 대부분의 작업을 컴파일 시간으로 이동시킵니다.
CSS는 부담스러운 CSS 파일을 피하고자 종종 Atomic CSS(조금만 다룰 CSS 아키텍처)로 컴파일되며 동적 런타임 스타일 시트에 비해 훨씬 더 캐시 가능하기 때문에 좋습니다.
CSS 모듈
CSS 모듈은 일반적인 CSS(또는 Sass)를 작성하면서 우리가 원하는 많은 확장 속성을 적용할 수 있도록 균형을 유지합니다.
CSS 모듈을 사용하면 컴포넌트 디렉터리 내에서 지역화된 항목을 유지하면서 컴포넌트를 거쳐 스타일이 번지는 것을 걱정하지 않고 CSS의 모든 기능과 제어를 사용할 수 있습니다.
특히 CSS in JS 라이브러리의 첫 번째 물결에서는 특정 뷰 라이브러리와 결합하는 CSS를 사용하는 것이 너무 과도했고, CSS 모듈은 이러한 문제를 해결하는 좋은 대안이었습니다. 그러나 일부는 선택자를 생성하고 범위를 지정하기 위해 Webpack과 같은 번들러에 의존하기 때문에 CSS in JS의 한 형태로 간주할 수 있습니다.
그런데도 CSS 모듈은 일반 CSS 세계와 CSS in JS와 같은 완전한 컴포넌트 중심 접근 방식 사이의 좋은 중간 균형을 이루었습니다. 여전히 BEM과 같이 규칙에 호환되는 이름을 짓는 것은 필요합니다.
도전적인 CSS 모범 사례
한편, 컴포넌트 기반 SPA의 세계 밖에서 원래 CSS Zen Garden의 영향을 받은 모범 사례는 또 다른 측면에서 도전을 받았습니다.
Atomic CSS는 대규모 프로젝트에서 CSS를 관리하는 암흑기 속에서 탄생했으며, 그것에 의해 형성되었습니다.
초기 동기는 완전히 실용적이었습니다. 즉, 기존 스타일시트에 규칙을 편집하거나 추가하지 않고도 스타일링할 수 있습니다. 그에 따라 모든 문제를 피할 수 있었습니다.
OOCSS, BEM 및 SMACSS와 같은 다른 CSS 아키텍처와 비교할 때 스펙트럼의 반대편에 있었고, 완전히 직관적이지 않았습니다.
Atomic CSS는 단일 목적 원자에 초점을 맞춰 “블록” 및 “객체”보다 낮은 레벨로 이동했습니다. HTML 사양에서 제시한 CSS 클래스 명을 지정하지 않는 방법에 대한 확립된 모범 사례에 전혀 반대되는 방식이었습니다.
이것은 기존 CSS를 수정하는 것이 너무 위험하다고 느끼는 팀에게 인기 있는 생산성을 향상하는 접근 방식이 되었습니다. 인기 있는 CSS 라이브러리에는 ACSS, Tachyons, WindiCSS등이 포함되어 있습니다.
state of CSS에 따르면, 오늘날 액세스할 수 있는 이 CSS 아키텍처의 가장 인기 있는 구현 중 하나는 Tailwind CSS 프레임워크입니다.
Tailwind의 부상
Tailwind는 2017년 출시 이후 빠르게 인기를 얻고 있습니다. Tailwind의 대표적인 특징은 CSS를 비전문가에게도 쉽게 접근할 수 있게 하여 생산성을 높이는 동시에 유지 관리가 용이하게 만든다는 것입니다. 일반적으로 “그냥 써보아라, 다시 돌아가지 않을 것이다”라는 충고가 있습니다.
Tailwind를 이끄는 원칙
Tailwind의 인기를 이해하기 위해 Tailwind 방법의 기본 원칙을 살펴보겠습니다.
확립된 모범 사례를 버리는 것처럼 보이지만, 그 이면에는 실제로 작동하는 실용적인 원칙 모음이 있습니다.
이름 지정 연기
지속해서 이름을 지정할 필요가 없다는 것은 Tailwind가 매우 생산적이라고 느끼는 이유 중 하나입니다. 이 워크플로는 단일 목적 원자를 상향식으로 구성한다는 아이디어로 뒷받침됩니다.
유지 관리의 관점에서 이는 성급한 추상화를 피하는 좋은 방법입니다.
이름을 지정하지 않는 것은 코드의 가독성을 해칩니다. 이에 따라 명확한 경계 없이 단일 목적 원자 클래스(또는 컴포넌트)가 이리저리 뒤섞인 형태가 될 수도 있습니다.
이것은 타당한 비판입니다. 그러나 실제로 이것이 진짜 고통이 되기 전에 얼마나 갈 수 있는지는 놀라울 정도입니다. 자주 변경되거나 많은 사람과 함께하는 코드 기반에서 이는 올바른 절충안입니다.
이는 컴포넌트 모델의 강력한 워크플로입니다. 이미 작업 중인 컴포넌트에 대한 의미론적 이름이 있으므로 컴포넌트 내부에 포함된 스타일로 스타일을 구축하게 됩니다.
이것은 미래 지향적인 프런트엔드 구축에 설명된 것과 동일한 높은 수준의 원칙입니다. 절대 추상화를 생성하지 않는 것이 아니라 성급하게 생성하지 않는 것입니다.
적절한 시기에 추상화
반복적으로 작업할 때, 코드를 쉽게 삭제하고 변경할 수 있는 기능은 중복의 비용보다 훨씬 중요합니다.
CSS를 작성할 때 공통적으로 겪는 문제 지점은 미리 너무 DRY 하거나 최적화하다가 나중에 변경하기 어려워진다는 것입니다.
지나치게 추상화된 코드를 근본적으로 바꾸고 새로운 용도로 사용하는 것보다, 일반적인 추상화 뒤에 중복된 코드를 DRY 하게 하기가 훨씬 쉽습니다.
Tailwind는 적당한 시점에 추상화할 수 있는 두 가지 기법을 제공합니다. 첫 번째는 블록(OOCSS와 유사)을 나타내는 공유된 CSS 클래스를 만드는 방법입니다.
두 번째는 컴포넌트 기반 프레임워크를 사용할 때 추천되는 방법인 중복된 클래스를 재사용할 수 있는(React, Vue, Solid, Svelte 등) 컴포넌트로 추출하여 공유하는 것입니다. 하여 적시에 추상화하는 두 가지 기술을 제공합니다.
자신감있는 리팩토링
클래스는 해당 마크업으로 지역화되기 때문에 다른 요소나 컴포넌트에 영향을 미칠 염려 없이 자신 있게 리팩토링할 수 있습니다.
이는 웹을 문서로써 이해하는 것과 컴포넌트 중심 모델 모두에 적용됩니다. 이에 따라 Tailwind는 웹 사이트 또는 애플리케이션의 유형에 따라 확장 및 축소할 수 있다는 느낌으로 이어집니다.
데드 코드 방지
Tailwind와 Atomic CSS로 사전 컴파일되는 CSS in JS 라이브러리들은 중복된 규칙으로 가득 찬 CSS 파일의 문제를 해결합니다.
Atomic CSS로 사용된 유일한 스타일의 수에 따라 CSS의 증가가 발생하며, 개발자가 배포하는 기능의 양에는 영향을 끼치지 않습니다.
예를 들어, flex와 같은 특정 속성을 모든 곳에서 재사용하는 것은 일반적입니다. 다른 클래스 이름으로 스타일 시트에 중복된 것보다, 해당 비용을 한 번만 지불하는 것이 효율적입니다. 이는 각 속성/값 조합에 해당합니다.
디자인 격차 해소
이러한 모든 원칙과 아키텍처에서 잠시 벗어나, CSS는 궁극적으로 시각적 디자인을 구현하는 것임을 기억하세요.
많은 개발자가 CSS를 어렵게 느끼는 가장 큰 이유는 디자인이 어렵다는 사실입니다.
기초를 올바르게 잡는 것은 큰 도움이 됩니다. 시각 디자인의 경우, 핵심 요소는 정렬, 간격, 일관성, 크기 조정, 타이포그래피 및 색상입니다.
CSS에서는 font-size, color 또는 padding과 같은 특정 속성에 대해 값을 구현하는 여러 가지 방법이 있습니다.
종종 임의로 구현하여, 약간 다른 글꼴 크기, 간격 및 색상 불일치를 일으키며 세련되지 못한 느낌을 줍니다.
CSS 크기 조정의 핵심 부분은 간격, 글꼴 크기, 색상, 중단점 등에 대한 값을 정의하는 공유 가능한 기본 요소의 견고한 기반을 둠으로써 이러한 디자인 격차를 해소하는 것입니다.
이들은 종종 디자인 토큰이라고 하며 디자인 시스템의 기초를 형성합니다. 이 기반이 없으면 모든 것이 매우 자의적이고 혼란스럽게 느껴질 수 있습니다.
Tailwind의 인기 비결 중 하나는 이미 생각해 둔 기본 디자인 요소를 제공한다는 것입니다. 이를 통해 종종 일관성 없이 수행되는 엄청난 양의 의사 결정이 제거됩니다.
견고한 기반을 위한 또 다른 훌륭한 오픈 소스 옵션은 어떤 CSS 접근 방식과도 호환되는 Open Props이며, 미리 준비된 훌륭하고 많은 변수와 토큰을 제공합니다.
결론
“유용한 것은 흡수하고, 쓸모없는 것은 버리고, 특징적으로 나만의 것을 추가하세요.”
완벽한 도구는 없으며 각 프로젝트와 팀은 다릅니다. 어떤 접근 방식을 취하든 디자인 격차를 해소하는 기반을 구축하는 것이 CSS 확장의 핵심 요소입니다.
그 위에 구성되고 구축되는 기본 요소에 집중하는 것도 큰 도움이 됩니다. 이는 컴포넌트 라이브러리를 사용하는 대규모 컴포넌트 기반 애플리케이션에도 적용됩니다. Box, Stack, Inline 등과 같은 구성 가능한 컴포넌트 레이아웃 기본 요소를 제공하는 것은 개발자가 CSS를 작성하지 않고도 CSS를 관리할 수 있는 좋은 방법입니다.
최근 CSS를 확장하기 어렵게 만드는 많은 문제점을 해결하는 인상적인 기능이 에버그린 브라우저에 제공되었습니다. 캐스케이딩 레이어, 컨테이너 쿼리, 하위 그리드, has 등과 같은 최신 기능은 향후 CSS에 대한 생각과 활용 방식을 바꿀 것입니다.
CSS 확장에서 성공하려면 특정 원칙에 일방적으로 충실히 하는 것이 아니라 실제 제약 조건을 기반으로 필요한 것을 정의하고, 작업을 지속 가능하고 효율적으로 처리해야 합니다.
![[Ykss]](/static/e1b6058af380e8a00f152aefa04db768/a12fc/profile.png)