디자이너라면 한 번쯤 클라이언트에게 "좀 더 부드럽게 해주세요"라는 말을 들어봤을 겁니다. 저도 5년 차 프리랜서로 일하면서 이 한마디 앞에서 막막했던 적이 한두 번이 아니었습니다. '부드러움'은 감각이 아니라 수치입니다. 이징 함수와 타이밍 구간을 제대로 이해하고 나서야 저는 그 막막함에서 벗어났습니다.
이징 함수, 숫자로 부드러움을 만드는 법
일반적으로 모션 디자인에서 200ms 안팎의 트랜지션이면 충분하다고 알려져 있습니다. 저도 그렇게 믿고 핀테크 모바일 앱 외주를 진행했었는데, 실제 사용자 테스트 결과는 생각과 달랐습니다.
디폴트로 적용해둔 linear 200ms 트랜지션을 ease-out 280ms로 바꿨을 뿐인데, NPS(Net Promoter Score)가 6점에서 8점으로 올랐습니다. NPS란 "이 제품을 주변에 추천하겠습니까?"라는 질문을 기반으로 고객 충성도를 수치화한 지표입니다. 단순히 느낌이 좋아진 게 아니라 추천 의향 자체가 달라진 겁니다.
핵심은 이징 함수(easing function)의 종류에 있습니다. 이징 함수란 애니메이션이 시작부터 끝까지 얼마나 빠르게, 혹은 느리게 움직이는지를 결정하는 수학적 곡선입니다. 같은 300ms라도 linear로 움직이는 요소와 ease-out으로 움직이는 요소는 전혀 다른 느낌을 줍니다.
자주 쓰이는 이징 곡선을 정리하면 다음과 같습니다.
- ease-out(감속): 화면에 진입하는 요소에 적용. 빠르게 들어와 부드럽게 멈추는 느낌
- ease-in(가속): 화면에서 빠져나가는 요소에 적용. 느리게 출발해 빠르게 사라지는 느낌
- ease-in-out(가속 후 감속): 화면 안에서 이동하는 요소에 적용. 중간 지점에서 가장 빠름
- linear(등속): 음악 플레이어 진행 바처럼 일정한 속도가 필요한 경우에만 사용
- spring(탄성): 물리 기반 탄성 효과로, 자연스러운 반동감 연출에 사용
저는 이걸 머릿속에만 두지 않고 노션에 의사결정 시트로 정리해뒀습니다. "요소가 화면에 진입하는가? → ease-out", "화면을 벗어나는가? → ease-in" 같은 흐름으로 조건을 분기해두니, 매번 감으로 고르던 시간이 크게 줄었습니다.
타이밍 기준, 200ms 가이드는 이미 낡았다
타이밍에 관해서는 200~500ms를 보편적 기준으로 제시하는 의견도 있지만, 저는 실제로 써보니 상황마다 꽤 다르다고 느낍니다.
Google의 Material Design 3 가이드라인에 따르면 데스크톱 마이크로인터랙션은 150~250ms, 모바일 페이지 전환은 300~350ms를 권장합니다(출처: Material Design). 마이크로인터랙션이란 버튼 클릭이나 체크박스 선택처럼 아주 작은 단위의 인터랙션을 뜻합니다. 이 기준보다 길면 앱 전체가 느리게 느껴지고, 짧으면 사용자가 변화를 인지하지 못합니다.
제가 직접 써봤는데, 호버 상태나 클릭 피드백처럼 즉각적인 반응이 필요한 곳에 280ms를 넘기면 분명히 체감 속도가 달라집니다. 반대로 화면 전환이나 모달이 올라오는 장면에는 300ms 이상을 줘야 자연스럽다는 걸 외주 4건을 재조정하면서 확인했습니다.
staggered timing(스태거드 타이밍)도 자주 활용합니다. 스태거드 타이밍이란 리스트 항목이나 카드 여러 개가 동시에 등장하지 않고 20~40ms 간격으로 순차 진입하도록 딜레이를 주는 기법입니다. 동시에 쏟아지는 것보다 훨씬 자연스럽고, 정보의 계층감도 생깁니다. cubic-bezier(큐빅 베지어) 값을 After Effects에서 미리 시뮬레이션한 뒤 Figma Smart Animate에 옮기는 흐름을 표준화하고 나서, 저는 작업 속도가 약 25% 단축됐습니다. cubic-bezier란 두 개의 제어점으로 곡선 모양을 정의해 애니메이션의 가속·감속 패턴을 정밀하게 조정하는 함수입니다.
spring 물리 기반 모션, 이제는 선택이 아니다
cubic-bezier 중심의 이징 가이드가 표준처럼 쓰이던 시절이 있었습니다. 그런데 솔직히 지금 그 기준만 고집하면 한 발 늦은 셈입니다.
Apple은 iOS 17과 Liquid Glass 디자인 언어를 통해 spring physics(스프링 물리) 기반 모션을 사실상 표준으로 정착시켰습니다(출처: Apple Developer Documentation). spring physics란 현실의 용수철처럼 tension(장력)과 friction(마찰)을 설정해 요소가 목표 지점에 도달할 때 자연스러운 반동을 만들어내는 물리 엔진 기반 애니메이션입니다. 사용자가 의식하지 못해도 몸으로 느끼는 '살아있는 느낌'의 근원이 여기에 있습니다.
국내에서도 토스, 당근, 쿠팡이 spring 모션을 적극적으로 도입하면서 이 흐름은 더 분명해졌습니다. 제가 spring 애니메이션을 처음 프로토타입에 적용했을 때 가장 놀랐던 건, 클라이언트가 "이게 뭔가 다르네요"라고 먼저 말했다는 점입니다. 구체적으로 뭐가 다른지는 설명하지 못하면서도 차이를 느낀 겁니다.
다만 spring 모션은 tension과 friction 조합에 따라 duration(지속 시간)이 예상보다 길어질 수 있어 주의해야 합니다. 반동이 너무 커지면 성능보다 개성이 앞서는 문제가 생깁니다. 저는 spring을 적용할 때 반드시 실기기에서 프리뷰를 확인하는 단계를 워크플로우에 넣어뒀습니다.
결국 모션 디자인에서 실력 차이가 나는 건 툴 숙련도가 아니라, 이 세 가지—이징 함수의 선택 근거, 타이밍 구간의 기준, spring 물리의 적용 판단—를 수치로 설명할 수 있느냐입니다. 저는 '부드럽게 해주세요'를 들을 때 더 이상 막막하지 않습니다. ease-out으로 바꾸고 280ms를 적용한 뒤 NPS가 오른 경험이 그 자신감의 근거입니다. 다음 작업에서 마이크로인터랙션 하나라도 수치 기반으로 조정해보시길 권합니다.