diff --git a/00_Raw/Fiber 아키텍처와 동시성 (Concurrent Rendering).md b/10_Wiki/Topics/Frontend_Mastery/Fiber 아키텍처와 동시성 (Concurrent Rendering).md similarity index 100% rename from 00_Raw/Fiber 아키텍처와 동시성 (Concurrent Rendering).md rename to 10_Wiki/Topics/Frontend_Mastery/Fiber 아키텍처와 동시성 (Concurrent Rendering).md diff --git a/00_Raw/Hydration 성능 최적화.md b/10_Wiki/Topics/Frontend_Mastery/Hydration 성능 최적화.md similarity index 100% rename from 00_Raw/Hydration 성능 최적화.md rename to 10_Wiki/Topics/Frontend_Mastery/Hydration 성능 최적화.md diff --git a/10_Wiki/Topics/Frontend_Mastery/React Fiber 및 동시성 렌더링.md b/10_Wiki/Topics/Frontend_Mastery/React Fiber 및 동시성 렌더링.md new file mode 100644 index 00000000..511cf74e --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/React Fiber 및 동시성 렌더링.md @@ -0,0 +1,32 @@ +# [[React Fiber 및 동시성 렌더링]] + +## 📌 Brief 시 Summary +React Fiber는 동기식 렌더링의 한계를 극복하고 동시성 렌더링(Concurrent rendering)을 지원하기 위해 도입된 React의 재조정(Reconciliation) 엔진 아키텍처이다 [1, 2]. 전체 컴포넌트 트리를 단일 호출로 처리하던 기존 방식과 달리, 렌더링 작업을 '파이버 노드(Fiber node)'라는 작은 단위로 쪼개어 스케줄링한다 [3, 4]. 이를 통해 메인 스레드를 차단하지 않고 렌더링을 일시 정지하거나 재개할 수 있으며, 타자 입력이나 클릭과 같은 긴급한 업데이트를 우선적으로 처리하여 반응성 높은 UI를 제공할 수 있다 [3, 5, 6]. + +## 📖 Core Content +**도입 배경 및 문제점 해결** +Fiber 아키텍처 이전의 React는 '스택 재조정자(Stack reconciler)'를 사용하여 전체 컴포넌트 트리를 한 번의 재귀 호출로 처리했다 [3]. 대규모 애플리케이션의 경우 이러한 방식은 메인 스레드를 16.6ms 이상 차단하여 UI의 애니메이션이나 사용자 입력 반응을 지연시키는 문제를 발생시켰다 [3]. React 16부터 도입된 Fiber는 렌더링을 완전히 재작성하여, 작업을 더 작은 청크로 나누고 여러 프레임에 걸쳐 분산할 수 있도록 설계되었다 [1, 4]. + +**작업 루프(Work Loop)와 렌더링의 두 단계** +React Fiber는 작업 루프를 통해 렌더링 단위를 점진적으로 처리하며, 전체 과정은 두 가지 주요 단계로 나뉜다 [4, 7]. +* **렌더 단계(Render Phase):** 이 단계는 중단할 수 있으며(Interruptible), DOM 변경 없이 순수한 연산만 수행된다 [7]. React는 Fiber 트리를 순회하면서(`beginWork`, `completeWork`) 이전 상태와 새로운 상태를 비교한다 [7, 8]. 이때, 메인 스레드가 바쁘거나 우선순위가 높은 상호작용이 들어오면 작업을 일시 정지, 재개 또는 폐기(WIP, Work-In-Progress 관리)할 수 있다 [9]. 변경이 필요한 노드에는 이펙트 태그(Placement, Update, Deletion 등)가 지정되며 이펙트 목록(Effect list)이 만들어진다 [7, 10, 11]. +* **커밋 단계(Commit Phase):** 이 단계는 동기적이고 중단 불가능(Uninterruptible)하다 [12]. 렌더 단계에서 생성된 이펙트 목록을 바탕으로 실제 DOM 변형이 이루어진다 [10, 12]. 이 단계는 DOM 변형 전(Before Mutation), 변형(Mutation), 레이아웃 이펙트(`useLayoutEffect` 실행), 패시브 이펙트(`useEffect` 실행) 순으로 처리된다 [13]. + +**우선순위 스케줄링과 차선(Lane) 모델** +Fiber는 '차선(Lanes)'이라고 불리는 비트마스크(Bitmask) 기반의 우선순위 시스템을 사용하여 동시성 작업을 관리한다 [11, 14]. +* **우선순위 레벨:** 클릭이나 타이핑 등 즉각 반응이 필요한 작업은 Sync 레벨, 스크롤이나 호버는 InputContinuous, 네트워크 응답 등은 Default, 오프스크린 렌더링은 Idle 레벨로 구분된다 [5, 15]. +* 이를 통해 낮은 우선순위의 작업을 처리하는 중에도 우선순위가 높은 상호작용이 들어오면 실행 중인 작업을 멈추고 중요한 작업을 먼저 렌더링하게 된다 [6]. + +**React 18 이후의 동시성 기능 활용** +이러한 아키텍처를 기반으로 React 18 및 19에서는 개발자가 렌더링 우선순위를 직접 조정할 수 있는 동시성 훅을 제공한다. +* `useTransition`: 특정 상태 업데이트를 낮은 우선순위로 지정하여, 무거운 필터링 작업이 진행되는 동안에도 타이핑 등의 긴급한 입력이 지연되지 않도록 한다 [16, 17]. +* `useDeferredValue`: 외부에서 전달받은 값의 소비를 지연시켜 무거운 렌더링 중에 UI가 동결되는 것을 막는다 [17, 18]. +* 또한 동시성 렌더링은 클라이언트의 Hydration 과정에서도 메인 스레드를 심하게 막지 않고 작은 청크로 쪼개어 렌더링할 수 있도록 돕는다 [19]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Reconciliation]], [[Virtual DOM]], [[Time-Slicing]], [[Hydration]] +- **Projects/Contexts:** [[React 18 Concurrent Features]], [[useTransition 및 useDeferredValue]] +- **Contradictions/Notes:** 제공된 소스 전반에 걸쳐 Fiber 아키텍처와 동시성 렌더링의 매커니즘, 장점에 대해 일관된 설명을 제공하고 있으며, 상충되는 의견은 존재하지 않습니다. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 재조정(Reconciliation).md b/10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 재조정(Reconciliation).md new file mode 100644 index 00000000..f590f355 --- /dev/null +++ b/10_Wiki/Topics/Frontend_Mastery/가상 DOM (Virtual DOM) 및 재조정(Reconciliation).md @@ -0,0 +1,30 @@ +# [[가상 DOM (Virtual DOM) 및 재조정(Reconciliation)]] + +## 📌 Brief Summary +가상 DOM(Virtual DOM)은 메모리 상에 사용자 인터페이스(UI) 요소들을 일반 자바스크립트 객체 형태로 가볍게 표현한 개념입니다 [1, 2]. 재조정(Reconciliation)은 React가 변경 사항을 감지하기 위해 새로 생성된 가상 DOM과 이전 버전의 가상 DOM을 비교(diff)하여, 실제 DOM을 가장 효율적인 방식으로 업데이트하는 프로세스를 의미합니다 [1-3]. 이 방식을 통해 개발자는 선언적 API를 사용하여 UI의 상태만 정의하면 되며, 수동적인 DOM 조작과 이로 인해 발생하는 렌더링 비효율성을 신경 쓰지 않아도 됩니다 [1, 3, 4]. + +## 📖 Core Content + +* **가상 DOM의 필요성과 역할** + 실제 DOM을 직접 수정하는 작업은 브라우저의 레이아웃(Reflow) 및 페인트(Repaint) 단계를 매번 유발하기 때문에 본질적으로 느립니다 [1, 5]. React는 가상 DOM이라는 메모리 상의 이상적인 UI 표현을 유지하며, 이를 통해 선언된 상태와 실제 DOM이 일치하도록 최소한의 업데이트만 수행하여 렌더링을 최적화합니다 [1, 3]. 설계상 가상 DOM 트리는 불변(immutable) 객체로 취급됩니다 [6]. + +* **휴리스틱 Diff 알고리즘과 $O(n)$ 최적화** + 두 개의 트리를 비교하여 최소한의 연산으로 변환하는 일반적인 알고리즘은 $O(n^3)$의 시간 복잡도를 가지므로, 요소가 많은 실제 애플리케이션에 적용하기에는 비용이 너무 큽니다 [7, 8]. 이에 React는 다음 두 가지 가정을 바탕으로 $O(n)$ 복잡도로 동작하는 휴리스틱 기반의 diff 알고리즘을 사용합니다 [7, 8]. + 1. **다른 타입의 요소**: 루트 요소의 타입이 다르면(예: ``에서 ``로 변경), React는 이전 트리를 완전히 파괴하고 새로운 트리를 처음부터 구축합니다 [7, 9]. 반면, 같은 타입의 DOM 요소인 경우에는 유지하면서 변경된 속성(예: className이나 특정 style)만 업데이트합니다 [10]. + 2. **Key 속성**: 여러 번의 렌더링 사이에서 리스트 내의 어떤 자식 요소가 안정적으로 유지되는지 식별하기 위해 `key` 속성을 사용합니다 [7, 8]. 자식 요소의 순서가 변경되거나 추가될 때 `key`를 활용하면 기존 하위 트리를 파괴하지 않고 요소의 이동만으로 트리를 효율적으로 재구성할 수 있습니다 [11, 12]. + +* **React Fiber와 점진적 재조정(Incremental Reconciliation)** + React 16부터는 기존의 동기식 차단(synchronous blocking) 문제를 해결하고 동시성 렌더링(concurrent rendering)을 지원하기 위해, 재조정 엔진을 완전히 재작성한 'Fiber 아키텍처'를 도입했습니다 [13-15]. Fiber 기반의 재조정 과정은 크게 두 단계로 나뉩니다. + 1. **렌더 단계(Render phase)**: DOM을 조작하지 않는 순수한 연산 과정으로, 중단이나 취소, 재시작이 가능합니다. 이 단계에서는 Fiber 트리를 순회하며 이전 상태와 새로운 상태의 차이를 계산하고, 업데이트나 삽입 등 변화가 필요한 요소들의 효과 목록(effect list)을 구축합니다 [16]. + 2. **커밋 단계(Commit phase)**: 렌더 단계와 달리 동기적으로 작동하며 중단할 수 없습니다. 구축된 효과 목록을 바탕으로 모든 변경 사항과 실제 DOM 조작(삽입, 삭제, 속성 업데이트)을 한 번에 적용합니다 [17]. + +* **재조정 알고리즘의 트레이드오프** + 재조정 알고리즘은 휴리스틱에 의존하기 때문에 주어진 가정이 충족되지 않으면 성능이 저하될 수 있습니다 [18]. 예를 들어, 하위 트리가 형제 요소 사이에서 이동한 것은 파악할 수 있지만, 트리 내의 완전히 다른 위치로 이동한 것은 인식하지 못해 전체 하위 트리를 다시 렌더링하게 됩니다 [19]. 또한 인덱스를 `key`로 사용하거나 예측 불가능한 불안정한 키를 사용할 경우, 불필요한 DOM 노드 및 컴포넌트 재생성으로 인해 성능 저하와 자식 컴포넌트의 상태 손실이 발생할 수 있습니다 [18, 20]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[React Fiber 아키텍처]], [[브라우저 렌더링 과정 (Critical Rendering Path)]], [[Reflow 및 Repaint]] +- **Projects/Contexts:** [[프론트엔드 기초 구조 이해 핵심 목적]] +- **Contradictions/Notes:** 소스 자료에 따르면, 두 트리를 비교하는 완벽한 트리 변환 알고리즘은 이론적으로 $O(n^3)$의 복잡도를 요구하여 브라우저에서 실행하기 어렵습니다. 하지만 React는 '타입(Type)'과 '키(Key)'라는 두 가지 단순하고 강력한 가정만으로 알고리즘 복잡도를 $O(n)$으로 극적으로 줄임으로써 빠른 성능을 확보했습니다 [7, 8, 21]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/00_Raw/가상 DOM과 재조정 (Reconciliation).md b/10_Wiki/Topics/Frontend_Mastery/가상 DOM과 재조정 (Reconciliation).md similarity index 100% rename from 00_Raw/가상 DOM과 재조정 (Reconciliation).md rename to 10_Wiki/Topics/Frontend_Mastery/가상 DOM과 재조정 (Reconciliation).md diff --git a/00_Raw/단일 페이지 애플리케이션 (SPA).md b/10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션 (SPA).md similarity index 100% rename from 00_Raw/단일 페이지 애플리케이션 (SPA).md rename to 10_Wiki/Topics/Frontend_Mastery/단일 페이지 애플리케이션 (SPA).md diff --git a/00_Raw/브라우저 렌더링 프로세스 (CRP).md b/10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 프로세스 (CRP).md similarity index 100% rename from 00_Raw/브라우저 렌더링 프로세스 (CRP).md rename to 10_Wiki/Topics/Frontend_Mastery/브라우저 렌더링 프로세스 (CRP).md diff --git a/00_Raw/성능 및 SEO 최적화 프로젝트.md b/10_Wiki/Topics/Frontend_Mastery/성능 및 SEO 최적화 프로젝트.md similarity index 100% rename from 00_Raw/성능 및 SEO 최적화 프로젝트.md rename to 10_Wiki/Topics/Frontend_Mastery/성능 및 SEO 최적화 프로젝트.md diff --git a/00_Raw/웹 프론트엔드 아키텍처 설계.md b/10_Wiki/Topics/Frontend_Mastery/웹 프론트엔드 아키텍처 설계.md similarity index 100% rename from 00_Raw/웹 프론트엔드 아키텍처 설계.md rename to 10_Wiki/Topics/Frontend_Mastery/웹 프론트엔드 아키텍처 설계.md diff --git a/00_Raw/중요 렌더링 경로 (Critical Rendering Path).md b/10_Wiki/Topics/Frontend_Mastery/중요 렌더링 경로 (Critical Rendering Path).md similarity index 100% rename from 00_Raw/중요 렌더링 경로 (Critical Rendering Path).md rename to 10_Wiki/Topics/Frontend_Mastery/중요 렌더링 경로 (Critical Rendering Path).md diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/Hydration 성능 최적화.md b/10_Wiki/Topics_Art/UI_UX_Assets/Hydration 성능 최적화.md new file mode 100644 index 00000000..05a683d4 --- /dev/null +++ b/10_Wiki/Topics_Art/UI_UX_Assets/Hydration 성능 최적화.md @@ -0,0 +1,34 @@ +# [[Hydration 성능 최적화]] + +## 📌 Brief Summary +Hydration은 서버에서 렌더링된 정적 HTML 뼈대에 JavaScript를 실행하고 이벤트 리스너를 연결하여 완전한 상호작용이 가능한 애플리케이션으로 변환하는 과정입니다 [1, 2]. 기본적으로 React는 페이지 전체를 한 번에 Hydration하면서 메인 스레드를 차단하여 TBT(Total Blocking Time)와 TTI(Time to Interactive) 지표를 악화시킬 수 있습니다 [3]. 이를 해결하기 위해 선택적 Hydration, 지연 로딩, React Server Components(RSC) 등의 최적화 기법을 도입하여 초기 로드 성능과 상호작용성을 극대화할 수 있습니다 [4-6]. + +## 📖 Core Content +* **Hydration의 개념 및 주요 성능 병목 현상:** + * Hydration은 SSR(Server-Side Rendering) 환경에서 서버가 생성한 HTML을 클라이언트가 넘겨받아 상호작용을 부여하는 필수적인 과정입니다 [2, 3]. + * 문제는 React가 기본적으로 시야에 보이지 않는 컴포넌트까지 포함하여 페이지 전체를 한 번에 Hydration 하려 한다는 점입니다 [3]. 이로 인해 JavaScript 실행이 메인 스레드를 장시간 점유하게 되고, 결과적으로 TBT(Total Blocking Time), FID(First Input Delay), TTI(Time to Interactive) 등의 핵심 웹 성능 지표가 크게 저하되며 사용자의 입력 지연을 초래합니다 [3, 7]. + * 또한 서버에서 렌더링된 HTML과 클라이언트의 렌더링 결과가 다를 때 발생하는 'Hydration Mismatch' 오류와, 모든 컴포넌트를 위한 전체 JavaScript를 다운로드해야 해서 발생하는 번들 크기 비대화(Bundle Size Bloat) 문제도 겪을 수 있습니다 [4, 8]. + +* **점진적 및 선택적 Hydration (Selective & Progressive Hydration):** + * 페이지 전체를 일괄 처리하는 대신 스크롤 위쪽(Above-the-fold)의 중요한 콘텐츠를 우선 처리하고, 덜 중요한 컴포넌트는 Hydration을 지연시킵니다 [4]. + * Next.js 환경에서는 `next/dynamic`을 활용한 동적 임포트(Dynamic Imports)를 통해 구현하거나, IntersectionObserver API를 사용하여 요소가 뷰포트에 들어올 때만 Hydration을 수행하는 지연(Lazy) 방식을 적용할 수 있습니다 [5, 9]. 이를 통해 메인 스레드 차단을 분산시켜 TBT를 최대 40%까지 줄일 수 있습니다 [5]. + +* **React Server Components (RSC)의 활용:** + * Next.js App Router 등에서 지원하는 React Server Components는 오직 서버에서만 실행되며 클라이언트로 JavaScript 페이로드를 전혀 보내지 않습니다 [5, 10, 11]. + * 정적이거나 상호작용이 필요 없는 UI(예: 텍스트, 사이드바 등)를 RSC로 구성하면 해당 영역은 Hydration 프로세스 자체가 필요 없어지므로 클라이언트의 부담과 번들 크기가 비약적으로 감소합니다 [6, 12, 13]. + +* **Streaming 및 Suspense 적용:** + * React의 Suspense API를 활용하면 서버에서 HTML을 점진적으로 스트리밍(Streaming)할 수 있습니다 [6]. + * 이를 통해 렌더링이 완료된 일부 화면을 사용자에게 더 빠르게 보여주면서(FCP 개선), 복잡한 부분에 대한 Hydration 작업은 나중으로 미루어 체감 성능을 향상시킬 수 있습니다 [6, 14]. React 18의 동시성 렌더링(Concurrent Rendering)은 Hydration 작업을 작은 청크로 쪼개어 브라우저가 사용자 입력을 처리할 수 있도록 양보(yield)하는 기능을 제공합니다 [15]. + +* **부분 Hydration (Partial Hydration) 및 기타 팁:** + * 정적인 콘텐츠 영역을 고립시키고 상호작용이 필요한 특정 부분만 Hydration하는 섬 아키텍처(Island Architecture)를 도입하거나, 절대적으로 정적인 콘텐츠의 경우 `dangerouslySetInnerHTML`을 사용하여 통째로 Hydration 과정에서 배제하는 것도 유용한 전략입니다 [16-18]. + * 불가피하게 클라이언트와 서버 간의 렌더링 불일치가 예상되는 곳에는 `suppressHydrationWarning`을 제한적으로 사용하거나, Hydration 완료 이후에 동작해야 하는 로직을 의존성 배열이 빈 `useEffect` 내에 배치하여 불일치 에러를 방지할 수 있습니다 [17, 19]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Server-Side Rendering (SSR)]], [[React Server Components (RSC)]], [[Total Blocking Time (TBT)]], [[Concurrent Rendering]] +- **Projects/Contexts:** [[Next.js App Router]], [[Island Architecture]] +- **Contradictions/Notes:** SSR은 클라이언트에게 완성된 HTML을 즉시 제공하여 FCP(First Contentful Paint)와 SEO를 크게 향상시키지만, JavaScript 번들이 다운로드되고 Hydration이 완료될 때까지 사용자가 페이지와 상호작용할 수 없으므로 TTI(Time to Interactive)가 오히려 지연되는 성능적 트레이드오프(Trade-off)가 존재합니다 [20, 21]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 및 동시성 렌더링.md b/10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 및 동시성 렌더링.md new file mode 100644 index 00000000..511cf74e --- /dev/null +++ b/10_Wiki/Topics_Art/UI_UX_Assets/React Fiber 및 동시성 렌더링.md @@ -0,0 +1,32 @@ +# [[React Fiber 및 동시성 렌더링]] + +## 📌 Brief 시 Summary +React Fiber는 동기식 렌더링의 한계를 극복하고 동시성 렌더링(Concurrent rendering)을 지원하기 위해 도입된 React의 재조정(Reconciliation) 엔진 아키텍처이다 [1, 2]. 전체 컴포넌트 트리를 단일 호출로 처리하던 기존 방식과 달리, 렌더링 작업을 '파이버 노드(Fiber node)'라는 작은 단위로 쪼개어 스케줄링한다 [3, 4]. 이를 통해 메인 스레드를 차단하지 않고 렌더링을 일시 정지하거나 재개할 수 있으며, 타자 입력이나 클릭과 같은 긴급한 업데이트를 우선적으로 처리하여 반응성 높은 UI를 제공할 수 있다 [3, 5, 6]. + +## 📖 Core Content +**도입 배경 및 문제점 해결** +Fiber 아키텍처 이전의 React는 '스택 재조정자(Stack reconciler)'를 사용하여 전체 컴포넌트 트리를 한 번의 재귀 호출로 처리했다 [3]. 대규모 애플리케이션의 경우 이러한 방식은 메인 스레드를 16.6ms 이상 차단하여 UI의 애니메이션이나 사용자 입력 반응을 지연시키는 문제를 발생시켰다 [3]. React 16부터 도입된 Fiber는 렌더링을 완전히 재작성하여, 작업을 더 작은 청크로 나누고 여러 프레임에 걸쳐 분산할 수 있도록 설계되었다 [1, 4]. + +**작업 루프(Work Loop)와 렌더링의 두 단계** +React Fiber는 작업 루프를 통해 렌더링 단위를 점진적으로 처리하며, 전체 과정은 두 가지 주요 단계로 나뉜다 [4, 7]. +* **렌더 단계(Render Phase):** 이 단계는 중단할 수 있으며(Interruptible), DOM 변경 없이 순수한 연산만 수행된다 [7]. React는 Fiber 트리를 순회하면서(`beginWork`, `completeWork`) 이전 상태와 새로운 상태를 비교한다 [7, 8]. 이때, 메인 스레드가 바쁘거나 우선순위가 높은 상호작용이 들어오면 작업을 일시 정지, 재개 또는 폐기(WIP, Work-In-Progress 관리)할 수 있다 [9]. 변경이 필요한 노드에는 이펙트 태그(Placement, Update, Deletion 등)가 지정되며 이펙트 목록(Effect list)이 만들어진다 [7, 10, 11]. +* **커밋 단계(Commit Phase):** 이 단계는 동기적이고 중단 불가능(Uninterruptible)하다 [12]. 렌더 단계에서 생성된 이펙트 목록을 바탕으로 실제 DOM 변형이 이루어진다 [10, 12]. 이 단계는 DOM 변형 전(Before Mutation), 변형(Mutation), 레이아웃 이펙트(`useLayoutEffect` 실행), 패시브 이펙트(`useEffect` 실행) 순으로 처리된다 [13]. + +**우선순위 스케줄링과 차선(Lane) 모델** +Fiber는 '차선(Lanes)'이라고 불리는 비트마스크(Bitmask) 기반의 우선순위 시스템을 사용하여 동시성 작업을 관리한다 [11, 14]. +* **우선순위 레벨:** 클릭이나 타이핑 등 즉각 반응이 필요한 작업은 Sync 레벨, 스크롤이나 호버는 InputContinuous, 네트워크 응답 등은 Default, 오프스크린 렌더링은 Idle 레벨로 구분된다 [5, 15]. +* 이를 통해 낮은 우선순위의 작업을 처리하는 중에도 우선순위가 높은 상호작용이 들어오면 실행 중인 작업을 멈추고 중요한 작업을 먼저 렌더링하게 된다 [6]. + +**React 18 이후의 동시성 기능 활용** +이러한 아키텍처를 기반으로 React 18 및 19에서는 개발자가 렌더링 우선순위를 직접 조정할 수 있는 동시성 훅을 제공한다. +* `useTransition`: 특정 상태 업데이트를 낮은 우선순위로 지정하여, 무거운 필터링 작업이 진행되는 동안에도 타이핑 등의 긴급한 입력이 지연되지 않도록 한다 [16, 17]. +* `useDeferredValue`: 외부에서 전달받은 값의 소비를 지연시켜 무거운 렌더링 중에 UI가 동결되는 것을 막는다 [17, 18]. +* 또한 동시성 렌더링은 클라이언트의 Hydration 과정에서도 메인 스레드를 심하게 막지 않고 작은 청크로 쪼개어 렌더링할 수 있도록 돕는다 [19]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[Reconciliation]], [[Virtual DOM]], [[Time-Slicing]], [[Hydration]] +- **Projects/Contexts:** [[React 18 Concurrent Features]], [[useTransition 및 useDeferredValue]] +- **Contradictions/Notes:** 제공된 소스 전반에 걸쳐 Fiber 아키텍처와 동시성 렌더링의 매커니즘, 장점에 대해 일관된 설명을 제공하고 있으며, 상충되는 의견은 존재하지 않습니다. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/단일 페이지 애플리케이션 (SPA).md b/10_Wiki/Topics_Art/UI_UX_Assets/단일 페이지 애플리케이션 (SPA).md new file mode 100644 index 00000000..f74ae4c6 --- /dev/null +++ b/10_Wiki/Topics_Art/UI_UX_Assets/단일 페이지 애플리케이션 (SPA).md @@ -0,0 +1,18 @@ +# [[단일 페이지 애플리케이션 (SPA)]] + +## 📌 Brief Summary +단일 페이지 애플리케이션(SPA)은 서버에서 라우트마다 완전한 HTML을 받아오는 대신, 클라이언트 사이드 렌더링(CSR)을 활용하여 브라우저 내에서 콘텐츠를 동적으로 생성하는 웹 애플리케이션입니다 [1-3]. 초기 로드 시 필요한 모든 HTML, CSS 및 자바스크립트 파일을 다운로드하며, 그 이후부터는 서버를 통한 전체 페이지 새로고침 없이 사용자의 상호작용을 처리합니다 [4]. 이를 통해 사용자에게 페이지 전환이 즉각적으로 이루어지는 매끄러운 '앱과 같은(app-like)' 경험을 제공합니다 [1, 4]. + +## 📖 Core Content +* **작동 방식:** SPA는 서버로부터 기본 구조만 갖춘 최소한의 HTML 템플릿과 자바스크립트 번들을 전달받습니다 [1-3]. 이후 자바스크립트가 문서의 제어권을 넘겨받아 브라우저 내에서 각 라우트를 동적으로 생성하고 데이터를 채워 넣습니다 [2, 3]. +* **성능 및 사용자 경험 측면의 장점:** SPA는 페이지를 새로고침할 때 발생하는 끊김 현상을 제거하여 매우 유동적이고 반응성이 뛰어난 사용자 경험을 제공합니다 [4, 5]. 또한 렌더링 작업을 클라이언트로 넘기므로 서버 부하가 감소하며, 복잡한 자바스크립트 런타임 서버 없이 정적 서버(Amazon S3, Netlify 등)에 호스팅할 수 있어 비용 효율적입니다 [5, 6]. +* **초기 로딩 및 SEO의 한계:** 브라우저가 자바스크립트를 모두 다운로드하고 구문 분석 및 실행을 완료하기 전까지는 의미 있는 콘텐츠가 화면에 나타나지 않으므로 초기 로드 시간(First Contentful Paint)이 느리다는 단점이 있습니다 [1, 7]. 또한, 빈 HTML 껍데기만 먼저 전송되기 때문에 일부 검색 엔진 크롤러가 콘텐츠를 제대로 읽지 못해 검색 엔진 최적화(SEO)에 불리할 수 있습니다 [1, 7, 8]. 사용자 기기의 컴퓨팅 성능에 따라 렌더링 성능이 크게 좌우되기도 합니다 [9]. +* **이상적인 활용 사례:** SEO가 우선순위가 아니며 복잡하고 풍부한 사용자 상호작용이 필수적인 애플리케이션에 매우 적합합니다 [10]. 주로 로그인 장벽 뒤에 있는 내부 비즈니스 도구, 실시간 데이터가 업데이트되는 사용자 대시보드, SaaS 플랫폼 등에서 이상적으로 활용됩니다 [5, 10]. + +## 🔗 Knowledge Connections +- **Related Topics:** [[클라이언트 사이드 렌더링 (CSR)]], [[검색 엔진 최적화 (SEO)]], [[초기 로드 시간 (Initial Load Time)]] +- **Projects/Contexts:** [[SaaS 플랫폼 및 인터랙티브 대시보드 개발]] +- **Contradictions/Notes:** 소스에 따르면 SPA의 핵심인 CSR 방식은 상호작용성과 개발 속도 면에서 뛰어나지만 SEO와 초기 로드 시간에서는 뚜렷한 한계를 보입니다. 이러한 단점은 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)이 갖는 장점(빠른 초기 화면 및 SEO 최적화)과 정확히 대조됩니다 [1, 7, 8, 11]. + +--- +*Last updated: 2026-04-25* \ No newline at end of file diff --git a/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 프로세스 (CRP).md b/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 프로세스 (CRP).md new file mode 100644 index 00000000..7fb91638 --- /dev/null +++ b/10_Wiki/Topics_Art/UI_UX_Assets/브라우저 렌더링 프로세스 (CRP).md @@ -0,0 +1,21 @@ +# [[브라우저 렌더링 프로세스 (CRP)]] + +## 📌 Brief Summary +브라우저 렌더링 프로세스, 즉 중요 렌더링 경로(Critical Rendering Path, CRP)는 브라우저가 HTML, CSS, JavaScript를 화면의 픽셀로 변환하기 위해 실행하는 일련의 단계입니다 [1, 2]. 이 과정은 DOM 및 CSSOM 트리 생성, 렌더 트리 합성, 레이아웃(Reflow) 계산, 그리고 화면에 픽셀을 그리는 페인트(Paint) 및 합성(Composite) 단계로 구성됩니다 [2, 3]. 이 경로를 최적화하는 것은 첫 렌더링 시간을 단축하고, 원활한 사용자 상호작용을 보장하며 성능 병목현상을 피하기 위한 프론트엔드 엔지니어링의 핵심 목표입니다 [1, 4]. + +## 📖 Core Content +브라우저 렌더링 프로세스는 코드가 화면의 시각적 요소로 변환되는 과정으로, 다음과 같은 핵심 단계들을 거칩니다: + +* **문서 객체 모델(DOM) 구축:** 브라우저가 서버로부터 HTML 데이터를 수신하면, 바이트를 문자, 토큰, 노드로 순차적으로 변환하여 계층적인 DOM 트리를 구성합니다 [1, 5]. 이 DOM 구축은 점진적으로 진행되므로 브라우저는 네트워크 요청이 활성화된 상태에서도 트리를 구축할 수 있습니다 [1, 6]. 그러나 노드 수가 많아질수록 이후의 렌더링 단계에서 더 많은 계산 시간이 소요됩니다 [6, 7]. +* **CSS 객체 모델(CSSOM) 구축:** CSS는 콘텐츠가 어떻게 스타일링될지 정의합니다. DOM 구축과 달리 CSSOM 구축은 점진적이지 않으며 렌더링을 차단(render-blocking)하는 작업입니다 [6, 7]. 브라우저는 스타일이 적용되지 않은 콘텐츠가 화면에 노출되는 현상(FOUC)을 방지하기 위해 연결된 모든 스타일시트를 다운로드하고 파싱할 때까지 렌더 트리를 빌드하지 않습니다 [6, 7]. +* **렌더 트리(Render Tree) 합성:** DOM과 CSSOM이 모두 준비되면 브라우저는 두 트리를 결합하여 렌더 트리를 만듭니다 [8, 9]. 이 트리는 화면에 렌더링하는 데 필요한 노드만 포함하므로, `