docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links

01_Archive/2026-04-20/브라우저 및 Node.js 메모리 튜닝.md

@@ -1,4 +1,4 @@
-# [[브라우저 및 Node.js 메모리 튜닝]]
+# [[브라우저 및 Node.js 메모리 튜닝|브라우저 및 Node.js 메모리 튜닝]]
 
 ## 📌 Brief Summary
 브라우저와 Node.js의 메모리 튜닝은 V8 엔진의 메모리 사용량을 모니터링하고 가비지 컬렉션(GC)을 최적화하며, 메모리 누수를 해결하는 과정이다 [1, 2]. 애플리케이션의 메모리가 해제되지 않고 누적되는 현상을 탐지하기 위해 힙 스냅샷(Heap snapshot)과 타임라인 할당 추적(Allocation timeline) 등의 도구를 활용하여 원인을 분석한다 [3-6]. 또한 커맨드라인 플래그를 통한 힙 메모리 크기 조정과 V8의 세대별(Generational) 메모리 관리 구조를 깊이 이해함으로써 Out-Of-Memory (OOM) 크래시를 방지하고 성능을 극대화할 수 있다 [2, 7, 8].
@@ -17,8 +17,8 @@
   최신 프론트엔드 및 Node.js 애플리케이션의 7대 주요 누수 패턴으로는 화면에서 제거된 후에도 JavaScript 변수에 묶여있는 DOM 노드(Detached DOM nodes) [35, 36], 무한정 커지는 인메모리 캐시 [37], 삭제되지 않은 이벤트 리스너(Event Listener Accumulation) [34, 38], 정리되지 않은 setInterval 등의 타이머 및 옵저버 [37, 39, 40], 클로저(Closure) 내부 변수의 과도한 수명 연장 현상 등이 있다 [37, 38]. 
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** `[[V8 Engine Heap Architecture]]`, `[[Orinoco Garbage Collector]]`, `[[Heap Snapshot & Allocation Timeline]]`, `[[Generational GC Hypothesis]]`
-- **Projects/Contexts:** `[[Node.js Production Monitoring]]`, `[[Chrome DevTools Profiling]]`, `[[Electron Memory Cage]]`
+- **Related Topics:** `V8 Engine Heap Architecture`, `Orinoco Garbage Collector`, `Heap Snapshot & Allocation Timeline`, `Generational GC Hypothesis`
+- **Projects/Contexts:** `[[Node.js Production Monitoring|Node.js Production Monitoring]]`, `Chrome DevTools Profiling`, `Electron Memory Cage`
 - **Contradictions/Notes:** 가비지 컬렉션 시 살아남은 객체를 새로운 메모리 페이지로 복사(Copy)하는 방식은 비용이 크게 느껴질 수 있으나, 소스에 따르면 '대부분의 객체는 매우 짧은 시간 안에 버려진다(Generational Hypothesis)'는 통계적 근거 덕분에, 적은 수의 생존 객체만 복사하는 것이 전체 메모리 스캔 비용보다 훨씬 저렴하여 성능 상 이점이 크다고 설명한다 [41]. 또한, 포인터 압축(Pointer Compression) 기술은 메모리 사용량을 대폭 절감하지만, V8 힙을 최대 4GB로 제한하는 구조적 한계를 낳아 Electron과 같은 특수 환경에서 큰 ArrayBuffer를 다루는 네이티브 모듈에 리팩토링 부담을 주는 트레이드오프가 있다 [42-45].
 
 ---