CSS

초기 웹 문서는 글자 크기와 색을 문서 안에 직접 적었습니다. 제목 하나하나에 크기와 색을 지정하는 태그를 덧붙이는 식이었습니다. 이 방식의 값은 사이트가 커진 뒤에 청구됩니다. 제목이 200개인 사이트에서 제목 색을 감색에서 검정으로 바꾸기로 하면 고칠 자리가 200군데였고, 그중 한 곳을 빠뜨리면 그 페이지만 혼자 감색으로 남았습니다.

원인은 구조와 표현이 한 줄에 섞여 있다는 데 있었습니다. 이 문서에 무엇이 있는지를 적는 일과 그것이 어떻게 보이는지를 적는 일이 분리되지 않으니, 보이는 방식만 바꾸려 해도 문서 전체를 건드려야 했습니다. 디자인을 한 번 바꾸는 데 며칠이 들었고, 그러다 보니 고치지 말자는 쪽으로 결론이 나곤 했습니다.

CSS는 표현을 문서 밖으로 빼내 한곳에 모으려고 만든 언어입니다. HTML 문서에는 여기가 제목이라는 사실만 적고, 제목이 어떻게 보일지는 별도의 스타일 파일에 한 번 적습니다. 그러면 색을 바꾸는 일이 200군데 수정이 아니라 한 줄 수정이 됩니다.

CSS가 맡아 푸는 문제는 셋입니다. 같은 규칙을 여러 곳에 반복해 적는 중복, 화면 크기마다 배치가 달라져야 하는 상황, 규칙끼리 부딪혔을 때 무엇을 따를지 정하는 일입니다.

1. 중복은 선택자로 풉니다. 선택자는 규칙을 적용할 대상을 고르는 문법으로, 화면의 모든 제목처럼 조건에 맞는 요소를 한꺼번에 가리킵니다. 대상이 200개든 1개든 규칙을 적는 자리는 한 곳입니다.
2. 화면 크기는 조건부 규칙으로 풉니다. 창 너비가 600픽셀보다 좁을 때만 적용할 규칙을 따로 적어 두면, 넓은 화면에서 가로로 나란히 놓였던 카드 세 장이 좁은 화면에서는 세로로 쌓입니다. 반응형 디자인이 가능해진 것도 이 문법 덕분입니다.
3. 충돌은 우선순위 규칙으로 풉니다. 한 요소에 여러 규칙이 걸리는 일은 예외가 아니라 기본값에 가깝습니다. 이때 더 좁게 지정한 규칙이 이기고, 좁기가 같으면 나중에 적은 규칙이 이깁니다.

세 번째가 이 언어의 이름이 된 부분입니다. 스타일이 위에서 아래로 흘러내리며 겹친다는 뜻에서 종속형 시트라고 부릅니다. 글자 색을 문서 전체에 회색으로 깔아 두고 본문 영역에서만 검정으로 덮어쓰면, 따로 지정하지 않은 자리는 회색을 그대로 물려받습니다.

브라우저가 최종적으로 읽는 것은 언제나 CSS이고, 대안이라 불리는 것들은 CSS를 대신하는 도구가 아니라 CSS를 만들어 내는 방식입니다. 무엇을 고르든 결과물의 문법은 같습니다.

1. 인라인 스타일 — 태그마다 스타일을 직접 붙이는 방식입니다. 한 곳만 급히 고칠 때는 빠르지만 등장 배경에서 본 문제가 그대로 돌아옵니다.
2. 전처리기 — 변수와 중첩 같은 편의 문법으로 적은 뒤 일반 CSS로 변환해 주는 도구입니다. 지금은 CSS 자체가 변수를 지원해서 쓰는 곳이 줄었습니다.
3. CSS-in-JS — 스타일을 자바스크립트 코드 안에 적어 두고 실행 시점에 붙이는 방식입니다. 컴포넌트 하나가 구조와 동작과 스타일을 한 파일에 갖게 되어 지울 때 함께 지워집니다.
4. 유틸리티 프레임워크 — 여백 4픽셀, 글자 굵게처럼 잘게 쪼갠 클래스를 미리 만들어 두고 문서에서 골라 붙이는 방식입니다. 새 이름을 짓지 않아도 되는 대신 문서가 길어집니다.

고르는 기준은 취향이 아니라 팀의 규모와 디자인 시스템의 유무입니다. 색과 간격의 기준값을 디자인 토큰으로 정해 둔 팀이라면 어느 방식이든 그 값을 CSS 변수로 받아 쓰게 되고, 기준값이 없는 팀은 어느 방식을 골라도 같은 회색이 다섯 가지로 늘어납니다.

"이거 CSS만 건드리면 되나요, 아니면 구조까지 바꿔야 하나요?"

요청한 수정이 스타일 몇 줄로 끝나는 일인지, 문서의 뼈대를 다시 짜야 하는 일인지를 묻는 말입니다. 뒤쪽이면 일정이 달라집니다.

"사파리에서만 간격이 틀어집니다. CSS 쪽에서 잡아 주세요."

브라우저마다 기본값이 달라 생긴 차이이니 크로스 브라우저 대응을 스타일에서 해 달라는 뜻입니다.

"이 색은 CSS 변수로 빼 두죠."

값을 한 자리에 모아 두자는 제안입니다. 나중에 어두운 화면 모드를 붙일 때 고칠 곳이 한 군데로 줄어듭니다.

페이지덱에서 민서가 버튼 여백을 20픽셀에서 24픽셀로 통일하자고 제안한 적이 있습니다. 화면 열두 개에 걸친 변경이라 처음에는 며칠짜리 일로 보였지만, 태오가 확인해 보니 여백 값이 이미 변수 하나에 묶여 있어서 그 줄만 고치면 되는 일이었습니다. 반대로 같은 주에 올라온 카드 배치 변경 요청은 구조를 다시 짜야 해서 스프린트 하나가 들었습니다.

두 요청의 차이를 가르는 것이 CSS와 HTML의 경계입니다. 보이는 방식만 달라지면 스타일 파일에서 끝나고, 무엇이 어디에 속하는지가 달라지면 문서 쪽을 건드려야 합니다. 그래서 디자인 시안을 받았을 때 개발자가 가장 먼저 하는 판단도 이 경계를 어디에 긋느냐입니다.

문법이 단순하니 금방 배운다고 보는 경우가 가장 많습니다. 제어문도 없고 속성과 값을 짝지어 적는 게 전부로 보이니 그렇게 읽힙니다. 실제로 어려운 쪽은 문법이 아니라 규칙이 겹칠 때의 우선순위와, 한 요소를 고쳤는데 옆이나 아래 요소의 자리가 함께 밀리는 현상입니다. 이 구조를 모른 채 쌓아 가면 안 먹히는 규칙마다 강제 적용 표시를 붙이는 습관이 생기고, 반년 뒤에는 아무도 손대지 못하는 스타일 파일이 남습니다.

CSS를 디자이너의 일로 미루는 것도 흔합니다. 색과 여백을 다루니 디자인 영역처럼 보이지만, CSS가 만들어 내는 결과는 화면에 실제로 그려지는 요소들의 배치이고 그 배치는 DOM의 구조와 맞물려 정해집니다. 어떤 배치는 문서 구조를 바꾸지 않으면 애초에 나오지 않습니다. 이 경계를 모르고 디자인을 넘기면 구현 단계에서 왜 안 되는지를 두고 매번 같은 대화를 반복하게 됩니다.