서론

기획이라는걸 정말 치밀하고 확실하게 준비해야함을 깨달았다.
기획에서 치밀하지 못했기 때문에 결국 개발환경 자체를 바꾸어야 했는데, 그 이유에 대해서 서술하려 한다.

본론

왜 스와이퍼를 선택했나?

처음 개인 포폴사이트에 스와이퍼를 도입한 이유는 간단했다.

1. UX에서 뛰어난 효과

• PC에서는 마우스 휠로 페이지 이동을 할 수 있음
• 모바일에선 드래그로도 쉽게 페이지를 이동할 수 있음

2. 페이지 이동 애니메이션

• 기본적으로 제공되는 부드럽게 움직이는 모션
• 필요하다면 여러가지 페이지 이동 모션 라이브러리에 존재

스와이퍼의 한계점

1) 페이지네이션 스타일링

그렇게 야심차게 도입했던 Swiper인데, 여러가지 한계에 봉착했다.
먼저, Tailwind를 주로 사용하는 나에게 고전적인 CSS로 페이지네이션을 수정해야한다는 부분은 스타일링을 이원화 시키게 되어 통일성이 옅어진다.

페이지네이션 스타일링의 문제는 Zustand(전역 상태)로 해결

이 문제를 해결하기 위해 기본적으로 제공되는 페이지네이션의 함수를 수정하는게 아니라, Zustand를 사용해 페이지 리스트는 무엇이고, 현재 페이지가 어떤건지, 어떤 액션(휠, Nav 버튼 클릭)을 통해 페이지가 수정될 것인지를 지정하였다.
이 문제가 완벽하게 해결된 것은 아니다. 인덱스의 앞뒤가 연결되는 무한설정의 경우 내부 로직의 문제인지 전역변수화 시켜놓은 상황에서 잘 해결이 되지 않아 무한 인덱스는 기능을 끄게 되었다.

2) 메인 페이지에 Y스크롤이 생길 경우

보여주고 싶은 메인 페이지에 Y스크롤이 생길 경우 pc는 마우스 휠, 모바일은 터치 드래그로 Y스크롤을 조절하는 것이 보통이다.
PC 화면에서는 Y스크롤이 없도록 기획하여 사실 문제가 없지만, 모바일로 가면 그 작은 디바이스에 한 페이지에서 보여줘야하는 모든 것을 보여주기가 힘들다.
그래서 브레이크포인트 또는 flex-wrap으로 세로로 길어지도록 하는 것이 보통인데, 이를 간과한 것이다. 향후 pc에서도 Y스크롤이 생길 수도 있는데-일기장 탭이 있다- 마우스 휠 또는 터치드래그로 다음 페이지로 넘어가버린 다는 것은 UX에 매우 치명적인 단점으로 작용한다.

결국 Swiper의 한계점을 인정하고 마이그레이션 결심

나는 프론트엔드 개발자이다. 프론트엔드는 고객과 맞닿는 부분을 디자인하기 때문에 항상 최상의 UX를 제공하려 노력해야한다. 고객의 불편함을 알고도 "그건 기술문제라 어쩔 수 없다"라는건 변명이라고 생각한다. 결국 전통적인 Next.js의 폴더라우팅으로 돌아가기로 한다.

마이그레이션을 하며 보완되는 점

그러나 원래 기능 요구사항에 존재했던 기능은 충실히 구현해야하는 것도 개발자의 숙명이다.
입사 테스트 중 Framer로 인터랙션을 구현했던 과제가 있어 Framer에 대해 알아보던 중 Framer-motion이라는 애니메이션 라이브러리를 알게 되었다.
이를 통해 어느정도 기능 요구사항을 만족할 수 있을 것 같다.

1. 아래는 UX상 불편함이 있어 포기해야하는 기능 요구사항

• PC에서는 마우스 휠로 페이지 이동
• 모바일에선 터치-드래그로 페이지를 이동

2. Framer-motion의 라우트 트랜지션 기능으로 구현

• 라우트시 어떤 애니메이션을 보여줄 지 직접 코드로 구현 가능

결론

사실 이 안에 코드는 없다. Framer-motion의 예시라도 들었다면 좋았으련만, 그것은 다음 포스트로 넘기고 오늘은 간단히 느낀점만 적고 마무리하도록 한다.