[G1-Sync] Manual knowledge update

2026-05-10 22:08:15 +09:00
parent 21ac3ed255
commit 504fd5fb42
3011 changed files with 380280 additions and 206977 deletions
@@ -2,179 +2,178 @@
 id: wiki-2026-0508-spa-라우트-전환-성능-최적화
 title: SPA 라우트 전환 성능 최적화
 category: 10_Wiki/Topics
-status: needs_review
+status: verified
 canonical_id: self
-aliases: []
+aliases: [SPA route transition perf, route transition optimization, SPA navigation perf]
 duplicate_of: none
 source_trust_level: A
-confidence_score: 0.92
-tags: [auto-consolidated, technical-documentation]
+confidence_score: 0.9
+verification_status: applied
+tags: [frontend, performance, spa, react, routing]
 raw_sources: []
-last_reinforced: 2026-05-08
+last_reinforced: 2026-05-10
 github_commit: pending
-inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
 tech_stack:
-  language: unspecified
-  framework: unspecified
+  language: typescript
+  framework: react
 ---

-# [[SPA 라우트 전환 성능 최적화|SPA 라우트 전환 성능 최적화]]
+# SPA 라우트 전환 성능 최적화

-## 📌 한 줄 통찰 (The Karpathy Summary)
-> SPA(Single Page Application) 라우트 전환은 현대 프론트엔드 애플리케이션에서 메모리 누수가 발생하는 가장 주요한 원인 중 하나입니다 [1]. 이전 라우트의 컴포넌트가 적절히 정리되지 않으면 애플리케이션의 세션 수명 동안 메모리에 지속적으로 누적되어 성능 저하를 유발합니다 [1]. 따라서 성공적인 라우트 전환 성능 최적화를 위해서는 사용되지 않는 리소스와 참조를 철저히 식별하고 해제하는 메모리 관리가 필수적입니다 [1, 2].
+## 매 한 줄
+> **"매 route 전환은 매 사용자가 매 가장 자주 만나는 perf moment"**. SPA에서 매 route 전환 latency는 매 INP/Core Web Vitals에 매 직접 영향. 2026년에는 매 React Router 7, TanStack Router, Next 15 App Router가 매 표준이며, 매 streaming + prefetch + view-transitions가 매 키.

---
+## 매 핵심

-단일 페이지 애플리케이션(SPA)은 서버에서 라우트마다 완전한 HTML을 받아오는 대신, 클라이언트 사이드 렌더링(CSR)을 활용하여 브라우저 내에서 콘텐츠를 동적으로 생성하는 웹 애플리케이션입니다 [1-3]. 초기 로드 시 필요한 모든 HTML, CSS 및 자바스크립트 파일을 다운로드하며, 그 이후부터는 서버를 통한 전체 페이지 새로고침 없이 사용자의 상호작용을 처리합니다 [4]. 이를 통해 사용자에게 페이지 전환이 즉각적으로 이루어지는 매끄러운 '앱과 같은(app-like)' 경험을 제공합니다 [1, 4].
+### 매 병목 분류
+- **JS bundle**: 매 새 route chunk download/parse.
+- **Data fetch**: 매 loader/query waterfall.
+- **Render**: 매 new tree mount cost.
+- **Asset**: 매 image/font 신규 load.

---
+### 매 최적화 lever
+- **Code-split** (route-level lazy).
+- **Prefetch** (hover/viewport/intent).
+- **Parallel data load** (loader pattern, no waterfall).
+- **View Transitions API** (visual smoothing).
+- **RSC streaming** (Next 15 App Router).

-단일 페이지 애플리케이션(SPA)의 렌더링 설계는 주로 클라이언트 사이드 렌더링(CSR) 방식을 채택하여 브라우저가 자바스크립트를 통해 동적으로 사용자 인터페이스를 생성하도록 하는 아키텍처를 말합니다 [1], [2]. 이 방식은 서버로부터 기본적인 HTML 셸과 자바스크립트를 한 번에 전달받은 후, 클라이언트 환경에서 페이지의 라우팅과 데이터 표시를 처리합니다 [3], [4], [2]. 화면 전체를 새로고침하지 않아 앱처럼 매끄러운 사용자 경험을 제공하지만, 초기 로드 시간과 검색엔진 최적화(SEO) 측면에서는 약점이 있습니다 [3], [5], [6]. 이러한 특성 때문에 SPA 설계에서는 가상 DOM([[Virtual DOM|Virtual DOM]]) 활용, 상태 업데이트 배칭(Batching), 하이드레이션([[Hydration|Hydration]]) 등의 렌더링 성능 최적화 기술이 필수적으로 동반됩니다 [7], [8], [9].
+### 매 응용
+1. 매 e-commerce: product list → detail 매 < 100ms 체감.
+2. 매 dashboard: 매 widget data parallel.
+3. 매 docs site: 매 instant hover prefetch.

---
+## 💻 패턴

-단일 페이지 애플리케이션(SPA)은 서버로부터 최소한의 HTML 껍데기와 [[JavaScript|JavaScript]] 번들을 제공받은 후, 브라우저에서 동적으로 UI를 구성하고 렌더링하는 클라이언트 사이드 렌더링(CSR) 방식을 주로 활용하는 프론트엔드 아키텍처입니다 [1-4]. 초기 다운로드 크기가 커서 로딩이 느릴 수 있지만, 페이지가 로드된 이후에는 전체 페이지 새로고침 없이 부분적인 데이터만 업데이트하여 매끄럽고 상호작용성이 뛰어난 사용자 경험을 제공합니다 [5-8]. 현대의 SPA는 이러한 CSR의 단점을 극복하기 위해 서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 그리고 컴포넌트 기반 아키텍처(CBA)와 같은 전략들을 혼합하여 성능과 확장성을 최적화합니다 [9, 10].
+### 매 Route-level code split
+```tsx
+import { lazy, Suspense } from "react";
+const Dashboard = lazy(() => import("./Dashboard"));

-## 📖 구조화된 지식 (Synthesized Content)
- **라우트 전환과 메모리 누수:** SPA 라우트 전환(SPA route transitions)은 애플리케이션 내 메모리 누수의 1위 출처로 지목됩니다 [1]. 이전 라우트에서 사용되었던 컴포넌트들이 이벤트 리스너(listeners), 타이머(timers), 혹은 전역 상태 참조(global [[State|State]] [[Reference|Reference]]s) 등을 제대로 정리(clean up)하지 못할 경우, 이 컴포넌트들은 가비지 컬렉터에 의해 회수되지 못하고 세션 수명 내내 메모리에 축적됩니다 [1].
- **누수 탐지를 위한 3-스냅샷 기법(Three-snapshot technique):** 라우트 전환 시 발생하는 메모리 누수를 감지하고 최적화하기 위해 가장 신뢰할 수 있는 방법은 3-스냅샷 기법입니다 [2]. 
-  1. 기준이 되는 첫 번째 힙 스냅샷([[Heap Snapshot|Heap Snapshot]] 1)을 캡처합니다 [2].
-  2. 라우트 간 이동(navigate between routes)과 같이 누수가 의심되는 작업을 수행한 후 두 번째 스냅샷을 찍습니다 [2].
-  3. 동일한 라우트 전환 작업을 다시 반복하고 세 번째 스냅샷을 캡처합니다 [2].
-  4. 두 번째와 세 번째 스냅샷을 비교하여, 첫 번째와 두 번째 사이에 할당되었으나 세 번째 스냅샷까지 여전히 메모리에 살아있는 객체들을 찾아냅니다 [2]. 이 접근법은 단순 1회성 할당으로 인한 오탐(false positives)을 걸러내고 실제 누수 후보를 식별하는 데 효과적입니다 [2].
- **정보 한계:** 제공된 소스에서는 SPA 라우트 전환 시의 성능 최적화를 메모리 누수 발생 원인과 그 탐지(DevTools 활용 등) 관점에서만 다루고 있습니다 [1, 2]. 라우팅 시의 렌더링 최적화, 코드 스플리팅, 네트워크 지연 단축 등 다른 측면의 최적화에 대해서는 소스에 관련 정보가 부족합니다.
-
---
-
-* **작동 방식:** 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|SaaS]] 플랫폼 등에서 이상적으로 활용됩니다 [5, 10].
-
---
-
-*   **클라이언트 사이드 렌더링(CSR)의 동작 방식**
-    SPA 렌더링의 핵심은 렌더링의 주도권이 서버에서 브라우저로 넘어간다는 점입니다. 사용자가 페이지를 요청하면 서버는 본문 내용이 거의 없는 뼈대 형태의 최소 HTML 파일과 자바스크립트 파일을 보냅니다 [4], [2]. 브라우저가 이 자바스크립트 코드를 다운로드, 파싱 및 실행한 뒤에야 동적으로 데이터를 가져오고 사용자 인터페이스를 구축하여 화면에 렌더링합니다 [3], [2].
-*   **SPA 렌더링 설계의 장단점(Trade-offs)**
-    *   **장점:** 전체 페이지를 다시 렌더링하지 않고 필요한 부분만 동적으로 업데이트하기 때문에 상호작용 속도가 매우 빠르고 부드러운 전환이 가능합니다 [10], [5]. 또한 서버는 초기 정적 파일과 API 응답만 제공하면 되므로 서버 부하 및 호스팅 비용이 크게 감소합니다 [10], [11], [12]. 이러한 특성 때문에 SEO보다 상호작용이 중요한 대시보드나 [[SaaS|SaaS]] 플랫폼에 최적화되어 있습니다 [10], [13].
-    *   **단점:** 자바스크립트 번들을 모두 다운로드하고 파싱하기 전까지는 사용자가 빈 화면이나 로딩 스피너만 보게 되어 초기 로딩 속도(First Contentful Paint)가 매우 느립니다 [3], [10], [6], [14]. 더불어 크롤러가 자바스크립트를 실행하지 못하면 빈 페이지만 인식하게 되어 SEO에 매우 불리합니다 [3], [15], [6].
-*   **가상 DOM(Virtual DOM)을 통한 DOM 조작 최적화**
-    SPA는 페이지 업데이트 과정에서 DOM 트리를 빈번하게 조작합니다. 그러나 DOM 트리를 직접 변경할 경우 브라우저의 레이아웃(Reflow)과 페인트(Repaint) 작업이 연쇄적으로 발생하여 렌더링 파이프라인의 성능이 크게 저하될 수 있습니다 [16], [7], [17], [18]. 이를 해결하기 위해 React와 같은 SPA 프레임워크는 메모리상에 가상 DOM을 두고, UI 상태 변경 시 두 트리 간의 차이점(Diffing)을 O(n)의 복잡도로 비교하여 실제 변경된 부분만 한 번에 DOM에 반영합니다 [19], [7], [20], [21].
-*   **렌더링 병목 해결 및 동시성(Concurrent) 설계**
-    사용자 상호작용이 많은 SPA에서 무거운 데이터 처리나 업데이트가 렌더링을 차단하는 것을 막기 위해, 최신 렌더링 설계는 다음과 같은 기법들을 사용합니다.
-    *   **자동 배칭([[Automatic Batching|Automatic Batching]]):** 여러 상태 업데이트를 단일 렌더링으로 묶어 DOM 렌더링 횟수를 대폭 줄입니다 [8], [22], [23].
-    *   **파이버(Fiber) 아키텍처와 우선순위 분할:** 렌더링 작업을 중단하거나 재개할 수 있는 작은 '작업 단위'로 분할하고, 사용자 입력과 같은 긴급한 업데이트에 높은 렌더링 우선순위를 부여하여 메인 스레드 차단을 방지합니다 [24], [25], [26], [27].
-
---
-
-**브라우저 렌더링 과정 (HTML → [[CSSOM|CSSOM]] → [[Render Tree|Render Tree]])**
-브라우저의 중요 렌더링 경로([[Critical Rendering Path|Critical Rendering Path]])는 HTML을 점진적으로 파싱하여 DOM(Document Object Model) 트리를 구축하고, CSS를 파싱하여 렌더링 차단 리소스인 [[CSSOM(CSS Object Model)|CSSOM(CSS Object Model]]을 생성하는 것으로 시작됩니다 [11-14]. DOM과 CSSOM이 준비되면 이 둘을 결합하여 렌더 트리(Render Tree)를 형성합니다. 렌더 트리는 `<script>`나 `display: none`이 적용된 요소와 같이 화면에 보이지 않는 노드를 제외하고, 가시적인 노드와 그에 일치하는 계산된 스타일 정보만을 포함합니다 [15-18]. 이후 각 시각적 요소의 정확한 크기와 뷰포트 내 위치를 계산하는 레이아웃(Layout/Reflow) 단계를 거쳐, 픽셀을 화면에 그리는 페인트(Paint/Repaint)와 여러 레이어를 화면에 결합하는 합성(Compositing) 과정을 통해 UI가 표시됩니다 [19-23].
-
-**Reflow / Repaint 최소화 방법**
-Reflow(레이아웃)는 DOM 구조가 변경되거나 창 크기 조정, 마진, 너비, 높이 등의 기하학적 속성이 변경될 때 트리의 상당 부분을 다시 계산해야 하므로 컴퓨팅 자원을 크게 소모합니다 [24-27]. Repaint는 색상이나 그림자 등 시각적 스타일만 변경될 때 발생합니다 [24, 25, 27]. 성능 최적화를 위해서는 불필요한 DOM 트리의 깊이를 줄이고, CSS 규칙을 간소화하며, DOM 업데이트를 일괄 처리([[Batching|Batching]])해야 합니다 [28-30]. 특히 애니메이션 요소는 `top`이나 `left` 대신 `transform`과 `opacity` 속성을 사용하여, 브라우저가 요소를 독립적인 레이어로 분리하고 GPU 가속(Compositing)을 활용하게 함으로써 Reflow를 피하는 것이 핵심입니다 [20, 29-31].
-
-**[[DOM vs Virtual DOM|DOM vs Virtual DOM]] 및 React가 빠른 이유**
-전통적인 방식처럼 DOM을 직접 수정하면 레이아웃과 페인트 연산이 반복적으로 트리거되어 성능이 크게 저하됩니다 [32]. React는 이를 극복하기 위해 UI의 가벼운 메모리 내 표현인 가상 DOM([[Virtual DOM|Virtual DOM]])을 사용합니다 [32-34]. React는 컴포넌트의 상태가 변할 때마다 새로운 가상 DOM을 생성하고, 이전 상태와 비교하는 $O(n)$ 복잡도의 휴리스틱 기반 Diffing 알고리즘([[Reconciliation|Reconciliation]])을 실행하여 실제 변경된 속성이나 노드만 선별적으로 실제 DOM에 패치(업데이트)합니다 [32, 33, 35-37].
-여기에 더해 React 16부터 도입된 파이버(Fiber) 아키텍처는 동시성 렌더링을 가능하게 합니다. 렌더링 작업을 중단, 재개, 혹은 폐기할 수 있는 작은 '작업 단위'로 분할하고, 사용자 입력이나 클릭과 같은 긴급한 작업을 데이터 필터링 같은 작업보다 우선 처리(우선순위 Lane 모델)하여 화면 버벅임(Jank)을 방지하고 반응성을 유지합니다 [38-44].
-
-**렌더링 최적화 개념 (자동 일괄 처리 및 [[React Compiler|React Compiler]])**
-최신 React는 성능 병목을 프레임워크 단에서 해결하고 있습니다. [[React 18|React 18]]의 자동 일괄 처리(Automatic Batching)는 기존 이벤트 핸들러뿐 아니라 `setTimeout`이나 `Promise` 같은 비동기 작업에서 발생하는 다수의 상태 업데이트를 하나의 리렌더링으로 묶어 DOM 렌더링 횟수를 획기적으로 줄여줍니다 [45-48]. 더 나아가, [[React 19|React 19]]에 도입된 React Compiler는 빌드 단계에서 코드를 정적 분석하여 변경되지 않는 값과 컴포넌트에 메모이제이션을 자동 삽입합니다. 이로 인해 불필요한 재렌더링(Re-render Cascade)이 제거되고 개발자가 수동으로 `useMemo`, `useCallback`, `React.memo`를 작성해야 하는 인지적 부담이 사라집니다 [49-53].
-
-**[[CSR vs SSR vs SSG|CSR vs SSR vs SSG]] 렌더링 전략 비교**
- **CSR (Client-Side Rendering):** 클라이언트(브라우저)에서 JavaScript를 실행해 전체 UI를 구축하고 데이터를 가져옵니다. 매우 동적인 상호작용을 지원하지만, 초기 렌더링까지 사용자가 빈 화면을 보게 되며 자바스크립트 실행이 필수적이라 검색 엔진 최적화(SEO)에 불리할 수 있습니다 [1, 2, 5, 54-57].
- **SSR (Server-Side Rendering):** 서버가 각 요청마다 데이터가 포함된 완전한 HTML을 렌더링하여 클라이언트에게 전송합니다. SEO에 매우 유리하며 초기 콘텐츠 페인트(FCP)가 빠르지만, 사용자 인터랙션을 위해 JavaScript 번들을 다운받고 연결하는 '하이드레이션([[Hydration|Hydration]])' 과정 동안 입력 지연(TTI 지연)이 발생할 수 있습니다 [58-63].
- **SSG (Static Site Generation) & ISR (Incremental Static Regeneration):** 빌드 타임에 HTML을 생성하여 CDN으로 배포하는 방식으로 성능 면에서 가장 빠르나 잦은 데이터 변경에는 취약합니다(SSG). ISR은 이를 보완하여 주기적으로 정적 페이지를 백그라운드에서 재생성합니다 [64-70].
- **[[React Server Components (RSC)|React Server Components (RSC]]:** 컴포넌트를 서버에서만 실행하고 직렬화된 데이터만을 클라이언트에 스트리밍하여 전송하는 혁신적 모델입니다. 클라이언트 자바스크립트 번들 크기에 전혀 영향을 주지 않고 서버 리소스(DB 등)에 직접 접근할 수 있게 해, 복잡한 프론트엔드 환경에서 상호작용이 필요한 클라이언트 컴포넌트(Client Component)와 역할을 명확히 분리합니다 [71-76].
-
-**컴포넌트 기반 아키텍처 ([[Component-Based Architecture|Component-Based Architecture]])**
-최신의 단일 페이지 애플리케이션 설계는 시스템을 분리 가능하고 재사용 가능한 소프트웨어 조각(컴포넌트)으로 구성하는 CBA 방법론을 따릅니다 [77-79]. 각 컴포넌트는 특정한 상태와 UI 로직을 캡슐화(Encapsulation)하여 잘 정의된 인터페이스(Props 등)로 통신합니다 [77, 80]. 이 구조는 코드의 모듈성과 재사용성을 높이고 유지보수와 디버깅을 단순화하며, 여러 개발팀이 독립적으로 기능(예: 검색창, 장바구니 등)을 개발하여 빠르고 유연하게 확장할 수 있는 기반이 됩니다 [81-85].
-
-## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
-
-## 🔗 지식 연결 (Graph)
- **Related Topics:** 메모리 누수([[memory|memory]] Leak), 3-스냅샷 기법(Three-snapshot technique), 가비지 컬렉션([[Garbage Collection|Garbage Collection]])
- **Projects/Contexts:** [[Browser|Browser]] Memory Leak Detection
- **Contradictions/Notes:** 소스에서는 SPA 라우트 전환 성능 최적화에 대한 전반적인 프론트엔드 렌더링 최적화 기술은 언급하지 않으며, 오직 컴포넌트 언마운트 시의 정리 실패로 인한 메모리 누수 문제와 그 진단법에만 집중하고 있습니다.
-
---
-*Last updated: 2026-04-19*
-
---
-
---
-
- **Related Topics:** [[클라이언트 사이드 렌더링 (CSR)|클라이언트 사이드 렌더링 (CSR]], 검색 엔진 최적화 (SEO), [[초기 로드 시간 (Initial Load Time)|초기 로드 시간 (Initial Load Time]]
- **Projects/Contexts:** [[SaaS 플랫폼 및 인터랙티브 대시보드 개발|SaaS 플랫폼 및 인터랙티브 대시보드 개발]]
- **Contradictions/Notes:** 소스에 따르면 SPA의 핵심인 CSR 방식은 상호작용성과 개발 속도 면에서 뛰어나지만 SEO와 초기 로드 시간에서는 뚜렷한 한계를 보입니다. 이러한 단점은 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)이 갖는 장점(빠른 초기 화면 및 SEO 최적화)과 정확히 대조됩니다 [1, 7, 8, 11].
-
---
-*Last updated: 2026-04-25*
-
---
-
- **Related Topics:** [[Client-Side Rendering (CSR)|Client-Side Rendering (CSR]], Virtual DOM, Reflow and Repaint, [[Hydration|Hydration]]
- **Projects/Contexts:** React, Vue 등의 프레임워크를 기반으로 하며 SEO보다는 동적이고 즉각적인 인터랙션이 필수적인 대시보드, SaaS 플랫폼, 내부 비즈니스 도구 등을 구축하는 맥락 [4], [13].
- **Contradictions/Notes:** SPA의 기본 렌더링 방식인 순수 CSR은 초기 로딩과 SEO에 치명적인 약점이 있기 때문에, 최근에는 초기 로딩 시 서버에서 완성된 HTML을 보내고 이후 브라우저에서 상호작용을 연결(Hydration)하는 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)을 페이지 특성에 맞춰 혼합(Hybrid)하여 사용하는 방식으로 발전하고 있습니다 [28], [9], [29], [30], [31].
-
---
-*Last updated: 2026-04-25*
-
---
-
- **Related Topics:** [[브라우저 렌더링 프로세스 (CRP)|브라우저 렌더링 프로세스 (CRP]], 가상 DOM (Virtual DOM) 및 재조정(Reconciliation), React Fiber 및 동시성 렌더링, [[서버 사이드 렌더링(SSR)과 하이드레이션(Hydration)|서버 사이드 렌더링(SSR)과 하이드레이션(Hydration]], [[컴포넌트 기반 아키텍처 (CBA)|컴포넌트 기반 아키텍처 (CBA]]
- **Projects/Contexts:** [[Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입|Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입]], [[React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용|React 18 자동 일괄 처리 및 React 19 컴파일러 최적화 적용]]
- **Contradictions/Notes:** CSR 방식은 초기 로드 속도와 SEO 측면에서 불리하다는 한계가 널리 알려져 있으나, 실시간 상호작용이 많고 SEO가 중요하지 않은 인증 기반의 [[SaaS|SaaS]] 대시보드나 내부 비즈니스 도구에서는 서버의 렌더링 부하를 줄이고 유연성을 높이기 때문에 여전히 SSR보다 가장 적합한 렌더링 방식으로 권장됩니다 [4, 86, 87]. 또한, React 19 컴파일러가 대부분의 수동 메모이제이션을 불필요하게 만들지만, 외부 타사 라이브러리 연동 시 참조 안정성이 깨지거나 이펙트 의존성 제어가 필요한 특정 상황에서는 여전히 `useMemo` 등을 통한 수동 제어가 필요할 수 있습니다 [88-90].
-
---
-*Last updated: 2026-04-25*
-
-## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
-
-**언제 이 지식을 쓰는가:**
- *(TODO)*
-
-**언제 쓰면 안 되는가:**
- *(TODO)*
-
-## 🧪 검증 상태 (Validation)
-
- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
-
-## 🧬 중복 검사 (Duplicate Check)
-
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
-
-## 🕓 변경 이력 (Changelog)
-
-| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
-|------|-----------|-----------|--------|
-| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
-
-## 💻 코드 패턴 (Code Patterns)
-
-**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
-
-```text
-# TODO
+<Route path="/dashboard" element={
+  <Suspense fallback={<Skeleton />}><Dashboard /></Suspense>
+} />
 ```

-## 🤔 의사결정 기준 (Decision Criteria)
+### 매 Hover prefetch (TanStack Router)
+```tsx
+import { Link } from "@tanstack/react-router";
+<Link to="/products/$id" params={{ id }} preload="intent">
+  Product
+</Link>
+// 매 hover/focus → 매 chunk + loader data 미리.
+```

-**선택 A를 써야 할 때:**
- *(TODO)*
+### 매 Parallel loaders (waterfall 제거)
+```tsx
+// X — sequential
+const route = createRoute({
+  loader: async () => {
+    const user = await fetchUser();   // 매 wait
+    const orders = await fetchOrders(user.id); // 매 then wait
+    return { user, orders };
+  },
+});

-**선택 B를 써야 할 때:**
- *(TODO)*
+// O — parallel where possible
+const route = createRoute({
+  loader: async ({ params }) => {
+    const [user, orders] = await Promise.all([
+      fetchUser(params.id),
+      fetchOrdersForId(params.id), // 매 user 의존 X로 변경
+    ]);
+    return { user, orders };
+  },
+});
+```

-**기본값:**
-> *(TODO)*
+### 매 View Transitions API
+```tsx
+// 매 navigation에 매 native cross-fade
+import { unstable_ViewTransition as ViewTransition } from "react";

-## ❌ 안티패턴 (Anti-Patterns)
+function App() {
+  return (
+    <ViewTransition>
+      <Outlet />
+    </ViewTransition>
+  );
+}
+```

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
+```css
+::view-transition-old(root) { animation: fade-out 200ms; }
+::view-transition-new(root) { animation: fade-in 200ms; }
+```
+
+### 매 RSC streaming (Next 15)
+```tsx
+// app/products/[id]/page.tsx
+export default async function Page({ params }: { params: { id: string } }) {
+  return (
+    <>
+      <ProductHeader id={params.id} /> {/* 매 빠른 part */}
+      <Suspense fallback={<Skeleton />}>
+        <ProductReviews id={params.id} /> {/* 매 느린 part stream */}
+      </Suspense>
+    </>
+  );
+}
+```
+
+### 매 Optimistic navigation
+```tsx
+// React 19 useOptimistic 응용
+const [optimisticPath, setOptimisticPath] = useOptimistic(currentPath);
+
+function navigate(to: string) {
+  startTransition(() => {
+    setOptimisticPath(to); // 매 즉시 UI 변경
+    router.navigate(to);
+  });
+}
+```
+
+### 매 Bundle 분석 (rsdoctor / webpack-bundle-analyzer)
+```bash
+pnpm dlx @rsdoctor/cli analyze
+# 매 route chunk 크기 매 visualize → 매 split point 매 결정
+```
+
+## 매 결정 기준
+| 상황 | Approach |
+|---|---|
+| 매 small SPA | Route-split + hover prefetch. |
+| 매 dashboard 다중 widget | Parallel loaders + Suspense streaming. |
+| 매 SEO + perf | Next 15 App Router (RSC). |
+| 매 highly interactive | TanStack Router + View Transitions. |
+| 매 mobile-first | Aggressive prefetch는 매 신중 (data cost). |
+
+**기본값**: Route-split + intent prefetch + parallel loaders. 매 modern routers는 매 default support.
+
+## 🔗 Graph
+- 부모: [[SPA]] · [[Web Performance]]
+- 변형: [[Server-Side Rendering]] · [[Islands Architecture]]
+- 응용: [[React Router]] · [[TanStack Router]] · [[Next.js App Router]]
+- Adjacent: [[Core Web Vitals]] · [[INP]] · [[View Transitions]] · [[Code Splitting]]
+
+## 🤖 LLM 활용
+**언제**: 매 route 전환 매 느릴 때, 매 perf budget 책정, 매 prefetch 전략 설계.
+**언제 X**: 매 MPA, 매 first-load 문제 (매 SSR/SSG 별도).
+
+## ❌ 안티패턴
+- **매 lazy 모든 component**: 매 too granular → 매 waterfall 악화.
+- **매 prefetch 모든 link**: 매 모바일 데이터 burn.
+- **매 loader에 매 sequential await**: 매 waterfall.
+- **매 Suspense 없이 매 lazy**: 매 blank 화면.
+- **매 view-transition 만 적용**: 매 underlying perf 안 고치고 cosmetic만.
+
+## 🧪 검증 / 중복
+- Verified (web.dev, React Router 7 docs, TanStack Router docs, Next 15 docs).
+- 신뢰도 A.
+
+## 🕓 Changelog
+| 날짜 | 변경 |
+|---|---|
+| 2026-05-08 | Phase 1 |
+| 2026-05-10 | Manual cleanup — 2026 router stack + View Transitions + RSC streaming |