greensock/GSAP 딥다이브
— "모든 것을 움직이는" 단일 틱 엔진, 이제 100% 무료

1한 줄 정체

GSAP를 한 문장으로 요약하면 "고성능 프로퍼티 조작기(property manipulator)"다. gsap.to(target, {x: 100, duration: 1}) 처럼 "이 대상의 이 속성을 이 값까지, 이 시간 동안 바꿔라"라고 말하면, 매 프레임 그 값을 계산해 대상에 적용해준다. 대상이 DOM 엘리먼트든, SVG든, Canvas 컨텍스트든, {x:0} 같은 순수 JS 객체든 상관하지 않는다.

핵심 저장소인 greensock/GSAP에는 코어 엔진(gsap-core.js)과, 그 위에 얹어 쓰는 20여 개의 플러그인(스크롤 연동 ScrollTrigger, 텍스트 쪼개기 SplitText, 드래그 Draggable, SVG 모핑 MorphSVGPlugin, 레이아웃 전환 Flip 등)이 함께 들어 있다. 예전에는 이 중 다수가 Club GSAP라는 유료 멤버십 전용이었지만, 2025년 Webflow 인수 이후 전부 무료로 전환됐다.

2왜 지금 뜨는가

GSAP는 신생 라이브러리가 아니다. 오히려 2008년부터 17년 넘게 웹 애니메이션 표준처럼 쓰여 온 "구관"이다. 그런데도 2026년 지금 다시 화제가 되는 이유는 셋으로 요약된다.

① Webflow 인수 → "유료 플러그인 전부 무료" 선언

README에는 이렇게 적혀 있다: "Thanks to Webflow, GSAP is now 100% FREE including ALL of the bonus plugins like SplitText, MorphSVG, and all the others that were exclusively available to Club GSAP members." 예전에는 SplitText·MorphSVGPlugin·InertiaPlugin·ScrollSmoother 같은 강력한 도구를 쓰려면 연 구독료를 내는 Club GSAP 멤버십이 필요했다. 이 장벽이 통째로 사라졌다는 것이 이번 화제의 진앙이다.

② "스크롤이 곧 스토리텔링"이 되는 웹 디자인 트렌드

최근 랜딩페이지·포트폴리오·에이전시 사이트들은 스크롤에 맞춰 요소가 나타나고, 고정(pin)되고, 모양이 바뀌는 연출을 즐겨 쓴다. 이런 연출의 사실상 표준 도구가 바로 무료로 풀린 ScrollTrigger다. 유료 장벽이 없어지자 튜토리얼·템플릿·쇼케이스가 폭발적으로 늘었다.

③ React 생태계와의 자연스러운 결합

공식 보조 패키지 @gsap/react가 제공하는 useGSAP() 훅은 useEffect를 대체하며 정리(cleanup)를 자동화한다. "React는 선언적, GSAP는 명령적"이라는 이질감이 이 훅과 gsap.context() 덕분에 크게 줄어, React/Next.js 프로젝트에서도 부담 없이 쓰이게 됐다.

3무엇을 해결하나

순수 CSS transition/@keyframes나 Web Animations API만으로도 애니메이션은 가능하다. 그런데도 GSAP가 필요한 이유는 CSS·JS 애니메이션이 실제 제품에서 부딪히는 세 가지 벽 때문이다.

① 크로스브라우저 변환(transform) 불일치

transform: translateX()와 rotate()를 동시에 쓰거나, SVG 요소에 CSS 변환을 걸 때 브라우저마다 미묘하게 다르게 동작하던 시절이 있었다. GSAP의 CSSPlugin은 이런 불일치를 흡수해 "당신의 애니메이션은 그냥 동작한다(just works)"는 약속을 지킨다.

② 복잡한 시퀀싱을 코드로 표현하기 어려움

"A가 끝나고 0.2초 뒤 B와 C가 동시에 시작하고, 그 중간 지점에 D가 끼어든다" 같은 시나리오를 setTimeout이나 CSS 애니메이션 지연 값 계산으로 짜면 순식간에 스파게티가 된다. GSAP의 타임라인(Timeline)은 이런 시퀀스를 "타임코드"라는 직관적인 위치 파라미터("-=0.2", "<" 등)로 선언적으로 표현하게 해준다.

③ 대량 애니메이션의 성능

한 페이지에 수백 개의 트윈이 동시에 돌아가면, 트윈마다 개별 requestAnimationFrame 콜백을 등록하는 순진한 구현은 금방 버벅인다. GSAP는 페이지 전체의 모든 애니메이션을 단 하나의 rAF 루프로 묶어 처리한다(5번 섹션에서 자세히). README는 "jQuery보다 최대 20배 빠르다"고 주장하는데, 근거가 바로 이 단일 틱 구조와 프로퍼티별 최적화된 렌더러다.

4전체 구조

src/ 폴더를 열어보면 구조가 명확하다. 코어(gsap-core.js, 약 3,255줄) 하나가 엔진·타임라인·트윈·플러그인 등록 시스템을 전부 담당하고, 나머지는 전부 독립된 플러그인 파일이다. 코어만 있어도 순수 JS 객체 애니메이션은 되지만, DOM을 움직이려면 CSSPlugin부터 필요하다.

구조가 주는 메시지는 명확하다. "코어는 아무것도 모른다". 코어는 CSS도, 스크롤도, SVG도 모른다. 오직 "속성을 시간에 따라 보간하고, 그 결과를 렌더러에게 넘긴다"는 일반적인 메커니즘만 안다. DOM을 움직이는 지식(transform 파싱, 단위 처리 등)은 전부 CSSPlugin에, 스크롤 위치 감지는 ScrollTrigger에 위임돼 있다. 이 관심사 분리 덕분에 필요한 기능만 골라 번들 크기를 최소화할 수 있다.

5핵심 설계·동작 원리

이 섹션이 이 문서에서 가장 중요하다. GSAP가 왜 빠르고, 왜 "타임라인"이라는 개념이 강력한지는 전부 gsap-core.js 소스 안에 있다.

① 단일 틱 엔진 — 페이지 전체에 rAF 콜백은 단 하나

gsap-core.js 안의 _ticker는 즉시실행함수로 만들어진 독립 객체다. 실제 코드를 보면:

_ticker = (function() {
  let _getTime = Date.now,
    _gap = 1000 / 240,           // 내부 정밀도 240fps 기준
    _tick = v => {
      let elapsed = _getTime() - _lastUpdate, ...
      if (overlap > 0 || manual) {
        frame = ++_self.frame;
        _self.time = time = time / 1000;
        dispatch = 1;
      }
      manual || (_id = _req(_tick));      // 다음 rAF 예약
      if (dispatch) {
        for (_i = 0; _i < _listeners.length; _i++) {
          _listeners[_i](time, _delta, frame, v);  // 리스너 전원 호출
        }
      }
    };
  ...
})();

// 코어 파일 맨 끝부분:
_ticker.add(Timeline.updateRoot);   // 전체 애니메이션 트리의 유일한 진입점

즉 브라우저의 requestAnimationFrame은 딱 하나만 걸려 있고, 그 콜백이 _listeners 배열을 순회한다. 그런데 이 배열에 등록된 리스너는 사실상 Timeline.updateRoot 단 하나뿐이다 — 이것이 루트 타임라인(_globalTimeline)을 갱신하고, 루트가 자신의 모든 자식(하위 타임라인·트윈)을 재귀적으로 갱신한다. 페이지에 트윈이 1개든 1만 개든 브라우저 입장에서는 rAF 콜백이 딱 하나인 셈이다.

② Animation → Tween / Timeline 계층 구조

gsap-core.js에는 class Animation(공통 기반), 그 아래 class Tween extends Animation과 class Timeline extends Animation이 정의돼 있다. Timeline은 자식으로 Tween이나 다른 Timeline을 가질 수 있는 합성(Composite) 구조다. 실제로 페이지의 전체 애니메이션은 _globalTimeline = new Timeline({id:"root", ...})라는 단 하나의 루트를 정점으로 한 트리(연결 리스트, _first/_next로 순회)를 이룬다. gsap.timeline()으로 만든 타임라인도 결국 이 루트의 자식으로 편입된다.

③ PropTween — 속성 하나하나가 연결 리스트 노드가 된다

트윈이 실제로 값을 바꾸는 최소 단위는 class PropTween이다. 대상(target)·속성명(p)·렌더 함수(r)·시작값(s)·변화량(c)·setter를 들고 있는 가벼운 객체이며, 트윈 하나가 여러 속성(x, y, opacity...)을 가지면 그만큼의 PropTween이 연결 리스트(_pt → _next)로 이어진다. 매 틱마다 이 리스트를 한 번 순회하며 각 노드의 렌더 함수를 호출하는 것만으로 모든 속성이 갱신된다 — 배열 생성이나 객체 순회 오버헤드를 최소화한 설계다.

④ 플러그인 시스템 — 등록(register) 기반의 확장

코어에는 let _plugins = {}라는 빈 레지스트리가 있다. gsap.registerPlugin(ScrollTrigger, Flip, ...)을 호출하면 내부 _createPlugin()이 각 플러그인 설정을 받아 init/render/kill 생명주기를 가진 Plugin 클래스를 만들고 _plugins에 등록한다. 이후 gsap.to(el, {scrollTrigger: {...}})처럼 등록된 이름의 속성을 쓰면 해당 플러그인의 렌더 로직이 PropTween 파이프라인에 끼워 넣어진다.

재미있는 점은 각 플러그인 파일이 스스로 등록을 시도한다는 것이다. 예를 들어 ScrollTrigger.js 맨 끝 줄은 이렇다:

// ScrollTrigger.js 맨 끝
_getGSAP() && gsap.registerPlugin(ScrollTrigger);

// _getGSAP()의 정의:
_getGSAP = () => gsap || (_windowExists() && (gsap = window.gsap) && gsap.registerPlugin && gsap)

즉 <script> 태그로 전역 window.gsap가 이미 있는 환경(브라우저 전역 빌드)에서는 import만 해도 자동으로 등록된다. 하지만 번들러(webpack/Vite) + ESM 환경에서는 전역 window.gsap가 없을 수 있어 자동 등록이 실패하고, 개발자가 직접 gsap.registerPlugin(ScrollTrigger)를 호출해야 한다(9번 섹션의 대표적 함정).

⑤ gsap.context() / matchMedia — 프레임워크 친화적 정리(cleanup)

class Context는 특정 함수 스코프 안에서 생성된 모든 애니메이션(과 셀렉터)을 this.data 배열에 수집한다. context.revert()를 호출하면 수집된 모든 트윈·타임라인을 역순으로 되돌리고 제거한다 — React의 useEffect cleanup이나 컴포넌트 unmount에서 "이 컴포넌트가 만든 애니메이션만 깔끔히 지우기"에 정확히 맞는 도구다. class MatchMedia는 이 Context를 브레이크포인트별로 감싸, 네이티브 window.matchMedia()의 change 이벤트에 맞춰 조건에 맞는 애니메이션만 자동으로 되돌리고 다시 만든다.

⑥ 렌더 파이프라인과 자동 절전(autoSleep)

틱마다 루트 타임라인은 render(totalTime)을 호출해 현재 로컬 시간을 계산하고, 각 자식의 PropTween 리스트를 순회해 값을 적용한다. 흥미로운 디테일은 자동 절전(autoSleep)이다. 코드 상에는 이렇게 돼 있다:

if (_ticker.frame >= _nextGCFrame) {
  _nextGCFrame += _config.autoSleep || 120;
  ...
  child || _ticker.sleep();   // 돌아가는 애니메이션이 없으면 rAF 루프 자체를 정지
}

애니메이션이 하나도 없는 순간에는 _ticker.sleep()으로 rAF 요청 자체를 멈춰 배터리·CPU를 아낀다. 새 트윈이 만들어지면 _wake()가 다시 깨운다.

⑦ CustomEase — SVG 패스를 이징 함수로 압축

CustomEase.js는 SVG cubic-bezier 패스 문자열을 파싱해 내부 좌표 배열로 정규화(_normalize)한 뒤, gsap.registerEase()로 이름 붙은 커스텀 이징 함수를 등록한다. 디자이너가 그래픽 에디터에서 그린 곡선을 그대로 이징으로 쓸 수 있게 해주는 다리 역할이다.

6기술 스택·의존성

7설치·요구사항

GSAP는 서버가 아니라 브라우저(또는 브라우저와 유사한 렌더링 컨텍스트)에서 도는 클라이언트 라이브러리다. "설치"는 사실상 스크립트 참조 또는 npm 패키지 추가가 전부다.

방법 1 — CDN (가장 빠른 시작)

<script src="https://cdn.jsdelivr.net/npm/gsap@3.15/dist/gsap.min.js"></script>
<script>
  gsap.to(".box", { x: 300, duration: 1 });
</script>

전역 빌드이므로 플러그인 스크립트도 순서대로 추가하면 _getGSAP()가 window.gsap을 찾아 자동 등록해준다.

방법 2 — npm (번들러 환경)

npm install gsap

import gsap from "gsap";
import ScrollTrigger from "gsap/ScrollTrigger";
import Flip from "gsap/Flip";

gsap.registerPlugin(ScrollTrigger, Flip);  // 번들러 환경에선 자동등록이 안 되므로 명시 필수

8실제 사용 흐름

기본적인 사용 흐름을 단계별로 살펴본다.

1단계 — 단순 트윈과 타임라인

import gsap from "gsap";

// 단발성 트윈: .box를 1초간 x=300으로
gsap.to(".box", { x: 300, duration: 1, ease: "power2.out" });

// 타임라인: 순서·겹침을 타임코드로 지정
const tl = gsap.timeline();
tl.to(".title", { opacity: 1, y: 0, duration: 0.6 })
  .to(".subtitle", { opacity: 1, duration: 0.4 }, "-=0.2")  // 앞 트윈 끝나기 0.2초 전 시작
  .to(".cta", { scale: 1 }, "<");                            // 바로 앞 트윈과 동시 시작

2단계 — ScrollTrigger로 스크롤 연동

import ScrollTrigger from "gsap/ScrollTrigger";
gsap.registerPlugin(ScrollTrigger);

gsap.to(".panel", {
  x: -500,
  scrollTrigger: {
    trigger: ".panel",
    start: "top top",
    end: "+=1000",
    scrub: true,   // 스크롤 위치에 애니메이션 진행률을 직접 연결
    pin: true      // 구간 동안 요소를 화면에 고정
  }
});

3단계 — React에서 gsap.context()로 안전하게 정리

import { useGSAP } from "@gsap/react";
import gsap from "gsap";

function Banner() {
  const container = useRef(null);

  useGSAP(() => {
    gsap.to(".hero", { opacity: 1, y: 0, duration: 0.8 });
    // 컴포넌트가 unmount되면 이 스코프 안 애니메이션이 자동으로 revert됨
  }, { scope: container });

  return <div ref={container}><div className="hero">Hello</div></div>;
}

4단계 — Flip으로 레이아웃 전환 애니메이션

import Flip from "gsap/Flip";
gsap.registerPlugin(Flip);

const state = Flip.getState(".card");  // 변경 "전" 위치·크기 스냅샷
container.appendChild(card);            // DOM 구조를 실제로 바꿈
Flip.from(state, { duration: 0.5, ease: "power1.inOut" }); // "전"에서 "후"로 자연스럽게 보간

이 네 단계는 실제로 GSAP를 쓰는 프로젝트에서 가장 자주 반복되는 패턴이다. 공통점은 "값을 직접 계산해 매 프레임 대입하는" 저수준 작업을 GSAP가 대신 해준다는 것이다.

9함정·오해 방지

10대안 비교

11정리 — 누가 쓰면 좋은가

GSAP는 "움직임을 정밀하게 지휘해야 하는 모든 웹 프로젝트"에 잘 맞는다. 특히 다음과 같은 사람·상황에 추천한다.

• 랜딩페이지·에이전시 사이트 제작자 — 스크롤에 맞춰 요소가 등장·고정·전환되는 연출을 ScrollTrigger로 짧은 코드에 구현
• React/Vue 프론트엔드 개발자 — gsap.context()/useGSAP()로 프레임워크 생명주기와 충돌 없이 명령형 애니메이션을 안전하게 섞어 쓰고 싶은 경우
• 인터랙티브 시각화·데이터 대시보드 개발자 — 순수 JS 객체·Canvas·SVG 값을 타임라인으로 정교하게 제어해야 할 때
• 디자인-투-코드 작업자 — Flip으로 레이아웃 전환을, MorphSVGPlugin으로 아이콘·일러스트 모핑을 무료로 구현하고 싶은 경우

반대로 버튼 hover 색상 전환처럼 아주 단순한 트랜지션 하나만 필요하다면 굳이 GSAP를 끌어올 필요는 없다 — CSS만으로 충분하고, 번들 크기도 아낄 수 있다. "얼마나 복잡한 타임라인을 지휘해야 하는가"가 GSAP 도입 여부를 가르는 가장 실용적인 기준이다.