뷰 전환 API(View Transitions) — 새로고침 없는 화면 전환, 왜 지금 표준이 됐나

주소창을 새로고침하지 않고도 페이지가 부드럽게 넘어가는 화면 전환. 예전엔 무거운 자바스크립트 프레임워크를 통째로 얹어야 겨우 흉내 냈던 이 효과가, 이제는 브라우저가 기본으로 제공하는 뷰 전환 API(View Transitions API)로 몇 줄 안에 구현된다. 요즘 프런트엔드 화두를 하나 꼽으라면 나는 망설임 없이 이걸 꺼낸다.

핵심만 먼저 말하면, 뷰 전환 API는 화면이 A 상태에서 B 상태로 바뀔 때 그 사이를 브라우저가 애니메이션으로 이어 주는 웹 표준이다. 같은 페이지 안에서의 DOM 변화든, 서로 다른 문서 사이의 이동이든 똑같은 방식으로 다룰 수 있다는 점이 진짜 변화다.

무엇이 달라지나

기존 방식은 대략 이랬다. 화면을 부드럽게 바꾸고 싶으면 옛 화면과 새 화면을 동시에 DOM에 얹어 두고, 위치와 투명도를 직접 계산해 트윈시키고, 애니메이션이 끝나면 옛 화면을 지운다. 이 과정을 손으로 관리하는 순간 상태가 꼬이기 시작한다. 중간에 사용자가 뒤로 가기를 누르면? 애니메이션이 겹치면? 그래서 결국 라우터와 전환을 통합한 무거운 프레임워크에 기대게 됐다.

뷰 전환 API는 이 흐름을 뒤집는다. 개발자는 그냥 "지금부터 DOM을 바꾸겠다"고 브라우저에 선언한다. 그러면 브라우저가 바꾸기 직전의 화면을 스냅샷으로 찍어 두고, DOM 갱신이 끝난 뒤의 화면과 그 스냅샷 사이를 알아서 이어 준다. 개발자가 손댈 부분은 "어떻게 이어질지"를 CSS로 기술하는 것뿐이다.

단일 문서 전환

같은 페이지 안에서 목록을 상세로 펼치거나, 탭을 바꾸거나, 카드를 확대할 때 쓴다. 상태 변경 코드를 전환을 시작하는 함수 안에 감싸 넣기만 하면, 그 안에서 일어난 DOM 변화가 통째로 애니메이션 대상이 된다.

document.startViewTransition(() => {
  updateTheDOM(); // 이 안의 변경이 전환 대상
});

문서 간 전환

더 인상적인 건 서로 다른 HTML 문서 사이의 전환이다. 자바스크립트로 라우팅을 가로채지 않고, 평범한 링크를 눌러 실제로 페이지가 넘어가는데도 전환이 매끄럽다. 두 문서가 같은 출처이고 짧은 메타 설정만 공유하면, 목록 페이지의 썸네일이 상세 페이지의 헤더 이미지로 자연스럽게 커지는 연출까지 순수 서버 렌더링 위에서 가능해진다. 나는 이 지점이 가장 크다고 본다. 그동안 "앱 같은 부드러움"은 SPA의 전유물처럼 여겨졌는데, 그 전제가 무너지기 때문이다.

왜 지금 중요한가

세 가지 흐름이 겹쳤다. 첫째, 서버 렌더링과 스트리밍이 다시 주류가 되면서 "굳이 클라이언트에서 다 그리지 않아도 된다"는 공감대가 생겼다. 그런데 서버 렌더링의 약점이 바로 화면 전환의 뻣뻣함이었고, 그 마지막 퍼즐을 이 API가 메운다.

둘째, 성능 예산에 대한 감각이 예민해졌다. 전환 애니메이션 하나 붙이자고 수백 킬로바이트짜리 라이브러리를 얹는 건 이제 정당화하기 어렵다. 브라우저 내장 기능은 그 비용이 사실상 0이다.

셋째, 접근성과 성능이 기본으로 챙겨진다. 사용자가 시스템에서 "동작 줄이기"를 켜 두면 미디어 쿼리로 애니메이션을 손쉽게 끌 수 있고, 스냅샷 합성은 브라우저의 최적화된 경로를 탄다.

현실적인 한계

물론 만능은 아니다. 브라우저별 지원 시점이 다르므로, 지원하지 않는 환경에서는 애니메이션 없이 그냥 바뀌도록 설계하는 게 정석이다. 다행히 이 API는 그 폴백이 자연스럽게 이뤄지도록 설계돼 있어서, "있으면 좋고 없으면 즉시 전환"이라는 점진적 향상 철학과 잘 맞는다.

또 하나, 전환은 어디까지나 연출이다. 전환이 화려하다고 데이터 로딩이 빨라지지는 않는다. 오히려 과한 애니메이션은 체감 속도를 떨어뜨린다. 나는 전환 길이를 짧게 잡고, 위치 이동보다 투명도·크기 변화 위주로 절제하는 편을 권한다.

정리하자면, 이 기술은 새로운 마법이라기보다 그동안 프레임워크가 떠맡던 책임 하나를 플랫폼으로 되돌리는 조정에 가깝다. 그리고 그런 조정이야말로 웹이 오래 살아남는 방식이었다.

자주 묻는 질문

뷰 전환 API를 쓰려면 프레임워크를 버려야 하나요?

아니다. 프레임워크와 무관한 브라우저 표준이므로, 리액트든 뷰든 순수 HTML이든 그 위에서 그대로 쓸 수 있다. 오히려 많은 프레임워크가 이 API를 내부적으로 감싸 더 편한 인터페이스를 제공하는 방향으로 움직이고 있다.

SPA에서만 쓸 수 있나요?

아니다. 단일 문서 전환은 SPA에서, 문서 간 전환은 여러 페이지로 나뉜 전통적인 서버 렌더링 사이트에서 특히 빛난다. 서버 렌더링 사이트에 앱 같은 부드러움을 붙이는 용도가 오히려 매력적이다.

지원하지 않는 브라우저에서는 어떻게 되나요?

전환 애니메이션만 생략되고 화면은 정상적으로 바뀐다. 기능이 없다고 페이지가 깨지지 않도록 설계돼 있어, 별도의 복잡한 분기 없이 점진적 향상 방식으로 도입할 수 있다.

접근성은 어떻게 챙기나요?

사용자가 운영체제 수준에서 동작 최소화를 선택한 경우를 감지하는 미디어 쿼리로 전환을 끄거나 약하게 만들 수 있다. 전정 감각에 민감한 사용자를 위해 이 처리는 선택이 아니라 기본으로 넣는 걸 권한다.