예전의 단순했던 CSS만으로 일했던 그때를 기억하시나요? 사용한 CSS 파일은 단 하나지만 (코드의 줄은) 잠 못 이루는 밤보다 더 길었습니다. (대게 서툴게 작성된) 셀 수 없이 많은 줄과 거기서 알려지지 않고 좌절스럽기만한 IE 버그를 고치고자, 변경할 값 하나를 찾으려고 애썼죠.

여러분, 이제 그런 날들은 과거가 되었습니다. CSS를 다루는 것은 더 흥미로워지고 더 복잡해집니다. 아마도 흥미로워지니 복잡해지겠죠(역자:다양하게 표현할 수 있는 코드가 쏟아지므로 더 복잡해진다는 의미). 멋진 이들이 얘기하는 CSS 전처리기, 반응형 웹 디자인, 점진적 향상^{progressive enhancement}, 적절한 낮춤^{graceful degradation[1]}, 그 외의 것들이 있어서 CSS는 어느 때보다 더 강해지고 있습니다.

CSS는 더 흥미롭고 더 복잡해지고 있습니다.
— 저자

다루어야 할 것이 너무 많기에 체계적인 상태를 유지하는 것이 중요합니다. 그게 항상 수월하지 않다는 것에 대해 동의하실 거예요. 이 글에서 저는 여러분에게 생각하는 법(구현방법이 아닌←이것은 여러분께 맡길게요)을 터득하도록 도움을 드리고자 합니다.

내 구조 만들기

CSS 전처리기를 사용해서 얻는 혜택 중 하나는 성능에 영향을 주지 않고 코드를 나누어 여러 개의 파일에 담을 수 있다는 것입니다. Sass의 @import 지시자 덕분에 개발 환경에서 원하는 만큼 많은 파일을 만들 수 있습니다. 실시간 환경에서 모든 파일이 하나의 파일로 컴파일 될 것입니다.

다중 파일은 개발 환경에서, 하나의 파일은 실시간 환경에서.
— 브루스 리^{Bruce Lee}

CSS를 여러 파일과 폴더에 적절히 나누어 넣는 것에서 정리가 시작됩니다. 저의 은사 중 한 분이 이런 말씀을 하시곤 하셨어요. “모든 것은 그것에 맞는 장소가 있고, 모든 장소에는 그에 맞는 것이 있다.” 그 말씀대로 제가 여기서 하고자 합니다!

폴더는 훌륭하기에 이것을 사용하라

폴더가 없어서는 안되죠. 여러분은 집에서 모든 문서를 상자 하나에 다 넣지 않죠. 아마도 서류철들^folders이 있겠지요. 집/아파트용 서류철, 은행용 서류철, 영수증용 서류철 등등.

제가 모든 SASS 파일을 같은 폴더에 넣을 필요가 없다고 말한다면요?

CSS 구조를 설계하는 것도 정확히 같습니다. 모든 Sass 파일들을 같은 폴더에 넣지 않습니다. 그것들을 분류하세요.

아래는 파일들을 구조화하는 것을 보여줍니다.

보다시피 루트^root에 Sass 파일(main.scss) 한 개만 있습니다. 나머지 다른 파일들은 적당히 나누어져 폴더에 들어 있습니다. 파일명 앞에 밑줄(_)이 붙은 것은 Sass에게 파셜^partial .scss 파일이라고 말해주는 것이에요. 파셜 .scss 파일은 .css 파일로 컴파일 되지 않습니다. 파일을 불러오고 합치는 기본 파일^{base file}의 역할을 수행합니다.

모든 파일을 통치하는 파일 하나,
파일들을 찾는 파일 하나,
모든 파일을 가져오는 파일 하나,
그들을 Sass 방식으로 합쳐라.
— J.R.R. 톨킨^Tolkien

위의 파일 구조에서 폴더를 하나씩 보지요.

Base

base/ 폴더에 일명 프로젝트용 표준 문안^{boilerplate[2]} 관련 내용이 있습니다. 거기에서 reset(아니면 Normalize.css나 그에 유사한 무엇이든) 코드를 찾을 수 있습니다. 아마 프로젝트에 따라 타이포그래피를 다루는 소스나 다른 소스를 발견할 수 있을 것입니다.

Helpers

helpers/ 폴더(때론 utils/로 부르는)에 모든 Sass 툴과 프로젝트 여기저기서 사용할 헬퍼들이 모여있습니다. 기능이 포함됐나요? 믹스인? 다 이 폴더에 넣으세요. 이 폴더에는 _variables.scss(때론 _config.scss로 부르는) 파일도 있어 프로젝트에 대한 모든 글로벌 변수(타이포그래피, 색 구성^{color schemes} 등)를 이곳에 담고 있습니다.

Layout

layout/ 폴더(때론 partials/로 부르는)에 보통 파일이 많이 들어 있습니다. 개별 파일에서 레이아웃(헤더, 푸터 등)의 주요 부분에 관한 스타일을 정의합니다. _grid 파일도 있어서 이 레이아웃을 만드는데 그리드 시스템이 사용된다는 것을 알 수 있습니다.

이 폴더에 네비게이션 파일을 넣는 것이 이치에 맞을 수 있습니다. 저는 이 파일을 components/(다음 내용에서 보실거예요)에 넣지만요. /layout 폴더에 넣는 것이 더 좋을 수 있다고 생각하지만 결정은 여러분 몫으로 할게요.

Components

좀 더 작은 구성요소를 위한 components/ 폴더(흔히 modules/로 부르는)가 있습니다. layout/을 (전역적^global 와이어프레임을 정의하는) 매크로라고 치면 components/는 좀 더 마이크로입니다. 슬라이더, 로더^loader나 그런 유형의 특정한 모듈을 담을 수 있습니다. 여러분의 사이트가 거의 작은 모듈들로 이루어졌기에 보통 components/에 많은 파일들이 있습니다.

Pages

페이지에 특정화된 스타일이 있다면 pages/ 폴더에 그 스타일을 넣고 페이지명과 파일명을 일치시키는 것이 좋을거라 생각합니다. 예를 들면 Home 페이지에 독특한 스타일을 적용하는 일은 흔하죠. 이 스타일을 처리하려고 pages/ 폴더에 _home.scss 파일을 넣을 수 있습니다.

여러분의 배포 과정에 따라 이 파일들은 별도로 호출될 수 있는데 이는 출력되는 스타일시트에서 다른 파일과 합쳐지는 것을 방지하기 위함입니다. 여러분 결정에 달렸습니다. 저의 회사에서는 그것을 partials로 만들지 않기로 결정했습니다. 그것을 요청하는 페이지에만 포함시키도록 하려는 목적이었습니다. 예를 들어 Home 페이지에 특별한 레이아웃이 있고 대략 200줄 되는 CSS를 컴파일한다고 하죠. 모든 페이지에서 그 규칙이 로딩되는 것을 막고자 그 파일을 Home 페이지에만 넣었습니다.

Themes

저처럼 여러 테마를 다루는 규모가 큰 사이트에서 작업한다면 themes/ 폴더가 있는 것이 이치에 맞습니다. 테마/디자인과 관련된 스타일 모두 거기에 넣으세요. 완전히 프로젝트에 특화된 것이어서 여러분이 필요를 느낄 때만 파일을 넣으면 됩니다.

Vendors

마지막이지만 중요한 것으로 여러분은 아마 외부 라이브러리와 프레임워크(부트스트랩, jQueryUI, jQuery에서 제공하며 잘 다듬어진 캐로셀 슬라이더^{FancyCarouselSliderjQueryPowered} 등)에 포함된 모든 CSS 파일을 vendors/ 폴더에 넣을 것입니다. 파일들을 별개의 폴더에 넣는 것은 좋은 방법으로 “이봐, 이건 내가 작성한 파일이 아니고, 내가 짠 코드도 아니며, 내 책임이 아니야”라는 것을 알려줍니다.

예를 들면

게다가 저희 회사에서 vendors-extensions/ 폴더도 있었는데 여기에 벤더 파일을 일부 덮어쓰기하는 파일을 넣었습니다. 예를 들어 _bootstrap.scss 파일을 거기 넣어서 부트스트렙에 있는 구성요소 일부를 바꾸는데 사용했습니다. 벤더 파일 자체를 편집하지 않으려고 했습니다. 그것은 좋은 생각이 아닙니다.

—————————————————————————————————————–

이게 전부입니다. 프로젝트에 따라 구조가 달라질 수 있겠지만 여러분이 이 개념을 이해했다고 확신합니다. 폴더 안에 폴더를 중첩하는 것에 관해 항상 반대하진 않지만 그렇다고 선호하지도 않습니다. 대부분의 경우 단일 레벨^{single level} 구조가 너무 복잡해지지 않고 파일을 깔끔하고 정돈된 상태로 유지할 수 있다는 것을 알게되었습니다. 그렇더라도 프로젝트에서 하위 레벨 구조가 필요하다고 생각한다면 그렇게 하시기 바랍니다.

전문가 조언: 여러분이 scss 폴더를 본 누군가가 파일 구조를 명확히 이해할 수 없다고 생각한다면 구조 전체를 설명하는 README.md 파일을 만들어 (main.scss와 나란히) 루트 레벨에 넣는 것을 고려해 보세요.

파일도 훌륭해!

제가 자주 받는 질문은 “얼마나 많아야지 너무 많은 파일이라고 말하나요?”입니다. 저는 너무 많은 파일은 절대 없습니다고 답변합니다. 작업을 몇몇 파일로 쪼개는 것은 코드를 정리하려는 목적입니다. 여러분이 무언가 더 많은 파일로 나눠야겠다고 느끼면 그렇게 밀어붙이세요!

크리스 코이어가 그의 Sass 스타일 가이드에서 말했듯이

이해될 때까지 작은 파일로 나누세요.
- 크리스 코이어^{Chris Coyier}

저는 단일 구성요소를 다수의 파일로 폭발적으로 증가시키는 데 반대하는 편입니다. 그렇게 하는 타당한 이유가 없는 한 말이죠. 일반적으로 저는 더도 덜도 말고 파일당 모듈 하나를 넣고 모듈의 의미를 알 수 있는 이름을 짓습니다. 이 방식으로 저는 서브라임 텍스트^{Sublime text}에서 코드를 찾고자 할 때 빠른 찾기^{go to[3]}를 할 수 있습니다.

요약

이 글에서 제안한 모든 내용은 저의 개인적 경험을 근거로 작성되었습니다. 저는 프랑스에서 규모가 큰 은행 그룹 중 하나인 크레디 아그리꼴^{Crédit Agricole}사의 웹기반 지사^{web-based branch}에 근무하는 단 한 명의 프론트엔드 개발자입니다. 아마 여러분의 환경과 경험에 맞는 다른 접근방법이 있을 것입니다.

Sass 프로젝트의 아키텍처에 관한 황금률^{Golden Rule}을 뽑으라고 하면 다음과 같이 단순할 수 있습니다. 말이 되는 것을 뽑으세요. 여러분이 프론트엔드 팀에서 일을 하면 모든 팀원들이 선택한 구조에 대해 편히 느끼는지 확인하세요. 그렇지 않으면 어딘가에 문서화하고 공개해서 누구나 파일구조가 어떻게 구성되어 있는지 이해하도록 해주세요.

Sass 구조에 대해 의견이나 제안이 있으신가요? 여러분의 견해를 기다립니다.

큰 힘에는 언제나 큰 책임이 따른다.
— 아쿠아맨^Aquaman

휴고 기로델 Hugo Giraudel
트위터 @HugoGiraudel
GitHub HugoGiraudel
구글플러스: +Hugo Giraudel

휴고 기로델은 프랑스에 거주하는 프론트엔드 개발자이며 재미 삼아 Sass를 하며 시간을 보내는 것을 즐깁니다. 그는 SassyLists, SassyJSON, SassyMatrix, SassyCast, SassySort, Browserhacks를 만든 제작한 저작자입니다.

• [1] 적절한 낮춤(graceful degradation): 먼저 최신 기술기반 혹은 최신 기기에서 동작하는 기능을 만들고 나서 오래된 기술기반 혹은 오래된 기기에서도 유사하게 (성능을 낮춰서라도) 동작하도록 하는 것
• [2] 프로젝트용 표준 문안(boilerplate): (사업상 서류・법률적 합의안 등의) 표준 문안
• [3] 서브라임 텍스트 빠른 찾기(go to): 원하는 파일이나 코드를 빠르게 찾아주는 일종의 검색기능

댄 시더홈 Dan Cederholm

웹디자이너를 위한
SASS

CSS 마스터, 댄 시더홈이 전수하는 SASS 노하우!
SASS로 스마트한 CSS 고수가 되자!

책 구매하기책 미리보기책 상세설명

루비 인스톨러(Ruby Installer) 설치

루비인스톨러 설치 파일을 다운로드하기 위해 해당 페이지로 이동합니다.

루비인스톨러 파일 다운로드 하기

이동한 페이지에서는 루비인스톨러 실행 파일을 버전별로 나열해서 보여줍니다. 최신 버전을 설치할 것이므로 Ruby 2.0.0-p481를 클릭합니다. 클릭하자마자 파일이 자동으로 다운로드되기 시작합니다.

루비 인스톨러 설치하기

다운로드가 끝나면 실행 파일을 클릭합니다. 설치가 시작되고 언어옵션을 선택하는 화면이 보입니다. 아쉽게도 한글을 지원하지 않습니다. 영어(English)를 선택하고 동의(OK)버튼을 누르세요.

다음 화면에 루비프로그램 설치 및 사용을 위한 라이선스 동의서가 보입니다. ‘I accept the License(라이센스를 수락합니다)’ 라디오 버튼을 클릭하세요. 수락하지 않으면 다음 단계로 넘어갈 수 없습니다.

다음에 나오는 화면이 정말 중요합니다. 이 화면에서 설치폴더를 눈으로 확인하고(기본으로 보여진 폴더를 변경하지 마세요) 바로 아래에 있는 체크박스 옵션 3개 중에서 가운데 옵션(Add Ruby executable to your PATH – 실행할 루비 파일경로를 환경변수에 추가)에 체크하세요. 체크한 후 실행(Install) 버튼을 누릅니다. 설치가 본격적으로 진행됩니다.

설치가 끝나면 설치를 완료했다는 화면이 보입니다. 마침(Finish) 버튼을 누르세요.

SASS 설치

루비를 설치했으므로 그 다음 단계인 Sass를 설치하겠습니다. Sass는 명령 프롬프트(Command prompt)에서 직접 명령어를 입력해서 설치합니다. 예전에 도스(DOS) 시절을 아시는 분은 명령 프롬프트가 친근하겠지만 처음 들어보시는 분은 낯설 것입니다. 겁부터 먹지 마세요. 화면에서 명령어 한 줄만 입력하면 됩니다.

명령 프롬프트 찾아서 실행하기

명령 프롬프트는 어디에서 찾을까요? 2가지 방법이 있습니다. 우선 왼쪽 하단에 있는 ‘시작’ 버튼을 눌러 나오는 ‘모든 프로그램’ 메뉴를 보세요. 보조프로그램 폴더를 클릭해서 펼치면 그 안에 명령 프롬프트가 있습니다. 다른 방법은 ‘시작’ 버튼을 눌러 나오는 화면 하단에 ‘프로그램 및 파일 검색’이라는 검색 입력박스에 ‘cmd’를 입력하고 엔터키를 누르면 명령 프롬프트가 실행되면서 화면에 나옵니다.

SASS 설치하기

명령 프롬프트는 아래와 같이 검정 화면에 텍스트만 있습니다. 단순하죠. 여기서 명령어 한 줄 입력해서 Sass를 설치할 것입니다. 지금 어느 디렉터리에 있든 상관없이 gem install sass를 입력하고 엔터키를 누르세요.

Gem은 루비의 패키지 설치 및 관리 프로그램으로 위의 명령행을 실행하면 Sass 패키지(버전 3.3.8)를 자동으로 다운로드 받아 설치합니다. 설치된 결과는 아래와 같이 보입니다.

축하합니다! 여러분은 지금 윈도우에서 Sass 설치하는 작업을 완료했습니다.

댄 시더홈 Dan Cederholm

웹디자이너를 위한
SASS

CSS 마스터, 댄 시더홈이 전수하는 SASS 노하우!
SASS로 스마트한 CSS 고수가 되자!

책 구매하기책 미리보기책 상세설명

1996년 첫 CSS1이 공식적으로 권고되었고 CSS3까지 발전했으며 이 순간에도 CSS3의 새 규칙이 소개되고 있습니다. 웹 개발에서 CSS 업무의 비중이 커지고 있습니다. 브라우저 호환성을 맞추고 반응형 디자인을 적용하는 작업 등 CSS의 몫이 큽니다. 이에 따라 스타일시트 문서는 길어지고 용량도 커집니다.

이렇게 된 주요 원인 중 하나는 코드의 반복입니다. 전 세계 웹 디자이너들에게 인기 있는 CSS-Tricks의 블로그 운영자인 크리스 코이어^{Chris Coyier}는 “CSS에는 추상화 개념이 없고 코드의 반복만 있습니다. 이런 이유로 CSS가 널리 채택되고 사용되었지만 이제는 관리하기가 어려워졌습니다”라고 말합니다.

코드의 반복으로 인해 CSS 작업자는 파일에 산재해 있는 코드를 찾고 수정하는 데 많은 시간을 보냅니다. 코드를 관리하는 것은 어려워지고 그 효율성도 시간이 갈수록 떨어집니다. CSS를 작성하고 관리하는 분이라면 누구나 공감할 것입니다.

과연 이 문제를 해결하기 위한 좋은 방안은 없을까요? 물론 있지요! CSS의 전처리기가 바로 그것입니다. 전처리기는 위에 언급된 문제에 대해 해결안을 제시합니다. CSS 작업자에게 전처리기는 선택사항입니다. 그럼에도 전 세계 웹 관련 종사자들의 전처리기에 대한 관심은 높습니다. 그들은 여러 전처리기를 비교·분석하고 본인에게 맞는 전처리기를 찾는 데 열심입니다. 마치 이런 변화의 흐름과 거리가 먼 듯 국내에는 아직 그 불꽃이 일어나지 않은 상태입니다.

이 책의 저자인 댄 시더홈은 유명한 웹 디자이너이자 프론트엔드 개발자입니다. 글로벌 웹 디자인계에서 실력 있는 최고 전문가들이 참여해서 저술하는 A Book Apart의 두 번째 책인 《웹디자이너를 위한 CSS3》의 저자입니다. CSS를 10년 이상 직접 손으로 코드를 작성해온 댄은 본인만의 노하우가 담긴 CSS 작업 방식을 고집스럽게 지켜왔습니다. 그렇기에 그는 CSS 전처리기인 Sass에 대해 처음부터 호의적이지 않았다고 고백합니다. Sass를 사용하면서 그의 불신은 강한 믿음으로 완전히 바뀌었고, 이제는 열성적인 Sass 전도사가 되었습니다.

독자 여러분을 위해 댄은 Sass를 처음 접하는 독자의 눈높이에서 복잡하고 어려운 Sass의 용어와 문법을 쉽게 풀어서 설명해줍니다. 그가 제시하는 가상 웹사이트 프로젝트와 예제 코드는 글로 설명할 수 없는 내용을 여러분의 머릿 속에서 쉽게 구체화해줄 것입니다. 댄과 함께 재미있는 Sass 여행을 떠나보세요.

독자 여러분의 많은 관심과 격려 바랍니다.

웹액츄얼리 북스팀

부트스트랩^Bootstrap은 작업자가 초보자이든 전문가이든 상관없이 최근 사이트나 앱의 구조^scaffold를 빠르고 쉽게 생성할 수 있는 소스 코드를 제공합니다. 점점 더 많은 개발자들이 개인 툴박스에 이 프레임워크를 넣고 있습니다.

부트스트랩에는 어두운 이면도 있습니다. 정리되지 않고 시맨틱하지 않으며 재사용 할 수 없는 마크업을 쉽사리 작성할 수 있습니다. 이렇게 작성해도 모든 브라우저에서 제대로 보여지긴 하지요.

저는 이 글에서 부트스트랩을 사용해 견고하고 시맨틱한 코드를 작성하는 방법에 대해 설명할 것입니다. 부트스트랩의 최신 버전에는 Sass를 공식적으로 탑재하고 있습니다. 이 글의 목적을 달성하고자 Sass의 가장 강력한 기능 중에 하나인 @extend 지시자를 사용할 것입니다.

시맨틱에 관하여

우선 무언가를 ‘시맨틱’하게 만든다는 말이 무슨 뜻인지 알아봅시다. HTML 문서는 정보의 계층구조적 관점에서 콘텐츠를 묘사합니다. 누구나 코드를 읽고 무엇을 말하고 있는지 알 수 있어야 합니다. 어떻게 보이는가는 해당하지 않습니다.

CSS 특히 CSS 프레임워크의 인기가 높아지면서 독자/개발자의 입장보다 CSS 문서 자체에 신경을 쓰며 HTML을 작성합니다. 요즘 웹사이트 소스 코드에서 이와 같이 작성된 HTML 마크업을 보는 것은 흔한 일이죠.

부트스트랩의 CSS 파일은 위의 코드가 무엇을 할지 압니다. 열이 모두 2개 있고, 한 열에 행이 3개 있으며, 나머지 열에 100% 너비가 적용된 행 1개가 있다는 것을 말이지요. 부트스트랩을 다뤄본 개발자라면 이것을 쉽게 파악합니다. 하지만 이 프레임워크를 사용해 본 경험이 없는 사람이 보았다면 어떨까요? 위의 HTML 코드들은 왜 있는 걸까요? 어떤 정보가 담겨 있죠? 이 마크업은 쓸만한 정보를 보여주지 않습니다.

시맨틱 마크업은 보이는 외관보다 콘텐츠를 설명하는 코드입니다. 위의 코드를 다음과 같이 의미가 담긴 코드로 작성할 수 있습니다.

부트스트랩이 시맨틱한 스타일을 어떻게 반영할까?

여러분은 내장된 클래스없이 어떻게 부트스트랩을 사용할지 궁금해할 것입니다. Sass @extend 기능의 힘을 사용해서 이것을 해결할 수 있습니다.

Sass 문서:

@extend는 확장된^extended 선택자가 있는 스타일시트 안에 어디에서나 확장하는^extending 선택자를 넣어서 작동합니다.

 
이는 시맨틱한 선택자를 사용하면서 부트스트랩의 선택자를 확장할 수 있는 장점을 취한다는 의미입니다. 어떻게 적용하는지 봅시다.

재사용성^Reusability

이 방법의 또 다른 장점은 가독성과 재사용성 모두를 가진 구성요소^components를 만든다는 것입니다. 예를 들어 행과 열 밖에서 필요할 때마다 author 구성요소를 반복해서 만들지 않아도 됩니다. 대신 구축하기 쉽도록 구성요소 각 부분의 이름을 알기 쉽게 지어주세요. 전체 사이트에서 일관적으로 보이는지 부트스트랩을 통해 확인할 수 있습니다.

이식성^Portability

부트스트랩이 최고의 프레임워크들 중에 하나일지라도 나중에 다른 프레임워크로 이전하거나 아예 자체 프레임워크를 제작할 때가 올지 모릅니다. 위에 대략 서술한 방식으로 이와 같은 작업을 할 수 있습니다. 왜냐하면 CSS에서 여러분의 마크업을 군더더기 없이 깔끔하게 분리할 수 있기 때문입니다.

툴벨트^toolbelt를 매세요.

부트스트랩의 Sass 버전을 아직 사용해보지 않았다면 반드시 사용해 보세요. Github 페이지에서 시작하는 것이 좋습니다.

Sass가 유일하게 놀 거리는 아닙니다. HTML과 CSS에서 다음 단계의 시맨틱을 진정으로 알고 싶다면 BEM이나 SMACSS 같은 명명법^{naming convention}을 권해드립니다. 여러분은 이것으로 선택자를 표준화하고 기억하기 쉽게 만들 수 있습니다.

이제 나가서 확장하세요

부트스트랩에 놀랍도록 강력한 스타일 세트가 있습니다. 그렇다 하더라도 코드를 대충 꿰 맞추어서 마크업의 품질을 상실할 수도 있습니다. Sass의 @extend 지시자를 사용하면 콘텐츠와 개발자 모두를 위해 의미를 명확히 전달할 수 있는 마크업을 작성할 수 있습니다.

브래드 바로우 Brad Barrow

트위터 @foxwisp

브래드 바로우는 호주 멜버른에 거주하는 프론트엔드 개발자이고 디자이너이며 SitePoint팀과 함께 작업하고 있다. 아침 식사로 자바스크립트/CSS를 먹으며 계속 변화하는 프론트엔드 세계의 정상에 서있고자 노력한다.

댄 시더홈 Dan Cederholm

웹디자이너를 위한
SASS

CSS 마스터, 댄 시더홈이 전수하는 SASS 노하우!
SASS로 스마트한 CSS 고수가 되자!

책 구매하기책 미리보기책 상세설명

장거리 도보 여행을 가려고 짐을 쌀 때 모든 것을 가방에 차곡차곡 챙깁니다. 무게가 많이 나가고 자주 꺼내지 않는 물건을 먼저 넣습니다. 침낭, 취침용 패드, 해먹(hammock) 같은 것이죠. 위로 올라오면서 꺼내기 쉽고 가방 안에서 옮기기 편한 물건을 넣습니다. 옷가지, 취사 도구, 과자, 응급처치 도구, 콤파스, 지도 같은 것 말이죠.

인터넷에서 이야기해 보죠

바닐라(Vanilla) CSS ^[1]에 의존했던 때가 있었어요. 작은 코드 하나라도 직접 작성해야 했습니다. 첫 작업은 늘 자랑하고 싶고 끝내주게 멋진 작품이 될 수 있었습니다. 하지만 불가피하게 개선사항이 나오자 여기 저기에서 코드를 수정하고 클래스나 섹션을 추가해야 했습니다. 그러면서 코드는 엉기기 시작했죠.

위에서 아래로 써 내려가는 융통성 없는 CSS의 특성 때문에 코드를 잘 정리된 상태로 유지하기가 힘들었습니다. 그때부터 저는 이상한 작업을 하기 시작했죠. 자주 반복하는 CSS 규칙 섹션을 임시 문서에 담고 문서를 열어 놓은 채 필요할 때마다 복사하기와 붙여넣기를 해서 코드를 원본 파일에 넣었습니다. 앞서 말했던 것처럼 악몽 같은 유지보수 작업이었습니다.

Sass와 함께

거의 1년 6개월 전만 해도 저는 “전처리기(preprocessors)”에 대해 몰랐습니다. 그 후에 Sass에 대해 듣게 되었는데 그때만 해도 “왜 이것을 써야 하지? CSS로 충분한데?”라고 생각했습니다. 그런데 결국 Sass를 사용했습니다. 대세가 바뀌었죠.

Sass는 Syntactically Awesome Style Sheets의 약자로, 우리에게 많은 툴을 줍니다. 클래스 이름을 장황하게 쓰지 않고 스타일을 중첩(nest)할 수 있습니다. 믹스인과 extends 같은 기능을 사용해 코드를 체계적이고 신속하게 만듭니다.

Sass는 모듈식으로 되어 있는데 이것이 짐을 쌀 때 배낭의 웨빙(webbing)^[2]과 어떻게 유사한지 자세히 설명할 수 있습니다. 하지만 여기서는 여러분이 이 툴에 대한 기본 지식을 가지고 있다고 가정합니다.

수준 높은 구조화

스파크박스(Sparkbox)의 개발자들은 SMACSS식의 사고를 가지고 웹사이트 각 부분에 해당하는 개별 .scss 파일을 만듭니다.

예: _fonts.scss, _colors.scss, _header.scss, _footer.scss, _blog-listing.scss, _hero.scss

스타일을 이처럼 관리하기 쉬운 작은 덩어리로 나눌 수 있습니다. 보통 나눠진 파일에 150줄 정도의 코드가 있습니다. 파일에서 특히 글꼴과 색상 같이 스타일 전체에 영향을 주는 코드는 배낭에 넣는 텐트와 침낭에 비유할 수 있습니다.

전체에 영향을 주는 코드를 먼저 설정하세요. 작성하는 모든 코드의 기준이 되고 그것으로부터 코드가 계속 확장될 것입니다. 일단 배낭 안에 넣어두면 여러 번 꺼낼 필요가 없거든요.

만일 스타일시트에 작성된 코드가 200줄이 넘게 되면 그 파일을 나누어야 할지, 일부 코드를 리팩토링(refactoring)^[3] 할지 고려해야 합니다.

양이 적은 코드

Sass를 작성할 때 각 엘리먼트에 규칙을 더해가듯 구조를 만듭니다. 양이 적은 코드는 이동이나 접근이 쉽고 나중에 수정하기도 편합니다. 마치 배낭 위에 물건을 올려놓는 것처럼요. 예를 들면 작은 믹스인 코드가 있습니다. 클래스 이름이 .warm이고 모든 엘리먼트의 배경색을 덮어씁니다. 플리스(fleece)^[4] 담요처럼 말이죠.

스타일이 적용될 엘리먼트

믹스인을 먼저 넣습니다.

만일 작업하는 데 필요한 믹스인이 없다면 글꼴, 레이아웃, 글꼴 색상에 관한 스타일을 각각 작성합니다.

만약 미디어 쿼리를 고려해야 할 상황이라면 다음에 추가합니다. 스파크박스의 글인 ‘Sass mixin으로 미디어 쿼리 활용하기’를 읽어보시기 바랍니다. 이것은 믹스인의 위치를 정하는 규칙에서 벗어난 예외사항이긴 합니다.

자, 중첩 스타일을 작성할 준비가 되었습니다. 구조 안에 동일한 규칙을 보여주는 코드를 다음에 넣으세요. CSS를 중첩할 때 2~3단계 이상 깊게 들어가지 않도록 합니다. 더 많은 단계로 들어가며 코드를 작성하게 되면 그때 차라리 스타일을 나누세요. 그게 안전합니다.

여행을 떠나세요

이와 같은 방법으로 코드를 빨리 훑어보고 편하게 이동하며 유지보수가 쉬운 Sass 파일을 만들 수 있습니다. 물론 모든 사람이 사용해야 하는 규칙은 아닙니다. 단지 제 작업 방식일 뿐이죠. 그래도 형식을 구조화하는 것이 그렇지 않은 것보다 낫다고 믿습니다.

마셜 노만 Marshall Norman

트위터 @marshall_norman
드리블 https://dribbble.com/marshall-norman

마셜 노만은 오하이오주 데이톤에 위치한 스파크박스의 웹 개발자이다. 본인이 운영하는 싱글 세일(Single Sail)에서 웹사이트를 구축하고 디자인 프로젝트를 진행하고 있다.

댄 시더홈 Dan Cederholm

웹디자이너를 위한
SASS

CSS 마스터, 댄 시더홈이 전수하는 SASS 노하우!
SASS로 스마트한 CSS 고수가 되자!

책 구매하기책 미리보기책 상세설명