diff --git "a/week1/font/\354\230\244\353\256\244_\353\213\244\354\230\210\354\201\250\354\262\264.ttf" "b/week1/font/\354\230\244\353\256\244_\353\213\244\354\230\210\354\201\250\354\262\264.ttf"
deleted file mode 100644
index b26b9e9..0000000
Binary files "a/week1/font/\354\230\244\353\256\244_\353\213\244\354\230\210\354\201\250\354\262\264.ttf" and /dev/null differ
diff --git "a/week1/\354\203\235\352\260\201\352\263\274\354\240\234.md" "b/week1/\354\203\235\352\260\201\352\263\274\354\240\234.md"
deleted file mode 100644
index e7c61b7..0000000
--- "a/week1/\354\203\235\352\260\201\352\263\274\354\240\234.md"
+++ /dev/null
@@ -1,111 +0,0 @@
-## 1주차 생각과제
-
-
-
-
-## 웹 최적화는 무었일까?
-
-웹에 접속하는 사람 마다의 네트워크 상황이 다를 수 있고, 웹 서비스별로 목표로 하는 사용자나 평균 접속자 수가 상이할 수 있기 때문에
-이러한 여러 상황들을 고려하여 서비스를 제공하는데 필요한 렌더링에 걸리는 시간을 줄이는 것!
-
-
-
-
-## 최적화가 필요한 이유는 무엇일까?
-
-네트워크가 원활하지 못한 사용자나 상황에서도 서비스를 이용할 수 있도록 하여 범용성을 넓히기 위해서 필요하고,
-사용 환경을 고려하지 않더라도 더 좋은 사용자 경험 제공을 위해 필수적으로 따져야 한다.
-좋은 사용자 경험은 사용자들의 서비스 재방문 여부를 결정하는 중요한 지표이므로 렌더링 최적화를 신경써야할 필요가 있다!
-
-
-
-
-## 이를 위해 어떤 개발을 해야할까?
-
-브라우저에 서비스가 렌더링되는 방법을 고려하여 렌더링 최적화를 진행하거나,
-서비스 번들 크기 자체를 줄여 웹 서버에서 번들 파일을 제공하는 시간을 단축하거나,
-서버에서 데이터를 불러올 때 캐싱 등의 방법을 적용하여 불필요한 작업들을 최소화한다!
-
-렌더링 최적화를 위한 수단으로는 여러가지가 있겠지만,
-대표적으로는 아래의 수단들이 있습니다.
-
-
-
-### 1. 번들러 사용하기
-
-Webpack, Vite, Bun 등의 자바스크립트 번들러는 우리가 작성한 코드를 하나로 묶어 압축하여 큰 파일로 만들어주는데, 이 과정에서 불필요한 공백들을 없애는 등의 최적화 과정을 거칩니다. 이를 통해 결과적으로 웹 서버에 저장되는 파일의 크기를 효과적으로 줄여줌으로서 렌더링 최적화를 진행할 수 있습니다.
-
-
-
-### 2. 라이브러리 의존도 줄이기
-
-간단한 기능을 구현하기 위해 모두 라이브러리를 불러와 사용하다 보면 최종 번들 크기가 커지고 최적화에 큰 영향을 줄 수 있습니다.
-이를 발지하기 위해 핵심 기능 구현을 위해 필수적인 라이브러리들을 제외하고 불필요하거나 직접 구현할 수 있는 기능들은
-직접 구현해보는 것이 좋다고 생각합니다.
-
-
-
-### 3. 개발 의존성 라이브러리 구별하기
-
-필수적인 라이브러리 중에서도 개발 단계에서만 사용해도 되는 라이브러리와 실제 서비스 단에서 사용되는 라이브러리가 있습니다.
-이를 구별하여 package.json에 명시해주는 것이 최종 번들 크기를 줄이는 효과적인 방법이 된다고 생각합니다.
-
-
-
-### 4. 캐싱
-
-캐싱은 서비스에서 데이터 변경 시 발생하는 리렌더링이나 데이터 패칭의 과정을 최적화하기 위해 사용됩니다.
-기존의 렌더링된 사항에서 변경사항이 없음을 감지한 부분은 다시 그리지 않음으로써 로딩 시간을 단축할 수 있고,
-데이터를 불러오는 과정 또한 캐싱을 통해 동일한 데이터에 대한 불필요한 재호출을 막음으로써 로딩 시간을 단축할 수 있습니다.
-
-캐싱을 위해 사용되는 것들로는 React의 useMemo, useCallback 훅, React query / SWR 라이브러리 등이 있습니다!!
-
-
-
-### 5. 이미지 최적화(Lazy loading, img sprite), 폰트 최적화
-
-이미지는 텍스트보다 용량이 크기 때문에 웹에서 렌더링을 신경써야 하는 주된 요소 중 하나입니다.
-이때 화면에 들어오는 이미지만 동적으로 로딩하는 지연 로딩(Lazy loading)을 적용하거나,
-아이콘과 같이 간단하지만 자주 사용되는 이미지들은 하나의 이미지로 묶어 위치정보를 통해 해당 아이콘을 구현하는 이미지 스프라이트를 적용해도 좋습니다.
-
-폰트 파일 또한 번들 크기에 영향을 크게 주는 요소 중 하나입니다.
-폰트 파일은 크기가 매우 크므로 폰트를 외부에서 불러오는 방식을 적용하거나, 압축된 폰트 확장자(WOFF, WOFF2)를 적용한다거나,
-서브셋 폰트 사용등을 통해 폰트 최적화를 진행할 수 있습니다.
-
-
-
-### 6. 상황에 맞는 렌더링 기법 적용하기
-
-브라우저에 파일을 렌더링하는 방법은 크게 네 가지가 대표적으로 있습니다.
-
-`CSR`: 클라이언트에서 직접 사이트를 렌더링하고, 데이터 패칭, 라우팅 등의 모든 작업을 클라이언트에서 진행하는 기법입니다.
-일반적으로 동적인 페이지 생성에 가장 많이 사용됩니다.
-
-`SSR`: 서버 사이드에서 사이트를 미리 생성하고 이를 클라이언트에 보내 띄우는 방식으롸, 초기 로딩 시간이 CSR에 비해 짧다는 장점이 있어
-초기 페이지 로딩 시 UX 개선에 효과적입니다. 또한 서버에서 미리 페이지를 렌더링하므로, SEO에 효과적입니다.
-그러나 매 페이지 이동마다 새로운 리소스를 다운받아 페이지 렌더링을 해야하므로 CSR보다 페이지 이동이 원활하지 못함.
-
-`SSG`: 서버에서 미리 렌더링된 사이트를 전달해주므로 로딩이 빠르고, SEO에 적합하다.
-대신 동적인 컨텐츠 제공이 어렵다.
-데이터의 변경이 잦지 않은 블로그 등의 정적 페이지에 적합합니다.
-
-`ISR`: SSG를 일정 시간마다 재수행하는 렌더링 기법이라고 생각하면 좋다.
-정적인 페이지를 렌더링하되, 일정 주기를 기준으로 데이터를 다시 불러 새로운 페이지를 렌더링해줍니다.
-
-
-
-### 7. 성능 최적화 도구 적용하기
-
-실제 내가 적용한 방법들이 잘 적용되어 좋은 효과를 내는지 확인하기 위해 Chrome lighthouse와 같은 툴을 이용하여 렌더링 최적화 정도를 파악할 수 있다.
-
-
-
-
-
-### 최적화를 위한 개발을 꼭 해야할까?
-
-필수적이라고 할 수는 없더라도, 서비스의 범용성을 생각한다면 꼭 필요한 과정이라고 생각합니다.
-최적화를 진행한 결과물과 진행하지 않은 결과물을 비교하였을 때 그 차이를 쉽게 느낄 수 있습니다.
-
-최적화 과정은 메인 비즈니스 로직과는 별개의 영역이지만,
-서비스의 고도화는 유저의 이탈을 효과적으로 막고, 동일한 서비스를 제공하는 경쟁사와의 경쟁에서 아이덴티티를 확보하고 유저를 잡아두기 위한 서비스 고도화에 필수적인 과정이라고 생각합니다.
diff --git "a/week3/\354\203\235\352\260\201\352\263\274\354\240\234.md" "b/week3/\354\203\235\352\260\201\352\263\274\354\240\234.md"
new file mode 100644
index 0000000..46513cb
--- /dev/null
+++ "b/week3/\354\203\235\352\260\201\352\263\274\354\240\234.md"
@@ -0,0 +1,30 @@
+## 💟 React에서 상태관리는 왜 필요한가?
+
+ - 상태(state) 란 세미나 때 공부한 것처럼 컴포넌트 내부에서 공유되는 지역 변수와도 같다. 일반적으로 선언된 변수와 다른 점이라면 데이터 바인딩이 적용되어 JSX 문법과 사용하기 좋다는 것이고, 동적인 데이터를 다루기 용이하다는 점이다.
+
+ - 상태를 사용하여 동적인 웹 페이지를 생성하는 과정에서 상태관리는 필수가 되었다. 리액트 프로젝트의 규모가 커지고 코드 추상화에 따른 파일과 폴더의 수가 증가할수록 컴포넌트 간의 데이터를 전달하고 특정 컴포넌트에서의 상태 변경을 이에 관여하는 모든 컴포넌트들에 전달하기 어려워지는 문제가 발생했다. 이러한 개별 컴포넌트 관계를 정확하게 파악하고 데이터를 전달해주기 어려운 상황에서 우리는 각 컴포넌트에서 사용하는 상태를 관리하고, 특히 컴포넌트 간에 공유되는 상태를 관리할 필요가 생긴 것이다.
+
+ - 이러한 상황에서 등장한 것이 '전역 상태 관리'라는 개념인데, 기존에 props drilling으로 해결하던 컴포넌트 간의 상태 전달 문제를 전역적으로 관리해야하는 상태를 따로 빼낸 store의 개념을 도입하며 해소하였다. 다수의 컴포넌트에 공유되는 상태를 전역 상태로 선언하여 관리에 용이하게 만든 것이다.
+
+### 관리 해야 하는 상태에 대한 기준은 무엇인가?
+
+- 상태관리가 필요한 상태의 경우 여러 컴포넌트에서 공유되는 값을 가지고 있다는 특징이 있다. 여러 컴포넌트에서 해당 값을 사용해야하므로, 이를 전역 상태 관리 store 단에서 선언해 값을 사용하고자 하는 모든 컴포넌트에 전달할 필요가 있다.
+
+### 어떤 상태관리 라이브러리를 어떤 상황에서 사용해야 할까?
+
+- 상태 관리 라이브러리는 Redux, Recoil, ContextAPI 등등이 존재하는데, 나는 우선 이 3가지를 비교해보고자 한다. 우선 ContextAPI 는 React 내장 기능으로 그 목적이 나머지 둘과 조금 다르다. 상태 관리를 위한 것은 맞지만 전역상태관리에 목적을 두는 것은 아니다. 오히려 Redux, Recoil이 전역상태관리를 위한 다양한 기능들을 많이 제공해주므로 전역 상태관리를 위해서라면 Redux, Recoil 등의 라이브러리를 사용하는 것이 좋다. ContextAPI는 그 외에 간단한 컴포넌트 묶음 내부에서 공유할 상태가 존재하는 경우 등 특수한 상황에서 가볍게 적용하는 것이 좋다고 생각했다.
+
+- Redux와 Recoil을 비교하면, Redux는 오랫동안 유명했고 그만큼 사용자와 팬층이 두터워 현재 분명한 1위로 자리하고 있다. 또한 강력한 Devtools와 Flux 패턴 기반의 아키텍쳐는 Redux를 사용하는 개발자들의 개발자 경험을 충분히 끌어올려준다. 그러나 React 친화적이고 Redux보다 훨씬 간단한 구성 환경을 제공하여 진입장벽을 낮춘 Recoil의 경우 앞으로 사용자가 많이 늘어나고 적용하는 곳이 많아진다면 충분히 입지를 다질 수 있을 것이라고 생각한다. 그리고 Recoil 또한 Devtools가 발전 중에 있고, React를 만든 페이스북에서 React를 위한 상태관리 라이브러리라고 소개한 만큼 시간이 지나면 React 생태계 내에서 충분히 Redux와 견줄 만한 좋은 라이브러리가 될 수 있을 것이라고 생각한다.
+
+- 따라서 정말 대규모 비즈니스 로직을 관리하는 곳에서는 Redux를 사용하고, 아직 대규모가 아니거나 프로젝트 단위의 개발이라면 충분히 Recoil을 사용해도 좋을 것 같다.
+
+## 💟 React에서 렌더링을 효과적으로 관리하는 방법은 무엇이 있을까?
+
+- React에서 렌더링은 사용자 경험을 좌지우지하는 결정적인 요소이다. 렌더링을 효과적으로 관리하기 위해서는 불필요한 리렌더링을 방지하는 것이 가장 중요하다. 불필요한 리렌더링이란 특정 state의 변경을 감지하고 리렌더링을 진행할 때, 해당 state의 변경에 영향을 받지 않는 요소까지 렌더링되는 것을 말한다. 이를 위해서는 useMemo 혹은 useCallback과 같은 메모이제이션을 위한 훅을 사용하면 좋다.
+
+
+### 이를 위해 어떤 식으로 비즈니스 설계를 진행해야 할까
+
+- state가 변경되는 로직을 캡슐화하여 관리하는 방법이 존재한다. 뷰와 로직을 분리하고 로직을 따로 관리함으로써 해당 state에 영향을 받는 것들을 확실하게 할 수 있다.
+
+- 이를 위해 이전에 언급되었던 Custom Hooks를 최대한 활용하면 좋을 것 같다.
- favorite
- 
- 
- 
- 
- 
- 
- 
- 
- 
- 
-