CDD와 CSS의 변천사

 

🚩CDD가 뭔데요?

왜 프로그래밍엔 이렇게 축약어가 많을까요?

CDD라는 단어를 처음 본다면 생소하게 느껴질 수 있을 겁니다. Component-Driven Development의 약어라고 하면 조금 이해가 빠를지도요. 아이들이 레고를 조립하듯이 부품 단위로 UI 컴포넌트를 만들어 나가는 상향식 개발을 의미하는데, 사람들이 '재사용 가능한 UI 컴포넌트'에 초점을 맞추면서 CDD의 중요성이 떠오르기 시작했습니다.

 

흠... 그렇다면 왜 재사용이 중요해졌을까요. 그냥 만들면 되는 거 아닌가?... 라고 생각할 수도 있지만...

구조화된 CSS가 필요해진 이유는 오랜 CSS의 변천사와 발전 흐름을 짚어가면서 설명해야 합니다.

 

 

🚩태초에 CSS가 있었다...(feat 전처리기, 방법론)

css도 진화를 거듭한다.

기나긴 인류 역사처럼 기술의 발달은 CSS만 논외로 두지 않았습니다. CSS도 발전을 한다, 이 말이에요.

 

초기에는 가장 기본적인 CSS만이 있었습니다. 뼈대인 HTML을 꾸며주는 CSS는 혁신이었습니다. 보기 좋게, 더 예쁘게 꾸미면서 앞다투어 사람들은 개성을 자랑했습니다. 그런데 프로젝트 규모가 커지고 복잡해지는 과정에서 CSS를 작성하는 일관된 패턴이 없다는 것이 개발자에게 슬슬 걸림돌이 되기 시작했습니다. 심지어 모바일이나 태블릿 등 다양한 디바이스들이 우르르 등장하면서, 단일한 웹사이트여도 여러 종류의 디스플레이까지 커버해야 한다는 점 덕분에 CSS는 더더욱 끔찍해지고 말았죠. 

그러니 '우리 CSS도 좀더 효율적으로 구조화 해보자!'는 의견이 등장한 것은 이상하지 않습니다. 유사한 구조를 하나의 컴포넌트로 묶어두고, 그걸 가져다 여기저기 재활용 하는 아이디어는 프로그래밍에서 그리 낯설지 않잖아요?

 

CSS 전처리기

이때 등장한 것이 바로 위에 보이는 녀석들, 즉 CSS 전처리기였습니다. CSS Preprocessor들은 자신만의 특별한 syntax를 갖고 CSS가 구조적으로 작성될 수 있게 도와주는데요. 2006년에 나온 가장 이른 전처리기 SASS(후에 SCSS로 개선됨)는 CSS를 다룰 때 생기는 단점들을 커버해주고, 원하는 속성을 JS처럼 변수로 선언해서 재사용하게 해주는 등, 더 신속하며 깔끔하게 개발할 수 있게 해줍니다. 다만 전처리기로 작성된 파일은 SCSS형태로 되어 있어서 CSS로 변환해주는 '컴파일'이라는 과정을 거쳐야 합니다. 웹 서버는 CSS파일만 인지하거든요. 어쨌거나 컴파일을 해야 한다는 번거로움에도 불구하고 전처리기의 장점이 너무 확실했기 때문에 사람들은 한동안 CSS 전처리기에 의존하며 개발을 진행했습니다.

실제로 저도 SCSS는 자주 사용하는데, CSS와 비교가 안 되게 편리한 부분들이 있습니다... 어디에 뭐가 있는지 일일이 찾으러 다니는 것보다 제대로 구조화 되어 있어서 보기도 편하고, 속도도 빨라져요. 

 

하지만 CSS 전처리기에도 문제는 있었죠. 전처리기는 계층 구조를 통해 CSS의 구조화를 해결해주었지만, 그 과정에서 컴파일 된 CSS 용량이 어마어마하게 커지는 단점이 발생합니다. (왜 단점은 계속 생겨나는지...)

 

이 문제를 보완하기 위해 BEM, OOCSS, SMACSS와 같은 CSS 방법론이 떠오르기 시작합니다. 각각의 방법론들은 장단점을 갖지만 모두 '코드의 재사용' '유지보수 용이를 위한 간결화' '확장성' '예측성'을 지향한다는 점에서 동일했습니다.

 

BEM은 대표적인 CSS 방법론입니다. Block, Element, Modifier으로 구분해서 클래스명을 작성하는 방법인데요. 

https://keepinguptodate.com/pages/2020/05/bem-visually-explained/

위의 사진처럼 클래스명을 작성하면 됩니다. 저렇게 보면 참 쉽긴 한데.......

딱 보면 문제점이 보입니다. 클래스명 선택자가 너무 길어져요. 그리고 불필요하게 용량이 길어지고, 복잡해지고... 솔직히 저렇게 매번 확장해서 쓰라고 하면 재사용도 그렇게 쉽지는 않을 것 같습니다.

 

개발자들은 다시 새로운 방법을 찾아 헤매기 시작합니다.

"더이상 이렇게 캡슐화되지 않은 CSS를 쓸 수는 없어!"

 

 

 

🚩혜성같이 날아드는 CSS-in-JS (현대 웹 프로그래밍의 추세)

일단 개발의 발전에 따른 컴포넌트 단위의 개발이 중요해졌다는 사실은 알고 있을 겁니다.

'자주 반복되는 요소들은 하나의 컴포넌트로 묶어버린다. 그러면 재활용도 쉽고 유지 보수도 쉬워진다.'

개발자들은 바로 이 개념을 CSS에도 적용하기 시작합니다. 그러자 앞선 문제도 풀렸죠. 

 

CSS-in-JS의 대표로는 Styled-Component가 있습니다. 이 라이브러리는 기능적, 혹은 상태를 가진 컴포넌트들로부터 UI를 완전히 분리해서 사용할 수 있는 단순한 패턴을 제공합니다. 

 

다음 글에서 Styled-Component를 자세하게 파기에 앞서,

지금까지 배운 방법들의 장단점을 표로 표현하자면 아래와 같습니다.

	특징	장점	단점
CSS	기본적 스타일링 방법	-	일관된 패턴을 갖지 않음, !important의 남용
SASS(전처리기)	프로그래밍 방법론 도입, 컴파일 된 CSS를 만드는 전처리기	변수/함수/상속 개념을 써서 재사용 가능, CSS의 구조화	전처리 과정 필요, 디버깅에 어려움, 컴파일한 CSS파일이 큼
BEM(방법론)	CSS클래스명 작성에 일관된 패턴을 강제하는 방법론	네이밍으로 문제 해결, 전처리 과정 필요 없음	선택자 이름이 장황함, 클래스 목록이 너무 많음
Styled-Component (CSS-in-JS)	컴포넌트 기반으로 CSS를 작성하도록 도와준 라이브러리	CSS를 컴포넌트로 캡슐화, 네이밍이나 최적화 신경X	빠른 페이지 로드에 불리

 

 

출처: 

https://happydata.studio/stream/what-is-component-driven-design/

What is Component Driven Design (CDD)?

https://orezytivarg.github.io/css-evolution-from-css-sass-bem-css-modules-to-styled-components/