[번역] 확장성 있는 CSS

원문은 Css and Scalability에서 확인하실 수 있습니다.

수 년전부터 나는 확장성 있는 CSS에 대해 고민하게 됐다. 그 때는 친구들이 빌려준 책 몇 권이나 괜찮은 블로그 글 몇 개를 제외하면 지금처럼 참고할 수 있는 자료가 많지 않았다. 당시엔 CSS가 꽤 새로운 존재였고, 대부분의 사람들은 거대한 애플리케이션을 만들 때의 확장성과 같은 개념에 대해 깊게 생각하지 않았다.

그 시절엔 Css zen garden(역자 주: 같은 Html 구조를 CSS를 통해 얼만큼 변화시킬 수 있는가를 보여주기 위한 데모 프로젝트)은 굉장한 데모 프로젝트 였고, 우리는 이 데모가 CSS의 cascade한(역자 주: CSS는 나중에 추가한 규칙이 위의 규칙을 마치 "폭포수가 위에서 아래로 떨어지는 것처럼" 변경할 수 있다) 힘을 잘 보여 줬다고 생각한다. CSS를 통해 HTML구조를 전혀 변경하지 않고도, 사이트의 외형을 큰 폭으로 변화시킬 수 있다.

처음엔 CSS의 cascade함이 사람들의 이목을 사로잡았다. CSS를 작성할 땐 한 군데만 바꿔도 그 변화를 여러 곳에 적용시킬 수 있다. 이론적으로 이런 기능은 굉장히 매력적이다. 하지만 11년이 지나고 나서 생각해보면 이러한 CSS의 특징이 CSS에서 가장 당혹스러운 부분이자 제품을 짧은 주기로 업데이트하는 것을 방해하는 가장 큰 걸림돌 이라는 생각이 든다.

두 CSS 속성이 바(Bar)로 걸어들어온다.
전혀 다른 바에 있던 바 의자가 무너진다.

[- @thomasfuchs](https://twitter.com/thomasfuchs/status/493790680397803521)
Thomas Fuchs의 트위터 멘션

수없이 많은 프로젝트에서 CSS 시스템이 붕괴되어 가능 과정을 경험하고 나니 나는 내가 CSS의 이런 "기능"을 원하지 않는다는 것을 알게 됐다.

나는 언젠가 프론트엔드 개발에서 최악의 문제는 문제를 해결하는 사람이 다른 프론트엔드 개발자 라는 농담을 한 적이 있다. 그러나 지난 몇 년 간 똑똑한 개발자들이 CSS에 대해 깊이 공부하고 확장성 있는 UI를 만드는 법을 고민하기 시작했다. 내가 확장성에 대해 처음 고민하기 시작했을 때는 읽을 수 있는 모든 블로그 포스트를 읽고, 가능한 모든 테크토크를 참석했다. 그런 자리에서 유지 가능한 sass/less/stylus 등에 대한 best practices를 들을 수 있었다. 이를테면 Mixin을 사용해서 코드를 DRY(역자 주: Don't repeat yourself, 코드를 중복하지 말라는 원칙)하게 만드는 방법이나 상속을 통해 마크업을 깔끔하게 유지하는 법 또는 BEM 네이밍을 통해 코드를 완벽하게 유지하는 방법 말이다.

하지만 현실은 어떤가? 프로덕션 환경에 배포되는 코드는 어떤가? 이 모든 방법론이나 개념이 프로덕션 CSS 또는 팀 전체에 어떤 영향을 미쳤나? 가장 중요한 사용자에게는 어떤 영향을 미쳤는가?

제품을 디자인하고 배포하는 과정에서 나는 항상 현실 세계를 염두에 둔다. 몇몇 테크토크나 세미나 자리는 현실 세계에 대한 이야기를 꺼리곤 했다. 그들은 이론적인 가능성에 대한 공허한 이야기만을 했다. 나 또한 정신을 놔 버리고 그들처럼 되고 싶을 때도 있다. 하지만 현실에서 자신이 처한 상황을 돌아보지 않으면서 문제가 무엇인지 알아내는 건 어렵다. 그리고 문제를 인지하지 못한 채로 해답을 찾아낼 확률은 극히 낮다.

나는 2014년에 Salesforce에서 일을 했다. 사이트에는 굉장히 많은 CSS 코드가 있었고, 나는 그 코드에 좀 더 익숙해지고 싶어서 개발자 도구를 켜 CSS를 관찰했다.

한 줄 한 줄, 처음부터 끝까지 읽어 나갔다.

어떤 코드를 나를 웃게 했다:

/* 재 사용가능한 스타일 규칙 시작 */

또 어떤 코드는 나를 울게 했다.

.homepage-promos .grid-50 {
width: 100%
}
.homepage-promos .grid-33 {
width: 100%
}
.homepage-promos .grid-34 {
width: 100%
}

어떤 코드를 보면서 나는 웃기도 울기도 했다.

#seo-container {
    display: none;
}

어떤 코드는 이 수치가 어디서 왔는지 의문을 품게 했다.

.product-tab {
  height: 530px;
  width: 99.7%;
}

어떤 코드는 내가 CSS 스펙을 읽었다는 것에 감사하게 했다.

(역자 주: float에는 center라는 속성이 없음)

.container-inner.promo-status {
     float: center;
  }

마지막으로 나는 이 코드에서 잠시 멈추었다.

.left {
  float: left!important;
}

나는 이 클래스를 보면서 잠시 생각했다. 다른 규칙과 달리 이 규칙은 굉장히 재사용 가능성이 높아 보였다. 누군가 요소를 왼쪽으로 위치시키고 싶다면 이 클래스를 사용하면 된다.

나는 다음 코드에서도 잠시 멈추었다.

.left-max-scr1,
.left-max-scr2,
.left-max-scr3,
.left-only-scr1 {
    float: left;
}

바로 다음 줄의 이 CSS를 보면서 말이다.

.left-min-scr2,
.left-min-scr3,
.left-max-scr3,
.left-only-scr3 {
    float: left;
}

다음 코드를 보면서는 코드를 이렇게 작성한 이유에 대한 의문이 들었다.

.header-nav-list가 .header-nav-container 아래에 위치하지 않았기 때문일까?

.header-nav-container .header-nav-list {
    float: left;
}

.CA .header-nav-list.second {
    float: left;
}

#nav.challenger-a .submenu-3col li,
#nav.challenger-a .submenu-3col li {
    float: left;
}

다음 코드에서는 content-semantic class (역자 주: 레이아웃과 같이 마크업과 관련된 내용을 담고 있는 클래스명)와 visually semantic class(역자 주: 시각적인 요소 - 색깔, 그리드, 칼럼 등을 담고 있는 클래스명)가 함께 사용된 것을 알 수 있다.

.ie6 #footer-content .flex-control-nav li a,
.ie7 #footer-content .flex-control-nav li a,
.ie8 #footer-content .flex-control-nav li a {
    float: left;
}

#nav.challenger-a li.menu-products {
    float: left;
}

CSS에서는 가장 나중에 작성한 코드가 파일의 맨 아래에 위치하게 된다. 그렇기 때문에 CSS 파일을 처음부터 끝까지 읽다 보면 시스템이 시간 순서에 따라 어떻게 붕괴해 갔는지를 알 수 있다.

위 예에서는 아래로 갈수록 규칙들이 float: left 라는 하나의 속성을 설정하기 위해 갈수록 더 긴 선택자를 사용한다는 사실을 알 수 있다.

CSS 파일을 읽으면서 나는 많은 생각을 하게 됐다. 내 머리 속에서 떠나지 않는 생각은 "왜 한 가지 속성을 바꾸기 위해 이렇게 많은 코드를 작성해야 하지? 왜 어떤 요소를 왼쪽으로 위치시키기 위해서 저렇게 많은 코드를 작성해야 할까?" 였다.

내가 이해한 바로는 이런 상황은 프론트엔드 코드를 작성하는 이들의 사고 체계가 정확히 반영된 것이다. 이들은 보통 UI에서 한 두 개 요소를 바꾸려고 하기 때문이다. 그리고 이들은 한 부분의 변화가 다른 부분에 영향을 주지 않기를 바란다.

그리고 나는 코드 간 의사소통에 대해서도 생각해 보게 됐다. 나는 HTML을 읽을 때는 특정한 CSS가 어떤 일을 하는지 알고 싶고, CSS를 읽을 때는 이 규칙을 어떤 HTML 요소에 적용했을 때 어떤 일이 일어날지 알고 싶다. 좋은 시스템에선 정보가 두 방향으로 움직인다(two-way street of information). CSS를 볼 때면 이 CSS가 무슨 일을 할 지 알 수 있고, HTML을 보면 적용된 CSS가 어떤 영향을 미칠지 알 수 있다.

그러나 대부분 프론트엔드 시스템은 그렇지 않다. 많은 프로젝트에서 정보는 한 방향으로만 움직인다. 개인적으로는 HTML을 보면서 CSS가 어떤 영향을 미칠 지 5초 안에 파악할 수 없다면 시스템이 붕괴될 것이라고 본다.

.container-inner.promo-status

위 코드는 두 가지의 클래스를 동시에 가진 요소에 적용된다. 그래서 이 경우에는 container-inner와 promo-status의 두 가지 클래스 정의를 모두 살펴봐야 한다. 하지만 내가 이 두 가지 규칙의 정의를 찾을 때 쯤 이면 아마도 나는 내가 원래 하려고 했던 일을 잊은 채 책상을 밀고 커피를 마시러 갈 것이다.

반대로 이런 경우는 어떨까?

.red {
  color: #FF4136;
}

나는 이 클래스가 요소의 텍스트를 빨간 색으로 만든다는 것을 짐작할 수 있다. 이제까지 나는 이런 식의 네이밍이 끔찍한 네이밍 이라는 소리를 들어왔다. 하지만 나는 이런 네이밍을 좋아한다 - red라는 이름을 단 채로 보라색, 파란색 혹은 빨간색이 아닌 다른 색깔을 설정하지만 않는다면 말이다.

그리고 내가 이런 html 코드를 보게 된다면:

<div class=“red”>Some text</div>

위 코드에서 나는 CSS를 보지 않고도 어떤 일이 일어날지 알 수 있다. 이런 코드에서는 정보가 양 방향으로 움직인다. 그러므로 작은 클래스 여러 개가 어떤 영향을 미칠 지 예측이 가능하고, 작은 클래스를 다른 요소에 재 사용하는 것도 어렵지 않다. 또 클래스 명과 그 정의가 1대1로 매칭이 된다. 이러한 개념은 새로운 것이 아니다. 단지 CSS 커뮤니티에서 오랜 기간 무시해 왔을 뿐이다. 작은 클래스의 이점은 반대의 경우를 고려해 보면 분명해진다. 상상의 filesize라는 함수가 파일 이름을 인자로 받고 파일의 크기를 리턴 한다고 하자. 좋은 느낌이다. 하지만 이 함수가 파일의 크기 대신 파일의 줄 수를 리턴 한다면 어떤가? 그다지 좋은 느낌이 들지 않는다. 이것이 CSS 클래스의 재 정의할 때 발생하는 일이다. 이는 CSS를 디버깅하기 어렵게 만들고, 만약 개발자가 cascade한 CSS의 특성을 제대로 이해하지 못한다면 상황은 더 끔찍할 것이다.

극도로 복잡한 CSS를 볼 때면 우리는 모든 규칙 뒤에 복잡한 사연이 있다는 걸 기억해야 한다. 작성자가 시간이 부족해서 재 사용할 수 있는 코드가 있다는 사실을 기억하지 못했을 수도 있다. 혹은 CSS 작성에 전혀 공을 들이지 않고 동작하자 마자 커밋한 뒤에 다른 코드를 작성하러 갔을 수도 있다. 나쁜 코드를 작성하는 이유는 단지 좋은 코드를 작성하기 위해 의식적으로 노력하지 않기 때문만은 아니다. 작업 중에는 항상 다른 방해 요인이 있다. 깨끗하고 재 사용 가능한 코드 작성을 방해하는 요소는 어떤 것 일까? 어떻게 그런 요소를 제거할 수 있을까? 나는 지난 몇 년 동안 사람들이 어떤 식으로 프론트엔드 코드를 작성하는 지, 또 어떻게 다른 사람의 코드를 사용해 UI를 개발하는 지에 대해 연구 해왔다. 나는 이를 통해 사람들이 가진 다양한 사고 체계에 대해 배웠으며, 사람들이 버그와 싸우는 대신 제품 코드 작성에 집중할 수 있는 시스템을 만드는 일에 대해 생각하게 되었다.

Sidenote:

퍼포먼스 및 유저 테스팅을 하기 전까지 나는 oocss나 atomic css(역자 주: 둘 모두 굉장히 재 사용 가능한 작은 클래스를 지향한다.)를 좋아하지 않았다. 나는 요소에 대한 모든 정의를 담은 클래스를 작성한 뒤에 선택자를 통해 DOM 구조에 적용되는 코드를 좋아했다. 내게는 그 방식이 가장 적합하다고 생각했고 그 방식으로 많은 웹사이트를 제작해 왔다. 나는 이전의 가정을 테스트해 나가면서 현재의 방식에 대해 알게 되었다. 이제는 개인적인 측면보다는 큰 조직에서의 일에 더 큰 관심이 있다.

새로운 컴포넌트를 작성하거나 기존의 UI를 변경할 때 어떤 식으로 작업하는가? 내가 알기로 이 과정에서 CSS를 재 사용하기 위해 모든 CSS를 읽는 사람은 없다. 누가 수 천 줄의 css를 읽을 시간이 있겠는가? 그럴 충분한 시간이 있더라도 그럴 사람은 없다. 나는 그들을 비난 하려는 게 아니다.

설사 모든 CSS를 읽고 어떤 코드가 재사용 가능하다는 생각이 들더라도 그 코드를 나중에 누군가 수정해 버리면 어떡하겠는가? 그런 상황에서는 아마 새롭게 CSS를 작성하는 걸 선호할 것이다.

Salesforce가 많은 돈을 들여 사람들을 고용하고 올해의 혁신적인 기업으로 Forbes 상을 탈 수도 있다. 하지만 Salesforce의 css는 "혁신적"(역자 주: 모든 사람이 제각각 새로운 방식으로 CSS 코드를 작성하는 상황에 대한 풍자적인 표현)이다. CSS를 읽어 나가는 일련의 과정에서 나는 울거나 머리를 쥐어 뜯거나 크게 웃었다. 그리고 이러한 문제는 Salesforce만의 문제 여야 된다고 생각했다. 만약 모든 웹 사이트의 CSS가 이렇다면 그것만큼 끔찍한 상황은 없을 테니까! 동시에 Medium, GitHub, Adobe 혹은 Pinterest 같은 굉장한 회사에는 이런 문제가 없을 것이라고. 이 회사들은 내가 만난 굉장한 CSS 개발자들이 다니는 회사니까. 그들이 분명 어떤 식으로 css를 확장성 있게 유지하는지 알아냈을 것이다.

자연스럽게 나는 그들의 사이트를 열어 css를 읽어 나가기 시작했다. 한 줄 한 줄, 처음부터 끝까지. 나는 현실이 어떠한지 보고 싶었다. 나는 정확히 똑같은 문제를 발견했다. display: none을 설정하는 규칙들이 어떤 모습을 하고 있는지 살펴보자:

• Github
• Pinterst
• Medium
• Adobe

display: none이라는 하나의 속성을 설정하기 위해 수많은 코드가 사용됐다. 위 내용을 살펴 봤을 때 그들이 DRY 원칙이나 재 사용성에 대해 고민한 것처럼 보이는가?

내가 CSS를 작성할 때면 나는 그 코드가 재 사용될 코드 이길 바란다. 만약 다른 사람이 다시 사용할 수 없다면 그 코드는 크게 쓸모가 없을 것이다.

그렇다면 DRY는 어떤 의미일까? 결국 CSS든 HTML이든 어딘가 에서는 반복을 해야 되는데 말이다! 하지만 CSS를 잘 알아도 새로운 HTML을 추가하지 않고는 새로운 컴포넌트를 작성할 수 없다. 반면 새로운 CSS를 작성하지 않고 새로운 컴포넌트를 작성하는 일은 가능하다. 이는 UI를 변경하는 경우에도 마찬가지다. HTML을 변경 하기만 하면 디자인을 변경할 수 있다.

내가 위에서 든 display: none 예시는 일반적으로 작성자가 cascade한 특성을 활용해 한 두 가지의 규칙을 변경 하려고 한 결과다. 시간이 가면서 cascade를 활용하기 위해 더 긴 선택자가 필요하게 되고 파일 사이즈가 더 커지면서 CSS를 디버깅하기 위한 시간도 계속 증가하게 된다.

이런 상황에선 항상 새로운 CSS를 작성해야 한다. CSS를 리팩토링하는 일은 어렵고 시간이 많이 필요하다. 더 이상 사용 되지 않는 CSS를 제거하는 일 또한 그렇다. 그 결과는 어떤가? 사람들은 계속해서 CSS를 추가해 나가기만 한다.

이런 현상은 확장성에 두 가지 영향을 미친다. 하나는 코드를 작성하기 어렵게 만든다는 점이다. 이는 현실적으로 앱 내의 모든 CSS를 기억할 수 없고, 그렇기에 코드의 재 사용성을 심각하게 저해하기 때문이다. 또한 이는 사용자가 더 큰 크기의 코드를 다운로드 받아야만 한다는 말이다. 만약 "gzip 처리를 하면 그렇게 큰 사이즈도 아닐텐데, 뭐"와 같은 생각을 한다면 당신은 틀렸다. Pinterest의 CSS는 압축되지 않았을 때 1mb 이상의 파일 5개 분량 이며, 이를 gzip 처리 하더라도 여전히 159kb를 차지한다. 게다가 이 CSS의 97%는 첫 페이지에서 사용 되지 않는다. 나라면 사용자가 실제로 사용 되는 3%의 CSS만 다운로드 받게 할 것이다.

코드가 폭발적으로 늘어나는 원인 중 하나는 'content-semantic' 클래스 네이밍이다. 솔직히 나는 아직도 이 네이밍을 괜찮게 생각하는 사람들이 있다는 것이 놀랍다. Nicolas Gallagher는 이미 이런 네이밍 방식이 왜 제대로 동작하지 않는지에 대해 굉장한 포스트를 쓴 적이 있다. 하지만 무슨 이유 인지는 몰라도 여전히 어떤 이들은 이 방식의 장점이 모든 문제에 대한 해결책(silver bullet)이라고 생각한다. 그래서 나는 우리가 배워온 CSS의 모든 원칙이 잘못됐을 가능성에 대해 생각해 본다.

문제의 핵심은 여기에 있다. content semantic 네이밍은 시각적인 스타일과 전혀 관련이 없다. 레고를 조립할 때 어떤 블록을 보면서 "엔진에 들어갈 블록이네"라고 생각하지는 않는다. 대신 "1x4짜리 파란색 블록이네. 이걸로 뭐든지 할 수 있겠어"라고 생각한다. 내가 지하 잠수부 기지를 만들든 비행기를 만들든 전혀 상관없다. 나는 이 블록을 어떻게 사용할지 정확하게 알고 있다.

결국 모든 것이 레고 블록이다. 나는 블록을 프로젝트의 어느 부분에서든 사용할 수 있고, 블록은 언제나 같은 모양을 유지한다. 나는 프론트엔드 개발이 "레고 블록"을 활용하길 꿈꾼다. 레고 블록은 어디에서나 사용할 수 있다. 이 아이디어는 프로젝트의 종류에 관계 없이 굉장한 효력을 발휘할 것이다.

브랜드 관련 배경 사진이나 화려한 그래디언트 같은 특수한 경우를 제외하면 사이트에 사용될 CSS는 이미 모두 이전에 작성된 것들이다. 그럼에도 우리는 언제나 바퀴를 새로 발명한다(역자 주: 이전에 해결한 문제를 계속해서 다시 해결하는 것). 이는 사진을 찍기 위해 계속해서 카메라를 발명하는 것과 같은 기분이 들게 한다. 카메라를 처음부터 만드는 건 멋진 일이지만 사진을 찍을 때마다 그러고 싶지는 않다. 나는 단지 새로운 사진 한 장을 찍고 싶을 뿐이니까.

CSS의 확장성에 대한 얘기를 들을 때면 대부분의 사람들은 어떤 식으로 CSS를 작성할 것인 지에 집중한다. 하지만 실제로 확장성 있는 CSS를 만드는 방법은 CSS를 작성하지 않는 것이다. 가장 자주 사용 되는 클래스를 추출해내고, 작은 클래스를 결합해서 새로운 스타일을 만들다 보면 팀이 얼마나 빠른 속도로 코드를 작성할 수 있는지 알게 될 것이다.

사람들이 CSS를 작성하게 되면 생기는 많은 문제가 있다. 비 일관적인 값, 매직 넘버(역자 주: 의도를 알 수 없는 숫자 상수)의 사용, 코드 중복, 반응형(responsive)이지 않은 디자인 말고도 굉장히 많다.

유연하고 강력한 시스템을 구축한다면 디자인이 좀 더 조화로워 지는 것을 경험할 것이다. cascade를 디버깅하기 위해 시간을 덜 쓰게 될 것이고, 웹사이트는 좀 더 빠르게 로딩될 것이다. 하지만 누가 알겠는가. 이 방법론이 전혀 맞지 않을 수도 있다. 내가 아는 것은 단지 현재의 방식이 전혀 작동하지 않는다는 것 뿐이다. 새로운 CSS를 작성하는 것은 새로운 규칙(역자 주: 팀의 규칙과 CSS의 각 클래스 정의가 모두 규칙이라고 불리는 것을 이용한 말장난)이 아니라 예외일 뿐이다.

정리하며

만약 최종 CSS 파일을 처음부터 끝까지 읽어 본 적이 없다면 그렇게 하길 추천한다. 나는 Salesforce의 CSS를 읽은 뒤로 수 많은 웹사이트의 CSS를 읽었다. 지금도 마찬가지다. 그렇게 하면서 새로운 것들을 배우고 있다.

하지만 이를 도그마(역자 주: 굳은 믿음, 신념. 일반적으로는 다른 사상 혹은 가치를 배척하려고 하는 믿음 체계를 말함)로 받아들이지는 마라. 내가 말하고자 하는 건 자신의 생각을 테스트해 보라는 것이다. 다른 사람이 새로운 코드를 추가하거나 오래된 코드를 리팩토링 하는 과정을 "지켜보는 것"만으로는 충분하지 않다. 유저 테스팅은 사람들이 어떤 식으로 뭔가를 사용하는지를 알 수 있는 좋은 방법이다. 그렇게 함으로써 대단한 프론트엔드 개발자의 코드 혹은 새로운 개발자의 코드를 통해 새로운 것들을 배울 수 있다. 내가 만약 최신 블로그 글 만을 뒤지거나 자리에 앉아서 생각만 했다면 이렇게 많은 것을 배울 수는 없었을 것이다. 현실에서는 다양한 경험을 가진 사람들이 코드를 작성하고 시스템은 이 모든 사람들을 위해 동작해야 한다.

지난 몇 년 간 나에게 훌륭한 피드백을 준 이들에게 감사를 표한다. 또한 기존의 best practices에 의문을 제기하고 내가 그렇게 할 수 있도록 도와준 이들에게 큰 감사를 표한다. 특히 @stubbornella, @necolas 그리고 @dam은 정말 큰 도움이 되었다.

번역 후기

저 또한 저자와 비슷한 생각을 한 적이 있기 때문에 큰 공감이 되는 글이었습니다. 저자의 경험과 마찬가지로 재 사용 가능한 클래스를 만들어 놓고는 며칠만 지나도 그 존재를 까먹고 다시 또 다시 같은 속성을 작성했죠.

저는 코드를 작성하다 보면 항상 비슷한 일이 일어난다고 생각합니다. JS 코드를 작성할 때도 재 사용 가능한 유틸리티 함수를 만들어 놓고는 금새 잊어버리고 다시 똑같은 코드를 작성하죠. 만약 팀 레벨로 일한다면 이런 상황은 더 자주 일어날 겁니다. 이는 결국 재 사용 가능한 코드가 있다는 사실을 모든 사람들이 기억할 수가 없기 때문이죠.

이런 상황을 타개할 수 있는 가장 좋은 방법은 어딘가에

1) 쉽게 찾아볼 수 있고,

2) 이름만 읽어 봐도 쉽게 그 기능을 유추할 수 있는

외부 코드 저장소를 두는 것이라고 생각합니다.

JS에서는 유틸리티 함수 라이브러리인 lodash를 사용하는게 한 가지 방법이 될 수 있을 것이고, CSS에서는 마찬가지로 유틸리티 클래스 라이브러리인 Tachyons나 TailwindCSS를 사용하는게 한 가지 방법이 될 수 있을 겁니다.

위 방법을 사용하면 물론 최종 번들 사이즈가 증가하게 됩니다. 하지만 웹팩과 같은 빌드 시스템을 사용하고 있다면 ES2015 모듈을 활용한 Tree Shaking을 통해 번들 사이즈를 줄일 수 있고, CSS의 경우에도 purgecss 같은 도구를 같이 사용한다면 번들 사이즈의 증가를 걱정하지 않아도 됩니다.

잘 드러나지 않는 또 다른 이점은 개발자의 생산성 향상입니다. 유틸리티 함수 라이브러리를 사용하면 새로운 유틸리티가 필요할 때마다 몇 시간을 써가며 새로운 코드를 작성하는 대신 이미 누군가가 고민하고 테스트 해놓은 코드를 쓸 수 있습니다. 또 HTML 마크업에서 패딩이나 마진을 수정하기 위해 새로운 규칙을 작성할 필요가 없죠. pl-2나 ma-3 같은 클래스를 HTML에 추가 하기만 하면 되니까요.

위 내용에 대해 조금 더 공부하고 싶으신 분들은 CSSconf EU 2019에서 Alex Tait이 발표한 Class Clash을 같이 보시면 좀 더 이해에 도움이 될 것입니다.