스크롤 트리거 vs 드리븐, JS 없는 스크롤 애니메이션
스크롤에 반응하는 리빌 애니메이션은 오랫동안 인터섹션 옵서버 같은 JS 훅의 몫이었다. 그런데 CSS-Tricks가 6월 19일 소개한 '스크롤 트리거 애니메이션'이 이 패턴을 CSS 안으로 끌어들인다. Chrome 146에 처음 실린 이 기능은 요소가 특정 스크롤 임계점에 닿으면 애니메이션을 고정된 시간 동안 재생한다. 이미 자리 잡은 '스크롤 드리븐 애니메이션'과 이름이 헷갈리기 쉽지만, 둘은 전혀 다른 도구다 — 지금 그 경계를 정리해 둘 때다.
"스크롤 트리거 애니메이션은 특정 스크롤 임계점을 넘어서면 고정된 시간 동안 재생된다."CSS-Tricks
무슨 일인가
핵심은 두 방식의 시간축이 다르다는 점이다. 스크롤 드리븐(animation-timeline: scroll()·view())은 애니메이션 진행률을 스크롤 위치에 1:1로 묶어 '스크롤을 되감으면 애니메이션도 되감기는' 방식이라 고정 재생 시간이 없다. 반면 스크롤 트리거는 임계점 통과를 '신호'로만 삼아, 한 번 발동되면 정해진 duration 동안 독립적으로 완주한다. 새로 제안된 timeline-trigger가 발동 조건(예: view() entry 100% exit 0%)을 정의하고, animation-trigger가 play-forwards·play-once·reset·replay 같은 동작을 지정한다. 흔한 '스크롤하면 한 번 나타나는' 리빌 패턴을 JS 없이 선언형으로 얻는 것이다.
여러 시각
같은 '스크롤 애니메이션'이라도 목적에 따라 골라 써야 한다.
- CSS-Tricks: 스크롤 드리븐(반대 방향 데모) — 진행률 연동 방식은 두 열의 아이템이 스크롤에 따라 서로 반대로 흐르는 효과를, 가상요소 마스킹과
view()만으로 JS 없이 구현한다. 진행률에 정밀히 묶어야 하는 시각효과엔 이쪽이 정답이다. - 브라우저 현실 — 같은 저자도 "스크롤 드리븐은 크롬·사파리 밖에선 아직 지원이 제한적"이라 인정한다. 트리거 방식 역시 Chrome 146 단독이라, 지금은 표현력과 호환성을 맞바꾸는 초기 단계다.
왜 중요한가
이 구분을 흐리면 잘못된 도구로 문제를 풀게 된다. '한 번 나타나고 끝'인 리빌에 스크롤 드리븐을 쓰면 사용자가 위로 스크롤할 때마다 애니메이션이 되감겨 어색해지고, 반대로 패럴럭스처럼 스크롤에 딱 붙어야 할 효과에 트리거를 쓰면 뚝뚝 끊긴다. 네이티브 CSS로 내려오면 JS 번들과 인터섹션 옵서버 콜백이 줄어 성능·접근성 모두 이득이지만, 지원 범위가 좁은 지금은 폴백 설계가 전제 조건이다. '무엇이 표준으로 오고 있는가'를 미리 읽어 두는 것이 마이그레이션 비용을 가른다.
실무 적용
- '한 번 재생'이면 스크롤 트리거, '진행률 연동'이면 스크롤 드리븐 — 효과의 시간축부터 정하고 API를 고른다.
- Chrome 146 단독 지원을 전제로,
@supports와 프로그레시브 인핸스먼트로 미지원 환경엔 즉시 표시되는 폴백을 깐다. - QA 시 위·아래 반복 스크롤, 빠른 플링,
prefers-reduced-motion환경을 재현 시나리오에 넣어 되감김·끊김·과도한 모션을 잡는다.
Kenny의 관점
프런트엔드에서 새 CSS 기능의 진짜 가치는 '화려함'이 아니라 '제거되는 JS'에 있다. 스크롤 리빌 하나 때문에 인터섹션 옵서버와 상태 관리 코드를 얹던 관행이 몇 줄의 선언형 CSS로 대체되면, 번들도 유지보수 부담도 함께 가벼워진다. 다만 나는 Chrome 단독 지원 단계의 기능을 프로덕션 기본값으로 삼지 않는다 — 대신 폴백을 먼저 깔고 인핸스먼트로 얹는다. 좋은 AX는 최신 문법을 빨리 쓰는 게 아니라, 지원이 무르익는 곡선 위에서 위험을 관리하며 올라타는 판단에서 나온다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — CSS-Tricks ↗