스크롤이 내려가면 숫자가 카운트업되고, 뷰포트에 진입한 카드는 부드럽게 떠오릅니다. 마우스 휠의 위치에 따라 진행 바가 차오르고, 문단마다 글자가 한 줄씩 밝아집니다. 이런 인터랙션을 구현하려면 지난 10년간 GSAP, ScrollMagic, AOS, Framer Motion 같은 자바스크립트 라이브러리가 필요했습니다. 무거운 스크립트와 스크롤 이벤트 리스너, 그리고 requestAnimationFrame 최적화까지 신경 써야 했죠.
그 풍경이 2026년에 완전히 달라졌습니다. Chrome, Edge, Safari, Firefox 모두에서 Scroll-driven Animations가 네이티브로 동작하면서, 스크롤을 타임라인처럼 다루는 일이 CSS 속성 한두 줄로 끝나게 됐습니다.
스크롤 애니메이션, 왜 다시 주목받는가
랜딩 페이지와 브랜드 사이트에서 스크롤 연동 애니메이션은 선택이 아닌 기본기가 됐습니다. 방문자는 첫 화면을 본 뒤 스크롤을 내리며 브랜드의 이야기를 따라가고, 그 흐름에 맞춰 움직이는 시각 요소는 체류 시간과 브랜드 인지도에 직접적인 영향을 줍니다.
하지만 이 효과를 위해 기존에는 30KB가 넘는 라이브러리를 불러와야 했습니다. 작은 마케팅 페이지에도 GSAP와 ScrollTrigger 플러그인이 들어가면서 번들 사이즈가 뛰고, 모바일 성능과 Core Web Vitals 점수가 함께 무너지는 일이 흔했습니다.
두 개의 타임라인이 전부다
Scroll-driven Animations의 문법은 단순합니다. CSS 애니메이션의 기준이 되는 타임라인을 시간이 아니라 스크롤로 바꾸는 것이 전부입니다. 핵심은 두 가지 타임라인뿐입니다.
scroll() — 스크롤 컨테이너 전체의 진행도
페이지 전체 또는 특정 스크롤 컨테이너의 스크롤 위치를 0에서 100까지의 진행도로 매핑합니다. 페이지 상단의 진행 바, 기다란 페이지의 고정 요소가 위치에 따라 바뀌는 효과, 긴 아티클에서 읽은 비율을 시각적으로 보여주는 인디케이터 같은 것에 바로 쓸 수 있습니다.
구현은 animation-timeline: scroll() 한 줄로 끝납니다. @keyframes로 시작과 끝 상태만 정의하면, 브라우저가 스크롤 위치에 따라 알아서 보간해 줍니다.
view() — 특정 요소가 뷰포트에 머무는 구간
더 자주 쓰게 될 쪽은 이쪽입니다. 요소가 뷰포트에 처음 진입한 순간부터 완전히 빠져나갈 때까지의 구간을 타임라인으로 삼습니다. 카드가 화면에 들어올 때 페이드인되고, 지나가면서 살짝 기울어지며, 빠져나갈 때 부드럽게 사라지는 식의 고전적인 스크롤 스토리텔링이 바로 이 한 속성으로 가능해집니다.
게다가 view-timeline-range를 이용하면 뷰포트의 어느 지점에서 애니메이션을 시작하고 끝낼지를 세밀하게 제어할 수 있어서, 기존 라이브러리에서 Trigger 지점을 수동으로 계산하던 번거로움이 사라집니다.
라이브러리와 비교하면 무엇이 달라지는가
가장 큰 차이는 성능입니다. 기존 자바스크립트 기반 스크롤 애니메이션은 메인 스레드에서 계산되기 때문에, 스크롤 이벤트가 초당 수십 번씩 발생할 때마다 DOM과 스타일을 다시 계산해야 했습니다. 반면 Scroll-driven Animations는 브라우저의 컴포지터 스레드에서 처리되기 때문에, 메인 스레드가 바빠도 애니메이션이 끊기지 않습니다.
두 번째는 번들 사이즈입니다. 페이지 애니메이션 한두 가지 때문에 30KB짜리 라이브러리를 불러오던 관행이 사라집니다. 이는 First Contentful Paint를 수백 밀리초 당기는 효과로 이어지고, 그만큼 이탈률이 내려갑니다.
세 번째는 유지보수입니다. 라이브러리 버전 업그레이드, API 변경, 프레임워크와의 호환성 문제에서 해방됩니다. CSS 표준이기 때문에 웹 자체가 사라지지 않는 한 계속 동작합니다.
그럼 기존 라이브러리는 언제 쓸까
Scroll-driven Animations가 모든 것을 대체하지는 않습니다. 스크롤 방향에 따라 분기 처리를 하거나, 여러 요소의 애니메이션을 복잡하게 동기화해야 하거나, 특정 스크롤 위치에서 사운드를 재생하는 등의 고급 시나리오는 여전히 GSAP 계열이 유리합니다.
기준은 단순합니다. 시각 효과 하나를 스크롤에 연동하는 수준이라면 CSS로, 스크롤을 중심으로 복잡한 상태 머신을 짜야 한다면 라이브러리로 가는 것이 현재의 최선입니다. 실제로 저희가 최근 작업한 브랜드 원페이지 사이트의 80% 이상은 CSS만으로 스크롤 연출이 충분히 나옵니다.
놓치기 쉬운 접근성과 성능 주의점
스크롤 애니메이션이 가벼워진 만큼, 과도하게 쓸 위험도 커졌습니다. 반드시 prefers-reduced-motion 미디어 쿼리로 모션을 줄이는 옵션을 제공해야 합니다. 전정 기관이 민감한 방문자에게 과도한 스크롤 애니메이션은 실제로 멀미와 두통을 유발합니다.
또한 요소가 뷰포트에 들어와야만 보이도록 초기 상태를 투명도 0으로 설정하는 경우, 자바스크립트가 꺼진 환경이나 이전 브라우저에서는 콘텐츠 자체가 보이지 않을 수 있습니다. @supports 규칙으로 지원 여부를 감지하고, 지원하지 않을 때는 기본 상태에서 콘텐츠가 그대로 보이도록 폴백을 구성하는 것이 원칙입니다.
우리는 이 변화를 어떻게 반영하고 있는가
CYAN 에이전시의 2026년 제작 스펙에서는 포트폴리오 사이트, 브랜드 원페이지, 서비스 소개 페이지의 기본 스크롤 연출을 모두 CSS Scroll-driven Animations 기반으로 전환했습니다. 그 결과 모바일에서 체감 로딩 속도가 눈에 띄게 개선됐고, Core Web Vitals의 INP 지표가 꾸준히 좋은 점수를 유지하고 있습니다.
무엇보다 가벼운 사이트가 더 감각적으로 움직이는 역설적인 경험을 고객에게 전달할 수 있게 됐습니다. 웹 트렌드는 늘 화려함과 가벼움 사이의 줄다리기였고, 이번 라운드는 가벼움의 승리로 기울고 있습니다.
새 프로젝트를 준비 중이거나 기존 사이트의 스크롤 연출이 무겁게 느껴진다면, 지금이 구조를 바꿔볼 적기입니다. 작은 디테일 하나가 방문자의 머무는 시간을 결정하고, 그 시간이 곧 문의로 이어집니다.