Firefox.com의 네이티브 CSS, 빌드 도구는 어디까지 줄일 수 있을까
Firefox.com의 CSS 구현과 공개 빌드 설정을 대조해 네이티브 CSS를 적용할 조건을 살펴본다. 작성 문법, 배포 처리, 브라우저 지원을 구분하면 유지할 도구와 줄일 도구를 판단하기 쉬워진다.
CSS 변수를 쓸 수 있고 복잡한 배치도 브라우저가 처리한다면, 스타일을 빌드하는 도구는 어디까지 줄일 수 있을까. Firefox.com의 재구축 사례는 이 질문을 구체적으로 살펴볼 기회를 준다. 디자인을 작성하는 문법과 실제로 배포하는 파일 사이에 어떤 처리가 남는지 확인해야 도구를 덜어낼 수 있다.
이 사례를 설명한 Jo Sprague의 원문은 2026년 8월 14일 작성됐고 9월 16일 갱신됐다. GeekNews에는 9월 17일 오전 2시 53분에 등록됐다. 최근 다시 소개된 구현 사례이며, 오늘 새로운 CSS 기능이나 사이트가 출시됐다는 소식은 아니다.
CSS가 맡을 수 있는 일이 늘었다
Sprague는 Mozilla·Lincoln Loop와 함께 Firefox.com을 만들면서 네이티브 CSS, 즉 브라우저가 이해하는 CSS 문법으로 현대적인 디자인을 구현하려 했다고 설명한다. 디자인 시스템은 70개 이상의 컴포넌트와 25개 페이지 템플릿으로 구성됐고, 이를 Wagtail CMS의 컴포넌트로 제공해 콘텐츠 팀이 페이지를 조립하도록 했다. 구현자의 설명이다.
이 선택의 배경에는 Custom Properties, Grid, Flexbox의 발전이 있다. Custom Properties는 색상·간격 같은 값을 CSS 안에서 이름으로 참조하는 기능이다. 반복되는 디자인 값을 여기에 담고 배치를 Grid와 Flexbox로 표현하면, 별도 언어로 작성해야 했던 규칙 일부를 브라우저의 기능으로 옮길 수 있다.
공개된 토큰 파일에는 디자인 도구에서 추출한 색상 등이 들어 있다. 디자인 토큰은 여러 화면에서 공유하는 디자인 값에 이름을 붙인 것이다. 스타일 진입점은 기본 스타일, 테마, 컴포넌트, 유틸리티 등을 레이어로 나눈다. 레이어는 스타일 규칙을 묶고 묶음 사이의 우선순위를 정하는 기능이다.
내가 주목한 부분은 콘텐츠 담당자에게 제공하는 선택지가 컴포넌트로 정리돼 있다는 점이다. 토큰과 컴포넌트를 누가 관리하고 어디까지 조합할 수 있는지가 정해져야 CSS의 재사용성이 실제 운영으로 이어진다고 본다. CSS 문법의 발전만으로 이 설계가 저절로 생기지는 않는다.
공개 소스를 읽으면 빌드의 역할이 더 보인다
원문에는 프로덕션에서 PostCSS로 @import를 펼친다는 설명이 있다. 다른 스타일시트를 가져오는 @import를 미리 합치면, 브라우저가 파일을 읽다가 다음 파일을 발견해 요청하는 의존 관계를 줄일 수 있다. 저자는 작성한 CSS의 유효성 자체는 빌드에 의존하지 않는다고 설명한다. 원문의 갱신 내용
그런데 9월 17일 확인한 저장소에는 이 설명만으로는 드러나지 않는 처리가 있다. flare.css의 구형 브라우저용 분기는 @supports 안에 @import를 넣는다. 소스의 주석도 이것이 유효한 CSS가 아니며 사용자 정의 로더로 펼친다고 명시한다. 확인한 소스와 로더 구현을 함께 볼 필요가 있다. MDN 역시 @import를 조건부 그룹 안에 중첩할 수 없다고 설명한다. CSS 문법 규칙
또한 빌드 설정에는 postcss-custom-media가 연결돼 있고, 미디어 쿼리 토큰에는 화면 너비 조건에 이름을 붙이는 @custom-media 정의가 있다. 현재 소스를 그대로 배포하는 것과 빌드한 결과를 배포하는 것을 같은 동작으로 가정하면 안 되는 이유다.
이 차이를 근거로 사례 전체를 부정할 필요는 없다. 다만 도입할 때는 작성 문법, 파일 결합, 호환성 변환을 따로 확인해야 한다. 나는 이 구현을 CSS가 직접 맡는 범위를 넓히면서 필요한 변환을 남긴 사례로 읽는다. 여기서는 해당 저장소를 빌드하거나 성능을 측정하지 않았다.
지원할 브라우저가 사용할 문법을 결정한다
네이티브 기능도 지원 하한에 따라 선택이 달라진다. flare.css는 지속적으로 업데이트되는 브라우저와 Safari 15.6 이상을 목표로 명시하고, Safari 15.6에서 지원되지 않는 중첩 규칙이나 일부 색상 함수에 주의를 준다. 소스의 지원 조건이다. 네이티브 CSS를 쓴다는 말이 최신 문법을 모두 사용할 수 있다는 뜻은 아니다.
Mozilla의 브라우저 지원 문서는 향상된 레이아웃을 제공하는 범위와, 읽기 및 기본 기능을 유지하는 범위를 구분한다. 이 표의 갱신 표기는 2025년 1월 20일이므로 모든 서비스의 현재 지원 목록으로 가져와서는 안 된다. 여기서 참고할 점은 경험의 수준을 나눠 정의한다는 접근이다.
다운로드 버튼이 있는 안내 페이지라면 오래된 브라우저에서도 내용을 읽고 버튼을 사용할 수 있어야 한다. 반면 복잡한 배치까지 똑같이 재현해야 하는지는 별도 결정이다. 이렇게 요구를 나누면 대체 스타일에 드는 비용과 포기할 수 있는 표현을 구체적으로 논의할 수 있다. 자신의 서비스에서는 실제 방문 환경과 핵심 사용자 흐름을 기준으로 범위를 다시 정해야 한다.
도구를 지우기 전에 역할을 나눠 본다
CSS 도구를 줄이려는 팀이라면 현재 빌드 단계가 하는 일을 먼저 적어 보겠다.
| 빌드가 맡는 일 | 줄이거나 유지할 때 확인할 조건 |
|---|---|
| 변수와 반복 규칙 표현 | CSS 토큰과 컴포넌트 규칙으로 같은 변경을 설명할 수 있는가 |
| 파일 결합과 압축 | 요청 구조와 전송량을 유지하거나 개선할 수 있는가 |
| 지원되지 않는 문법 변환 | 가장 오래된 지원 브라우저에 유효한 결과가 전달되는가 |
공통 디자인을 여러 페이지에 반복하는 CMS나 콘텐츠 사이트는 작은 컴포넌트부터 비교하기 좋다. 예를 들어 카드 한 종류를 골라 토큰 변경, 긴 번역문, 키보드 포커스, 좁은 화면을 확인한다. 작성 파일과 생성 파일을 비교하면 제거하려는 플러그인이 실제로 무엇을 대신하고 있는지도 드러난다.
이미 Sass의 반복 생성이나 유틸리티 도구에 깊이 의존하는 팀이라면 전환 비용도 함께 계산해야 한다. 기존 도구를 유지하면서 색상과 간격만 Custom Properties로 옮기거나, 새 컴포넌트부터 표준 CSS를 적용하는 방법도 있다. 핵심은 파일 확장자가 아니라 변경을 이해하고 검증하는 비용이다.
Firefox.com에서 가져갈 기준은 세 가지다. 브라우저가 직접 이해할 규칙을 늘리고, 남겨 둔 빌드 단계의 이유를 설명하고, 지원 범위 밖에서도 유지할 사용자 경험을 정한다. 이 세 가지를 컴포넌트 하나에서 확인한 뒤 전환 범위를 넓히는 편이 합리적이라고 본다.
참고 자료
이 이야기가 도움이 되었나요?