다른 서비스
NEW
기획
디자인
개발
프로덕트
아웃소싱
프리랜싱
비즈니스
최근 검색어
전체 삭제
최근 검색어가 없습니다.

개발

역사로 알아보는 CSS가 어려워진 이유: ②CSS in JS와 Atomic CSS

지난 글에서는 CSS의 역사를 돌아보며, CSS의 규모와 발전속도의 간극으로 인해 생기는 문제점들을 CSS의 스펙이나 CSS 내에서 해결하려는 시도를 살펴봤습니다. 이번 글에서는 JS와 Atomic CSS의 두 가지 갈래로 진화하고 있는 프레임워크와 번들 생태계를 살펴보려고 합니다.

 

CSS 수고했어... 이제는 JS가 해결해볼게!

CSS Modules, 2015

CSS의 Global Scope로 인해서 컴포넌트와 CSS 간의 구조와 범위가 일치하지 않는 문제를 JS를 통해서 해결하고자 하는 움직임이 생겼습니다. 그중 첫 번째 도구인 CSS Modules는 컴포넌트에서 CSS를 불러와서 컴포넌트에서만 적용이 될 수 있도록 컴파일을 해주는 도구였습니다.

 

CSS JS

 

CSS의 태생적인 문제를 JS를 통해 극복할 수 있게 되었고 본격적으로 JS와 CSS를 결합하려는 시도가 이어졌습니다.

 

CSS Modules를 통해서 CSS의 가장 고질적인 문제인 Global Scope에 대한 해결이 이루어졌습니다. 사실상 CSS Modules 등을 쓴다면 기존의 BEM과 같은 방법론이 더 이상 필요하지 않게 되기도 했습니다.

2019년까지만 하더라도 방법론들을 학습하는 것이 CSS 학습의 중요한 부분이었어요. 하지만 지금은 또 그렇지 않습니다. 결국 CSS가 가지고 있는 문제점은 CSS만으로 극복을 하는 데에는 한계가 있었기 때문입니다.

 

CSS in JS: Styled-Component, 2016

CSS는 다음과 같은 구조적인 문제를 지니고 있습니다.

Problems CSS

 

  • Global namespace: 모든 스타일이 Global에 선언되어 중복되지 않는 Class 이름을 적용해야 하는 문제
  • Dependencies: CSS와 JS 간의 의존관계를 관리하기 힘든 문제
  • Dead Code Elimination: 기능 추가, 변경, 삭제 과정에서 불필요한 CSS를 제거하기 어려운 문제
  • Minification: 클래스 이름의 최소화 문제
  • Sharing Constants: JS 코드와 상태 값을 공유할 수 없는 문제
  • Non-deterministic Resolution: CSS 로드 순서에 따라 스타일 우선순위가 달라지는 문제
  • Breaking Isolation: CSS의 외부 수정을 관리하기 어려운 문제(캡슐화)

 

CSS의 Global Scope와 Specificity문제는 CSS의 구조상 해결할 수 없는 문제였습니다. ’그렇다면 JS를 통해서 CSS를 만들게 되면 이러한 문제를 해결한 새로운 CSS를 만들어낼 수 있지 않을까?’ 하는 생각으로 CSS in JS가 탄생하였습니다.

 

CSS in JS

 

이러한 방식을 통해서 Specificity문제의 원흉인 Selector는 사라지게 되고 Property와 Value를 컴포넌트 구조에 맞게 작성을 하면 되게 되었습니다.

 

현재에 와서 Selector의 의미가 많이 퇴색이 된 이유입니다. Selector를 복잡하게 쓰게 되면 Specificity관리가 힘들어지게 되고 BEM도 마찬가지이지만 결국 하나의 Specificity를 갖는 방식으로 진화하고 있습니다.

 

지금까지의 CSS는 틀렸다, ‘TailwindCSS! 2017’

CSS 프레임워크

 

JS가 아닌 CSS 생태계에서 이를 해결하고자 하는 새로운 패러다임을 얘기하는 CSS프레임워크가 나타났습니다. 그것은 Utiliy-First라고 불리는 방식의 TailwindCSS였습니다. 사실 TailwindCSS가 새로운 개념은 아니었습니다. HTML과 CSS가 만들어졌을 초창기부터 Class에 유틸리한 이름을 붙여 개발하는 방식은 개발자들 사이에서 암암리에 행해지는 방식이었습니다. 하지만 시맨틱한 방식이 중요한 패러다임이 되면서 이러한 방식은 일종의 꼼수, 옳치 않은 방식으로 여겨졌기에 가급적 피하게 되는 안티 패턴이었습니다.

.mt10 { margin-top: 10px} 은 좋은 클래스인가?

Class name에 대한 고찰

의미있는 CSS 클래스 명을 써라

 

하지만 TailwindCSS는 이러한 방식을 오히려 일부 차용이 아니라 전면적으로 이러한 방식을 사용을 하는 것을 권장하며 패러다임 쉬프트에 성공하였습니다. 당연히 이러한 방식은 예시를 든 블로그의 내용을 보더라도 당시에는 받아들이기 아주 힘든 패러다임이었습니다. 그래서 Tailwind의 경우에는 초반에 반대로 굉장히 많았습니다.

 

TailwindCSS가 받아들여지는 데에는 예전과는 달리 다음과 같은 변화가 있었기 때문에 통용이 됩니다.

1) 웹 개발은 이제 대부분 솔루션 방식이 아니라 프론트가 직접 HTML과 CSS를 수정한다.

2) CSS로 개발하는 것보다 HTML을 다루는 게 더 편하며 사이드-이펙트가 적다.

3) 대부분 서비스들이 하나의 디자인 시스템을 가지고 여러 개의 스타일시트를 이용해서 테마를 만들 이유가 없다.

 

Atomic한 CSS는 모두 같은 Specificity한 Class로 구성이 되었으며 개발을 할 때에도 새롭게 CSS를 작성하지 않아도 되었기에 더 이상 추가적인 CSS의 관리가 필요하지 않다는 큰 장점이 있습니다.

 

무엇보다 이름을 짓기 위한 고민을 하지 않아도 되며(엄청 큰 장점입니다!) 또한 이미 만들어진 CSS는 서비스가 커지더라도 CSS의 양이 변화가 없기 때문에 대형 서비스 일 수록 CSS의 크기를 줄일 수 있다는 이점이 존재합니다.

 

워드프레스와 같이 HTML이 미리 고정이 되어있고 테마를 제공해야 하는 솔루션에서는 절대로 쓸 수 없는 기술이다 보니 초창기에는 많은 사람들에게 좋지 않은 방식이라고 부정당했습니다. 하지만 지금은 당당히 CSS의 구조적인 문제를 다룰 수 있는 방법으로 인정받고 가장 인기 있는 프레임워크가 되었습니다.

 

 

CSS Variables의 등장, 2017

Sass나 Less와 같은 PreProcessor의 등장 이유기도 했던 CSS에 변수를 쓸 수 있는 기능이 IE11 제외 모든 브라우저에서 사용을 할 수 있게 되었습니다. IE11 지원을 포기하고 새로운 CSS의 세상을 살기로 마음먹은 서비스들은 이제 더 이상 Sass를 써야 할 이유가 사라졌습니다.

 

복잡한 Selector는 CSS 구조상 이제 필요가 없어졌고, CSS Variable은 이제 CSS의 기본 기능이 되었습니다. Autoprefixer의 경우는 PostCSS가 대신할 수 있게 되었고 mixin과 같은 기능들은 CSS in JS에서 더욱 잘 지원할 수 있게 되었습니다.

IE11을 쓰지 않을거라면, CSS in JS를 할거라면, Atomic CSS를 쓴다면, 점점 Sass를 써야 하는 이유가 줄어들고 있습니다. 여전히 Sass는 CSS에서의 점유율이 높지만 서서히 대체 도구들이 등장하고 있는 중입니다.

 

GridLayout의 등장, 2017

2017년 드디어 Grid Layout이 등장하게 됩니다. 구상은 Flexbox보다도 훨씬 전에 논의되었지만 여러 가지 버전을 거쳐서 공개되었습니다. 하지만 IE의 시간은 2015년도에 머물러 있었기에 새롭게 만들어진 Grid Layout스펙과 IE에서 사용 가능한 Grid Layout의 경우 미묘하게 스펙이 달랐습니다.

 

그래서 GridLayout은 흥행을 실패합니다. 사람들은 골치 아프게 IE11에서 크로스 브라우징을 해야 하는 GridLayout에 비해 Flexbox로 충분히 대부분의 레이아웃을 작업할 수 있었기에 Grid Layout은 실험적인 기능에 그치게 되었습니다.

 

IE11 안녕~ 함께해서 더러웠고 다신 만나지 말자, 2020

MS에서 공식적으로 IE11의 지원종료를 발표하였습니다. IE11을 지원하지 않아도 된다는 사실을 못 박은 것이기 때문에, 사람들은 그동안 2015년에 묶여있었던 5년 치의 CSS를 한꺼번에 배워야 했습니다.

 

이제는 새로운 CSS의 스펙을 마음대로 쓸 수 있게 되었습니다. 흥행에 실패했던 GridLayout의 사용 점유율도 10%에서 50%로 올라왔습니다. 더불어, 아직 사용할 수 없는 수많은 스펙들이 새로 만들어지고 있습니다. 새롭게 지원해줄 스펙을 통해서 CSS를 더 좋게 만들 수 있는 방법들을 고민해볼 차례입니다. 물론 아직 그런 시대는 오지 않았습니다.

 

Figma, Sketch를 누르고 디자인 툴 1위가 되다, 2020

디자인 툴에 대한 지각변동이 발생하게 됩니다. Figma가 점유율 1위가 된 것은 아주 중요한 사건입니다. Figma는 디자이너뿐만 아니라 개발자와의 협업을 하기 위한 실시간 클라우드와 Zeplin과 같은 Handoff 기능을 겸하고 있습니다.

 

Figma는 AutoLayout과 같은 개발자적인 관점에서의 도구를 가지고 있습니다. 점유율 1위가 되면서 디자이너들이 대부분 선택하는 도구가 되고 Zeplin대신 Figma를 통해서 HandOff 및 디자인 리소스를 작업하게 되었습니다. Figma의 CSS Inspect는 아주 훌륭하며 디자이너와 함께 협업을 하기 위해서는 개발자들도 알아야 하는 도구입니다.

 

CSS in JS의 대유행, 2021

Styled-Component의 흥행과 React의 압도적인 점유율로 인해 CSS in JS는 새로운 강자를 찾는 중입니다. 런타임에 CSS를 생성한다는 문제점을 극복하기 위해서 Zero-Time CSS, Near Zero CSS와 같은 콘셉트를 들고 나오는 중입니다.

 

State 2021
State of 2021-2021 새로운 기술들은 대부분 CSS in JS에 몰려있다.

 

Satisfaction intezest
오래된 기술의 사용율이 높은 편이다.

 

usage awereness
다만 만족도의 순위는 엎치락뒤치락 중이다!

 

아직까지 Styled-Component가 절대적 강자의 자리를 지키고 있기에, 어떠한 라이브러리가 최종 승자가 될지는 좀 지켜보면서 천천히 이동해도 될 것 같습니다.

 

On-demand Atomic CSS!... 2021? 2022? 2023?

TailwindCSS는 미리 만들어둔 CSS만으로는 수치나 색상 입력에 한계가 있고, 이러한 부분들을 미리 설정을 해두는 방식으로는 한계가 있다는 지적을 받아왔습니다. 그래서 CSS를 미리 만들어 두는 방식이 아니라 AtomicCSS에 필요한 수치를 입력을 해두면 필요한 CSS를 자동으로 생성을 해두는 주문형(on-demand) Atomic CSS 패러다임으로 발전하고 있습니다.

 

그중에서도 UnoCSS의 성장세가 무섭습니다. Atomic-CSS 토픽에서 벌써 3위가 되었네요. 나머지 1위 2위는 모르셔도 됩니다. 정말 5~6년도 더 된 아주 아주 오래된 것들이기 때문에 얻은 Star라서요.

 

Atomic CSS
UnoCSS

 

제가 만들고자 했던 것과 콘셉트가 상당히 유사합니다. antfu는 개발을 참 잘하는 것 같습니다. vite를 함께 개발하는 코어 개발자인데 evan you와 함께 요새 안 만드는 게 없는 거 같아요.

 

Star 수를 보면 아직까지 Atomic-CSS, Functional-CSS, Utility-First라는 콘셉트 그리고 On-demand라고 하는 콘셉트 자체가 아직은 희귀해서 인기 자체가 좀 없는 느낌이기는 합니다.

 

유용태 라이브러리
developer-1px

 

Atomic-CSS 토픽에서 조금만 더 스크롤해보시면 제 라이브러리가 보입니다. 하하!!

주문형 Atomic-css

 

주문형 Atomic-css라는 콘셉트로 현업에서 잘 활용하고 있고 몇몇 동료 개발자분들이 좋다고 인정을 해주고 실제 본인 현업에서도 써주시는 분들이 계십니다. 많이 이용해 보고 의견 남겨주세요!

 

 

요약

너무 길었던 내용이라 중요한 내용만 복습해보겠습니다.

1) CSS는 문서에서 서식과 콘텐츠를 분리하기 위해서 만들어졌다.

2) 콘텐츠를 제공하는 솔루션을 기반으로 CSS를 커스텀하는 방식으로 발전했다.

3) 그로 인해 시맨틱 웹과 복잡한 Selector를 사용하는 방식으로 진화했다.

4) CSS의 규모가 커져가는데 CSS의 발전은 늦어지자 CSS의 문법을 확장시키고자 하는 방향으로 발전했다.

5) 백엔드는 데이터만 처리하는 웹 애플리케이션 방식으로 발전했다.

6) 문서를 만드는 방법으로 애플리케이션을 만들어야 하는 과도기를 겪었다.

7) Flexbox라는 애플리케이션을 위한 스펙들이 활성화되기 시작했다.

8) 컴포넌트를 기반으로 하는 프레임워크가 보편화되면서 CSS의 구조상의 문제가 드러났다.

9) Selector는 단순화되는 방향으로 진화하며 컴포넌트 개발방식에 맞는 CSS설계가 주요 아젠다가 되었다.

10) CSS 방법론은 BEM이 살아남았으나 CSS 구조의 한계를 느끼고 JS로 CSS의 부족함을 메꾸려는 방향으로 발전했다. - PostCSS, CSSModules, CSS in JS

11) CSS 자체적으로는 Utiliy-First라는 TailwindCSS가 새로운 대안으로 떠오르게 되었다.

12) IE11의 방파제가 무너지면서 Grid Layout이나 CSS Variable과 같은 CSS의 새로운 스펙들의 사용빈도가 높아지고 있다.

13) 현재는 CSS in JS, Atomic CSS 두 가지 갈래의 방향으로 프레임워크와 번들 생태계와 함께 진화 중이다.

 

 

끝으로

분명 이번 시리즈의 목적은 ’CSS의 역사를 이해해서 CSS 과도기 시기에 확대 재생산되었던 옛날 자료와 최신의 트렌드를 구분할 수 있고 본인의 상황에 맞는 도구를 찾기 위함’이라고 작성을 했지만 ‘목적에 충실한 글이었나’를 돌이켜 보게 되네요. 적어도 CSS의 역사를 돌아보고 그 과정에는 어떤 CSS가 있었는지 돌아보는 계기가 되었길 바랍니다.

 

 

<참고자료>

CSS Ecosystem

JS Tools & CSS-in-JS

[2013] PostCSS

[2014] Autoprefixer

[2014] Browserslist

[2014] JSS

[2015] CSS Modules

[2016] Styled Components

[2017] Emotion

댓글 0

테오의 프론트엔드

Svelte를 좋아하는 시니어 프론트엔드 개발자입니다. 카카오엔터프라이즈에서 프론트엔드를 통해 종합 업무 플랫폼을 만드는 것을 함께하고 있습니다. 개인적으로 Svelte+Rx 상태관리 라이브러리 Adorable과 Vite기반의 Rapid on-demand Atomic CSS 프레임워크인 AdorableCSS를 개발하고 있습니다.

같은 분야를 다룬 글들을 권해드려요.

요즘 인기있는 이야기들을 권해드려요.

일주일에 한 번!
전문가들의 IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.

일주일에 한 번! 전문가들의 요즘IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.