처음 만난 리덕스 (Redux) 문서


2.4 Redux vs Context API

지금까지 Redux를 사용해야 하는 경우들에 대해서 알아보았습니다.
하지만 그런 경우에 무조건 Redux를 사용해야 하는 것은 아닙니다.
다른 방식으로도 비슷한 문제를 해결할 수 있기 때문이죠.

대표적으로 Redux와 항상 비교되는 것이 바로 리액트에 내장되어 있는 Context API입니다.
지금부터 두 가지 방법의 차이점과 어떤 경우에 Redux를 사용해야 하는지 알아보도록 하겠습니다.

2.4.1 Context API

먼저 Context API는 2018년에 리액트 버전 16.3에 정식으로 포함되어 릴리즈 되었습니다.
Context는 리액트 컴포넌트들 사이에서 데이터를 기존의 props를 통해 전달하는 방식 대신 component tree를 통해 곧바로 컴포넌트로 전달하는 새로운 방식을 제공합니다.
이를 통해 어떤 컴포넌트든지 데이터에 쉽게 접근할 수 있습니다.

DOM Tree without Context API

조금 더 쉬운 이해를 위해서 이 그림을 한 번 보겠습니다.

이 그림은 props를 통해 상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달하는 일반적인 방식을 보여줍니다. 일반적으로 사용하는 방식이죠.
이 방식의 단점은 여러 컴포넌트에 걸쳐서 자주 사용되는 데이터(예: 로그인 여부, 프로필 정보 등)를 전달하려면 반복적인 코드가 많이 생기고 지저분해진다는 것입니다.

예를 들어, 위 그림에서 루트 노드에 있는 데이터를 C 컴포넌트로 전달하려면 최소 2번을 props로 전달해야 합니다.
만약 데이터를 전달하려는 컴포넌트가 10단계 밑에 있다면 10번이나 props를 타고 하위 컴포넌트로 내려가야 합니다.

그래서 이러한 불편한 점을 개선하기 위해 생겨난 것이 바로 Context입니다.

DOM Tree with Context API

이 그림은 방금 전과 동일한 기능을 구현하기 위해 Context를 사용한 것입니다.

Context를 사용하면 일일이 props로 전달할 필요 없이, 이 그림처럼 데이터를 필요로 하는 컴포넌트에 곧바로 데이터를 전달할 수 있습니다.
따라서 코드도 매우 깔끔해지고 데이터를 한곳에서 관리하기 때문에 디버깅을 하기에도 굉장히 유리합니다.

그렇다면 언제 Context를 사용해야 할까요?
Context는 여러 개의 컴포넌트들이 접근해야 하는 로그인 여부, 로그인 정보, UI 테마 등의 데이터에 사용하면 좋습니다.

여기까지만 보면 Context가 하는 역할과 용도는 Redux와 매우 유사합니다.
실제로 두 가지 기술 모두 앞에서 살펴본, 여러 단계에 걸쳐서 props를 통해 데이터를 전달하는 prop drilling이라고 불리는 문제를 해결하기 위한 방법입니다.

Context API and Redux

Redux나 Context API를 사용하면, 이렇게 데이터를 특정 계층에 있는 컴포넌트에 직접 전달할 수 있게 되는 것이죠.
그리고 내부적으로 Redux는 리액트 Context API를 사용하여 컴포넌트 Tree를 따라 스토어에 있는 데이터들을 전달합니다.
결국 알고보면 다 같은 민족(?)이라는 사실입니다.

2.4.2 Redux와 Context API의 차이점

그럼 결국은 같은 기술인데 Redux와 Context API의 차이점은 뭘까요?

첫 번째 차이점으로는 Redux를 사용하게 되면, 앞에서 설치했던 redux-devtools라는 강력한 도구를 사용할 수 있다는 것입니다.
redux-devtools는 모든 상태의 변화를 시각적으로 확인할 수 있게 해주며, 이전 상태로 돌아가서 하나씩 Action을 실행하면서 디버깅 할 수도 있습니다.
애플리케이션 규모가 커질수록 꼭 필요한 기능이죠.

그리고 두 번째 차이점은, Context API는 특정 Context에 의존하는 컴포넌트들을 분리시킬 수 있다는 점입니다.
여러 개의 Context를 만들고 해당 Context와 관련이 있는 컴포넌트들만을 묶어서 분리시킬 수 있다는 것이죠.
이렇게 분리를 시키면 해당 Context와 관련이 없는 컴포넌트는 애초에 데이터에 접근이 불가능해지기 때문에, 의도치 않게 발생할 수 있는 side effect를 사전에 방지할 수 있습니다.

Redux vs Context

그리고 마지막 Redux와 Context의 가장 큰 차이점은 데이터를 처리하는 방식입니다.

Redux는 전체 애플리케이션의 데이터를 Redux Store라고 불리는 하나의 거대한 객체로 관리합니다.
그리고 사전에 정의된 Action과 Reducer를 통해서만 상태를 변경할 수 있습니다.

반면에 Context는 오로지 하나로 구성되어 있지도 않을 뿐만 아니라, 데이터를 별도로 관리하지도 않습니다.
Context는 state를 들고 있는 것이 아니라 state를 전달하기 위한 통로의 역할만 하는 것이죠.
그리고 만약 Context API를 사용해서 state를 업데이트 하려면, 상위 컴포넌트의 state에 의존할 수밖에 없습니다.
상위 컴포넌트에서 state를 업데이트하고, 변경된 값을 Context라는 통로를 통해 하위 컴포넌트로 전달만 하는 것이죠.

그래서 결론적으로 Redux와 Context API 중에서 어떤 것을 사용해야 할까요?

이 질문에 정답은 없습니다.
다만, 앞에서 설명한 Redux와 Context API의 차이점에 대해서 잘 이해하고 각자 개발하려는 애플리케이션에 따라서 적합한 기술을 선택해서 사용하는 것이 중요합니다.
규모가 크고 관리해야 할 상태가 많다면 redux-devtools 등을 제공하는 Redux를 사용하는 것이 좋고, 규모가 작고 관리해야 할 상태가 몇개 없다면 Context API를 사용하는 것이 보편적으로 더 나은 선택일 수 있습니다.

또한 어떤 경우에는 Redux와 Context API 모두 사용할 필요가 없는 경우도 있고, 둘 다 함께 사용해야 할 경우도 있을 수 있습니다.
하지만 이 모든 것은 설계의 영역이기 때문에 정답은 없습니다.
그래서 여러분들이 각자 개발하려는 애플리케이션에 따라서 다양한 방법을 적용해보는 것이 중요합니다.


마지막 업데이트: 2023년 07월 14일 00시 00분

이 문서의 저작권은 이인제(소플)에 있습니다. 무단 전재와 무단 복제를 금합니다.