Webpack, Framer, Preact, Reach UI를 연습 삼아 간단하게 사용 해 봤다.

TL;DR

전체 코드는 https://github.com/iamchanii/preact-framer-motion-modal 에서 확인할 수 있다. 그런데 이 글에서 코드에 대한 이야기는 하지 않는다. (그냥 궁금하면 봐 주시라)

Webpack

필자는 웹팩을 구성할 줄 안다. 저장소의 웹팩 설정 파일을 보면 알 수 있지만 정말 딱 그정도 수준으로만 만들줄 안다.

회사 프로젝트도 그렇고, 평소에 CRA를 매우 잘 사용하고 있다. 개발 환경 구성으로 인한 스트레스를 받지 않을 수 있으면서도 꽤 괜찮은 환경을 제공하기 때문이다. Eject 보다 React App Rewired 같은 것을 선호하는 이유도 비슷한 맥락에 있다.

그런 환경에서 개발을 하다보니 웹팩에 대한 관심이 크게 줄어들고 있음을 몸소 느끼고 있었다. 새로운 번들러가 나와도 시큰둥, 웹팩 5에 대한 소식이 나와도 시큰둥한 내 모습은, 마치 다른 언어의 소식을 접한 개발자, 아니 개발 소식을 접한 비개발자의 자세와 다를 바 없었다.

그리고 모든 프론트엔드 엔지니어가 웹팩을 능숙하고 우아하게 다뤄야 하는 필수 스킬은 아니지만, 잘하진 않더라도 아는 것과 전혀 못하는 것은 매우 큰 차이가 있다.

처음부터 모든 설정을 직접 해봤다. 경험 해 보니 CRA가 제공하는 스캐폴딩이 얼마나 높은 수준이었는지 절감하게 되었다. 프로덕션으로 사용이 가능한, CRA에서 제공하는 수준의 웹팩 설정을 직접 하는게 얼마나 어려울지 감히 상상도 되지 않는다.

이번 경험을 바탕으로, 회사라면 더욱 적극적으로 CRA를 사용할 것 같다. 별개로 웹팩에 대한 공부는 꾸준히 해야 겠다.

Preact

웹팩을 직접 구성하게 된 결정적인 이유는 Preact를 경험 해 보고 싶었기 때문이다. 엄청 큰 프로젝트를 구성하는게 아니라서 Preact의 핵심 콘셉트가 내게는 큰 효과를 경험하기는 어려웠지만 빌드 용량이 많이 줄어든 것을 볼 수 있었다.

그 외에는 사실 잘 모른다. 좀 더 사용해 보고 나중에 한번 더 정리하기로 한다.

Framer Motion

모든 프론트엔드 엔지니어는 화려한 애니메이션을 구현한 것에 대한 욕심이 있을 것이다.

CSS 트랜지션 수준의 효과가 아니라 느낌적인 느낌의 효과를 말하고 싶다. 마치 드리블에서 볼 법한 효과들. 목에 칼을 들이 밀고 구현하라면 또 어떻게든 (울면서) 하겠지만, 결코 쉬운 작업이 아니다.

가끔 기획자와 디자이너가 **“이렇게 슈웅, 그리고 솨악”**할 때 마다 표정이 어두워지는 이유는 욕심과 현실이 충돌하기 때문이라는 것을 알아주셨으면 좋겠다.

결론은, 비록 내가 많이 사용해본 것은 아니지만, 요번에 홈페이지 일부 기능을 구현하면서 디자이너님이 요청한**“슥슥슥”**효과를 구현할 수 있었기에 Framer Motion을 사용하면 그나마 슈웅, 솨악을 흉내낼 수 있도록 도와줄 수 있을 것 같다는 이야기를 하고 싶었다.

Reach UI

리액트에서 ReactDOM.createPortal API가 제공되고 있으므로 다이얼로그나 모달, 알림과 같은 UI를 처음부터 구현하는 것이 불가능하지는 않다.

문제는 접근성을 고려해서 구현하는 것이 까다롭다. 키보드로 포커스를 이동하거나, 엔터 또는 스페이스바를 누르면 버튼이 눌릴 수 있도록 하는 작업을 처리 해 주지 않으면, 매우 사소하지만 PC에서 사용성이 떨어지는 것을 초래할 수 있다.

원래 모바일의 사용자 경험을 챙기는 것에 집중했었는데, 데스크탑에서의 경험 또한 중요하다는 사실을 요 근래 많은 피드백을 들으면서 깨닫고 있다.

데스크탑은 키보드와 마우스가 있으니까 괜찮고, 모바일은 화면이 작고 입력 방법이 제한적이어서 모바일을 주로 챙겼었는데, 프로젝트 성향에 따라 입력 방법이 다양한 데스크탑을 더 세심하게 챙길 필요가 있다는 것이다.

또, 그런 생각을 한 적이 있다. 시각이 불편한 사람이 디지털 사이니지 관리 도구를 사용할 수 있다면 어떨까? 이 생각을 했을 때에는 이미 먼 길을 왔기에 시도조차 할 수 없었지만, 디지털 사이니지 관리 도구를 “제품”이나 “서비스”로 바꾸면 말이 안되는 말은 아니지 않나.

예전에 레진에서 실제로 사용하고 있는 WAI-ARIA 가이드 라인을 읽은 적이 있는데, 접근성을 지키는 것 자체도 멋있었지만, 제품에 적용한 사례를 기술 블로그를 통해 공유한 것이 감명 깊었다.

레진코믹스처럼 접근성을 하나 하나 챙기기 어렵다면 Reach UI나 Reakit을 사용하여 UI를 구축하는 것은 훌륭한 대안이라고 생각되어 다이얼로그를 구현할 때 Reach UI를 사용하였다.

특별히 나쁜 점은 모르겠다. 언젠가 회사 차원의 디자인 시스템을 구축하게 된다면 기꺼이 이러한 접근성 UI 라이브러리들을 채택하고자 한다.

라이브러리 주도 개발 혹은 학습

결국 라이브러리를 자주 사용하는 습관은 크게 나아지지 않은 것 같다.

하지만 요새 나의 생각을 관통하는 말이 있다. 완벽한 것은 없다. 다만 만족할 수 있는 것이 있을 뿐이다. 그것은 조직 문화일 수도 있고, 라이브러리일 수도 있고, 진짜 사소하게는 뭐, 매일 같이 사용하는 고데기에도 적용할 수 있지 않을까.

다만 라이브러리들이 진짜로 무엇을 해결하기 위해 만들어 졌는지 충분히 고민하고 이해한 뒤, 내가 맞이한 문제를 해결할 수 있다고 판단이 되었을 때에는 라이브러리를 도입해도 괜찮다고 생각이 든다. 만약 내가 그런 수준의 고민을 한 뒤라면 그 이후에 발생하는 문제 또한 해결할 수 있는 실력이 있을 것이다.

코드 베이스가 구린건 단연코 라이브러리의 문제가 아니다.