[프론트엔드] 상태관리 (1) - 상태/상태관리 개념, 상태관리 역사와 방법론

요약

1. 상태
  - 사용자에게 노출시키고 상호작용하기 위한 데이터와 눈에 보이지 않지만 서버와 주고받는 데이터까지 모두 포함하여 상태라고 부릅니다.

2. 상태 관리
  - 상태를 정의, 유지하고 변화를 주고, 외부에 상태를 반영하는 것을 의미합니다.

3. 상태관리가 필요한 이유
  - 상태들이 복잡하게 얽혀있다면, 상호간에 의존성이 많아지게 되어 UI가 어떻게 변하는지 알기 어려울 수 있기에 효율적으로 관리해야 함.

4. 평소 상태관리는 어떻게 하는지?
  - 특정 컴포넌트에서만 사용하는 상태는 useState 를 사용하여 로컬 상태로 관리하고, 여러 컴포넌트에서 사용하는 상태는 Redux-toolkit 등 전역 상태관리 툴을 이용하여 전역 상태로 관리합니다.

 

상태(State)

• 사용자에게 노출시키고 상호작용하기 위한 데이터와 눈에 보이지 않지만 서버와 주고받는 데이터까지 모두 포함하여 상태라고 부릅니다.
• 특정 컴포넌트안에서 관리되는 로컬 상태와 여러 컴포넌트에서 관리되는 전역 상태로 구분지을 수 있습니다.

 

상태관리(State Management)

상태를 정의, 유지하고 변화를 주고, 외부에 상태를 반영하는 것을 의미합니다.

 

 

상태관리가 필요한 이유

• 상태가 너무 복잡하기 때문입니다.
• 상태는 각각의 뷰에서, 때로는 뷰와 상관없이 필요에 의해서, 실시간, 비동기로 계속해서 변화합니다. 결국, 상태가 언제, 어떻게, 왜 변화했는지 제어할 수 없는 상황에 이를 수 있습니다. 상태들이 복잡하게 얽혀있다면, 상호간에 의존성이 많아지게 되어 UI가 어떻게 변하는지 알기 어려울 수 있기에 효율적으로 관리해야 합니다.
• 컴포넌트는 각각 다르지만, 사용하는 데이터가 연결되어있는 경우가 많습니다. 컴포넌트간에 통신을 하거나 상호간에 데이터 전달을 자연스럽게 하는게 대두되어서 상태관리의 중요성이 높아집니다.

 

상태관리의 역사

과거의 상태관리

 - 과거 ES6이전 시대에도 상태는 당연히 필요했습니다. 이 시기에도 이미 Ajax가 구현되어 비동기적으로 동적화면을 구성하던 시기였습니다.

 

- 단순히 전역객체를 사용하여 데이터를 관리할 수도 있었지만 전역상태를 오염시킬 수 있었고, 상태를 필요로 하는 요소만 직접 관리하고 싶었기에 사용한 방식이 HTML의 data 속성입니다. 상태가 필요한 태그의 data속성에 상태를 넣음으로써 해당 요소에만 접근하여 상태를 관리할 수 있었습니다. 

 

 

 하지만 위 방식은 크게 두 가지 문제점으로 복잡성을 키웠습니다.

 

 

 

 - 첫째, 상태에 대한 접근성이 떨어집니다. DOM에 상태를 저장하고 있으므로, 상태를 관리하기 위해서는 DOM에 직접 접근을 해야합니다. 이를 위해 DOM에 접근하는 코드가 반드시 필요합니다. 결과적으로 상태가아니라 DOM 요소를 중심으로 코드가 작성됩니다. 이는 상태에 대한 접근성을 떨어트리고 복잡성을 키우게 됩니다.

 

 - 둘째, 상태변화 추적이 어렵습니다. 상태는 여러 요소에 흩어져있는데 만일 api를 호출하여 업데이트 하는 중 상태가 변경된다면 상태가 올바르게 변경될지도 미지수이고, 버그 발생시 어디서 문제가 생겼는지 추적하기도 어렵습니다. 이는 코드의 유지보수와 확장을 어렵게하는 대표적인 문제 중 하나입니다.

 

 

현대의 상태관리

스마트폰이  2007년 초부터 확산되며, 웹의 활동 무대는 더 이상 PC에 한정되지 않게 되었습니다.수많은 웹이 스마트폰 위에서 돌아가기 시작했습니다. 스마트폰을 통해 웹은 이전보다 압도적으로 많은 사용자를 상대할 수 있었습니다.

 

웹은 이러한 요구에 발맞추어 웹앱이라고 부르는 복잡하고 정교한 웹으로 거듭나야 할 수밖에 없었습니다. 이전에 비해 코드량도 폭발적으로 증가하죠.

 

매우 강력한 기능들로 무장해 높은 사용자 경험(UX)을 선사해야 하는 웹앱의 상태관리는 이전과 비교할 수 없을 정도로 복잡해질 수밖에 없었습니다. 이젠 웹앱 환경에서 더 이상 jQuery의 상태관리로는 효과적인 개발과 확장, 유지보수를 보장할 수 없었습니다.

 

또한, SPA(Single Page Application)에 대한 요구도 있었습니다. 상태관리에 따른 잦은 페이지 새로고침은 모바일 환경에서 나쁜 사용자 경험을 주었습니다. 이에 AngularJS가 등장하고, 뒤이어 React, Vue, Svelte 등의 프레임워크, 라이브러리가 등장합니다. 

 

이후 Flux 패턴을 기반으로 Redux 라는 전역 상태관리 라이브러리가 등장합니다. Flux 패턴은 React 를 만든 페이스북이 2014년 개발자 컨퍼런스에서 발표했는데, Flux 패턴을 만든 이유는 대규모 어플리케이션에서 데이터 관리를 일관된 방식으로 하기 위함이었습니다. 

 

Flux 패턴은 양방향 데이터 프름이 아닌 단방향 데이터 흐름을 가지도록 변경했습니다. 데이터 흐름이 한 방향으로 강제되고, 모든 상태가 스토어에 모여 있어서 변경 사항을 컴포넌트에 전달하기도 쉬워졌습니다. 

 

 

 

평소 State 관리 방법

• 특정 컴포넌트에서만 사용하는 상태는 useState 를 사용하여 로컬 상태로 관리합니다.
• 여러 컴포넌트에서 사용하는 상태는 Redux-toolkit 등 전역 상태관리 툴을 이용하여 전역 상태로 관리합니다.

 

 

 

 

 

참고

 

[FE] 프론트엔드에서의 상태관리란 무엇인가? (1) 등장배경과 정의

<FE> 프론트엔드 상태 관리와 역사

프론트엔드 개발에서의 상태 관리

프론트엔드 상태관리의 역사 - (1)

[YOUTUBE] TECH CONCERT: FRONT END 2019 - 데이터 상태관리. 그것을 알려주마