사실 저는 코드 블록 하이라이팅 하나에도 예민한 편입니다. 블로그에 <pre> 태그 하나 올릴 때마다 DevTools를 열어서 DOM 트리를 확인하는데, Prism.js든 highlight.js든 기존 라이브러리가 뱉어내는 <span> 노드의 양을 보면 매번 한숨이 나옵니다. 키워드 하나에 <span> 하나, 문자열 리터럴에 또 <span> 하나 — 코드 50줄짜리 예제 하나에 DOM 노드가 수백 개씩 생기는 구조입니다. Lighthouse Performance 탭에서 "Avoid an excessive DOM size" 경고가 뜨는 건 시간문제죠.
그래서 velog에 번역 공개된 CSS Custom Highlight API 아티클을 보고 꽤 흥분했습니다. 핵심은 단순합니다. 텍스트를 <span>으로 잘게 쪼개는 대신, 단일 텍스트 노드를 유지한 채 JavaScript Range 객체로 문자 위치만 지정하고, CSS.highlights 레지스트리에 등록해서 ::highlight() 의사 요소로 스타일을 입히는 방식입니다. DOM 조작이 제로에 가까우니 레이아웃 재계산과 페인트 비용이 극적으로 줄어듭니다. 사용자 입장에서는 코드 블록이 많은 기술 문서나 Playground 형태의 앱에서 스크롤 버벅임이 확연히 개선되는 것이죠.
물론 한계도 분명합니다. ::highlight()로 적용 가능한 속성은 color, background-color, text-decoration, text-shadow 등 제한적이고, font-weight나 font-size 같은 속성은 먹지 않습니다. 즉 기존 구문 하이라이터처럼 키워드를 볼드 처리하는 건 불가능합니다. 브라우저 지원 현황도 Chrome 105+, Firefox 140+, Safari 17.2+로 모던 브라우저에서는 대응 가능하지만, CSS.highlights 존재 여부를 반드시 체크하고 폴백을 준비해야 합니다. Figma에서 볼 때는 괜찮았는데, 실제로 구현하면 폴백 분기 로직이 번들 사이즈를 키우는 — 전형적인 디자인-개발 갭이 여기서도 발생합니다.
이 API가 흥미로운 건, 현대 CSS가 겪고 있는 더 큰 맥락과 맞닿아 있기 때문입니다. dev.to에서 Alex Beygi가 지적한 것처럼, CSS 스펙은 이미 개발자의 인지 능력을 넘어서는 속도로 팽창하고 있습니다. 2025 State of CSS 설문에서 OKLCH 같은 Level-4 색공간을 써보고 긍정적 경험을 했다는 응답은 겨우 12%, offset-path는 2022년부터 전 브라우저 지원인데도 존재 자체를 아는 개발자가 30%에 불과합니다. shape(), path(), Container Queries, @layer, :has() — 기능이 없어서가 아니라 기능이 너무 많아서 따라잡지 못하는 시대입니다. oklch(0.7017 0.3225 328.36)을 보고 색상을 떠올릴 수 있는 사람은 거의 없습니다.
사실 이건 Tailwind가 왜 여전히 의미 있는지를 설명하는 맥락이기도 합니다. Tailwind는 CSS의 복잡성을 유틸리티 클래스라는 제약된 어휘로 평탄화합니다. OKLCH를 직접 다루는 대신 디자인 토큰 기반 text-primary, bg-muted 같은 시맨틱 클래스를 쓰면 인지 부하가 줄어들고, 동시에 디자인 시스템의 일관성도 확보됩니다. 물론 "Tailwind가 정답이냐"는 별개의 논쟁이지만, 현대 CSS의 복잡성이 높아질수록 추상화 레이어의 필요성은 커집니다. 이건 의견이 아니라 State of CSS 데이터가 보여주는 현상입니다.
그렇다면 현실적 예산 안에서 이 모든 걸 어떻게 챙길까요? Austin Welsh가 dev.to에서 제안한 "측정 가능한 예산으로서의 크래프트맨십" 프레임워크가 실용적입니다. 핵심은 세 가지 축입니다. 첫째, 디자인 토큰으로 spacing·type scale·color를 CSS 변수화하고 "raw hex 금지" 룰을 린터로 강제합니다. 둘째, 성능 예산을 CI에 박아 넣습니다 — LCP 2.5초 미만, INP 200ms 미만, 초기 루트 JS 200~300KB gzip, CSS 50~100KB gzip. 셋째, 접근성 기본값을 컴포넌트 레벨에 내장합니다 — focus ring, aria 속성, 키보드 동작을 버튼·인풋·모달 컴포넌트가 기본으로 보장하게 합니다. "에이전시 레벨 UI"란 결국 더 많은 회의가 아니라, 올바른 것을 가장 쉬운 것으로 만드는 워크플로우 설계입니다.
여기서 CSS Highlights API 같은 신기능이 갖는 위치가 명확해집니다. 이건 번들 사이즈를 줄이는 기술이 아니라, 렌더링 파이프라인 비용을 줄이는 기술입니다. 성능 예산에서 JS/CSS 파일 크기만 관리하는 팀이 많은데, 실제 사용자가 체감하는 INP나 Long Task는 DOM 복잡도와 페인트 비용에서 오는 경우가 더 많습니다. 코드 에디터, 검색 결과 하이라이팅, 실시간 마크다운 프리뷰 같은 시나리오에서 이 API는 Core Web Vitals의 숨은 병목을 해결하는 도구가 됩니다. 여기서 로딩 스켈레톤을 넣는 것보다 근본적인 접근이죠.
전망을 정리하면 이렇습니다. CSS는 계속 강력해지겠지만, 그 강력함을 직접 다루는 개발자의 수는 오히려 줄어들 가능성이 높습니다. 시각적 편집 도구, 디자인 토큰 추상화, 유틸리티 프레임워크가 중간 레이어로 자리 잡고, Highlight API처럼 브라우저 네이티브 최적화 경로를 활용하는 저수준 기법은 라이브러리 제작자나 성능 엔지니어의 영역으로 분화될 겁니다. 프론트엔드 크래프트맨십의 정의 자체가 달라지고 있습니다 — 모든 CSS 속성을 외우는 것이 아니라, 토큰·예산·자동화라는 시스템 위에서 사용자 경험의 1px과 1ms를 지키는 것. 그것이 지금 시대의 장인 정신입니다.