feat: batch wikification of Skybound balance pass and scalable frontend architectures

Processed 80+ files including Skybound playtest feedback, Monorepo strategies, and Modern Component Patterns.

10_Wiki/Topics/Frontend_Mastery/Performance Optimization.md

@@ -1,27 +1,19 @@
 # [[Performance Optimization]]
 
 ## 📌 Brief Summary
-성능 최적화(Performance Optimization)는 웹 애플리케이션의 로딩 속도를 단축시키고 사용자 상호작용을 매끄럽게 만들기 위해 브라우저 렌더링 과정과 리소스 처리 방식을 개선하는 일련의 기술적 과정입니다 [1-3]. 주로 초기 렌더링 시간(Fast First Paint)을 앞당기고, 프레임 드롭(Jank)을 방지하며, 최대 콘텐츠풀 페인트(LCP)와 같은 핵심 웹 바이탈(Core Web Vitals) 지표를 향상하는 것을 목표로 합니다 [2-6]. 모던 프론트엔드에서는 중요 렌더링 경로(CRP)의 최소화, React와 같은 프레임워크 수준에서의 불필요한 렌더링 방지, 그리고 적절한 서버/클라이언트 렌더링 전략(SSR, SSG 등)의 선택을 통해 이루어집니다 [1, 7-9].
+최신 React 프론트엔드 아키텍처에서 성능 최적화(Performance Optimization)는 런타임 오버헤드를 최소화하고, 번들 크기를 줄이며, 코어 웹 바이탈(Core Web Vitals)을 개선하는 일련의 과정과 아키텍처적 선택을 의미합니다. 이는 주로 런타임에 스타일을 동적으로 주입하는 CSS-in-JS 대신 빌드 타임에 정적 CSS를 생성하는 유틸리티 퍼스트(Utility-first) CSS를 도입하는 방식으로 이루어집니다 [1, 2]. 또한 복잡한 컴포넌트 설계 시 컨텍스트(Context) 분리와 메모이제이션(Memoization)을 통해 불필요한 리렌더링을 방지하는 컴포넌트 수준의 설계 최적화도 포함됩니다 [3-5].
 
 ## 📖 Core Content
-*   **중요 렌더링 경로(CRP) 최적화 및 브라우저 렌더링 제어**
-    *   브라우저가 HTML, CSS, JavaScript를 화면의 픽셀로 변환하는 '중요 렌더링 경로(Critical Rendering Path)'를 최적화하는 것이 가장 기본입니다 [1, 10]. 초기 렌더링 속도를 높이기 위해 렌더링을 차단하는 리소스를 지연시키거나 제거하며, 불필요한 DOM 노드의 깊이를 최소화해야 합니다 [8, 11, 12].
-    *   특히 계산 비용이 큰 레이아웃 재계산인 **리플로우(Reflow)**를 유발하는 속성(예: width, height, margin 조작) 사용을 최소화하고, 시각적 속성만 변경하는 리페인트(Repaint)나 GPU 가속 기반의 컴포지팅(Compositing) 기법을 활용하여 성능 저하를 방지해야 합니다 [6, 12-20].
-
-*   **React 프레임워크 레벨의 최적화 기법**
-    *   **리렌더링 폭포수(Re-render Cascade) 방지:** 부모 컴포넌트의 상태 변화가 무관한 자식 컴포넌트들의 렌더링까지 유발하는 것을 막기 위해 `React.memo`, `useMemo`, `useCallback`을 사용하여 얕은 비교를 통한 메모이제이션을 수행합니다 [21-25]. 
-    *   **자동 일괄 처리 (Automatic Batching):** React 18부터 도입된 기능으로, 네이티브 이벤트 핸들러뿐만 아니라 비동기 작업(Promise, setTimeout 등) 내에서 발생하는 여러 상태 업데이트들을 하나로 묶어(Batching) 단 한 번의 리렌더링만 발생하도록 하여 렌더링 성능을 극대화합니다 [26-33].
-    *   **동시성 렌더링 (Concurrent Rendering):** `useTransition` 및 `useDeferredValue` 훅을 사용하여 무거운 연산을 후순위로 미루고(Non-urgent), 사용자의 타이핑이나 클릭 같은 긴급한 상호작용(Urgent)을 우선적으로 처리함으로써 UI가 멈추는 현상을 방지합니다 [34-38].
-    *   **가상화 및 코드 분할:** 수백 개 이상의 긴 목록은 화면에 보이는 항목만 DOM 노드로 생성하는 가상화(Virtualization)를 적용하며 [39, 40], `React.lazy()`를 활용한 라우트 수준의 코드 분할(Code Splitting)로 초기 자바스크립트 번들 크기를 줄여 LCP 점수를 개선합니다 [41].
-
-*   **아키텍처 및 렌더링 전략 최적화**
-    *   애플리케이션 특성에 맞춰 **CSR(클라이언트 사이드 렌더링)**, **SSR(서버 사이드 렌더링)**, **SSG(정적 사이트 생성)**, **ISR(점진적 정적 재생성)** 등을 적절히 선택하거나 혼합(Hybrid)하여 사용합니다 [42-60]. 
-    *   최근 도입된 **[[React Server Components]] (RSC)**는 브라우저로 전송되는 자바스크립트 번들 크기를 '0 바이트'로 줄이고 서버 측 자원(DB 등)에 직접 접근하여 렌더링 된 HTML만을 스트리밍 형태로 클라이언트에 전달하므로, 클라이언트 측의 렌더링 및 하이드레이션(Hydration) 부하를 혁신적으로 제거합니다 [61-66].
+- **스타일링 패러다임과 런타임 오버헤드:** Tailwind CSS와 같은 유틸리티 퍼스트 프레임워크는 빌드 타임에 정적 CSS를 생성하므로 런타임 오버헤드가 없으며, 프로덕션 환경에서 5-20kb 수준의 작은 번들 크기를 유지합니다 [1, 2, 6]. 반면 Styled-components나 Emotion과 같은 런타임 CSS-in-JS는 브라우저에서 JavaScript를 실행해 CSS 문자열을 생성하고 삽입하는 '런타임 세금(Runtime tax)'을 발생시켜, 콘텐츠가 많거나 저사양 기기에서 CPU 병목 현상을 유발할 수 있습니다 [2, 7, 8].
+- **Core Web Vitals 및 렌더링 속도 향상:** Styled-components에서 Tailwind CSS로 스타일링을 전환한 벤치마크 및 실제 기업 사례에 따르면, JavaScript 실행 시간이 줄어듦에 따라 모바일 환경에서 최초 입력 지연(FID)이 최대 75.9%, 다음 페인트에 대한 상호작용(INP)이 최대 58.4% 감소했습니다 [9-12]. 10,000개의 리스트 아이템을 렌더링하는 테스트에서도 Tailwind는 85ms, Styled-components는 148ms가 소요되어 상당한 성능 격차를 보였습니다 [13].
+- **React Server Components (RSC) 호환성:** React Context에 의존하는 런타임 CSS-in-JS 라이브러리들은 Context API가 존재하지 않는 서버 전용 실행 환경인 RSC와 근본적으로 호환되지 않아 성능 문제를 일으킵니다 [8, 14, 15]. 따라서 Next.js App Router와 같은 환경에서는 런타임 CSS-in-JS의 사용을 지양하고, Tailwind CSS나 CSS Modules, 또는 Zero-runtime CSS-in-JS(예: vanilla-extract)를 사용하는 것이 성능상 권장됩니다 [14, 16].
+- **빌드 성능 개선 (Tailwind v4):** 최근 도입된 Tailwind CSS v4는 Rust 기반의 Oxide 엔진을 채택하여 기존 JavaScript 기반 컴파일러 대비 전체 빌드 속도가 5~10배, 증분 빌드(Incremental build) 속도가 100배 이상 빨라져 개발 환경의 성능을 비약적으로 향상시켰습니다 [17-21].
+- **컴포넌트 아키텍처 수준의 최적화:** 합성 컴포넌트(Compound Components) 패턴을 통해 복잡한 UI를 구성할 때, 모든 상태를 하나의 Context에 담기보다 상태(State)와 액션(Actions)을 별도의 컨텍스트로 분리(Split Contexts)하면 불필요한 하위 컴포넌트의 리렌더링을 방지할 수 있습니다 [3, 5]. 이와 함께 렌더링 비용이 높은 하위 컴포넌트에 대해 전략적인 메모이제이션을 적용하는 것도 성능 최적화의 핵심입니다 [4].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** [[Critical Rendering Path]], [[Reflow and Repaint]], [[Automatic Batching]], [[React Compiler]], [[Virtual DOM]], [[Server-Side Rendering (SSR)]], [[React Server Components]]
-- **Projects/Contexts:** [[React 18 Concurrent Features]], [[Next.js App Router]]
-- **Contradictions/Notes:** 과거에는 개발자가 수동으로 `useMemo`나 `useCallback`, `React.memo`를 삽입하여 불필요한 리렌더링을 최적화해야 했으나, 최근 안정화된 **React Compiler**는 빌드 타임에 코드와 데이터 흐름을 분석하여 이러한 메모이제이션 경계를 자동으로 삽입해 줍니다. 따라서 이제 수동 메모이제이션은 컴파일러의 자동 처리에 의존하게 되어 대부분 제거될 수 있으나, 효과적인 의존성 제어나 서드파티 라이브러리 통합 등 특수한 예외 상황의 '비상 탈출구(Escape Hatch)' 용도로만 제한적으로 남게 됩니다 [25, 67-72].
+- **Related Topics:** [[Tailwind CSS]], [[Styled-components]], [[React Server Components (RSC)]], [[Core Web Vitals]], [[Compound Components]]
+- **Projects/Contexts:** [[Next.js App Router]], [[Tailwind CSS v4 Oxide Engine]]
+- **Contradictions/Notes:** 런타임 오버헤드 문제로 인해 Styled-components가 성능 측면에서 불리하다는 지적이 많으나, Styled-components v6 메이저 업데이트에서는 캐싱 및 핫 패스 마이크로 최적화를 통해 부모 컴포넌트의 리렌더링 속도를 최대 3.3배 향상시켰으며, 인라인 스타일 주입 방식을 통해 RSC(React Server Components) 환경에 대한 호환성을 새롭게 추가하여 단점들을 개선했습니다 [22-24].
 
 ---
-*Last updated: 2026-04-25*
+*Last updated: 2026-04-26*