Redux의 진짜 강점과 단점

Redux를 배우는 것은 쉽지 않다. 가파른 러닝 커브를 지닌 복잡한 툴이다. 하지만 이런 러닝커브를 극복하고 Redux를 사용했을때 과연 어떤 점이 편해지는 걸까? 단순히 React의 상태state를 관리해주는 도구일 뿐인걸까, 아니면 그 이상의 무언가가 있는걸까? Redux의 진짜 강점을 알아보자.

Redux로 무엇을 할 수 있을까?

(현재) React는 상태 관리(state management) 측면에서 부족하다. Redux는 그것을 보완해주기 위해 탄생한 도구이다. 우선, 상태 관리가 무엇을 의미하는지 짚고 넘어가자.

상태state가 무슨 의미인지 이해하기 어렵다면, 단순히 데이터data라고 생각하면 쉽다. 이 상태는 수시로 변경되며, 이 내용을 바탕으로 UI에 표현될 내용을 결정한다. 일반적으로 앱에서 데이터를 활용하는 방식은,

데이터를 가져오고(fetch) -> 저장하며(store) -> UI구현 -> 데이터 변경

의 형태이다.

서버로 부터 가져온 데이터를 표현하고 사용자 액션에 따라 적절히 업데이트 시켜주는 것. 사실 이 작업은 React로도 충분하다. 하지만 앱의 덩치가 점점 커지고 복잡해지면 이 데이터, 즉 앱의 상태를 관리해주는게 힘들어진다. 이를 해결해주는게 바로 Redux의 역할이다.

앱의 상태 관리

React는 작은 컴포넌트들도 나뉘어져 있다. 각각의 컴포넌트에서 필요한 데이터를 스스로 호출한다고 가정해보면, 컴포넌트 개수 이상의 API 호출이 일어날 것이다. 만약 A라는 컴포넌트와 B라는 컴포넌트에서 일부 중복되는 데이터를 쓰고 있더라도, A와 B의 상태는 서로 공유되지 않기 때문에 불필요한 호출을 시도해야 한다.

Redux를 사용하면 한번 호출된 데이터는 store에 저장된다. 마치 창고에 데이터를 적재해둔것과 같다. 컴포넌트들은 언제든 이 창고에 들려 필요한 데이터만 가지고 가면 된다. 굉장히 효율적이다. 또한, 단 하나의 진실의 근원(single source of truth)을 보장한다. 모든 컴포넌트는 동일한 데이터를 가져다 쓴다. 이렇게 하면 모든 UI가 일관된 내용을 유지할 수 있다.

사실 React만으로도 충분히 이 내용을 구현할 수 있다. 컨테이너 컴포넌트를 쓰면 된다.

부모 컴포넌트만 데이터를 가지고 있고, 그 하나의 데이터를 자식들에게 넘겨 주는 방식이다. 각 컴포넌트가 직접 데이터를 가져오는 것보다는 훨씬 효율적이다. 하지만 이 방식에도 단점은 있다. 부모가 가지고 있는 데이터를 자식이 아닌 손자, 그 손자의 손자 컴포넌트까지 전달하려면 수많은 컴포넌트들을 거쳐 가야 될 것이다. 거쳐가는 컴포넌트들에 이 데이터가 필요없는 경우에도, 목적지까지 전달되기 위해선 비효율적인 전달이 불가피하다.

만약 창고에 데이터가 있다면? Redux를 사용하면 어떤 컴포넌트에도 이 데이터를 곧바로 전달할 수 있다. 다른 컴포넌트들에게 끼치는 영향은 전혀 없다.

참고로 여기까지 설명한 역할을 해주는 context API가 최신 React(16.3)에서 소개되었다. Redux를 사용하는 이유가 단지 위의 역할 뿐이라면, 적용 해보는것을 고려해보자.

Redux의 진정한 강점

지금까지 살펴본것을 보면, Redux는 단순히 React를 조금 도와주는 것에 불과하다. 하지만 Redux의 강점은 지금부터다.

Redux는 몇가지 규칙을 아주 엄격하게 강제한다.

모든 데이터는 텍스트로 설명되어야 한다. 액션(데이터의 변경)도 마찬가지다. 뭔가 바꾸기 전에 무엇을 할건지 기록해두어야 한다. 이런 기록들을 남기지 않고서는 데이터를 변경할 수 없다. Redux의 액션은 디스패치에 의해 실행되고, 동일한 인자값은 항상 동일한 결과를 반환한다(순수함수). 이러한 규칙들을 지킨다면 Redux의 강점을 아래와 같이 확인할 수 있다.

1. 사용자가 어떤 액션을 했고, 어떤 데이터가 어떻게 변경되었는지 쉽게 관찰할 수 있다. 이 모든 내용은 기록되고, 개발자는 이전의 특정 상태로 돌아가볼 수 있다. 시간 여행이 가능해진 부분이다. 버그가 나기 이전 상태로 돌아가서 테스트해볼 수 있다.

2. 많은 사용자들이 동시에 다양한 작업을 하는 페이스북 같은 서비스에서 힘을 발휘한다. 다른 기기에서 다른 사용자들이 실행하는 액션을 받아 로컬의 작업과 병합해 보여준다.

3. 모든 데이터는 스토리지에 저장할 수 있다. 사용자는 브라우저를 종료하고 다시 들어와도 완전 동일한 시점부터 다시 진행할 수 있다.

Redux의 단점

마냥 좋아보이는 엄격한 규칙때문에 발생하는 단점도 있다.

1. 러닝커브 : React만 알아가는 것도 힘든데 Redux까지.. 이 개념을 이해하는데 상당히 오랜 시간이 소요되었다.

2. 결코 적지 않은 코드량 : 아주 작은 기능이라도 Redux로 구현하는 순간 몇개의 파일들을 "필수로" 만들어야 한다. 최소한의 코드로 기능을 구현한다는 건 별로 와닿지 않는다.

정리

Redux는 단순히 React의 상태를 관리해주는 도구가 아니다. 몇가지 매력적인 강점들을 알아보았다. Redux를 사용할지 말지 결정하는 것은 개발자 혹은 팀의 몫이다.

Redux를 만든 Dan Abramov의 You Might Not Need Redux라는 글을 읽어보자.

사실 굳이 Redux를 쓰지 않아도 되는 상황들이 분명 있다. 만들고자 하는 앱이 Redux를 사용했을때 개발 효율 및 사용성이 올라간다면, 추가적인 작업이 필요하겠지만 사용하는 것을 권장한다. 하지만 그렇지 않다면, Redux를 사용하지 않아도 전혀 문제될 것은 없다.