Sass: 파일 구조, 믹스인과 @extend

Sass란

Sass(Syntactically Awesome Style Sheets)는 CSS로 컴파일되는 전처리기다. 브라우저는 Sass를 모른다. 작성자와 .css 파일 사이에 끼어 변수, 중첩, 믹스인, 상속(@extend), 함수, 파일 분할을 제공한다. 흔히 .scss 문법(CSS와 같은 중괄호 문법)을 쓴다.

네이티브 CSS와의 역할 분담

CSS가 Sass의 대표 기능을 상당 부분 흡수했다.

Sass에 남는 강점은 믹스인, 반복문·조건문, 맵 같은 데이터 구조, 모듈 시스템, 빌드 시점 계산이다. 실행 중에 바뀌어야 하는 값(테마, 다크 모드)은 Sass 변수가 아니라 CSS 커스텀 속성이 맞다(CSS 커스텀 속성으로 색상 체계 짜기).

다른 전처리기와 PostCSS

전처리기의 공통 이점은 변수·중첩·믹스인으로 반복을 줄이고 파일을 나눠 구조를 잡는 것이고, 비용은 빌드 단계와 별도 문법을 팀 전체(디자이너·퍼블리셔 포함)가 익혀야 한다는 것이다. CSS가 변수와 중첩을 갖게 된 지금은 「전처리기 없이 네이티브 CSS + PostCSS(또는 Lightning CSS)」도 흔한 선택이다.

설치: 예전과 지금

공식 구현은 Dart Sass이고 Node 패키지로 설치한다. 과거에는 Ruby를 먼저 깔고 gem install sass로 Ruby Sass를 설치했지만, Ruby Sass는 2019년에 지원이 끝났다. C++ 구현인 LibSass(node-sass)도 2020년에 폐기됐다.

npm install -D sass
npx sass src/scss/main.scss dist/main.css --watch

Vite, Next.js 같은 빌드 도구는 sass 패키지만 설치하면 .scss 파일을 바로 불러온다.

파일 구조: 개발은 여러 파일, 배포는 한 파일

전처리기의 큰 이점은 성능 손해 없이 CSS를 여러 파일로 나눌 수 있다는 것이다. 개발 중에는 잘게 나누고, 배포할 때는 한 파일로 합친다. 널리 쓰이는 폴더 구조가 7-1 패턴(폴더 7개 + 진입 파일 1개)이다.

scss/
├─ base/        리셋(normalize), 기본 타이포그래피
├─ helpers/     변수, 함수, 믹스인, 플레이스홀더 (utils/, abstracts/라고도 부른다)
├─ layout/      헤더, 푸터, 사이드바, 그리드, 폼 같은 큰 뼈대
├─ components/  버튼, 캐러셀, 미디어 객체 같은 작은 모듈 (modules/)
├─ pages/       특정 페이지 전용 스타일 (_home.scss)
├─ themes/      여러 테마가 있을 때만
├─ vendors/     부트스트랩 등 외부 CSS. 직접 고치지 않는다
└─ main.scss    루트에는 이 파일 하나. 나머지를 불러오기만 한다

• 외부 라이브러리를 덮어쓸 때는 vendors 파일을 고치지 말고 vendors-extensions/ 같은 별도 폴더에 덮어쓰는 파일을 둔다.
• 특정 페이지에만 필요한 큰 스타일은 공용 번들에 합치지 않고 그 페이지에서만 불러올 수도 있다.
• 폴더는 한 단계면 충분한 경우가 많다. 구조가 낯설면 main.scss 옆에 README를 둔다.
• 황금률은 하나다. 팀이 모두 납득하는 구조를 고르고, 문서로 남긴다.

// main.scss: @import 대신 @use로 불러온다
@use 'helpers/variables';
@use 'base/reset';
@use 'layout/header';
@use 'components/button';

@use는 파일을 한 번만 불러오고 멤버에 네임스페이스를 붙인다(variables.$brand). 여러 파셜을 한 진입점으로 다시 내보낼 때는 @forward를 쓴다.

옮기는 작업은 공식 도구 sass-migrator(npx sass-migrator module --migrate-deps main.scss)가 대부분 자동으로 한다. 2026년 10월 기준 Dart Sass는 1.x대이며 3.0.0은 나오지 않았다. 일정은 Sass 공식 breaking changes 문서에서 확인한다.

파일과 규칙 안의 순서

Sass 구조는 배낭 꾸리기와 같다. 무겁고 자주 꺼내지 않는 것(글꼴, 색상처럼 전체에 영향을 주는 설정)을 먼저 넣고, 자주 바뀌는 작은 것을 위에 얹는다.

중첩이 깊으면 출력 선택자가 길어지고 특정도가 올라가 덮어쓰기 어려워진다(CSS 선택자와 우선순위).

믹스인과 @extend

둘 다 "반복을 없애는" 도구지만 출력이 다르다.

%btn-base { padding: .5em 1em; border-radius: 4px; font-weight: 600; }
 
@mixin button($bg) {
  @extend %btn-base;       // 고정 속성: 선택자 합치기로 한 번만 출력
  background: $bg;         // 바뀌는 속성: 호출마다 출력
}
 
.btn-primary { @include button($green); }
.btn-danger  { @include button($red); }

/* 출력 */
.btn-primary, .btn-danger { padding: .5em 1em; border-radius: 4px; font-weight: 600; }
.btn-primary { background: #2a8; }
.btn-danger  { background: #d33; }

DRY 믹스인은 이 아이디어를 끝까지 밀어붙인 패턴이다. 믹스인을 정적 부분과 동적 부분으로 나누고, 정적 부분은 처음 호출될 때 @at-root로 플레이스홀더를 만들어 그 뒤로는 확장만 한다. 이미 만든 플레이스홀더는 맵(map.merge)과 unique-id()로 기억한다. 작성자는 믹스인 하나만 부르고, 출력에서는 고정 속성이 한 번만 나온다.

이런 메타프로그래밍은 Sass 코드를 읽기 어렵게 만든다. 전송 시 gzip·Brotli 압축이 반복 속성을 상당히 줄이므로, 출력 크기가 실제 문제로 측정될 때만 도입한다.

@extend로 프레임워크 클래스를 숨기기

부트스트랩을 그대로 쓰면 HTML이 class="col-md-4 col-sm-6 row"처럼 보이는 모양을 설명하는 클래스로 가득 찬다. 프레임워크를 모르는 사람은 이 요소가 무엇인지 알 수 없다.

// HTML에는 의미만: <article class="author"> <img class="author__photo"> …
.author        { @extend .row; }
.author__photo { @extend .col-sm-3; }
.author__bio   { @extend .col-sm-9; }

• 가독성: HTML이 콘텐츠의 의미를 말한다.
• 재사용성: author 컴포넌트를 어디서나 같은 이름으로 쓴다.
• 이식성: 나중에 프레임워크를 바꿔도 HTML은 그대로 두고 Sass만 고친다.

이 방향은 겉모양을 클래스로 드러내자는 OOCSS와 정반대다. 둘의 장단은 객체 지향 CSS(OOCSS)에서 비교한다. 이름 규칙을 더 체계화하려면 BEM이나 SMACSS를 함께 쓴다.

정리

• Sass는 컴파일 시점의 도구다. 실행 중에 바뀌는 값은 CSS 커스텀 속성으로.
• 개발은 파셜로 잘게, 배포는 한 파일. base·helpers·layout·components·pages·vendors로 나누고 팀과 합의한다.
• 파일은 모듈 하나, 150줄 안팎, 중첩은 2~3단계까지.
• 변형이 필요하면 믹스인, 같은 스타일 공유는 @extend + 플레이스홀더. 둘을 섞으면 출력 중복을 줄일 수 있다.
• 지금은 Dart Sass(npm i -D sass)와 @use가 표준이다. @import와 전역 함수는 3.0.0에서 사라진다.

관련 노트: 객체 지향 CSS(OOCSS), CSS 커스텀 속성으로 색상 체계 짜기, CSS 선택자와 우선순위, React 스타일링: CSS Modules와 styled-components, CSS의 역사로 본 CSS가 어려워진 이유