SCSS(Sass) 사용법

사실 이 글은 SCSS를 어떻게 사용하는 지보다 만약 SCSS를 처음 사용하는 것을 가정하고 SCSS가 무엇이고 어떻게 동작하기 때문에 어떤 것이 필요한지 적어보려고한다. 그리고 이 글은 이 블로그 를 보고 작성했다.

Sass(SCSS) 완전 정복!

 

SCSS란? Sass는??

프로젝트나 서비스의 규모가 작을 때 CSS를 사용할 때는 문제점이 없지만 작업이 고도화되고, 방대해지고 복잡해 질 때 CSS의 단점이 드러난다. 하지만 웹에서는 표준 CSS 만 작동할 수 있기 때문에 다른 방법이 없다. 그래서 등장한 것이 Sass, Stylus, Less 와 같은 "CSS 전처리기" 들이다. 이 전처리기들은 CSS의 문법과 상당히 흡사하지만, selector 의 중첩이나 조건문, 반복문, 다양한 단위의 연산 등 표준 CSS로는 할 수 없는 기능들이 추가되어있다. 그러니 표준 CSS보다 훨씬 간편하고 다양한 코드를 작성할 수 있다. 

 

하지만 앞서 말했듯 웹에서는 표준 CSS 만 작동할 수 있기 때문에 표준 CSS로 변환하는 과정이 필요하다. 그러므로 이러한 전처리기를 사용할 때는 전처리기로 작성을 하고, 표준 CSS로 컴파일 하는 것이다. 컴파일을 하는 방법은 조금 이따가 다뤄보겠다. 다시 돌아오자면 Sass는 이러한 기능을 하는 전처리기의 일종이다. 그리고 앞서 말했던 Stylus, Less의 장점을 모두 가졌다하여 많은 사람들이 이용하고 있는 전처리기 이다.

 

그렇다면 SCSS는 무엇일까? SCSS는 Sass 3버전에서 새롭게 나온 전처리기 로써, CSS 구문과 완전히 호환되도록 새로운 구문을 도입해 만든 Sass의 모든 기능을 지원하는 CSS 수퍼셋이라고 볼 수 있다. 즉, SCSS는 CSS와 거의 같은 문법을 가지고 Sass 기능을 모두 지원한다는 말이다. 어찌되었든 Sass, SCSS, Stylus, Less 모두 전처리기의 일종이고 입맛에 맞추어, 혹은 회사가 사용하는 종류에 맞추어 사용하면 된다. 

컴파일 방법

앞서 말했듯 SCSS와 같은 전처리기는 웹에서 알아먹지 못하기 때문에 표준 CSS로 컴파일 하는 과정이 필요하다. 여러가지 방법들이 있지만 간추려서 몇개만 적어보겠다.

 

SassMeister

SCSS 코드가 조금만 들어간다거나 프로젝트의 규모가 작다면 컴파일러를 설치하는 것이 부담될 수 도있다. 그럴때 

이 사이트 를 사용할 수 있다. 

 

위와 같이 SCSS 문법으로 코드를 작성하면 CSS로 바로 변환해 준다. 적용전에 미리 결과를 보거나 연습해 볼때 사용하면 좋을 것 같다.

node-sass

Node.js 를 컴파일러인 LibSass에 바인딩한 라이브러리이다. 

$ npm install -g node-sass

$ node-sass [옵션] <입력파일경로> [출력파일경로]

위와과 같이 컴파일하려는 <파일의 경로>와 컴파일된 파일이 [저장될 경로]를 설정합니다. 옵션도 지정할 수 있는데

다음과 같이 --watch 혹은 -w 를 사용하면 런타임 중 파일을 감시하여 저장 시 자동으로 변경 사항을 컴파일한다.

$ node-sass --watch scss/main.scss public/main.css

 

Parcel

Parcel 이란 웹 어플리케이션 번들러이다. 번들러가 무엇인지는 아래의 내 블로그에 있는 글에서 간략하게 알아 볼 수있다.

pimpdevelop.tistory.com/9?category=890978

번들러 란 (모듈 번들러, webpack)

번들러에는 다양한 종류가 있다. 그중에서 Parcel은 별다른 설정없이 자동적으로 번들이 가능한 툴이다. 하지만 우리가 필요한 것은 컴파일러인데 왜 SCSS를 사용하는 컴파일 방법에 번들러가 등장한 것일까? 맨 처음에 말했듯 블로그글을 보고 작성하고 있었는데, 이 부분이 궁금해서 질문을 드렸다. 블로그 주인장분께서 정말 친절히 답변을 해주셨고 전체적인 답변을 요약하자면, 번들러는 번들을 할 뿐이고, 그 과정에서 무엇을 할 지는 webpack의 경우 Loader로 수행을, Rollup의 경우 Plugin으로 수행을, 그리고 Parcel의 경우 앞서 말했 듯 자동적으로 수행된다. Loader과 되었든, Plugin이 되었든 그 수행 과정을 사용자가 세팅 혹은 명령해야 하는 것이다.

 

그렇다면 Loader나 Plugin이 번들 과정 내에서 수행하는 일과 SCSS 컴파일과 무슨 관계가 있는 것일까? 번들은 저 블로그에서 다루듯 웹에 구성되어 있는 자원을 하나의 결과물로 만드는 역할을 한다. 그리고 스타일(CSS)의 경우 그 결과물은 모두 CSS일 것이다. 따라서 SCSS코드가 작성되어있는 경우 후처리를 위해 전처리, 즉 컴파일이 필요하고, Loader(webpack의 경우)는 이 코드를 보고 이렇게 생각할 것이다. "얘는 CSS로 변환해줘야하는데? 컴파일이 가능한 node-sass가 필요하겠군". 여기서 node-sass는 앞서 말한 컴파일러이며, Loader는 처리과정을 수행하며 필요한 모듈을 부르는 것(이 부분은 정확하게 설명을 못할 것 같다. 나중에 정확하게 알아볼 것이다.)이라고 볼 수 있다. 

 

그렇다면 SCSS를 컴파일하는 방법에 Parcel이라는 번들러가 사용될 수 있는 이유를 알 수 있다. 요약하자면

 

1. 번들러는 번들 하는 수행과정을 사용자가 명령 혹은 세팅하거나(webpack ...) 혹은 자동적으로 처리(Parcel할 수 있다.

2. 이 번들 의 수행과정은 Loadr나 Plugin이 처리한다.

3. 이 수행과정에서 컴파일이 필요한 SCSS 문법을 만났을 경우 컴파일링은 node-sass와 같은 실제 동작을 하는 모듈(이 경우 컴파일러)이 하게 된다.

4. 그러므로 별도의 세팅이 필요없이 자동적인 번들이 가능한 Parcel의 경우 컴파일을 직접할 필요없이 SCSS를 사용할 수 있다.

 

블로그 주인장님분이 "번들러는 번들만, Loader는 과정 처리만, 실제 기능은 해당 모듈이 한다" 라고 이해하면 생각하기 쉬울거라고 하셨고, 우선 그렇게 개념을 잡고 있으려고한다. 하지만 여기서 실제 기능을 담당하는 Loader도 있다고 하신 부분도 있고 물론 자세하게 알아보면 다른 부분들이 있을 거라고 생각하기 때문에 이에 대한 것은 나중에 다시 공부해보려고 한다.

 

 

SCSS의 사용방법에 대해서 찾아보다가 번들러가 어떻게 전처리까지 수행하는 지에 대해서도 알게 되었다. 하나를 찾으면 모르는 것이 열가지씩은 나오는 것 같은데 알아가는 재미가 있는 것 같다.