React용 Swiper 대안, 실제로 무엇을 피하려는지에 따라
Swiper가 나빠서 떠나는 사람은 없습니다 — 존재하는 슬라이더 중 가장 완전하니까요. 사람들이 떠나는 이유는 무게(모듈 적용 전 기준 ≈40 kB) 때문이거나, DOM과 CSS를 그대로 물려받아야 하기 때문이거나, 애초에 자신의 "슬라이더"가 진짜 슬라이드가 아니었기 때문입니다. 각 불만에는 저마다 다른 최선의 답이 있습니다.
| Swiper | Embla | keen-slider | react-horizontal-scrolling-menu | |
|---|---|---|---|---|
| 번들 (코어, min+gzip) | ≈40 kB | ≈8 kB | ≈7 kB | ≈5.7 kB |
| 모델 | 슬라이드, 배터리 포함형 | 슬라이드, 헤드리스 | 슬라이드, 최소 엔진 | 네이티브 스크롤 행 안의 항목 |
| 이펙트와 모듈 | 가장 풍부함 | 플러그인 / 직접 구현 | 일부 내장 | 없음 — 대신 레시피 제공 |
| 제스처 레이어 소유 여부 | 있음 (transform) | 있음 (transform) | 있음 (transform) | 없음 — 브라우저가 스크롤 |
| 항목별 가시성 | 슬라이드 인덱스 이벤트 | 슬라이드 인덱스 이벤트 | 슬라이드 인덱스 이벤트 | 내장 (useIsVisible) |
| 교체하기 좋은 경우 | — | 어차피 모든 것을 직접 스타일링한다면 | 최소한의 슬라이더, React 종속 없음 | "슬라이드"가 사실 클릭 가능한 항목이라면 |
크기는 대략적인 코어 기준입니다 — Swiper는 가져오는 모듈에 따라 커지며, 이는 곧 다이어트한 Swiper 빌드가 평판보다 작을 수 있다는 뜻이기도 합니다.
킬로바이트에서 벗어나기: Embla 또는 keen-slider
제품이 진짜 캐러셀이라면 — 스냅되고, 한 번에 한 페이지의 슬라이드만 보여준다면 — 가벼운 엔진들이 거의 그대로 대체될 수 있습니다:
- Embla (≈8 kB): 헤드리스, 뛰어난 물리 엔진, 퍼스트클래스 React 훅, shadcn/ui 캐러셀이 내부적으로 쓰는 엔진입니다. 모든 마크업과 CSS는 여러분이 직접 가져오는데, 그것이 바로 핵심입니다.
- keen-slider (≈7 kB): 프레임워크에 종속되지 않는 최소한의 엔진으로, 같은 슬라이더를 React와 비React 환경에 모두 배포해야 할 때 좋습니다.
둘 다 transform 기반 슬라이드 모델을 유지하므로 페이드나 커버플로 같은 이펙트는 직접 구현해야 합니다 — 그런 이펙트에 의존한다면, 다시 구현하는 것보다는 다이어트한 Swiper 빌드가 정직하게 더 나은 답입니다.
슬라이드 모델에서 벗어나기: 메뉴 형태인 경우
또 다른 탈출구는 Swiper의 슬라이드 시맨틱이 애초에 구조를 떠받치고 있지 않았던 구성을 위한 것입니다: 카테고리 행, 로고 월, 탭 스트립, 칩 바, 상품 레일. 신호는 slidesPerView: 'auto'와 freeMode: true를 함께 쓰는 설정입니다 — 이 조합은 Swiper에게 네이티브 스크롤을 흉내 내라고 요구하는 것입니다.
react-horizontal-scrolling-menu (≈5.7 kB)는 바로 그 네이티브 스크롤에, 브라우저가 제공하지 않는 부분들을 더한 것입니다: 항목별 가시성, scroll-to-item, 가장자리를 인식하는 화살표, 그리고 클릭을 깨뜨리지 않는 드래그. 이펙트도, 스냅도, 제스처 에뮬레이션도 없습니다 — Netflix 행, 탭, 칩 바 페이지, 또는 전체 표를 확인하세요.
양쪽 방향 모두를 향한 공정한 경고
Swiper에서 벗어나 무게를 줄이려다가 자동재생, 페이지네이션, a11y 안내, 이펙트를 직접 구현하게 되면, 40 kB짜리 문제가 사람 한 달치 공수 문제로 바뀌는 셈입니다. 사용 범위가 정말로 부분집합일 때만 더 가벼운 엔진으로 교체하고, 슬라이드 시맨틱이 애초에 가짜였을 때만 스크롤 메뉴로 바꾸세요. Swiper의 깊이를 쓰고 있다면 Swiper를 유지하세요.