개요
저는 사실 CSS와 담을 쌓고 지냅니다. 웹 디자인이 깔끔한 것을 사랑하지만 제가 감히 다루려고 시도하면 폭탄이 되어버리는 관계죠. 그런데 거기서 더 진화된 SASS를? 박물관에 계시는 그림의 떡입니다. 저는 박물관을 즐겨찾지도 않으며 그림의 떡은 먹을 수 없는 떡이듯이요. 이미 훌륭하신 오픈소스 기여자분들께서 만들어둔 정성을 무시할 수 없었던 저는 직접 CSS를 디자인하는 일이 없었습니다.
근데 중요한 것은 이제 가르치는 입장이란 것입니다. 스승은 제자에게 답을 배울 수 있도록 길을 알려주는 존재이며 벽에 가로막혔을 때 넘을 수 있도록 조언을 주는 사람입니다. 제자가 배우고자 하는 것에 답을 해줄 수 없는 것은 스승으로서 가히 수치스럽다 할 수 있겠습니다. 성장하지 않는 스승은 성장하는 제자를 가르칠 자격이 없으니까요. 때문에 제자가 배우고자 하는 SASS를 스승으로써 아예 모르고 있을 순 없었습니다.
SASS 란?
Sass is the most mature, stable, and powerful professional grade CSS extension language in the world.
SASS는 세계에서 가장 성숙하고, 안정적이고, 강력한 전문등급을 가진 CSS확장 언어이다. 라고 하네요. 이런 건 뭐 누구나 자신의 모듈을 사용하게끔 하기 위한 광고일테니 넘어갑시다. 간단히 정리해서 SASS는 모든 CSS를 지원함과 동시에 더해서 추가적인 기능을 제공하는 CSS전처리기입니다.
다들 전처리기라고 하는데 저는 트랜스파일언어라고 설명하고 싶네요. 마치 타입스크립트처럼요! SASS는 고유 확장자 .scss, .sass를 파싱해서 .css 파일로 만드는 작업을 합니다. 실제 웹브라우저에서는 SASS가 아니라 CSS가 동작하는 거죠.
SASS를 쓰는 이유
그럼, CSS로 동작하는데 SASS를 사용하는 이유는 무엇일까요? 요즘 지원하는 게 너무 많아서 기능들을 정리하기엔 힘드니 간단한 장점 몇 개를 나열해봅시다.
변수 사용 가능
1 | $base-color: #c6538c; |
변수를 사용할 수 있다는 것은 유지보수 측변에서 CSS보다 훨씬 뛰어난 이점을 가지게 됩니다. 예를 들어 기본적인 테마 컬러를 변수로 등록해 두고 작업하다가, 테마 색깔을 변경하고 싶을 때 변수 선언한 부분만 변경해 주면 싹 바뀌니까요.
물론, 위와 같이 CSS에도 변수가 있기는 합니다만 SASS는 여기서 더 확장된 변수 선언이 가능합니다.
1 | @use "sass:map"; |
$theme-colors
변수를 맵 형태로 변수선언 후, SASS에서 기본 지원하는 map.get을 사용해 유동적으로 값을 가져올 수 있습니다.
2. 함수 사용 가능
1 | @function pow($base, $exponent) { |
함수를 사용한다는 것은 반복적인 계산식을 여러번 작성하는 대신 함수 하나로 끝낼 수 있는 것에 장점이 있습니다. 이 또한 개발 및 유지보수에서 큰 이점을 가져갈 수 있습니다. 계산식이 바뀌었을 때, 모든 부분을 찾아내서 수정하는 것 보단 함수의 내용을 한 번 바꾸는게 빠르니까요.
3. Mixin
1 | @mixin corner-icon($name, $top-or-bottom, $left-or-right) { |
mixin은 함수와 조금 다릅니다. 재사용 가능한 코드를 생성하는 것이 믹스인입니다.
한 마디로 정의하면 “찍어낼 수 있는 틀”이 되겠습니다.
C언어의 #define
이나 inline 함수
를 알고 있다면 이해가 쉽습니다. 내가 mixin 안에 넣어둔 내용을 그대로 호출한 부분에 작성하는 것이니까요. 만약 다음 SASS포스팅이 있다면 언제 한 번 다뤄보도록 합시다.
SASS와 SCSS의 차이
그 잘난 SASS님의 특징과 장점을 알아봤습니다. 근데 scss, sass. 뭐라고 불러야 될지 헷갈릴 정도로 많은 곳에서 혼용하며 사용하고 있습니다. 두 개의 차이가 뭘까요? 이름도 다르고 확장자도 다르지만 가장 먼저 눈에 띄는 것은 문법입니다. 이것은 SASS 공식 문서에서 설명하고 있습니다.
SCSS
1 | @mixin button-base() { |
SASS
1 | @mixin button-base() |
가장 눈에 띄는 것은 중괄호와 세미콜론의 유무입니다. SASS 문법은 들여쓰기로 문법을 파싱한다는 것이 파이썬과 비슷하네요! 의문점이 하나 있습니다. SASS 공식 문서에 왜 SCSS 설명이 있는 걸까요?
SCSS 는 Sassy CSS(Sass한 CSS)를 줄인 단어입니다. 원래 SCSS는 없었고 SASS만 릴리즈가 되었습니다. 근데 평소 개발자들이 배웠던 CSS와 다른 문법을 가지고 있던 SASS는 개발자들에게 큰 이점이 없어 등한시 되었습니다. 사실 같은 값이면 다홍치마라고, 진입장벽이 낮았던 Less를 사용하곤 했죠.
그래서 SASS개발자는 CSS문법과 유사한 SASS를 만들었습니다. 사실 SASS한 CSS가 아니라 CSS한 SASS였던 것이죠. 때문에 .scss
파일에서 .sass
문법을 사용해도 정상적으로 동작한다고 합니다.
사실 이 역사는 제가 어디선가 봤는데 정확한 증빙자료를 찾을 수가 없어 믿거나 말거나입니다. 그래도 SASS보단 SCSS를 더 많이 쓰게 되는 것은 사실입니다.
SASS 컴파일
사실 처음 SASS 컴파일러는 Ruby 언어로 만들어졌습니다. 분명 어디서 봤었는데 전 그것도 모르고 node-sass만 기억을 하고 있으니, 분명 cli도 노드일 것이다! 라고 어느 순간부터 잘못된 인지를 하고 있었죠. 얼마 전 플러터가 떡상하고 나서 다트 언어로 이루어진 dart-sass도 나왔습니다.
아무것도 모르는 상태에서 질문을 받으니 일단 대답부터 해야겠다는 생각이 강했습니다. 모른다고 하면 될 것을 굳이 한 마디라도 더 붙여서 정확한 전달을 하지 않으니 왜곡된 사실이 전달되는 것입니다. 제자가 노드 어쩌고 하는 것을 보면 마음이 아픕니다.
SASS 컴파일은, CLI 명령어를 사용하여 컴파일합니다.
1개의 SASS 파일을 컴파일 할 때
1 | $ sass [input.scss] [output.css] |
여러개의 SASS 파일을 컴파일 할 때
1 | $ sass [<input.css>:<output.css>] [<input/>:<output/>] [input.css] [input/]... |
사실 너무 직관적이라 어렵게 느껴지진 않습니다.
그리고 아무래도 개발할 땐 파일 변경점을 감지하고, 자동으로 컴파일하는 watch옵션을 많이 쓰게 되지 않을까 싶기도 합니다.
1 | $ sass --watch themes:public/css |
배포를 할 땐 공백이 없도록 minify하는 style옵션을 사용해서 컴파일해야 합니다.
1 | $ sass --style=compressed style.scss |
놀랍게도, scss가 css파일로 변경되어 출력됩니다. 우리는 출력된 css를 가져다 사용하면 되는 것입니다.
마무리
사실 이러니 저러니 해도 결국 직접 해보는 게 중요합니다. 백 번 눈으로 구경하는 것 보다 한 번 경험하는 게 배우는 것이 많으니까요. 원래 스타일은 모바일로 봤을 때 못생겨 보여서 글 스타일도 바꿔봤습니다.
아마 SASS를 다루는 글은 많이 작성하지 않을 것 같아 그냥 스터디에다가 꽁쳐둘려고요.