diff --git a/.DS_Store b/.DS_Store
index bb6bf76..a90ee35 100644
Binary files a/.DS_Store and b/.DS_Store differ
diff --git a/chapter02/wogus216.md b/chapter02/wogus216.md
index 3e79f39..6babe08 100644
--- a/chapter02/wogus216.md
+++ b/chapter02/wogus216.md
@@ -665,15 +665,15 @@ componentDidcatch 두개의 인수를 받는데, 첫번째는 getDerivedStateFro
1. 최초 렌더링
2. 리렌더링: 최소 렌더링이 발생한 이후로 발생하는 모든 렌더링을 의미
+ 리렌더링 발생하는 경우는 다음과 같다.
- 리렌더링 발생하는 경우는 다음과 같다.
- * 클래스형 setState가 실행되는 경우: state의 변화는 컴포넌트 상태의 변화를 의미
- * 클래스형 forceUpdate가 실행되는 경우
- * 함수형 useState 두 번째 배열요소 setter가 실행되는 경우
- * 함수형 useReducer 두 번째 배열요소 dispatch가 실행되는 경우: useReducer도 useState와 마찬가지로 상태를 업데이트 함수를 배열로 제공
- * 컴포넌트의 key props가 변경되는 경우: 리액트에서 Key는 리렌더링이 발생하는 동안 형제요소들 사이에서 동일한 요소를 식별하는 값.
- * props가 변경되는 경우: 부모로 전달 받는 값이 props가 달라지면 자식 컴포넌트 변경이 필요
- * 부모 컴포넌트가 렌더링될 경우
+ - 클래스형 setState가 실행되는 경우: state의 변화는 컴포넌트 상태의 변화를 의미
+ - 클래스형 forceUpdate가 실행되는 경우
+ - 함수형 useState 두 번째 배열요소 setter가 실행되는 경우
+ - 함수형 useReducer 두 번째 배열요소 dispatch가 실행되는 경우: useReducer도 useState와 마찬가지로 상태를 업데이트 함수를 배열로 제공
+ - 컴포넌트의 key props가 변경되는 경우: 리액트에서 Key는 리렌더링이 발생하는 동안 형제요소들 사이에서 동일한 요소를 식별하는 값.
+ - props가 변경되는 경우: 부모로 전달 받는 값이 props가 달라지면 자식 컴포넌트 변경이 필요
+ - 부모 컴포넌트가 렌더링될 경우
### 2.4.3 리액트의 렌더링 프로세스
@@ -750,5 +750,10 @@ memo나 다른 메모제이션 방법을 사용하는 것이 이점이 있을
- 리액트가 구 트리와 신규 트리를 비교
얼핏 봐도 memo를 하지 않았을 때 치러야할 잠재적인 위험비용이 더 커보인다.
+정리하자면 메모제이션은 하지 않는 것 보다 메모이제이션을 했을 때 더 많은 이점을 누린다.
+
+> 예제의 차이를 이해해보자
### 2.5.3 결론 및 정리
+
+꼼꼼히 확인 하고 써보거나 쓰면서 계속 체크를 하는 둘 중 하나 방법
diff --git a/chapter03/info.md b/chapter03/info.md
new file mode 100644
index 0000000..f920e2f
--- /dev/null
+++ b/chapter03/info.md
@@ -0,0 +1,65 @@
+# 03장: 리액트 훅 깊게 살펴보기
+
+리액트를 이루는 핵심 요소들을 깊게 살펴보고, 리액트의 렌더링 과정을 이해하는 장입니다.
+
+
+
+- [03장: 리액트 훅 깊게 살펴보기](#03장-리액트-훅-깊게-살펴보기)
+ - [3.1 리액트 훅 깊게 살펴보기](#31-리액트-훅-깊게-살펴보기)
+ - [3.1.1 useState](#311-usestate)
+ - [3.1.2 useEffect](#312-useeffect)
+ - [3.1.3 useMemo](#313-usememo)
+ - [3.1.4 useCallback](#314-usecallback)
+ - [3.1.5 useRef](#315-useref)
+ - [3.1.6 useContext](#316-usecontext)
+ - [3.1.7 useReducer](#317-usereducer)
+ - [3.1.8 useImperativeHandle](#318-useimperativehandle)
+ - [3.1.9 useLayoutEffect](#319-uselayouteffect)
+ - [3.1.10 useDebugValue](#3110-usedebugvalue)
+ - [3.1.11 훅의 규칙](#3111-훅의-규칙)
+ - [3.1.12 정리](#3112-정리)
+ - [3.2 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?](#32-사용자-정의-훅과-고차-컴포넌트-중-무엇을-써야-할까)
+ - [3.2.1 사용자 정의 훅](#321-사용자-정의-훅)
+ - [3.2.2 고차 컴포넌트](#322-고차-컴포넌트)
+ - [3.2.3 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?](#323-사용자-정의-훅과-고차-컴포넌트-중-무엇을-써야-할까)
+ - [3.2.4 정리](#324-정리)
+
+
+
+## 3.1 리액트 훅 깊게 살펴보기
+
+### 3.1.1 useState
+
+### 3.1.2 useEffect
+
+### 3.1.3 useMemo
+
+### 3.1.4 useCallback
+
+### 3.1.5 useRef
+
+### 3.1.6 useContext
+
+### 3.1.7 useReducer
+
+### 3.1.8 useImperativeHandle
+
+### 3.1.9 useLayoutEffect
+
+### 3.1.10 useDebugValue
+
+### 3.1.11 훅의 규칙
+
+### 3.1.12 정리
+
+
+
+## 3.2 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?
+
+### 3.2.1 사용자 정의 훅
+
+### 3.2.2 고차 컴포넌트
+
+### 3.2.3 사용자 정의 훅과 고차 컴포넌트 중 무엇을 써야 할까?
+
+### 3.2.4 정리