스크롤 애니메이션, CSS냐 GSAP이냐
스크롤에 반응하는 모션은 더 이상 화려한 데모의 전유물이 아니다. 2025년 말부터 두 흐름이 동시에 무르익었다. 하나는 GSAP ScrollTrigger로 정교한 3D 좌표를 직접 계산하는 방식, 다른 하나는 브라우저가 스크롤 진행도를 곧장 애니메이션에 매핑하는 CSS 네이티브 방식이다. Codrops의 최신 튜토리얼은 Three.js 없이 삼각함수와 CSS transform만으로 텍스트를 3D 공간에 배치한다. 같은 문제를 정반대 철학으로 푸는 두 진영을 나란히 놓고 보면, 실무 선택의 기준이 선명해진다.
"ScrollTrigger는 스크롤 거리를 애니메이션의 진행값에 끊임없이 매핑한다."Codrops
무슨 일인가
Codrops의 David Faure는 GSAP의 ScrollTrigger와 ScrollSmoother를 등록해 스크롤 진행도를 애니메이션에 직접 묶는다. 각 텍스트 항목은 sine·cosine으로 3D 좌표를 계산받고, transform-style: preserve-3d와 gsap.set()으로 GPU 가속 변환을 받는다. 실린더는 180도, 원형은 360도 궤도, 튜브는 Z축 터널처럼 수학 패턴이 효과를 가른다. 핵심은 수동 스크롤 이벤트 핸들링을 버리고 onUpdate 콜백이 프레임마다 값을 동기화한다는 점이다.
여러 시각
같은 "스크롤 구동"이라는 단어를 세 출처가 다르게 해석한다.
- Codrops — JS 오케스트레이션 진영. 복잡한 3D 좌표와 ScrollSmoother 같은 세밀한 제어가 필요할 때 GSAP의 표현력이 압도적이라는 입장이다.
- Josh W. Comeau — CSS 네이티브 진영. "지속 시간 대신 스크롤 거리에 키프레임을 매핑하면 어떨까"라며, JS 없이 약 85% 브라우저에서 동작하는 패러다임 전환을 강조한다.
- CSS-Tricks — 실무 가이드 진영.
scroll()과view()타임라인의 차이, 메인 스레드를 막지 않는 "NO JANK" 하드웨어 가속을 핵심 이점으로 짚는다.
왜 중요한가
몇 년간 스크롤 모션은 곧 JS 라이브러리였고, 스크롤 이벤트 리스너가 메인 스레드를 점유해 끊김을 만들었다. 이제 CSS의 animation-timeline: scroll()·view()가 같은 일을 컴포지터 스레드에서 처리한다. Interop 2026 대상이라 Firefox 정식 지원이 붙으면 베이스라인이 된다. 즉 "라이브러리 없이도 되는 영역"이 빠르게 넓어지고, GSAP은 진짜 복잡한 표현에 집중하는 분업 구도가 굳어진다.
실무 적용
- 단순 패럴랙스·진행 바·뷰포트 진입 리빌은 CSS
view()/scroll()로 먼저 시도하고, GSAP은 3D 좌표·체이닝이 필요할 때만 쓴다. animation-timeline은 반드시animation단축 속성 뒤에 선언하고,@supports로 기능 감지 후 폴백을 둔다.- 두 방식 모두
prefers-reduced-motion으로 게이팅해 접근성을 지킨다.
Kenny의 관점
프론트엔드·AX 관점에서 이 분기는 "표현력 대 비용"의 문제다. CSS 네이티브는 의존성 0에 컴포지터 가속이라 대부분의 인터랙션에서 기본값이 되어야 한다. 다만 AI가 생성하는 인터페이스가 늘수록, 좌표를 정밀하게 제어하는 GSAP식 접근은 브랜드 경험의 차별화 지점으로 남는다. 나는 "CSS로 시작하고 GSAP으로 끝낸다"는 계층 전략을 권한다. 무엇보다 모션은 의미를 전달할 때만 가치가 있으므로, reduced-motion 분기를 설계 첫 단계에서 정의하는 습관이 둘 모두에 우선한다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Codrops ↗