스타일이 몇백 줄을 넘어가면 변수 · 중첩 · 파일 분할이 필요해집니다. SCSS 를 붙이는 일 자체는 어렵지 않습니다. 진짜 결정은 그다음에 옵니다 — 컴파일된 CSS 를 저장소에 커밋할 것인가.
가장 단순한 구성
필요한 것은 컴파일러 하나와 스크립트 두 줄입니다. 소스는 assets/scss/, 산출물은 assets/dist/ 에 두고, enqueue 는 산출물만 가리킵니다.
{
"scripts": {
"build": "sass assets/scss/main.scss assets/dist/main.css --style=compressed --no-source-map",
"watch": "sass --watch assets/scss/main.scss:assets/dist/main.css"
}
}진입점 파일 하나(main.scss)가 나머지를 전부 불러오는 구조로 두면, 파일을 아무리 쪼개도 브라우저가 받는 요청은 한 개로 유지됩니다. 이것이 SCSS 분할이 성능을 해치지 않는 이유입니다.
Node 는 빌드 타임에만 필요합니다
여기가 판단의 핵심입니다. 컴파일러는 개발자의 기계에서만 돌면 되고, 운영 서버에는 Node 가 없어도 됩니다. 오히려 없는 편이 낫습니다 — 공격 표면과 이미지 크기가 줄고 배포가 단순해집니다.
그런데 워드프레스 테마의 배포 방식은 대개 “파일을 올린다” 입니다. zip 으로 배포하든 저장소를 그대로 배치하든, 중간에 빌드가 도는 단계가 없습니다. 그래서 산출물이 저장소 안에 없으면 서버에 스타일이 존재하지 않습니다.
커밋의 대가를 정직하게 적습니다
빌드 산출물을 커밋하는 것은 일반적인 애플리케이션 코드에서는 권장되지 않습니다. 그 관례에는 이유가 있고, 그 이유는 테마에서도 그대로 발생합니다.
정리하면 이렇습니다. 배포 파이프라인이 이미 있고 거기서 빌드를 돌릴 수 있다면 커밋하지 않는 편이 깔끔합니다. 파일을 올려서 배포하는 일반적인 워드프레스 환경이라면 커밋이 맞습니다. 중요한 것은 어느 쪽을 고르든 그 이유를 문서에 적어 두는 것입니다 — 다음 사람이 같은 논쟁을 처음부터 다시 하지 않도록.
커밋하기로 했다면 대가를 관리해야 합니다. dist/ 는 절대 손으로 고치지 않는다는 규칙을 세우고, 커밋 전에 빌드를 한 번 돌리고, 병합 충돌은 손으로 풀지 않고 다시 빌드해서 해결합니다. 컴파일 결과를 수동으로 병합하는 것은 정의상 의미가 없는 작업입니다.
빌드 실패가 파일을 비웁니다
알아 둘 함정이 하나 있습니다. 컴파일러는 대개 출력 파일을 먼저 비우고 쓰기 때문에, 문법 오류로 빌드가 실패하면 산출물이 빈 파일로 남습니다. 화면이 통째로 스타일 없이 나오는데 원인은 CSS 가 아니라 터미널에 있습니다.
그래서 빌드 성공을 눈으로 확인하고 커밋하는 습관이 필요하고, 산출물이 버전 관리 안에 있다는 사실이 이때 안전망이 됩니다 — 되돌릴 곳이 있다는 것 자체가 커밋 쪽 논거를 하나 더 보태 줍니다.
소스맵은 별도 판단입니다. 개발에는 유용하지만 운영에 함께 올리면 SCSS 구조가 그대로 공개됩니다. 위험한 정보는 아니지만, 의도해서 올리는 것과 모르고 올리는 것은 다릅니다.
저장소 운영과 배포 절차를 다루는 글은 개발 워크플로우 아카이브에 있고, 배포 파이프라인을 포함한 환경 정비를 한 번에 맡기고 싶다면 최적화 지원 사업에 포함돼 있습니다.
다음 회차
화면을 그리기 시작하면 값을 출력하게 됩니다. 다음 회차는 출력 이스케이프입니다 — 왜 입력이 아니라 출력에서 처리하는지, 그리고 자리마다 함수가 다른 이유를 다룹니다.