장거리 도보 여행을 가려고 짐을 쌀 때 모든 것을 가방에 차곡차곡 챙깁니다. 무게가 많이 나가고 자주 꺼내지 않는 물건을 먼저 넣습니다. 침낭, 취침용 패드, 해먹(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 고수가 되자!

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