feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

10_Wiki/Topics/AI_and_ML/GPU Acceleration (Compositing).md

@@ -1,9 +1,26 @@
+---
+id: wiki-2026-0508-gpu-acceleration-compositing
+title: GPU Acceleration (Compositing)
+category: 10_Wiki/Topics
+status: needs_review
+canonical_id: self
+aliases: []
+duplicate_of: none
+source_trust_level: A
+confidence_score: 0.92
+tags: [uncategorized]
+raw_sources: []
+last_reinforced: 2026-05-08
+github_commit: pending
+inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
+---
+
 # [[GPU Acceleration (Compositing)|GPU Acceleration (Compositing]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 GPU 가속(또는 합성, Compositing)은 브라우저가 메인 스레드에서 수행하던 애니메이션 등 렌더링 작업을 그래픽 처리 장치(GPU)로 오프로드(Offload)하여 처리하는 성능 최적화 기법이다 [1, 2]. 이를 통해 브라우저는 값비싼 레이아웃 재계산(Reflow) 및 다시 그리기(Repaint) 단계를 건너뛰고 오직 합성(Composite) 단계만 트리거하게 된다 [2]. 결과적으로 특히 성능이 제한적인 모바일 기기 환경에서도 60FPS의 부드럽고 끊김 없는 애니메이션을 구현하는 데 핵심적인 역할을 한다 [2, 3].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 * **작동 원리 및 이점:** 
   모던 브라우저의 렌더링 파이프라인은 '스타일 계산 -> 레이아웃(Reflow) -> 페인트(Repaint) -> 합성(Composite)' 순으로 이루어진다 [4]. 복잡한 애니메이션에서 60FPS의 부드러운 성능을 달성하려면 비용이 많이 드는 레이아웃과 페인트 단계를 우회해야 하는데, 이때 연산을 GPU로 위임하여 합성 단계만 실행하게 하는 것이 GPU 가속의 원리이다 [2]. 이는 렌더링 레이어에만 영향을 주기 때문에 성능이 크게 향상된다 [5].
 * **GPU 가속을 트리거하는 주요 CSS 속성:** 
@@ -18,10 +35,41 @@ GPU 가속(또는 합성, Compositing)은 브라우저가 메인 스레드에서
 * **성능 최적화([[Optimization|Optimization]]) 전략:**
   CSS 실전 설계 시 유지보수성과 성능을 동시에 잡으려면 애니메이션 구현 시 `transform`과 `opacity` 위주로 사용하여 GPU 가속을 적극 활용해야 한다 [2, 8]. 또한, 거대한 백그라운드 이미지나 무거운 `box-shadow` 등의 애니메이션은 GPU/CPU 자원을 많이 소모하므로 사용을 최소화해야 한다 [5, 9].
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 - **Related Topics:** [[CSS Animations|CSS Animations]], [[Reflow and Repaint|Reflow and Repaint]], will-change
 - **Projects/Contexts:** [[Performance Optimization|Performance Optimization]], UI/UX Motion Design
 - **Contradictions/Notes:** 소스 문헌들은 `will-change` 속성이 브라우저가 요소를 GPU에서 처리하도록 미리 준비시켜 애니메이션 성능을 높이는 데 유용하다고 설명하지만, 동시에 이를 예상되는 성능 문제를 방지하기 위해 너무 많은 요소에 남용해서는 안 된다고 경고한다. 불필요한 `will-change` 남용은 오히려 시스템 리소스를 고갈시키고 성능 문제를 악화시킬 수 있으므로, 기존에 발생한 성능 문제를 해결하기 위한 최후의 수단(last resort)으로만 제한적으로 사용해야 한다 [7, 9, 10].
 
 ---
-*Last updated: 2026-04-26*
+*Last updated: 2026-04-26*
+
+## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
+
+**언제 이 지식을 쓰는가:**
+- *(TODO)*
+
+**언제 쓰면 안 되는가:**
+- *(TODO)*
+
+## 🧪 검증 상태 (Validation)
+
+- **정보 상태:** needs_review
+- **출처 신뢰도:** A
+- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
+
+## 🧬 중복 검사 (Duplicate Check)
+
+- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
+- **처리 방식:** UPDATE (자동 정규화)
+- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
+
+- **과거 데이터와의 충돌:** 없음
+- **정책 변화:** 없음
+
+## 🕓 변경 이력 (Changelog)
+
+| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
+|------|-----------|-----------|--------|
+| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |