Redux와 Recoil : 실례지만 어데 Re씹니꺼?

RIP Cheems

전역 상태 관리 라이브러리의 필요성

별도의 상태 관리 라이브러리 없이 state를 사용할 때 발생할 수 있는 몇 가지 문제가 있습니다.

• props drilling으로 인한 관심사 분리 불가능, 성능 저하 문제
  • props drilling은 상위 컴포넌트로부터 하위 컴포넌트로 상태를 전달하고자 할 때, 직접적으로 전달할 수 없으므로 두 컴포넌트 사이의 여러 컴포넌트를 거쳐 전달할 때 발생합니다.
  • 이러한 방식으로 상태를 전달할 경우, 상태가 업데이트 될 때 실제로 리렌더링 되어야 하는 컴포넌트 이외에도 단순히 전달 목적으로만 관여한 컴포넌트 또한 리렌더링이 되게 됩니다. 이는 성능 저하를 유발합니다. (물론 React의 memo 기능을 사용하면 방지할 수 있는 부분입니다.)
  • 또한, 컴포넌트가 ‘단순히 하위 컴포넌트에 전달할 용도로’ 상태를 갖고 있는 것 자체가 직관적이지 못합니다. 각각의 컴포넌트가 필요한 기능만을 가지고 있으면 한 눈에 봐도 ‘아, 이 컴포넌트는 이러이러한 기능을 하는구나’ 라고 판단할 수 있겠죠? 하지만 이 컴포넌트가 그저 전달하는 것 이외에 어떤 목적도 없는 상태를 가지고 있으면 어떨까요? 컴퓨터 프로그래밍의 디자인 원칙 중 관심사 분리의 원칙이 있습니다. 하나의 컴포넌트(혹은 함수, 파일)가 본연의 기능과 역할만 수행할 수 있도록 하는 것 또한 관심사 분리의 일환입니다. 이러한 관심사 분리가 제대로 이루어지지 않으면, 코드를 읽는 입장에서는 이 컴포넌트가 어떤 역할을 하는지 직관적으로 파악하기 어렵습니다. 상기에 예로 든 경우에도, 특정 컴포넌트가 어떤 역할을 하는지 알고 싶은데 해당 컴포넌트의 주 역할과 직접적으로 관련이 없는 상태를 가지고 있다면 역할을 제대로 파악하기 어려울 것입니다.
    
• 복잡한 상태 로직 처리의 어려움
  • React에서 상태를 관리하는 가장 기본적인 방법인 useState는 단순한 상태를 처리하기에는 적합하지만, 애플리케이션의 구조가 복잡해지면 상태 로직을 처리하기 어려워집니다. 예를 들어, 상태가 다른 상태에 의존하는 경우가 있으면 이러한 종속성을 추적하고 관리하기가 어려울 수 있습니다.
  • 또한, 이렇게 복잡한 구조의 애플리케이션에 대해 일반적인 상태 관리 방식으로 접근하는 것은 애플리케이션 내에서 컴포넌트 간 결합도를 높일 수 있습니다.
    컴포넌트 간 결합도란, 하나의 컴포넌트가 다른 컴포넌트에 종속되어있는 정도를 말합니다. 결합도가 높은 컴포넌트는 변경이 발생할 시 다른 컴포넌트에도 영향을 주기 쉽습니다. 이렇게 결합도가 높은(=종속성이 높은) 컴포넌트는 코드를 수정할 때에 다른 컴포넌트에 미치는 영향까지 고려해야 하고, 여러 컴포넌트와 결합되어 있을 경우 해당 컴포넌트의 코드까지 일일히 수정해주어야 하므로 유지보수성이 떨어집니다.
• 상태 공유의 어려움
  • useState는 하나의 컴포넌트에서 단독적으로 사용되는 지역 상태를 다루기에 적합합니다. 그러나 동일한 방법으로 여러 컴포넌트에서 공유해야 하는 전역 상태를 다뤄야 하는 경우를 생각해봅시다. 예를 들어 볼까요? 한 컴포넌트에서 로그인 상태를 관리하고 있을 때, 다른 컴포넌트에서도 로그인 상태를 관리하려면,

    • 해당 상태를 부모 컴포넌트로 전달하고

    • 다시 props로 자식 컴포넌트에 전달하는 방식을 취해야 합니다.

      이러한 방식은 컴포넌트가 서로 의존하도록 만들어 재사용하기 어려워지고, 코드를 복잡하게 하여 가독성이 떨어집니다.

앞서 말한 props drilling, 복잡한 상태 로직 처리, 상태 공유의 어려움과 같은 문제를 해결하기 위해 상태 관리 라이브러리를 사용할 수 있습니다. 상태 관리 라이브러리에는 대표적으로 Redux, MobX, Recoil, jotai, zustand 등이 있습니다.

Redux

상태 관리 라이브러리 중 우리가 학습한 Redux에 대해서 복기해봅시다. Redux는 Store라는 일종의 저장소를 만들고, UI 내에서 발생한 Action을 Reducer로 전달한 후 Action의 종류에 따라 알맞은 방식으로 상태를 업데이트 합니다. 이렇듯 특정 컴포넌트 내에서 로컬로 상태를 관리하는 대신 별도의 공간에서 관리하는 방식은, 기존처럼 복잡한 상태 전달 구조가 없이 필요한 컴포넌트에서 useSelector로 상태를 불러오는 것 만으로 해당 상태를 활용할 수 있습니다.

Redux는 불변성immutability을 유지하는 상태 업데이트를 강제합니다. 이는 상태 변화를 추적하기 쉽게 만들고, 디버깅을 용이하게 해줍니다. 또한 중앙 집중화된 상태 관리를 제공하므로, 컴포넌트 간 데이터 흐름을 예측 가능하게 만들어주며, 상태 업데이트 로직을 표준화하여 유지보수성을 높입니다.

Redux의 단점

Redux, Mobx 등의 대표적인 상태 관리 라이브러리의 성능 자체에 문제가 있는 것은 아닙니다. 오히려, 페이스북에서 고안한 Flux 패턴을 기반으로 설계되어 안정적인 전역 상태 관리가 가능했습니다.

그럼에도 불구하고 Redux의 사용도와 만족도가 감소하게 된 요인은 다음과 같습니다.

• React 전용 라이브러리가 아니다 : React 관점에서는 Store가 외부 요인으로 취급되어, 동시성 모드를 구현하기가 어렵다는 단점이 있습니다.
• 복잡한 보일러 플레이트 초기 세팅이 필요하다 : Store, Action, Reducer 등 다양한 구성요소가 필요합니다. Redux 환경을 설정할 때, 세 개 요소를 위해 각각의 디렉토리와 파일을 생성하는 과정을 경험해보신 적이 있을 겁니다. 이러한 일련의 과정을 보일러 플레이트 초기 세팅이라고 합니다.
• 비동기 데이터에 추가 리소스가 요구된다 : Redux-thunk, Redux-saga 등 전역 상태에 비동기 데이터를 호출하기 위한 서드 파티 라이브러리를 요구합니다.

Recoil그게 뭔데 그게 어떻게 하는건데

상기한 Redux의 단점을 보완한, React에 좀 더 최적화된 전역 상태 관리 라이브러리인 Recoil을 소개합니다.

Recoil은 우선 React 전용 라이브러리인 만큼 React 내부 접근성이 높으며, React 동시성 모드, Suspense 등을 지원하기 때문에 사용자 경험 관점에서도 매우 유리합니다. 또한 전역 상태의 설정이 편리하며, Recoil이 지원하는 React Hooks로 상태를 get/set 하기 때문에 React 문법과 유사하여 사용법을 익히기도 쉽습니다.

Recoil 공식 문서에서 정리하는 Recoil의 장점은 다음과 같습니다.

• 공유 상태도 내부 상태처럼 간단한 인터페이스로 사용 가능 (Boilerplate-free)
• 동시성 모드를 비롯한 다른 새로운 React 기능과의 높은 호환성
• 상태 정의가 증분 및 분산되므로 코드 분할이 가능
  • Recoil은 앱에 필요한 모든 상태를 중앙 집중적으로 관리합니다. 이는 앱의 모든 컴포넌트에서 공유될 수 있으므로, 컴포넌트간에 상태를 전달하거나 업데이트하는 로직을 작성할 필요가 없습니다.
  • Recoil에서 상태는 Atoms라고 불리는 작은 단위로 분할됩니다. 이러한 Atoms는 각각 독립적으로 캡슐화되어 있으므로, 다른 Atoms와 완전히 별개로 존재할 수 있습니다. 이는 코드의 분할을 가능하게끔 합니다.
  • 예를 들어, 이전의 예시처럼 앱의 여러 컴포넌트에서 공유해야 하는 ‘로그인 여부’ 상태가 있다고 합시다. 이 상태는 Recoil Atoms로 분리하여 중앙 집중적으로 관리할 수 있습니다. 이러한 상태 분할은 앱이 커질수록 코드의 복잡성을 낮춰줍니다. 또한, 다른 Atoms와 별개로 존재하기 때문에 코드 분할과 같은 기술을 사용하여 필요한 상태만을 로드하고 나머지는 나중에 로드하는 등 편리하게 사용할 수 있습니다.
• 상태를 사용하는 컴포넌트에서 수정할 필요 없이 상태에서 파생된 데이터를 사용 가능하다. 또한, 파생된 데이터는 동기/비동기 모두 활용 가능하다.텍스트
  • Recoil에서는 Selectors라는 개념을 사용하여 상태에서 파생된 데이터를 생성할 수 있습니다. 이렇게 만들어진 데이터는 상태를 직접 수정하지 않아도 되고, 컴포넌트에서 간단하게 사용할 수 있습니다.
  • Selector는 상태를 인자로 받아 계산된 값을 반환하는 함수입니다. 이 계산된 값을 사용하는 컴포넌트에서는 Selector 함수를 호출하여 값을 얻을 수 있습니다. 이 때 Selector 함수가 반환하는 값은 상태와 마찬가지로 Recoil Atoms로 캡슐화되어 있으므로, 이 값이 변경되면 이를 구독subscribe하고 있는 컴포넌트들에게 알려져서 업데이트가 됩니다.
  • Selectors는 동기적으로 값을 계산할 수 있고, 비동기적으로도 값을 계산할 수 있습니다. 예를 들어, 비동기적으로 데이터를 불러와서 처리해야 하는 경우에도 Selector 함수를 사용하면 비동기적으로 데이터를 가져와 계산한 후 이를 사용하는 컴포넌트에서 값을 호출할 수 있습니다.
  • 이러한 기능을 활용하면 상태를 직접적으로 변경하지 않고도 상태에서 파생된 데이터를 사용할 수 있으므로, 앱의 코드를 더욱 단순화하고 유지보수하기 쉽게 만들 수 있습니다.

Atoms를 분산시키는 Recoil의 모습 (상상도)

그럼 Recoil이 Redux보다 무조건 더 좋다는 거야?

물론 그런 것은 아닙니다. (어디 가서 그렇게 말하면 누가 화낼수도 있어요!) 서로 다른 특성을 가지고 있는 라이브러리이기 때문에, 각각의 특징을 고려하여 적재적소에 사용할 필요가 있습니다.

Redux는 이미 많은 사용자와 생태계를 갖춘 성숙한 라이브러리입니다. 따라서 Redux는 많은 사용자들에게 익숙하고, 풍부한 리소스와 지원이 제공됩니다. 반면 Recoil은 최근에 출시된 비교적 새로운 라이브러리로, Redux에 비해 아직 상대적으로 적은 수의 사용자와 생태계를 가지고 있습니다.

또한, 상태 업데이트 방식에서도 두 라이브러리는 차이를 보입니다. Recoil은 React Hooks를 사용하여 상태를 업데이트합니다. 이는 간편하게 상태를 업데이트할 수 있다는 장점이 있지만, Redux처럼 불변성을 강제하지 않기 때문에 상대적으로 상태 변화에 따른 데이터 흐름을 추적하기 어려울 수 있으며, 이에 따라 디버깅에도 어려움이 생길 수 있습니다.

이에 더해, Recoil은 Redux와는 다르게 미들웨어를 지원하지 않습니다. 미들웨어는 비동기 처리, 로깅, 라우팅 등 다양한 고급 상태 관리 기능을 추가하는 데 사용됩니다. Recoil은 이러한 미들웨어 기능을 제공하지 않기 때문에, 여러 고급 기능을 요구하는 더 복잡한 애플리케이션을 구현할 때에는 Redux에 비해 사용성이 떨어질 수 있습니다.

즉, 앞서 말한 각 라이브러리의 장단점을 따져 볼 때, Recoil은 구조가 복잡하지 않은 소규모의 프로젝트에 더 적합하고, Redux는 고급 기능과 높은 확장성, 쉬운 유지보수를 요구하는 대규모의 프로젝트에 더 적합하다고 볼 수 있겠습니다.

어떤 라이브러리나 프레임워크가 무조건 우월하다거나, 무조건 열등하다는 생각은 자칫 위험할 수 있습니다. 특정 환경에서는 옳은 판단일 수 있지만, 각각의 라이브러리나 프레임워크가 가지는 특성이 상이하기에 상황과 목적에 따라 유연하게 사용하는 것 또한 개발자로서 중요한 역량이라 할 수 있습니다. 여러 라이브러리를 다양하게 사용해보고, 어디에 써야할 지 생각해보면 좋을 것 같습니다.

수정이 필요한 부분이 있거나, 다른 의견이 있으시면 말씀해주세요!