diff --git a/Aug/article/Deep-Dive-into-React-Concurrent-Mode-Exploring-Key-Features-and-Use-Cases.md b/Aug/article/Deep-Dive-into-React-Concurrent-Mode-Exploring-Key-Features-and-Use-Cases.md
new file mode 100644
index 0000000..37e217a
--- /dev/null
+++ b/Aug/article/Deep-Dive-into-React-Concurrent-Mode-Exploring-Key-Features-and-Use-Cases.md
@@ -0,0 +1,324 @@
+# [Deep Dive into React Concurrent Mode: Exploring Key Features and Use Cases](https://www.dhiwise.com/post/deep-dive-into-react-concurrent-mode-exploring-key-features-and-use-cases)
+
+### 🗓️ 번역 날짜: 2024.08.04
+
+### 🧚 번역한 크루: 버건디(전태헌)
+
+---
+
+안녕하세요, React 열성 팬 여러분!
+
+React Concurrent Mode의 미스터리를 풀어내는 짜릿한 여정을 준비하세요. React 18에서 도입된 이 강력한 새로운 기능은 우리가 사용자 인터페이스를 구축하는 방식을 혁신할 것입니다. 마치 React 앱이 메인 스레드를 차단하지 않고 여러 작업을 동시에 수행할 수 있는 새로운 차원으로 들어가는 것과 같습니다.
+
+무거운 계산이나 네트워크 요청 중에도 앱이 응답성을 유지할 수 있는 세계를 상상해 보세요. 사용자가 상호작용할 때 UI가 멈추지 않는 세계를 말이죠. 이것이 Concurrent 기능의 약속입니다. 이것은 단순한 새로운 기능이 아니라 React에 대한 새로운 사고방식입니다.
+
+그럼, 안전벨트를 매고 React의 동시성 세계로 뛰어들 준비를 합시다!
+
+```tsx
+import { unstable_createRoot } from "react-dom";
+
+const root = unstable_createRoot(document.getElementById("root"));
+
+root.render(<App />);
+```
+
+이 코드 스니펫에서 우리는 react-dom의 unstable_createRoot 함수를 사용하여 루트 노드를 생성하고 있습니다. 이 함수는 전체 앱에 대해 동시 렌더링을 가능하게 합니다.
+
+동시 렌더링의 아름다움은 React가 메모리에서 UI의 여러 버전을 준비한 다음 사용자 상호작용 및 네트워크 조건에 따라 빠르게 전환할 수 있게 한다는 것입니다. 이는 무거운 계산이나 네트워크 요청이 있는 복잡한 앱에서도 더 응답성이 좋고 유동적인 사용자 경험을 제공합니다.
+
+그러나 동시 렌더링이 만병통치약은 아닙니다. 이는 새로운 수준의 복잡성을 도입하며 앱이 업데이트되고 렌더링되는 방식을 다르게 생각해야 합니다. 그러나 이를 익히게 되면, React 앱이 한 단계 더 발전할 수 있는 방법을 알게 될 것입니다.
+
+## 리액트 16에 비해서 동시성 모드는 어떻게 다른가
+
+React 18의 등장과 함께 React 팀은 이전 버전인 React 16 및 이전 버전에서 사용된 동기 렌더러와 근본적으로 다른 새로운 동시 렌더러를 도입했습니다. 그렇다면 정확히 무엇이 변경되었을까요?
+
+React 16에서는 렌더링이 항상 동기적이었습니다. 이는 React가 컴포넌트 트리의 렌더링을 시작하면 전체 트리가 렌더링될 때까지 중지하지 않는다는 것을 의미합니다. 이는 큰 렌더링 작업이 메인 스레드를 차단하여 UI가 멈추고 응답하지 않게 되는 문제를 일으킬 수 있었습니다.
+
+반면, React 18은 동시 렌더링을 도입합니다. 이 새로운 모드는 React가 렌더링 프로세스를 중단하고 사용자 입력과 같은 더 긴급한 작업을 처리할 수 있게 합니다. 이는 마치 React가 동시에 여러 곳에 있을 수 있는 초능력을 가진 것과 같습니다.
+
+```ts
+// React 16
+ ReactDOM.render(<App />, document.getElementById('root'));
+
+// React 18
+ const root = ReactDOM.createRoot(document.getElementById('root'));
+ root.render(<App />)
+```
+
+React 16에서는 ReactDOM.render를 사용하여 앱을 렌더링합니다. 그러나 React 18에서는 ReactDOM.createRoot를 사용하여 루트 노드를 생성한 후 해당 루트 노드에서 render를 호출합니다. 이를 통해 앱 전체에서 동시 렌더링이 가능해집니다.
+
+하지만 차이점은 단순히 앱을 렌더링하는 방식에 그치지 않습니다. 동시 모드를 통해 React 18은 여러 상태 업데이트의 자동 일괄 처리, 스트리밍 서버 렌더링, 그리고 컴포넌트의 부드러운 로딩 상태를 만들 수 있는 React Suspense와 같은 새로운 기능들을 도입합니다.
+
+본질적으로, React 18의 동시 모드는 React에서 렌더링에 대한 사고방식을 변화시키는 패러다임의 전환입니다. 이는 단순히 앱을 더 빠르게 만드는 것뿐만 아니라 더 응답성이 좋고 사용자 친화적으로 만드는 것을 목표로 합니다.
+
+## 리액트 18에서의 동시성 기능들 : 깊이 파헤치기
+
+React 18에는 앱을 더 응답성 있고 사용자 친화적으로 만들기 위한 다양한 동시 기능이 포함되어 있습니다. 이러한 기능 중 일부를 깊이 살펴보고 어떻게 React 앱을 향상시킬 수 있는지 알아보겠습니다.
+
+1. 자동 배칭:
+
+이전 버전의 React에서는 React 이벤트 외부에서 트리거된 상태 업데이트가 함께 배칭되지 않았습니다. 이는 불필요한 재렌더링과 비효율적인 앱을 초래할 수 있었습니다. React 18은 여러 상태 업데이트를 함께 배칭하여 단일 재렌더링을 수행하는 자동 배칭을 도입합니다.
+
+다음은 예제입니다:
+
+```tsx
+const [count, setCount] = useState(0);
+
+// In React 16, these would cause two re-renders
+setCount(count + 1);
+setCount(count + 1);
+
+// In React 18, these are batched together and cause a single re-render
+```
+
+2. 스트리밍 서버 렌더링:
+
+React 18은 서버에서 클라이언트로 HTML을 스트리밍할 수 있는 새로운 서버 렌더링 API를 도입합니다. 이는 브라우저가 전체 응답을 기다리지 않고 첫 번째 데이터 청크를 받자마자 HTML 렌더링을 시작할 수 있음을 의미합니다. 이를 통해 앱의 인식된 로드 시간을 크게 개선할 수 있습니다.
+
+3. React Suspense:
+
+React Suspense는 컴포넌트에 대해 부드러운 로딩 상태를 만들 수 있는 React 18의 새로운 기능입니다. Suspense를 사용하면 일부 코드가 로드될 때까지 "대기"하고 선언적으로 로딩 상태를 지정할 수 있습니다. 이는 코드 분할 또는 데이터 페칭을 처리할 때 특히 유용할 수 있습니다.
+
+```tsx
+<Suspense fallback={<div>Loading...</div>}>
+  <MyComponent />
+</Suspense>
+```
+
+이 예제에서 컴포넌트는 MyComponent를 감싸고 있습니다. MyComponent가 아직 준비되지 않은 경우(예: 데이터를 페칭하거나 코드 분할 청크를 로드하는 중일 때), React는 fallback 속성으로 지정된 내용을 표시합니다. 이 경우 간단한 "Loading..." div를 표시합니다.
+
+이것은 React 18의 동시 기능 중 일부에 불과합니다. 또한 startTransition 기능이 있어 특정 업데이트를 "전환"으로 표시하고 우선순위를 낮추어 처리할 수 있으며, useDeferredValue 기능을 사용하면 느린 상태 업데이트를 빠른 업데이트가 완료될 때까지 연기할 수 있습니다.
+
+이러한 동시 기능들을 함께 사용하면 React는 복잡한 렌더링 작업을 더 효율적으로 처리하고 더 부드럽고 응답성이 뛰어난 사용자 경험을 제공할 수 있습니다.
+
+## 동시성 모드가 가능하도록하기 : 차근치근 해보기
+
+이제 동시 렌더링과 그 기능에 대해 알아보았으니, 실제로 React 앱에서 동시 모드를 활성화하는 방법을 살펴보겠습니다.
+
+단계 1: React 18로 업그레이드
+
+첫 번째 단계는 앱을 React 18로 업그레이드하는 것입니다. 이를 위해 터미널에서 다음 명령어를 실행하면 됩니다:
+
+이 명령어를 실행하면 React와 ReactDOM 패키지가 최신 버전으로 업데이트됩니다.
+
+```
+npm install react@18 react-dom@18
+```
+
+단계 2: Strict Mode 활성화
+
+다음으로, 앱에서 Strict Mode를 활성화해야 합니다. 이는 동시 모드에서 문제가 될 수 있는 잠재적인 이슈를 잡아내는 데 도움이 됩니다. 이를 위해 앱의 루트 컴포넌트를 StrictMode로 감싸면 됩니다.
+
+```tsx
+import React, { StrictMode } from "react";
+
+<StrictMode>
+  <App />
+</StrictMode>;
+```
+
+단계 3: 동시 모드 활성화
+
+이제 동시 모드를 활성화할 차례입니다. ReactDOM.render를 사용하는 대신 ReactDOM.createRoot를 사용합니다.
+
+```tsx
+import { createRoot } from "react-dom";
+
+const root = createRoot(document.getElementById("root"));
+root.render(<App />);
+```
+
+그리고 보세요! 이제 React 앱에서 동시 모드를 활성화했습니다. 이제 자동 배칭, 스트리밍 서버 렌더링 및 React Suspense와 같은 React 18의 동시 기능을 최대한 활용할 수 있습니다.
+
+기억하세요, 동시 모드는 강력한 도구이지만 큰 힘에는 큰 책임이 따릅니다. 이는 새로운 수준의 복잡성을 도입하며 앱의 업데이트와 렌더링 방식을 다르게 생각해야 합니다. 그러나 이를 익히게 되면, React 앱이 한 단계 더 발전할 수 있는 방법을 알게 될 것입니다.
+
+## 동시 React: 실제 예제
+
+이제 동시 모드의 이론과 설정에 대해 다루었으니, 실제로 동시 React가 사용자 경험을 어떻게 향상시킬 수 있는지 몇 가지 예제를 살펴보겠습니다.
+
+### 예제 1: 사용자 입력 우선 처리
+
+동시 모드의 주요 이점 중 하나는 특정 작업을 다른 작업보다 우선 처리할 수 있다는 것입니다. 예를 들어, 앱에 검색창이 있다고 가정해봅시다. 사용자가 검색창에 입력하면 앱은 사용자의 입력을 기반으로 항목 목록을 필터링합니다.
+
+전통적인 동기 렌더링 모델에서는 항목 목록이 크다면, 목록을 필터링하는 작업이 메인 스레드를 차단하여 입력이 사용자의 타이핑 속도에 뒤처질 수 있습니다. 이는 사용자를 불편하게 만들 수 있습니다.
+
+동시 모드를 사용하면, React는 필터링 프로세스를 중단하고 사용자 입력을 처리하여 입력이 항상 응답성을 유지하도록 할 수 있습니다.
+
+### 예제 2: Suspense를 통한 부드러운 로딩 상태
+
+동시 모드의 또 다른 강력한 기능은 React Suspense입니다. 이를 통해 컴포넌트의 부드러운 로딩 상태를 만들 수 있습니다.
+
+예를 들어, API에서 데이터를 가져오는 컴포넌트가 있다고 가정해봅시다. 전통적인 모델에서는 로딩 상태를 수동으로 관리해야 하며, 제대로 관리되지 않으면 사용자 경험이 불편해질 수 있습니다.
+
+Suspense를 사용하면 선언적으로 로딩 상태를 지정하고 나머지는 React가 처리하도록 할 수 있습니다. 이렇게 하면 React가 데이터를 로드하는 동안 "기다리고" 그 사이에 로딩 상태를 보여줌으로써 훨씬 더 부드러운 사용자 경험을 제공할 수 있습니다.
+
+```tsx
+<Suspense fallback={<div>Loading...</div>}>
+  <DataFetchingComponent />
+</Suspense>
+```
+
+이 예제에서 DataFetchingComponent가 여전히 데이터를 가져오는 중이라면, React는 fallback 속성을 표시합니다. 이 경우 간단한 "Loading..." div를 보여줍니다.
+
+이것은 동시 React가 사용자 경험을 향상시키는 방법에 대한 몇 가지 예에 불과합니다. 가능성은 무궁무진하며, 이러한 강력한 새로운 기능으로 여러분이 무엇을 만들지 기대됩니다!
+
+## React 18: 손쉽게 동시성 처리
+
+React 18의 동시 모드는 애플리케이션에서 동시성을 처리하는 방식에 큰 변화를 가져옵니다.
+이는 새로운 동시 렌더러를 도입하여 메인 스레드를 차단하지 않고 동시에 여러 작업을 수행할 수 있게 합니다. 이는 한 번에 하나의 작업만 처리할 수 있었던 이전의 동기 렌더러에 비해 상당한 개선입니다.
+
+하지만 React는 동시성을 어떻게 처리할까요? 그 비밀은 React가 업데이트를 스케줄링하는 방식에 있습니다. 동시 모드에서는 React가 진행 중인 렌더링 프로세스를 중단하고 사용자 입력과 같은 더 긴급한 작업을 처리할 수 있습니다. 이를 통해 앱이 무거운 계산이나 네트워크 요청 중에도 항상 응답성을 유지할 수 있습니다.
+
+이것을 설명하기 위한 예제는 다음과 같습니다:
+
+```tsx
+import { startTransition } from "react";
+
+function MyComponent() {
+  const [state, setState] = useState(initialState);
+
+  function handleClick() {
+    startTransition(() => {
+      setState(newState);
+    });
+  }
+
+  // ...
+}
+```
+
+이 예제에서는 startTransition 함수를 사용하여 상태 업데이트를 "전환"으로 표시하고 있습니다. 이는 React에게 이 업데이트가 긴급하지 않으며, 더 긴급한 작업이 있을 경우 중단될 수 있음을 알려줍니다.
+
+작업의 우선순위를 지정할 수 있는 이 기능이 동시 모드를 매우 강력하게 만듭니다. 이를 통해 React는 복잡한 렌더링 작업을 더 효율적으로 처리하고 더 부드럽고 응답성이 좋은 사용자 경험을 제공합니다.
+
+그러나 큰 힘에는 큰 책임이 따릅니다. 동시 모드는 새로운 수준의 복잡성을 도입하며, 앱이 업데이트되고 렌더링되는 방식을 다르게 생각해야 합니다. 따라서 동시 모드를 사용하기 전에 개념을 철저히 이해하는 것이 중요합니다.
+
+## React 18: 더블 렌더 미스터리 설명
+
+React 18의 동시 모드에서 가장 흥미로운 측면 중 하나는 소위 "더블 렌더" 현상입니다. React 18을 실험해보셨다면 일부 컴포넌트가 한 번만 렌더링되어야 하는데 두 번 렌더링되는 것처럼 보이는 것을 발견했을지도 모릅니다. 도대체 무슨 일이 벌어지고 있는 걸까요?
+
+더블 렌더는 사실 버그가 아니라 기능입니다. 이는 새로운 동시 렌더러의 작동 방식에서 비롯됩니다. 동시 모드에서는 React가 DOM을 업데이트하기 전에 메모리에서 새로운 화면(또는 업데이트된 컴포넌트 상태)을 준비합니다. 이를 "메모리 내 렌더링" 또는 "오프스크린 렌더링"이라고 합니다.
+
+이 단계에서 React는 일부 컴포넌트를 사용자에게 보이지 않더라도 한 번 이상 렌더링할 수 있습니다. 이것이 "더블 렌더"를 초래하는 원인입니다. 그러나 이러한 추가 렌더링은 일반적으로 빠르게 이루어지며 메인 스레드를 차단하지 않으므로 앱의 성능에 영향을 미치지 않습니다.
+
+이를 설명하기 위한 예제는 다음과 같습니다:
+
+```tsx
+function MyComponent() {
+  const [state, setState] = useState(initialState);
+
+  console.log("Render");
+
+  // ...
+}
+```
+
+이 예제에서 이 컴포넌트를 동시 모드에서 실행하면, 컴포넌트가 한 번만 업데이트되더라도 콘솔에 "Render"가 두 번 기록되는 것을 볼 수 있습니다. 이것이 바로 "더블 렌더" 현상입니다.
+
+따라서 동시 모드에서 컴포넌트가 두 번 렌더링되는 것을 보더라도 놀라지 마세요. 이는 React가 새로운 화면을 메모리에서 준비하여 더 부드러운 사용자 경험을 제공하기 위한 과정일 뿐입니다.
+
+## React Experimental: 무엇에 관한 것일까?
+
+React 개발을 주시하고 있다면 "React Experimental"이라는 용어를 접했을 것입니다. 하지만 이것이 무엇을 의미하며 동시 모드와 어떤 관련이 있을까요?
+
+"React Experimental"은 안정적인 릴리스에서는 아직 사용할 수 없는 기능을 포함하는 실험적인 React 빌드를 가리키는 용어입니다. 이러한 실험 빌드는 React 팀이 새로운 기능을 테스트하고, 커뮤니티로부터 피드백을 받고, 안정적인 릴리스에 포함하기 전에 디자인을 반복적으로 개선하는 방법입니다.
+
+동시 모드는 처음에 React Experimental에서 도입되었습니다. 이는 광범위한 테스트와 피드백이 필요한 급진적인 새로운 기능이었기 때문입니다. React Experimental에서 먼저 출시함으로써, React 팀은 커뮤니티로부터 귀중한 피드백을 수집하고 동시 모드의 디자인과 구현에 필요한 조정을 할 수 있었습니다.
+
+따라서 최신의 React 기능을 공식 출시 전에 사용해보고 싶다면 React Experimental을 주목하세요. 하지만 React Experimental의 기능은 변경될 수 있으며, 프로덕션 환경에서 사용해서는 안 됩니다.
+
+그리고 React 개발에 기여하고 싶다면, React Experimental을 시도해보고 React 팀에 피드백을 제공하는 것이 좋은 시작점입니다. 여러분의 피드백은 React의 미래를 형성하고 모든 사람에게 더 나은 React를 만드는 데 도움이 될 수 있습니다.
+
+## React의 지속적인 개발: 미래 전망
+
+React는 지속적으로 개발되고 개선되는 살아 숨쉬는 프로젝트입니다. React 팀과 오픈 소스 커뮤니티에 의해 끊임없이 발전하고 있으며, React 18의 출시로 React의 미래는 밝고 흥미로운 가능성들로 가득 차 있음을 알 수 있습니다.
+
+React의 지속적인 개발에서 가장 흥미로운 측면 중 하나는 동시성에 대한 집중입니다. React 18에서 동시 모드의 도입으로 React는 더 응답성이 좋고 사용자 친화적인 미래를 향한 큰 발걸음을 내디뎠습니다. 하지만 이는 시작에 불과합니다. React 팀은 이미 동시 렌더링의 강력함을 한층 더 발전시키기 위한 새로운 동시 기능과 개선 작업을 진행하고 있습니다.
+
+또 다른 흥미로운 개발 영역은 서버 컴포넌트입니다. 이는 서버에서 렌더링되고 HTML로 클라이언트에 전송될 수 있는 새로운 유형의 컴포넌트입니다. 서버 컴포넌트는 API 계층 없이도 서버 측 데이터를 직접 액세스할 수 있어, 앱의 데이터 페칭 로직을 크게 단순화하고 성능을 향상시킬 수 있습니다.
+
+그리고 React Suspense도 잊지 말아야 합니다. 컴포넌트의 부드러운 로딩 상태를 만들 수 있는 강력한 기능입니다. Suspense는 이미 React 18에서 사용할 수 있지만, React 팀은 이를 더욱 강력하고 유연하게 만들기 위한 새로운 API와 추가 개선 작업을 진행하고 있습니다.
+
+따라서 React 개발자로서 앞으로 기대할 것이 많습니다. React의 미래는 앱을 더 응답성 높고 사용자 친화적이며, 개발하기 재미있게 만드는 흥미로운 새로운 기능과 개선으로 가득할 것입니다. React 팀이 우리에게 어떤 것을 준비하고 있을지 정말 기대가 됩니다!
+
+## 왜 React가 개발자들 사이에서 인기가 많은가
+
+React는 프론트엔드 개발의 세계를 강타했습니다. 2013년 Facebook에 의해 출시된 이후, React는 개발자들 사이에서 엄청난 인기를 얻었으며 사용자 인터페이스를 구축하는 데 가장 널리 사용되는 JavaScript 라이브러리 중 하나가 되었습니다. 그렇다면 왜 React가 이렇게 인기가 많을까요?
+
+주요 이유 중 하나는 그 단순함과 유연성입니다. React는 재사용 가능한 코드 조각인 컴포넌트 기반으로 구성되어 있으며, 이러한 컴포넌트를 조합하여 복잡한 사용자 인터페이스를 구축할 수 있습니다. 이 컴포넌트 기반 아키텍처는 대규모 애플리케이션을 구축하고 유지보수하기 쉽게 만듭니다.
+
+또 다른 이유는 성능입니다. React는 가상 DOM과 디핑(diffing) 알고리즘을 사용하여 실제 DOM에 대한 업데이트 수를 최소화합니다. 이는 실제 DOM 업데이트가 느릴 수 있기 때문입니다. 이를 통해 React 애플리케이션은 복잡한 UI를 가진 대규모 애플리케이션에서도 빠르고 응답성이 높습니다.
+
+React 18에서 도입된 동시 모드는 이러한 성능을 한 단계 더 끌어올립니다. React가 여러 작업을 동시에 수행하고 그 중요도에 따라 우선 순위를 지정할 수 있게 함으로써, 동시 모드는 React 애플리케이션을 더욱 응답성이 높고 사용자 친화적으로 만듭니다.
+
+하지만 아마도 React의 인기가 많은 가장 중요한 이유는 그 활기찬 커뮤니티일 것입니다. 전 세계 수백만 명의 개발자가 React를 사용하고 있어, 언제나 도움을 받을 수 있습니다. 문제 해결, 개발을 단순화할 라이브러리, 또는 영감이 필요할 때, React 커뮤니티가 항상 도와줄 준비가 되어 있습니다.
+
+그리고 동시 모드, 서버 컴포넌트, React Suspense와 같은 새로운 기능의 도입으로, React는 현재에 안주하지 않고 계속해서 진화하고 개선되고 있습니다. 이는 React가 개발자들에게 흥미롭고 보람 있는 선택이 되게 만듭니다.
+
+## React Suspense: 프로덕션 준비가 되었을까? 분석
+
+React Suspense는 React 18에서 도입된 가장 흥미로운 기능 중 하나입니다. 이는 컴포넌트의 로딩 상태를 선언적으로 처리할 수 있는 방법을 제공하여 부드럽고 응답성 좋은 로딩 경험을 만들기 쉽게 해줍니다. 하지만 이것이 프로덕션에서 사용하기에 준비가 되었을까요?
+
+답은 "예"이지만 주의할 점이 있습니다. React Suspense는 React 18에 포함되어 있으며 프로덕션에서 사용할 수 있지만, 여전히 실험적인 기능으로 간주됩니다. 이는 일반적으로 안정적이고 신뢰할 수 있지만, React 팀이 해결해야 할 몇 가지 엣지 케이스와 버그가 있을 수 있음을 의미합니다.
+
+Suspense를 사용할 때 염두에 두어야 할 주요 사항 중 하나는 로딩 상태에 대한 사고방식의 변화가 필요하다는 점입니다. 컴포넌트에서 로딩 상태를 수동으로 관리하는 대신, Suspense를 사용하면 선언적으로 로딩 상태를 지정하고 나머지는 React가 처리하도록 할 수 있습니다.
+
+이렇게 하면 코드가 간소화되고 로딩 상태가 일관되게 유지될 수 있지만, 기존 코드를 일부 리팩토링해야 할 수도 있습니다. 따라서 Suspense를 대규모 기존 코드베이스에 사용하려고 한다면, 어느 정도의 작업을 준비해야 합니다.
+
+결론적으로, React Suspense는 부드러운 로딩 상태를 만드는 강력한 도구이지만, 여전히 실험적인 기능이며 기존 코드에 통합하는 데 약간의 작업이 필요할 수 있습니다. 그러나 새로운 프로젝트를 시작하거나 기존 코드를 리팩토링할 의지가 있다면, 로딩 경험을 크게 개선할 수 있는 게임 체인저가 될 수 있습니다.
+
+## React 18: 주요 변경 사항과 대처 방법
+
+라이브러리나 프레임워크의 주요 릴리스마다 항상 호환성 문제가 발생할 가능성이 있습니다. React 18도 예외는 아닙니다. React 팀은 하위 호환성을 유지하기 위해 많은 노력을 기울였지만, 기존 코드를 잠재적으로 중단시킬 수 있는 몇 가지 변경 사항이 있습니다.
+
+가장 중요한 변경 사항 중 하나는 동시 모드의 도입입니다. 동시 모드는 많은 이점을 제공하지만, React에서 렌더링과 상태 업데이트에 대한 새로운 사고방식을 도입합니다. 이는 기존 코드에서 가정한 내용을 잠재적으로 중단시킬 수 있습니다.
+
+예를 들어, 동시 모드에서는 React가 사용자에게 보이지 않더라도 컴포넌트를 여러 번 렌더링할 수 있습니다. 이는 이전 버전의 React에서 컴포넌트가 정확히 한 번 렌더링되는 동기 렌더링 모델과는 다릅니다.
+
+또 다른 잠재적인 문제는 자동 배칭의 도입입니다. React 18에서는 여러 상태 업데이트가 배치되어 단일 재렌더링이 발생합니다. 이는 상태 업데이트가 즉각적인 재렌더링을 유발하는 기존 코드에 영향을 줄 수 있습니다.
+
+이러한 변경 사항에 어떻게 대처할 수 있을까요? 다음 몇 가지 팁을 참고하세요:
+
+1. 앱 테스트하기: 변경 사항에 대처하는 첫 번째 단계는 앱을 철저히 테스트하는 것입니다. 변경 사항에 영향을 받을 것이라고 생각되는 부분뿐만 아니라 앱의 모든 부분을 테스트하세요.
+
+2. 엄격 모드 사용하기: 엄격 모드는 앱에서 잠재적인 문제를 잡아내는 데 도움이 되는 React 도구입니다. React의 새로운 버전으로 마이그레이션할 때 특히 유용하며, 문제가 발생하기 전에 변경 사항을 감지할 수 있습니다.
+
+3. 필요에 따라 리팩토링하기: React 18의 변경 사항으로 인해 앱의 일부가 깨지는 경우, 코드를 리팩토링해야 할 수 있습니다. 이는 상태 업데이트를 처리하는 방식을 변경하거나 앱에서 렌더링을 처리하는 방식을 재고하는 것을 포함할 수 있습니다.
+
+4. 도움 구하기: 막히면 주저하지 말고 도움을 구하세요. React 커뮤니티는 활기차고 지원적이며, React 18의 변경 사항을 탐색하는 데 도움이 되는 많은 리소스가 있습니다.
+
+기억하세요, 호환성 문제는 도전적일 수 있지만, 이는 코드를 개선하고 React에 대해 더 많이 배울 수 있는 기회이기도 합니다. 도전을 받아들이고 즐겁게 코딩하세요!
+
+## React 18: 동시 기능의 힘
+
+React 18과 그 동시 모드를 탐험하면서 React에서 렌더링에 대한 새로운 사고방식을 어떻게 도입했는지 알 수 있었습니다. 이는 단순히 앱을 더 빠르게 만드는 것이 아니라 더 응답성 있고 사용자 친화적으로 만드는 것입니다. React 18의 동시 기능의 힘은 과장할 수 없습니다.
+
+자동 배칭: 이 기능은 여러 상태 업데이트를 함께 배치하여 단일 재렌더링을 수행할 수 있게 합니다. 이는 상태 업데이트가 빈번한 앱의 성능을 크게 향상시킬 수 있습니다.
+
+**스트리밍 서버 렌더링:** 이 기능은 서버에서 클라이언트로 HTML을 스트리밍할 수 있게 하여 앱의 인식된 로드 시간을 개선합니다. 브라우저는 전체 응답을 기다리지 않고 첫 번째 데이터 청크를 받자마자 HTML 렌더링을 시작할 수 있습니다.
+
+**React Suspense:** 이 기능은 컴포넌트에서 로딩 상태를 처리하는 선언적인 방법을 제공합니다. Suspense를 사용하면 일부 코드가 로드될 때까지 "기다리고" 선언적으로 로딩 상태를 지정할 수 있습니다. 이를 통해 코드가 간소화되고 사용자에게 부드러운 로딩 경험을 제공할 수 있습니다.
+
+**StartTransition:** 이 기능을 사용하면 특정 업데이트를 "전환"으로 표시하고 우선 순위를 낮출 수 있습니다. 이는 긴급하지 않고 더 긴급한 작업이 있을 때 중단할 수 있는 업데이트에 유용할 수 있습니다.
+
+**UseDeferredValue:** 이 기능을 사용하면 느린 상태 업데이트를 더 빠른 상태 업데이트가 완료될 때까지 연기할 수 있습니다. 이는 무거운 계산이나 네트워크 요청 중에도 UI의 응답성을 유지하는 데 유용할 수 있습니다.
+
+이러한 동시 기능들은 React 18의 핵심입니다. 이들은 응답성이 뛰어나고 사용자 친화적인 앱을 구축하기 위한 새로운 도구와 기술을 제공합니다. 그러나 큰 힘에는 큰 책임이 따릅니다. 이러한 기능들은 새로운 수준의 복잡성을 도입하며 앱이 업데이트되고 렌더링되는 방식을 다르게 생각해야 합니다. 따라서 이러한 개념을 철저히 이해한 후에 사용하시기 바랍니다.
+
+## 동시 모드와 함께하는 React의 미래
+
+React 동시 모드에 대한 탐험을 통해 우리는 많은 것을 배웠습니다. 동시 렌더링의 기본을 이해하는 것부터 React 18의 새로운 기능을 깊이 파고드는 것까지, 동시 모드가 사용자 인터페이스 구축 방식을 혁신할 준비가 되어 있음을 알 수 있었습니다.
+
+동시 모드는 단순한 새로운 기능이 아니라 React에 대한 완전히 새로운 사고방식입니다. 이를 통해 React는 메인 스레드를 차단하지 않고 동시에 여러 작업을 수행할 수 있습니다. 자동 배칭, 스트리밍 서버 렌더링, React Suspense와 같은 강력한 새로운 기능을 도입합니다. 그리고 React에서 렌더링 및 상태 업데이트에 대한 사고방식을 변화시킵니다.
+
+하지만 이러한 새로운 힘에는 새로운 도전 과제가 따릅니다. 동시 모드는 새로운 수준의 복잡성을 도입하며 앱이 업데이트되고 렌더링되는 방식을 다르게 생각해야 합니다. 기존의 가정을 재고하고 코드를 리팩토링해야 할 수 있습니다. 그리고 React 개발자로서 계속 배우고 성장해야 합니다.
+
+하지만 이것이 바로 React의 매력입니다. React는 지속적으로 진화하고 개선되는 살아있는 프로젝트입니다. 더 나은 사용자 인터페이스를 구축하기 위해 열정을 가진 수백만 명의 개발자로 구성된 커뮤니티입니다. 그리고 학습, 성장, 발견의 여정입니다.
+
+따라서 동시 모드와 함께하는 React의 미래를 바라보며, 여러분이 무엇을 구축할지 기대됩니다. 이러한 새로운 기능을 사용하여 더 응답성이 뛰어나고 사용자 친화적인 앱을 어떻게 만들지 기대됩니다. 그리고 이 여정을 여러분과 함께 계속하게 되어 기쁩니다.
+
+React 개발의 모든 잠재력을 발휘할 준비가 되셨나요?
+
+React 애플리케이션을 구축하는 것은 흥미롭지만 시간이 많이 소요될 수 있습니다. [DhiWise React Builder](https://app.dhiwise.com/sign-up?utm_campaign=blog&utm_source=seo&utm_medium=website&utm_term=education&utm_content=deep-dive-into-react-concurrent-mode-exploring-key-features)는 더 적은 시간에 더 많은 것을 이룰 수 있도록 도와줍니다.
+
+오늘 DhiWise 계정을 등록하고 React 애플리케이션 구축의 미래를 경험해보세요.
diff --git a/Aug/article/Leveraging-TypeScript-branded-types-for-stronger-type-checks.md b/Aug/article/Leveraging-TypeScript-branded-types-for-stronger-type-checks.md
new file mode 100644
index 0000000..150f714
--- /dev/null
+++ b/Aug/article/Leveraging-TypeScript-branded-types-for-stronger-type-checks.md
@@ -0,0 +1,284 @@
+## 🔗 [Leveraging TypeScript branded types for stronger type checks](https://blog.logrocket.com/leveraging-typescript-branded-types-stronger-type-checks/)
+
+### 🗓️ 번역 날짜: 2024.08.04
+
+### 🧚 번역한 크루: 렛서(김다은)
+
+---
+
+## TypeScript 브랜드 타입을 활용하여 더 강력한 타입 검사하기
+
+TypeScript의 브랜드 타입은 더 명확한 코드를 작성하고 더 타입 안전한 솔루션을 제공할 수 있게 해줍니다. 이 강력한 기능은 구현하기도 매우 간단하며, 코드 유지 보수를 더 효율적으로 할 수 있게 도와줍니다.
+
+<br/>
+
+![](https://blog.logrocket.com/wp-content/uploads/2024/07/Leveraging-TypeScript-branded-types-stronger-type-checks.png)
+
+<br/>
+
+이 기사에서는 간단한 예제부터 시작하여 몇 가지 고급 사용 사례에 이르기까지, TypeScript 코드에서 브랜드 타입을 효과적으로 사용하는 방법을 배워보겠습니다. 시작해봅시다.
+
+## TypeScript의 브랜드 타입이란 무엇인가요?
+
+TypeScript의 브랜드 타입은 코드 가독성, 맥락, 타입 안전성을 향상시키기 위한 매우 강력하고 효율적인 기능입니다. 이 타입은 기존 타입에 추가 정의를 제공하여 구조와 파일 이름이 유사한 엔티티를 비교할 수 있게 합니다.
+
+예를 들어, 문자열로 사용자 이메일을 저장하는 대신, 이메일 주소에 대한 브랜드 TypeScript 타입을 만들어 일반 문자열과 구분할 수 있습니다. 이렇게 하면 엔티티를 더 체계적으로 검증할 수 있고 코드도 명확해집니다.
+
+브랜드 타입 없이 우리는 일반적으로 대부분의 경우처럼 값들을 제네릭 타입 변수에 저장합니다. 브랜드 타입을 사용하면 해당 변수를 강조하고 코드 전반에서 그 유효성을 유지할 수 있습니다.
+
+## 간단한 TypeScript 브랜드 타입 예제
+
+이메일 주소를 위한 브랜드 타입을 만들어봅시다. type에 브랜드 이름을 붙이는 것으로 브랜드 타입을 생성할 수 있습니다. 이 경우, 이메일 주소에 대한 브랜드 타입은 다음과 같습니다:
+
+```ts
+type EmailAddress = string & { __brand: 'EmailAddress' };
+```
+
+여기서, 우리는 \_\_brand 이름 'EmailAddress'를 붙여서 브랜드 타입 EmailAddress를 만들었습니다.
+
+브랜드 타입을 만들 때 제네릭 문법은 필요없다는 사실을 명심하세요. 브랜드 타입의 제네릭(문자열, 숫자 등)에 따라 달라집니다. \_\_brand 문법도 예약어가 아니므로 \_\_brand 외의 다른 변수 이름을 사용할 수 있습니다.
+
+이제 EmailAddress 타입의 객체를 만들고 문자열을 전달해 봅시다:
+
+```ts
+const email: EmailAddress = 'asd'; // error
+```
+
+보시는 바와 같이 타입 에러가 발생합니다.
+
+```shell
+Type 'string' is not assignable to type 'EmailAddress.' Type 'string' is not assignable to type '{ __brand: "EmailAddress"; }.'
+```
+
+이를 고치기 위해서 이메일 주소에 대한 기본적인 유효성 검사를 생성해봅시다.
+
+```ts
+const isEmailAddress = (email: string): email is EmailAddress => {
+  return email.endsWith('@gmail.com');
+};
+```
+
+여기서 boolean 값을 반환하는 대신, `email is EmailAddress`를 반환하고 있습니다. 이는 함수가 `true`를 반환하면 email이 `EmailAddress` [타입으로 캐스팅](https://blog.logrocket.com/how-to-perform-type-casting-typescript/)된다는 의미입니다. 이를 통해 문자열에 대해 어떤 작업을 수행하기 전에 유효성을 검증할 수 있습니다.
+
+```ts
+const sendVerificationEmail = (email: EmailAddress) => {
+  //...
+};
+const signUp = (email: string, password: string) => {
+  //...
+  if (isEmailAddress(email)) {
+    sendVerificationEmail(email); // pass
+  }
+  sendVerificationEmail(email); // error
+};
+```
+
+보시는 바와 같이, 오류는 if 조건문 안에서 보이지 않지만, 해당 조건문의 범위를 벗어나면 발생합니다.
+
+`assert`를 사용하여 이메일 주소를 검증할 수도 있습니다. 이렇게 하면 검증이 통과되지 않을 경우 오류를 발생시키고자 할 때 유용할 수 있습니다.
+
+```ts
+function assertEmailAddress(email: string): asserts email is EmailAddress {
+  if (!email.endsWith('@gmail.com')) {
+    throw new Error('Not an email addres');
+  }
+}
+
+const sendVerificationEmail = (email: EmailAddress) => {
+  //...
+};
+
+const signUp = (email: string, password: string) => {
+  //...
+  assertEmailAddress(email);
+  sendVerificationEmail(email); // ok
+};
+```
+
+여기서 보시다시피, 반환 타입으로 `asserts email is EmailAddress`를 명시하고 있습니다. 이는 검증이 통과하면 이메일 주소가 브랜드 타입 `EmailAddress`임을 보장합니다.
+
+## TypeScript에서 브랜드 타입의 고급 사용 사례
+
+위 예시는 브랜드 타입의 간단한 시연입니다. 우리는 이를 더 고급 사례에서도 사용할 수 있습니다. 예시를 하나 보겠습니다.
+
+먼저, 다른 타입에 붙일 수 있는 공통 Branded 타입을 선언해 봅시다:
+
+```ts
+declare const __brand: unique symbol;
+type Brand<B> = { [__brand]: B };
+export type Branded<T, B> = T & Brand<B>;
+```
+
+여기서, 심볼을 사용해 각 타입을 구분하는 고유한 브랜드를 만듭니다. 심볼은 다른 어떤 심볼과도 구별되는 유일한 심볼임을 보장합니다. 이는 새로운 심볼을 생성할 때마다 다른 심볼과 구별된다는 것을 의미합니다. 다음은 이를 설명하는 예제입니다:
+
+```ts
+// 브랜드로 사용할 고유 심볼 정의
+const metersSymbol: unique symbol = Symbol('meters');
+const kilometersSymbol: unique symbol = Symbol('kilometers');
+
+// 브랜드 타입 정의
+type Meters = number & { [metersSymbol]: void };
+type Kilometers = number & { [kilometersSymbol]: void };
+
+// 브랜드 값을 생성하는 도우미 함수
+function meters(value: number): Meters {
+  return value as Meters;
+}
+
+function kilometers(value: number): Kilometers {
+  return value as Kilometers;
+}
+
+// 브랜드 타입을 가진 변수들
+const distanceInMeters: Meters = meters(100);
+const distanceInKilometers: Kilometers = kilometers(1);
+
+// 아래 할당은 타입 오류를 발생시킴
+const wrongDistance: Meters = distanceInKilometers;
+const anotherWrongDistance: Kilometers = distanceInMeters;
+
+// 올바른 사용법
+const anotherDistanceInMeters: Meters = meters(200);
+const anotherDistanceInKilometers: Kilometers = kilometers(2);
+
+console.log(distanceInMeters, distanceInKilometers);
+```
+
+공통 Branded 타입 인터페이스를 가지면 TypeScript에서 여러 브랜드 타입을 동시에 생성할 수 있어, 코드 구현을 줄이고 코드를 훨씬 깔끔하게 만들 수 있습니다. 이제 위의 이메일 검증 예제를 확장하여, 이 공통 Branded 타입을 사용해 EmailAddress 브랜드를 다음과 같이 정의할 수 있습니다:
+
+```ts
+type EmailAddress = Branded<string, 'EmailAddress'>;
+
+const isEmailAddress = (email: string): email is EmailAddress => {
+  return email.endsWith('@gmail.com');
+};
+
+const sendEmail = (email: EmailAddress) => {
+  // ...
+};
+
+const signUp = (email: string, password: string) => {
+  if (isEmailAddress(email)) {
+    // 인증 메일 전송
+    sendEmail(email);
+  }
+};
+```
+
+이제 이 Branded 타입을 사용하여 새로운 브랜드 TypeScript 타입을 만들 수 있습니다. Branded 타입을 사용하는 또 다른 예를 살펴봅시다. 사용자가 게시물을 좋아할 수 있도록 하는 함수를 작성한다고 가정해 보겠습니다. userId와 postId 모두에 Branded 타입을 사용할 수 있습니다:
+
+```ts
+type UserId = Branded<string, 'UserId'>;
+type PostId = Branded<string, 'PostId'>;
+
+type User = {
+  userId: UserId;
+  username: string;
+  email: string;
+};
+
+type Post = {
+  postId: PostId;
+  title: string;
+  description: string;
+  likes: Like[];
+};
+
+type Like = {
+  userId: UserId;
+  postId: PostId;
+};
+
+const likePost = async (userId: UserId, postId: PostId) => {
+  const response = await fetch(`/posts/${postId}/like/${userId}`, {
+    method: 'post',
+  });
+  return await response.json();
+};
+
+// 가상의 객체
+const user: User = {
+  userId: '1' as UserId,
+  email: 'a@email.com',
+  username: 'User1',
+};
+const post: Post = {
+  postId: '2' as PostId,
+  title: 'Sample Title',
+  description: 'Sample post description',
+  likes: [],
+};
+
+likePost(user.userId, post.postId); // ok
+likePost(post.postId, user.userId); // error
+```
+
+## TypeScript 5.5-beta에서 브랜드 타입으로 작업하기
+
+새로운 TypeScript 5.5-beta 릴리스에서는 TypeScript의 제어 흐름 분석이 코드가 진행됨에 따라 변수의 타입이 어떻게 변하는지 추적할 수 있게 되었습니다.
+
+이는 변수의 타입이 코드 로직에 따라 변경될 수 있으며, TypeScript가 코드 로직의 각 수정 체인에서 변수 타입을 추적한다는 것을 의미합니다. 변수가 가질 수 있는 두 가지 가능한 타입이 있는 경우, 필요한 조건을 적용하여 변수의 타입을 분리할 수 있습니다.
+
+아래 코드를 보면서 이해해봅시다:
+
+```tsx
+interface ItemProps {
+  // ...
+}
+
+declare const items: Map<string, ItemProps>;
+
+function getItem(id: string) {
+  const item = items.get(id); // item은 ItemProps | undefined 타입으로 선언됨
+  if (item) {
+    // if 문 안에서 item은 ItemProps 타입을 가짐
+  } else {
+    // 여기서 item은 undefined 타입을 가짐
+  }
+}
+
+function getAllItemsByIds(ids: string[]): ItemProps[] {
+  return ids.map((id) => items.get(id)).filter((item) => item !== undefined); // 이전에는 이런 오류가 발생했습니다: Type '(ItemProps | undefined)[]' is not assignable to type 'ItemProps[]'. Type 'ItemProps | undefined' is not assignable to type 'ItemProps'. Type 'undefined' is not assignable to type 'ItemProps'
+}
+```
+
+다음 예제를 살펴보겠습니다. 이 예제에서는 이메일 주소 목록을 가져와서 검증된 이메일 주소를 데이터베이스에 저장합니다. 이전 예제를 사용하여 브랜드 EmailAddress 타입을 생성하고 검증된 이메일을 데이터베이스에 저장할 수 있습니다:
+
+```ts
+type EmailAddress = Branded<string, 'EmailAddress'>;
+const isEmailAddress = (email: string): email is EmailAddress => {
+  return email.endsWith('@gmail.com');
+};
+
+const storeToDb = async (emails: EmailAddress[]) => {
+  const response = await fetch('/store-to-db', {
+    body: JSON.stringify({
+      emails,
+    }),
+    method: 'post',
+  });
+  return await response.json();
+};
+
+const emails = ['a@gmail.com', 'b@gmail.com', '...'];
+const validatedEmails = emails.filter((email) => isEmailAddress(email));
+storeToDb(validatedEmails); // error
+```
+
+여기서 검증된 이메일 주소를 validatedEmails 배열에 나열하고 있지만, storeToDb 함수에 전달할 때 오류가 발생하는 것을 볼 수 있습니다. 이 오류는 특히 v5.5-beta 이전의 TypeScript 버전을 사용할 때 나타납니다.
+
+낮은 버전의 TypeScript에서는 validatedEmails 배열의 타입이 원래 변수인 emails 배열에서 파생됩니다. 그래서 validatedEmails 배열의 타입이 string[]로 나타납니다. 그러나 이 문제는 현재 TypeScript 베타 버전(현재 기준으로 5.5-beta)에서 해결되었습니다.
+
+현재 베타 버전에서는 검증된 이메일을 필터링한 후에 validatedEmails가 자동으로 EmailAddress[]로 타입 캐스팅됩니다. 따라서 TypeScript 5.5-beta 버전에서는 오류가 발생하지 않습니다. 프로젝트에 TypeScript 베타 버전을 설치하려면 터미널에서 다음 명령어를 실행하십시오:
+
+```shell
+npm install -D typescript@beta
+```
+
+<br/>
+
+## 결론
+
+브랜드 타입은 TypeScript에서 매우 유용한 기능입니다. 이들은 런타임 타입 안전성을 제공하여 코드 무결성을 보장하고 가독성을 향상시킵니다. 또한 도메인 수준에서 오류를 발생시켜 코드의 버그를 줄이는 데 매우 유용합니다.
+
+브랜드 타입을 쉽게 검증하고, 검증된 객체를 프로젝트 전반에 걸쳐 안전하게 사용할 수 있습니다. 최신 TypeScript 베타 버전 기능을 사용하면 코딩 경험을 더욱 원활하게 활용할 수 있습니다.
diff --git a/Aug/article/Server-Component.md b/Aug/article/Server-Component.md
new file mode 100644
index 0000000..45cd5a2
--- /dev/null
+++ b/Aug/article/Server-Component.md
@@ -0,0 +1,122 @@
+## 🔗 [Server Components](https://nextjs.org/docs/app/building-your-application/rendering/server-components)
+
+### 🗓️ 번역 날짜: 2024.08.04
+
+### 🧚 번역한 크루: 러기(박정우)
+
+---
+
+## 서버 컴포넌트
+
+React 서버 컴포넌트를 사용하면 서버에서 UI를 렌더링하고 선택적으로 캐시할 수 있습니다. Next.js에서는 라우트 세그먼트에 따라 렌더링 작업을 분할하여 스트리밍 및 부분 렌더링을 가능하게 하며, 세 가지 서버 렌더링 전략이 있습니다:
+
+- 정적 렌더링
+- 동적 렌더링
+- 스트리밍
+
+이 페이지에서는 서버 컴포넌트의 작동 방식, 사용 시기, 다양한 서버 렌더링 전략에 대해 설명합니다.
+
+## 서버 렌더링의 이점
+
+서버에서 렌더링 작업을 수행하는 것은 다음과 같은 몇 가지 이점을 제공합니다:
+
+- **데이터 가져오기**: 서버 컴포넌트를 사용하면 데이터 소스에 가까운 서버에서 데이터를 가져올 수 있습니다. 이를 통해 렌더링에 필요한 데이터를 가져오는 시간을 단축하고 클라이언트에서 요청해야 하는 횟수를 줄여 성능을 개선할 수 있습니다.
+- **보안**: 서버 컴포넌트를 사용하면 토큰이나 API 키와 같은 민감한 데이터와 로직을 클라이언트에 노출시키지 않고 서버에 유지할 수 있습니다.
+- **캐싱**: 서버에서 렌더링하면 결과를 캐시하고 이후 요청 및 사용자 간에 재사용할 수 있습니다. 이를 통해 성능을 개선하고 각 요청마다 렌더링 및 데이터 가져오기를 줄여 비용을 절감할 수 있습니다.
+- **성능**: 서버 컴포넌트를 사용하면 기본 성능을 최적화하는 추가 도구를 제공합니다. 예를 들어, 완전히 클라이언트 컴포넌트로 구성된 앱에서 상호작용이 없는 UI 부분을 서버 컴포넌트로 이동하면 클라이언트 측 JavaScript 양을 줄일 수 있습니다. 이는 느린 인터넷이나 성능이 낮은 장치를 사용하는 사용자에게 유리합니다.
+- **초기 페이지 로드 및 첫 번째 콘텐츠 페인트(FCP)**: 서버에서 HTML을 생성하여 사용자가 페이지를 즉시 볼 수 있도록 합니다. 이는 클라이언트가 페이지를 렌더링하는 데 필요한 JavaScript를 다운로드, 파싱, 실행하는 것을 기다리지 않게 합니다.
+- **검색 엔진 최적화(SEO) 및 소셜 네트워크 공유 가능성**: 렌더링된 HTML은 검색 엔진 봇이 페이지를 인덱싱하고 소셜 네트워크 봇이 페이지의 소셜 카드 미리보기를 생성하는 데 사용할 수 있습니다.
+- **스트리밍**: 서버 컴포넌트를 사용하면 렌더링 작업을 청크로 분할하고 준비되는 대로 클라이언트에 스트리밍할 수 있습니다. 이를 통해 전체 페이지가 서버에서 렌더링될 때까지 기다리지 않고 페이지의 일부를 먼저 볼 수 있습니다.
+
+## Next.js에서 서버 컴포넌트 사용
+
+기본적으로 Next.js는 서버 컴포넌트를 사용합니다. 이를 통해 추가적인 설정 없이 자동으로 서버 렌더링을 구현할 수 있으며, 필요할 때 클라이언트 컴포넌트를 선택할 수 있습니다.
+
+---
+
+## 서버 컴포넌트는 어떻게 렌더링되나요?
+
+서버에서 Next.js는 React의 API를 사용하여 렌더링을 조정합니다. 렌더링 작업은 개별 라우트 세그먼트 및 서스펜스 경계를 기준으로 청크로 분할됩니다.
+
+각 청크는 두 단계로 렌더링됩니다:
+
+1. React는 서버 컴포넌트를 특수 데이터 형식인 React 서버 컴포넌트 페이로드(RSC Payload)로 렌더링합니다.
+2. Next.js는 RSC 페이로드와 클라이언트 컴포넌트 JavaScript 지침을 사용하여 서버에서 HTML을 렌더링합니다.
+
+그런 다음 클라이언트에서는:
+
+1. HTML을 사용하여 초기 페이지 로드 시 빠르고 비상호작용적인 미리보기를 즉시 표시합니다.
+2. React 서버 컴포넌트 페이로드를 사용하여 클라이언트와 서버 컴포넌트 트리를 조정하고 DOM을 업데이트합니다.
+3. hydrate를 위해 JavaScript 지침을 사용하여 클라이언트 컴포넌트를 활성화하고 애플리케이션을 상호작용 가능하게 만듭니다.
+
+### React 서버 컴포넌트 페이로드(RSC)란 무엇인가요?
+
+RSC 페이로드는 렌더링된 React 서버 컴포넌트 트리의 간결한 바이너리 표현입니다. 이는 클라이언트에서 React가 브라우저의 DOM을 업데이트하는 데 사용됩니다. RSC 페이로드는 다음을 포함합니다:
+
+- 서버 컴포넌트의 렌더링된 결과
+- 클라이언트 컴포넌트가 렌더링될 자리 표시자 및 해당 JavaScript 파일에 대한 참조
+- 서버 컴포넌트에서 클라이언트 컴포넌트로 전달된 모든 props
+
+## 서버 렌더링 전략
+
+서버 렌더링에는 세 가지 하위 집합이 있습니다: 정적, 동적 및 스트리밍.
+
+### 정적 렌더링 (기본값)
+
+정적 렌더링에서는 라우트가 빌드 시 또는 데이터 재검증 후 백그라운드에서 렌더링됩니다. 결과는 캐시되어 콘텐츠 전달 네트워크(CDN)에 푸시될 수 있습니다. 이 최적화는 렌더링 작업의 결과를 사용자 및 서버 요청 간에 공유할 수 있게 합니다.
+
+정적 렌더링은 라우트의 데이터가 사용자에게 개인화되지 않고 빌드 시 알 수 있는 경우에 유용합니다. 예를 들어 정적 블로그 게시물이나 제품 페이지 등이 있습니다.
+
+### 동적 렌더링
+
+동적 렌더링에서는 라우트가 요청 시마다 사용자에게 맞춰 렌더링됩니다. 동적 렌더링은 쿠키나 URL의 검색 매개변수와 같은 요청 시에만 알 수 있는 정보를 포함하는 라우트에 유용합니다.
+
+### 캐시된 데이터가 있는 동적 라우트
+
+대부분의 웹사이트에서 라우트는 완전히 정적이거나 완전히 동적이지 않습니다. 예를 들어, 간격마다 재검증되는 캐시된 제품 데이터를 사용하는 전자 상거래 페이지가 있을 수 있지만, 캐시되지 않은 개인화된 고객 데이터도 포함될 수 있습니다.
+
+Next.js에서는 캐시된 데이터와 캐시되지 않은 데이터를 모두 포함하는 동적으로 렌더링된 라우트를 가질 수 있습니다. 이는 RSC 페이로드와 데이터가 별도로 캐시되기 때문입니다. 이를 통해 모든 데이터를 요청 시 가져오는 성능 문제 없이 동적 렌더링을 선택할 수 있습니다.
+
+전체 라우트 캐시 및 데이터 캐시에 대해 자세히 알아보세요.
+
+[Building Your Application: Caching - full route cache](https://nextjs.org/docs/app/building-your-application/caching#full-route-cache)
+
+[Building Your Application: Caching - data cache](https://nextjs.org/docs/app/building-your-application/caching#data-cache)
+
+### 동적 렌더링으로 전환
+
+렌더링 중에 동적 함수나 캐시되지 않은 데이터 요청이 발견되면 Next.js는 전체 라우트를 동적으로 렌더링하도록 전환합니다. 이 표는 동적 함수와 데이터 캐싱이 라우트의 정적 또는 동적 렌더링 여부에 어떻게 영향을 미치는지 요약합니다:
+
+| 동적 함수 | 데이터        | 라우트            |
+| --------- | ------------- | ----------------- |
+| 아니요    | 캐시됨        | 정적으로 렌더링됨 |
+| 예        | 캐시됨        | 동적으로 렌더링됨 |
+| 아니요    | 캐시되지 않음 | 동적으로 렌더링됨 |
+| 예        | 캐시되지 않음 | 동적으로 렌더링됨 |
+
+위의 표에서, 라우트가 완전히 정적이 되려면 모든 데이터가 캐시되어야 합니다. 그러나 캐시된 데이터와 캐시되지 않은 데이터 가져오기를 모두 사용하는 동적으로 렌더링된 라우트를 가질 수 있습니다.
+
+개발자로서 정적 렌더링과 동적 렌더링을 선택할 필요는 없습니다. Next.js는 사용된 기능과 API에 따라 각 라우트에 최적의 렌더링 전략을 자동으로 선택합니다. 대신 특정 데이터를 캐시하거나 재검증할 때와 UI의 일부를 스트리밍할 때를 선택합니다.
+
+### 동적 함수
+
+동적 함수는 요청 시에만 알 수 있는 정보(예: 사용자의 쿠키, 현재 요청 헤더 또는 URL의 검색 매개변수)에 의존합니다. Next.js에서 이러한 동적 함수는 다음과 같습니다:
+
+- `cookies()`와 `headers()`: 서버 컴포넌트에서 이를 사용하면 전체 라우트가 요청 시에 동적으로 렌더링됩니다.
+- `searchParams`: 페이지에서 `searchParams` prop을 사용하면 페이지가 요청 시에 동적으로 렌더링됩니다.
+
+이들 중 하나를 사용하면 전체 라우트가 요청 시에 동적으로 렌더링됩니다.
+
+### 스트리밍
+
+![streaming](https://nextjs.org/_next/image?url=%2Fdocs%2Fdark%2Fsequential-parallel-data-fetching.png&w=3840&q=75)
+
+스트리밍은 서버에서 UI를 점진적으로 렌더링할 수 있게 합니다. 작업은 청크로 분할되고 준비되는 대로 클라이언트에 스트리밍됩니다. 이를 통해 전체 콘텐츠가 렌더링될 때까지 기다리지 않고 페이지의 일부를 즉시 볼 수 있습니다.
+
+![streaming2](https://nextjs.org/_next/image?url=%2Fdocs%2Fdark%2Fserver-rendering-with-streaming.png&w=3840&q=75)
+
+스트리밍은 Next.js App Router에 기본적으로 내장되어 있습니다. 이는 초기 페이지 로딩 성능을 향상시키고, 전체 라우트 렌더링을 차단할 느린 데이터 가져오기에 의존하는 UI를 개선합니다. 예를 들어, 제품 페이지의 리뷰가 해당합니다.
+
+라우트 세그먼트를 스트리밍하려면 `loading.js`와 React 서스펜스를 사용하여 UI 컴포넌트를 사용할 수 있습니다. 자세한 내용은 로딩 UI 및 스트리밍 섹션을 참조하세요.
+
+[Routing: Loading UI and Streaming](https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming)