🧪

왜 Redux를 쓰는가?

프론트엔드 이직 기록

나는 2년차 프론트엔드 엔지니어가 되었을 때 이직을 결심했다. 이 포스트는 이직에 대한 기록이다. 전 회사의 기술 스택이 더 이상 바뀌지 않을 것 같았다. 일(개발)을 이렇게 하는 것이 맞나? 다른 회사는 어떻게 의사 결정을 하지? 회사 제품에 애정이 점점 사라져간다. 팀원이 떠나가는 것을 보고 싶지 않다.

https://velog.io/@lingodingo/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EC%9D%B4%EC%A7%81-%EA%B8%B0%EB%A1%9D

1.

코드는 production 수준으로 짜라

2.

테스트 작성 필수

3.

주석으로 코드 설명(production에서는 주석이 없겠지만, 이건 평가를 위한 것이므로)

4.

기술 스택은 최대한 자신이 잘 설명할 수 있는 것으로 선택

왜 Redux를 쓰는가? 였다.

나는 prop drilling을 해결해 주며 global state의 강점이 있다고 설명을 했었는데, prop drilling은 react-redux의 경우가 아니냐? 라고 되물었었고, 그리고 global state에 대해서는, useContext를 써서 global 한 state를 만들면 되지 않느냐. 왜 redux를 써야하는가? 이렇게 되물어봤었다.

Redux의 장점은1. 관심사의 분리에 굉장히 뛰어나다는 장점이 있습니다. Flux 아키텍쳐의 단방향 흐름은 코드의 유지보수를 쉽게 만들기 때문입니다. 즉 데이터 흐름이 직관적이게 되고 예측을 할 수 있다는 점입니다. 양방향으로 데이터를 조작하다보면 디버깅이 얼마나 어려운지 느끼실 수 있을겁니다.2. 훌륭한 미들웨어가 존재합니다. 비동기 액션을 처리할 때에 리덕스 미들웨어는 정말 훌륭한 도구입니다. 거의 미들웨어 때문에 리덕스를 쓴다고 해도 과언이 아닙니다. 미들웨어가 코드의 관심사 분리를 따로 빼주기 때문에, 깔끔(?)하게 코드를 작성할 수 있게 됩니다. 뷰에 해당하는 컴포넌트에 비동기 코드가 덕지덕지 붙는다고 생각해보세요. 이 컴포넌트를 재활용할 수 있을까요? (하게 만들 수는 있습니다만.. 엄청난 Composition을 해야할 것 같네요)3. 대부분 프론트엔드의 상태관리 기술 스택이 Redux를 사용하기 때문입니다.4. 테스트가 용이합니다.

예외,1. Redux는 상태관리에서의 장점은 이제 거의 없습니다. Redux를 사용해보시면 아시겠지만 결국 거의 모든 상태가 Redux의 Global store로 흘러들어갑니다. 이 때문에 Store, Reducer, Action이 난무하게 되버려 코드 가독성이 크게 나빠집니다. redux-toolkit이 나오기 전까진 보일러플레이트 때문에 리덕스를 안 쓰고 싶단 생각도 들었습니다.1.1. 모든 상태가 Redux store로 들어가게 된다고 가정하면 API Response도 저장해야 되는 경우도 있습니다. 이런 경우에는 대안도 많은데, Recoil, SWR등이 대세가 되고 API 캐싱까지 해결해주면서 Redux는 점점 그 이점을 잃어가고 있습니다.2. 종종 redux와 context를 비교하는데, Context는 비교 대상조차 되지 않습니다. Context는 단지 Prop Drilling을 해결하기 위한 것일 뿐입니다. 상태관리는 useState, useReducer로 합니다.