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의 메모리 누수는 가비지 컬렉션(GC)되어야 할 객체들이 클로저, 이벤트 리스너, 타이머 등의 루트(Root) 객체에 계속 참조되어 메모리에서 해제되지 않을 때 발생합니다 [1, 2]. Node.js는 단일 프로세스로 장기간 실행되는 특성이 있어, 누수된 참조는 모든 요청에 걸쳐 지속적으로 축적되며 결국 V8 힙 한계에 도달하여 OOM(Out-Of-Memory) 크래시를 유발합니다 [3, 4]. 이 문제를 해결하기 위해서는 힙 스냅샷과 메모리 할당 타임라인 도구를 활용하여, 지속적으로 증가하는 객체의 참조 경로(Retaining Path)를 추적하고 참조를 끊어 GC가 정상 작동하도록 근본적인 원인을 수정해야 합니다 [5-7].
@@ -19,8 +19,8 @@ Node.js의 메모리 누수는 가비지 컬렉션(GC)되어야 할 객체들이
     *   만약 V8의 힙 영역 중 장기 생존 객체가 저장되는 공간에 큰 메모리가 필요하다면, `--max-old-space-size` 명령줄 플래그로 Old Space 크기를 늘려 애플리케이션 충돌과 과도한 GC 지연을 방지할 수 있습니다 [24]. 반대로, 짧은 주기의 객체 생성이 많은 경우에는 `--max-semi-space-size` 플래그로 New Space를 늘려 마이너 GC 주기를 조절할 수 있습니다 [25].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** [[가비지 컬렉션 (Garbage Collection)]], [[V8 엔진 (V8 Engine)]], [[힙 스냅샷 (Heap Snapshots)]], [[Mark-Sweep]]
-- **Projects/Contexts:** [[Chrome DevTools]], [[clinic.js]], [[Node.js Production Monitoring]]
+- **Related Topics:** [[가비지 컬렉션 (Garbage Collection)|가비지 컬렉션 (Garbage Collection)]], [[V8 엔진 (V8 Engine)|V8 엔진 (V8 Engine)]], [[힙 스냅샷 (Heap Snapshots)|힙 스냅샷 (Heap Snapshots)]], [[Mark-Sweep|Mark-Sweep]]
+- **Projects/Contexts:** [[Chrome DevTools|Chrome DevTools]], [[clinic.js|clinic.js]], [[Node.js Production Monitoring|Node.js Production Monitoring]]
 - **Contradictions/Notes:** 소스에 따르면 모던 프론트엔드 환경의 브라우저에서는 메모리 누수의 가장 주요한 원인(1위)으로 SPA(Single Page Application) 경로 전환을 꼽고 있지만 [26], Node.js 프로덕션 서버 환경에서는 EventEmitter 리스너 누적이 가장 흔한 메모리 누수 패턴으로 언급되는 차이가 있습니다 [9].
 
 ---