페이지 전환, 어디까지 CSS로? — WebGPU와의 분업
세련된 페이지 전환은 이제 선택이 아니라 기대치가 됐다. 마침 두 흐름이 나란히 도착했다. 하나는 네이티브 CSS 뷰 트랜지션이 세 엔진에서 모두 지원되며 Baseline에 올라 '문법 몇 줄'로 전환을 얻게 된 것이고, 다른 하나는 Codrops가 WebGPU로 DOM 밖에서 이미지 평면을 유지하며 사이트 전체에 지속되는 전환을 구현한 심화 튜토리얼을 6월 30일 공개한 것이다. 표준이 성숙할수록 '어디까지 CSS로 하고, 어디부터 GPU로 갈까'라는 분업의 질문이 오히려 또렷해진다.
"전환 동안 모든 평면을 DOM 추적에서 떼어내면, 렌더 루프가 GSAP 트윈을 덮어쓰지 못해 바운드 애니메이션이 방해 없이 완주한다."Codrops (Ben Paine)
무슨 일인가
Codrops의 기법은 페이지마다 캔버스를 새로 그리지 않는다. 사이트 전체에 걸쳐 단 하나의 WebGPU 레이어를 두고, 이미지 평면들을 그 위에 지속시켜 DOM 상태가 바뀔 때 생기는 '팝(pop)' 현상을 없앤다. 각 평면은 getBoundingClientRect()로 측정한 DOM '슬롯'에 바인딩돼 매 프레임 위치를 갱신하다가, 전환이 시작되면 추적에서 분리된다. 전환은 세 가지 상태 — 유지(바운드를 모핑), 제거(불투명도 0으로 페이드), 추가(즉시 찍고 페이드인) — 로 처리되고, 가벼운 바닐라 JS 라우터가 내비게이션을 가로채 이전·다음 페이지의 out()·in()을 동시에 발사한다. CSS만으로는 닿기 어려운 수준의 시각적 제어를 GPU로 확보하는 접근이다.
여러 시각
같은 '페이지 전환'이라는 목표를 두 진영이 정반대 무게중심으로 푼다.
- web.dev(Bramus) — 동일 문서 뷰 트랜지션이 파이어폭스 144 출시와 함께 'Baseline Newly available'에 올랐다.
document.startViewTransition(),view-transition-name,:active-view-transition같은 API만으로 대부분의 전환을 선언형으로 얻는다 — 코드도, 유지보수 비용도 최소인 기본값이다. - Codrops(WebGPU) — 반대로 프레임워크 없이 GPU 씬을 직접 소유해 브랜드성 짙은 커스텀 전환을 만든다. 대신 라우터·바운드 추적·메모리 관리를 손수 져야 한다. 표현력과 복잡도를 맞바꾸는, 명백히 상급 옵션이다.
왜 중요한가
핵심은 '둘 중 하나'가 아니라 계층화다. 뷰 트랜지션이 Baseline에 오르면서 부드러운 전환의 '바닥'이 표준으로 깔렸고, 그 위에서 WebGPU는 히어로 페이지나 쇼케이스처럼 정말 필요한 곳에만 얹는 사치품이 된다. 표준이 성숙할수록 커스텀 엔진의 존재 이유는 '기본을 대체'가 아니라 '기본을 넘어서는 특정 순간'으로 좁혀진다. 무엇을 CSS에 위임하고 무엇을 직접 만들지 가르는 판단력이, 성능과 유지보수성을 동시에 지키는 열쇠다.
실무 적용
- 기본 내비게이션 전환은
@view-transition·view-transition-name으로 먼저 깔고, 프로그레시브 인핸스먼트로 미지원 환경을 감싼다. - WebGPU 커스텀 전환은 랜딩·캠페인 페이지 등 투자 대비 효과가 확실한 소수 지점에만 국한하고, 전환 성능 예산(프레임·메모리)을 명시적으로 잡는다.
- 전환을 QA할 때 느린 API·SSR로 인한 지연, 종횡비 왜곡, 저사양 GPU 폴백을 재현 시나리오에 반드시 포함한다.
Kenny의 관점
프런트엔드에서 '멋짐'의 비용은 늘 유지보수와 성능으로 청구된다. 나는 이 둘을 경쟁이 아니라 계층으로 본다 — 표준 뷰 트랜지션을 기본값으로 깔아 대부분을 저비용으로 해결하고, WebGPU는 브랜드 경험이 매출·기억에 직결되는 극소수 지점에만 쓰는 것이다. 화려한 데모에 홀려 사이트 전체를 커스텀 엔진에 태우는 순간, 애니메이션이 아니라 기술 부채가 지속된다. 좋은 AX 판단은 '무엇을 만들까'만큼이나 '무엇을 표준에 맡길까'를 아는 데서 나온다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Codrops ↗