Firefox.com 네이티브 CSS 재구축, CSS Zen Garden이 실제로 실현된 사례

2026년 9월 17일

CSS Zen Garden이 던진 질문 — HTML 파일 하나를 CSS만으로 완전히 다르게 꾸밀 수 있는가 — 는 2003년 5월 Dave Shea가 시작한 프로젝트에서 나왔습니다. 그 질문이 대형 상용 사이트에서 실현됐다는 보고가 있습니다. Jo Sprague가 2026년 8월 14일 발행하고 9월 16일 갱신한 글 "The CSS Zen Garden dream, finally shipped"의 요지입니다. Firefox.com을 Mozilla와 Lincoln Loop가 함께 전처리기 없는("no pre-processors") 현대적 네이티브 CSS로 다시 지었다는 것입니다. 저자 발언 기준으로 이 디자인 시스템은 70개가 넘는 컴포넌트와 25개 페이지 템플릿입니다.

이 글은 원문과 Lincoln Loop 사례 페이지, 공개 저장소 mozmeao/springfield를 겹쳐 읽은 정리입니다. 사이트를 직접 만지거나 빌드를 돌려 본 글은 아닙니다. 겹쳐 읽자 규모는 출처마다 다르게 적혀 있었고 수치를 합치지 않고 출처별로 옮깁니다.

CSS Zen Garden부터 Firefox.com 재구축 보고까지의 흐름을 나타낸 타임라인. 2003년 5월 Dave Shea가 CSS Zen Garden을 시작했고, 2008년 글쓴이 Jo Sprague가 대학 졸업 직후 이 프로젝트를 접했으며, 2026년 8월 14일 "The CSS Zen Garden dream, finally shipped"가 발행되고 2026년 9월 16일 갱신됐다.

2003년의 실험과 2008년의 회상, 2026년의 보고가 이어진다.

CSS Zen Garden이 던진 질문과 2008년의 위치

CSS Zen Garden은 하나의 HTML 파일을 건드리지 않고 CSS만 갈아 끼워 전혀 다른 디자인을 보여주는 프로젝트입니다. 글쓴이는 원문에서 2008년, 대학 졸업 직후 이 프로젝트를 발견했다고 회상합니다. 그것을 "하나의 HTML 파일이 CSS만으로 완전히 다른 무언가로 다시 꾸며질 수 있는 Dave Shea의 프로젝트"라고 소개합니다.

연도가 둘 나옵니다. 프로젝트의 시작은 2003년 5월이고 글쓴이가 처음 접한 것은 2008년입니다. 앞의 값은 csszengarden.com과 Wikipedia로 확인되는 사실이고 뒤의 값은 저자의 회상입니다. 이 둘을 섞은 "저자가 2003년에 이 프로젝트를 발견했다" 같은 서술은 원문에 없습니다.

이 실험이 증명하려던 것을 csszengarden.com 문구가 말해줍니다 — "Luckily, designing this way shows how well various browsers have implemented CSS by now."(이런 식으로 디자인하면 여러 브라우저가 지금까지 CSS를 얼마나 잘 구현했는지도 드러난다). CSS만으로 어디까지 갈 수 있는가를 보여주는 동시에, 브라우저의 구현 수준을 가늠하는 잣대이기도 했습니다.

원문 제목 "dream, finally shipped"는 이 질문이 대형 상용 사이트에서 답된 것처럼 보인다는 선언입니다.

재구축에서 실제로 바뀐 것 — 규모 숫자는 셋이다

규모에 대한 저자의 문장은 이것입니다 — "Together we built a design system of more than 70 components and 25 page templates, implemented as Wagtail components so the site's content team can create pages for any locale without engineering help."(함께 70여 개 컴포넌트와 25개 페이지 템플릿의 디자인 시스템을 Wagtail 컴포넌트로 구현해, 사이트 콘텐츠 팀이 엔지니어링 도움 없이 어느 로캘의 페이지든 만들 수 있게 했다)

이 발언의 "we"에 대해서도 출처만 옮깁니다. 원문은 이 재구축을 Mozilla와 Lincoln Loop와 함께 한 일로 소개합니다. 글쓴이의 직함은 "Staff Software Engineer, Design Systems and Front-End Platforms"이고 2008년부터 CSS로 디자인 시스템을 만들어 왔다고 밝히지만 Lincoln Loop 소속이라고 쓸 근거는 확인하지 못했습니다.

Lincoln Loop 사례 페이지는 다르게 셉니다 — 문서화된 컴포넌트 41개, 지원 로캘 16개, 주간 방문자 6,000만, 기간은 "Duration: 9 months, plus ongoing support"(9개월, 이후 지속 지원)입니다. 70과 41은 기준이 다른 숫자라 "70개 중 41개가 문서화됐다" 식으로 합치면 근거 없는 계산이 됩니다. 규모 숫자는 출처별로 따로 부릅니다.

숫자	출처
컴포넌트 70+ · 페이지 템플릿 25	원문의 저자 발언 (2026-08-14 발행)
문서화된 컴포넌트 41 · 지원 로캘 16 · 주간 방문자 60M · 9개월 + 지속 지원	Lincoln Loop 사례 페이지
CSS 컴포넌트 파일 57	mozmeao/springfield 저장소 실측 (2026-09-17 카운트)

셋째 값은 저장소 쪽입니다. 공개 저장소를 2026-09-17 기준으로 세면 media/css/cms/components/ 아래 CSS 컴포넌트 파일은 57개입니다. 문서화 수치(70+/25, 41)와의 대응은 확인된 바가 없어 주장하지 않습니다.

Wagtail 연결은 Lincoln Loop의 문장이 구체적입니다 — "Firefox marketing team"(Firefox 마케팅 팀)이 페이지들을 독립적으로 만들고 발행할 수 있게 하는 Wagtail CMS 컴포넌트 묶음을 만들었다고 적습니다. 이 사이트에서 Wagtail은 콘텐츠 팀이 페이지를 구성하는 데 쓰인 CMS입니다. 원문은 같은 자리를 "content team"(콘텐츠 팀)으로 부릅니다. 두 표현이 같은 팀이라는 확인은 없어 각각 출처와 함께 옮깁니다.

스타일 재료도 바뀌었습니다. 원문은 "design tokens exported directly from design files into Custom Properties"(디자인 파일에서 바로 뽑아 Custom Properties로 옮긴 디자인 토큰)라고 적습니다. 저장소의 flare-tokens.css는 :root 사용자 정의 속성 모음이고 주석에는 "Static values extracted from Figma"(맥락에 따라 바뀌지 않는, Figma에서 추출한 정적 값)라고 적혀 있습니다. 어떤 도구로 뽑는지는 원문에 없으므로 "Figma 자동 export" 같은 구체화는 하지 않습니다.

Firefox.com 재구축의 규모를 세 곳의 출처로 나눠 보여주는 표. 원문의 저자 발언은 컴포넌트 70개 이상과 페이지 템플릿 25개, Lincoln Loop 사례 페이지는 문서화된 컴포넌트 41개와 지원 로캘 16개, 주간 방문자 6천만, 9개월+지속 지원, 저장소 실측(2026-09-17)은 CSS 컴포넌트 파일 57개다.

같은 사이트를 세는 기준이 출처마다 다르다.

전처리기가 없지 빌드가 없는 것은 아니다

"no pre-processors"를 "빌드가 없다"로 읽으면 반쯤 놓칩니다. 원문 본문의 문장은 "All of the styles written purely in native CSS with no special syntax"(모든 스타일은 특수 문법 없이 순수한 네이티브 CSS로 작성됐다)까지입니다. Sass류 전처리 문법이 없다는 뜻이지 도구 체인이 없다는 뜻이 아닙니다. 전처리기가 없고 작성 CSS는 네이티브 문법이며 빌드(PostCSS·webpack)는 @import 평탄화 용도로 남아 있습니다.

경계는 저자 각주 1에 그대로 적혀 있습니다.

"We did end up using PostCSS in production to inline @import statements. But the authored CSS is still plain, native CSS. Nothing in it depends on a build step to be valid or to make sense. The build only flattens what the browser would otherwise fetch serially."(프로덕션에서 @import 인라인을 위해 PostCSS를 쓰게 됐다. 그러나 작성된 CSS는 여전히 평범한 네이티브 CSS이고, 유효하거나 의미가 통하는 데 빌드가 필요하지 않다. 빌드는 브라우저가 순차로 가져와야 할 것을 평탄화할 뿐이다.)

flare.css의 주석도 같은 경계를 적습니다 — "Nested @imports are not valid CSS, but these are inlined by a custom webpack loader."(중첩된 @import는 유효한 CSS가 아니지만, 커스텀 webpack 로더가 인라인한다). 저장소에는 webpack 설정이 셋 있습니다. 예외가 하나 명시돼 있습니다 — fallback 블록의 중첩 @import는 "유효한 CSS가 아니다"가 주석의 문장 그대로입니다.

"Sass가 사라졌다"고 읽으면 이것도 틀립니다. 저장소 전체에는 .scss 파일이 80개 남아 있고 CMS 스타일 디렉터리인 media/css/cms/ 안에도 base.scss, rich-text.scss, routing/resolver.scss 셋이 있습니다. 정확히는 — 새로 지은 CMS 스타일(Flare)이 전부 .css입니다.

작성 단계와 배포 단계의 경계를 보여주는 도식. 개발자가 쓰는 CSS는 특수 문법 없는 네이티브 문법이고, PostCSS와 셋의 webpack 설정이 @import를 인라인해 평탄화하며, 브라우저는 그 결과물을 받는다. fallback 블록의 중첩 @import는 유효한 CSS가 아니라는 예외가 주석에 명시돼 있다.

빌드는 문법을 바꾸지 않고 @import만 평탄화한다.

브라우저 지원은 두 단계로 읽히지만 문서는 네 단계다

원문 각주 2는 브라우저를 어떻게 나눠 받는지 두 문장으로 정리합니다.

"All of the modern browsers listed on this browser support matrix under "Enhanced support" are supported without hacks. Legacy browsers listed under "Degraded support" are supported using a basic accessible branded stylesheet."(매트릭스의 "Enhanced support" 현대 브라우저는 핵 없이 지원되고, "Degraded support"의 레거시 브라우저는 접근성을 갖춘 기본 브랜드 스타일시트로 지원된다.)

매트릭스 문서(2025-01-20 갱신)의 분류는 두 단계가 아니라 네 단계입니다.

단계	해당 브라우저
Enhanced	에버그린 브라우저 + Safari 15.6 (Windows 10 이상, macOS 10.15 이상, Linux)
Degraded	Firefox 115 ESR, Chrome 109, Chrome 116, Safari 12.1, IE10, IE11
Basic	IE9, IE8
Unsupported	IE7, IE6

Degraded의 정의는 "fully readable and accessible, but they may not get enhanced CSS layout or JS features"(완전히 읽히고 접근 가능하지만 향상된 CSS 레이아웃이나 JS 기능은 없을 수 있다)입니다. 실제 스타일시트의 대상은 flare.css 주석대로 에버그린 브라우저와 Safari 15.6 이상입니다.

Enhanced 문턱인 Safari 15.6은 현대 CSS 전부를 받지 못합니다. CSS 중첩 규칙은 Safari 16.5부터, light-dark()는 Safari 17.5부터 쓸 수 있어서 15.6에서는 빠집니다. 이 사례의 "현대 CSS"는 이런 기준선 위에서 정의돼 있습니다.

IE8까지를 명시적으로 분류해 둔 사례를 "구형 브라우저는 버렸다"고 읽으면 틀립니다. 매트릭스 문서는 Progressive Enhancement를 원칙으로 명시하고 있고 각주 2의 "basic accessible branded stylesheet"가 그 방식입니다.

Firefox.com의 브라우저 지원을 네 단계로 나눠 보여주는 표. Enhanced는 에버그린 브라우저와 Safari 15.6 이상(Windows 10 이상, macOS 10.15 이상, Linux), Degraded는 Firefox 115 ESR과 Chrome 109·116, Safari 12.1, IE10·IE11, Basic은 IE9과 IE8, Unsupported는 IE7과 IE6이다.

Degraded 단계도 완전히 읽히고 접근 가능한 상태를 유지한다.

이 사례가 성립한 조건 — 원문이 하지 않은 말과 함께

원문과 사례 페이지를 겹쳐 보면 성립 조건이 넷 보입니다. Wagtail 컴포넌트로 구현된 디자인 시스템(저자 발언 기준, 콘텐츠 팀이 엔지니어링 도움 없이 로캘별 페이지 제작), "9 months, plus ongoing support"로 표기된 지속 지원이 붙는 기간, 브라우저 매트릭스라는 문서화된 지원 정책, 그리고 디자인 파일에서 뽑아 Custom Properties로 옮긴 토큰입니다.

반대로 이 보고가 하지 않는 말도 분명합니다. "모든 사이트가 Sass를 버려야 한다"는 조언은 원문에 없습니다. 원문은 한 사이트의 사례("dream, finally shipped")를 보고할 뿐 일반론을 주장하지 않고 저장소에 SCSS가 남은 것도 그 일반론을 지지하지 않습니다. 이 글 역시 그렇게 일반화하지 않습니다.

확인된 사실로 남는 것은 둘입니다. @import 평탄화 수준의 최소 빌드와 네이티브 문법 작성의 조합이 상용 사이트에서 배포됐다는 것, 그 경계를 저자는 각주로, 저장소는 주석으로 남겨 뒀다는 것. 어디까지가 발언이고 어디서부터 실물인지 가르는 일이 이 글의 대부분이었습니다.

근거와 참고

Jo Sprague — "The CSS Zen Garden dream, finally shipped" (2026-08-14 발행, 2026-09-16 갱신) — https://josprague.com/blog/the-css-zen-garden-dream-finally-shipped/
Lincoln Loop — "Building the new Firefox.com" 사례 페이지 — https://lincolnloop.com/work/building-the-new-firefoxcom/
mozmeao/springfield 공개 저장소 (2026-09-17 카운트) — https://github.com/mozmeao/springfield
media/css/cms/flare.css 원본 — https://github.com/mozmeao/springfield/blob/main/media/css/cms/flare.css
Firefox 플랫폼 문서 — 브라우저 지원 매트릭스 (2025-01-20 갱신) — https://mozmeao.github.io/platform-docs/development/browser-support/
CSS Zen Garden — https://csszengarden.com/ · Wikipedia — https://en.wikipedia.org/wiki/CSS_Zen_Garden