[CSS] Sass 와 Styled-components 비교 분석 + 직접 사용해보며 느낀점

Sass 와 Styled-components 비교 분석 + 직접 사용해보며 느낀점

[index]

1. Sass 특징

2. Styled-components 특징 

3. Sass와 Styled-components 코드로 비교해보기

4. css-in-css vs css-in-js 관점에서 비교해보기

5. 직접 사용해보며 느낀점 | 개인적인 견해

---

이번글은 주로 css in css와 css in Js의 차이를 중점으로 Sass 와 styled-components를 비교해보려고 합니다.

우선 Sass 와 styled-components 각각의 특징에 대해 간략하게 정리해보겠습니다.

 

1. Sass 특징 

Sass는 CSS in CSS 방식입니다. 흔히 HTML, JS, CSS는 관심사가 다른 개별적 요소로 보고 분리하는 것이 좋다고 여겨집니다. 따라서 CBD(Component Based Developement)방식이 아닌 경우, Sass를 쓰는 것이 적합할 수 있습니다. 기존의 CSS와 유사한 문법을 사용하여 학습 난이도가 낮다는 장점이 있습니다. 그리고 다양한 기능( 변수, 함수, 중첩된 선택자. 조건문 등등)을 사용하여 더 쉽고 유연하게 코드를 작성할 수 있습니다.

 

하지만 이러한 기능들로 인해 CSS 파일의 용량이 증가할 수 있고, 반드시 필요한 컴파일 과정에서 소요 시간이 증가할 수 있습니다. 또한 컴포넌트 변화에 따른 반응도가 떨어지고, 처음 렌더링 될 때 보이지않는 컴포넌트까지 스타일 정보를 불러오다보니, 불필요한 컴파일이 추가된다는 단점이 있습니다.

 

Sass에 대한 더 자세한 내용은 아래의 글을 참고해주세요.

https://reveur1996.tistory.com/71

[CSS] CSS전처리기 Sass & Scss + 직접 사용해보고 느낀점

 

 

2. Styled-components 특징

styled-components는 동일한 컴포넌트 내부에서 작성하는 CSS in JS 방식입니다. 따라서, CSS가 전역에 중첩되지 않도록 만들어주는 장점이 있으며 className에 대한 고민을 덜어줍니다. 또한, 컴포넌트 단위로 개발하기 때문에 CBD(Component Based Developement)방식을 지향하는 react와 궁합이 좋습니다.

 

하지만 CSS in JS 의 특성 상 컴포넌트가 렌더링 될 때마다 스타일 정보를 가져오게 되는데, 컴포넌트 상태값 전환이 활발한 동적인 웹사이트라면 추가적인 렌더링이 많아진다는 단점이 있습니다.

 

Styled-components에 대한 더 자세한 내용은 아래의 글을 참고해주세요.

https://reveur1996.tistory.com/137

CSS-in-JS Library | styled-components란? ( + 직접 사용해본 후 느낀점 )

 

 

3. Sass와 Styled-components 코드로 비교해보기

실제로 다른 두 프로젝트에서 유사한 형식으로 스타일을 적용하는 코드를 가져왔습니다.

작성하는 형식에서 차이가 보이시나요? 

Sass방식

 

Sass는 mixin 기능을 사용해 반복적으로 적용되는 스타일을 관리할 수 있습니다. flex를 예로 들자면 4줄에 걸쳐 작성되었던 코드를 실제 적용할 때는 1줄로 줄여 작성 할 수 있습니다. 아래의 스타일 적용 코드를 확인해보세요.

 

그리고 자주 사용하는 스타일들을 변수로 사용할 수 있습니다. 이 기능은 실제 프로젝트에서 컨벤션에 따라 일괄적으로 스타일을 수정해야 할 때 코드를 하나하나 찾아서 바꾸지않고  variables.scss의 변수 값을 변경하여 손 쉽게 수정했던 경험이 있습니다.  

styled-components 방식

 

위의 코드를 보시면, 전역으로 적용할 스타일을 적용하기 위해 createGlobalStyle을 사용한 것을 보실 수 있습니다. Sass 와는 달리 별도로 createGlobalStyle를 사용해야만 전역 스타일을 지정할 수 있습니다. 

 

그외 Sass에서 자주 사용하는 색상을 변수로 사용했던 것처럼 styled-components에서도 동일한 기능을 유사한 형식으로 사용할 수 있습니다. 하지만 실제 코드에 적용하는 방식에서는 다소 차이가 있습니다. 아래의 코드를 보시면 이해가 더 쉬우실 겁니다.

 

스타일 적용 코드 Sass(좌) styled-components(우)

 

Sass 방식의 경우 scss 파일에 사용하고자하는 스타일을 관리하고 있는 scss파일을 import하고 @include와 같은 명령어로 해당 스타일을 불러와 사용할 수 있습니다. 변수의 경우 $를 붙여 해당하는 변수를 바로 스타일에 적용할 수 있습니다.

 

styled-components 방식의 경우는 별도의 파일없이 컴포넌트 파일에서 바로 작성됩니다. 사용하고자하는 변수가 관리되는 theme파일을 따로 import하지 않고, 적용하고자하는 styled-component에 props로 받아와서 적용할 수 있습니다. 이 부분이 Sass와 코드 작성하는 방법에서 가장 차이나는 부분이라고 생각합니다.

(위의 코드에서는 Sass에서 flex를 mixin을 사용해 코드를 작성했던것과 달리 CSS 문법 그대로 작성하였습니다. 하지만 styled-components에서도 mixin을 사용할 수 있습니다.)

 

4. CSS-in-CSS vs CSS-in-JS관점에서 비교해보기

직접 작성한 코드를 통해 직관적으로 둘의 차이점을 비교해보았다면 이제는 CSS in CSS와 CSS in JS의 관점에서 비교해보겠습니다. 

 

4-1. CSS-in-CSSvs CSS-in-JS 특징 비교

CSS-in-CSS

CSS-in-CSS는 전통적인 CSS 방식을 가리키는 말로, 보통은 별도의 CSS 파일에 스타일을 작성하고 이를 HTML에 연결(link)하여 사용하는 방식을 말합니다. CSS를 모듈화 한다는 의미입니다.  CSS 클래스를 만들면 자동으로 고유한 클래스네임을 만들어서 scope를 지역적으로 제한합니다.  대표적으로 CSS Module, CSS 전처리기(Sass, Less  등)가 이 방식에 속합니다.

 

CSS-in-JS

CSS-in-JS는 자바스크립트 코드에서 CSS를 작성하는 방식입니다. CSS를 HTML에서 분리하여 자바스크립트 코드에 작성함으로써, CSS와 자바스크립트의 상호작용을 보다 쉽게 할 수 있습니다.  CSS를 JavaScript로 추상화하여 CSS와 JavaScript 코드를 함께 작성하고 관리할 수 있습니다.  대표적으로 Styled-components, emotion 등등의 라이브러리가 이 방식에 속합니다.

 

4-2. CSS-in-CSSvs CSS-in-JS 장단점 비교

 

CSS-in-CSS

CSS-in-CSS 방식의 장점

• 개발 생산성 향상 : CSS 전처리기를 사용하여 공통 요소나 반복적인 항목을 변수나 함수로 대체하여 개발 시간과 비용을 절약할 수 있습니다.
• 렌더링 성능이 향상 : CSS 파일이 별도로 로드되며, 이는 브라우저가 CSSOM (CSS Object Model)을 생성하게 합니다. CSSOM이 한 번 생성되고 나면, 다시 렌더링 될 때는 해당 스타일 시트를 다시 파싱할 필요가 없으므로 렌더링 성능이 향상될 수 있습니다.
• 유지보수 용이 : 모듈화된 CSS로 스타일시트 파일을 유지보수하기 쉽습니다. CSS 파일을 별도로 분리하여 관리할 수 있으므로, 개발자별로 CSS를 관리하기 쉽습니다.

CSS-in-CSS 방식의 단점

• 로드 순서에 따른 우선순위 변동: CSS 파일 로딩 순서에 따라 스타일 우선순위가 변동될 수 있는 문제가 있습니다.
• 미사용 코드 관리: 지속적인 리팩토링 중에 필요 없어진 CSS 코드를 적절하게 식별하기 어려울 수 있습니다. 
• 상태값 공유: JavaScript의 상태 값을 CSS와 공유하기 어렵습니다.
• CSS 파일들 간의 상호 의존성 관리: CSS 파일들 간의 상호 의존성을 효과적으로 관리하기 어렵습니다.
• 전역 스타일 : CSS 파일에 스타일을 작성하면 해당 스타일이 전역으로 적용되어, 특별한 클래스 명명 규칙을 사용해야 합니다.

CSS-in-JS

CSS-in-JS 방식의 장점

• 상수 및 함수 공유: 자바스크립트와 CSS 사이의 상수와 함수를 공유하여 코드를 더 효율적으로 관리할 수 있습니다.
• 개발 생산성 향상: JavaScript와의 통합으로 CSS를 간결하게 작성할 수 있어 생산성을 향상시킵니다.
• 유지보수성 향상: 컴포넌트별로 스타일을 직접 관리함으로써 컴포넌트 간 스타일 충돌을 방지하고 유지보수성을 향상시킵니다.
• 자바스크립트 통합: JavaScript 코드와의 통합을 지원하여 CSS를 동적으로 생성하거나 조작할 수 있습니다.
• 컴포넌트 레벨로 모듈성 강화: CSS-in-JS는 CSS 모델을 문서 레벨이 아닌 컴포넌트 레벨로 추상화하여 모듈성을 강화합니다.
• 클래스 자동 생성 및 코드 경량화: 짧은 길이의 유니크한 클래스를 자동으로 생성하여 코드를 더 경량화합니다.
• 확장성 강화: 다양한 기능을 제공하여 스타일링을 확장할 수 있습니다.
• 효율적인 성능: 필요한 스타일만 DOM에 포함하여 성능을 향상시킬 수 있습니다.

CSS-in-JS 방식의 단점

• 러닝 커브: 기존의 CSS를 사용하는 개발자들이 CSS-in-JS로 전환하는 데에는 학습 곡선이 존재합니다. 새로운 접근 방식에 적응하는 데 시간이 필요할 수 있습니다.
• 렌더링 성능 저하:  CSS-in-JS는 컴파일러를 거쳐야 하므로 개발 단계에서의 추가 작업이 필요합니다.  이로 인해 자바스크립트 로딩 이후에 CSS 코드가 생성되기 때문에 초기 다운로드 시간이 증가할 수 있습니다.  따라서 렌더링 성능이 저하될 수 있습니다. 컴포넌트가 렌더링될 때마다 스타일 정보를 다시 읽어와야 하기 때문에 렌더링 중복이 발생할 수 있습니다.
• 번들 크기 증가: CSS-in-JS 라이브러리를 사용하면 추가적인 자바스크립트 코드를 다운로드해야 하므로 번들 크기가 늘어납니다.
• 서버 사이드 렌더링(SSR) 복잡성: 일부 CSS-in-JS 라이브러리는 서버 사이드 렌더링과 함께 사용될 때 추가적인 설정과 처리가 필요할 수 있습니다.
• 인터랙션 지연: CSS-in-JS를 사용하면 인터랙티브한 웹페이지의 성능이 감소할 수 있으며, 사용자와의 상호작용에 딜레이가 발생할 수 있습니다.
• 유지보수 어려움: CSS-in-JS는 스타일과 관련된 로직을 JavaScript로 이동시키기 때문에 스타일과 컴포넌트 로직이 하나의 파일에 결합되어 있을 수 있습니다. 이는 코드를 읽고 유지보수하기를 어렵게 만들 수 있습니다.
• 의존성 추가: 새로운 라이브러리 도입으로 인한 의존성이 증가하게 됩니다.

 

간략하게 키워드만 표로 정리하면 아래와 같습니다.

	css-in-css	CSS-in-JS
장점	개발 생산성 향상 렌더링 성능이 향상 유지보수 용이	상수 및 함수 공유 생산성 향상 유지보수성 향상 자바스크립트 통합 컴포넌트 레벨로 모듈성 강화 클래스 자동 생성 및 코드 경량화 확장성 강화 효율적인 성능
단점	로드 순서에 따른 우선순위 변동 미사용 코드 관리 상태값 공유 SS 파일들 간의 상호 의존성 관리 전역 스타일	러닝 커브 렌더링 성능 저하 번들 크기 증가 서버 사이드 렌더링(SSR) 복잡성 인터랙션 지연 유지보수 어려움 의존성 추가

 

 

4-3. 키워드로 비교 정리

위의 내용들을 바탕으로 몇가지 키워드를 통해 더 쉽게 정리해보겠습니다.

	css-in-css	CSS-in-JS
개발생산성	공통 요소나 반복적인 항목을 변수나 함수로 대체하여 개발 시간과 비용을 절약
	단점 CSS와 JS간의 상태값 공유가 어려움  class 관리가 어려움 미사용 코드에 대한 관리가 어려움	장점 JavaScript와의 통합으로 CSS를 간결하게 작성할 수 있어 생산성을 향상 클래스 자동 생성 및 코드 경량화 컴포넌트 레벨로 모듈성 강화
유지보수성	장점 모듈화된 CSS로 스타일시트 파일. CSS 파일을 별도로 분리하여 관리.	장점 컴포넌트별로 스타일을 직접 관리 유지보수성을 향상
	단점 불필요한 코드 식별이 어려움. CSS 파일들 간의 상호 의존성 관리 어려움.	단점 스타일과 컴포넌트 로직이 결합되어 분리가 어려움
랜더링 성능	공통 추가적인 컴파일 작업이 필요합니다.
	장점 CSS 파일이 별도로 로드되고 CSSOM이 한 번 생성되고 나면, 다시 렌더링 될 때는 해당 스타일 시트를 다시 파싱할 필요가 없으므로 렌더링 성능 우수	장점 컴포넌트 렌더링시 필요한 스타일만 불러옴
	단점 초기 로드시 불필요한 스타일까지 모두 불러옴	단점 자바스크립트 로딩 이후에 CSS 코드가 생성되기 때문에 초기 다운로드 시간이 증가하고 이로 인해  렌더링 성능 저하
JS와의 관계성	단점 JS 상태값 공유가 어려움	장점 상수, 함수 공유 가능  동적 스타일 용이

 

 

4-4. 어떤 프로젝트에 더 적합할까?

CSS-in-CSS 방식은 다음과 같은 경우에 적합합니다.

• 큰 규모의 프로젝트를 개발하는 경우
• 분업에 용이한 구조를 원하는 경우
• 렌더링 성능을 최적화해야 하는 경우 (컨텐츠가 많은 웹 사이트일 경우)
• 랜더링 속도가 빨라야하는 인터렉티브한 프로젝트에 적합
• 별도의 자바스크립트 전환이 필요 없어 빠른 속도

 

CSS-in-JS 방식은 다음과 같은 경우에 적합합니다.

• 개발의 효율성이 중요한 컴포넌트 위주의 프로젝트에 적합
• 웹 컴포넌트를 개발하는 경우
• CSS와 자바스크립트의 상호작용이 용이한 구조를 원하는 경우
• CSS의 재사용성을 높이고 싶은 경우

 

5. 직접 사용해보며 느낀점 | 개인적인 견해 

 

컴포넌트 기반인가?

컴포넌트 기반의 개발 방식으로 계속해서 프로젝트를 진행해왔던 저로서는 CSS-in-JS 방식이 개발 과정에서는 훨씬 편리하다고 느꼈습니다. 또한 필요한 컴포넌트 페이지의 CSS 스타일 요소만 로딩한다는 점에서도 컴포넌트 중심의 개발 방식에 장점을 살릴 수 있다고 생각합니다.  CSS-in-CSS방식은 사용하지 않는 CSS 스타일 요소까지 로딩하기 때문에 비효율적일 수 있습니다. 

 

랜더링이 많이 발생하는 인터렉티브한 웹 사이트인가?

CSS-in-CSS 방식은 랜더링할 때 모든 CSS 스타일 요소를 로딩하기 때문에 컴포넌트 상태가 변하더라도 바로 적용이 가능합니다. 하지만 CSS-in-JS은 상태 변경으로 인한 랜더링 때마다 JS 파일 내의 CSS 코드를 파싱해야하기 때문에 성능이 떨어질 수 있습니다. 물론 컴포넌트 내에서 이루어지는 인터렉티브한 변화의 경우는 해당 컴포넌트만을 다시 그리기 때문에 문제가 되지 않을 수 있습니다. 따라서 지속적으로 영향을 받는 범위가 컴포넌트 단위로 나누어져서 컴포넌트 내부에서만 일어나는지, 전반에 걸쳐 일어나는지에 따라 어떤 것이 더 나은 선택인지 나뉠 것 같습니다. 

 

초기 로드 속도가 중요한 콘텐츠가 많은 웹 사이트인가? 

콘텐츠가 많은 웹사이트의 경우 초기 랜더링 되는 시간이 길어질 수 있습니다. 그리고 이때 얼마나 시간을 단축하여 사용자가 불편함을 느끼지 않게 하는지가 중요합니다.  CSS-in-JS를 사용할 경우 라이브러리를 설치해야하기 때문에 번들링 크기가 커져 초기에 속도가 느려질 수 있습니다. 그리고 JavaScript를 모두 불러와야만 CSS를 그릴 수 있기 때문에 사용자 입장에서 화면이 그려지기까지의 시간이 더 길어지게 되고 이로 인해 속도 저하를 체감하게 될 수 있습니다.

이를 개선하기 위해 서버사이드 랜더링을 사용한다고 해도 SSR를 위한 라이브러리를 설치해야하기 때문에 의존성과 초기 로드시 번들링의 크기가 커지는 것을 감안해야 합니다. 

 

개발 생산성과 유지 보수 측면은 양면적?

확실히 팀프로젝트로 진행하다보면 겪는 개발과정에서의 문제점들을 상당부분 해결할 수 있어 개발 생산성 측면에서는  CSS-in-JS 가 더 편리했습니다. 하지만 유지 보수 측면에서는 얀쪽 모두 장담점이 분명해 팀내의 우선순위에 따라 선택이 달라질 것 같습니다. 실제로 팀프로젝트를 할 당시 팀원들 사이에서도 의견이 갈렸던 부분이라 포거스를 어디에 두느냐에따라 장점도 단점이 될 수 있고, 단점도 장점이 될 수 있을 것 같습니다.  CSS-in-JS 방식의 경우 저는 CSS 파일을 분리하지 않고 컴포넌트 단위로 관리되어서 편리했지만  다른 팀원은 개발 과정에서 코드 가독성이 떨어져 불편함을 느꼈다고 했습니다. 저또한  이후 코드 리팩토링 과정에서 코드 가독성이 떨어진다는 것을 느낀 경험이 있습니다. 하지만 CSS-in-CSS방식이 더 가독성이 뛰어나다고 할 수도 없어 이 부분역시 상대적인 단점이라고 생각됩니다.

 

마지막으로...

최근 트렌드?(이미 몇년되어 최근이라고 하기 어려울수도 있지만)는 다시  CSS-in-JS에서 CSS-in-CSS 방식 혹은 Tailwind CSS와 같은 방식을 더 선호하는 것 같기도 합니다. 저 또한 최근 Tailwind CSS를 사용해보면서 왜 그런 움직임이 생기는지 조금은 알 것 같았습니다. (조만간 Tailwind CSS에 대해서도 글로 정리해보겠습니다.) 아무튼, Sass와 Styled-components 두가지 방식을 모두 사용해보며 느낀점으로는 두가지 모두 장점과 단점을 가지고 있고, 결국 중요한건 위의 4가지 질문에 어떤 것이 더 적합한가를 기준으로 팀 상황이나 프로젝트 기획에 맞게 선택하는 것이 중요하다는 생각이 들었습니다.  팀프로젝트를 하며 랜더링 속도와 관련해서 측정 비교해보았더라면 좀 더 유의미한 비교를 할 수 있었을텐데, 프로젝트 진행할 당시에는 그런 생각을 미처 하지 못해 아쉬움도 있습니다. 이후 프로젝트에서는 기획단계에서 이 부분을 고려하여 CSS 방식을 선정하도록 하겠습니다. 

---

참고 문헌

[css] scss vs styled-components 비교

Emotion vs SCSS vs Styled-components

업무를 하며 느낀 styled-component와 sass 컨셉

[TIL] scss, styled-components, emotion

에스코어

(번역) 우리가 CSS-in-JS와 헤어지는 이유

웹 컴포넌트 스타일링 관리 CSS-in-JS vs CSS-in-CSS | 인사이트리포트 | 삼성SDS

카카오웹툰은 CSS를 어떻게 작성하고 있을까? | 카카오엔터테인먼트 FE 기술블로그https://seizemymoment.tistory.com/145

https://andrejgajdos.com/css-modules-vs-css-in-js-vs-atomic-css-in-react-js/