diff --git "a/5\354\236\245/\352\271\200\353\217\231\352\267\234.md" "b/5\354\236\245/\352\271\200\353\217\231\352\267\234.md"
new file mode 100644
index 0000000..4fdcf86
--- /dev/null
+++ "b/5\354\236\245/\352\271\200\353\217\231\352\267\234.md"
@@ -0,0 +1,83 @@
+# 5장 리액트와 상태 관리 라이브러리
+
+## 5.1 상태 관리는 왜 필요한가?
+
+상태는 어떠한 의미를 지닌 값이며 애플리케이션의 시나리오에 따라 지속적으로 변경될 수 있는 값을 의미한다. 대표적으로 아래와 같은 값이다.
+
+- UI, URL, Form, 서버에서 가져온 값
+
+```생각 & 의견
+왜 데이터들을 꼭 State(상태)라고 부를까 GPT 형님한테 물어보니, "시스템이나 애플리케이션의 현재 상황"을 나타내기 때문에 상태라고 부른다고 합니다.
+
+프론트엔드 개발을 하면 이런 상태관리가 (얕은 시야로 보기에..)백엔드보다 많이 난이도가 높아 보이는데, 유저의 인터렉션이라는 개발로 정의되지 않은 변수도 상태값으로 편입되기 때문에 어려운게 아닐까 생각이 드네요!
+```
+
+### 5.1.1 React 상태관리 역사
+
+#### Flux 패턴의 등장
+
+양방향 데이터 바인딩의 문제점을 Action -> Dispatcher -> Model -> View 의 단방향흐름으로 데이터를 제어 하는 것
+
+```생각 & 의견
+실제로 Vue에서는 React와 다르게 양방향 바인딩을 지원하고 있어 자주 사용했습니다.
+Flux 패턴이 등장한 이유 처럼 소프트웨어가 복잡해지면 데이터 흐름을 찾아가기 어려운 문제가 확실하게 있으나, 책에서 언급된 코드의 양이 줄어든다와 간단한 규모에서는 상당히 편리합니다!
+
+ex) 모달 open, close 제어 등..
+```
+
+#### 시장의 지배자 Redux
+
+- 기존의 많은 문제를 해결했다.
+- Elm 아키텍처의 영향을 받았다.
+- 보일러플레이트 코드가 너무 많아서 비판을 많이 받았다.
+
+```생각 & 의견
+Redux의 문제를 해결하기 위해, Redux Toolkit(https://redux-toolkit.js.org/)이라는 것도 출시 되었습니다.
+```
+
+#### Context API와 useContext
+
+Props를 간편하게 넘겨주기 위해 16.3 버전에서 Context API 출시 다만 아래와 같은 문제점이 있었다.
+
+- 상위 컴포넌트가 렌더링 되면 `shouldComponentUpdate`가 항상 `true`를 반환하여 불필요한 렌더링이 일어난다.
+- context를 인수로 받기 때문에 컴포넌트와 결합도가 높다.
+- 렌더링을 막아주는 기능이 없다.
+
+```생각 & 의견
+context가 아니더라도 상태관리를 해주는 무언가를 사용한다면 결합도가 없을 수가 없지 않을까...
+```
+
+## 5.2 리액트 훅으로 시작하는 상태 관리
+
+### 5.2.1 useState와 useReducer
+
+지역적인 상태관리 방법. 컴포넌트 재 랜더링으로 인한 초기화를 피하고 싶다면 부모 컴포넌트에서 상속받자.
+
+### 5.2.2 useState 상태를 바깥으로 분리하기
+
+리액트 렌더링 원리에 의해 컴포넌트 외부로 값을 빼더라도 "리 렌더링" 트리거를 넣어줘야한다.
+
+- useEffect 혹은 useState/useReducer의 두번째 인자 등..
+
+### 5.2.3 useState와 Context를 동시에 사용하기
+
+여러개의 서로 다른 데이터를 공유해 사용하고 싶을 때 사용. Context를 활용해 해당 스토어를 하위 컴포넌트에 주입한다!
+
+### 5.2.4 상태 관리 라이브러리 Recoil, Jotai, Zustand
+
+- Recoil
+  - ReocilRoot 선언해 하나의 스토어 생성
+  - atom이라는 상태 단위를 스토어 등록
+  - atom은 key 값으로 구별
+  - hook을 통해 atom의 변화를 구독
+  - 값이 변경된다면 forceUpdate 같은 기법을 통해 리렌더링, 최신 atom값을 가져옴
+- Jotai
+  - Recoil의 컨셉을 가져와 사용하고 단점을 해결하여 사용
+  - Bottom-up 접근법을 취하고 있어 불필요한 렌더링이 일어나지 않음
+  - Key를 별도로 관리하는 부분을 추상화 하여 사용자가 관리할 필요 없다.
+  - 객체 참조를 WeakMap에 보관해 해당 객체 자체가 변경 되지 않는 한 객체의 참조를 통해 관리 가능
+- Zustand
+  - 리덕스에 영감을 받아 만들었다. 중앙 집중형
+  - 빠르고 간단하게 스토어를 만들어서 사용 가능
+  - 특정 프레임워크에 종송적이지 않음
+  - 번들 사이즈가 엄청 낮음