3D 뷰 전환은 왜 깨질까, perspective의 함정
페이지 전환에 입체감을 넣으려다 화면이 평평하게 뭉개지는 경험. CSS-Tricks가 2026년 6월 12일 공개한 글에서 Sunkanmi Fafowora는 그 원인을 정확히 짚는다. 뷰 트랜지션(View Transitions)으로 만든 의사 요소(pseudo) 트리는 일반 HTML 흐름 바깥, DOM 위 별도 레이어에 렌더된다. 그래서 조상 요소에 건 perspective는 끝내 닿지 않는다. 단순한 버그가 아니라 뷰 트랜지션의 렌더링 모델 자체에서 비롯된 함정이다.
"Since the view transition pseudo tree does not have a true parent, we've gotta use perspective()."CSS-Tricks
무슨 일인가
핵심은 perspective 속성과 perspective() 함수의 차이다. perspective 속성은 부모 요소에 걸어 자식들이 공유하는 3D 공간을 만든다. 하지만 뷰 트랜지션 의사 트리에는 진짜 부모가 없으니 이 속성이 무력하다. 해결책은 부모가 필요 없는 perspective() 변형 함수를 @keyframes 안에서 요소 자신에 직접 적용하는 것이다. 단, 사파리는 스냅샷을 찍을 때 3D 맥락을 통째로 평면화해 perspective()마저 듣지 않는다(WebKit 버그 #283568·#302166).
여러 시각
같은 "스크롤·전환 애니메이션" 영역은 도구를 혼동하기 쉽다. CSS-Tricks의 다른 글들이 그 지형도를 보완한다.
- CSS-Tricks(스크롤·전환 4분류) — 분류의 관점. 스크롤 구동(scroll-driven)은 스크롤 진행과 1:1로 묶이고, 스크롤 트리거(scroll-triggered)는 임계선을 넘으면 끝까지 한 번 재생되며, 스크롤 상태(scroll-state)는 sticky가 "붙은" 조건에서 스타일을 바꾸고, 뷰 트랜지션은 상태 A→B 전환을 맡는다. 넷을 구분해야 디버깅이 풀린다.
- CSS-Tricks(View Transitions 레시피) — 실전의 관점. 같은 API라도 추상 개념 대신 카드 확장·목록 전환 같은 시나리오별 레시피로 접근하면 감을 더 빨리 잡는다.
왜 중요한가
뷰 트랜지션은 2026년 들어 크로스 도큐먼트까지 확장되며 "JS 없이 매끄러운 페이지 전환"의 표준 후보가 됐다. 하지만 의사 트리라는 독특한 렌더링 모델 탓에, 익숙한 3D 트릭이 그대로 통하지 않는다. perspective 하나가 왜 안 먹는지 모르면 한나절을 날린다. 표준이 강력해질수록, 그 내부 모델을 이해한 개발자와 "왜 안 되지"만 반복하는 개발자의 생산성 격차가 벌어진다.
실무 적용
- 뷰 트랜지션에 3D를 줄 때는 조상에
perspective속성을 걸지 말고,@keyframes안에서perspective()함수를 요소에 직접 적용한다. - 사파리는 스냅샷 단계에서 3D를 평면화하므로, 입체 전환은 점진적 향상(progressive enhancement)으로 설계하고 평면 fallback이 항상 자연스럽게 보이게 한다.
- 스크롤 효과를 넣기 전, 원하는 동작이 스크롤 구동·트리거·상태·뷰 트랜지션 중 무엇인지 먼저 분류해 잘못된 API로 디버깅하는 시간을 없앤다.
Kenny의 관점
프론트엔드 관점에서 이 사례의 교훈은 "추상화의 경계를 의심하라"다. 뷰 트랜지션은 마치 일반 DOM처럼 보이지만 별도 레이어에서 돌아가고, 그 작은 차이가 perspective를 무력화한다. 나는 새 CSS API를 쓸 때 "이게 어디서, 어떤 트리 위에서 렌더되는가"를 먼저 확인한다. 화려한 3D 전환보다, 꺼졌을 때도 멀쩡한 평면 전환을 기본으로 두는 편이 사용자에게도 팀에게도 안전하다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — CSS-Tricks ↗