---
id: P-REINFORCE-AUTO-2F9E62
category: "10_Wiki/💡 Topics/Programming & Language"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 메모리 누수(Memory Leaks)"
---

# [[메모리 누수(Memory Leaks)|메모리 누수(Memory Leaks)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 가비지 컬렉션 환경에서의 메모리 누수는 개발자가 더 이상 필요로 하지 않는 객체들이 가비지 컬렉션(GC) 루트로부터 여전히 참조되고 있어 메모리가 해제되지 않는 현상을 의미한다 [1-4]. 이러한 현상은 애플리케이션의 메모리 사용량을 점진적으로 증가시키며, 결과적으로 잦은 GC 실행에 따른 성능 저하와 메모리 부족(OOM) 크래시를 유발한다 [5, 6]. 일반적인 메모리 유실과 달리, 자바스크립트에서의 메모리 누수는 기본적으로 코드 어딘가에 남아있는 원치 않는 참조 때문에 발생한다 [1, 4].

## 📖 구조화된 지식 (Synthesized Content)
*   **발생 메커니즘:** V8 엔진과 같은 런타임 환경에서 객체는 글로벌 객체, 활성 클로저, 이벤트 리스너, 타이머 등으로부터 도달 가능(reachable)한 상태일 때 메모리에 유지된다 [1, 4]. 이 연결 고리를 끊지 않으면 프로그램 실행 시간이 길어질수록 힙(Heap) 메모리가 해제되지 않고 계단식(Ratchet)으로 상승하는 패턴을 보인다 [7, 8]. 특히 수명이 긴 객체들이 모이는 V8의 'Old space' 영역 사용량이 Major GC 이후에도 지속적으로 증가한다면 메모리 누수일 확률이 매우 높다 [9, 10].
*   **주요 누수 패턴:** 소스에 따르면 다음과 같은 상황에서 메모리 누수가 빈번하게 발생한다.
    *   **이벤트 리스너 및 타이머 축적:** 렌더링 주기나 인터벌 콜백에서 추가된 리스너 및 타이머(setInterval 등)를 적절히 제거하지 않으면, 해당 콜백의 클로저와 참조된 객체들이 무기한 메모리에 남게 된다 [11-14]. Node.js 환경에서 단일 이벤트에 10개 이상의 리스너가 추가될 때 발생하는 `MaxListenersExceededWarning` 경고는 누수 발생을 확인하는 명확한 지표이다 [15].
    *   **클로저 스코프 보존:** 여러 클로저가 하나의 스코프를 공유하는 경우, 단 하나의 클로저라도 변수를 참조하여 활성 상태를 유지하면 동일 스코프 내에서 캡처된 다른 대용량 객체들도 메모리에서 해제되지 못한다 [11, 15].
    *   **분리된 DOM 노드:** DOM 트리에서는 제거되었으나 JavaScript 변수나 Map/Set 등에 의해 참조를 유지하고 있는 DOM 요소는 해당 요소가 포함된 전체 서브트리의 메모리를 지속적으로 점유한다 [16, 17].
    *   **무제한 캐시 및 라우트 전환:** 크기 제한이 없는 캐시 데이터, 혹은 SPA(Single Page Application)에서 이전 라우트의 컴포넌트가 전역 상태 참조나 리스너를 정리하지 못하는 것도 주요 누수 원인이다 [15, 18].
    *   **잘라낸 문자열(Sliced String):** 거대한 문자열의 일부분을 `substring()` 등으로 잘라 전역 변수에 보관할 경우, 잘라낸 문자열이 원본 문자열의 포인터를 유지하므로 사용하지 않는 원본 문자열 전체가 메모리에서 해제되지 못할 수 있다 [19].
*   **진단 및 프로파일링 도구:** 
    *   Chrome DevTools의 '힙 스냅샷(Heap Snapshots)'과 '할당 타임라인(Allocation Timeline)'을 활용하여 누수를 진단한다 [20-23]. 
    *   특정 동작을 수행하기 전후로 여러 번 스냅샷을 찍어 비교하는 '3-스냅샷 기법'을 통해, 의도치 않게 남아있는 객체를 효과적으로 식별할 수 있다 [20, 24]. 타임라인에 나타나는 파란색 막대는 할당 후 해제되지 않은 살아있는 메모리를 의미하며, 이를 통해 잠재적인 누수 지점을 파악한다 [23, 25, 26].
    *   의심되는 객체를 찾았다면 DevTools의 'Retainers' 패널을 통해 해당 객체가 어떤 참조 경로(Retaining Path)를 거쳐 GC 루트에 연결되어 있는지 역추적하여 원인을 파악할 수 있다 [27-29].
    *   또한 `--trace-gc` 플래그, `heapdump`, `clinic.js` 같은 도구를 사용하여 가비지 컬렉션 동작과 메모리 증가 추세를 모니터링할 수 있다 [7, 13, 30, 31].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[가비지 컬렉션(Garbage Collection)|가비지 컬렉션(Garbage Collection)]], [[V8 Heap Architecture|V8 Heap Architecture]], [[힙 스냅샷(Heap Snapshot)|힙 스냅샷(Heap Snapshot)]], 클로저(Closure)
- **Projects/Contexts:** Node.js Memory Leaks in Production, [[브라우저 메모리 누수 탐지(Browser Memory Leak Detection)|Browser Memory Leak Detection]]
- **Contradictions/Notes:** C/C++ 프로그램 등에 사용되는 컴파일러 지원이 없는 보수적(Conservative) 가비지 컬렉터의 경우, 포인터처럼 보이는 일반 정수 데이터로 인해 거대한 객체 서브그래프가 유지되는 독특한 형태의 메모리 누수를 유발할 가능성이 존재한다고 소스에서 지적한다 [32]. 또한 프론트엔드 최신 도구인 `WeakRef`와 `FinalizationRegistry`를 사용해 누수에 강한 패턴을 작성할 수 있으나, 가비지 컬렉터는 자체 일정에 따라 실행되어 결정론적이지 않으므로 적절한 객체 수명 주기 관리를 완벽히 대체할 수는 없음에 유의해야 한다 [12].

---
*Last updated: 2026-04-19*
- Raw Source: 00_Raw/2026-04-20/메모리 누수(Memory Leaks).md
---