Organizing your CSS

김동현·2026년 3월 18일

mdn 학습 번역 - CSS

목록 보기

18/190

안녕하세요! 프론트엔드 개발자라는 멋진 길을 걷고 계신 것을 진심으로 환영합니다. 오늘 우리가 함께 살펴볼 내용은 바로 'CSS 체계적으로 관리하기(Organizing your CSS)'입니다.

React, Next.js 등 최신 프레임워크를 다루더라도 결국 브라우저 화면을 그리는 것은 CSS입니다. 프로젝트가 커지면 커질수록 CSS 코드는 방대해지고, "이 스타일이 도대체 어디서 온 거지?" 하며 헤매는 일이 잦아지죠. 공식 문서의 내용을 하나도 빠짐없이 번역해 드리면서, 제가 실무에서 구르며(?) 얻은 꿀팁들도 함께 아낌없이 나눠드릴게요! 자, 시작해 볼까요?

CSS 체계적으로 관리하기 (Organizing your CSS)

점점 더 규모가 큰 스타일시트와 대형 프로젝트를 다루기 시작하면, 거대한 CSS 파일을 유지보수하는 일이 얼마나 만만치 않은지 깨닫게 될 것입니다. 이 문서에서는 CSS를 쉽게 유지보수할 수 있도록 작성하는 몇 가지 모범 사례(best practices)들을 가볍게 살펴보고, 다른 개발자들이 유지보수성을 높이기 위해 실제로 사용하고 있는 여러 해결책들도 알아볼 것입니다.


선행 조건 (Prerequisites):	기본 소프트웨어 설치, 파일 다루기에 대한 기본 지식, HTML 기초 (HTML 소개 공부하기), 그리고 CSS 작동 원리에 대한 이해 (CSS 스타일링 기초 공부하기).
학습 목표 (Objective):	스타일시트를 체계적으로 관리하는 팁과 모범 사례를 배우고, CSS 구조화 및 팀 협업을 돕기 위해 흔히 사용되는 명명 규칙(naming conventions)과 도구들에 대해 알아보기.

CSS를 깔끔하게 유지하는 팁 (Tips to keep your CSS tidy)

스타일시트를 체계적이고 깔끔하게 유지하기 위한 몇 가지 일반적인 제안 사항들을 소개합니다.

프로젝트에 코딩 스타일 가이드가 있나요? (Does your project have a coding style guide?)

만약 여러분이 기존 프로젝트에서 팀과 함께 일하게 되었다면, 가장 먼저 확인해야 할 것은 해당 프로젝트에 이미 정해진 CSS 스타일 가이드가 있는지입니다. 팀의 스타일 가이드는 항상 여러분 개인의 취향보다 우선시 되어야 합니다. 코딩에 무조건적인 정답이나 오답이 있는 경우는 드물지만, 가장 중요한 것은 '일관성(consistency)'이기 때문입니다.

예를 들어, MDN 코드 예제를 위한 CSS 가이드라인을 한번 훑어보시는 것도 좋은 참고가 될 것입니다.

일관성 유지하기 (Keep it consistent)

만약 여러분이 프로젝트의 규칙을 직접 정할 수 있는 위치에 있거나 혼자서 작업하고 있다면, 가장 명심해야 할 점은 일관성을 유지하는 것입니다. 일관성은 클래스 이름에 동일한 명명 규칙(naming convention)을 사용하거나, 색상을 지정하는 방식(Hex, RGB 등)을 하나로 통일하거나, 코드 포맷팅을 일정하게 유지하는 등 다양한 방식으로 적용될 수 있습니다. (예를 들어, 코드를 들여쓰기 할 때 탭(Tab)을 쓸 것인지 스페이스(Space)를 쓸 것인지? 스페이스를 쓴다면 몇 칸을 띄울 것인지?)

항상 따르는 명확한 규칙 세트가 있으면 CSS를 작성할 때 "이걸 어떻게 짜야 하지?" 하고 고민하는 정신적 소모(mental overhead)를 크게 줄일 수 있습니다. 이미 결정된 사항들이니까요.

💡 강사님의 실무 팁!
요즘 실무에서는 이런 '포맷팅(들여쓰기, 띄어쓰기 등)'을 사람이 직접 맞추지 않습니다. Prettier나 Stylelint 같은 코드 포매터/린터 도구를 프로젝트에 세팅해두고, 저장할 때마다 알아서 규칙에 맞게 코드가 정렬되도록 자동화하는 것이 표준입니다.

읽기 좋은 CSS 포맷팅 (Formatting readable CSS)

CSS를 포맷팅하는 데에는 개발자들마다 선호하는 몇 가지 방식이 있습니다. 어떤 개발자들은 아래처럼 모든 규칙을 한 줄에 몰아서 작성하는 것을 선호합니다:

.box {background-color: #567895; }
h2 {background-color: black; color: white; }

반면에 다른 개발자들은 각 속성과 값을 새로운 줄로 나누어 작성하는 것을 선호하죠:

.box {
  background-color: #567895;
}

h2 {
  background-color: black;
  color: white;
}

CSS 자체는 여러분이 어느 쪽을 쓰든 전혀 신경 쓰지 않습니다(둘 다 정상 작동합니다). 하지만 개인적으로는 각 속성과 값을 새로운 줄에 나누어 적는 것이 읽기에 훨씬 편하다고 생각합니다.

CSS에 주석 달기 (Comment your CSS)

CSS에 주석을 달아두면 나중에 여러분의 코드를 인계받을 미래의 개발자에게 큰 도움이 될 뿐만 아니라, 휴가를 다녀오거나 몇 달 뒤에 해당 프로젝트를 다시 열어볼 미래의 여러분 자신에게도 엄청난 도움이 됩니다.

/* This is a CSS comment
It can be broken onto multiple lines. */

아주 좋은 팁 하나를 드리자면, 스타일시트 내의 논리적인 구역들 사이에 주석 블록을 추가해 보세요. 이렇게 하면 코드를 쭉 훑어볼 때 각 구역을 빠르게 찾을 수 있고, 편집기의 검색(Search) 기능을 이용해 원하는 CSS 파트로 단번에 점프할 수도 있습니다. 코드 자체에는 쓰이지 않을 법한 특수 문자열을 주석에 포함시키면 검색하기가 훨씬 쉬워지죠. 아래 예제에서는 || 기호를 사용했습니다.

/* || General styles */

/* … */

/* || Typography */

/* … */

/* || Header and Main Navigation */

/* … */

물론 CSS의 모든 줄에 구구절절 주석을 달 필요는 없습니다. 대부분의 코드는 그 자체로 무엇을 하는지 명확하니까요(self-explanatory). 여러분이 주석을 달아야 할 곳은 '특별한 이유가 있어서' 특정한 결정을 내린 부분입니다.

예를 들어, 구형 브라우저와의 호환성 문제를 해결하기 위해 특정 CSS 속성을 썼다면 이렇게 남길 수 있겠죠:

.box {
  background-color: red; /* fallback for older browsers that don't support gradients */
  background-image: linear-gradient(to right, red, #aa0000);
}

혹은 어떤 특정 튜토리얼을 따라 하면서 구현했는데 CSS 코드가 직관적이지 않고 난해한 경우도 있을 겁니다. 그럴 때는 주석에 해당 튜토리얼의 URL을 남겨두세요. 1년쯤 뒤에 이 프로젝트를 다시 열었을 때, "아, 이거 엄청 유용한 튜토리얼 보고 만든 건데 어디서 봤더라..." 하고 기억을 더듬으며 고통받는 미래의 여러분을 구원해 줄 것입니다.

스타일시트를 논리적인 구역으로 나누기 (Create logical sections in your stylesheet)

스타일시트의 맨 윗부분에는 모든 요소에 전역적으로 적용되는 공통 스타일을 먼저 두는 것이 좋습니다. 즉, 해당 요소에 뭔가 특별한 스타일을 추가로 덮어씌우지 않는 한 기본적으로 적용될 스타일들을 말하죠. 보통 다음과 같은 태그들에 대한 규칙을 설정합니다:

body
p
h1, h2, h3, h4, h5
ul 과 ol
table 속성들
링크 (a 태그)

이 구역에서는 사이트 전체의 폰트(타이포그래피) 기본 스타일을 제공하고, 데이터 표(table)나 목록(list) 등에 대한 기본 디자인을 세팅합니다.

/* || GENERAL STYLES */

body {
  /* … */
}

h1,
h2,
h3,
h4 {
  /* … */
}

ul {
  /* … */
}

blockquote {
  /* … */
}

이 공통 구역 다음에는 유틸리티(utility) 클래스들을 정의해 볼 수 있습니다. 예를 들면, Flexbox를 적용할 목록이나 특별한 용도로 쓰일 목록에서 기본 점(bullet) 스타일을 제거해 주는 클래스 같은 것들 말이죠. 사이트 곳곳에 있는 수많은 요소에 공통적으로 적용하고 싶은 스타일링 옵션이 있다면 이 구역에 모아두세요.

/* || UTILITIES */

.no-bullets {
  list-style: none;
  margin: 0;
  padding: 0;
}

/* … */

그다음으로는 사이트 전반(sitewide)에 걸쳐 사용되는 요소들을 추가할 수 있습니다. 기본적인 페이지 레이아웃, 헤더(header), 내비게이션 스타일 같은 것들이 여기에 들어갑니다.

/* SITEWIDE */

.main-nav {
  /* … */
}

.logo {
  /* … */
}

마지막으로, 사용되는 문맥(context), 페이지, 혹은 특정 컴포넌트에 따라 분류된 구체적인 CSS를 포함시킵니다.

/* || STORE PAGES */

.product-listing {
  /* … */
}

.product-box {
  /* … */
}

이렇게 순서를 정해서 코드를 구성해 두면, 적어도 내가 바꾸고 싶은 스타일이 스타일시트의 어느 구역쯤에 있을지 쉽게 예상할 수 있어 유지보수가 훨씬 수월해집니다.

과도하게 구체적인 선택자 피하기 (Avoid overly-specific selectors)

선택자(selector)를 너무 구체적으로 만들면, 나중에 다른 요소에 똑같은 스타일을 적용하고 싶을 때 CSS 코드를 그대로 복사해서 붙여넣기 해야 하는(중복 코드 발생) 귀찮은 상황이 자주 발생합니다. 예를 들어, main이라는 클래스를 가진 <article> 안의 box라는 클래스를 가진 <p> 태그에만 스타일을 적용하려고 아래와 같은 선택자를 썼다고 가정해 봅시다.

article.main p.box {
  border: 1px solid #cccccc;
}

그런데 나중에 이 규칙을 main 바깥에 있는 요소나, <p> 태그가 아닌 다른 요소에도 똑같이 적용하고 싶어진다면 어떻게 될까요? 기존 규칙에 새로운 선택자를 쉼표로 연결해서 추가하거나, 아예 똑같은 내용의 새로운 규칙 세트를 만들어야만 합니다. 그 대신, 처음부터 그냥 .box라는 깔끔한 클래스 선택자를 사용해서 box 클래스를 가진 모든 요소에 규칙이 적용되도록 만들 수 있습니다:

.box {
  border: 1px solid #cccccc;
}

물론 선택자를 매우 구체적으로 만들어야만 하는 상황도 분명히 존재합니다. 하지만 그것은 일반적인 관행이라기보다는 '예외적인 상황'으로 취급하는 것이 좋습니다.

💡 강사님의 실무 팁!
나중에 CSS 명시도(Specificity) 점수를 계산하는 법을 알게 되시겠지만, article.main p.box 처럼 선택자를 엮어서 길게 쓰면 점수가 아주 높아집니다. 이렇게 높은 점수의 스타일을 나중에 모바일 화면에서 바꾸려고 하면 더 긴 선택자를 쓰거나 !important를 남발해야 하는 악순환에 빠지게 되죠. 클래스 하나만 심플하게 쓰는 것을 생활화하세요!

거대한 스타일시트를 여러 개의 작은 파일로 쪼개기 (Break large stylesheets into multiple smaller ones)

사이트의 여러 파트마다 완전히 다른 독자적인 스타일을 가지고 있다면, 모든 전역 규칙을 담은 글로벌 스타일시트 하나와, 특정 섹션에만 필요한 규칙들을 담은 여러 개의 작은 스타일시트로 파일을 나누는 것을 고려해 보세요. HTML 페이지 하나에서 여러 개의 스타일시트를 링크(link)로 불러올 수 있으며, 나중에 링크된 스타일시트의 규칙이 먼저 링크된 스타일시트의 규칙보다 우선한다는 CSS의 캐스케이드(Cascade) 기본 원칙이 그대로 적용됩니다.

예를 들어, 웹사이트 안에 온라인 스토어가 포함되어 있다면, 상품 목록이나 스토어용 결제 폼 등을 꾸미는 데만 쓰이는 많은 양의 CSS가 존재하겠죠. 이런 스타일들은 별도의 파일로 분리하여 오직 스토어 페이지에서만 불러오도록(link) 하는 것이 합리적입니다.

이렇게 하면 CSS를 체계적으로 관리하기가 쉬워집니다. 또한 여러 명의 개발자가 CSS를 동시에 작업할 때, 두 사람이 똑같은 스타일시트 파일을 동시에 건드려서 버전 관리 도구(Git 등)에서 코드 충돌(conflicts)이 일어나는 골치 아픈 상황도 줄일 수 있습니다.

도움을 줄 수 있는 다른 도구들 (Other tools that can help)

CSS 언어 자체에는 코드를 구조화하고 조직하는 기능이 내장되어 있지 않습니다. 따라서 CSS 코드의 일관성과 구조는 전적으로 여러분의 역량에 달려있습니다. 이를 돕기 위해 웹 개발 커뮤니티는 거대한 CSS 프로젝트를 관리할 수 있는 다양한 도구와 방법론들을 개발해 왔습니다. 여러분이 다른 사람들과 협업하다 보면 필연적으로 이런 도구들을 마주하게 될 것이고, 개인 프로젝트에서도 큰 도움이 되기 때문에 여기서 간단히 소개해 드리겠습니다.

CSS 방법론 (CSS methodologies)

CSS를 작성하기 위해 자신만의 규칙을 밑바닥부터 끙끙대며 새로 짜는 대신, 이미 수많은 프로젝트에서 검증되고 커뮤니티에 의해 디자인된 '방법론(approaches)' 중 하나를 도입하는 것이 훨씬 유리할 수 있습니다. 이러한 방법론들은 본질적으로 CSS를 아주 체계적이고 구조화된 방식으로 작성하고 관리하도록 돕는 '코딩 가이드'입니다. 이런 방법론을 쓰면, 프로젝트에 맞춰 커스텀 선택자를 완벽하게 최적화해서 짤 때보다 CSS 클래스 이름이 조금 길고 수다스러워지는(verbose) 경향이 있습니다.

하지만 방법론을 도입하면 엄청난 구조적 안정성을 얻을 수 있습니다. 대부분 널리 알려진 시스템이므로, 새로운 개발자가 팀에 합류하더라도 여러분만의 독창적인(?) 비밀 규칙을 처음부터 다시 가르칠 필요 없이, 기존에 알던 방식대로 빠르게 코드를 이해하고 작성할 수 있게 됩니다.

OOCSS (객체 지향 CSS)

여러분이 마주치게 될 대부분의 방법론은 Nicole Sullivan의 작업으로 유명해진 객체 지향 CSS(Object Oriented CSS, OOCSS)의 개념에 빚을 지고 있습니다. OOCSS의 기본 아이디어는 CSS를 재사용 가능한 객체(objects)로 분리하여 사이트 어디서든 필요할 때 가져다 쓰는 것입니다. OOCSS의 가장 대표적인 예시가 바로 미디어 객체(The Media Object)라 불리는 패턴입니다. 이는 한쪽에는 고정된 크기의 이미지나 비디오가 있고, 반대쪽에는 유연하게 늘어나는 텍스트 콘텐츠가 있는 형태를 말하죠. 댓글 창, 리스트, 게시물 등 웹사이트 곳곳에서 정말 흔하게 볼 수 있는 패턴입니다.

만약 OOCSS 방식을 쓰지 않는다면, 이 패턴이 쓰이는 곳마다 일일이 커스텀 CSS를 만들었을 것입니다. 예를 들어, 댓글 영역의 부품들을 정의하는 comment라는 클래스와, 이와 거의 동일하지만 아주 미세하게 다른 list-item이라는 또 다른 클래스를 만들었겠죠. 이 두 컴포넌트의 유일한 차이점은 list-item에는 하단에 테두리(bottom border)가 있고, comment 안의 이미지에는 테두리가 있지만 list-item 이미지에는 테두리가 없다는 것뿐일 텐데 말입니다.

.comment {
  display: grid;
  grid-template-columns: 1fr 3fr;
}

.comment img {
  border: 1px solid grey;
}

.comment .content {
  font-size: 0.8rem;
}

.list-item {
  display: grid;
  grid-template-columns: 1fr 3fr;
  border-bottom: 1px solid grey;
}

.list-item .content {
  font-size: 0.8rem;
}

OOCSS를 도입하면, 우리는 media라는 하나의 베이스 패턴을 만들어서 두 컴포넌트에 공통으로 들어가는 CSS를 모아둡니다. 즉, 미디어 객체의 기본적인 '모양(shape)'을 담당하는 뼈대 클래스를 만드는 것이죠. 그런 다음, 이 두 컴포넌트의 아주 미세한 차이점을 처리하기 위한 추가적인 클래스를 부여하여 특정 방식으로 뼈대를 '확장(extending)'합니다.

/* 공통 뼈대 (Base Object) */
.media {
  display: grid;
  grid-template-columns: 1fr 3fr;
}

.media .content {
  font-size: 0.8rem;
}

/* 특정 차이점만 확장 (Modifiers) */
.comment img {
  border: 1px solid grey;
}

.list-item {
  border-bottom: 1px solid grey;
}

이제 HTML에서 댓글을 작성할 때는 media와 comment 클래스를 모두 적용해야 합니다:

<div class="media comment">
  <img src="" alt="" />
  <div class="content"></div>
</div>

리스트 아이템(list-item)을 작성할 때는 media와 list-item 클래스를 적용하고요:

<ul>
  <li class="media list-item">
    <img src="" alt="" />
    <div class="content"></div>
  </li>
</ul>

Nicole Sullivan이 이러한 접근법을 설명하고 널리 알린 덕분에, 오늘날 엄격한 OOCSS 원칙을 100% 따르지 않는 개발자들조차도 기본적으로 CSS를 이런 식으로 재사용하고 있습니다. 이제는 이 방식이 CSS를 다루는 아주 훌륭하고 보편적인 상식으로 자리 잡은 셈이죠.

BEM

BEM은 Block(블록) Element(요소) Modifier(수정자)의 약자입니다. BEM에서 블록(Block)은 버튼, 메뉴, 로고처럼 스스로 독립적으로 존재할 수 있는 개체를 뜻합니다. 요소(Element)는 리스트 아이템이나 제목처럼 자신이 속한 블록에 종속된 부분입니다. 마지막으로 수정자(Modifier)는 블록이나 요소의 외형이나 상태를 바꿔주는 플래그(flag) 역할을 합니다. CSS 클래스 이름에 하이픈(-)과 언더스코어(_)가 잔뜩 들어간 것을 본 적이 있다면, 그게 바로 BEM 방식을 사용한 코드입니다. 예를 들어, BEM 명명 규칙(Naming conventions) 공식 페이지에 있는 다음 HTML 구조를 살펴볼까요?

<form class="form form--theme-xmas form--simple">
  <label class="label form__label" for="inputId"></label>
  <input class="form__input" type="text" id="inputId" />

  <input
    class="form__submit form__submit--disabled"
    type="submit"
    value="Submit" />
</form>

여기서 클래스들을 추가한 방식은 앞서 살펴본 OOCSS 예제와 결이 비슷하지만, BEM만의 엄격한 이름 짓기 규칙이 적용되어 있습니다. (__는 요소를 의미하고, --는 수정자를 의미합니다. form__submit--disabled는 "form 블록 안의 submit 요소인데 현재 disabled 된 상태야!"라는 뜻이죠.)

BEM은 전 세계의 수많은 대규모 웹 프로젝트에서 폭넓게 사용되고 있으며, 지금도 많은 개발자가 이 방식으로 CSS를 작성합니다. 웹에서 각종 튜토리얼을 보시다 보면 왜 CSS 클래스 이름을 저렇게 기괴하게(?) 지었는지 설명도 없이 BEM 문법을 사용하는 예제들을 흔하게 만나보실 수 있을 겁니다.

이 시스템에 대해 더 자세히 알고 싶으시다면 CSS Tricks의 BEM 101 문서를 읽어보세요!

💡 강사님의 실무 팁!
"와, 클래스 이름이 저렇게 길어지면 너무 지저분한 거 아니에요?"
네, 처음에는 그렇게 느낄 수 있습니다. 하지만 컴포넌트 단위로 개발하는 React 같은 환경에서 BEM을 쓰면, CSS 파일 간에 클래스 이름이 충돌해서 화면이 와장창 깨지는 대참사를 완벽하게 막아줍니다. 클래스 이름만 봐도 이 스타일이 어느 컴포넌트에 쓰이는지 단번에 알 수 있는 엄청난 장점이 있어요.

기타 널리 쓰이는 시스템들 (Other common systems)

이 외에도 현업에는 수많은 시스템이 존재합니다. Jonathan Snook이 고안한 SMACSS(Scalable and Modular Architecture for CSS), Harry Roberts의 ITCSS, 그리고 원래 Yahoo!에서 만든 Atomizer CSS (ACSS) 등이 대표적입니다. 새로운 프로젝트에 투입되었는데 이런 방법론 중 하나를 사용하고 있다면 당황하지 마세요. 해당 스타일로 코딩하는 법을 친절하게 설명해 주는 수많은 문서와 가이드를 구글에서 쉽게 찾을 수 있다는 것이 큰 장점이니까요.

다만 이런 거창한 방법론의 단점은, 아주 작고 간단한 프로젝트에 도입하기에는 설정이나 규칙이 너무 과하고 복잡하게(overly complex) 느껴질 수 있다는 점입니다.

CSS를 위한 빌드 시스템 (Build systems for CSS)

CSS를 조직적으로 관리하는 또 다른 차원의 접근법은 프론트엔드 개발자들을 위해 만들어진 도구(Tooling)들을 적극 활용하는 것입니다. 이 도구들을 쓰면 CSS를 조금 더 프로그래밍 언어처럼 다룰 수 있게 해 줍니다. 크게 전처리기(pre-processors)와 후처리기(post-processors)로 나눌 수 있는데요. 전처리기는 여러분이 작성한 특수한 코드를 읽어서 브라우저가 이해할 수 있는 순수한 CSS 파일로 변환해 주는 녀석이고, 후처리기는 완성된 CSS 파일을 가져다가 더 빠르게 로딩되도록 압축하는 등 모종의 최적화 작업을 해주는 녀석입니다.

이러한 도구들을 사용하려면 개발 환경에 전처리나 후처리를 실행할 수 있는 스크립트 실행 환경(Node.js 등)이 구축되어 있어야 합니다. 요즘 많은 코드 에디터(VS Code 등)가 이런 작업을 알아서 해주는 플러그인을 제공하기도 하고, 커맨드 라인 툴(CLI)을 직접 설치해서 사용할 수도 있습니다.

가장 대표적이고 인기 있는 전처리기가 바로 Sass입니다. 이 글이 Sass를 본격적으로 가르치는 튜토리얼은 아니기 때문에, Sass가 가진 수많은 기능 중 다른 건 안 쓰더라도 코드 관리에 있어서만큼은 기가 막히게 유용한 두 가지 기능만 짧게 소개해 드리겠습니다. Sass에 대해 더 깊이 파고들고 싶다면 Sass basics (기초) 문서를 먼저 읽고 공식 문서를 둘러보시길 바랍니다.

변수 정의하기 (Defining variables)

요즘은 순수 CSS에도 기본적으로 커스텀 속성(CSS 변수) 기능이 생겨서 전처리기의 변수 기능이 예전만큼 절대적이진 않습니다. 하지만 예전부터 개발자들이 Sass를 썼던 가장 큰 이유 중 하나가 바로 프로젝트에 쓰이는 모든 색상과 폰트들을 상단에 '설정값(변수)'으로 정의해 두고, 프로젝트 전역에서 그 변수 이름을 불러다 쓰기 위해서였습니다. 이렇게 해두면 나중에 디자이너가 "아, 이 파란색 너무 칙칙한데 좀 더 밝은 톤으로 다 바꿔주세요"라고 했을 때, 수백 줄의 CSS를 뒤질 필요 없이 변수가 정의된 단 한 곳의 색상값만 바꾸면 모든 곳에 자동으로 적용되거든요!

아래 코드의 첫 번째 줄처럼 $base-color라는 변수를 만들었다면, 스타일시트 어디서든 그 색상이 필요한 곳에 해당 변수를 가져다 쓸 수 있습니다.

$base-color: #c6538c;

.alert {
  border: 1px solid $base-color;
}

이 Sass 코드를 컴파일(변환)하고 나면, 최종적으로 완성되어 브라우저에 전달되는 CSS 파일에는 아래와 같이 값이 치환되어 들어갑니다.

.alert {
  border: 1px solid #c6538c;
}

컴포넌트 단위의 스타일시트 컴파일하기 (Compiling component stylesheets)

위에서 큰 스타일시트 하나를 여러 개의 작은 파일로 쪼개는 것이 좋다고 말씀드렸죠? Sass를 쓰면 이 개념을 극단적으로 끌어올려 아주 잘게 쪼개진 수많은 스타일시트 조각들(심지어 컴포넌트 하나당 파일 하나씩)을 만들 수 있습니다. Sass에 내장된 파일 병합 기능(partials)을 이용하면, 이 수많은 조각들을 컴파일 타임에 깔끔하게 하나(혹은 몇 개)의 완성된 CSS 파일로 합쳐서 웹사이트에 링크할 수 있습니다.

예를 들어, 파일 이름 앞에 언더스코어(_)를 붙여서 파셜(partials) 파일을 만듭니다. foundation 폴더 안에 _code.scss, _lists.scss, _footer.scss, _links.scss 등을 만들어 두는 거죠. 그런 다음, 이 파셜들을 하나의 스타일시트에서 Sass의 @use 규칙을 이용해 싹 다 불러옵니다.

// foundation/_index.scss
@use "code";
@use "lists";
@use "footer";
@use "links";

위의 예시처럼 파셜들이 모두 인덱스 파일(index file)로 불려 모아졌다면, 또 다른 최종 스타일시트에서는 그 폴더 전체를 한 번의 명령으로 통째로 가져올 수 있습니다.

// style.scss
@use "foundation";

참고:
아무런 설치 없이 Sass를 가장 쉽게 맛보는 방법은 CodePen을 사용하는 것입니다. 펜(Pen) 설정 창에서 CSS 프로세서를 Sass로 선택하기만 하면, CodePen이 실시간으로 Sass 코드를 파싱해서 평범한 CSS가 적용된 결과 화면을 보여줍니다. 가끔 웹에서 CSS 튜토리얼을 볼 때 CodePen 데모 코드가 일반 CSS가 아니라 Sass로 적혀있는 경우가 종종 있으니, 이 구조를 조금이라도 눈에 익혀두시면 아주 편리합니다.

최적화를 위한 후처리 (Post-processing for optimization)

만약 파일이 여러 개로 나뉘고, 수많은 주석과 공백(띄어쓰기)을 추가해서 CSS 파일의 용량(size)이 너무 뚱뚱해지는 것이 걱정되시나요? 그럴 때 바로 후처리(post-processing) 단계가 출동하여 실제 운영 서버(production)에 배포될 최종본에서 쓸데없는 찌꺼기들을 전부 깎아내고 최적화해 줍니다. 이렇게 코드를 꽉꽉 압축해 주는 대표적인 후처리기 솔루션으로 cssnano 같은 도구들이 있습니다.