웹 애니메이션 라이브러리 GSAP으로 사이트를 움직이게 하려면, 코딩 에이전트에게 무엇을 어떻게 시켜야 하는지가 문제입니다. 개발자 John Polacek이 그 답으로 Animaxxing 스킬을 만들었고, 10월 26일 Codrops 튜토리얼로 만드는 과정을 풀어 썼습니다.
스킬만 있는 게 아닙니다. 공식 사이트 animaxxing.com과 Museum of Motion에 직접 눌러 볼 수 있는 데모가 잔뜩 올라와 있습니다. 이 글은 설명보다 그 데모를 보여 드리는 데 힘을 줬습니다.
설치는 한 줄입니다. 공식 GSAP 스킬 위에 Animaxxing 스킬을 얹는 구조라서, 명령이 두 개 이어집니다.
아래가 Animaxxing 스킬의 구성입니다. 열 개이고, 라이선스는 MIT입니다. 공식 gsap-skills는 따로 여덟 개 모듈(코어, 타임라인, ScrollTrigger, 플러그인, 유틸, React, 성능, 프레임워크)로 나뉩니다.
Animaxxing 스킬 열 개
| 모션 | 2 | animaxxing, animaxxing-webgl |
| 프레임워크 | 7 | gsap-vanilla, gsap-astro, gsap-sveltekit, gsap-nuxt, gsap-react-router, gsap-tanstack-router, gsap-nextjs |
| 스타일 | 1 | style-animaxxing |
프레임워크 스킬은 전부 같은 수명 주기를 따릅니다. 이 순서가 페이지 전환을 가능하게 한다고 Codrops 글은 설명합니다.
- 마운트 → 시작 자세
- 시작 자세 → 인트로
- 인트로 → 안정
- 안정 → 아웃트로
- 아웃트로 → 끝 자세
- 끝 자세 → 떠남
핵심은 맨 끝 규칙입니다. 떠나는 일을 끝낸 다음에야 도착을 시작합니다.
Museum of Motion은 튜토리얼에서 만든 데모 사이트입니다. 효과 57개를 하나씩 따로 보여 주고, 각각 무엇을 하는지와 터치, 키보드, 움직임 줄이기에서 어떻게 동작하는지를 적어 둡니다.
Museum of Motion의 효과 57개, 묶음별
| 항목 | Museum of Motion의 효과 57개, 묶음별 |
|---|---|
| 글자 | 9 개 |
| 재생 | 14 개 |
| 스크롤 | 11 개 |
| 포인터 | 11 개 |
| 드래그 | 4 개 |
| 분위기 | 8 개 |
사이트의 묶음 이름은 글자(Type), 재생(Play), 스크롤(Scroll), 포인터(Pointer), 드래그(Drag), 분위기(Vibes)입니다. 막상 눌러 보면 설명보다 훨씬 재미있습니다. 제가 먼저 열어 본 세 곳입니다.
- Wave는 글자가 굵어졌다가 놓이면서 문장 위로 물결이 지나갑니다. 지속 시간, 간격, 이징을 직접 바꿔 볼 수 있습니다
- Physics는 도형이 중력으로 떨어져 쌓이고, 튕기고, 새총처럼 날아갑니다. 클릭하면 더 떨어뜨립니다
- Liquid는 Vibes 묶음에 속합니다. 효과를 섞어서 하나의 분위기로 만든 작은 사이트입니다
그림: museum.animaxxing.com/exhibits/wave
튜토리얼에서 가장 쓸모 있었던 대목은 프롬프트보다 순서였습니다.
- 먼저
MOTION.md라는 짧은 모션 브리프를 씁니다. 에이전트가 세 가지 성격(정확하고 단호한 "프레스", 살짝 튀는 "키네틱 포스터", 차분한 "갤러리")을 내놓았고, 글쓴이는 에이전트의 추천 대신 키네틱 포스터를 골랐습니다. 이후 프롬프트마다 타이밍과 이징을 되풀이해 적지 않아도 됩니다 - 계획 프롬프트로 질문을 주고받은 다음, 새 세션에서 빌드 프롬프트를 던집니다
- 한 번에 다 시키지 않습니다. 전시 하나를 제대로 만든 뒤 "다른 것에도 적용해 줘"라고 합니다
버그 이야기가 은근히 재미있습니다. 이름 위에 마우스를 올리면 레이아웃이 흔들렸는데, 에이전트가 모든 이름에 호버를 걸어 보는 테스트를 짰더니 76개 중 31개에서 무언가가 움직였습니다. 원인은 폭 276.6픽셀을 277로 올림한 것이었습니다. 고친 뒤 같은 테스트에서 일곱 가지 화면 폭 모두 움직임이 0이었습니다.
여기서 한 걸음 더 갑니다. 글쓴이는 "스킬을 고쳐 줘"라고 시켰고, 이제 스킬에 레이아웃이 흔들리지 않는 호버 효과와 그걸 확인하는 검사가 들어 있습니다. 프로젝트 하나의 버그가 스킬의 수정이 되는 순환입니다.
Animaxxing과 공식 GSAP 스킬 모두 접근성을 기본으로 챙깁니다. 튜토리얼이 꼽은 항목은 다음과 같습니다.
- 움직임 줄이기를 켠 사람은 애니메이션 없이 각 요소의 마지막 모습으로 바로 갑니다
- 자바스크립트가 없어도 서버가 완성된 페이지를 보냅니다. 늦게 도착하면 잠깐 뒤에 보여 줍니다
- 호버 효과에는 같은 포커스 효과가 붙어서 탭 키로도 똑같이 반응합니다
- 반복되는 것에는 일시 정지 버튼이 있고, 선택을 기억합니다
- WebGL 효과는 실패하거나 움직임 줄이기가 켜져 있으면 실제 이미지를 보여 줍니다
Showcase에는 이미 아는 사이트 여덟 곳이 Animaxxing 방식으로 다시 그려져 있습니다. 같은 구조를 흑백과 모션으로 옮긴 것들입니다. 옆으로 넘기면서 보시면 됩니다. 눌러서 크게 볼 수도 있습니다.
저라면 스킬부터 깔지 않고 데모부터 열어 보겠습니다. 어떤 움직임이 마음에 드는지 알아야 모션 브리프를 쓸 수 있기 때문입니다. 튜토리얼도 같은 말을 합니다. 브리프 한 장이 이후 모든 프롬프트를 줄여 준다는 것입니다.
글쓴이 스스로 정적인 사이트가 괜찮다고, 은행 사이트에 스크롤 애니메이션을 원하는 사람은 없다고 적은 대목이 마음에 남았습니다. 이 스킬은 모든 곳을 움직이게 만드는 도구가 아니라, 움직이기로 정한 곳을 안전하게 움직이는 도구로 읽는 편이 맞아 보입니다.
한 가지는 아직 모릅니다. 데모 사이트의 움직임이 가벼운지, 실제 서비스의 성능 예산 안에 들어가는지는 이 기록만으로 알 수 없습니다. 써 본 뒤에 판단하려고 합니다.
Codrops 글은 에이전트와 애니메이션을 함께 쓸 때 참고할 자료도 꼽았습니다.
- Emil Kowalski의 디자이너와 엔지니어용 스킬
- Motion AI Kit, 코딩 에이전트를 위한 애니메이션 모범 사례
- Vercel Web Interface Guidelines, 애니메이션 성능과 접근성을 포함합니다