페이지 전환은 이제 브라우저의 일 — View Transitions API

퍼블리셔로 일할 때, “화면이 부드럽게 넘어가게 해주세요”는 늘 난감한 주문이었어요.

멀티 페이지 사이트는 링크를 누르면 화면이 하얗게 껌뻑이고 새로 그려졌으니까요.

그 껌뻑임을 없애려면 SPA로 만들거나, JS로 화면을 통째로 관리해야 했어요.

전환 하나 때문에 아키텍처를 바꾸는 셈이었죠.

이제 그걸 브라우저가 해줘요.

View Transitions API는 옛 화면과 새 화면의 스냅샷을 떠서, 그 사이를 알아서 애니메이션으로 이어줘요.

내가 “무엇이 어디로 가는지”만 이름 붙여주면, “어떻게 움직일지”는 브라우저 몫이에요.

float으로 레이아웃 짜던 시절에서 grid로 넘어올 때 느꼈던 그 이동 — 어떻게를 내가 관리하다 무엇을만 선언하면 되는 쪽으로 — 이 여기서도 똑같이 일어나요.

가장 단순한 형태는 두 줄이에요.

전환시킬 두 화면의 CSS에 이 규칙을 넣으면, 같은 사이트 안 페이지 이동이 통째로 크로스페이드돼요.

@view-transition {
  navigation: auto;
}

여기엔 조건이 붙어요.

나가는 문서와 들어오는 문서 양쪽 모두에 이 규칙이 있어야 하고, 같은 출처(same-origin)의 사용자가 누른 이동일 때만 작동해요.

외부 링크나 스크립트 리다이렉트, 폼 제출엔 안 걸리고요.

크로스페이드에서 한 발 더 나가면, 특정 요소가 “페이지를 건너 이어지게” 만들 수 있어요.

목록의 썸네일이 상세 페이지의 큰 이미지로 자라나는, 그런 연결이요.

두 페이지에서 같은 요소에 같은 이름만 붙여주면 돼요.

.thumb {
  view-transition-name: hero-image;
}

이름이 같으니 브라우저가 “이건 같은 것이 이동한 거네” 하고 위치·크기를 자연스럽게 보간해요.

예전 같으면 두 요소의 좌표를 재고 JS로 트윈을 짜야 했을 일을, 이름 하나로 끝내는 거예요.

지원 상황은 이래요.

같은 페이지 안(SPA형) 전환은 크롬 계열에서 2023년부터 되다가, 이제 모든 주요 브라우저에 들어와 2025년 10월 Baseline에 올랐어요.

페이지를 넘나드는(MPA형) 전환은 크롬 126·사파리 18.2에 들어왔지만, 파이어폭스가 아직이라 Baseline엔 못 든 ‘제한적’ 단계고요.

그래서 실무에선 “있으면 부드럽게, 없으면 그냥 즉시 전환”으로 두면 돼요 — 안 되는 브라우저는 껌뻑임 없이 원래대로 넘어갈 뿐이라 깨지지 않아요.

사실 이 블로그가 지금 그렇게 움직여요.

글과 글 사이를 눌러보면 하얗게 껌뻑이지 않고 스르륵 넘어가는데, 그게 View Transitions예요.

Astro의 <ClientRouter />가 이 API를 감싸서, 정적 사이트인데도 SPA처럼 전환을 입혀줘요.

플레인 CSS로 디자인 시스템을 만든 글에서 “가장 안 변하는 바닥에 결을 심는다”고 했는데, 전환도 프레임워크가 아니라 브라우저 API 위에 얹으니 마음이 편해요.

한 가지 주의는, 이름은 한 화면에 하나만 살아 있어야 한다는 거예요.

같은 view-transition-name을 가진 요소가 동시에 둘 보이면 브라우저가 어느 걸 이어야 할지 몰라 전환이 깨져요.

목록처럼 같은 종류가 여러 개인 곳에선, 실제로 이동하는 그 하나에만 이름을 붙였다 떼는 식으로 관리하게 되고요.

정리하고 싶진 않지만 하나만 남기면, 전환은 이제 “기능을 더 넣는 일”이 아니라 “브라우저에게 맡기는 일”이 됐어요.

움직임은 사용자를 놀래는 게 아니라 어디서 와서 어디로 갔는지 안심시키는 정도면 충분하고, 그 절제된 정도를 이제 CSS 두어 줄로 표현할 수 있게 된 거예요.