Blog으로 돌아가기
2026.06.01.2 min read

좋은 모션은 얼마나 움직여야 할까

애니메이션을 넣는 일은 쉽지만, 좋은 리듬을 만드는 일은 생각보다 어렵습니다. 특히 포트폴리오에서는 움직임이 나를 설명하는 언어가 됩니다.

GSAPInteraction

움직임은 설명이어야 한다

처음에는 요소가 등장할 때마다 조금씩 움직이면 화면이 풍성해진다고 생각했습니다. 그런데 실제로 보면 움직임이 많을수록 사용자가 읽어야 할 정보와 경쟁하기 시작했습니다.

그래서 현재는 화면의 상태가 바뀌는 순간, 사용자의 시선이 이동해야 하는 순간에만 모션을 남기는 쪽으로 정리하고 있습니다.

포트폴리오를 만들면서 GSAP을 여러 페이지에 적용해보니, 모션은 단순히 '보이게 하는 효과'가 아니라 화면의 문장을 이어주는 접속사에 가깝다는 생각이 들었습니다. 갑자기 나타나는 것보다 왜 나타났는지 느껴지는 것이 더 중요했습니다.

예를 들어 Contact 페이지의 SendMail 영역은 터미널 컨셉을 갖고 있어서 타이핑되는 애니메이션이 자연스럽게 어울렸습니다. 사용자는 버튼을 보기 전에 이미 명령어가 입력되는 장면을 상상하게 됩니다. 반대로 Blog 페이지에서는 글을 읽는 흐름이 중요하므로, 지나치게 튀는 모션은 오히려 컨셉과 맞지 않았습니다.

결국 같은 GSAP이어도 페이지마다 쓰임이 달라야 했습니다. 어떤 곳에서는 등장감이 필요하고, 어떤 곳에서는 거의 느껴지지 않는 부드러운 전환이 필요했습니다. 도구는 같아도 목적이 다르면 움직임의 성격도 달라졌습니다.

딜레이보다 즉시성

스크롤이나 클릭 같은 입력 뒤에 1초 가까운 공백이 생기면 아무리 부드러운 모션이라도 느리게 느껴집니다.

최근 프로젝트 페이지를 수정하면서 타임라인을 병렬로 바꾸었고, 그 결과 화면이 훨씬 가볍게 반응했습니다. 모션은 늦게 시작되는 연출보다 즉시 반응하는 피드백에 가까워야 했습니다.

처음에는 딜레이를 주면 더 고급스러워 보일 거라고 생각했습니다. 순서대로 들어오는 요소들이 화면을 정돈해주는 느낌이 있었기 때문입니다. 하지만 실제 사용 상황에서는 그 딜레이가 곧 기다림이 되었습니다. 클릭했는데 반응이 늦고, 스크롤했는데 내용이 한 박자 뒤에 바뀌면 사용자는 애니메이션을 감상하기보다 답답함을 먼저 느꼈습니다.

그래서 지금은 입력 직후 첫 변화가 바로 일어나는지를 가장 먼저 확인합니다. 전체 애니메이션이 0.6초 걸리더라도 첫 0.1초 안에 무언가 반응하면 훨씬 빠르게 느껴집니다. 이 차이는 코드로 보면 작은 수치지만 화면에서는 꽤 크게 느껴졌습니다.

GSAP 타임라인을 조정할 때도 같은 원칙을 적용했습니다. 여러 요소가 순서대로 끝나기를 기다리지 않고, 상태 변화가 하나의 덩어리처럼 시작되도록 겹쳤습니다. 사용자는 타임라인의 순서를 알 필요가 없고, 결과적으로 화면이 내 행동을 이해했다는 느낌만 받으면 됩니다.

내가 좋아하는 리듬

짧게 들어오고, 잠깐 머무르고, 다음 정보가 자연스럽게 이어지는 리듬을 좋아합니다.

화려한 효과보다 '방금 화면이 왜 바뀌었는지'를 몸으로 이해하게 만드는 모션을 계속 연습하고 싶습니다.

내가 좋아하는 모션은 과시하는 느낌이 적고, 화면의 질서를 살짝 알려주는 움직임입니다. 요소가 위에서 아래로 내려오는지, 왼쪽에서 오른쪽으로 밀리는지, 작게 커지는지에 따라 사용자가 다음에 봐야 할 위치가 달라집니다. 이런 작은 방향성이 화면의 흐름을 만듭니다.

이번 포트폴리오에서는 검정과 흰색을 많이 쓰고 있기 때문에 모션이 더 눈에 잘 띄었습니다. 색이 차분할수록 움직임 하나가 강하게 느껴졌고, 그래서 더 절제해야 했습니다. 연두색 포인트도 마찬가지였습니다. 조금만 써도 충분히 강해서, 정말 필요한 곳에만 남기는 편이 좋았습니다.

앞으로 더 해보고 싶은 것은 스크롤 위치와 글 읽기 경험을 연결하는 모션입니다. 사용자가 어느 섹션을 읽고 있는지 인덱스가 조용히 반응하고, 다음 글로 넘어갈 때도 방향감이 생기면 블로그가 단순한 글 목록보다 더 살아 있는 공간처럼 느껴질 것 같습니다.