Part 10: 실전 종합 + Sass를 언제 써야 할까?
Part 10: 실전 종합 + Sass를 언제 써야 할까?
지금까지 총 9개의 파트에 걸쳐 모던 CSS의 핵심 기능들을 배웠습니다. 커스텀 프로퍼티, CSS 네스팅, 최신 선택자, 컨테이너 쿼리, @layer, 색상·수학 함수, Grid + Subgrid, 애니메이션까지 다루었습니다.
이번 마지막 파트에서는 지금까지 배운 내용을 종합적으로 정리하고, 현실적인 관점에서 **“언제 Sass를 써야 하는가?”**에 대한 명확한 기준을 제시하겠습니다.
1. 지금까지 배운 주요 기능 정리
AD
제휴 광고 · 일부 링크는 수수료를 받을 수 있습니다
이 시리즈에서 다룬 내용들을 한 번 더 정리해보겠습니다:
- Part 1~2: 선택자·특정도, 커스텀 프로퍼티 (Sass 변수 대체)
- Part 3: CSS 네스팅과
&선택자 - Part 4: :has(), :is(), :where(), :not() 등 최신 선택자
- Part 5: 컨테이너 쿼리 (@container)
- Part 6: @layer와 @scope를 통한 CSS 아키텍처 관리
- Part 7: oklch, color-mix, clamp 등 색상·수학 함수
- Part 8: Grid + Subgrid를 포함한 고급 레이아웃
- Part 9: 애니메이션과 View Transitions API
이 기능들만 잘 활용해도, 대부분의 현대적인 웹 프로젝트에서 충분히 깔끔하고 강력한 CSS를 작성할 수 있습니다.
2. 2026년 기준 현실적인 추천 스택
AD
제휴 광고 · 일부 링크는 수수료를 받을 수 있습니다
현재 시점에서 대부분의 신규 프로젝트에 추천하는 CSS 스택은 다음과 같습니다:
- 기본 스택: 네이티브 CSS + 커스텀 프로퍼티 + 네스팅 + @layer
- 고급 활용: 컨테이너 쿼리 + :has() + oklch + Subgrid
- 필요 시 추가: PostCSS (autoprefixer, 미래 문법 플러그인)
- 복잡한 로직이 필요할 때만: Sass 또는 Lightning CSS
3. Sass를 아직 쓰는 게 나을 때
그럼에도 불구하고 Sass를 사용하는 것이 더 나은 경우가 있습니다. 아래는 그 기준입니다:
- 매우 복잡한 로직이 들어간 재사용 가능한 믹스인이 필요한 경우
@for,@each같은 루프를 사용해 대량의 유틸리티 클래스를 생성해야 할 때- 거대한 레거시 프로젝트를 유지보수해야 할 때 (이미 Sass로 되어 있는 경우)
- 팀 내에 이미 강력하게 구축된 Sass 기반 디자인 시스템이 있을 때
- 빌드 타임에 복잡한 색상 계산이나 수학 연산이 필요한 경우
4. 결론
AD
제휴 광고 · 일부 링크는 수수료를 받을 수 있습니다
2026년 현재, 대부분의 프로젝트에서 Sass 없이도 충분히 강력하고 유지보수하기 쉬운 CSS를 작성할 수 있습니다. CSS 네스팅, 커스텀 프로퍼티, 컨테이너 쿼리, @layer 등의 기능이 Sass가 하던 많은 역할을 대신해 주고 있기 때문입니다.
다만 프로젝트의 규모, 팀 상황, 기존 코드베이스에 따라 Sass를 병행하는 것도 여전히 유효한 선택입니다. 중요한 것은 “무조건 Sass를 버리자”가 아니라, 상황에 맞게 최선의 도구를 선택하는 것입니다.
이 시리즈를 통해 모던 CSS에 대한 이해가 한층 깊어지셨기를 바랍니다.
읽어주셔서 감사합니다.
AD
제휴 광고
일부 링크는 제휴 링크이며, 구매 또는 가입 시 일정 수수료를 받을 수 있습니다.
AD