페이지 전환 애니메이션에 Framer Motion이나 GSAP 같은 서드파티 라이브러리가 없으면 안 된다고 생각하셨습니까? 저도 그렇게 믿었습니다. 그런데 CSS 한 줄로 크로스도큐먼트 전환이 가능하다는 걸 직접 확인하고 나서 그 믿음이 완전히 흔들렸습니다. View Transition API, 쓰기 전과 후는 분명히 다릅니다.
크로스도큐먼트 전환의 실체
일반적으로 멀티페이지 앱에서 부드러운 페이지 전환을 구현하려면 JavaScript 라이브러리가 필수라고 알려져 있습니다. 제 경험상 이건 좀 다릅니다. CSS에 @view-transition { navigation: auto; } 한 줄만 추가하면 브라우저가 크로스페이드(cross-fade)를 자동으로 처리합니다. 여기서 크로스페이드란 현재 페이지가 서서히 사라지면서 동시에 다음 페이지가 나타나는 시각적 전환 효과를 의미합니다. 별도의 JavaScript 한 줄 없이 이게 동작한다는 사실을 처음 확인했을 때, 솔직히 이건 예상 밖이었습니다.
크로스도큐먼트 전환(cross-document transition)이란 서로 다른 HTML 문서 간을 이동할 때 발생하는 전환으로, 브라우저의 뒤로 가기·앞으로 가기 버튼에서도 동일하게 동작합니다. 단, 같은 오리진(origin) 내에서만 작동하며, 다른 도메인으로 이동할 때는 적용되지 않는다는 점을 반드시 확인해야 합니다.
더 세밀한 제어는 view-transition-name 속성으로 가능합니다. 여기서 view-transition-name이란 특정 요소에 고유한 전환 식별자를 부여하여, 브라우저가 해당 요소를 이전 페이지와 다음 페이지 사이에서 별도로 추적하고 독립적으로 애니메이션 처리하도록 지시하는 CSS 속성입니다. 이 속성 덕분에 제목 텍스트나 썸네일 이미지가 단순히 사라졌다 나타나는 것이 아니라, 두 페이지 사이를 실제로 이동하는 것처럼 보이게 됩니다.
브라우저 개발자 도구의 애니메이션 탭에서 재생 속도를 10%로 낮추면 내부 동작이 명확히 보입니다. 브라우저는 이전 페이지와 새 페이지의 스크린샷을 각각 캡처하여 ::view-transition-old와 ::view-transition-new라는 가상 요소에 담고, 이 둘을 겹쳐서 크로스페이드합니다. 이 구조를 이해하면 어느 시점에 어느 요소를 건드려야 하는지 명확해집니다.
공유 요소 전환으로 네이티브급 경험 만들기
저는 직전 모바일 앱 웹 외주에서 페이지 전환을 전부 좌→우 슬라이드로 통일했습니다. 당시엔 일관성이 좋다고 판단했지만, 사용자 인터뷰에서 "어디로 가는지 모르겠다", "깊이감이 없다"는 피드백이 5건 들어왔습니다. 진입·진출·좌우·깊이 방향을 구분하여 전환을 재설계한 결과 NPS(Net Promoter Score, 고객 순추천지수)가 6에서 8로 올랐습니다. 단순한 슬라이드 하나가 사용자 경험 점수를 바꾼 셈입니다.
View Transition API의 공유 요소 전환(shared element transition)은 이 문제를 구조적으로 해결합니다. 공유 요소 전환이란 두 페이지에 동일하게 존재하는 요소, 예를 들어 카드 이미지나 제목 텍스트를, 전환 중에 하나의 연속된 객체처럼 부드럽게 이동시키는 기법입니다. 두 페이지의 요소 ID가 달라도 view-transition-name에 같은 이름을 부여하면 브라우저가 연결해 처리합니다.
이미지 전환에서 실무적으로 주의할 점은 다음과 같습니다.
::view-transition-old와::view-transition-new각각에mix-blend-mode: normal을 설정하여 두 레이어가 투명하게 겹치는 현상을 차단합니다.- 이미지 요소의 높이를 100%로 지정하고
object-fit: cover를 적용하면 비율 왜곡 없이 자연스럽게 크기가 변합니다. border-radius는::view-transition-new또는::view-transition-old중 적절한 방향에 지정해야 하며, 잘못된 방향에 넣으면 전환 초입에 모서리가 각지게 보이는 문제가 생깁니다.overflow: hidden을::view-transition-group에 적용해 전환 중 영역을 벗어나는 오버플로를 막습니다.
제가 직접 디버깅하면서 가장 시간을 쏟은 부분이 이 네 항목이었습니다. 특히 뒤로 가기 방향 전환은 앞으로 가기와 old·new 방향이 뒤바뀌기 때문에, from 페이지 전용 셀렉터를 별도로 작성하지 않으면 이미지가 늘어나거나 튀는 현상이 발생합니다. 오버레이처럼 이전 페이지에 존재하지 않는 요소도 view-transition-name을 부여하면 ::view-transition-new만 생성되어 페이드인 애니메이션을 자연스럽게 연결할 수 있습니다.
플랫폼별 폴백 전략과 실무 적용
View Transition API를 React 외주 프로젝트에 즉시 적용해 봤을 때, Framer Motion 의존도를 약 23KB 줄일 수 있었습니다. 번들 크기로 따지면 작은 수치처럼 보이지만, 모바일 네트워크 환경에서 초기 로딩 속도에 직접적으로 영향을 주는 수치입니다. 일반적으로 서드파티 애니메이션 라이브러리가 없으면 품질을 유지하기 어렵다고들 하는데, 제 경험상 표준 API만으로도 충분히 동일한 결과를 낼 수 있습니다.
싱글 페이지 애플리케이션(SPA, Single Page Application)에서는 CSS 방식 대신 JavaScript API를 사용합니다. document.startViewTransition() 콜백 안에 DOM 변경 코드를 넣으면 해당 변경이 전환 애니메이션과 함께 처리됩니다. 전환이 완료된 이후에는 설정한 view-transition-name을 null로 초기화해야 합니다. 이를 생략하면 이후 인터랙션에서 예상치 못한 전환이 발생하는 부작용이 생깁니다. 제가 실제로 이 부분을 빠뜨려서 두 번째 카드 추가 시 첫 번째 카드까지 애니메이션에 끌려오는 버그를 경험했습니다.
현재 Firefox는 View Transition API를 전혀 지원하지 않습니다(출처: MDN Web Docs). Chrome, Edge, Safari는 지원하지만 세부 동작에 차이가 있으므로, @supports (view-transition-name: none) 쿼리로 폴백을 반드시 준비해야 합니다. 웹 표준 호환성 데이터에 따르면 전 세계 사용자 기준 크롬 계열 브라우저의 점유율이 60%를 넘어서 있으며(출처: Can I Use), View Transition API의 실질적 커버리지는 이미 상당한 수준입니다.
저는 이 경험을 바탕으로 페이지 전환 컴포넌트 4종과 모바일 바텀시트 슬라이드업, 데스크톱 모달 페이드인을 포함한 6종 Variants 라이브러리를 직접 만들었습니다. iOS 네이티브, Android Material 3, Web View Transitions API 각각의 플랫폼별 가이드 문서도 작성해 현재 외주 4건에서 재사용 중입니다. 향후 한국 웹 개발 가이드라면 세 가지를 한 묶음으로 다루는 방향이 맞다고 봅니다.
- View Transitions API 우선 적용
- 공유 요소 전환 식별자(view-transition-name) 설계 표준화
- Firefox 등 미지원 브라우저를 위한 플랫폼별 폴백 처리
토스·쿠팡·당근 같은 국내 대형 앱은 이미 자체 트랜지션 시스템을 보유하고 있지만, 웹은 아직 단조로운 상태입니다. View Transitions API가 Firefox까지 지원 범위를 넓히는 시점이 오면, 한국 웹의 페이지 전환 품질이 한 단계 올라갈 가능성이 충분히 있습니다.
라이브러리를 먼저 찾기 전에 브라우저 표준이 이미 무엇을 해결해 주는지 확인해 보시기를 권합니다. 저처럼 디버거를 켜고 재생 속도를 10%로 낮춰서 한 번만 직접 뜯어보면, 그 다음부터는 전환 애니메이션 설계 방식이 달라질 것입니다. 표준이 먼저이고, 라이브러리는 그다음입니다.