[짧은 회고] Redux를 배웠지만 사용하지 않았던 이유

유용하고 강력한 상태 관리 라이브러리임에도 불구하고 힘들여 배워 놓고 사실상 한번도 사용해 보지 못했다.
Redux는 자바스크립트 상태 관리 라이브러리로 다양한 데이터를 한곳에서 관리하고 여러 컴포넌트가 이를 구독함으로서 동작한다.
컴포넌트간 프롭으로 데이터를 전달하는 것과 달리 Redux에서는 데이터가 한방향으로 흐르게 되어 있다.

Redux의 세가지 원칙

1. Single source of truth

데이터는 Store에서 가져오며 스토어는 하나만 존재할 수 있다.
즉 데이터는 한곳에서 관리된다는 의미이다.

2. State is read-only

데이터는 읽는 것만 가능하며 변경을 위해서는 액션 객체를 이용해서 변경하는 것이 가능하다.

3. Changes are made with pure functions

상태 변경은 순수함수로만 가능하다.

Redux로 얻을 수 있는 장점

• 상태를 예측 가능한 상태로 만든다.
• 유지 보수가 용이하다.
• 디버깅이 쉽다.
• 테스트를 붙이기 쉽다.

action 객체를 이용해서 상태를 변경하므로 상태를 예측하기 쉽다.
데이터의 흐름이 정해져 있고 하나뿐인 스토어에서 데이터가 관리되고 있어 유지보수가 용이하다.
크롬 확장프로그램인 Redux dev tool을 이용해 디버깅이 용이하다.
순수함수를 이용하므로 테스트를 위한 코드를 붙이기 쉽다.

그럼에도 불구하고 여태 사용하지 않았던 이유

• Redux를 사용하기엔 프로젝트가 작았다.
  action객체를 만들고 reducer를 작성하고 초기 상태 값을 작성하기에는 프로젝트가 작아 효율적이지 못했다.
• Redux를 사용하기에는 역량이 부족했다.
  Redux는 다른 상태 관리 라이브러리와 비교했을 때 러닝커브가 높은 편에 속한다. 내가 사용할 수 있다고 해서 함께 프로젝트를 진행하는 팀원이 사용할 수 없다면 프로젝트를 무겁게 할 뿐인 쓸모 없는 라이브러리다. 나 역시 Redux를 갓 배운 상태에서 팀원을 가르쳐주며 작업을 진행하기엔 우리에겐 시간이 부족했다.

확실히 Recoil을 사용하면 빠르게 코드를 작성하고 금방 익숙해질 수 있었지만, 프로젝트가 진행되면서 계속 추가되는 수상한 상태값과 어디서 변경되고 사용되는지 찾기 어려워지는 문제를 겪을 수 밖에 없었다.

Recoil로 작성한 코드들을 개선해볼 기회가 온다면 Redux를 사용해본다면 좋을 것 같다는 생각을 한다.