시작하는 글
리액트를 사용하면서 넘어야 할 몇 가지 산 중에 하나가 redux로 대표되는 state management라고 생각합니다. 여기에 관한 수많은 고민들이 있었던 거 같습니다. 프론트엔드 개발을 시작한지 얼마되지 않았지만 짧은 시간 사이에 쫓아갈 수도 없을 만큼 수많은 라이브러리들과 아티클들이 쌓여있네요.
쏟아지는 기술들 사이에서 어떤 기술을 잘 선별하는가에 대한 고민들이 다들 깊으실 거 같습니다. 예를들어 고심 끝에 회사의 프로젝트를 A라이브러리를 통해서 작업을 하고 있었고 이제 프로덕션 레벨에서 배포를 해야하는데 치명적인 결함이 발견되면 돌이킬 수 없게 될 수도 있으니깐요.
이러한 리스크는 아무리 철저한 심사를 거친다고 해도 충분히 생길 수 있는 일이라고 생각합니다. 더욱 철저한 검사를 통해서 B 라이브러리를 선택해도 같은 문제는 또 생길 수 있다고 생각해요. 늘 열린 마음으로 리팩토링의 가능성을 생각해야 되지 않나 싶어요. 내가 짠 코드가 언제든 새롭게 변경될 수 있다는 가능성을 열어둬야 하는 거 같습니다. 결국 이 말은 당연하게도 완벽한 라이브러리나 답은 없다는 말이 되겠네요. 선택을 똑똑하게 하고 유지보수 그리고 개선의 가능성을 늘 고려해야 하는 거 같습니다.
개인 공부를 하거나 토이프로젝트를 할 때 좋은점은 신기술(?)을 마구 써도 되잖아요. 검증이 부족한 라이브러리에 대한 부담감은 개인 작업에서는 확실히 낮은데 있는 거 같아요. 이번에 recoil을 기반으로 토이프로젝트를 진행하려고 생각중인데 그 중간 단계로 정리를 해보고자 합니다.
개인적으로 recoil을 써보려고 하는 이유가 다른 라이브러리보다 OO가 더 나아서가 아니라 정말 그냥 한 번 써보고 싶어서 입니다. 제가 경험한 state management 라이브러리 중에서 초기 설정이 가벼운 편인 거 같긴한데 아직은 잘 모르겠습니다. 한 번 써보고 왜 이걸 써야해 이걸 쓰지 말아야 해를 알 수 있지 않나 하는 생각입니다.
개인적인 검증의 시간을 자유롭게 가져보고자 합니다. ㅎㅎ
