TL;DR

  • CSS가 30주년을 맞는 2026년에도 웹사이트에 CSS를 적용하는 방식은 합의되지 않았으며, 프로젝트의 프레임워크 사용 여부와 스타일 범위가 선택의 핵심임.
  • 관심사의 분리(Separation of Concerns)는 CSS를 출력물에, 동작의 지역성(Locality of Behavior)은 CSS를 소스 파일에 범위 지정하는 방식임.
  • 전역 스타일은 여러 페이지에 걸친 변경과 스타일 재사용에 효율적이지만, 프로젝트가 커질수록 의도치 않은 선택자 일치와 덮어쓰기 때문에 취약해짐.
  • 범위가 지정된 스타일은 전역 변경의 효율성을 일부 포기하는 대신, 각 요소의 스타일을 이해하고 수정하기 쉽게 하며 대규모 코드베이스의 복잡성을 줄임.
  • 프레임워크가 없다면 관심사의 분리를, 프레임워크를 사용한다면 동작의 지역성을 권장하며, Nordcraft는 요소별로 다른 요소에 영향을 주지 않는 엄격한 범위 지정 스타일을 채택함.

CSS는 30년이 지나도 스타일링 방식을 두고 논쟁 중임

  • 올해 12월 CSS가 30주년을 맞지만, 웹사이트에 CSS를 추가하는 기본 방식조차 합의되지 않은 상태임.
  • 선택지로 CSS 모듈, Tailwind, CSS-in-JS, 일반 CSS 파일이 거론됨.

관심사의 분리와 동작의 지역성

  • 두 접근 방식의 핵심 차이는 범위(scope)임. 동작의 지역성에서는 CSS가 소스 파일을 기준으로 범위 지정되고, 관심사의 분리에서는 출력물을 기준으로 범위 지정됨.
  • Vue.js에서 scoped 속성을 사용하면 Vue 컴파일러가 각 컴포넌트에 고유한 해시를 생성함.
  • 컴파일된 CSS는 해당 컴포넌트가 생성한 HTML에만 스타일을 적용하므로 스타일의 범위가 파일 내부로 제한됨.
  • scoped 속성을 제거하면 동작의 지역성에서 관심사의 분리로 전환됨.
  • 스타일 태그의 CSS가 해당 컴포넌트에서 렌더링했는지와 관계없이 페이지의 모든 문단을 대상으로 하며, 스타일은 범위가 지정되지 않은 전역 스타일이 됨.
  • 각 접근 방식의 범위 차이를 이해하면 프로젝트에 적합한 방식을 더 잘 판단할 수 있음.

범위의 문제

  • 전역 스타일의 장점은 여러 페이지의 스타일을 한 번에 쉽게 바꿀 수 있다는 점임. 모든 문단을 빨간색으로 만들려면 문단 선택자에 color: red;를 추가하면 됨.
  • 더 구체적인 스타일은 캐스케이드(cascade)로 만들 수 있음. 캐스케이드는 효율적인 CSS 작성을 가능하게 하며, 작은 프로젝트에서는 작성과 이해가 쉬운 CSS를 제공함.
  • 프로젝트가 커지면 캐스케이드 규칙과 의도하지 않은 요소를 선택할 가능성도 함께 늘어남.
  • 문단의 종류가 다양해지고 다른 캐스케이드 규칙의 스타일을 덮어써야 하면서 CSS가 취약해짐.
  • p { font-size: 1rem; } 같은 규칙을 바꾸면 의도하지 않은 여러 문단의 스타일이 깨질 가능성이 큼.
  • 범위 지정 스타일은 효율성을 단순성과 맞바꾸는 선택임. 모든 문단의 글자 크기를 한 번에 바꾸는 능력은 잃지만, 이해에 필요한 스타일이 눈앞에 모여 있어 CSS를 파악하기 쉬워짐.

“그건 실력 문제임!”

  • CSS-in-JS나 Tailwind 같은 범위 지정 스타일 솔루션에 대한 흔한 비판은 CSS를 충분히 잘 알지 못하는 사람만 이런 도구를 필요로 한다는 주장임. CSS를 제대로 작성하면 규모가 커져도 잘 확장된다는 주장도 이에 포함됨.
  • 두 접근 방식 모두 올바르게 사용하면 확장 가능하다는 점은 기술적으로 맞음.
  • 차이는 전역 스타일에서 실수하기가 더 쉽고, 스타일에 범위가 지정되지 않아 실수의 영향도 대체로 훨씬 크다는 점임.
  • 전역 스타일을 사용하는 코드베이스를 확장하려면 범위 지정 스타일을 사용하는 경우보다 훨씬 높은 코드 품질이 필요함. 전역 스타일에서는 코드베이스가 커질수록 코드 품질도 선형적으로 높아져야 함.

어떤 방식을 선택할까?

  • 프레임워크를 사용하지 않는다면 효율적이고 필요할 때 사이트 전반에서 스타일을 재사용할 수 있는 관심사의 분리를 권장함.
  • 컴포넌트가 이미 스타일을 포함한 코드 재사용 방식을 제공하므로, 두 번째 재사용 메커니즘을 추가하면 가치보다 복잡성이 커짐.
  • 매우 큰 프로젝트에서는 기능을 구현하거나 버그를 수정할 때 코드베이스의 95%를 무시할 수 있는 것이 큰 장점임. JavaScript와 CSS 모두에서 범위 지정이 중요한 이유임.

프로젝트가 커질수록 코드 품질이 향상되어야만 유지되는 아키텍처는 나쁜 아키텍처임.

  • 프레임워크를 사용해야 하는 프로젝트라면 동작의 지역성을 선택하는 것이 좋다는 입장임.

예외 사항

  • 경력 중 정확히 두 차례, 하나의 코드베이스를 여러 사이트에서 사용해야 하는 프로젝트를 경험했으며 두 사례 모두 이커머스였음.
  • 사이트들은 같은 HTML을 사용하면서도 스타일은 완전히 달라야 했음. 차이가 색상과 테두리 반경을 훨씬 넘어 각 사이트에 별도의 스타일시트가 필요했음.
  • 두 사례 모두 관심사의 분리가 명확한 선택이었으며, 사이트가 성장하면서 생기는 추가 어려움을 감수해야 했음.
  • 디자이너가 CSS 대부분을 작성하지만 React와 JavaScript를 포함한 전체 개발 환경 사용에는 익숙하지 않은 사이트도 경험했음.
  • 이런 경우 관심사의 분리를 통해 디자이너가 코드베이스에 기여할 수 있었으며, 그렇지 않았다면 기여하기 어려웠음.

개선의 여지는 여전히 있음

  • CSS가 30년 전 도입됐을 때 웹은 문서를 공유하는 플랫폼이었음. 당시에는 HTML과 CSS를 분리하는 것이 합리적이었기에 CSS도 HTML과 분리되도록 설계됨.
  • 프레임워크가 HTML 작성 방식을 바꾼 것처럼 CSS 작성 방식도 바뀌는 것이 자연스러움.
  • Vue와 Svelte는 단일 파일 컴포넌트와 범위 지정 스타일을 통해 좋은 선택지를 제공하지만, 개선의 여지는 여전히 있음.
  • Nordcraft의 스타일링 방식을 정할 때 매우 엄격한 범위 지정 스타일을 선택함.
  • Nordcraft에서는 요소별로 스타일을 설정하며, 한 요소의 CSS가 다른 요소에 영향을 주지 않음.
  • 이는 사실상 인라인 스타일링이지만, 캐스케이드를 이용해 의사 클래스와 미디어 쿼리 등의 스타일 규칙을 만들 수 있음.
  • JavaScript 파일에 CSS가 의존하지 않으면서도 CSS-in-JS의 개발자 경험을 제공하는 방식임.
  • Nordcraft의 여러 기능 가운데, 코드를 다시 작성할 때 가장 그리워하는 기능임.
  • CSS의 30주년을 축하하며, 앞으로 30년 동안도 CSS를 두고 논쟁이 이어질 것이라는 기대를 밝힘.