쏟아지는 CSS, 베이스라인으로 안전선 긋기
매달 새로운 CSS 기능이 쏟아진다. 문제는 “멋진 기능”이 아니라 “지금 프로덕션에 써도 되는 기능”을 가려내는 일이다. web.dev가 6월 3일 펴낸 5월 베이스라인(Baseline) 다이제스트는 바로 그 경계를 매달 갱신한다. 어떤 기능이 이제 막 모든 핵심 브라우저에 도달했고(Newly available), 어떤 기능이 충분히 무르익어 마음 놓고 써도 되는지(Widely available)를 한 장에 정리한다.
“Baseline gives you clear information about which web platform features are safe to use in your projects today.”web.dev
무슨 일인가
5월 다이제스트에서 새로 베이스라인에 진입한 기능은 여섯 가지다. 부모 컨테이너의 커스텀 속성으로 자식을 스타일링하는 container style queries, <dialog>·<details>의 열림 상태를 잡는 :open 의사클래스, 팝오버를 연 컨트롤을 식별하는 ToggleEvent.source, 픽셀아트·QR에 유용한 image-rendering, 밑줄이 글자 꼬리를 피하게 하는 text-decoration-skip-ink: all, 그리고 여러 탭이 공유하는 SharedWorker다. 동시에 lh·rlh 단위, clip-path, :user-invalid 같은 기능은 이제 '널리 사용 가능' 단계로 올라서 폴백 고민 없이 쓸 수 있게 됐다.
여러 시각
같은 “빠르게 변하는 CSS” 문제를 세 글이 다른 층위에서 다룬다.
- web.dev (5월 베이스라인 다이제스트) — '새로 사용 가능'과 '널리 사용 가능'을 매달 구분해, 실험 기능과 안전 기능 사이의 선을 분명히 긋는다.
- CSS-Tricks (Interop 2026) — Blink·WebKit·Gecko 세 엔진이 앵커 포지셔닝, 뷰 트랜지션, 스크롤 기반 애니메이션 등을 올해 함께 맞추기로 합의했다며, 베이스라인이 빨라지는 근본 동력을 짚는다.
- web.dev (Chrome DevTools의 베이스라인) — 이제 DevTools 요소 패널과 Browserslist 쿼리에서 베이스라인 상태를 바로 확인할 수 있어, 지원 여부 판단을 도구로 자동화하는 길을 연다.
왜 중요한가
세 글을 겹치면 그림이 분명해진다. 엔진들이 합의(Interop)로 기능을 빠르게 수렴시키고, 베이스라인이 그 결과를 매달 '안전선'으로 번역하며, DevTools·Browserslist가 그 선을 코드와 워크플로에 박아 넣는다. 과거엔 “이 기능 사파리에서 되나?”를 일일이 caniuse로 뒤졌지만, 이제는 '베이스라인 진입 여부'라는 공통 언어로 팀이 합의할 수 있다. 새 기능을 빨리 쓰는 능력만큼, 무엇을 아직 쓰지 말지 판단하는 능력이 중요해졌다.
실무 적용
- 새 CSS를 도입할 때 “멋진가”가 아니라 “베이스라인 단계가 무엇인가”를 먼저 확인하고, Newly와 Widely를 구분해 폴백 전략을 정하라.
- Browserslist에 베이스라인 쿼리를 걸고 DevTools의 베이스라인 표시를 켜, 지원 여부 판단을 사람의 기억이 아닌 도구에 맡겨라.
- 매달 베이스라인 다이제스트를 팀 채널에 공유해, '언제부터 써도 되는지'를 개인이 아닌 팀 합의로 만들어라.
Kenny의 관점
프론트엔드 실무에서 가장 비싼 비용은 새 기능을 모르는 게 아니라, 써도 되는 시점을 잘못 잡는 것이다. 너무 일찍 쓰면 폴백 지옥에, 너무 늦게 쓰면 JS로 떡칠한 레거시에 갇힌다. 베이스라인은 그 타이밍 결정을 개인의 직감에서 팀의 공통 기준으로 옮겨준다. 나는 새 컴포넌트를 설계할 때 “이 기능의 베이스라인 단계는?”을 코드 리뷰 체크리스트의 첫 줄로 둔다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — web.dev ↗