[FE] 상태관리란?

상태관리란?

[index]

1. 상태관리란?

2. 상태관리의 역사

3. 상태관리 라이브러리의 종류

---

1. 상태관리란?

 State Management

 상태 관리는 모던 프론트엔드의 핵심 역량 중 하나로 여겨지며, 효과적인 상태 관리는 개발자의 핵심 역량이 되었습니다. 프론트엔드 개발에서 상태 관리는 다양한 컴포넌트 간 데이터 전달과 이벤트 통신을 효과적으로 관리하는 것이 목표입니다.

상태의 정의

 프론트엔드에서 상태는 주로 유저 정보나 UI에 영향을 미치는 동적으로 변화하는 데이터를 말합니다. 또한 프론트엔드에서 상태는 눈에 보이는 UI 요소 뿐만 아니라 서버와의 통신을 통해 변하는 데이터를 포함합니다. 이를 관리하기 위해서는 예측 가능한 변화를 유지하고 상태의 일관성을 유지해야 합니다. React에서는 상태를 "Plain JavaScript Object hold information influences the output of render"로 정의하고 있습니다. 

 

상태 관리의 원칙

1. 단일 출처의 진리 (Single Source of Truth)
   어플리케이션의 상태는 하나의 특정 위치에서만 관리되어야 합니다. 이것은 다른 부분에서 상태의 중복을 방지하고, 코드의 일관성을 유지하는 데 도움이 됩니다.
2. 상태는 읽기 전용 (State is Read-Only)
   상태는 직접 수정되어서는 안 되며, 변경은 액션을 통해 이뤄져야 합니다. 이는 예측 가능하고 추적 가능한 상태 변화를 유지하며, 디버깅을 더 쉽게 만듭니다.
3. 변화는 순수 함수로 관리 (Changes are Made with Pure Functions)
   상태 변화는 순수 함수, 즉 이전 상태와 액션을 받아 새로운 상태를 반환하는 함수를 통해 이루어져야 합니다. 이는 부작용을 최소화하고 예측 가능한 동작을 유지하는 데 도움이 됩니다.

(위의 내용은 Redux에서 제시하고 있는 3가지 원칙입니다.)

 

상태 관리의 목표

1. 효과적인 UI 및 UX 설계
   상태를 기반으로 한 적절한 UI 및 UX를 설계하고 구현하는 것이 상태 관리의 주요 목표 중 하나입니다.
2. 네트워크 상호작용 관리
   서버로의 클라이언트 요청에 따라 변하는 상태를 효과적으로 관리하는 것이 필요합니다.
3. 예외 처리 및 에러 관리
   상태 관리를 통해 예외적인 상황에 대한 피드백을 제공하여 에러를 관리합니다.

 

상태관리의 필요성

1. 컴포넌트 간 데이터 공유
   프론트엔드 애플리케이션은 여러 컴포넌트로 구성되어 있으며, 이들 컴포넌트는 서로 다른 계층에 위치하거나 부모-자식 관계에 있을 수 있습니다. 상태 관리를 통해 컴포넌트 간에 데이터를 효과적으로 공유하고 전달하는 방법을 마련할 수 있습니다.
2. 전역 상태 관리
   어떤 데이터는 여러 컴포넌트에서 공통으로 사용되어야 할 때가 있습니다. 이런 경우, 전역 상태를 통해 모든 컴포넌트에서 접근하고 업데이트할 수 있습니다. 이를 통해 중복된 데이터를 방지하고 일관성을 유지할 수 있습니다.
3. UI 상태 관리
   사용자 인터페이스(UI)의 상태는 사용자와의 상호작용에 따라 동적으로 변경됩니다. 예를 들어, 모달의 열림 또는 닫힘, 폼 입력값 등이 여기에 해당합니다. UI 상태를 관리하여 어플리케이션의 시각적인 부분을 업데이트하고 사용자 경험을 제어할 수 있습니다.
4. 복잡한 비즈니스 로직 효율적으로 처리
   어플리케이션에는 종종 복잡한 비즈니스 로직이 내장되어 있습니다. 이러한 로직은 상태에 의존하거나 상태를 변경할 수 있습니다. 상태 관리를 통해 비즈니스 로직과 상태 간의 관계를 명확하게 유지하고 효율적으로 처리할 수 있습니다.
5. 데이터의 흐름 예측 및 관리
   상태를 통한 데이터 흐름은 예측 가능하고 추적 가능해야 합니다. 이는 버그를 예방하고 디버깅을 용이하게 만듭니다. 상태 관리를 통해 데이터가 언제, 어떻게 변경되는지를 효과적으로 추적할 수 있습니다.
6. 컴포넌트의 독립성 유지
   각 컴포넌트는 자체적으로 상태를 관리하는 것이 이상적입니다. 이를 통해 각 컴포넌트는 독립적으로 작동하며, 재사용성이 높아지고 유지보수가 쉬워집니다.

 

상태 관리를 통해 이러한 측면들을 고려하고 처리함으로써 애플리케이션의 확장성, 유지보수성, 그리고 사용자 경험을 향상시킬 수 있습니다. 상태 관리 라이브러리나 프레임워크를 사용하여 이러한 목표를 달성하는 데 도움을 받을 수 있습니다. 상태를 효과적으로 관리함으로써 어플리케이션의 개발 및 유지보수가 더욱 원활해집니다.

 

 

2. 상태관리의 역사

과거의 상태 관리

jQuery 시대

• jQuery와 ES6 이전에는 상태를 유지하기 위해 주로 jQuery를 사용했습니다.
• jQuery의 data()나 HTML5의 data- 속성을 활용하여 상태를 유지했으며, 이는 DOM을 그릇으로 삼아 상태를 관리하는 방식이었습니다.

문제점

1. 상태에 대한 접근성이 낮음
   • DOM에 상태를 저장하고 있어서 상태를 다루려면 직접 DOM에 접근해야 했습니다.
   • 상태를 사용하기 위해서는 어떤 DOM에 상태를 저장했는지 추적해야 했습니다.
2. 상태의 파편화
   • 상태가 여러 DOM에 흩어져 있어서 상태 변화 추적이 어려웠습니다.
   • 여러 DOM 관련 상태 변화 로직에 대한 디버깅이 어려웠습니다.

 

현대의 상태 관리

프레임워크 등장 (AngularJS, React, Vue, Svelte)

• AngularJS의 등장으로 상태는 DOM에서 탈출하고, JavaScript에서 상태를 관리할 수 있게 되었습니다.
• React, Vue, Svelte와 같은 프레임워크 등장으로 상태 관리가 데이터 중심으로 발전했습니다.

라이브러리 등장 (Redux, React-Query, SWR)

• Redux, React-Query, SWR 등의 라이브러리 등장으로 상태를 효과적으로 관리할 수 있게 되었습니다.
• 전역 상태를 효율적으로 관리하고 Props drilling 문제를 해결했습니다.

문제점

• 데이터 실시간 관리 및 서버리스 환경에 대한 새로운 요구사항이 등장했습니다.

 

앞으로의 상태 관리

실시간 & 앱

• 더욱 더 실시간에 가까워지면서 상태를 빠르고 효율적으로 관리해야 합니다.
• PWA와 같이 웹과 앱의 경계가 허물어지며 상태 관리가 고도화됩니다.

서버리스(serverless)

• 서버리스 개념이 강조되면서 프론트엔드가 클라우드를 통해 서버 없이 작업하는 환경이 발전하게 될 것입니다.
• 서버리스 어플리케이션은 이벤트 드리븐하고, 상태 관리에 집중할 수 있는 환경 제공합니다.

SWR (stale-while-revalidate) 컨셉

• 데이터를 필요한 시점에서 캐시하고, 주기적으로 revalidate하여 out-of-date 문제를 해결합니다.

전역 상태의 필요성

• 전역 상태는 여전히 필요하며, 컴포넌트 트리 외부에서 노출되는 UI에 필요합니다.

앞으로는 더욱 더 실시간에 초점을 맞추고, 서버리스 환경에서 데이터를 효율적으로 관리하는 방식이 발전할 것으로 예측됩니다. SWR 컨셉과 전역 상태의 조화로 상태를 효과적으로 관리하는 것이 중요해질 것입니다.

 

 

3. 상태관리 라이브러리의 종류

1. Redux

Motivation | Redux

Redux는 상태 관리 라이브러리 중 가장 초기에 등장한 것으로, 중앙 집중식 Storage와 Reducer를 사용하여 상태 업데이트를 관리합니다. 이는 단방향 데이터 흐름을 따릅니다.

 

특징

1. 전역 상태 관리
    Redux는 상태를 전역적으로 관리하여 어느 컴포넌트에 상태를 두어야 할지 고민을 줄입니다.
2. 단방향 데이터 흐름
    데이터 흐름이 단방향으로 흐르도록 하여 예측 가능한 상태 업데이트를 제공합니다.
3. 불변성 유지
    불변성 유지가 중요하며, Immutable.js 등의 라이브러리가 사용될 수 있습니다.
4. Flux 아키텍처 준수
    Flux 아키텍처를 따르며, 미들웨어(예: redux-thunk, redux-saga)를 사용하여 dispatch 관리가 필요합니다.

장점

1. 탄탄한 커뮤니티
    오랜 역사로 인해 커뮤니티와 개발자 풀이 탄탄합니다.
2. 다양한 보일러플레이트
    다양한 보일러플레이트가 존재하며, 버그 해결이 비교적 용이합니다.
3. 테스트 용이성
    단방향 데이터 흐름으로 인해 Reducer 등의 단위 테스트가 쉽게 구현 가능합니다.

단점

1. 구조의 복잡성
    작은 웹 앱조차도 Action, Reducer, Action Creator 등의 코드를 작성해야 하므로 구조가 복잡해집니다.
2. 러닝 커브의 높음
    Redux는 처음에는 러닝 커브가 높게 느껴질 수 있습니다.
3. 반응형 메커니즘이 부족
    Redux는 State가 변경될 때 Component를 업데이트하는 반응형 메커니즘이 내장되어 있지 않아 외부 라이브러리나 React의 메커니즘을 사용해야 합니다.

 

2. MobX

About MobX · MobX 🇺🇦

MobX는 Redux와 유사한 상태 관리 라이브러리이지만 Redux보다 간결하고 객체 지향적인 구조를 가진다는 특징이 있습니다. MobX는 상태 변화를 자동으로 추적해주는 것이 가장 큰 특징으로, React에 종속적이지 않으며 Redux와는 다르게 제한 없이 여러 개의 store를 사용할 수 있습니다.

 

특징

1. React에 종속성 없음
    React에 종속적이지 않고, Redux와는 다르게 store에 제한이 없습니다.
2. 자동 추적
    모든 상태 변화가 자동으로 추적되어 리액트 컴포넌트를 업데이트합니다.
3. 객체 지향적
   객체 지향적이며, JAVA Spring과 유사한 아키텍처를 제공하여 서버 개발자들에게 친숙합니다.
4. Decorator 사용
    Redux의 보일러플레이트 코드 대신 데코레이터를 사용하여 깔끔한 코드 작성이 가능합니다.
5. 캡슐화
    Mobx Config 설정을 통해 State를 메서드를 통해서만 변경할 수 있도록 캡슐화가 가능합니다.
6. 불변성 유지 불필요
    Redux에서처럼 불변성을 유지하기 위한 노력이 필요하지 않습니다.

장점

1. 쉬운 러닝 커브
    전반적으로 Redux에 비해 쉬운 러닝커브를 가지고 있으며, 객체 지향적이고 캡슐화를 지원하기에 개발자 친화적입니다.
2. 반응형 메커니즘 제공
    Redux에서 제공하지 않는 반응형 메커니즘을 통해 동적 웹 앱을 쉽게 개발할 수 있습니다.

단점

1. 디버깅 어려움
    웹 앱 규모가 커지면서 로직이 MobX의 자동 업데이트에 의존하게 되어 디버깅이 어려워질 수 있습니다.
2. 커뮤니티 규모
    Redux에 비해 커뮤니티 규모가 작고, Validation 구현 시 코드가 번잡할 수 있습니다.

MobX는 상대적으로 쉬운 러닝커브와 반응형 메커니즘을 통해 간결한 코드 작성을 제공하지만, 큰 규모의 웹 앱에서는 디버깅이 어려울 수 있고, 커뮤니티 규모가 작다는 한계를 가지고 있습니다.

 

3. Recoil

Recoil

Recoil은 비교적 최근에 나온 상태 관리 라이브러리로, Facebook에서 개발했으며 React에 가장 적합한 상태 관리 철학을 가지고 있습니다. Recoil은 React의 내장 상태 관리 기능과 관련된 고통을 줄이는 것을 목표로 하며, 2020년 중반에 릴리스되었습니다. Recoil은 Reactive 메커니즘을 탑재하고 있어 동적인 기능을 쉽게 구현할 수 있습니다. Recoil은 context API를 기반으로 하며, 함수형 컴포넌트에서만 사용 가능합니다.

 

특징

1. 비동기 처리 및 동시성 모드
    비동기 처리를 기반으로 하여 동시성 모드를 제공하므로, 다른 비동기 처리 라이브러리에 의존할 필요가 없습니다.
2. 간결한 상태 관리
    Atom과 Selector를 통한 간결한 상태 관리를 지향하며, 코드 분할이 증분 및 분산되어 가능합니다.
3. 쉬운 러닝커브
    Atom과 Selector만으로도 구현이 가능하고, 러닝커브가 낮아 초심자가 사용하기에도 적합합니다.

장점

1. 간단한 구조
    Redux, MobX에 비해 더 간단한 구조를 가지고 있어 초심자가 시작하기에 적합하며, 보일러 플레이트가 필요하지 않습니다.
2. 세밀한 제어
    Recoil을 사용하면 컴포넌트의 렌더링 시기, 상태 등을 세밀하게 제어할 수 있어 성능 최적화에 활용 가능합니다.
3. Reactive Mechanism
    Reactive 메커니즘을 통해 동적인 기능을 쉽게 구현할 수 있습니다.

단점

1. 커뮤니티 부족
    최신 라이브러리로서 커뮤니티 규모가 작아 사용자가 혼자 문제를 해결해야 하는 경우가 있습니다.
2. 디버깅 및 테스트 어려움
    Recoil의 세분화된 상태 관리가 초심자에게는 디버깅이나 테스트가 어려울 수 있습니다.

Recoil은 React에 가까운 라이브러리로서 간단한 구조와 세밀한 제어를 제공합니다. 그러나 아직은 커뮤니티의 부족과 초심자에게는 디버깅이나 테스트가 어려울 수 있는 단점이 있습니다.

 

 

 

---

참고 문서

https://ui.toast.com/weekly-pick/ko_20210707

React 상태 관리 기술 소개 2021 ⚜️🌐

https://blog.toktokhan.dev/react-%EC%83%81%ED%83%9C%EA%B4%80%EB%A6%AC-%EC%B5%9C%EA%B0%95%EC%9E%90%EB%8A%94-f0753ad7d186

React 상태관리 최강자는?

https://ykss.netlify.app/react/redux_mobx_recoil/

Redux vs Mobx vs Recoil