랜딩 페이지에 패럴랙스 효과를 넣었다가 모바일 사용자에게 "화면이 어지럽다"는 피드백을 받아본 적 있으신가요? 저는 있습니다. 브랜드 랜딩 외주에서 데스크톱과 모바일에 동일한 강도로 효과를 적용했다가 5명에게서 같은 말을 들었습니다. 그 경험이 지금 이 글을 쓰게 만든 출발점입니다.
Figma 안에서 패럴랙스를 시뮬레이션한다는 것
혹시 디자이너로 일하면서 "이 효과를 개발자한테 어떻게 설명하지?"라고 막막했던 순간이 있으셨나요? 패럴랙스(parallax) 효과는 특히 그렇습니다. 패럴랙스란 스크롤할 때 전경과 배경 레이어가 서로 다른 속도로 움직이면서 원근감과 공간감을 만들어 내는 기법입니다. 말로 설명하면 쉽지만, 실제 느낌을 전달하기는 어렵습니다.
Figma의 스마트 애니메이트(Smart Animate) 기능이 이 문제를 상당 부분 해결해 줍니다. 스마트 애니메이트란 두 프레임 사이에서 같은 이름을 가진 레이어를 자동으로 감지하고, 위치·크기·투명도 변화를 자연스럽게 보간(interpolation)해 주는 기능입니다. 즉, 개발자에게 말로 설명하는 대신 프로토타입 링크 하나를 넘겨주면 됩니다.
구체적인 방법은 이렇습니다. 배경이 되는 산 이미지, 수면 레이어, 수중 레이어를 각각 분리한 뒤 Scene 1과 Scene 2에서 각 레이어의 위치를 다르게 배치합니다. Scene 1에서 Scene 2로 넘어갈 때 스마트 애니메이트가 각 레이어를 개별적으로 움직여 전경과 배경의 이동 속도가 달라 보이는 패럴랙스 효과가 완성됩니다. 레이어가 많을수록, 이동 거리 차이가 클수록 3D처럼 느껴지는 깊이감이 강해집니다.
모바일 최적화, 강도를 어떻게 정할까
패럴랙스를 만들고 나면 바로 이 질문이 따라옵니다. "모바일에서는 어떻게 해야 하지?"
제가 직접 써봤는데, 데스크톱에서 50%로 설정한 패럴랙스 이동 강도를 모바일에 그대로 적용하면 문제가 생깁니다. 실제로 저는 그 결과로 "어지럽다"는 피드백 5건을 받았고, 모바일 강도를 20%로 낮춘 뒤 같은 피드백이 0건이 됐습니다. 수치가 명확하게 말해 주는 차이였습니다.
왜 이런 차이가 날까요? 모바일 기기는 화면 크기가 작고 사용자가 손으로 쥐고 있어 물리적 흔들림이 기본적으로 존재합니다. 거기에 빠른 패럴랙스 이동이 더해지면 전정기관에 혼란을 줍니다. 또한 모바일 브라우저의 렌더링 파이프라인(rendering pipeline), 즉 브라우저가 화면을 그리는 일련의 과정이 데스크톱보다 제한적이어서 60fps를 유지하기가 더 어렵습니다.
이 문제를 해결할 때 실용적인 기준은 다음과 같습니다.
- 데스크톱 패럴랙스 이동 강도의 40% 이하를 모바일 기준으로 삼는다
- prefers-reduced-motion 미디어 쿼리를 반드시 설정한다. 이는 사용자가 운영체제에서 "움직임 줄이기"를 활성화했을 때 애니메이션을 끄거나 약하게 해 주는 CSS 속성입니다
- 터치 기기에서는 스크롤 이벤트 대신 scroll 이벤트의 passive 옵션을 사용해 메인 스레드 부하를 줄인다
솔직히 이건 예상 밖이었습니다. 강도를 조금 낮추는 것만으로 피드백 건수가 완전히 사라질 줄은 몰랐거든요.
GSAP ScrollTrigger로 구현할 때 실제로 달라지는 것
Figma 프로토타입은 기획·설득 단계에서 강력하지만, 실제 코드 구현에서는 GSAP의 ScrollTrigger가 현장에서 가장 많이 쓰이는 선택지입니다. ScrollTrigger란 스크롤 위치를 감지해 특정 요소의 애니메이션을 트리거·제어할 수 있는 GSAP 플러그인입니다.
제 경험상 이건 좀 다릅니다. ScrollTrigger를 쓸 때 transform과 opacity만 건드리는 디폴트 설정을 지키는 것이 생각보다 중요합니다. transform(위치·크기 변환)과 opacity(투명도)는 GPU 가속 레이어에서 처리되기 때문에 레이아웃 재계산이 일어나지 않습니다. 반면 top, left, width 같은 CSS 속성을 건드리면 브라우저가 레이아웃을 처음부터 다시 계산하는 리플로우(reflow)가 발생하고, 이것이 프레임 드롭의 주범이 됩니다.
저는 외주 4건에서 동일하게 GSAP과 CSS scroll-timeline 폴백(fallback) 패턴을 적용했는데, 작업 속도가 평균 30% 단축됐습니다. 폴백이란 최신 기능을 지원하지 않는 브라우저에서 대체 방법으로 같은 결과를 내는 코드 구조를 말합니다. 같은 패턴을 반복 재사용할 수 있는 Webflow 컴포넌트로 정리해두면 신규 프로젝트마다 처음부터 짜지 않아도 되니 효율이 크게 오릅니다.
60fps가 실제로 유지되는지 확인하는 방법도 중요합니다. 저는 Chrome DevTools의 Performance 탭을 활용하는 5단계 체크리스트를 만들어 두었습니다.
- Performance 탭에서 Record 후 스크롤 테스트 진행
- Frames 섹션에서 빨간/노란 프레임 위치 확인
- 원인 레이어를 Layers 패널에서 식별
- transform/opacity 외 속성 사용 여부 검토
- 모바일 기기 에뮬레이션으로 동일 체크 반복
이 체크리스트를 거친 4건의 랜딩 페이지에서 평균 페이지 체류 시간이 32초에서 51초로 늘었습니다. 숫자가 말해 주는 결과라고 생각합니다.
CSS scroll-timeline, 이제는 표준으로 봐야 할까
일반적으로 패럴랙스 구현에는 JS 라이브러리가 필수라고 알려져 있지만, 2025년 현재 상황은 조금 다릅니다. CSS scroll-driven animations는 W3C CSS Working Group에서 공식 표준으로 채택한 사양이며(출처: W3C), Chrome 115 이상과 Safari Technology Preview에서 이미 지원되고 있습니다.
CSS scroll-timeline이란 CSS만으로 스크롤 진행 비율을 애니메이션 타임라인에 연결하는 표준 기능입니다. 쉽게 말해 JS 없이도 스크롤 위치에 따라 요소가 움직이는 패럴랙스 효과를 CSS 몇 줄로 구현할 수 있다는 의미입니다. animation-timeline: scroll() 한 줄로 기본 패럴랙스가 동작합니다.
번들 크기 측면에서도 차이가 납니다. GSAP ScrollTrigger 플러그인은 약 25KB(gzip 기준)를 차지하는 반면, CSS scroll-timeline은 별도 다운로드가 필요 없습니다. Web Almanac 2023 보고서에 따르면 JS 번들 크기가 100KB 증가할 때마다 모바일에서 페이지 인터랙티브(TTI) 시간이 평균 1초 늘어납니다(출처: Web Almanac).
개인적으로는 "CSS scroll-timeline 우선, GSAP ScrollTrigger 폴백" 순서로 접근 방식을 바꿔가는 것이 맞는 방향으로 보입니다. 다만 아직 구형 브라우저 지원이 필요한 프로젝트라면 GSAP 폴백을 완전히 버리기는 이릅니다.
패럴랙스는 "어떻게 만드느냐"보다 "얼마나 절제하느냐"가 결과를 가릅니다. Figma 프로토타입으로 효과를 먼저 확인하고, 모바일 강도를 데스크톱의 40% 이하로 제한하고, 60fps 체크를 습관화하는 것. 이 세 가지를 지키는 것만으로도 사용자가 느끼는 경험은 크게 달라집니다. 아직 패럴랙스 강도를 기기별로 분리해두지 않으셨다면, 지금 프로젝트에서 바로 확인해 보시길 권합니다.