feat: batch wikify raw data into Master Archive and specialized categories
Processed 70+ files covering Skybound mechanics, Frontend mastery, and Business strategy.
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,31 @@
|
||||
# [[Core Web Vitals Optimization (INP, LCP 개선)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Core Web Vitals는 구글이 웹 페이지의 검색 순위와 사용자 경험을 평가하기 위해 정의한 핵심 성능 지표입니다 [1]. 여기에는 화면의 주요 콘텐츠가 로드되는 속도를 측정하는 LCP(Largest Contentful Paint)와 페이지 세션 내내 애플리케이션이 사용자 상호작용에 얼마나 빠르게 응답하는지 측정하는 INP(Interaction to Next Paint)가 포함됩니다 [1, 2]. 이 지표들의 기준치(LCP 2.5초 미만, INP 200 밀리초 미만)를 달성하면 사용자 이탈률을 낮추고 유기적 검색(SEO) 성과를 직접적으로 높일 수 있습니다 [1-3].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
- **Largest Contentful Paint (LCP) 최적화**
|
||||
LCP는 브라우저 화면의 가장 큰 콘텐츠 요소가 렌더링되는 시간을 측정하며, 이를 2.5초 미만으로 유지하는 것이 목표입니다 [1].
|
||||
- **코드 스플리팅(Code Splitting):** 기본적으로 번들러는 전체 애플리케이션을 하나의 큰 파일로 묶지만, `React.lazy()` 등을 통해 라우트 수준에서 코드를 분할하면 초기 번들 크기를 30~50%가량 줄여 LCP를 크게 개선할 수 있습니다 [4].
|
||||
- **렌더링 전략 변경:** 클라이언트 측 렌더링(CSR)은 초기 로딩이 느리다는 단점이 있습니다 [5, 6]. 따라서 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)을 도입해 자바스크립트 파싱 전에 완성된 HTML을 사용자에게 즉시 제공함으로써 LCP 병목 현상을 해소할 수 있습니다 [7-9].
|
||||
- **이미지 최적화:** WebP나 AVIF 같은 현대적인 이미지 포맷을 사용하여 파일 크기를 줄이고, 화면에 보일 때만 이미지를 로드하는 `loading="lazy"` 지연 로딩을 도입해 초기 주요 리소스와의 대역폭 경쟁을 막습니다 [10, 11].
|
||||
|
||||
- **Interaction to Next Paint (INP) 최적화**
|
||||
INP는 기존의 First Input Delay(FID)를 대체한 지표로, 클릭이나 키보드 입력 같은 상호작용 지연 시간을 200ms 이내로 응답하게 만드는 것이 핵심입니다 [2].
|
||||
- **동시성 렌더링(Concurrent Rendering):** React 19의 `useTransition` 및 `useDeferredValue` 훅을 통해 무거운 상태 업데이트(예: 대규모 목록 필터링)를 후순위로 미루고, 긴급한 사용자 입력(타이핑 등)을 먼저 처리하여 메인 스레드의 응답성을 유지합니다 [2, 12, 13].
|
||||
- **메모이제이션과 연산 최적화:** 부모 컴포넌트의 상태가 변할 때 발생하는 불필요한 '리렌더링 폭포(Re-render Cascade)' 현상을 막기 위해 `React.memo`, `useMemo`, `useCallback`을 활용합니다 [14-16]. 더불어 키 입력마다 발생하는 과도한 API 호출을 줄이기 위해 디바운싱(Debouncing)을 적용합니다 [17].
|
||||
- **목록 가상화(Virtualization):** 수백, 수천 개의 항목이 포함된 긴 목록을 렌더링할 때, 화면에 보이는 노드만 렌더링하는 가상화를 도입하면 레이아웃 및 페인트 작업 부하를 방지하여 상호작용 속도를 높입니다 [2, 18, 19].
|
||||
- **React Server Components (RSC):** 읽기 전용 데이터 컴포넌트를 서버에서 전적으로 실행함으로써 클라이언트의 자바스크립트 크기를 40~60% 감소시키고, 상호작용 시 브라우저 메인 스레드가 처리할 코드를 줄여 INP를 직접적으로 낮출 수 있습니다 [20].
|
||||
|
||||
- **Cumulative Layout Shift (CLS) 관리 및 성능 프로파일링**
|
||||
- 시각적 안정성을 측정하는 CLS는 0.1 미만을 목표로 하며, 불필요한 DOM 노드를 줄이기 위한 React Fragment의 사용, 이미지의 명시적 크기 지정 등의 방법으로 개선합니다 [2, 21].
|
||||
- 최적화를 적용하기 전에 항상 `React DevTools Profiler`나 `Lighthouse`를 사용하여 병목을 유발하는 컴포넌트를 찾고, 프로덕션 환경의 실측 데이터를 얻기 위해 `Web Vitals` 라이브러리로 필드 데이터를 모니터링해야 합니다 [22-26].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Largest Contentful Paint (LCP)]], [[Interaction to Next Paint (INP)]], [[Concurrent Rendering]], [[Server-Side Rendering (SSR)]], [[React Server Components (RSC)]]
|
||||
- **Projects/Contexts:** [[React Performance Optimization]], [[Search Engine Optimization (SEO) Strategy]]
|
||||
- **Contradictions/Notes:** Lighthouse와 같은 도구로 측정한 연구실 데이터(Lab measurements)는 다양한 기기 성능과 네트워크 조건을 겪는 실제 사용자들의 경험(Field data)과 항상 일치하지는 않으므로 프로덕션 상의 Web Vitals 데이터를 함께 수집해야 합니다 [23, 24].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[DOM (Document Object Model)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
DOM(Document Object Model)은 브라우저가 수신한 HTML 문서 데이터를 파싱하여 생성하는 페이지 구조의 계층적 트리 표현입니다 [1-3]. 브라우저는 HTML 태그의 포함 관계를 바탕으로 부모 및 자식 노드의 트리를 형성하며, `<html>` 요소를 루트 노드로 갖습니다 [4, 5]. DOM은 페이지의 모든 콘텐츠 정보를 담고 있으며, 스타일 정보를 담은 CSSOM과 결합해 최종 화면 출력에 필요한 렌더 트리(Render Tree)를 형성하는 브라우저 렌더링 과정의 핵심 기반입니다 [6-8].
|
||||
|
||||
## 📖 Core Content
|
||||
* **DOM 트리의 점진적 구축 (Incremental Construction)**
|
||||
브라우저는 네트워크를 통해 HTML 문서의 전체 데이터를 다 받기 전부터 점진적으로 DOM 트리를 구축할 수 있습니다 [1, 4]. 초기 14KB의 데이터 패킷이 수신되면 바이트를 문자로, 문자를 토큰(startTag 및 endTag 등)으로 변환한 뒤, 최종적으로 노드(Node)로 변환하여 트리를 조립합니다 [1, 4]. 이 점진적 생성 메커니즘 덕분에 네트워크 요청이 진행 중인 상태에서도 브라우저는 렌더링 준비를 시작할 수 있습니다 [9].
|
||||
|
||||
* **렌더링 파이프라인에서의 DOM과 CSSOM**
|
||||
DOM은 문서의 '콘텐츠'를 표현하는 반면, CSSOM은 해당 콘텐츠의 '스타일'을 정의하는 독립적인 트리 구조입니다 [9, 10]. 이 두 모델은 브라우저에 의해 결합되어 화면에 시각적으로 출력되어야 하는 노드만을 포함하는 '렌더 트리(Render Tree)'로 합성됩니다 [6, 11, 12]. 이 과정에서 `<script>`, `<meta>` 또는 `display: none`이 적용된 요소처럼 시각적 영향을 주지 않는 DOM 노드는 렌더 트리에서 제외됩니다 [8, 11-13].
|
||||
|
||||
* **크기와 복잡성이 성능에 미치는 영향**
|
||||
DOM 트리의 깊이와 생성된 노드의 개수는 웹 성능과 직결됩니다 [5, 9]. 노드의 수가 많아질수록 렌더 트리 합성, 레이아웃(Reflow), 페인트 단계에서 브라우저가 처리해야 할 계산의 양과 시간이 증가하여 애플리케이션의 성능이 저하될 수 있습니다 [5, 7, 9, 14]. 불필요한 래퍼를 줄이고 React Fragment 등을 사용하여 DOM 노드 수를 최소화하는 것이 성능 향상에 도움이 됩니다 [15].
|
||||
|
||||
* **DOM 조작의 비효율성과 최적화**
|
||||
JavaScript를 사용해 DOM을 직접 조작하고 크기나 위치 등을 변경하면, 브라우저는 문서 전체의 레이아웃(Reflow)과 페인트(Repaint) 과정을 다시 실행해야 하므로 처리 비용이 매우 높습니다 [16-18]. 이를 최적화하기 위해서는 사용된 DOM 노드나 속성값을 캐싱하고, DOM의 읽기 및 쓰기 작업을 분리하여 레이아웃 스래싱(Layout thrashing)을 방지해야 합니다 [16, 19, 20]. React와 같은 프레임워크는 실제 DOM을 직접 수정하는 비효율성을 피하고자 메모리 내에 가벼운 사본인 가상 DOM(Virtual DOM)을 생성하여 조작을 추상화합니다 [17, 21, 22].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[CSSOM (CSS Object Model)]], [[Render Tree]], [[Virtual DOM]], [[Critical Rendering Path (CRP)]], [[Reflow (Layout)]], [[Repaint]]
|
||||
- **Projects/Contexts:** 프론트엔드 성능 최적화(DOM 접근 최소화 및 렌더링 파이프라인 관리), React의 렌더링 엔진 구조 및 재조정(Reconciliation) 과정 이해 [6, 17, 23, 24].
|
||||
- **Contradictions/Notes:** DOM 구축은 HTML을 파싱하면서 '점진적(incremental)'으로 이루어지지만, CSSOM 구축은 렌더링을 차단(render-blocking)하며 점진적으로 처리되지 않는다는 구조적 차이가 있습니다 [1, 7, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,31 @@
|
||||
# [[DOM 및 CSSOM]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
DOM(문서 객체 모델)과 CSSOM(CSS 객체 모델)은 브라우저의 핵심 렌더링 경로(Critical Rendering Path)에서 웹 페이지를 화면에 그리기 위해 생성되는 두 가지 독립적인 트리 구조 데이터입니다 [1, 2]. DOM은 HTML 마크업을 점진적으로 파싱하여 문서의 구조와 내용을 나타냅니다 [3, 4]. 반면, CSSOM은 문서에 적용될 스타일 규칙을 정의하며, 렌더링 시 스타일이 적용되지 않은 콘텐츠가 깜빡이는 현상(FOUC)을 방지하기 위해 렌더링 차단(render-blocking) 방식으로 생성됩니다 [5, 6]. 이 두 트리가 결합하여 화면에 표시될 시각적 요소들만 포함하는 렌더 트리(Render Tree)를 최종적으로 형성합니다 [7, 8].
|
||||
|
||||
## 📖 Core Content
|
||||
**DOM(Document Object Model) 구축**
|
||||
- 브라우저는 HTML 응답을 받으면 데이터를 문자, 토큰(token)으로 변환하고, 이를 다시 노드(node)로 변환하여 계층적인 DOM 트리를 구축합니다 [3, 4, 9].
|
||||
- DOM 트리는 문서의 콘텐츠와 각 요소 간의 관계 및 계층 구조를 나타냅니다 [4, 8, 9].
|
||||
- DOM 구축은 점진적(incremental)으로 이루어지므로, 브라우저는 네트워크 요청이 진행 중인 상태에서도 파싱을 시작하여 트리를 구성할 수 있습니다 [3, 5, 6].
|
||||
- 단, DOM 노드의 수가 많아질수록 레이아웃 및 페인트 등 이후의 렌더링 단계에서 브라우저의 연산 부담이 커지고 처리 시간이 길어집니다 [5, 6, 9].
|
||||
|
||||
**CSSOM(CSS Object Model) 구축**
|
||||
- CSSOM은 DOM이 어떻게 스타일링될지에 대한 모든 정보를 담고 있으며, 브라우저가 CSS 규칙을 이해하고 적용할 수 있도록 만든 트리 구조의 스타일 맵입니다 [2, 6, 8].
|
||||
- DOM과 달리 CSSOM 구축은 점진적이지 않으며, 문서의 렌더링을 차단(render-blocking)합니다 [5, 6].
|
||||
- 브라우저는 스타일이 적용되지 않은 원시 HTML이 사용자에게 노출되는 현상(FOUC)을 막기 위해 링크된 모든 스타일시트를 다운로드하고 파싱할 때까지 렌더링을 중단합니다 [5].
|
||||
- CSS 규칙은 하향식으로 종속(Cascade)되는 특성이 있어 파싱 도중 이전 규칙이 덮어써질 수 있으므로, 완전히 파싱이 끝나기 전까지는 렌더 트리를 구축하는 데 사용될 수 없습니다 [10, 11].
|
||||
- 브라우저는 CSS 선택자를 오른쪽에서 왼쪽으로 파싱합니다 [12]. 따라서 `.container.navigation.item`과 같이 구체적인 선택자는 단순히 `.item`을 찾는 것보다 DOM 트리를 거슬러 올라가며 조상 관계를 확인해야 하므로 연산 비용이 더 듭니다 [12, 13].
|
||||
|
||||
**렌더 트리(Render Tree) 합성**
|
||||
- DOM과 CSSOM 구조가 모두 준비되면, 브라우저는 이 둘을 결합하여 화면에 그릴 렌더 트리를 생성합니다 [7, 14].
|
||||
- 렌더 트리는 시각적으로 렌더링되는 요소들만 캡처합니다 [7]. 따라서 시각적 레이아웃에 영향을 주지 않는 `<script>`, `<meta>` 요소나, CSS에 의해 `display: none`으로 처리된 요소는 렌더 트리에서 제외됩니다 [7, 8, 14, 15].
|
||||
- 하지만 `visibility: hidden`이 적용된 요소는 보이지 않더라도 레이아웃 상에서 공간을 차지하므로 렌더 트리에 포함됩니다 [15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[Critical Rendering Path]]`, `[[Render Tree]]`, `[[Reflow and Repaint]]`
|
||||
- **Projects/Contexts:** `[[프론트엔드 성능 최적화]]`, `[[브라우저 렌더링 파이프라인 이해]]`
|
||||
- **Contradictions/Notes:** CSS 선택자의 구체성이 CSSOM 생성 연산 속도에 영향을 미치지만, 최신 브라우저는 파싱 속도가 매우 빨라 이로 인한 지연은 마이크로초 단위에 불과합니다 [11, 13]. 따라서 과도하게 선택자 구체성 최적화에 집착하기보다는 미니파이(minification)나 렌더링 차단을 방지하는 다른 CSS 최적화 기법에 집중하는 것이 좋습니다 [13].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[DOM(Document Object Model)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
DOM(Document Object Model)은 브라우저가 HTML 마크업을 내부적으로 표현하기 위해 생성하는 계층적인 트리 구조의 객체 모델입니다 [1, 2]. 브라우저가 HTML 데이터를 수신하면서 점진적으로 생성하며, 웹 페이지의 모든 콘텐츠와 요소 간의 구조적 관계를 담고 있습니다 [1, 3, 4]. 자바스크립트(JavaScript) 내의 다양한 API를 통해 DOM에 접근하고 이를 동적으로 조작할 수 있습니다 [2].
|
||||
|
||||
## 📖 Core Content
|
||||
- **DOM 생성 과정 (DOM Construction Process)**
|
||||
브라우저는 서버로부터 HTML 문서를 수신하면 즉시 파싱(Parsing)을 시작합니다 [5]. 이 과정은 전체 문서가 도착하기를 기다리지 않고 점진적(incremental)으로 이루어집니다 [1]. 수신된 데이터(바이트)는 문자로 변환되고, 이후 토큰(tokens)으로 변환된 다음 최종적으로 노드(nodes)로 변환되어 계층적인 DOM 트리를 형성합니다 [1, 6]. 시작 태그(startTag)와 종료 태그(endTag) 사이에 다른 태그들이 포함되는 방식으로 노드 간의 계층 구조가 정의됩니다 [6].
|
||||
|
||||
- **트리 구조와 구성 (Tree Structure and Composition)**
|
||||
DOM 트리는 문서의 콘텐츠를 묘사하며, `<html>` 요소가 트리 구조의 첫 번째 요소이자 루트(root) 노드가 됩니다 [4]. 다른 요소 안에 중첩된 요소들은 자식 노드(child nodes)가 되어 트리 내부에서 각 요소의 관계와 계층을 반영합니다 [4]. 생성된 DOM 트리는 이후 스타일 정보를 담고 있는 CSSOM(CSS Object Model)과 결합하여 화면에 그려질 요소를 결정하는 렌더 트리(Render Tree)를 구축하는 데 사용됩니다 [7, 8].
|
||||
|
||||
- **성능에 미치는 영향 (Performance Implications)**
|
||||
DOM 트리의 깊이와 복잡성은 브라우저의 성능과 직결됩니다 [9]. DOM에 존재하는 노드의 수가 많아질수록 렌더 트리 생성, 레이아웃(Layout), 페인트(Paint)와 같은 중요 렌더링 경로(Critical Rendering Path)의 후속 작업에 소요되는 시간과 연산 부담이 커지게 됩니다 [3, 4, 9].
|
||||
|
||||
- **직접적인 DOM 조작의 한계 (Limitations of Direct DOM Manipulation)**
|
||||
자바스크립트 등을 통해 DOM을 직접 변경하는 작업은 브라우저의 레이아웃(Reflow)과 페인트 단계를 지속적으로 트리거하기 때문에 본질적으로 속도가 느리고 비용이 많이 듭니다 [10]. 애플리케이션이 복잡해질 경우 여러 노드를 개별적으로 업데이트하면 중복 연산이 발생하며, 이는 React와 같은 프레임워크가 가상 DOM(Virtual DOM)을 도입하게 된 핵심 배경이 되었습니다 [10].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[CSSOM(CSS Object Model)]], [[Critical Rendering Path(CRP)]], [[Render Tree]], [[Virtual DOM]], [[Reflow / Repaint]]
|
||||
- **Projects/Contexts:** 브라우저 렌더링 과정 (Browser Rendering Process), 프론트엔드 성능 최적화 및 React의 Virtual DOM 도입 배경 이해 [7, 10, 11]
|
||||
- **Contradictions/Notes:** 소스 간의 모순된 정보는 없습니다. 참고로 DOM의 생성은 점진적(incremental)으로 진행되어 문서를 파싱하는 동안에도 화면을 그리기 시작할 수 있지만, CSSOM의 생성은 렌더링을 차단(render-blocking)한다는 점에서 두 모델의 구축 방식에 차이가 있습니다 [3, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[Next.js 기반의 Hybrid Rendering (SSR/CSR/RSC 혼합 적용)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Next.js 기반의 Hybrid Rendering은 단일 애플리케이션 내에서 SSR, CSR, SSG 및 React Server Components(RSC) 등 다양한 렌더링 방식을 페이지나 컴포넌트 특성에 맞게 혼합하여 사용하는 아키텍처입니다 [1, 2]. 이 접근 방식은 각 렌더링 전략의 장점만을 결합하여 초기 로딩 속도, SEO, 그리고 상호작용성(Interactivity)을 동시에 최적화할 수 있도록 돕습니다 [1]. 특히 최신 Next.js 환경에서는 기본적으로 무거운 작업을 서버에서 처리하는 RSC를 사용하고, 상호작용이 필요한 영역에만 선택적으로 CSR을 적용하여 클라이언트의 자바스크립트 부담을 최소화합니다 [3-5].
|
||||
|
||||
## 📖 Core Content
|
||||
- **페이지 단위의 유연한 렌더링 전략 선택:** Next.js와 같은 최신 프레임워크는 프로젝트의 요구사항에 따라 렌더링 방식을 유연하게 혼용할 수 있게 해줍니다 [1, 2]. 예를 들어, 내용이 변하지 않는 홈페이지나 마케팅 페이지에는 SSG(Static Site Generation)를 사용하고, 항상 최신 데이터를 반영해야 하는 상품 목록에는 SSR(Server-Side Rendering)을, 고도의 상호작용이 요구되는 유저 대시보드에는 CSR(Client-Side Rendering)을 개별적으로 적용할 수 있습니다 [1, 2].
|
||||
- **React Server Components (RSC)의 도입:** Next.js App Router 구조에서는 모든 컴포넌트가 기본적으로 서버 컴포넌트로 동작합니다 [5, 6]. 서버 컴포넌트는 오직 서버에서만 실행되어 렌더링된 HTML과 직렬화된 UI 표현(명령어)만 클라이언트로 전달하므로, 클라이언트 측 자바스크립트 번들에 어떠한 용량도 추가하지 않습니다(Zero Client-Side JavaScript) [3, 7, 8]. 이를 통해 브라우저에서의 하이드레이션(Hydration) 비용을 제거하고 데이터베이스에 직접 접근할 수 있습니다 [3, 8, 9].
|
||||
- **서버와 클라이언트 컴포넌트의 결합 원칙:** 모든 UI가 정적일 수는 없으므로 버튼 클릭이나 폼 입력과 같은 상호작용, 혹은 상태(State) 관리가 필요한 경우에는 파일 최상단에 `"use client"` 지시어를 선언하여 클라이언트 컴포넌트로 명시합니다 [3, 6]. 하이브리드 구조에서는 서버 컴포넌트가 데이터에 접근하고 클라이언트 컴포넌트를 렌더링(포함)하는 방식으로 혼합 구성됩니다 [3, 10]. 단, 클라이언트 컴포넌트가 서버 컴포넌트를 직접 임포트(import)할 수는 없으며, 의존성의 방향은 항상 서버에서 클라이언트로 흘러야 합니다 [11, 12].
|
||||
- **성능 최적화 및 부분 하이드레이션:** 이러한 혼합 아키텍처는 선택적 하이드레이션과 스트리밍(Streaming)을 가능하게 합니다 [10, 13, 14]. 상호작용이 필요 없는 영역은 서버에서 HTML로 완성되어 즉시 렌더링되며 자바스크립트 실행이 생략되지만, 클라이언트 컴포넌트가 위치한 조각에 대해서만 자바스크립트 번들이 전송되어 부분적으로 하이드레이션이 일어납니다 [10]. 이로 인해 초기 화면 표시 시간과 INP(Interaction to Next Paint) 지표가 극적으로 개선됩니다 [4, 7, 13].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Server Components (RSC)]], [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[Static Site Generation (SSG)]], [[Hydration]]
|
||||
- **Projects/Contexts:** [[Next.js App Router]], [[React 19]]
|
||||
- **Contradictions/Notes:** 서버 컴포넌트를 도입하여 클라이언트의 번들 크기를 줄일 수는 있지만, 렌더링 및 데이터 호출 부하가 서버로 집중되므로 복잡한 스트리밍 인프라나 명확한 캐싱 전략이 부재할 경우 서버 병목 현상이라는 새로운 문제가 발생할 수 있습니다 [15-17]. 또한 클라이언트 컴포넌트에서 서버 컴포넌트를 직접 호출할 수 없는 등 엄격한 트리 구성 규칙을 지켜야 합니다 [11, 12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,28 @@
|
||||
# [[React 18 & 19 Performance Optimization]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 18 및 19의 성능 최적화는 동시성 렌더링, 자동 배칭(Automatic Batching), 그리고 빌드 타임 컴파일러를 통해 불필요한 렌더링을 최소화하고 UI 반응성을 극대화하는 기술적 진보를 의미합니다 [1-4]. React 18은 다양한 비동기 이벤트의 상태 업데이트를 한 번에 묶는 자동 배칭과 `useTransition`을 통한 동시성 훅을 도입했습니다 [3, 5, 6]. React 19는 React Compiler를 도입하여 수동 메모이제이션의 부담을 없애고, React Server Components(RSC) 아키텍처를 통해 클라이언트로 전송되는 JavaScript 번들 크기를 획기적으로 줄였습니다 [2, 4, 7, 8].
|
||||
|
||||
## 📖 Core Content
|
||||
* **React 18 자동 배칭(Automatic Batching)**
|
||||
React 18부터는 프로미스, `setTimeout`, 네이티브 이벤트 핸들러 내부에서 발생하는 상태 업데이트까지 모두 한 번의 리렌더링으로 묶어서 처리하는 자동 배칭이 기본으로 적용됩니다 [3, 9, 10]. 이를 통해 Virtual DOM 디핑(Diffing) 연산을 최소화하며, 특정 데이터 집약적인 대시보드 사례에서는 렌더링 횟수를 최대 40% 줄이고 프레임 속도를 25% 향상시키는 성과를 냈습니다 [1, 11, 12]. 만약 즉각적인 DOM 업데이트가 반드시 필요한 경우라면 `flushSync` API를 사용하여 자동 배칭을 우회할 수 있습니다 [12-14].
|
||||
|
||||
* **동시성 렌더링 기능(Concurrent Features)**
|
||||
React 18/19의 동시성 훅인 `useTransition`과 `useDeferredValue`는 메인 스레드가 차단되는 것을 방지합니다 [5, 12, 13]. 타이핑이나 클릭과 같은 긴급한 상호작용 업데이트와, 대용량 리스트 필터링 등 비긴급 상태 업데이트를 분리 처리하여 앱의 INP(Interaction to Next Paint) 지표를 크게 개선합니다 [5, 12, 15-17].
|
||||
|
||||
* **React 19 Compiler와 자동 메모이제이션**
|
||||
2025년 말 안정화된 React Compiler는 빌드 타임에 추상 구문 트리(AST)를 분석하여 데이터 흐름을 파악하고 최적의 위치에 자동으로 메모이제이션 경계를 삽입합니다 [2, 18-21]. 이 컴파일러는 참조 동일성 문제로 발생하는 연쇄적인 리렌더링(Re-render Cascade)을 근본적으로 방지하며, 개발자가 직접 `useMemo`, `useCallback`, `React.memo`를 수동으로 작성해야 하는 인지적 부담을 덜어줍니다 [2, 4, 22, 23]. 정밀한 자동 메모이제이션 덕분에 Meta 내부 테스트에서는 렌더링 횟수가 60% 감소하고 사용자 상호작용 속도가 2.5배 향상되었습니다 [24].
|
||||
|
||||
* **React Server Components (RSC) 활용**
|
||||
RSC는 렌더링과 컴포넌트 로직이 서버에서만 배타적으로 실행되는 새로운 아키텍처로, 클라이언트 JavaScript 번들 사이즈에 추가 바이트를 발생시키지 않습니다(0 바이트) [7, 8, 25, 26]. 클라이언트에서 여러 번 발생하는 데이터 페칭 왕복(waterfall)을 유발하는 대신, 서버에서 직접 데이터베이스나 로컬 시스템에 안전하게 접근하여 처리한 뒤, 직렬화된 React 명령(React Flight 프로토콜)과 HTML만을 클라이언트에 스트리밍하여 초기 로딩 속도와 보안을 개선합니다 [27-31].
|
||||
|
||||
* **기본적인 성능 최적화 기법**
|
||||
최신 렌더링 기능 외에도, 성능 확보를 위해서는 긴 목록 렌더링 시 가상화를 적용하는 `react-window` 라이브러리 사용, 라우트 단위의 `React.lazy()`를 이용한 코드 분할, 그리고 인라인 객체 및 함수의 불필요한 생성 방지 같은 원칙적인 최적화가 꾸준히 권장됩니다 [32-35].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[Automatic Batching]]`, `[[React Compiler]]`, `[[Concurrent Rendering]]`, `[[React Server Components]]`
|
||||
- **Projects/Contexts:** `[[Next.js App Router]]`, `[[Virtual DOM]]`
|
||||
- **Contradictions/Notes:** 소스 자료에 따르면 React Compiler가 최적화의 90% 이상을 자동화하고 대부분의 경우 `useMemo`와 `useCallback`을 대체하지만, Effect 종속성을 명시적으로 제어해야 하거나 타사 라이브러리의 참조 안정성이 필수적인 밀리초 단위의 중요한 성능 경로(Critical performance path)에서는 여전히 수동 메모이제이션이 "이스케이프 해치(Escape Hatch)"로 작동해야 한다고 강조합니다 [36-39].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[React 18 Concurrent Features]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 18의 동시성 기능(Concurrent Features)은 렌더링 작업을 중단, 일시 중지 및 재개할 수 있도록 하여 애플리케이션의 반응성을 획기적으로 향상시키는 핵심 메커니즘입니다. 이 기능은 긴급한 사용자 상호작용(예: 타이핑, 클릭)과 덜 긴급한 작업(예: 무거운 데이터 필터링)을 분리하여 메인 스레드의 차단을 방지합니다. 결과적으로 연산량이 많은 상황에서도 UI가 멈추지 않고 부드럽게 작동하게 하여 사용자 경험을 개선하고 핵심 웹 지표(Core Web Vitals)를 최적화합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **동시성 렌더링의 기반 (Fiber Architecture & Lane Model):**
|
||||
React의 동시성 기능은 Fiber 아키텍처의 작업 루프(Work loop)와 타임 슬라이싱(Time-slicing)을 기반으로 작동합니다. 렌더링 작업을 작은 단위로 쪼개어 처리하며, 긴급한 사용자 입력이 발생할 경우 작업을 멈추고 브라우저에 제어권을 양보(Yield)할 수 있습니다 [1-3]. 업데이트의 중요도는 비트마스크 시스템인 'Lane 모델'을 통해 동기적(Sync), 사용자 차단(User-blocking), 기본(Normal), 유휴(Idle) 등의 우선순위 레벨로 관리됩니다 [4-6].
|
||||
* **`useTransition`과 `startTransition`:**
|
||||
긴급하지 않은 상태 업데이트의 우선순위를 낮추어 UI의 반응성을 유지하는 기능입니다. 타이핑과 동시에 검색 결과를 필터링하는 등의 무거운 연산을 `startTransition`으로 감싸면, React는 사용자의 긴급한 상호작용을 먼저 처리하고 메인 스레드가 여유로울 때 해당 업데이트를 백그라운드에서 처리합니다 [7-9]. 또한 `isPending` 플래그를 제공하여 무거운 작업이 진행되는 동안 사용자에게 시각적 피드백(로딩 상태 등)을 보여줄 수 있습니다 [10].
|
||||
* **`useDeferredValue`:**
|
||||
상태를 업데이트하는 코드(setState)를 직접 제어할 수 없고 외부(예: Props)에서 값을 받아올 때 렌더링을 지연시키는 훅입니다 [10]. React는 새로운 필터링 결과 등 연산이 완료될 때까지 이전 렌더링 결과를 계속 화면에 표시하여 UI가 얼어붙는(Freezing) 현상을 방지합니다 [11].
|
||||
* **`flushSync`를 통한 강제 동기화:**
|
||||
동시성 기능이 적용된 상태에서도 DOM 요소에 즉각적으로 포커싱을 하거나 레이아웃을 측정해야 하는 예외적인 상황을 위해 제공되는 API입니다. `flushSync`로 감싼 상태 업데이트는 React가 즉각적이고 동기적으로 렌더링하도록 강제합니다 [8, 9].
|
||||
* **자동 일괄 처리 (Automatic Batching):**
|
||||
React 18은 Promise, setTimeout, 비동기 작업 및 네이티브 이벤트 핸들러 내에서 연속적으로 발생하는 여러 상태 업데이트를 하나로 묶어 단일 리렌더링으로 처리합니다 [12-14]. 이로 인해 불필요한 Virtual DOM 비교와 렌더링 횟수가 급감하여 애플리케이션 성능이 향상됩니다 [13, 15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[Fiber Architecture]]`, `[[Automatic Batching]]`, `[[Lane Priority Model]]`, `[[Virtual DOM]]`
|
||||
- **Projects/Contexts:** `[[React Performance Optimization]]`, `[[Interaction to Next Paint (INP)]]`
|
||||
- **Contradictions/Notes:** 동시성 훅(`useTransition`, `useDeferredValue`)은 코드의 실제 실행 속도를 높여주는 것이 아닙니다. 대신 무거운 연산이 즉각적인 사용자 피드백을 방해하지 않도록 처리 순서를 미뤄, 앱이 시각적으로 더 "빠르게 반응하는 것처럼(feel faster)" 느끼게 만드는 아키텍처적 접근입니다 [16]. 또한 `flushSync`는 남용할 경우 동시성 및 일괄 처리로 얻는 성능 이점을 무효화할 수 있으므로 주의해서 사용해야 합니다 [17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,18 @@
|
||||
# [[React 19]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 19는 UI의 반응성을 높이고 성능 최적화를 자동화하는 데 중점을 둔 React의 주요 업데이트 버전입니다 [1, 2]. 이 버전은 빌드 타임에 자동으로 메모이제이션을 수행하는 React Compiler를 도입하여 개발자의 수동 최적화 부담을 크게 줄여줍니다 [3, 4]. 또한, 모든 컴포넌트를 기본적으로 서버 컴포넌트(Server Components)로 처리하여 클라이언트 측 자바스크립트 번들 크기를 획기적으로 줄이고 렌더링 효율을 높이는 패러다임의 전환을 가져왔습니다 [5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
- **React Compiler (자동 메모이제이션):** React 19 이상 환경에서 작동하는 React Compiler는 코드의 추상 구문 트리(AST)를 분석하여 데이터 흐름을 추적하고, 반응형 값과 정적 값을 스스로 구분합니다 [3, 4]. 결과적으로 `useMemo`, `useCallback`, `React.memo`와 같은 수동 메모이제이션 래퍼 없이도 자동으로 최적화 경계를 삽입해 불필요한 리렌더링 연쇄를 방지합니다 [3, 7, 8].
|
||||
- **동시성 렌더링(Concurrent Rendering) 강화:** `useTransition`과 `useDeferredValue` 같은 훅을 제공하여, 긴급한 UI 업데이트(사용자 입력 등)와 비긴급 업데이트(대용량 리스트 필터링 등)의 우선순위를 분리합니다 [2]. 이를 통해 무거운 연산이 메인 스레드를 블로킹하는 것을 방지하고 애플리케이션의 반응성(INP 등)을 최적의 상태로 유지합니다 [1, 9].
|
||||
- **서버 컴포넌트(RSC)의 기본화:** React 19에서는 모든 컴포넌트가 기본적으로 서버 컴포넌트로 동작합니다 [5]. 상호작용이 필요하여 브라우저에서 실행되어야 하는 경우에만 최상단에 `"use client"` 지시어를 명시해 클라이언트 컴포넌트로 선언합니다 [5]. 서버 컴포넌트는 클라이언트로 전송되는 JS 번들 크기를 없애고, 하이드레이션(Hydration) 단계를 생략하게 해 초기 로딩 속도와 성능을 대폭 향상시킵니다 [10-13].
|
||||
- **데이터 패칭 및 상태 관리의 진화:** 서버 컴포넌트는 브라우저를 거치지 않고 서버 환경에서 직접 데이터베이스나 파일 시스템에 접근하여 데이터를 가져올 수 있습니다 [14]. 또한 `useOptimistic`, `useActionState`, 프로미스를 직접 다루는 `use` 훅 등을 통해 데이터 패칭 및 비동기 상태 관리를 한층 더 효율적으로 수행할 수 있도록 지원합니다 [15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Compiler]], [[React Server Components (RSC)]], [[Concurrent Rendering]], [[useTransition]], [[useDeferredValue]]
|
||||
- **Projects/Contexts:** [[Frontend Performance Optimization]], [[Next.js App Router]]
|
||||
- **Contradictions/Notes:** React 19의 React Compiler가 수동 메모이제이션 작업의 90% 이상을 자동으로 처리하지만, 타사 라이브러리와의 통합이나 명시적 제어가 필요한 이펙트 의존성 관리를 위해서는 여전히 `useMemo`나 `useCallback`을 수동으로 사용하는 예외 수단(Escape Hatch)이 필요할 수 있습니다 [16-18].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,24 @@
|
||||
# [[React Fiber 아키텍처]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React Fiber는 React 16에서 도입된 조정(reconciliation) 엔진의 완전한 재작성 버전으로, 동시성 렌더링(concurrent rendering)을 지원하기 위해 설계되었습니다 [1, 2]. 기존의 동기식 '스택 조정자(stack reconciler)'가 렌더링 중 메인 스레드를 차단하던 문제를 해결하기 위해, 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위(units of work)로 분할하여 다수의 프레임에 걸쳐 처리합니다 [2, 3]. 이를 통해 우선순위에 따라 렌더링 작업을 일시 중지, 중단, 또는 재개할 수 있는 세밀한 제어와 타임 슬라이싱(time-slicing) 기능을 제공하여 UI의 응답성을 극대화합니다 [3-5].
|
||||
|
||||
## 📖 Core Content
|
||||
**Fiber 노드와 작업 루프 (Work Loop)**
|
||||
React의 각 컴포넌트는 Fiber 노드로 표현되며, 해당 컴포넌트의 타입, 상태(state), 속성(props)뿐만 아니라 부모(return), 자식(child), 형제(sibling) 관계를 나타내는 포인터를 포함합니다 [6-8]. Fiber 아키텍처의 중심에는 작업 루프가 존재하며, 스케줄러를 통해 우선순위와 가용 시간에 따라 다음 작업 단위를 선택하여 순차적으로 처리합니다 [2, 9]. 작업을 수행(`beginWork`, `completeWork`)한 후에는 더 높은 우선순위의 작업(예: 사용자 입력)을 처리하기 위해 브라우저에 제어권을 넘겨야 하는지(yield)를 지속적으로 확인합니다 [6, 9, 10].
|
||||
|
||||
**두 단계의 렌더링 프로세스 (Reconciliation Phases)**
|
||||
Fiber의 조정 과정은 작업을 중단하고 우선순위를 매기기 위해 두 가지 구별된 단계로 나뉩니다 [4].
|
||||
* **렌더 단계 (Render Phase):** 이 단계는 중단 가능(interruptible)하며, 브라우저의 DOM을 직접 변경하지 않고 메모리 내의 Fiber 트리를 순회하여 순수 계산만을 수행합니다 [4, 11]. 이전 상태와 새로운 상태를 비교하여 DOM 삽입, 삭제, 업데이트 등의 부작용(side effects)이 필요한 노드들을 파악하고, 이를 모아 최적화된 '이펙트 리스트(Effect list)'를 구축합니다 [4, 12, 13]. 더 높은 우선순위 작업이 들어오면 기존 작업을 일시 중지하고, 진행 중이던 작업(WIP, Work-In-Progress)을 저장하거나 폐기 및 재시작할 수 있습니다 [11, 14].
|
||||
* **커밋 단계 (Commit Phase):** 이 단계는 동기적으로 실행되며 중단할 수 없습니다(uninterruptible) [11, 15]. 렌더 단계에서 생성된 이펙트 리스트만을 순회하며 모든 변경 사항을 실제 DOM에 한 번에 적용합니다 [12, 15]. 이 과정에서 `useLayoutEffect`와 같은 동기적 레이아웃 효과와 비동기적인 `useEffect`가 함께 실행됩니다 [11, 15, 16].
|
||||
|
||||
**우선순위와 레인 모델 (Priority Levels and Lane Model)**
|
||||
Fiber는 여러 동시 작업을 관리하기 위해 32비트 정수 비트마스크를 활용한 '레인(Lane)'이라는 정교한 우선순위 모델을 사용합니다 [13, 17]. 타이핑이나 클릭과 같은 이산적인 사용자 입력은 즉시 처리되어야 하는 가장 높은 우선순위(Sync Lane)를 부여받고, 스크롤이나 호버 등의 연속적 입력은 그 다음 높은 우선순위를 갖습니다 [18, 19]. 반면 화면에 보이지 않는 오프스크린 렌더링이나 데이터 로깅 작업은 유휴(Idle) 상태에 처리되도록 낮은 우선순위가 할당됩니다 [18, 19]. 이 모델을 통해 React는 여러 우선순위가 섞인 업데이트를 효율적으로 관리하고, 지연된 작업이 영원히 실행되지 않는 기아 상태(starvation)를 방지하며 항상 쾌적한 반응성을 유지할 수 있습니다 [17, 20].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Concurrent Rendering]], [[Reconciliation]], [[Virtual DOM]]
|
||||
- **Projects/Contexts:** [[React 16]], [[Time-Slicing]]
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,17 @@
|
||||
# [[React Flight Protocol]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React Flight Protocol은 React Server Components(RSC)가 서버에서 렌더링된 결과를 클라이언트에게 전달할 때 사용하는 직렬화된 React 명령어 통신 규약입니다 [1]. 이 프로토콜은 무거운 전체 자바스크립트 코드를 전송하는 대신, 클라이언트의 React가 UI 조각들을 어떻게 결합해야 하는지 알려주는 가벼운 형태의 '청사진 언어(blueprint language)' 역할을 합니다 [1]. 비유하자면 브라우저에게 반쯤 조립된 가구와 함께, 빠진 상호작용 부품을 어떻게 끼워 넣는지 적힌 작은 조립 설명서를 보내는 것과 같습니다 [1].
|
||||
|
||||
## 📖 Core Content
|
||||
- **직렬화된 명령어와 HTML의 결합**: React Server Components는 단순히 순수한 HTML만을 브라우저에 출력하지 않습니다. 정적인 부분을 위한 HTML과 함께, 클라이언트 측에서 각 요소들을 어떻게 꿰매어 연결할지(stitch together) 지시하는 직렬화된 React 명령어를 생성하는데, 이 과정이 바로 React Flight 프로토콜을 통해 이루어집니다 [1].
|
||||
- **클라이언트 자바스크립트 전송 최소화**: 브라우저에 컴포넌트를 위한 전체 자바스크립트 번들을 보내는 대신, React Flight 프로토콜은 브라우저 내의 React가 여러 UI 조각들을 어떻게 맞추고 조립해야 하는지 알려주는 매우 가벼운 지침(instructions)만을 전달하여 통신과 렌더링을 최적화합니다 [1].
|
||||
- **상세 원리 한계**: 제공된 소스 내에서는 React Flight Protocol이 어떤 데이터 포맷을 사용하는지 등의 더 깊은 기술적 명세에 대해서는 다루고 있지 않습니다. 따라서 소스에 관련 정보가 부족합니다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Server Components]], [[Serialized React Instructions]]
|
||||
- **Projects/Contexts:** [[Modern React Architecture]], [[React 19]]
|
||||
- **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으나, React Flight Protocol 자체의 심층적인 구조나 동작 방식에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,35 @@
|
||||
# [[React Frontend Development]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React는 가상 DOM(Virtual DOM)과 컴포넌트 기반 아키텍처(CBA)를 활용하여 사용자 인터페이스를 효율적이고 선언적으로 구축하는 프론트엔드 라이브러리입니다 [1-3]. 브라우저의 비용이 많이 드는 Reflow와 Repaint 작업을 최소화하기 위해 '재조정(Reconciliation)' 알고리즘을 사용하며, 최신 버전에서는 Fiber 아키텍처와 자동 메모이제이션(React Compiler)을 통해 렌더링 성능을 극대화합니다 [1, 3-5]. 또한, 애플리케이션의 특성에 맞춰 CSR, SSR, SSG 및 React Server Components(RSC) 등 다양한 렌더링 전략을 지원하여 초기 로딩 속도, SEO, 상호작용(Interactivity)의 균형을 맞춥니다 [6-9].
|
||||
|
||||
## 📖 Core Content
|
||||
* **브라우저 렌더링 과정 (CRP) 및 비용 최소화**
|
||||
브라우저의 중요 렌더링 경로(Critical Rendering Path)는 HTML과 CSS를 파싱하여 DOM과 CSSOM 트리를 생성하고, 이를 결합해 렌더 트리(Render Tree)를 만듭니다 [10, 11]. 이후 요소의 정확한 위치와 크기를 계산하는 레이아웃(Reflow) 단계와 화면에 픽셀을 그리는 페인트(Repaint) 단계를 거칩니다 [12, 13]. Reflow는 연산 비용이 매우 높으며, 잦은 Reflow와 Repaint는 성능 저하를 유발하므로 DOM 접근과 조작을 최소화하는 것이 필수적입니다 [14-16].
|
||||
|
||||
* **Virtual DOM 및 재조정 (Reconciliation)**
|
||||
실제 DOM의 직접적인 조작으로 인한 성능 저하를 막기 위해, React는 메모리에 가벼운 UI 표현인 Virtual DOM을 유지합니다 [1, 3]. 상태가 변경되면 새로운 Virtual DOM을 생성하고 이전 트리와 비교(Diffing)하여 변경된 부분만 실제 DOM에 업데이트합니다 [1, 3]. 이 재조정 알고리즘은 요소의 타입 비교 및 리스트의 `key` 속성을 활용해 $O(n^3)$의 복잡도를 $O(n)$으로 최적화합니다 [17-20].
|
||||
|
||||
* **React Fiber 아키텍처와 동시성 렌더링 (Concurrent Rendering)**
|
||||
React 16에 도입된 Fiber 아키텍처는 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위로 분할하여 동시성 렌더링을 가능하게 합니다 [21-23]. 우선순위 기반 모델(Lane Model)과 시간 분할(Time-Slicing)을 적용하여, 사용자의 입력(타이핑, 클릭 등)과 같은 긴급한 작업이 들어오면 무거운 렌더링 작업을 잠시 중단(Yield)하고 메인 스레드를 비워두어 UI의 반응성을 유지합니다 [22, 24-26].
|
||||
|
||||
* **컴포넌트 기반 아키텍처 (Component-Based Architecture)**
|
||||
애플리케이션을 독립적이고 재사용 가능한 컴포넌트 단위로 분할하여 구축합니다 [27-29]. 각 컴포넌트는 자체 로직과 UI 상태를 캡슐화하여 렌더링하므로 유지보수성과 확장성이 높으며, 다른 프로젝트에서도 재사용하기 쉽습니다 [30-32].
|
||||
|
||||
* **렌더링 전략: CSR vs SSR vs SSG vs RSC**
|
||||
* **CSR (Client-Side Rendering):** 서버에서 빈 HTML을 받고 브라우저가 JavaScript를 다운로드하여 UI를 그립니다. 동적 상호작용에 유리하지만, JS 다운로드 전까지 화면이 보이지 않아 초기 로딩과 SEO에 불리합니다 [6, 33-35].
|
||||
* **SSR (Server-Side Rendering):** 서버에서 HTML을 미리 렌더링하여 전송하므로 초기 콘텐츠 표시가 빠르고 SEO에 유리합니다 [7, 36, 37]. 이후 브라우저에서 JS를 연결해 상호작용을 가능하게 하는 수화(Hydration) 과정을 거칩니다 [7, 36, 38].
|
||||
* **SSG (Static Site Generation):** 빌드 타임에 HTML을 생성하여 CDN으로 배포하므로 로딩 속도가 가장 빠릅니다 [8, 39].
|
||||
* **React Server Components (RSC):** 서버에서만 렌더링되며 클라이언트로 JavaScript 번들을 전혀 보내지 않습니다 [9, 40]. 번들 크기를 줄이고 서버 데이터베이스에 직접 접근할 수 있으며, 상호작용이 필요한 곳에만 Client Component를 혼합해 사용할 수 있습니다 [41-43].
|
||||
|
||||
* **최신 렌더링 최적화 기법 (React 18 & 19)**
|
||||
* **자동 배칭 (Automatic Batching):** React 18부터는 이벤트 핸들러뿐만 아니라 Promise, setTimeout 등 비동기 작업 내의 여러 상태 업데이트를 하나로 묶어(Batching) 단일 리렌더링만 유발합니다 [44-46].
|
||||
* **React Compiler:** React 19에 도입된 빌드 타임 최적화 도구로, 개발자가 수동으로 작성하던 `useMemo`, `useCallback`을 제거하고 AST를 분석해 자동으로 메모이제이션 경계를 삽입합니다 [5, 47-49]. 이를 통해 불필요한 연산과 리렌더링을 지능적으로 방지합니다 [49, 50].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Virtual DOM]], [[Critical Rendering Path (CRP)]], [[React Fiber]], [[Component-Based Architecture]], [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], [[React Server Components (RSC)]]
|
||||
- **Projects/Contexts:** [[Next.js]], [[Single-Page Applications (SPA)]]
|
||||
- **Contradictions/Notes:** React Compiler의 도입으로 `React.memo`, `useMemo`, `useCallback`과 같은 수동 메모이제이션이 90% 이상 불필요해졌으나, 서드파티 라이브러리의 불안정한 객체 참조를 다루거나 특정 Effect 의존성을 명시적으로 제어해야 하는 경우에는 여전히 탈출구(Escape Hatch)로써 수동 메모이제이션의 사용이 필요할 수 있습니다 [51-53].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,31 @@
|
||||
# [[React 기반 대규모 웹 애플리케이션 최적화]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 기반 대규모 웹 애플리케이션 최적화는 브라우저의 렌더링 과정(CRP)과 React의 가상 DOM(Virtual DOM) 및 재조정(Reconciliation) 메커니즘을 이해하여 불필요한 연산과 DOM 변경을 최소화하는 전략입니다 [1-3]. 이를 위해 메모이제이션, 코드 스플리팅, 가상화(Virtualization) 등의 클라이언트 측 기법과, Fiber 아키텍처를 통한 동시성 렌더링(Concurrent Rendering)을 활용하여 UI 응답성을 유지합니다 [4-7]. 또한, SSR, SSG와 같은 렌더링 방식과 React 서버 컴포넌트(RSC) 및 React Compiler를 결합하여 자바스크립트 번들 크기를 대폭 줄이고 초기 로딩 속도와 상호작용성을 극대화합니다 [8-11].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **브라우저 렌더링 과정과 Reflow/Repaint 최소화**
|
||||
브라우저는 HTML과 CSS를 파싱하여 DOM과 CSSOM을 생성하고, 이를 결합하여 화면에 표시될 렌더 트리(Render Tree)를 구축합니다 [3, 12-14]. 이후 요소의 정확한 크기와 위치를 계산하는 레이아웃(Reflow) 단계와 화면에 픽셀을 그리는 페인트(Repaint) 단계를 거칩니다 [15-18]. 리플로우는 계산 비용이 매우 높아 성능 저하의 주원인이 되므로, 불필요한 DOM 깊이를 줄이고 DOM 상호작용을 최소화해야 합니다 [19-21]. 애니메이션 처리 시 `top`이나 `left` 대신 `transform`과 같이 GPU 가속을 지원하는 속성을 사용하면 리플로우와 리페인트를 최소화하여 프레임 드롭(Jank)을 방지할 수 있습니다 [16, 22, 23].
|
||||
|
||||
* **가상 DOM(Virtual DOM)과 재조정(Reconciliation)**
|
||||
React는 실제 DOM을 직접 조작하는 대신, 가벼운 메모리 내 표현인 가상 DOM을 사용하여 UI 상태를 선언적으로 관리합니다 [2, 24, 25]. 상태가 변경되면 React는 이전 가상 DOM 트리와 새로운 트리를 비교(Diffing)하여 실제 DOM에 필요한 최소한의 업데이트만 반영합니다 [2, 26]. 이 과정에서 React는 O(n) 복잡도의 휴리스틱 알고리즘을 사용하며, 요소의 타입이 다르면 트리를 완전히 새로 구축하고, 동일한 타입의 리스트 컴포넌트는 고유한 `key` 속성을 통해 요소의 이동 여부를 식별하여 불필요한 재생성을 방지합니다 [27-29].
|
||||
|
||||
* **Fiber 아키텍처와 동시성 렌더링(Concurrent Rendering)**
|
||||
기존의 동기식 렌더링은 대규모 컴포넌트 트리를 처리할 때 메인 스레드를 블로킹하여 UI 응답성을 떨어뜨렸습니다 [30]. 이를 해결하기 위해 도입된 Fiber 아키텍처는 렌더링 작업을 '작업 단위(Unit of Work)'로 나누어 타임 슬라이싱(Time-slicing)을 가능하게 합니다 [30, 31]. 렌더 단계는 중단 및 재개가 가능하며, 차선(Lane) 기반 우선순위 모델을 통해 사용자 입력과 같은 긴급한 작업을 렌더링 계산보다 먼저 처리할 수 있습니다 [32-34]. React 19의 `useTransition` 및 `useDeferredValue` 훅을 활용하면 무거운 계산 상태 업데이트의 우선순위를 낮추어 메인 스레드를 차단하지 않고 대규모 데이터를 부드럽게 처리할 수 있습니다 [5, 35, 36].
|
||||
|
||||
* **자동 일괄 처리(Automatic Batching)와 React Compiler**
|
||||
React 18에 도입된 자동 일괄 처리는 Promise나 setTimeout 같은 비동기 콜백 내의 여러 상태 업데이트를 단일 리렌더링으로 묶어 렌더링 횟수를 대폭 줄입니다 [37-39]. 나아가 React 19부터 안정화된 React Compiler는 빌드 타임에 AST(추상 구문 트리)를 분석하여 컴포넌트와 값의 의존성을 파악하고, `useMemo`, `useCallback`, `React.memo`와 같은 수동 메모이제이션을 자동으로 삽입합니다 [10, 11, 40]. 이를 통해 불필요한 렌더링 전파(Re-render Cascade)를 차단하고, 수동 최적화의 복잡성과 오류를 근본적으로 제거합니다 [10, 41, 42].
|
||||
|
||||
* **컴포넌트 렌더링 전략 (CSR, SSR, SSG) 및 서버 컴포넌트(RSC)**
|
||||
대규모 애플리케이션에서는 페이지의 특성에 따라 렌더링 전략을 혼합(Hybrid)하여 사용합니다 [43, 44].
|
||||
* **CSR/SSR/SSG:** 클라이언트 사이드 렌더링(CSR)은 로드 후 상호작용성이 좋으나 초기 속도가 느리고 SEO에 불리하며, 서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)은 초기 로딩(FCP)과 SEO에 유리하지만 SSR의 경우 하이드레이션(Hydration) 완료 전까지 상호작용(TTI)이 지연되는 단점이 있습니다 [8, 45-48].
|
||||
* **React 서버 컴포넌트 (RSC):** RSC는 서버에서 독점적으로 렌더링되며 클라이언트로 자바스크립트 번들을 전혀 보내지 않습니다 [9, 49, 50]. 데이터베이스나 파일 시스템에 직접 접근할 수 있어 클라이언트-서버 간 불필요한 API 호출을 줄입니다 [51-53]. 대규모 앱에서는 읽기 전용 UI를 서버 컴포넌트로 처리하고, 상태나 이벤트 핸들러가 필요한 요소만 `use client` 지시어를 통해 클라이언트 컴포넌트로 분리함으로써 번들 크기를 극적으로 줄이고 성능을 최적화할 수 있습니다 [51, 54, 55].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Critical Rendering Path]], [[Virtual DOM]], [[Reconciliation]], [[Fiber Architecture]], [[React Server Components]], [[React Compiler]], [[Automatic Batching]]
|
||||
- **Projects/Contexts:** [[초기 로딩 및 SEO 최적화가 필수적인 대규모 이커머스 및 콘텐츠 플랫폼]], [[수천 개의 리스트와 실시간 데이터 처리가 필요한 대형 SaaS 대시보드 애플리케이션]]
|
||||
- **Contradictions/Notes:** 수동 메모이제이션(`React.memo`, `useMemo`)은 리렌더링을 방지할 수 있지만 참조 객체 저장 및 비교 연산에 따른 자체적인 오버헤드가 발생하므로 모든 컴포넌트에 무분별하게 적용하는 것은 오히려 성능을 저하시키는 안티 패턴입니다 [42, 56]. 그러나 최신 React Compiler가 적용된 환경에서는 이러한 최적화 판단과 메모이제이션 삽입이 빌드 타임에 자동으로 이루어지므로 개발자가 수동으로 제어할 필요성이 크게 줄어들었습니다 [11, 57]. 또한, SSR은 빠른 초기 화면(FCP)을 제공하지만 하이드레이션 병목 현상으로 인해 상호작용(TTI)까지 지연 시간이 발생할 수 있으므로 주의가 필요합니다 [45, 48].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[React 동시성 훅 (useTransition, useDeferredValue)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React의 동시성 훅(Concurrent Hooks)인 `useTransition`과 `useDeferredValue`는 긴급한 업데이트와 비긴급 업데이트를 분리하여 UI의 응답성을 유지하는 데 사용되는 도구입니다 [1]. 이 훅들은 연산 속도 자체를 높이는 것이 아니라 무거운 연산이 메인 스레드를 차단하는 것을 방지함으로써 애플리케이션의 체감 속도를 높여줍니다 [2]. 결과적으로 사용자 피드백을 즉각적으로 처리하게 하여 INP(Interaction to Next Paint)와 같은 성능 지표를 개선하는 데 핵심적인 역할을 합니다 [3].
|
||||
|
||||
## 📖 Core Content
|
||||
* **동시성 렌더링의 원리 및 효과:**
|
||||
React의 동시성 기능은 타이핑이나 클릭 같은 '긴급한 상호작용'과 대규모 리스트 필터링이나 차트 재계산 같은 '비긴급 업데이트'를 분리합니다 [1]. 이 기능은 React의 우선순위 시스템인 'Lane 모델'을 기반으로 작동하며, 특정 업데이트를 낮은 우선순위로 표시하여 UI의 응답성을 유지할 수 있게 합니다 [4]. 이 훅들을 사용하면 메인 스레드가 긴급한 사용자 상호작용에 즉시 대응할 수 있으므로, INP 점수를 낮추는 데 직접적으로 기여합니다 [3].
|
||||
|
||||
* **useTransition (비차단 상태 업데이트):**
|
||||
`useTransition`은 개발자가 상태 업데이트 코드를 직접 제어할 수 있을 때 사용합니다 [3]. 상태 변경 함수(`setState` 등)를 `startTransition`으로 감싸면, 해당 업데이트를 낮은 우선순위로 처리하여 메인 스레드가 여유로워질 때까지 연산을 지연시킵니다 [1, 3].
|
||||
* 주로 사용자가 타이핑할 때마다 검색 결과를 필터링하는 패턴이나, 데이터가 많은 애플리케이션에서의 탭 전환 등에 매우 효과적입니다 [1].
|
||||
* `isPending`이라는 플래그를 함께 제공하여, 무거운 연산이 백그라운드에서 실행되는 동안 사용자에게 즉각적인 시각적 피드백(예: 로딩 상태)을 줄 수 있습니다 [5].
|
||||
|
||||
* **useDeferredValue (무거운 렌더링 지연):**
|
||||
`useDeferredValue`는 외부 스토어나 부모 컴포넌트에서 props로 전달받는 등 상태 업데이트 코드를 직접 제어할 수 없을 때 상태 값 자체를 감싸기 위해 사용합니다 [3, 5].
|
||||
* 무거운 렌더링을 처리하는 동안 UI가 멈추는(freezing) 현상을 방지하기 위해, React는 새로운 결과가 준비될 때까지 화면에 이전 결과를 계속 표시합니다 [3].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Fiber Architecture]], [[Lane Model]], [[INP (Interaction to Next Paint)]]
|
||||
- **Projects/Contexts:** [[검색어 입력 필터링 (Search-as-you-type)]], [[데이터 집약적 대시보드의 탭 전환]]
|
||||
- **Contradictions/Notes:** 동시성 훅(`useTransition`)과 디바운싱(Debouncing)은 불필요한 작업을 줄여준다는 공통점이 있지만 목적이 다릅니다. 컴포넌트 수준에서 UI 업데이트를 지연시키는 데는 React 네이티브 방식인 `useTransition`이 더 적합한 반면, 잦은 API 호출 빈도를 낮추는 데는 여전히 디바운싱 기법을 사용하는 것이 최선입니다 [6].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,29 @@
|
||||
# [[React 성능 최적화 (React Performance Optimization)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 성능 최적화는 불필요한 연산과 재렌더링을 최소화하고 브라우저의 중요 렌더링 경로(Critical Rendering Path)를 효율적으로 관리하여 애플리케이션의 속도 및 응답성을 극대화하는 과정이다 [1, 2]. 이는 렌더링 계단식(Re-render Cascade) 문제 해결, 초기 번들 크기 감소, 리플로우(Reflow) 및 리페인트(Repaint) 제어를 주요 목표로 삼는다 [3-6]. 최근에는 React 18의 자동 배칭(Automatic Batching)과 React 19 컴파일러의 자동 메모이제이션 도입으로 인해, 개발자의 수동 최적화 부담이 크게 줄어들고 프레임워크 및 빌드 타임 레벨에서 성능 향상이 이루어지는 추세이다 [7-9].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **불필요한 재렌더링 방지 및 가상 DOM 최적화**
|
||||
부모 컴포넌트의 상태가 변경될 때 모든 자식 컴포넌트가 재렌더링되는 '렌더링 계단식' 문제는 성능 저하의 주된 원인이다 [3, 10]. 이를 방지하기 위해 기존에는 `React.memo`, `useMemo`, `useCallback`과 같은 수동 메모이제이션 기법을 사용하여 참조(Reference)의 동등성을 유지하고 불필요한 비교(Diffing) 연산을 차단했다 [11-13]. 또한, React 18에 도입된 자동 배칭(Automatic Batching)은 이벤트 핸들러뿐만 아니라 Promise나 `setTimeout` 같은 비동기 작업 내의 여러 상태 업데이트를 단일 렌더링으로 묶어주어 가상 DOM 작업과 렌더링 횟수를 획기적으로 줄여준다 [7, 14, 15].
|
||||
|
||||
* **빌드 타임 최적화: React 컴파일러(React Compiler)**
|
||||
React 19 컴파일러는 애플리케이션 코드를 구문 분석(AST)하여 정적 값과 반응형 값을 자동으로 식별하고, 최적의 위치에 메모이제이션 경계를 삽입하는 빌드 타임 도구이다 [8, 9, 16, 17]. 이를 통해 개발자가 수동으로 의존성 배열을 관리하며 겪는 과도한 메모이제이션(Over-memoization)이나 누락 문제를 해결하고, 값이 변경된 특정 부분만 렌더링하는 세밀한 반응성(Fine-Grained Reactivity)을 달성하여 성능 최적화 작업의 90%를 제거한다 [18-20].
|
||||
|
||||
* **동시성 렌더링과 파이버(Fiber) 아키텍처**
|
||||
React 16부터 도입된 파이버 아키텍처는 동기적으로 블로킹되던 기존 렌더링 방식을 벗어나, 렌더링 작업을 작은 단위로 나누고(Time-slicing) 우선순위(Lane model)를 부여하여 중단 및 재개가 가능하도록 만들었다 [21-24]. 이를 기반으로 하는 `useTransition` 및 `useDeferredValue` 훅을 사용하면, 무거운 데이터 필터링이나 화면 전환 같은 비긴급 업데이트의 우선순위를 낮춤으로써 타이핑과 같은 긴급한 상호작용이 지연 없이 처리되도록 하여 UI의 응답성(INP 개선)을 높일 수 있다 [25-28].
|
||||
|
||||
* **브라우저 렌더링 최적화: Reflow와 Repaint 최소화**
|
||||
React가 가상 DOM을 업데이트한 후, 브라우저가 화면을 그리는 과정에서 레이아웃 계산(Reflow)과 시각적 업데이트(Repaint)는 큰 비용을 수반한다 [5, 6, 29]. 렌더링 성능을 개선하려면 React Fragment를 사용해 불필요한 DOM 노드 래퍼를 줄이고 DOM의 깊이를 얕게 유지해야 한다 [30, 31]. 100개가 넘어가는 긴 리스트의 경우 화면에 보이는 노드만 렌더링하는 가상화(Virtualization) 라이브러리를 도입하여 다중 노드 생성 비용을 극적으로 줄일 수 있다 [32, 33]. 더불어 애니메이션 구현 시 레이아웃을 다시 계산하는 속성 대신 `transform` 속성 등을 활용해 GPU 가속을 적용하면 리플로우를 피할 수 있다 [34-36].
|
||||
|
||||
* **번들 사이즈 제어 및 렌더링 전략 고도화**
|
||||
초기 로딩 속도(LCP)를 개선하려면 다운로드해야 할 JavaScript 번들 크기를 최소화해야 한다. `React.lazy()`를 활용한 라우트 레벨의 코드 스플리팅을 적용하면 초기 번들 크기를 30~50%가량 줄일 수 있다 [37]. 한 걸음 더 나아가 서버에서만 실행되는 React Server Components(RSC)를 활용하면 무거운 라이브러리나 정적 데이터 페칭 로직이 브라우저로 전송되지 않아 JavaScript 번들 크기를 '0 바이트'에 가깝게 줄이고 수화(Hydration) 비용을 완전히 제거할 수 있다 [38-40].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Virtual DOM (가상 DOM)]], [[Critical Rendering Path (중요 렌더링 경로)]], [[React Compiler (React 컴파일러)]], [[React Server Components (RSC)]], [[Concurrent Rendering (동시성 렌더링)]]
|
||||
- **Projects/Contexts:** [[코어 웹 바이탈(Core Web Vitals) 개선 프로젝트]], [[프론트엔드 컴포넌트 기반 아키텍처(CBA) 구축]]
|
||||
- **Contradictions/Notes:** React 18의 자동 배칭(Automatic Batching) 기능은 기본적으로 활성화되어 렌더링 최적화에 기여하지만, 사용자가 즉각적인 시각적 피드백(예: 입력 포커스, 폼 값 즉각 업데이트)을 필요로 하는 경우에는 `flushSync` API를 사용하여 의도적으로 배칭을 우회하고 동기적 렌더링을 강제해야 한다 [28, 41, 42]. 한편 기존 React 생태계에서는 `useMemo`와 같은 수동 최적화가 필수적이었으나, React 컴파일러 도입 이후에는 이들이 불필요해지며 의도적인 제어나 서드파티 라이브러리 대응과 같은 예외적 상황에서만 사용하는(Escape Hatch) 방식으로 패러다임이 바뀌고 있다 [19, 43-45].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,19 @@
|
||||
# [[React 컴파일러 (React Compiler)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 컴파일러(React Compiler, 이전 명칭 'React Forget')는 빌드 타임에 React 애플리케이션을 자동으로 최적화해주는 도구이다 [1-4]. 개발자가 수동으로 작성하던 `useMemo`, `useCallback`, `React.memo` 등의 메모이제이션 작업을 컴파일러가 코드를 분석하여 필요한 곳에 자동으로 삽입한다 [2, 3]. 이를 통해 불필요한 리렌더링을 방지하고 코드의 가독성을 높이며, 메모이제이션 누락이나 오용으로 인한 성능 저하를 효과적으로 해결한다 [4-6].
|
||||
|
||||
## 📖 Core Content
|
||||
- **작동 원리**: React 컴파일러는 Babel 또는 SWC 플러그인 형태로 동작하며 빌드 단계에서 코드를 변환한다 [7-9]. Abstract Syntax Tree(AST)를 분석하여 데이터 흐름을 추적하고, 각 값을 정적(Static), 반응형(Reactive), 파생(Derived)으로 분류한 뒤 최적의 위치에 메모이제이션 경계를 자동으로 삽입한다 [1, 10, 11]. 단순히 전체 컴포넌트를 캐싱하는 것을 넘어, 개별 JSX 요소와 내부 계산 작업까지 세밀하게(granular) 최적화하는 것이 특징이다 [12, 13].
|
||||
- **주요 장점**: 수동 메모이제이션이 유발하는 개발자의 인지적 부담과 '의존성 배열 지옥(Dependency Array Hell)'을 제거하여 코드를 깔끔하게 유지할 수 있다 [2, 6, 13]. 실제 프로덕션 환경(Meta, Sanity Studio, Wakelet 등)에서 적용한 결과 초기 로드 시간 단축, 상호작용 지연 시간(INP) 개선, 리렌더링 횟수 60% 감소 등의 괄목할 만한 성능 향상이 입증되었다 [14-16].
|
||||
- **단점 및 한계**: 일부 서드파티 라이브러리(예: TanStack Query 등 렌더링마다 의도적으로 새로운 객체를 반환하는 훅)와 호환성 문제가 발생하여 컴파일러의 최적화가 무력화될 수 있다 [17]. 또한, 내부 동작이 블랙박스처럼 처리되어 예기치 않은 리렌더링 발생 시 원인 규명과 디버깅이 더 까다로워질 수 있으며, React의 기본 원칙(Rules of React)을 다수 위반한 레거시 코드베이스에서는 곧바로 도입하기 어렵다 [18-20].
|
||||
- **도입 및 마이그레이션 전략**: 모든 코드에 일괄 적용할 필요 없이 특정 디렉터리부터 시작하거나 `'use compiler'` 지시어를 사용하여 파일 단위로 점진적인 도입이 가능하다 [21, 22]. 컴파일러 적용 전 ESLint 플러그인을 사용하여 React 규칙 위반 사항을 식별하고 수정하는 것이 적극 권장된다 [18, 22].
|
||||
- **수동 메모이제이션의 잔존 필요성**: 컴파일러가 대부분의 최적화를 자동으로 처리하지만, 이펙트(Effect)의 의존성 제어나 안정적인 참조가 필수적인 서드파티 라이브러리 연동 등 명시적인 제어가 필요한 상황(Escape Hatch)에서는 여전히 `useMemo` 및 `useCallback`을 사용해야 한다 [23-26].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[메모이제이션 (Memoization)]], [[빌드 타임 최적화 (Build-Time Optimization)]], [[리렌더링 (Re-rendering)]]
|
||||
- **Projects/Contexts:** [[Meta 프로덕션 앱 (Instagram, Quest Store)]], [[Sanity Studio]], [[Next.js 및 Vite 통합]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 React 컴파일러가 적용된 컴포넌트는 React DevTools에서 `Memo ✨` 배지가 표시되지만, 이것이 항상 최적화의 성공을 의미하는 것은 아니다 [17, 27]. 속성에 인라인 객체나 함수 등 불안정한 참조가 전달될 경우, 배지가 있더라도 부모 컴포넌트 업데이트 시 여전히 리렌더링이 발생할 수 있으므로 주의해야 한다 [17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,37 @@
|
||||
# [[Virtual DOM과 Reconciliation]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Virtual DOM은 UI의 이상적인 가상 표현을 메모리에 유지하는 프로그래밍 개념입니다 [1]. Reconciliation(재조정)은 이 Virtual DOM을 실제 DOM과 동기화하여 변경된 부분만 파악하고 효율적으로 업데이트하는 React의 핵심 프로세스입니다 [1, 2]. React는 O(n) 복잡도를 가진 휴리스틱 Diffing 알고리즘을 사용하여 실제 DOM 조작으로 인해 발생하는 비싼 렌더링 비용과 성능 저하를 최소화합니다 [3-5].
|
||||
|
||||
## 📖 Core Content
|
||||
**Virtual DOM의 개념과 도입 배경**
|
||||
* 브라우저의 실제 DOM을 직접 수정하는 작업은 레이아웃(Reflow)과 페인트(Repaint) 단계를 반복적으로 트리거하기 때문에 본질적으로 매우 느립니다 [2].
|
||||
* React는 이 문제를 추상화하기 위해 가볍고 메모리 내에 존재하는 UI 표현인 Virtual DOM을 도입했습니다 [2].
|
||||
* 이를 통해 개발자는 원하는 UI 상태를 선언적으로 명시하기만 하면 되며, React의 ReactDOM과 같은 라이브러리가 내부적으로 속성 조작, 이벤트 처리 및 수동 DOM 업데이트를 알아서 관리하게 됩니다 [1, 2].
|
||||
* React 세계에서 Virtual DOM은 일반적으로 사용자 인터페이스를 나타내는 객체인 'React Elements'를 의미하며, 컴포넌트 트리에 대한 추가 정보를 담고 있는 내부 객체인 'Fiber' 역시 그 구현의 일부로 간주될 수 있습니다 [6].
|
||||
|
||||
**Reconciliation과 휴리스틱 Diffing 알고리즘**
|
||||
* 상태(State)나 속성(Props)이 업데이트되면 `render()` 함수는 새로운 React Element 트리를 반환하며, React는 이를 가장 최근의 트리와 비교하여 UI를 어떻게 효율적으로 업데이트할지 계산합니다 [4].
|
||||
* 두 트리를 비교하여 변환하기 위한 최소한의 연산을 찾는 일반적인 알고리즘은 O(n^3)의 복잡도를 가지므로 실제 애플리케이션에 적용하기에는 비용이 너무 높습니다 [4].
|
||||
* 따라서 React는 다음 두 가지 가정에 기반한 **O(n) 휴리스틱 알고리즘**을 구현했습니다 [3-5]:
|
||||
1. 서로 다른 타입의 요소(Elements)는 본질적으로 다른 트리를 생성한다 [3, 5].
|
||||
2. 개발자가 `key` 속성을 제공하여 여러 렌더링 간에 어떤 자식 요소가 안정적인지 힌트를 줄 수 있다 [3, 5].
|
||||
|
||||
**비교(Diffing) 프로세스 상세 처리**
|
||||
* **다른 타입의 요소:** 루트 요소의 타입이 다르면(예: `<a>`에서 `<img>`로, 혹은 `<div>`에서 `<span>`으로 변경), React는 기존 트리를 완전히 파괴하고 처음부터 새 트리를 구축합니다 [3, 7]. 이 과정에서 이전 DOM 노드는 파괴되며 연관된 모든 컴포넌트의 상태(State)가 유실됩니다 [7].
|
||||
* **같은 타입의 DOM 요소:** 동일한 타입의 React DOM 요소를 비교할 때는 기본 DOM 노드를 유지한 채, `className`이나 `style` 등 변경된 속성(Attributes)만을 업데이트합니다 [8, 9].
|
||||
* **같은 타입의 컴포넌트 요소:** 컴포넌트가 업데이트될 때 인스턴스는 동일하게 유지되어 렌더링 간에 상태가 보존됩니다. React는 새 요소와 일치하도록 기본 컴포넌트 인스턴스의 props를 업데이트하고 수명 주기(Lifecycle) 메서드를 호출한 뒤, 자식 노드에 대해 재귀적으로 처리합니다 [9, 10].
|
||||
* **자식 노드 처리와 Key 속성:** 자식 노드를 순회할 때 리스트의 맨 앞에 요소를 추가하면 전체 트리가 변경된 것으로 인식해 매우 비효율적으로 작동할 수 있습니다 [10, 11]. 이를 해결하기 위해 `key` 속성을 사용하여 원본 트리와 후속 트리의 자식을 정확히 매칭시킵니다 [3, 11]. `key`는 형제 노드 사이에서 안정적이고 예측 가능하며 고유해야 성능 저하와 상태 유실을 방지할 수 있습니다 [12].
|
||||
|
||||
**React Fiber 아키텍처를 통한 렌더링 최적화**
|
||||
* 과거 동기적인 스택 재조정자(Stack reconciler)는 대규모 애플리케이션 처리 시 메인 스레드를 차단(Blocking)하여 UI의 반응성을 떨어뜨리는 문제가 있었습니다 [13, 14].
|
||||
* React 16은 이를 해결하기 위해 동시성 렌더링(Concurrent rendering)을 지원하는 **Fiber 아키텍처**로 재조정 엔진을 완전히 재작성했습니다 [15-17].
|
||||
* Fiber는 렌더링 작업을 '작업 단위(Unit of work)'로 나누고, 우선순위(Lanes) 시스템을 통해 긴급한 상호작용(클릭, 타이핑 등)을 위해 작업을 일시 중단, 양보(Yield), 및 재개할 수 있도록 지원합니다 [14, 16, 18, 19]. 이로 인해 Virtual DOM의 재조정 과정 중에도 UI 반응성을 유지할 수 있습니다 [16, 18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Fiber Architecture]], [[Critical Rendering Path (CRP)]], [[Concurrent Rendering]]
|
||||
- **Projects/Contexts:** [[React Application Performance Optimization]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 Virtual DOM 트리는 설계상 불변(immutable)으로 취급되지만, 단일 자식 노드를 여러 위치에서 사용하는 경우 복사 비용 문제가 발생할 수 있습니다. 이를 해결하기 위해 React는 현재 설치된 상태를 나타내는 가변적인 형태의 "Augmented DOM" 구조를 구축하며, 이것이 바로 React의 Fiber 데이터 구조가 수행하는 역할입니다 [20].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,27 @@
|
||||
# [[가상 DOM (Virtual DOM) 및 Fiber]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
가상 DOM(Virtual DOM)은 사용자 인터페이스(UI)의 이상적인 상태를 메모리에 저장하고 가볍게 표현한 자바스크립트 객체로, 실제 DOM과의 동기화(재조정, Reconciliation)를 통해 직접적인 DOM 조작의 비효율성을 추상화하는 개념입니다 [1-3]. React Fiber는 이러한 재조정 엔진을 완전히 재작성하여 React 16에 도입된 아키텍처로, 동기식 렌더링의 한계를 극복하고 렌더링 작업을 중단 및 재개할 수 있는 동시성 렌더링(Concurrent Rendering)을 지원합니다 [4, 5]. Fiber 아키텍처는 렌더링 작업을 '작업 단위(Fiber node)'로 분할하여 우선순위에 따라 스케줄링함으로써 애플리케이션의 반응성을 극대화합니다 [6-8].
|
||||
|
||||
## 📖 Core Content
|
||||
* **가상 DOM과 휴리스틱 재조정 알고리즘**
|
||||
실제 DOM을 직접 수정하는 것은 브라우저의 레이아웃 및 페인트 단계를 유발하므로 계산 비용이 많이 듭니다 [1]. React는 가상 DOM을 도입하여 이전 가상 DOM 트리와 새롭게 계산된 가상 DOM 트리를 비교(Diffing)하여 변경 사항을 감지합니다 [2]. 이론적인 트리 비교 알고리즘의 복잡도는 $O(n^3)$이지만, React는 두 가지 가정(다른 타입의 요소는 다른 트리를 생성하며, 개발자가 부여한 'key'를 통해 안정적인 요소를 식별함)을 바탕으로 $O(n)$의 휴리스틱 알고리즘을 구현하여 성능을 최적화합니다 [9-11].
|
||||
|
||||
* **스택 재조정자(Stack Reconciler)의 한계와 Fiber의 도입**
|
||||
Fiber 도입 이전의 React는 컴포넌트 트리를 단일 재귀 호출로 처리하는 동기식 스택 재조정자를 사용했습니다 [6]. 이 방식은 작업이 길어질 경우 16.6ms의 프레임 예산을 초과하여 메인 스레드를 차단하고 UI를 멈추게 하는 한계가 있었습니다 [6]. 이를 해결하기 위해 등장한 Fiber는 컴포넌트를 나타내는 변경 가능한 인메모리 구조(Fiber 데이터 구조)를 통해 렌더링 작업을 관리합니다 [12].
|
||||
|
||||
* **Fiber의 렌더링 단계 (Render & Commit Phases)**
|
||||
Fiber는 재조정 과정을 두 가지 명확한 단계로 분리하여 실행합니다 [13].
|
||||
1. **렌더 단계(Render Phase):** 이 단계는 비동기적이며 중단 가능합니다 [13]. React는 Fiber 트리를 순회하며 변경 사항을 계산하고 실제 DOM을 변형하지 않은 채로 부작용(Effect) 목록을 작성합니다 [13, 14]. 처리 도중 우선순위가 높은 작업(예: 사용자 입력)이 발생하면 브라우저에 제어권을 양보(Yield)할 수 있습니다 [6, 15].
|
||||
2. **커밋 단계(Commit Phase):** 이 단계는 동기적이며 중단할 수 없습니다 [16]. 렌더 단계에서 생성된 부작용 목록(DOM 삽입, 업데이트, 삭제 등)을 실제 DOM에 한 번에 적용하고, 동기식 레이아웃 효과(`useLayoutEffect`)를 실행합니다 [16, 17].
|
||||
|
||||
* **우선순위 레인(Lane) 모델과 스케줄링**
|
||||
React의 스케줄러는 비트마스크(Bitmask) 시스템을 사용하는 'Lane 모델'을 통해 동시성 작업을 관리합니다 [18, 19]. 업데이트의 성격에 따라 Sync Lane(사용자 타이핑, 클릭 등 즉시 처리), InputContinuous Lane(스크롤 등), Default Lane, Idle Lane(백그라운드 작업) 등으로 우선순위를 분류합니다 [20, 21]. 이를 통해 무거운 연산이 진행 중이더라도 메인 스레드를 차단하지 않고 긴급한 사용자 상호작용에 즉각적으로 반응할 수 있습니다 [20, 22].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[재조정 (Reconciliation)]], [[동시성 렌더링 (Concurrent Rendering)]], [[Critical Rendering Path (CRP)]], [[레이아웃 스래싱 (Layout Thrashing)]]
|
||||
- **Projects/Contexts:** [[React 16]], [[React 18 Concurrent Features (useTransition, useDeferredValue)]]
|
||||
- **Contradictions/Notes:** 가상 DOM 트리는 설계상 불변(Immutable)으로 취급되지만, React 내부적으로는 현재 설치된 상태(설치된 DOM 노드에 대한 참조 등)를 추적하기 위해 변경 가능한(Mutable) "증강된 DOM(Augmented DOM)" 형태인 Fiber 데이터 구조를 사용합니다 [12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,33 @@
|
||||
# [[가상 DOM과 재조정 (Virtual DOM and Reconciliation)]]
|
||||
|
||||
## 📌 Brief 시 Summary
|
||||
가상 DOM(Virtual DOM)은 실제 DOM과 동기화되는 사용자 인터페이스(UI)의 가벼운 인메모리(in-memory) 표현입니다 [1, 2]. React는 이 가상 DOM을 사용하여 이전 상태와 새로운 상태를 비교(Diffing)한 뒤, 가장 효율적인 방식으로 실제 DOM을 업데이트하는 '재조정(Reconciliation)' 과정을 수행합니다 [2, 3]. 이 메커니즘은 수동적인 DOM 조작의 비효율성을 추상화하고 선언적인 API를 가능하게 하여 애플리케이션의 렌더링 성능을 최적화합니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **가상 DOM의 도입 배경 및 개념**
|
||||
* 웹 브라우저에서 DOM을 직접 수정하는 것은 브라우저의 중요 렌더링 경로(Critical Rendering Path)에 있는 레이아웃(Layout) 및 페인트(Paint) 단계를 트리거하기 때문에 본질적으로 속도가 느립니다 [1].
|
||||
* React는 평범한 JavaScript 객체 형태인 가상 DOM을 도입하여 UI 엘리먼트를 표현함으로써 이 문제를 해결합니다 [3]. 이는 일시적인 프레젠테이션 상태를 지속적인 애플리케이션 상태에서 분리하여 불필요한 렌더링 작업을 줄입니다 [3].
|
||||
|
||||
* **휴리스틱 기반의 비교 알고리즘 (Heuristic Diffing Algorithm)**
|
||||
* 일반적으로 두 트리를 비교하는 알고리즘은 $O(n^3)$의 시간 복잡도를 가지며, 이는 실제 애플리케이션에 적용하기에는 너무 무겁습니다 [4, 5].
|
||||
* React는 두 가지 가정을 바탕으로 $O(n)$의 시간 복잡도를 갖는 휴리스틱 알고리즘을 사용합니다 [4, 6].
|
||||
1. 서로 다른 타입의 엘리먼트는 완전히 다른 트리를 생성합니다 [4, 6].
|
||||
2. 개발자는 `key` prop을 통해 여러 렌더링 사이에서 어떤 자식 엘리먼트가 안정적으로 유지되는지 React에 힌트를 제공할 수 있습니다 [4, 6].
|
||||
|
||||
* **엘리먼트 타입에 따른 업데이트 방식**
|
||||
* **다른 타입의 엘리먼트:** 루트 엘리먼트의 타입이 다르면(예: `<a>`에서 `<img>`로 변경), React는 이전 트리를 완전히 파괴하고 새로운 트리를 처음부터 다시 구축하며, 이때 이전 트리와 연관된 상태(State)는 모두 소실됩니다 [4, 7].
|
||||
* **동일한 타입의 DOM 엘리먼트:** 동일한 타입일 경우 기반이 되는 DOM 노드를 그대로 유지하고, 변경된 속성이나 스타일(예: `className`, `color`)만 업데이트합니다 [8, 9].
|
||||
* **동일한 타입의 컴포넌트 엘리먼트:** 컴포넌트 인스턴스가 동일하게 유지되어 렌더링 간에 상태가 보존됩니다 [9]. 새로운 엘리먼트에 맞춰 props를 업데이트한 후 `render()` 메서드를 호출하고, 그 결과에 대해 비교 알고리즘을 재귀적으로 수행합니다 [9, 10].
|
||||
|
||||
* **자식 노드 재귀 처리와 `key`의 역할**
|
||||
* React가 자식 노드들을 순회할 때, 기본적으로 두 리스트를 동시에 순회하며 차이가 있을 때마다 변이(mutation)를 생성합니다 [10].
|
||||
* 목록의 맨 앞에 새로운 엘리먼트가 추가되는 경우, 순서가 밀린 모든 자식 노드를 변경해야 하므로 성능이 크게 저하될 수 있습니다 [11].
|
||||
* 이를 해결하기 위해 `key` 속성을 부여하면, React는 원래 트리의 자식과 새로운 트리의 자식을 효율적으로 매치하여 기존 엘리먼트를 그대로 이동시킬 수 있습니다 [11, 12]. 단, 배열의 인덱스를 키로 사용하면 항목이 재정렬될 때 컴포넌트의 상태가 꼬이는 등의 문제가 발생할 수 있습니다 [12, 13].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Fiber Architecture]], [[DOM (Document Object Model)]], [[Critical Rendering Path]]
|
||||
- **Projects/Contexts:** [[React]]
|
||||
- **Contradictions/Notes:** 초기 구현이나 단순화된 개념에서는 '새롭게 계산된 가상 DOM'과 '이전 가상 DOM'을 직접 비교한다고 설명하지만, React는 단일 자식 노드가 여러 곳에서 공유되는 문제를 해결하기 위해 현재 설치된 상태를 나타내는 변경 가능한(mutable) "증강된 DOM(augmented DOM)"인 Fiber 데이터 구조를 생성하여 활용합니다 [14, 15].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[동시성 렌더링 (Concurrent Rendering)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
동시성 렌더링(Concurrent Rendering)은 React의 Fiber 아키텍처를 기반으로 메인 스레드를 동기적으로 차단하지 않고 렌더링 작업을 중단 및 재개할 수 있도록 하는 렌더링 방식입니다 [1, 2]. 이 기술은 전체 렌더링 작업을 작은 단위로 쪼개어 처리하는 타임 슬라이싱(Time-Slicing)을 통해, 긴급한 사용자 상호작용을 우선적으로 처리할 수 있도록 브라우저에 제어권을 양보합니다 [2-4]. 이를 통해 무거운 연산이 백그라운드에서 진행되는 동안에도 UI의 반응성을 부드럽게 유지할 수 있습니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
- **Fiber 아키텍처와 작업 분할 (Time-Slicing)**
|
||||
기존의 동기식 스택 리컨실러(Stack Reconciler)가 메인 스레드를 길게 차단하여 UI가 멈추는 문제를 해결하기 위해, React 16부터 도입된 Fiber 아키텍처는 동시성 렌더링을 지원합니다 [1, 2]. 전체 렌더링 작업을 '작업 단위(unit of work)'인 Fiber 노드로 나누어 처리하며, 각 작업 후 브라우저에 제어권을 양보(yield)하여 더 높은 우선순위의 작업(예: 사용자 입력)이 있는지 확인합니다 [3, 6]. 렌더링 단계는 이렇게 중단과 재개가 가능하지만, 실제 DOM을 변경하는 커밋 단계는 동기적으로 처리됩니다 [7, 8].
|
||||
|
||||
- **우선순위 기반의 레인(Lane) 모델**
|
||||
동시성 렌더링은 '레인(Lane)'이라는 비트마스크 시스템을 통해 렌더링 작업의 우선순위를 관리합니다 [9, 10]. 클릭이나 타이핑 같은 사용자 상호작용은 가장 높은 우선순위(Sync Lane)로 즉시 처리되고, 화면에 보이지 않는 요소의 렌더링이나 무거운 데이터 업데이트는 낮은 우선순위(Idle 또는 Default Lane)로 미루어집니다 [9, 11].
|
||||
|
||||
- **React 18/19의 동시성 훅 (Concurrent Features)**
|
||||
`useTransition`과 `useDeferredValue` 훅은 이 동시성 렌더링 모델을 직접적으로 활용합니다 [5]. `useTransition`은 대규모 목록 필터링과 같은 비긴급 상태 업데이트의 우선순위를 낮춰 입력 지연을 방지하며 [5, 12], `useDeferredValue`는 무거운 렌더링 계산이 필요한 값의 적용을 지연시킵니다 [12, 13].
|
||||
|
||||
- **동시성 하이드레이션 (Concurrent Hydration)**
|
||||
React 18부터는 하이드레이션 과정에도 동시성 렌더링이 적용됩니다 [14]. 거대한 덩어리의 하이드레이션 작업을 작은 조각으로 나누어 브라우저의 상호작용 처리를 방해하지 않게 하며, Suspense와 결합할 경우 사용자가 상호작용하는 UI 컴포넌트부터 우선적으로 하이드레이션하여 초기 로딩 성능(Total Blocking Time)을 크게 개선합니다 [14, 15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Fiber Architecture]], [[Time-Slicing]], [[Lane Model]], [[Reconciliation]]
|
||||
- **Projects/Contexts:** [[React 18/19 Performance Optimization]], [[Concurrent Hydration]]
|
||||
- **Contradictions/Notes:** 동시성 렌더링 기능(`useTransition`, `useDeferredValue` 등)은 애플리케이션의 실제 코드 실행 속도를 높이는 것이 아니라, 무거운 연산 중에도 긴급한 피드백을 방해하지 않도록 처리 순서를 조정함으로써 앱이 더 빠르게 "느껴지도록(feel faster)" 체감 성능을 향상시키는 역할을 합니다 [16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,22 @@
|
||||
# [[렌더링 차단 리소스(Render-blocking resources)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
렌더링 차단 리소스란 브라우저가 화면에 페이지를 그리는 렌더링 과정을 일시적으로 중단하게 만드는 핵심 웹 리소스를 뜻합니다 [1]. 대표적인 예인 CSS는 스타일이 적용되지 않은 화면(FOUC)이 사용자에게 노출되는 것을 막기 위해 CSSOM이 완전히 구성될 때까지 렌더링을 막습니다 [2, 3]. 동기적으로 실행되는 JavaScript 또한 HTML 파서를 멈추게 만들어 결과적으로 렌더링을 차단합니다 [4, 5]. 이러한 리소스들을 비동기 처리하거나 다운로드를 지연시키는 등 최적화하는 것은 초기 페이지 로드 속도와 웹 성능을 향상시키는 핵심 요소입니다 [6, 7].
|
||||
|
||||
## 📖 Core Content
|
||||
- **CSS의 렌더링 차단 원리**: 브라우저가 문서 파싱 중 일부 외부 리소스 요청을 만나면 해당 에셋이 처리될 때까지 렌더링을 중단합니다 [8]. CSS는 기본적으로 렌더링 차단 리소스로 동작하는데, 그 이유는 나중에 로드된 스타일 규칙이 이전 규칙을 덮어씌울 수 있기 때문에 브라우저가 CSSOM(CSS Object Model)을 완성하기 전까지 화면 렌더링을 보류해야 하기 때문입니다 [3]. 이는 사용자가 스타일이 입혀지지 않은 HTML 원본을 보게 되는 '스타일 없는 콘텐츠의 번쩍임(FOUC)' 현상을 방지하기 위한 안전장치입니다 [2]. `<head>` 태그 내에 존재하는 렌더링 차단 리소스는 사실상 페이지 전체의 렌더링을 차단합니다 [9].
|
||||
- **파서 차단(Parser-blocking)과 JavaScript**: JavaScript는 기본적으로 파서를 차단하는 리소스입니다 [5]. 스크립트 실행 과정에서 DOM이나 CSSOM이 어떻게 변경될지 알 수 없으므로, 브라우저는 실행이 완료될 때까지 HTML 파싱을 중단합니다 [5, 10]. 파싱이 막히면 브라우저는 그 이후의 콘텐츠에 접근해 렌더링할 수 없기 때문에, 파서 차단 리소스는 결과적으로 렌더링도 차단하게 됩니다 [11].
|
||||
- **차단 우회 및 최적화 방법**:
|
||||
- CSS의 경우 `<link>` 요소에 `media="print"`와 같이 현재 뷰포트 조건과 일치하지 않는 미디어 속성을 지정하면 렌더링을 차단하지 않도록 만들 수 있습니다 [12].
|
||||
- JavaScript의 경우 `<script>` 태그에 `async` 또는 `defer` 속성을 추가하여 파서와 렌더링이 막히는 것을 방지할 수 있습니다 [5, 13].
|
||||
- 중요하지 않은 리소스의 다운로드를 지연시키고, CSS 선택자 특이성을 최적화하거나 축소(minifying)하여 전체 차단 시간을 줄여야 합니다 [6, 14].
|
||||
- 최신 기술로는 Chrome 105부터 도입된 `blocking=render` 속성을 통해 파서는 계속 진행하도록 두면서 명시적으로 렌더링만 차단하게 설정할 수도 있습니다 [5].
|
||||
- **측정 및 식별**: WebPageTest, Lighthouse 등과 같은 성능 감사 도구는 렌더링 차단 리소스를 식별하는 기능을 제공합니다. 이를 통해 어떤 리소스가 실제 페이지 렌더링을 지연시키고 있는지 찾아내어 최적화의 단서로 삼을 수 있습니다 [15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[핵심 렌더링 경로(Critical rendering path)]], [[CSSOM(CSS Object Model)]], [[파서 차단 리소스(Parser-blocking resources)]], [[FOUC(Flash of Unstyled Content)]]
|
||||
- **Projects/Contexts:** [[웹 성능 최적화(Web Performance Optimization)]], [[Lighthouse 성능 감사]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 CSS가 렌더링을 차단한다고 해서 브라우저의 모든 작업이 중지되는 것은 아닙니다. 브라우저는 CSS를 다운로드하고 렌더링을 일시 정지한 상태에서도 나머지 HTML을 계속 처리하며 할 수 있는 다른 작업(예: 리소스 탐색 등)을 수행하여 효율성을 높입니다 [12]. 또한, 과거에는 렌더링 차단 리소스가 페이지 전체 렌더링을 막았으나 최근 브라우저(Firefox, Chrome)는 렌더링 차단 리소스 아래에 있는 콘텐츠의 렌더링만 차단하도록 동작 방식이 개선되었습니다 [9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
# [[메인 스레드 차단 문제 해결을 위한 React 16의 Fiber 엔진 교체 및 React 18, 19의 동시성 렌더링 적용 사례]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
React 16 이전의 동기적 렌더링 방식은 렌더링 작업이 길어질 경우 메인 스레드를 차단하여 UI 응답성을 떨어뜨리는 한계가 있었습니다. 이를 해결하기 위해 React 16은 렌더링 작업을 잘게 쪼개고 우선순위에 따라 작업을 중단, 재개할 수 있는 Fiber 아키텍처를 도입했습니다. 이를 기반으로 React 18에서는 자동 일괄 처리(Automatic Batching)와 `useTransition` 등을 활용한 동시성 렌더링 기능을 제공하였고, React 19에 이르러서는 React Compiler를 통한 자동 메모이제이션과 서버 컴포넌트(RSC)를 도입해 메인 스레드의 부하를 극적으로 줄이며 최적화를 자동화했습니다.
|
||||
|
||||
## 📖 Core Content
|
||||
**메인 스레드 차단 문제와 한계**
|
||||
React 16 이전의 React는 컴포넌트 트리를 단일 재귀 호출로 동기적으로 처리하는 '스택 재조정자(Stack Reconciler)'를 사용했습니다 [1]. 대규모 애플리케이션의 경우, 이 과정이 16.6ms의 프레임 예산을 초과하면 메인 스레드를 차단하여 사용자 입력 및 애니메이션에 대한 애플리케이션의 응답성이 지연되는 문제가 발생했습니다 [1].
|
||||
|
||||
**React 16의 Fiber 엔진 도입**
|
||||
* **작업 분할 및 타임 슬라이싱 (Time-Slicing):** 동기적 차단 문제를 해결하기 위해 React 16은 동시성 렌더링을 지원하도록 재조정(Reconciliation) 엔진을 완전히 재작성한 'Fiber' 아키텍처를 도입했습니다 [2]. Fiber는 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위(Unit of work)로 분할합니다 [1, 3].
|
||||
* **중단 및 재개 가능한 렌더링:** 작업 루프(Work loop) 내에서 React는 각 작업을 처리한 후 우선순위가 높은 작업(예: 사용자 입력)을 위해 브라우저에 제어권을 양보(Yield)할 수 있습니다 [4]. 렌더링 단계(Render phase)는 중단 및 재개가 가능하며, 실제 DOM에 변경 사항을 적용하는 커밋 단계(Commit phase)는 동기적으로 실행됩니다 [5, 6].
|
||||
* **우선순위 레인(Lanes):** 타이핑 및 클릭과 같은 긴급한 상호작용은 '동기(Sync) 레인'에 할당하고, 데이터 페칭은 '기본(Default) 레인'에 할당하는 방식으로 우선순위 기반 시스템을 운용하여 UI의 반응성을 향상시켰습니다 [7-9].
|
||||
|
||||
**React 18의 동시성 렌더링 적용 사례**
|
||||
* **긴급하지 않은 렌더링 지연:** React 18은 `useTransition` 및 `useDeferredValue` 훅을 통해 동시성 렌더링을 본격적으로 활용합니다 [10]. 긴급한 상호작용(예: 검색어 입력)을 먼저 처리하고, 무거운 연산(예: 수천 개의 목록 필터링)을 `startTransition`으로 감싸 지연시킴으로써 메인 스레드의 차단을 방지합니다 [10-12].
|
||||
* **자동 일괄 처리 (Automatic Batching):** 이벤트 핸들러 내부뿐만 아니라 Promise, setTimeout, 기본 이벤트 등 비동기 작업에서 발생하는 여러 상태 업데이트를 단일 리렌더링으로 묶어 처리합니다 [13-15]. 이는 Virtual DOM의 Diffing 오버헤드를 줄여 데이터 집약적인 대시보드 환경에서 프레임 속도를 최대 25% 향상시키는 성과를 보였습니다 [12, 13, 16].
|
||||
|
||||
**React 19의 성능 자동화 및 메인 스레드 부하 감소 사례**
|
||||
* **React Compiler를 통한 자동 메모이제이션:** React 19는 수동으로 작성하던 `useMemo`나 `useCallback`의 인지적 부담을 덜기 위해, 빌드 시점에 AST(추상 구문 트리)를 분석하여 최적의 메모이제이션 경계를 자동으로 삽입하는 React Compiler를 도입했습니다 [17-19]. 이는 미세 조정된 반응성(Fine-Grained Reactivity)을 구현하여 불필요한 연쇄 리렌더링(Re-render cascade)을 획기적으로 방지합니다 [17, 20]. Meta의 내부 테스트에서는 상호작용 속도(INP)가 최대 2.5배 빨라졌습니다 [21].
|
||||
* **React Server Components (RSC):** 번들 크기와 하이드레이션(Hydration) 비용을 근본적으로 제거하기 위해, 상호작용이 없는 컴포넌트를 서버에서만 실행하는 방식을 도입했습니다 [22-24]. 이 방식을 통해 브라우저로 전송되는 JavaScript를 0바이트로 줄여 메인 스레드가 파싱하고 실행해야 할 부담을 최소화했습니다 [22, 24, 25].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Virtual DOM]], [[Reconciliation]], [[Fiber Architecture]], [[Automatic Batching]], [[React Compiler]], [[React Server Components]], [[Time-Slicing]], [[Lane-Based Priority]]
|
||||
- **Projects/Contexts:** [[Next.js App Router]], [[Meta's Internal Testing (Quest Store)]], [[Sanity Studio]]
|
||||
- **Contradictions/Notes:** 컴포넌트의 렌더링 최적화와 관련해 React Compiler의 도입은 개발자가 `useMemo`나 `useCallback`을 사용하여 수동으로 최적화하던 기존 방식의 패러다임을 바꿉니다 [26]. 대부분의 자동 메모이제이션은 컴파일러가 처리하지만, `useEffect`의 의존성 관리나 타사 라이브러리 연동 등 세밀한 제어가 필요한 경우에는 여전히 수동 메모이제이션 방식이 "탈출구(Escape Hatch)"로 유효하다고 소스에서 지적하고 있습니다 [27-29].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,20 @@
|
||||
# [[브라우저 렌더링 과정 (Critical Rendering Path)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
브라우저 렌더링 과정(Critical Rendering Path)은 브라우저가 수신한 HTML, CSS, JavaScript 코드를 화면의 실제 픽셀로 변환하기 위해 거치는 일련의 순차적인 단계를 의미합니다 [1, 2]. 이 과정은 DOM과 CSSOM의 생성, 렌더 트리(Render Tree) 구축, 기하학적 형태를 계산하는 레이아웃(Layout), 그리고 픽셀을 그리는 페인트(Paint) 및 합성(Composite) 단계로 이루어집니다 [3, 4]. 렌더링 경로를 최적화하여 렌더링 차단 요소를 최소화하는 것은 웹 페이지의 초기 렌더링 속도를 높이고 사용자 경험(UX)을 향상시키는 프론트엔드 성능 최적화의 핵심입니다 [1, 5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
* **DOM (Document Object Model) 구축:** 브라우저가 HTML 데이터를 받으면 바이트를 문자, 토큰, 노드로 변환한 뒤 이를 기반으로 DOM 트리를 구축합니다 [1, 7]. 이 과정은 점진적(incremental)으로 이루어지기 때문에 브라우저는 네트워크 요청이 진행 중인 상태에서도 트리 구성을 시작할 수 있습니다 [1, 8]. 생성된 노드의 수가 많을수록 이후의 레이아웃과 페인트 단계에서 더 많은 시간이 소요됩니다 [1, 9].
|
||||
* **CSSOM (CSS Object Model) 구축:** DOM과 달리 CSSOM 구성은 점진적이지 않으며 렌더링을 차단(Render-blocking)합니다 [8, 9]. 브라우저는 사용자가 스타일이 적용되지 않은 날것의 콘텐츠(FOUC)를 보는 것을 방지하기 위해, 연결된 모든 스타일시트를 다운로드하고 파싱할 때까지 렌더링을 중단합니다 [8, 9].
|
||||
* **렌더 트리(Render Tree) 합성:** DOM과 CSSOM이 모두 준비되면 브라우저는 두 트리를 결합하여 화면에 렌더링되는 노드만 포함하는 렌더 트리를 생성합니다 [10, 11]. 이 과정에서 시각적 레이아웃에 영향을 주지 않는 `<script>`, `<meta>` 태그나 `display: none` 속성이 적용된 요소는 렌더 트리에서 완전히 제외됩니다 [10, 11]. 단, `visibility: hidden`이 적용된 요소는 눈에 보이지는 않지만 레이아웃 상에서 공간을 차지하므로 렌더 트리에 포함됩니다 [12, 13].
|
||||
* **Layout(레이아웃) / Reflow(리플로우):** 렌더 트리가 완성되면 브라우저는 뷰포트(Viewport)의 크기와 박스 모델을 기반으로 렌더 트리 내 각 요소의 정확한 크기와 화면상 위치를 계산합니다 [14-16]. 창 크기 조절, DOM 요소의 추가 및 제거, 크기 속성 변경 등의 작업은 전체 혹은 부분적인 레이아웃의 재계산(Reflow)을 유발하며 이는 컴퓨팅 비용이 매우 높은 작업입니다 [17, 18].
|
||||
* **Paint(페인트) 및 Compositing(합성):** 레이아웃 단계가 끝나면 브라우저는 계산된 기하학적 형태와 스타일을 바탕으로 화면에 실제 픽셀을 그리는 Paint 작업을 수행합니다 [19-21]. 요소의 색상이나 배경 등 시각적 스타일만 변경될 경우 레이아웃 계산을 생략하고 Repaint(리페인트)만 발생합니다 [18]. 페인트 이후 브라우저는 성능을 높이기 위해 요소들을 여러 레이어로 분리하여 그린 뒤, GPU 등을 활용해 이를 단일 이미지로 합치는 Compositing(합성) 과정을 거칩니다 [19, 22, 23].
|
||||
* **크리티컬 렌더링 패스 최적화:** 브라우저는 `<head>` 태그 내부에 있는 렌더링 차단 CSS 및 파서 차단(Parser-blocking) 동기식 JavaScript가 모두 처리될 때까지 화면을 렌더링하지 않습니다 [24-26]. 반면 이미지, 폰트, 그리고 지연 로드(async/defer) 설정이 된 스크립트 등은 초기 렌더링을 차단하지 않습니다 [27]. 따라서 불필요한 리소스의 다운로드를 지연시키거나 파일 크기를 최적화하는 것이 렌더링 경로 최적화의 기본 원칙입니다 [28, 29].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DOM]], [[CSSOM]], [[Render Tree]], [[Reflow 및 Repaint]]
|
||||
- **Projects/Contexts:** [[프론트엔드 렌더링 성능 최적화]], [[Core Web Vitals 최적화 (FCP, LCP 등)]]
|
||||
- **Contradictions/Notes:** 제공된 소스들은 브라우저 렌더링 과정에 대해 모순 없이 일관된 설명을 제공합니다. 특히 `display: none`(렌더 트리에서 제외됨)과 `visibility: hidden`(레이아웃 공간을 차지하므로 렌더 트리에 포함됨)의 처리 방식 차이를 명확히 대조하여 설명하고 있습니다 [13].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,26 @@
|
||||
# [[브라우저 렌더링 파이프라인(Critical Rendering Path)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
브라우저 렌더링 파이프라인(Critical Rendering Path, CRP)은 브라우저가 HTML, CSS, JavaScript 코드를 수신하여 화면의 픽셀로 변환하기 위해 거치는 일련의 핵심 단계입니다 [1, 2]. 이 파이프라인은 주로 DOM 및 CSSOM 생성, 렌더 트리 구축, 레이아웃, 페인트, 그리고 합성 단계로 이루어집니다 [3]. 이 경로를 최적화하는 것은 초기 렌더링 속도(Time to first render)를 높이고 60FPS의 부드러운 사용자 상호작용을 보장하기 위한 웹 성능 최적화의 핵심입니다 [4, 5].
|
||||
|
||||
## 📖 Core Content
|
||||
브라우저 렌더링 파이프라인은 다음과 같은 세부적인 과정을 거쳐 실행됩니다.
|
||||
|
||||
* **DOM(Document Object Model) 구축**
|
||||
브라우저가 서버로부터 HTML 데이터를 받으면, 이를 바이트 단위에서 문자, 토큰, 노드로 변환하여 점진적(incremental)으로 DOM 트리를 구성합니다 [1, 6]. 파싱 중 비차단(non-blocking) 리소스를 만나면 요청을 보내고 파싱을 계속하며, 프리로드 스캐너(Preload Scanner)가 백그라운드에서 CSS, 웹 폰트 등 우선순위가 높은 리소스를 미리 요청하여 병목을 줄입니다 [7].
|
||||
* **CSSOM(CSS Object Model) 구축**
|
||||
HTML과 별개로 브라우저는 CSS를 파싱하여 스타일 규칙과 계층 구조를 나타내는 CSSOM 트리를 생성합니다 [8, 9]. DOM 생성과 달리 CSSOM은 **렌더링을 차단(Render-blocking)**하는 속성을 지닙니다. 즉, 브라우저는 모든 CSS를 다운로드하고 파싱을 완료할 때까지 페이지 렌더링을 중단하여, 스타일이 입혀지지 않은 콘텐츠가 화면에 번쩍이는 현상(FOUC)을 방지합니다 [8, 10].
|
||||
* **렌더 트리(Render Tree) 생성**
|
||||
DOM과 CSSOM이 준비되면, 두 트리를 결합하여 **화면에 실제로 표시되는 노드들만 포함된 렌더 트리**를 구축합니다 [11, 12]. `<script>`, `<meta>` 같은 태그나 CSS의 `display: none`이 적용된 요소는 렌더 트리에서 완전히 제외되지만, 화면에 공간을 차지하는 `visibility: hidden`이 적용된 요소는 포함됩니다 [11-13].
|
||||
* **레이아웃(Layout) 또는 리플로우(Reflow)**
|
||||
렌더 트리가 완성되면, 브라우저는 뷰포트의 크기를 기준으로 각 요소가 화면의 어느 위치에, 어느 정도의 크기(기하학적 형태)로 배치될지 정확히 계산합니다 [14-16]. 창 크기가 조절되거나 JavaScript로 DOM 요소의 크기 및 위치를 조작할 때마다 이 계산이 다시 발생하며(**리플로우**), 이는 브라우저에 큰 계산 부담을 줍니다 [17-19].
|
||||
* **페인트(Paint)와 합성(Compositing)**
|
||||
레이아웃 계산이 끝나면 요소에 색상, 텍스트, 그림자, 테두리 등 시각적 속성을 적용하여 화면의 실제 픽셀로 변환하는 페인트(또는 리페인트) 단계가 진행됩니다 [17, 20]. 마지막으로, 성능 최적화를 위해 일부 요소(예: `<video>`, `<canvas>`, 특정 CSS 속성 적용 요소)가 별도의 레이어로 나뉘어 그려졌다면, 브라우저가 이들을 올바른 순서로 겹쳐서 최종 화면을 완성하는 **합성(Compositing)** 단계를 거칩니다 [21, 22]. GPU를 활용해 이 과정을 가속화할 수도 있습니다 [23, 24].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DOM(Document Object Model)]], [[CSSOM(CSS Object Model)]], [[리플로우와 리페인트(Reflow and Repaint)]], [[가상 DOM(Virtual DOM)]], [[웹 성능 최적화(Web Performance Optimization)]]
|
||||
- **Projects/Contexts:** [[최초 렌더링 시간(Time to First Render) 단축]], [[단일 페이지 애플리케이션(SPA)의 CSR 및 SSR 전략]]
|
||||
- **Contradictions/Notes:** 동기식 JavaScript는 기본적으로 파서를 차단(Parser-blocking)하여 결과적으로 렌더링 파이프라인 전체를 지연시키므로, `async`나 `defer` 속성을 활용해 렌더링 경로를 방해하지 않도록 처리하는 것이 공통적인 모범 사례로 권장됩니다 [7, 25, 26].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,25 @@
|
||||
# [[웹 성능 최적화(Web Performance Optimization)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
웹 성능 최적화는 웹 페이지가 빠르게 로드되고, 원활하게 렌더링되며, 사용자의 상호작용에 즉각적으로 반응하도록 보장하기 위한 기술과 전략을 의미한다 [1-3]. 이는 중요 렌더링 경로(Critical Rendering Path)를 관리하여 리플로우(Reflow)와 리페인트(Repaint)를 최소화하고, 브라우저가 화면을 그리는 속도와 효율성을 극대화하는 과정을 포함한다 [4-7]. 현대의 프론트엔드 환경에서는 적절한 렌더링 전략(CSR, SSR, SSG 등)의 선택, 자바스크립트 번들 크기 축소, 그리고 컴포넌트 아키텍처를 통한 렌더링 횟수 통제가 핵심적인 최적화 목표로 다루어진다 [8-11].
|
||||
|
||||
## 📖 Core Content
|
||||
* **중요 렌더링 경로(Critical Rendering Path, CRP) 최적화:** 브라우저는 네트워크를 통해 전달받은 HTML과 CSS를 파싱하여 DOM과 CSSOM 트리를 생성하고, 이를 결합해 렌더 트리(Render Tree)를 구축한 뒤, 요소의 위치와 크기를 계산(Layout)하고 화면의 픽셀로 변환(Paint)하는 단계를 거친다 [5, 12-14]. 초기 렌더링 시간을 줄이려면 렌더링을 차단하는 CSS나 파싱을 차단하는 자바스크립트(Render-blocking & Parser-blocking resources)의 수를 최소화하고 다운로드 순서를 최적화해야 한다 [15-18]. 또한 DOM 트리의 노드가 많아질수록 레이아웃과 페인트 단계의 연산 비용이 증가하므로 불필요한 DOM 노드 깊이를 줄여야 한다 [19-21].
|
||||
|
||||
* **리플로우(Reflow) 및 리페인트(Repaint) 최소화:** DOM 구조의 변경, 창 크기 조절, 요소의 크기 및 위치 변경 등은 브라우저가 기하학적 구조를 다시 계산하게 만드는 비용이 큰 리플로우(또는 레이아웃)를 유발한다 [22-25]. 시각적 스타일(색상, 그림자 등)만 변경되는 리페인트의 경우 리플로우보다는 연산량이 적지만 과도하게 발생하면 애니메이션 프레임 속도를 저하시킨다 [7, 26, 27]. 성능을 유지하기 위해서는 DOM 업데이트를 일괄 처리하고, 요소 이동 시 위치 관련 속성 대신 GPU 가속을 활용할 수 있는 `transform` 속성을 사용하는 것이 좋다 [7, 26, 28-30].
|
||||
|
||||
* **React 애플리케이션의 렌더링 최적화 기법:** React의 렌더링 특성상 부모의 상태가 변경되면 속성 변경 여부와 관계없이 하위 컴포넌트가 연쇄적으로 리렌더링되며 연산 비용을 낭비할 수 있다 [31, 32]. 이를 방지하기 위해 `React.memo`나 `useMemo` 등을 통한 메모이제이션, 대규모 목록에서 화면에 보이는 노드만 그리는 가상화(Virtualization), 그리고 상태 업데이트를 하나로 묶는 자동 일괄 처리(Automatic Batching)가 사용된다 [33-36]. 아울러 React 19의 동시성 렌더링 훅(`useTransition`, `useDeferredValue`)을 활용하면 무거운 연산 중에도 긴급한 상호작용의 응답성을 방해하지 않고 유지할 수 있다 [37-39].
|
||||
|
||||
* **렌더링 전략 선택 및 하이드레이션(Hydration) 병목 관리:** 애플리케이션의 성격과 요구에 따라 클라이언트 사이드 렌더링(CSR), 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 점진적 정적 재생성(ISR) 등의 방식을 전략적으로 선택해야 한다 [9, 40-42]. SSR과 SSG는 서버에서 미리 완성된 HTML을 전달하여 빠른 초기 콘텐츠 표시(FCP)와 우수한 SEO를 보장하지만, SSR의 경우 브라우저가 자바스크립트를 다운로드하고 HTML에 이벤트 핸들러를 연결하는 '하이드레이션(Hydration)' 과정이 끝날 때까지 상호작용(TTI)이 지연되거나 메인 스레드를 차단(TBT)하는 단점이 있다 [43-47].
|
||||
|
||||
* **React Server Components (RSC)의 도입과 자동화 도구:** 기존 렌더링 방식의 번들 크기 및 하이드레이션 문제를 근본적으로 해결하기 위해 컴포넌트를 서버에서만 실행하고 클라이언트에는 자바스크립트를 전송하지 않는 RSC 모델이 도입되었다 [48-51]. 이를 통해 클라이언트로 전송되는 JS 페이로드 크기를 대폭 줄이고 서버의 리소스를 직접 활용할 수 있다 [52-54]. 더 나아가 최신 React Compiler는 빌드 타임에 코드의 추상 구문 트리(AST)를 분석해 자동으로 세분화된 메모이제이션을 삽입해주어, 개발자가 수동으로 성능을 최적화해야 하는 부담을 대폭 감소시킨다 [55-58].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[Critical Rendering Path]]`, `[[Reflow and Repaint]]`, `[[React Server Components]]`, `[[하이드레이션(Hydration)]]`, `[[동시성 렌더링(Concurrent Rendering)]]`, `[[React Compiler]]`
|
||||
- **Projects/Contexts:** `[[콘텐츠 기반의 SEO 최적화 웹사이트 및 이커머스(E-commerce) 플랫폼]]` (초기 화면의 빠른 렌더링과 검색엔진 최적화를 위해 SSR, SSG, ISR이 필수적으로 요구되는 맥락) [43, 59-62], `[[고도의 상호작용이 필요한 관리자 대시보드 및 SaaS]]` (초기 렌더링보다 실시간 상태 업데이트와 인터랙션 속도가 중시되어 CSR 또는 선택적 클라이언트 컴포넌트가 적합한 맥락) [63-67].
|
||||
- **Contradictions/Notes:**
|
||||
- **수동 메모이제이션의 유용성에 대한 관점 변화:** 기존 React 생태계에서는 불필요한 리렌더링을 막기 위해 `useMemo`나 `useCallback`과 같은 수동 메모이제이션이 권장되었으나, 얕은 비교 검사 자체의 오버헤드가 발생하거나 종속성 관리가 복잡해져 과도한 사용이 안티 패턴으로 지적되기도 했다 [68, 69]. 그러나 React 19의 React Compiler 등장 이후, 컴파일러가 정적 분석을 통해 최적의 위치에 자동으로 메모이제이션을 적용하게 되면서 개발자의 수동 개입 필요성이 크게 사라지는 패러다임 전환이 이루어지고 있다 [55, 58, 70-72].
|
||||
- **SSR의 성능 지표 딜레마:** 서버 사이드 렌더링(SSR)은 클라이언트에게 완성된 HTML을 즉시 제공하여 초기 콘텐츠 표시(FCP)와 SEO를 개선하지만, 자바스크립트를 다운로드하여 정적 요소에 상호작용을 활성화하는 하이드레이션 과정이 완료될 때까지 상호작용 시작 시간(TTI)이 크게 지연되거나 메인 스레드 차단 시간(TBT)이 증가하는 역설적인 한계가 존재한다 [43, 45, 73-75].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,26 @@
|
||||
# [[크리티컬 렌더링 패스 (Critical Rendering Path)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
크리티컬 렌더링 패스(Critical Rendering Path, CRP)는 브라우저가 HTML, CSS, JavaScript 코드를 수신하여 화면의 픽셀로 변환하기 위해 거치는 일련의 단계를 의미합니다 [1, 2]. 브라우저는 DOM과 CSSOM을 생성하고, 이를 결합하여 렌더 트리를 구축한 뒤, 요소의 크기와 위치를 계산하는 레이아웃(Layout) 단계와 화면에 그리는 페인트(Paint) 단계를 수행합니다 [2, 3]. 이 경로를 최적화하는 것은 초기 렌더링 시간(Time to First Render)을 단축하고 사용자 상호작용의 유창함을 보장하기 위한 프론트엔드 성능 엔지니어링의 핵심 목표입니다 [1, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
**주요 진행 단계 (Sequential Progression of Steps)**
|
||||
* **DOM 트리 생성 (DOM Construction)**: 브라우저가 HTML 바이트를 파싱하여 점진적(incremental)으로 DOM 트리를 구축합니다 [5, 6]. 노드의 수가 많을수록 이후 단계에서 소요되는 시간이 길어집니다 [1, 7].
|
||||
* **CSSOM 트리 생성 (CSSOM Construction)**: CSS 규칙을 파싱하여 스타일 정보를 담은 CSSOM 트리를 생성합니다 [7, 8]. DOM과 달리 CSSOM 생성은 점진적이지 않으며, 브라우저는 모든 CSS를 처리할 때까지 페이지 렌더링을 차단(Render-blocking)합니다 [7, 9].
|
||||
* **렌더 트리 합성 (Render Tree Synthesis)**: DOM과 CSSOM이 준비되면, 시각적으로 화면에 표시되어야 하는 노드와 그에 해당하는 계산된 스타일만 포함하는 렌더 트리를 구축합니다. `<script>` 요소나 `display: none` 스타일이 적용된 노드 등 화면에 보이지 않는 요소는 제외됩니다 [10-12].
|
||||
* **레이아웃 (Layout / Reflow)**: 렌더 트리를 기반으로 기기의 뷰포트 크기를 고려하여 각 요소의 정확한 기하학적 형태(크기와 화면상 위치)를 계산합니다 [13-16].
|
||||
* **페인트 및 합성 (Paint and Composite)**: 계산된 기하학적 형태와 스타일을 실제 픽셀로 변환(Paint)하여 화면에 그리고, 여러 레이어로 분리된 요소를 올바른 순서로 화면에 결합(Composite)합니다 [17-20].
|
||||
|
||||
**성능 최적화 및 렌더링 차단 요소 (Performance Optimization and Blocking Resources)**
|
||||
* 초기 렌더링을 위해서는 HTML 일부와 `<head>` 태그 내에 있는 렌더링 차단 CSS 및 JavaScript 처리가 선행되어야 합니다 [21-23].
|
||||
* 브라우저의 파서(Parser)는 동기식 JavaScript를 만나면 DOM을 변경할 수 있기 때문에 HTML 파싱을 중단하며, 이는 렌더링 차단으로 이어져 큰 성능 비용을 발생시킵니다 [23, 24].
|
||||
* CRP 최적화를 위해서는 이러한 렌더링 차단 리소스의 영향을 최소화하여 중요한 리소스의 로드 순서를 제어하고 다운로드해야 할 크기를 줄이는 것이 필수적입니다 [25, 26].
|
||||
* 이미지나 폰트는 일반적으로 초기 렌더링을 지연시키는 차단 리소스로 취급되지 않지만 [27], 요소의 치수를 미리 제공하지 않으면 이미지가 로드된 후 레이아웃이 다시 계산되는 리플로우(Reflow) 현상이 발생하여 성능이 저하될 수 있습니다 [19, 20, 27].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[DOM (Document Object Model)]], [[CSSOM (CSS Object Model)]], [[렌더 트리 (Render Tree)]], [[리플로우 (Reflow)]], [[리페인트 (Repaint)]]
|
||||
- **Projects/Contexts:** 프론트엔드 성능 최적화(Frontend Performance Optimization) 작업이나 Lighthouse, Chrome DevTools, WebPageTest와 같은 성능 감사 도구를 통해 렌더링 병목 현상을 파악하고 해결하는 맥락에서 빈번하게 다뤄집니다 [28-30].
|
||||
- **Contradictions/Notes:** 전통적으로 크리티컬 렌더링 패스는 '최초 렌더링(First Paint)'을 위해 필요한 최소한의 과정을 의미하지만, 최근의 웹 성능 측정은 첫 페인트를 넘어 실제 유의미한 콘텐츠가 사용자에게 보여지는 시점인 LCP(Largest Contentful Paint) 등을 포괄하는 '크리티컬 콘텐츠 렌더링 패스(Critical Contentful Rendering Path)'에 집중해야 한다는 관점도 대두되고 있습니다 [26, 31].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,41 @@
|
||||
# [[프론트엔드 렌더링 최적화(Rendering Optimization)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 렌더링 최적화는 브라우저가 HTML, CSS, JavaScript를 화면의 픽셀로 변환하는 과정인 중요 렌더링 경로(Critical Rendering Path)를 효율화하여 애플리케이션의 응답성과 화면 표시 속도를 향상시키는 작업입니다 [1-3]. DOM 조작 시 발생하는 비용이 큰 리플로우(Reflow)와 리페인트(Repaint) 연산을 최소화하는 것이 핵심이며, React와 같은 프레임워크에서는 가상 DOM(Virtual DOM)과 파이버(Fiber) 아키텍처를 통해 이를 추상화 및 최적화합니다 [4-6]. 또한, 서비스의 특성에 따라 CSR, SSR, SSG 등의 렌더링 전략을 선택하고 하이드레이션(Hydration) 및 번들 크기를 관리함으로써 사용자 경험(Core Web Vitals)을 극대화하는 데 그 목적이 있습니다 [7-9].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
**1. 브라우저 렌더링 과정 (Critical Rendering Path)**
|
||||
브라우저는 서버로부터 HTML을 수신하면 점진적으로 문서를 파싱하여 DOM(Document Object Model) 트리를 생성하고, CSS를 파싱하여 렌더링 차단 리소스인 CSSOM(CSS Object Model) 트리를 구성합니다 [10-13]. DOM과 CSSOM이 준비되면 화면에 표시될 노드들만 포함하는 렌더 트리(Render Tree)를 합성합니다 [14, 15]. 이후 요소들의 정확한 위치와 크기를 계산하는 레이아웃(Layout 또는 Reflow) 단계를 거쳐, 픽셀을 화면에 그리는 페인트(Paint 또는 Repaint) 및 레이어들을 합성하는 컴포지팅(Compositing) 단계로 화면을 출력합니다 [16-19].
|
||||
|
||||
**2. 리플로우(Reflow)와 리페인트(Repaint) 최소화**
|
||||
* **리플로우 (Layout):** 창 크기 변경, 요소의 추가/제거, 크기나 여백(width, height, margin 등)의 변경은 DOM 트리의 위치나 크기 계산을 다시 하게 만드는 리플로우를 유발하며 이는 계산 비용이 매우 큽니다 [4, 6, 20].
|
||||
* **리페인트 (Paint):** 배경색이나 그림자 등 시각적 속성만 변경될 때 발생하며, 리플로우보다 비용이 적지만 과도하면 프레임 드롭(Jank)을 유발합니다 [17, 20, 21].
|
||||
* **최적화 전략:** 불필요한 DOM 깊이를 줄이고, 복잡한 CSS 선택자를 피해야 합니다 [22, 23]. 또한 화면을 강제로 재계산하게 하는 동기적 DOM 읽기/쓰기 작업을 분리하여 레이아웃 스래싱(Layout Thrashing)을 방지하고, 애니메이션 구현 시 `transform`과 `opacity`를 활용하여 GPU 가속(Compositing)을 사용하는 것이 유리합니다 [4, 17, 21, 24].
|
||||
|
||||
**3. 가상 DOM(Virtual DOM)과 재조정(Reconciliation)**
|
||||
React는 실제 DOM 조작의 비효율성을 피하기 위해 가상 DOM이라는 경량화된 메모리 내 UI 표현을 사용합니다 [5, 25]. 렌더링 시 이전 가상 DOM과 새로운 가상 DOM을 비교(Diffing)하여 변경된 부분만 실제 DOM에 반영합니다 [5, 25]. 이론상 트리를 비교하는 알고리즘은 O(n^3)의 복잡도를 가지지만, React는 요소 타입이 다르면 하위 트리를 완전히 새로 구축하고 리스트 요소의 경우 고유한 `key` 속성을 통해 식별하는 O(n)의 휴리스틱 알고리즘을 사용해 성능을 최적화합니다 [26, 27].
|
||||
|
||||
**4. React Fiber와 동시성 렌더링 (Concurrent Rendering)**
|
||||
React 16부터 도입된 파이버(Fiber) 아키텍처는 동기식으로 진행되어 메인 스레드를 블로킹하던 기존 렌더링 방식을 개선했습니다 [28-30]. 렌더링 작업을 잘게 쪼개어 중단, 일시 정지, 재개가 가능하게 만들었으며(Time-slicing) [29, 31], 우선순위 레인(Lanes) 시스템을 통해 사용자 입력 같은 긴급한 작업과 데이터 가져오기와 같은 비긴급 작업을 구분하여 동시성 렌더링을 처리합니다 [32-34].
|
||||
|
||||
**5. 렌더링 전략: CSR, SSR, SSG, ISR**
|
||||
웹의 렌더링 방식은 언제 어디서 HTML을 생성하느냐에 따라 나뉘며 각각의 트레이드오프가 존재합니다.
|
||||
* **CSR (Client-Side Rendering):** 브라우저가 자바스크립트를 다운로드하고 실행해 UI를 그립니다. 상호작용은 빠르고 부드러우나 초기 로딩(FCP)이 느리고 SEO에 불리합니다 [7, 35, 36].
|
||||
* **SSR (Server-Side Rendering):** 서버에서 매 요청마다 HTML을 생성해 보내므로 초기 로딩과 SEO가 우수합니다. 하지만 클라이언트에서 JS를 다운로드하고 이벤트 리스너를 연결하는 하이드레이션(Hydration) 과정이 완료될 때까지 상호작용(TTI)이 지연되는 단점이 있습니다 [37-39].
|
||||
* **SSG (Static Site Generation):** 빌드 시점에 정적 HTML을 생성해 CDN을 통해 배포하므로 로딩 속도가 가장 빠르지만 동적 데이터 업데이트에 취약합니다 [40-42].
|
||||
* **ISR (Incremental Static Regeneration):** 정적 페이지를 캐싱해 빠르게 제공하면서, 백그라운드에서 점진적으로 HTML을 재생성하여 데이터 최신화를 보완하는 하이브리드 전략입니다 [40, 43].
|
||||
|
||||
**6. React 성능 최적화 기법 (React 18 & 19)**
|
||||
* **컴포넌트 리렌더링 제한 (Memoization):** 부모 컴포넌트의 렌더링이 자식으로 전파되는 계단식 리렌더링(Cascade)을 막기 위해 `React.memo`, `useMemo`, `useCallback`을 사용합니다 [44-46]. 최근 React Compiler(React 19)가 도입되면서 빌드 타임에 AST를 분석하여 정적/반응성 값을 구분하고 최적화 경계를 자동으로 추가함으로써 수동 메모이제이션의 필요성이 크게 줄어들었습니다 [47-49].
|
||||
* **자동 배칭 (Automatic Batching):** React 18부터는 이벤트 핸들러뿐만 아니라 비동기 호출이나 타임아웃 내부의 다수 상태 업데이트도 하나의 리렌더링으로 자동 그룹화하여 DOM 업데이트 횟수를 줄입니다 [50-52].
|
||||
* **React Server Components (RSC):** 서버에서 독점적으로 실행되고 브라우저로 JavaScript 번들을 전송하지 않는 컴포넌트 아키텍처입니다 [53, 54]. 정적 UI와 데이터 접근 로직을 서버에 두고 대규모 JS 번들 로드와 하이드레이션 단계를 생략하여 초기 성능(INP 등)을 크게 개선할 수 있습니다 [53, 55, 56].
|
||||
* **기타 기법:** 화면에 보이지 않는 무거운 컴포넌트나 이미지의 지연 로딩(`React.lazy()`, Lazy Loading), 대규모 리스트의 가상화(Virtualization), 디바운싱(Debouncing) 등이 필수적으로 적용됩니다 [57-60].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Critical Rendering Path]], [[Reflow and Repaint]], [[Virtual DOM]], [[React Fiber Architecture]], [[Hydration]], [[Server-Side Rendering (SSR)]], [[Client-Side Rendering (CSR)]], [[React Compiler]], [[React Server Components (RSC)]]
|
||||
- **Projects/Contexts:** [[Next.js 기반 웹 성능 최적화 프로젝트]], [[대규모 데이터 대시보드 및 이커머스 플랫폼 렌더링 전략 구축]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 CSR은 동적인 상호작용성(Interactive)에 강점이 있으나 초기 로딩 속도와 SEO에 한계가 있는 반면, SSR은 초기 콘텐츠 표시와 SEO에는 유리하지만 하이드레이션(Hydration)이 완료되기 전까지 사용자의 입력이 차단되는(TBT/TTI 지연) 상충 관계(Trade-off)를 갖습니다 [7, 37, 61-64]. 또한 최근 도입된 React Compiler는 자동으로 세분화된 수준(Fine-Grained)의 메모이제이션을 수행하지만, `useLocation`이나 `useMutation` 처럼 렌더링마다 새로운 객체를 반환하여 참조 안정성(Reference Equality)을 깨뜨리는 서드파티 라이브러리를 사용할 경우 자동 최적화가 무력화되어 수동 메모이제이션이 여전히 필요할 수 있습니다 [49, 65-67].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,28 @@
|
||||
# [[프론트엔드 성능 최적화(Frontend Performance Optimization)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 성능 최적화는 브라우저가 코드를 해석하여 화면에 렌더링하는 과정과 웹 애플리케이션의 작동 방식을 개선하여 사용자 경험을 극대화하는 과정입니다. 이는 브라우저의 중요 렌더링 경로(CRP) 최적화부터 불필요한 리플로우(Reflow)와 리페인트(Repaint) 최소화, 그리고 웹 렌더링 전략(CSR, SSR, SSG 등)의 올바른 선택을 아우릅니다. 최근에는 React의 Fiber 아키텍처, 상태 업데이트 자동 배칭, 컴파일러를 통한 자동 메모이제이션, 그리고 React 서버 컴포넌트(RSC) 도입을 통해 클라이언트 측 자바스크립트의 실행 및 번들 크기를 획기적으로 줄이는 방향으로 발전하고 있습니다.
|
||||
|
||||
## 📖 Core 기Content
|
||||
**1. 브라우저 렌더링 과정 (Critical Rendering Path) 및 DOM 최적화**
|
||||
- **렌더 트리 구성:** 브라우저는 HTML을 파싱하여 DOM을 만들고, CSS를 파싱하여 CSSOM을 생성한 후, 화면에 표시될 가시적인 노드들만을 결합하여 렌더 트리(Render Tree)를 구축합니다 [1, 2].
|
||||
- **Reflow와 Repaint 최소화:** 렌더 트리가 변경되면 브라우저는 요소의 정확한 크기와 위치를 다시 계산하는 레이아웃(Reflow) 단계를 거친 후 픽셀을 화면에 그리는 페인트(Repaint) 작업을 수행합니다 [3-9]. Reflow는 연산 비용이 매우 높으므로 불필요한 DOM 깊이를 줄이고, 레이아웃에 영향을 주는 속성 변경을 피해야 합니다 [7, 8, 10-12]. 애니메이션의 경우 `transform` 속성이나 하드웨어(GPU) 가속을 활용해 Reflow를 피하고 컴포지팅(Compositing) 단계에서 처리되도록 최적화해야 합니다 [5, 12-14].
|
||||
- **렌더링 차단 리소스 최적화:** CSS와 동기식 자바스크립트는 초기 파싱 및 렌더링을 차단(Render-blocking)하므로, 자바스크립트에는 `async`나 `defer`를 사용하고 중요한 리소스는 Preload 스캐너를 통해 미리 로드하여 렌더링 지연을 방지해야 합니다 [15-23].
|
||||
|
||||
**2. 프론트엔드 아키텍처 및 React 렌더링 최적화**
|
||||
- **가상 DOM (Virtual DOM) 및 재조정 (Reconciliation):** React는 메모리상에 가상 DOM을 두고 상태 변경 전후를 비교합니다. O(n) 복잡도의 Heuristic Diffing 알고리즘을 사용하며, 요소의 타입이 다르거나 리스트에 `key` 속성이 변경된 경우에만 실제 DOM 노드를 업데이트하여 연산을 최소화합니다 [24-37].
|
||||
- **Fiber 아키텍처:** React 16부터 도입된 Fiber는 렌더링 작업을 잘게 쪼개는 시간 분할(Time-slicing) 기술과 우선순위(Lanes) 시스템을 제공합니다. 클릭이나 타이핑 같은 긴급한 작업을 먼저 처리하고 무거운 렌더링은 중단 및 재개할 수 있어 동시성 렌더링(Concurrent Rendering)과 부드러운 UI 응답성을 달성합니다 [26, 38-51].
|
||||
- **자동 배칭 (Automatic Batching) 및 메모이제이션:** React 18은 Promise나 setTimeout 같은 비동기 환경 내의 상태 업데이트도 하나로 묶어서(Batching) 처리하여 불필요한 리렌더링을 줄입니다 [52-56]. 또한, React Compiler는 빌드 타임에 AST를 분석해 정적 값과 반응형 값을 식별하고 자동으로 메모이제이션 경계를 추가하여 개발자가 수동으로 `useMemo`나 `useCallback`을 작성해야 하는 부담과 오버헤드를 크게 줄여줍니다 [57-65].
|
||||
|
||||
**3. 웹 렌더링 전략 (CSR, SSR, SSG) 및 하이드레이션**
|
||||
- **렌더링 전략의 장단점:** CSR(클라이언트 사이드 렌더링)은 동적 상호작용에 유리하지만 초기 로드가 느리고 SEO에 불리합니다 [66-70]. SSR(서버 사이드 렌더링)은 완성된 HTML을 바로 제공하여 초기 화면 표시(FCP)가 빠르고 SEO에 유리하지만 매 요청마다 서버 부하가 발생합니다 [71-76]. SSG(정적 사이트 생성)는 빌드 타임에 HTML을 미리 생성하여 가장 빠르고 CDN 캐싱이 가능하지만 동적 콘텐츠에는 한계가 있습니다 [77-82].
|
||||
- **하이드레이션 (Hydration) 병목 해결:** SSR 사용 시, 정적인 HTML이 사용자에게 표시된 후 자바스크립트를 다운로드하고 연결하여 상호작용을 활성화하는 하이드레이션 과정이 필수적입니다 [71, 83-85]. 이 과정은 메인 스레드를 차단하여 상호작용 지연 시간(TTI, TBT)을 악화시킬 수 있으므로, 사용자 뷰포트에 따라 렌더링을 지연시키는 선택적 하이드레이션(Selective Hydration)이나 지연 로딩 방식을 통해 최적화할 수 있습니다 [86-93].
|
||||
- **React 서버 컴포넌트 (React Server Components, RSC):** 상호작용이 필요 없는 정적 컴포넌트를 서버에서만 실행하고 결과 HTML과 직렬화된 지침(React Flight 프로토콜)만을 클라이언트에 스트리밍하는 아키텍처입니다. 클라이언트로 전송되는 자바스크립트 번들 크기를 0으로 만들어 하이드레이션 자체를 생략하므로, 성능(INP 등)이 대폭 향상되며 클라이언트와 서버 간의 데이터 폭포(Waterfall) 현상을 서버 수준에서 병렬로 해결할 수 있습니다 [94-109].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[브라우저 렌더링 과정(Critical Rendering Path)]], [[가상 DOM 및 재조정(Virtual DOM and Reconciliation)]], [[React Fiber 아키텍처]], [[하이드레이션(Hydration)]], [[웹 렌더링 전략(CSR, SSR, SSG, ISR)]], [[React 서버 컴포넌트(React Server Components)]], [[React Compiler]]
|
||||
- **Projects/Contexts:** [[Next.js를 활용한 웹 애플리케이션의 하이브리드 렌더링 구축]], [[Core Web Vitals (LCP, INP, CLS) 지표 측정 및 개선]]
|
||||
- **Contradictions/Notes:** 서버 사이드 렌더링(SSR)은 클라이언트 사이드 렌더링(CSR)에 비해 초기 화면 렌더링 속도(FCP)가 빠르고 검색 엔진 최적화(SEO)에 매우 유리하다는 강력한 이점을 지니지만 [71, 110], 자바스크립트를 로드하고 HTML 요소에 이벤트 리스너 등을 부착하는 하이드레이션(Hydration) 과정을 거쳐야 하므로 실제 사용자가 상호작용할 수 있는 시간(TTI)은 CSR의 로드 직후 반응성보다 다소 지연될 수 있다는 트레이드오프가 존재합니다 [71, 84, 111, 112].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
@@ -0,0 +1,29 @@
|
||||
# [[프론트엔드 프레임워크 (React, Angular, Vue)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
프론트엔드 프레임워크는 사용자 인터페이스를 구축하기 위해 컴포넌트 기반 아키텍처(CBA)를 채택하는 모듈형 소프트웨어 도구입니다 [1, 2]. React, Angular, Vue와 같은 프레임워크는 기본적으로 클라이언트 측 렌더링(CSR)을 활용하여 상호작용이 풍부한 웹 애플리케이션을 구축하며, 필요에 따라 서버 측 렌더링(SSR) 및 정적 사이트 생성(SSG)을 혼합하여 성능을 최적화합니다 [3-5]. 제공된 소스에서는 프론트엔드 프레임워크의 아키텍처와 작동 원리가 주로 React를 중심으로 상세히 다뤄지고 있으며, Angular와 Vue의 내부 구조에 대한 구체적인 정보는 부족합니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **컴포넌트 기반 아키텍처 (Component-Based Architecture, CBA)**
|
||||
* 현대 프론트엔드 프레임워크(React, Angular, Vue 등)는 시스템을 작고 독립적이며 재사용 가능한 '컴포넌트'로 나누어 설계하는 방식을 기반으로 합니다 [5-7].
|
||||
* 각 컴포넌트는 자체적인 로직, 상태, UI를 캡슐화하여 제공하므로, 병렬 개발과 독립적인 테스트 및 배포가 가능해져 애플리케이션의 유지보수성과 확장성이 크게 향상됩니다 [1, 8, 9].
|
||||
|
||||
* **웹 렌더링 전략 (Web Rendering Strategies)**
|
||||
* **클라이언트 측 렌더링 (CSR):** React와 Vue는 기본적으로 CSR을 사용하며, 서버에서 빈 HTML 셸을 받은 뒤 브라우저에서 JavaScript를 실행하여 UI를 동적으로 생성합니다 [10]. 이는 상호작용이 부드럽지만 초기 로드 속도 지연과 SEO 약점을 가질 수 있습니다 [11, 12].
|
||||
* **하이브리드 렌더링:** 이러한 한계를 극복하기 위해 Next.js(React 기반), Nuxt.js(Vue 기반) 등의 프레임워크는 서버 측 렌더링(SSR) 및 정적 사이트 생성(SSG)을 혼합 지원하여 빠른 초기 페인팅(FCP)과 강력한 SEO 성능을 제공합니다 [4, 13].
|
||||
|
||||
* **프레임워크 핵심 아키텍처 (React 중심)**
|
||||
* **Virtual DOM 및 재조정 (Reconciliation):** 직접적인 DOM 조작의 성능 저하를 막기 위해, React는 UI를 메모리에 가상 DOM 객체로 유지합니다 [14, 15]. 상태가 변경되면 새로운 트리와 기존 트리를 비교(Diffing)하여 실제 DOM에 변경된 최소한의 부분만 업데이트합니다 [16, 17].
|
||||
* **Fiber 아키텍처:** 렌더링 작업을 동기적으로 한 번에 처리하던 기존 방식과 달리, Fiber는 렌더링을 중단 및 재개할 수 있는 작은 '작업 단위'로 나눕니다 [18, 19]. 이를 통해 사용자 입력과 같은 우선순위가 높은 작업을 먼저 처리하는 동시성 렌더링(Concurrent Rendering)이 가능해집니다 [20-22].
|
||||
* **성능 최적화의 자동화:** React 18은 비동기 작업이나 이벤트 핸들러 내의 여러 상태 업데이트를 묶어 한 번에 렌더링하는 '자동 일괄 처리(Automatic Batching)'를 도입했습니다 [23-25]. 또한, 최근의 React Compiler는 빌드 타임에 코드를 분석하여 불필요한 리렌더링을 막기 위한 메모이제이션을 자동으로 적용합니다 [26-28].
|
||||
* **React Server Components (RSC):** 클라이언트 번들 크기를 줄이기 위해 등장한 개념으로, 컴포넌트가 서버에서만 실행되고 클라이언트에는 직렬화된 UI 정보만 전달되어 JavaScript 번들 크기와 Hydration 과정의 부하를 없앱니다 [29, 30].
|
||||
|
||||
*(소스에 관련 정보가 부족합니다: Angular와 Vue의 구체적인 내부 렌더링 엔진 작동 방식이나 상태 관리 최적화 기법 등 심층적인 프레임워크별 대조 정보는 제공된 소스에 포함되어 있지 않습니다.)*
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** `[[Component-Based Architecture]]`, `[[Client-Side Rendering (CSR)]]`, `[[Server-Side Rendering (SSR)]]`, `[[Virtual DOM]]`, `[[React Fiber]]`
|
||||
- **Projects/Contexts:** `[[Next.js 및 Nuxt.js를 활용한 하이브리드 웹 렌더링 최적화]]`, `[[Reflow 및 Repaint 최소화를 통한 브라우저 렌더링 개선]]`
|
||||
- **Contradictions/Notes:** 제공된 소스 데이터는 프론트엔드 프레임워크의 전반적인 개념(컴포넌트 구조, CSR/SSR)을 다루고 있으나, 기술적 작동 원리와 최적화 아키텍처(Virtual DOM, Fiber, Compiler, 자동 일괄 처리 등)에 대한 설명은 React에 압도적으로 편중되어 있습니다. Angular와 Vue는 개념을 설명하기 위한 예시로만 언급됩니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
Reference in New Issue
Block a user