2019년쯤이었나. 프로젝트에서 node-sass를 dart-sass로 교체하고 나서 CI 빌드 시간이 40초 줄었을 때, 팀 슬랙에 "🎉" 리액션이 12개 달렸다. Sass 전처리기가 프론트엔드 빌드 체인에서 차지하는 무게를 체감한 순간이었다. 그로부터 7년, W3C가 CSS 네이티브 믹스인 스펙을 밀어붙이고 있고, Chrome 146에서 @mixin과 @apply가 실제로 돌아갈 예정이다.

뭐가 오는 건지부터

CSS Functions and Mixins Module Level 1 — W3C 에디터스 드래프트 단계다. 핵심은 두 가지 at-rule이다.

@mixin --center {
  display: flex;
  align-items: center;
  justify-content: center;
}

.card {
  @apply --center;
  gap: 1rem;
}

Sass 써본 사람이면 눈에 익는 구조다. 다른 점은 이게 브라우저가 직접 해석한다는 것. 빌드 타임 변환이 아니라 런타임 해석이다. 파라미터도 된다:

@mixin --responsive-grid(--cols, --gap: 1rem) {
  display: grid;
  grid-template-columns: repeat(var(--cols), 1fr);
  gap: var(--gap);
}

.dashboard {
  @apply --responsive-grid(--cols: 3, --gap: 2rem);
}

@contents at-rule로 슬롯 패턴까지 지원하니까, Sass의 @content 블록과 거의 동일한 표현력을 갖는다.

그래서 Sass 드랍해도 되냐

아직은 아니다. 분명히 해두자.

Chrome 146 출시 예정이 2026년 중반이고, Edge는 따라올 거다. 문제는 Firefox와 Safari다. 두 브라우저 모두 구현 의사를 밝히긴 했지만 구체적인 타임라인은 없다. MDN 문서에도 "experimental" 딱지가 붙어 있는 상태. 즉, 프로덕션에서 Sass 걷어내려면 Baseline 도달까지 기다려야 하고, 그건 아무리 빨라도 2027년 초다.

하지만 여기서 중요한 건 방향성이다. CSS 자체가 프리프로세서의 존재 이유를 하나씩 흡수하고 있다. 커스텀 프로퍼티가 변수를 대체했고, color-mix()가 색상 함수를 가져갔고, 네스팅이 2023년에 들어왔다. 믹스인은 Sass가 CSS 위에 군림하던 마지막 보루 중 하나였는데, 그것마저 네이티브로 넘어간다.

빌드 파이프라인에 미치는 영향이 진짜 크다

내가 제일 기대하는 건 번들 사이즈나 문법이 아니라 빌드 체인 단순화다.

현재 전형적인 프론트엔드 프로젝트의 CSS 처리 흐름:

  1. Sass/SCSS 컴파일 (dart-sass 또는 sass-embedded)

  2. PostCSS 플러그인 체인 (autoprefixer, cssnano 등)

  3. CSS Modules 또는 CSS-in-JS 변환

  4. 번들러 통합 (Vite의 css.preprocessorOptions 등)

네이티브 믹스인이 Baseline에 도달하면 1번이 통째로 빠진다. dart-sass 의존성, .scss 파일 확장자, @use/@forward 모듈 시스템 — 전부 필요 없어진다. Vite 설정에서 preprocessorOptions.scss 블록을 지우는 그 순간, CI 파이프라인에서 sass-embedded 바이너리 다운로드가 사라지고, 콜드 빌드가 체감될 정도로 빨라진다.

Tailwind CSS v4가 이미 PostCSS 플러그인 방식을 버리고 자체 엔진으로 갈아탄 것도 같은 맥락이다. 빌드 스텝을 줄이는 게 2026년 프론트엔드 툴링의 가장 큰 흐름이고, 네이티브 믹스인은 그 퍼즐의 마지막 조각에 가깝다.

@function은 좀 다른 얘기

믹스인 옆에 @function도 같은 스펙에 들어있다. 이쪽은 값을 반환하는 순수 함수:

@function --clamp-size(--min, --max) {
  result: clamp(var(--min), 5vw, var(--max));
}

h1 {
  font-size: --clamp-size(--min: 1.5rem, --max: 3rem);
}

근데 @function은 @mixin보다 스펙 안정성이 한 단계 낮다. Chrome 팀도 믹스인을 먼저 밀고 있고, 함수는 아직 변동 가능성이 크다. 실무 관점에서는 일단 믹스인 동향만 추적해도 충분하다.

지금 당장 할 수 있는 건

Chrome Canary에서 chrome://flags/#enable-experimental-web-platform-features 플래그를 켜면 @mixin을 테스트해볼 수 있다. 진짜 프로덕션에 넣으라는 게 아니라, 기존 Sass 믹스인을 네이티브 문법으로 포팅하는 연습을 해보라는 뜻이다. 특히 디자인 시스템 토큰 레이어를 관리하는 팀이라면, 믹스인 마이그레이션 플랜을 미리 잡아두는 게 나중에 시간을 아껴줄 거다.

한 가지 주의할 점 — 네이티브 믹스인은 커스텀 프로퍼티 네임스페이스(--)를 쓴다. 기존 CSS 변수와 이름이 충돌하지 않도록 네이밍 컨벤션을 지금부터 정리해두면 좋다. --mixin-이나 --fn- 같은 접두사를 팀 내에서 합의하는 것도 방법이다.

Sass가 사라지는 게 아니라, Sass가 해왔던 일을 브라우저가 대신 해주는 시대가 온다. node-sass 에러 메시지에 시달리던 그 시절을 기억하는 사람이라면, 이건 꽤 감격스러운 전환이다.