Sass 와 SCSS의 차이

안녕하세요, 씨앤텍시스템즈입니다.

 

프로젝트의 기획 단계에서 어떤 언어를 사용할 것인지는 앞으로의 프로젝트 진행에 대한 편리함을 줄 수도 있고, 어려움을 줄 수도 있습니다. 가장 중요한 것은 팀에서 사용하는 언어라는 것이지만, 만약 선택의 여지가 있다면 어떤 언어를 사용하는 것이 좋을까요?

 

상기 질문에 대하여 고민하던 중 CSS 전처리기 특히, Sass와 SCSS(Sassy CSS)에 대한 흥미로운 글을 발견하여 함께 공유하고자 합니다.

 

먼저 CSS 전처리기란, 규모가 상당한 웹 개발 프로젝트를 할 때 파일 용량이 커져 유지 보수가 힘들어지는 CSS의 단점을 개선하기 위해 개발되었습니다.

 

이 글에서는 Kitty Giraudel의 What's the Difference Between Sass and SCSS 포스트를 인용하여 CSS 전처리기 중에서도 Sass와 SCSS을 중점적으로 다뤄보겠습니다.

 

우리는 Sass를 보통 전처리기를 언급할 때 및 언어 그 자체를 말하는 것으로 인식합니다. 예를 들어, Sass에 대해 말할 때, ‘우리는 Sass를 사용합니다.’ 또는 ‘이 부분은 Sass의 mixin입니다.’라고 말합니다.

 

그동안에 전처리기인 Sass는 두 가지의 다른 문법syntax을 포용하는 말이 되었습니다.

• 들여쓰기indented 문법으로 알려진 Sass
• CSS 친화적인 SCSS

상기 두 가지 문법에 대해 각각 알아보도록 합시다.

---

Sass의 역사

Sass는 Haml이라 불리는 또 다른 전처리기의 일부였으며, Ruby 개발자에 의해 쓰였습니다. 이 때문에, Sass의 Stylesheet은 Ruby의 문법에 따라, 중괄호나 세미콜론 및 엄격한 들여쓰기가 사용되지 않게 되었습니다.

 

//Variable
!primary-color= black

//Mixin
=border-radius(!radius)
-webkit-border-radius= !radius
-moz-border-radius= !radius
border-radius= !radius

.my-element
color= !primary-color

width= 100%
overflow= hidden

.my-other-element
+border-radius(5px)

 

상기 코드에서, 사용자 지정 CSS 속성variable은 $이 아닌, !으로 사용되고, 지정(할당) 표시assignment는 :이 아닌, =으로 사용되는 것을 확인할 수 있습니다.

 

이상하게 보일 수도 있겠습니다만, 상기 코드는 실제로 2010년 5월까지 Sass가 세 번째 버전인 ‘끝내주는 문법’이라는 뜻의 SCSS로 불리는 완전히 새로운 문법으로 나타나기 전까지 사용되었던 Sass의 문법입니다. 이 문법은 사용자들에게 친숙한 CSS 문법을 가져옴으로써, Sass와 CSS 사이의 간극을 없애는 것을 목표로 하였습니다.

 

 //Variable 
$primary-color:  black;

 //Mixin 
@mixin border-radius(!radius) {
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;
}

.my-element {
    color: $primary-color;
    width: 100%;
    overflow: hidden;
}

.my-other-element {
@include border-radius(5px);
}

 

이러한 SCSS는 Sass 보다 CSS에 완전히 친화적이라고 볼 수 있습니다. 하지만, Sass 개발자(원문에서는 maintainer, 본문에서는 개발자로 칭함)는 들여쓰기 문법의 ! variable sign 및 = assignment sign를 SCSS의 $ 및 :으로 바꿈으로써, 각각의 두 문법이 서로 가까운 형태를 유지할 수 있도록 만들었습니다.

 

그렇다면 어떤 문법을 사용하면 좋을까요? Sass와 SCSS의 장점을 각각 살펴보도록 합니다.

---

Sass 들여쓰기 문법의 장점

Sass는 문법은 이상해 보이면서도 흥미롭다고 할 수 있습니다. 먼저, 타이핑하기에 더 쉽고 더 빠르다는 점입니다. 또한, 중괄호 및 세미콜론 등이 더 이상 필요 없으며, =나, +와 같은 하나의 문자로 표현이 가능할 때는 @mixin이나 @include는 필요하지 않습니다.

 

추가로, Sass 문법은 들여쓰기를 이용하여 Clean Coding 표준을 따르도록 합니다. 잘못된 들여쓰기는 .sass 의 Stylesheet이 망가질 수 있기 때문입니다. 이로 인해 코드가 항상 깨끗하고 잘 정돈될 수 있도록 합니다. 따라서, Sass코드를 작성하기 위한 방법은 ‘좋은 방법’ 하나밖에 없다고 해도 무방합니다.

 

이때, 주의가 필요한 점은 들여쓰기를 사용하는 것은 Sass에서만 특별한 의미를 가진다는 것입니다. Selector에 들여쓰기가 사용된다면, 이것은 이전 Selector에 포함nest되는 것을 의미합니다.

 

예를 들어, 아래와 같은 코드를 작성한다면,

 

.element-a
color: black

.element-b
float: left

 

CSS에서는 다음과 같이 인식할 것입니다.

 

.element-a {
    color: black;
}

.element-a .element-b {
    float: left;
}

 

 .element-b가 오른쪽으로 한 단계 밀려남으로써  .element-a의 자식 요소로 쓰여, CSS 결과가 달라지는 것을 알 수 있습니다.

 

원문의 필자는 이러한 들여쓰기 문법은 PHP/Java를 사용하는 팀보다 Ruby/Python을 사용하는 팀에게 적합할 것 같다는 의견입니다.

---

SCSS 문법의 장점

시작에 앞서, SCSS는 완전히 CSS를 따릅니다. 즉, CSS를 .scss 확장명으로 저장한다면, 그 파일은 작동할 것입니다. SCSS가 발표된 이래, SCSS가 CSS와 완전히 호환 가능하도록 만드는 것은 Sass 개발자에게 최우선 순위의 과제였습니다. 더 나아가, Sass 개발자들은 무엇이 CSS 문법으로 유효하게 될지에 대한 연구 또한 끊임없이 지속하고 있습니다.

 

SCSS가 CSS와 호환 가능하기 때문에 조금의 학습은 필요할 수 있지만, 많은 노력을 필요로 하지는 않습니다. 이 문법은 결국 몇 가지 첨가물을 더한 CSS라는 것이 이미 알려져 있습니다. 이 사실은 신입 개발자와의 협업에 있어서도 중요합니다. 처음에 Sass에 대해 알지 못하더라도 빠르게 코딩을 시작할 수 있을 것이기 때문입니다.

 

더 나아가, SCSS는 직관적입니다. 실제로도 그 자체만으로 이해가 가능하기 때문입니다. @mixin을 읽을 때는 mixin을 선언한다declare는 것을 알 수 있습니다. 같은 방법으로, @include를 읽을 때는 이것이 하나의 mixin을 호출한다call는 것을 알 수 있습니다. 이것은 빠른 방법을 위해서가 아닌, 읽히는 그 자체로 이해가 가능하도록 설계된 것입니다. 또한, Sass를 위한 Plugin 및 Demon과 같은 거의 모든 툴은 SCSS 문법을 사용하여 개발되었습니다. 시간이 흐름에 따라, 위와 같은 이유로 이 문법은 탁월하고 기본적인 선택이 되었습니다.

---

마무리하며,

필자는 그녀의 글에서 Sass 보다 SCSS를 사용하는 것을 추천한다고 말합니다. 그녀는 기본적으로 들여쓰기 문법으로 많은 작업을 해왔고 또한, 그녀의 모든 프로젝트를 Sass기반의 언어로 바꾸려 기획한 적이 있다고 말합니다. 하지만, 들여쓰기 문법을 사용했다면, 다른 툴과 함께 사용해야 하는 상황에서 많은 어려움을 겪을 것이라고 말합니다. 

---

인용 자료

• (번역) https://www.sitepoint.com/whats-difference-sass-scss/