chore: clean up placeholders and wikify real-time incoming knowledge
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,35 @@
|
||||
# [[Fiber 아키텍처와 동시성 (Concurrent Rendering)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React의 **Fiber 아키텍처**는 단일 호출로 전체 트리를 동기적으로 렌더링하여 메인 스레드를 차단하던 기존의 한계를 극복하기 위해 재작성된 재조정(Reconciliation) 엔진입니다 [1, 2]. 이 엔진은 렌더링 과정을 작은 '작은 작업 단위(Unit of work)'로 분할하여 **동시성 렌더링(Concurrent Rendering)**을 구현합니다 [2, 3]. 결과적으로 긴급한 사용자 상호작용(예: 클릭, 타이핑)이 무거운 렌더링 작업에 의해 지연되지 않도록 작업을 일시 중지, 재개, 우선순위 재조정하여 사용자 인터페이스(UI)의 반응성을 극대화합니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
- **기존 렌더링의 문제점과 Fiber의 도입:**
|
||||
React 16 이전에는 전체 컴포넌트 트리를 단일 재귀 호출로 처리하는 '스택 재조정자(Stack Reconciler)'를 사용했습니다 [2]. 이 방식은 렌더링이 완료될 때까지 메인 스레드를 차단(synchronous blocking)하여, 큰 규모의 애플리케이션에서는 UI가 사용자의 입력이나 애니메이션에 반응하지 못하는 문제를 발생시켰습니다 [2]. 이를 해결하기 위해 렌더링을 중단 및 재개할 수 있는 Fiber 아키텍처가 도입되었습니다 [1, 2].
|
||||
|
||||
- **작업 루프(Work Loop)와 작업 단위(Unit of Work):**
|
||||
Fiber는 컴포넌트나 DOM 요소를 나타내는 'Fiber 노드' 단위로 렌더링 작업을 수행합니다 [2, 3]. 렌더링을 여러 프레임에 분산시키기 위해 '작업 루프'를 작동하며, 다음 작업을 선택하여 처리(beginWork)하다가 우선순위가 높은 작업이 발생하면 렌더링을 일시 중단하고 브라우저에 제어권을 양보(Yield)합니다 [3, 5].
|
||||
|
||||
- **재조정(Reconciliation) 단계의 분리:**
|
||||
동시성 렌더링을 위해 React의 재조정 과정은 중단 가능성에 따라 두 가지 단계로 나뉩니다 [6].
|
||||
* **렌더링 단계(Render Phase):** 컴포넌트 트리를 순회하며 이전 상태와 새로운 상태의 차이를 계산하고 효과 목록(Effect list)을 구축합니다 [6]. 이 단계는 실제 DOM을 변경하지 않는 순수한 연산 과정이므로 **언제든지 일시 중지, 취소 또는 재시작이 가능**합니다 [6, 7].
|
||||
* **커밋 단계(Commit Phase):** 렌더링 단계에서 만들어진 변경 사항(효과 목록)을 실제 DOM에 한 번에 적용합니다 [8]. 이 과정은 **동기적이고 중단할 수 없습니다** [7, 8].
|
||||
|
||||
- **우선순위 제어 및 차선 모델(Lane Model):**
|
||||
React는 타임 슬라이싱(Time-slicing)과 동시성을 효과적으로 관리하기 위해 32비트 정수 기반의 '차선(Lanes)' 시스템을 활용합니다 [4, 9].
|
||||
* 동기적 차선(Sync Lane): 타이핑, 클릭 등 즉시 처리해야 하는 긴급한 작업 [4, 10].
|
||||
* 입력 연속 차선(InputContinuous Lane): 스크롤, 마우스 호버 등 유동적인 움직임 [4, 10].
|
||||
* 그 외에도 데이터 페칭 결과를 처리하는 기본 차선(Default Lane)과 백그라운드 렌더링을 처리하는 유휴 차선(Idle Lane)으로 나뉩니다 [4].
|
||||
이러한 세밀한 모델 덕분에 작업 중인 Fiber(WIP Fibers)를 우선순위에 따라 지연시키거나 우선 처리할 수 있습니다 [11].
|
||||
|
||||
- **동시성 기능(Concurrent Features)의 활용:**
|
||||
Fiber의 동시성 렌더링 구조는 React 18, 19의 `useTransition` 및 `useDeferredValue`와 같은 훅(Hook)을 가능하게 합니다 [12, 13]. 긴급하지 않은 업데이트의 우선순위를 낮춰 처리함으로써 무거운 리스트 필터링이나 데이터 계산 중에도 앱의 반응성을 부드럽게 유지할 수 있습니다 [12, 14].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[가상 DOM과 재조정 (Virtual DOM and Reconciliation)]], [[차선 모델과 작업 우선순위 (Lane Model & Priorities)]], [[Time-Slicing]], [[React 동시성 훅 (useTransition, useDeferredValue)]]
|
||||
- **Projects/Contexts:** [[메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례]]
|
||||
- **Contradictions/Notes:** 소스 전반에 걸쳐 내용이 일치하며 상충되는 의견은 없습니다. 모든 소스는 Fiber 아키텍처가 렌더링을 작은 단계로 분할하고 우선순위를 부여함으로써 메인 스레드의 부하를 줄여 동시성과 반응성을 달성한다는 점을 일관되게 강조합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -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*
|
||||
@@ -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*
|
||||
@@ -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. **다른 타입의 요소**: 루트 요소의 타입이 다르면(예: `<a>`에서 `<img>`로 변경), 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*
|
||||
@@ -0,0 +1,28 @@
|
||||
# [[가상 DOM과 재조정 (Reconciliation)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
가상 DOM(Virtual DOM)은 메모리 내에 유지되는 UI의 이상적이고 가상적인 표현으로, ReactDOM과 같은 라이브러리에 의해 실제 DOM과 동기화되는 프로그래밍 개념이다 [1]. 이 가상 DOM을 실제 DOM과 일치시키는 과정을 **재조정(Reconciliation)**이라고 부른다 [1, 2]. 직접적인 DOM 수정이 유발하는 크리티컬 렌더링 패스의 비용을 최소화하기 위해 도입되었으며 [3], React는 $O(n)$ 복잡도를 가지는 효율적인 휴리스틱 비교 알고리즘을 통해 변경된 부분만 선택적으로 실제 DOM에 반영한다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **가상 DOM의 필요성과 역할**
|
||||
기존 방식처럼 실제 DOM을 직접 수정하면 변경이 일어날 때마다 브라우저의 레이아웃(Reflow)과 페인트(Repaint) 단계가 반복적으로 발생하여 성능이 저하된다 [3, 6]. 이를 극복하기 위해 React는 UI 요소를 일반 JavaScript 객체로 얕게 표현한 경량화된 트리인 가상 DOM을 사용한다 [1-3]. 개발자는 원하는 UI 상태를 선언적으로 지정하기만 하면 되며, 수동적인 DOM 조작과 속성 변경, 이벤트 처리는 React가 추상화하여 담당한다 [1].
|
||||
|
||||
* **휴리스틱 비교 알고리즘 (Heuristic Diffing Algorithm)**
|
||||
일반적인 트리 비교 알고리즘은 $O(n^3)$의 시간 복잡도를 가지지만, 이는 수천 개의 요소를 렌더링할 때 너무 큰 비용을 발생시킨다 [5, 7]. 따라서 React는 다음 두 가지 가정을 바탕으로 $O(n)$ 복잡도의 최적화된 알고리즘을 사용한다 [4, 5].
|
||||
1. **타입이 다른 요소**: 서로 다른 타입의 요소는 완전히 다른 트리를 생성한다고 가정한다. 예를 들어 `<a>`에서 `<img>`로 타입이 변경되면 React는 기존 트리를 완전히 파괴하고 처음부터 새 트리를 구축하며, 이 과정에서 기존 DOM 노드와 컴포넌트 상태(State)는 모두 소멸된다 [4, 5, 8]. 반면 같은 타입의 DOM 요소일 경우, 동일한 기본 DOM 노드를 유지한 채 변경된 속성(Attributes)과 스타일만 업데이트한다 [9, 10].
|
||||
2. **Key 속성**: 개발자가 `key` 속성을 제공하여 여러 렌더링 사이에서 어떤 자식 요소가 안정적으로 유지되는지 힌트를 줄 수 있다 [4, 5].
|
||||
|
||||
* **리스트 렌더링과 Key의 중요성**
|
||||
자식 노드들을 반복적으로 처리할 때, 기본적으로 React는 기존 트리와 새 트리의 자식 리스트를 동시에 순회하며 차이가 발생할 때마다 변형을 일으킨다 [11]. 리스트의 맨 끝에 요소를 추가하는 것은 원활하게 작동하지만, 리스트의 맨 앞에 요소를 추가하면 모든 자식 요소가 변경된 것으로 인식되어 매우 비효율적인 렌더링이 발생할 수 있다 [11, 12]. 고유한 `key`를 부여하면 React가 기존 트리와 새 트리의 요소를 정확히 일치시킬 수 있어 요소의 이동만으로 업데이트가 가능해진다 [12, 13]. 단, 배열의 인덱스를 `key`로 사용하면 항목 재정렬 시 컴포넌트 상태가 예기치 않게 꼬이거나 성능이 저하되는 문제가 발생할 수 있다 [13, 14].
|
||||
|
||||
* **Fiber 아키텍처 기반의 진화**
|
||||
React 16부터는 동시성(Concurrent) 렌더링을 지원하기 위해 재조정 엔진이 **'Fiber'** 아키텍처로 완전히 재작성되었다 [15-18]. 렌더링 작업을 단일 동기식 블록으로 처리하던 이전(Stack Reconciler)과 달리, Fiber는 작업을 작은 '작업 단위(Unit of work)'로 나누어 메인 스레드가 사용자 입력 등의 급한 작업을 먼저 처리할 수 있도록 돕는다 [19, 20]. 재조정 과정은 중단 및 재개가 가능하며 DOM 변경을 발생시키지 않는 **렌더 단계(Render phase)**와, 모든 변경 사항을 한 번에 동기적으로 실제 DOM에 반영하는 **커밋 단계(Commit phase)**로 나뉘어 실행된다 [21-23].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[크리티컬 렌더링 패스 (Critical Rendering Path)]]`, `[[Fiber 아키텍처 (Fiber Architecture)]]`, `[[DOM (Document Object Model)]]`
|
||||
- **Projects/Contexts:** `[[React 성능 최적화 (React Performance Optimization)]]`, `[[React 컴파일러 (React Compiler)]]`, `[[동시성 렌더링 (Concurrent Rendering)]]`
|
||||
- **Contradictions/Notes:** 섀도우 DOM(Shadow DOM)과 가상 DOM(Virtual DOM)은 혼동되기 쉬우나 서로 다른 개념이다. 섀도우 DOM은 웹 컴포넌트에서 변수와 CSS의 스코프를 지정하기 위해 설계된 브라우저 네이티브 기술인 반면, 가상 DOM은 브라우저 API 위에 JavaScript 라이브러리(React 등)에 의해 구현된 프로그래밍 개념이다 [24].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -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*
|
||||
@@ -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]. 이 트리는 화면에 렌더링하는 데 필요한 노드만 포함하므로, `<script>`, `<meta>` 태그나 CSS에서 `display: none`으로 설정된 요소는 렌더 트리에 포함되지 않습니다 [8-10].
|
||||
* **레이아웃(Layout) 또는 리플로우(Reflow):** 렌더 트리가 구성되면 브라우저는 기기의 뷰포트 크기와 박스 모델을 기반으로 각 시각적 요소의 정확한 위치와 치수(너비, 높이 등)를 계산합니다 [11-13]. 화면 크기 조정이나 DOM의 추가/삭제와 같은 변경이 일어나면 페이지 전체의 레이아웃을 다시 계산해야 하며 이를 리플로우(Reflow)라고 부르는데, 이는 계산 비용이 매우 높습니다 [11, 14, 15].
|
||||
* **페인트(Paint) 및 합성(Compositing):** 레이아웃 계산이 완료되면 기하학적 구조와 스타일을 바탕으로 브라우저는 화면의 픽셀을 채우는 페인트(Repaint) 단계를 거칩니다 [16-18]. 색상, 그림자 등의 시각적 속성을 업데이트하는 페인트 작업은 리플로우보다는 자원 소모가 덜하지만 과도하게 발생하면 성능에 영향을 줍니다 [19, 20]. 마지막으로 여러 레이어를 단일 이미지로 결합하는 합성(Compositing) 단계를 거치며, 최신 브라우저들은 렌더링 성능 최적화를 위해 특정 작업들을 GPU(그래픽 처리 장치)로 오프로드합니다 [16, 21].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DOM 및 CSSOM]], [[Reflow 및 Repaint]], [[Virtual DOM]], [[렌더링 차단 리소스(Render-blocking resources)]]
|
||||
- **Projects/Contexts:** [[프론트엔드 성능 최적화(Frontend Performance Optimization)]], [[단일 페이지 애플리케이션(SPA) 렌더링 설계]]
|
||||
- **Contradictions/Notes:** 주어진 소스들 간에 렌더링 과정과 관련하여 기술적인 모순은 없으나, 최적화의 우선순위 측면에서 단순히 페인트(Paint) 시간을 줄이는 미세한 CSS 선택자 성능 최적화보다는 레이아웃(Reflow) 발생을 최소화하거나 불필요한 DOM 노드를 줄이는 것이 훨씬 큰 성능 향상을 가져온다는 점을 주의해야 합니다 [14, 17, 22].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,28 @@
|
||||
# [[성능 및 SEO 최적화 프로젝트]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
성능 및 SEO 최적화 프로젝트는 애플리케이션의 초기 로드 속도와 반응성을 개선하고 검색 엔진 크롤러에 대한 접근성을 높여 최적의 사용자 경험과 비즈니스 성과를 달성하기 위한 목적을 가집니다. 브라우저의 중요 렌더링 경로(CRP)를 이해하여 불필요한 Reflow와 Repaint를 최소화하며, 프로젝트의 성격에 맞게 CSR, SSR, SSG, ISR 등 적절한 웹 렌더링 전략을 선택하는 것이 중요합니다. 더불어, React 기반 애플리케이션에서는 Virtual DOM과 Fiber 아키텍처, 자동 배칭(Automatic Batching), React Compiler 및 React Server Components(RSC)를 활용하여 렌더링 효율성을 극대화하고 JavaScript 번들 크기를 줄이는 최적화 작업을 수행합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
**브라우저 렌더링 메커니즘과 렌더링 최적화**
|
||||
* **중요 렌더링 경로 (Critical Rendering Path, CRP):** 브라우저가 HTML, CSS, JavaScript를 화면의 픽셀로 변환하는 과정입니다 [1, 2]. HTML을 파싱하여 DOM을 만들고 CSS를 파싱하여 CSSOM을 생성한 후, 두 개를 결합하여 화면에 보일 요소만 담은 렌더 트리(Render Tree)를 구성합니다 [2-4]. 이후 각 요소의 크기와 위치를 계산하는 Layout(Reflow) 단계와 화면에 실제 픽셀을 그리는 Paint(Repaint) 단계를 거칩니다 [5-8].
|
||||
* **Reflow 및 Repaint 최소화:** DOM 노드의 추가/제거나 요소의 크기 및 위치(width, height, margin 등)를 변경하면 막대한 비용이 드는 Reflow가 발생합니다 [9-11]. 성능 최적화를 위해서는 불필요한 DOM 깊이를 줄이고, 레이아웃 계산을 피할 수 있도록 `position: absolute`나 `position: fixed`를 사용하며, 애니메이션에는 Reflow를 유발하지 않는 `transform` 속성을 사용해야 합니다 [12-14].
|
||||
|
||||
**전략적 웹 렌더링 방식 (CSR, SSR, SSG, ISR)**
|
||||
* **CSR (Client-Side Rendering):** 서버에서 빈 HTML 뼈대와 자바스크립트를 보내고 브라우저가 모든 렌더링을 처리합니다. 페이지 전환이 부드럽고 상호작용성이 뛰어나지만, 초기에 화면이 비어 있어 FCP(First Contentful Paint)가 늦고 검색 엔진 최적화(SEO)에 불리합니다 [15-19].
|
||||
* **SSR (Server-Side Rendering):** 요청 시 서버에서 완전한 HTML을 렌더링하여 클라이언트에 제공합니다. 검색 엔진이 즉시 콘텐츠를 읽을 수 있어 SEO에 탁월하고 초기 화면을 빠르게 띄울 수 있습니다 [20-23]. 단, 자바스크립트가 다운로드되어 이벤트를 연결하는 하이드레이션(Hydration) 단계가 완료될 때까지 상호작용(TTI, Time to Interactive)이 지연될 수 있습니다 [20, 24-26].
|
||||
* **SSG (Static Site Generation) 및 ISR (Incremental Static Regeneration):** SSG는 빌드 타임에 HTML을 생성하여 CDN으로 배포하므로 로딩 속도와 SEO 측면에서 최상의 성능을 냅니다 [27-29]. ISR은 SSG의 성능을 유지하면서도 설정된 주기마다 백그라운드에서 페이지를 업데이트하여 최신 콘텐츠를 제공하는 하이브리드 방식입니다 [27, 30-32].
|
||||
|
||||
**React 아키텍처를 통한 렌더링 최적화 전략**
|
||||
* **Virtual DOM과 Reconciliation:** React는 메모리상에 가상의 DOM을 유지하고, 상태 변경 시 O(n) 복잡도를 갖는 휴리스틱 Diffing 알고리즘을 통해 이전 트리와 변경된 트리를 비교하여 실제 DOM에는 변경된 부분만 최소한으로 업데이트합니다 [33-36].
|
||||
* **Fiber 아키텍처와 동시성 렌더링 (Concurrent Rendering):** React 16부터 도입된 Fiber는 렌더링 작업을 중단하고 재개할 수 있는 작은 '작업 단위'로 나눕니다 [37-39]. 사용자 입력과 같은 긴급한 작업을 우선 처리하는 우선순위 라인(Priority Lanes)과 Time Slicing 기술을 활용하여 무거운 연산 중에도 UI가 멈추지 않고 반응성을 유지하도록 돕습니다 [38, 40-43].
|
||||
* **자동 배칭과 React Compiler:** React 18의 자동 배칭(Automatic Batching)은 여러 번의 상태 업데이트를 묶어 한 번의 리렌더링만 발생하도록 하여 불필요한 렌더링을 줄입니다 [44-47]. 나아가 React 19의 React Compiler는 빌드 타임에 코드를 분석해 `useMemo`나 `useCallback`과 같은 수동 처리 없이도 자동으로 최적화된 메모이제이션을 삽입하여 개발자의 인지적 부담과 성능 이슈를 동시에 해결합니다 [48-51].
|
||||
* **React Server Components (RSC):** RSC는 클라이언트로 다운로드되는 자바스크립트 번들에 포함되지 않고 전적으로 서버에서 실행됩니다 [52, 53]. 하이드레이션 과정을 생략할 수 있어 클라이언트가 부담해야 할 번들 크기를 제로(Zero)에 가깝게 만들며, 서버에 직접 접근해 효율적으로 데이터를 패칭할 수 있어 초기 로드와 상호작용 속도를 모두 개선합니다 [53-57].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Critical Rendering Path]], [[Reflow와 Repaint]], [[Server-Side Rendering (SSR)]], [[Virtual DOM과 Reconciliation]], [[React Server Components (RSC)]]
|
||||
- **Projects/Contexts:** [[대규모 콘텐츠 기반 애플리케이션 및 전자상거래 플랫폼 구축]], [[프론트엔드 성능 최적화 및 SEO 개선 프로젝트]]
|
||||
- **Contradictions/Notes:** 클라이언트 사이드 렌더링(CSR)은 로드 후 동적 상호작용에는 강점이 있으나 초기 FCP 저하 및 SEO 크롤링 측면에서 불리합니다. 반대로 서버 사이드 렌더링(SSR)은 뛰어난 SEO 및 초기 화면 노출을 보장하지만, 하이드레이션(Hydration) 병목으로 인해 TTI(Time to Interactive)가 지연되어 사용자가 버튼을 클릭해도 즉시 반응하지 않는 현상이 발생할 수 있다는 렌더링 방식 간의 명확한 트레이드오프가 존재합니다 [15, 20, 25, 58, 59].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,33 @@
|
||||
# [[웹 프론트엔드 아키텍처 설계]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
웹 프론트엔드 아키텍처 설계는 사용자 인터페이스를 독립적이고 재사용 가능한 컴포넌트 단위로 분할하여 복잡성을 관리하는 기술적 구조화 과정입니다 [1, 2]. 브라우저의 중요 렌더링 경로(CRP)를 최적화하고 상태 변화에 따른 불필요한 리플로우(Reflow)와 리페인트(Repaint)를 최소화하는 것을 핵심 목표로 합니다 [3-5]. 또한 애플리케이션의 특성에 맞춰 CSR, SSR, SSG 등의 렌더링 전략을 선택 및 혼합하여, 초기 로딩 속도, 상호작용성, 그리고 SEO 간의 최적의 균형을 맞추는 중대한 의사 결정 과정입니다 [6-9].
|
||||
|
||||
## 📖 Core Content
|
||||
* **컴포넌트 기반 아키텍처 (Component-Based Architecture, CBA)**
|
||||
* 시스템을 특정 기능을 수행하는 독립적이고 캡슐화된 '컴포넌트'의 조합으로 구축하는 방법론입니다 [2, 10].
|
||||
* 각 컴포넌트는 모듈성, 재사용성, 확장성을 지니며, 다른 컴포넌트에 영향을 주지 않고 개별적인 개발, 테스트, 배포가 가능하므로 유지보수와 협업의 효율성을 크게 높입니다 [1, 11-13].
|
||||
|
||||
* **브라우저 렌더링 파이프라인 (Critical Rendering Path)**
|
||||
* 브라우저는 HTML과 CSS를 파싱하여 각각 DOM(Document Object Model) 트리와 CSSOM 트리를 생성하고, 이 둘을 결합해 화면에 표시될 요소만 포함하는 렌더 트리(Render Tree)를 구축합니다 [14-17].
|
||||
* 이후 뷰포트를 기준으로 요소의 정확한 크기와 위치를 계산하는 레이아웃(Layout 또는 Reflow) 단계와 픽셀을 화면에 그리는 페인트(Paint 또는 Repaint) 단계를 거칩니다 [18-20].
|
||||
* 리플로우(Reflow)는 연산 비용이 매우 높으므로 DOM 깊이를 줄이거나, 레이아웃 변경을 최소화하고, CSS `transform`과 같은 속성을 활용해 GPU 가속을 유도하는 방식의 최적화가 필수적입니다 [5, 21-25].
|
||||
|
||||
* **렌더링 전략 (CSR, SSR, SSG, ISR, RSC)**
|
||||
* **CSR (Client-Side Rendering):** 클라이언트(브라우저)에서 JavaScript를 다운로드해 UI를 렌더링합니다. 매끄러운 화면 전환이 강점이지만, 초기 로딩 속도(FCP)가 느리고 SEO 처리에 불리할 수 있습니다 [6, 26, 27].
|
||||
* **SSR (Server-Side Rendering):** 서버에서 완성된 HTML을 전송하여 초기 로딩과 SEO에 유리합니다. 단, 브라우저가 JavaScript를 연결하는 하이드레이션(Hydration)이 끝날 때까지 페이지와 상호작용할 수 없는 지연 시간(TTI)이 발생합니다 [28-30].
|
||||
* **SSG (Static Site Generation) & ISR (Incremental Static Regeneration):** 빌드 타임에 HTML을 미리 생성해 CDN으로 초고속 제공하는 것이 SSG입니다. ISR은 백그라운드에서 주기적으로 정적 페이지를 재생성해 최신 정보와 빠른 성능을 동시에 만족시킵니다 [31-33].
|
||||
* **React Server Components (RSC):** 오직 서버에서만 실행되며 브라우저로 전송되는 JavaScript 번들 크기를 '0'으로 만듭니다. 인터랙티브한 부분만 Client Component로 분리 처리하여 효율성을 극대화합니다 [34-37].
|
||||
|
||||
* **가상 DOM (Virtual DOM) 및 최신 React 아키텍처**
|
||||
* **가상 DOM과 재조정 (Reconciliation):** 무거운 실제 DOM 조작을 추상화하여, 가벼운 메모리 내 표현을 비교(O(n) 휴리스틱 Diffing 알고리즘)하고 변경된 부분만 실제 DOM에 반영합니다 [38-41].
|
||||
* **Fiber와 동시성 (Concurrency):** React 16부터 도입된 Fiber는 렌더링 작업을 작게 분할하여, 긴급한 사용자 입력(클릭, 타이핑)과 같은 우선순위(Lanes)가 높은 작업을 먼저 처리하도록 렌더링을 중단하거나 재개할 수 있습니다 [42-45].
|
||||
* **자동 배칭과 컴파일러 최적화:** React 18의 자동 배칭(Automatic Batching)은 비동기 작업 내의 상태 업데이트도 묶어서 처리해 불필요한 리렌더링을 줄입니다 [46-48]. 나아가 React Compiler는 빌드 타임에 정적/반응형 값을 분석해 자동으로 최적의 메모이제이션을 삽입함으로써 개발자의 수동 최적화 부담을 줄입니다 [49-51].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[컴포넌트 기반 아키텍처 (CBA)]], [[Critical Rendering Path (CRP)]], [[가상 DOM (Virtual DOM) 및 Fiber]], [[웹 렌더링 전략 (CSR, SSR, SSG, ISR)]], [[React Server Components (RSC)]], [[하이드레이션 (Hydration)]]
|
||||
- **Projects/Contexts:** [[React 기반 대규모 웹 애플리케이션 최적화]], [[Next.js를 활용한 하이브리드 렌더링 및 SEO 최적화]]
|
||||
- **Contradictions/Notes:** 소스 [50]와 [52]는 React Compiler의 도입으로 `useMemo`나 `useCallback`과 같은 수동 메모이제이션이 90% 이상 불필요해진다고 강조합니다. 그러나 소스 [53]과 [54]은 서드파티 라이브러리가 매 렌더링마다 새로운 객체를 반환하거나 종속성 배열을 명시적으로 제어해야 할 때는 여전히 수동 메모이제이션이 제한적으로 필요할 수 있다고 지적합니다. 또한 소스 [55] 및 [56]은 React Server Components를 도입한다고 해서 자동으로 성능이 개선되는 것은 아니며, 데이터 종속성을 직렬로 설계할 경우 서버 측 폭포수(Waterfall) 현상이 발생할 수 있음을 주의해야 한다고 설명합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,23 @@
|
||||
# [[중요 렌더링 경로 (Critical Rendering Path)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
중요 렌더링 경로(Critical Rendering Path, CRP)는 브라우저가 HTML, CSS, JavaScript 코드를 수신하여 화면의 픽셀로 변환하기까지 거치는 일련의 필수 단계를 의미합니다 [1, 2]. 이 경로는 문서 객체 모델(DOM), CSS 객체 모델(CSSOM) 생성부터 렌더 트리 구축, 레이아웃, 그리고 페인트 단계까지 포함합니다 [2]. 중요 렌더링 경로의 과정을 최적화하면 웹 페이지의 첫 렌더링 시간(Time to First Render)을 단축하고 사용자 상호작용의 지연을 막을 수 있습니다 [1, 3].
|
||||
|
||||
## 📖 Core Content
|
||||
브라우저는 웹 페이지를 화면에 렌더링하기 위해 다음의 순차적인 단계들을 실행합니다:
|
||||
|
||||
* **DOM(Document Object Model) 트리 구축**: 브라우저가 서버로부터 HTML 응답을 받으면 데이터를 바이트에서 문자, 토큰, 노드로 변환하며 점진적으로 DOM 트리를 구축합니다 [1, 4, 5]. DOM은 문서의 구조와 콘텐츠 전체를 담고 있습니다 [6, 7].
|
||||
* **CSSOM(CSS Object Model) 트리 구축**: DOM과 유사하게 CSS 규칙들을 파싱하여 CSSOM을 만듭니다 [6, 7]. 다만 CSSOM은 후속 규칙이 이전 스타일을 덮어쓸 수 있기 때문에 점진적으로 구축될 수 없으며, 처리가 완료될 때까지 화면 렌더링을 차단(Render-blocking)합니다 [7, 8].
|
||||
* **렌더 트리(Render Tree) 결합**: 브라우저는 DOM과 CSSOM을 결합하여 실제로 화면에 렌더링될 요소들만을 포함하는 렌더 트리를 만듭니다 [9, 10]. 이 단계에서 `<head>` 태그나 `display: none` 속성이 적용된 비가시적 요소는 렌더 트리에서 제외됩니다 [10, 11].
|
||||
* **레이아웃(Layout) 또는 리플로우(Reflow)**: 렌더 트리가 준비되면 뷰포트(Viewport) 크기를 기준으로 각 요소의 정확한 위치와 기하학적 크기(너비, 높이 등)를 계산합니다 [12-14]. 화면 크기가 변하거나 DOM 노드가 추가/수정될 때마다 레이아웃이 다시 발생할 수 있습니다 [15, 16].
|
||||
* **페인트(Paint) 및 합성(Compositing)**: 레이아웃 계산을 마치면 브라우저는 요소의 텍스트, 색상, 그림자 등을 화면의 실제 픽셀로 그리는 페인트 단계를 거칩니다 [17-19]. 페이지 구성 요소가 여러 레이어로 나뉘어 있는 경우, 이를 GPU 등을 활용해 올바른 순서로 화면에 병합하는 합성(Compositing) 작업이 수행됩니다 [17, 20].
|
||||
|
||||
웹 성능을 최적화하기 위해서는 이 경로상에 있는 차단 리소스(예: 렌더링 차단 CSS나 파서 차단 동기식 JavaScript)의 수와 크기를 최소화하고, 로드 순서를 제어해야 합니다 [21-24].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DOM(Document Object Model)]], [[CSSOM(CSS Object Model)]], [[리플로우 및 리페인트(Reflow and Repaint)]]
|
||||
- **Projects/Contexts:** [[웹 성능 최적화(Web Performance Optimization)]]
|
||||
- **Contradictions/Notes:** CSS는 기본적으로 페이지 렌더링을 차단하는 리소스이지만, `<link>` 요소의 `media` 속성을 통해 현재 뷰포트 조건과 일치하지 않는 CSS를 설정함으로써 렌더링 차단 리소스에서 제외시킬 수 있습니다 [25, 26].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
Reference in New Issue
Block a user