# [[Memory Leak Detection]]

## 📌 Brief Summary
메모리 누수(Memory Leak)란 애플리케이션이 메모리를 할당한 후 해당 메모리가 더 이상 필요하지 않음에도 불구하고 해제하지 않아 발생하는 현상입니다 [1]. 이로 인해 시간이 지남에 따라 메모리 소비가 지속적으로 증가하며, 결국 성능 저하, 브라우저 탭 멈춤 또는 크래시 등을 유발하게 됩니다 [2]. 주로 문서에서 제거된 DOM 노드, 정리되지 않은 이벤트 리스너, 클로저에 의해 의도치 않게 유지되는 객체 참조 등이 주요 원인으로 작용합니다 [3, 4].

## 📖 Core 소스 Content
**증상 및 식별**
*   메모리 누수는 애플리케이션의 성능이 시간이 지남에 따라 점진적으로 저하되거나, 메모리 사용량이 안정화(plateau)되지 않고 계속 증가하는 증상으로 나타납니다 [1, 2, 5].
*   Chrome Task Manager를 사용해 실시간 메모리 사용량을 확인할 수 있습니다. 'Memory footprint'는 DOM 노드와 같은 OS 메모리를 의미하며, 'JavaScript Memory'의 괄호 안 숫자는 연결된(reachable) 객체들이 사용하는 JS 힙(heap)의 크기를 나타내어, 이 수치가 계속 증가하면 누수일 가능성이 높습니다 [6, 7].

**디버깅 및 분석 도구**
*   **Heap Snapshots (힙 스냅샷):** Chrome DevTools의 Memory 패널을 이용해 특정 시점의 메모리 분포를 캡처합니다 [8, 9]. 의심되는 작업을 수행하기 전후로 스냅샷을 찍고 비교(Comparison view)하여 양의 Delta 값을 가지는 객체를 식별할 수 있습니다 [9]. 'Detached' 필터 검색을 통해 DOM 트리에서 분리되었으나 JavaScript 참조로 인해 메모리에 남아있는 노드를 찾을 수 있습니다 [3, 8].
*   **Allocation Timeline (할당 타임라인):** 실시간 메모리 할당 패턴을 분석합니다 [10, 11]. 파란색 막대는 새로운 할당을, 회색 막대는 해제된 메모리를 나타내며, 파란색 막대가 지속적으로 회색으로 변하지 않으면 누수 객체임을 암시합니다 [11].
*   **Performance Recordings:** 시간 경과에 따른 페이지의 메모리 사용량을 시각화하며, 노드 수나 JS 힙 그래프가 우상향하는 패턴을 보일 때 누수를 의심할 수 있습니다 [12, 13].

**주요 발생 패턴**
*   **Detached DOM Nodes:** DOM 문서에서 제거되었으나 JavaScript 내 변수 등에 의해 참조가 유지되어 가비지 컬렉터가 수집하지 못하는 노드입니다 [3, 14].
*   **이벤트 리스너 및 구독 누적:** 컴포넌트 마운트 해제 시 리스너나 옵저버블 구독을 정리(cleanup)하지 않는 경우 발생합니다 (예: React의 `useEffect` 정리 함수 누락, Angular의 구독 해제 누락) [3, 15, 16].
*   **클로저(Closure) 유지:** 클로저가 부모 스코프의 변수를 살려두어 불필요하게 큰 객체 참조가 유지되는 경우 발생합니다 [4].

**예방 전략**
*   데이터 캐싱 시 가비지 컬렉션을 방해하지 않도록 객체 대신 `WeakMap`을 사용합니다 [16].
*   개발 과정 또는 CI 파이프라인에 Puppeteer를 활용한 자동화된 메모리 누수 감지 테스트를 통합합니다 [16].

## ⚖️ Trade-offs & Caveats
*   **메모리 팽창(Bloat)과의 구별:** 애플리케이션 성능이 시간이 지남에 따라 나빠지는 메모리 누수와 달리, 단순히 최적화되지 않아 지속적으로 성능이 나쁜 '메모리 팽창(Memory Bloat)'을 구별해야 합니다 [5]. 이 기준은 기기 성능에 따라 달라지므로, 대상 사용자의 기기 환경을 고려한 측정 기준이 필요합니다 [17].
*   **분석 과정의 복잡성:** 힙 스냅샷을 찍고 분석하는 과정은 로딩 처리에 시간이 소요될 수 있으며, 가비지 컬렉션(GC) 루트로부터의 거리와 Retainer path를 분석하는 것은 원인을 찾는 데 추가적인 학습 곡선이 요구됩니다 [4, 8].
*   **강제 GC의 필요성:** 정확한 메모리 누수 식별 및 패치 후 확인을 위해서는 스냅샷을 캡처하거나 성능 녹화를 시작하기 전후에 반드시 수동으로 강제 가비지 컬렉션(휴지통 아이콘 클릭 등)을 실행하여, 정상적으로 해제된 객체를 누수 데이터에서 배제해야 합니다 [9, 12, 18].

## 🔗 Knowledge Connections

### Related Concepts

#### [분석 및 모니터링 도구]
- [[Chrome DevTools]]
  - 연결 이유: Memory 패널의 Heap Snapshot, Allocation Timeline 등 메모리 누수를 진단하기 위한 핵심 기능을 제공하는 필수 환경입니다 [8-10].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 브라우저 내부에서 객체 메모리가 어떻게 할당되고, GC 루트가 참조를 어떻게 추적하는지에 대한 실제적 디버깅 흐름.

#### [주요 누수 원인/아키텍처]
- [[Detached DOM Nodes]]
  - 연결 이유: DOM 트리에선 제거되었으나 JS 코드에서 참조를 유지해 가비지 컬렉터가 수집하지 못하는, 가장 대표적인 메모리 누수 패턴입니다 [3, 14].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 프런트엔드 애플리케이션(특히 SPA)에서 UI 업데이트 및 컴포넌트 마운트 해제 시 발생하는 메모리 낭비 메커니즘.
- [[Garbage Collection]]
  - 연결 이유: JS는 가비지 컬렉터를 통해 사용되지 않는 메모리를 자동으로 회수하지만, GC 루트(root)에 참조가 남아있으면 이 과정이 방해를 받아 누수가 발생합니다 [1, 4].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: Shallow size와 Retained size의 차이점 및 메모리 관리의 근본적인 한계 [18].

#### [예방 및 캐싱 전략]
- [[WeakMap]]
  - 연결 이유: 캐시를 구현할 때, 강한 참조를 남기지 않아 가비지 컬렉션을 방해하지 않는 이상적인 메모리 관리 기법으로 제시됩니다 [16].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: JavaScript 환경에서 메모리를 안전하게 관리하며 데이터를 캐싱하는 고급 아키텍처 패턴.

### Deeper Research Questions
- Chrome DevTools의 힙 스냅샷(Heap Snapshot)에서 명시되는 Shallow Size와 Retained Size의 정확한 차이점은 무엇이며, 디버깅 과정에서 각각 어떻게 활용되는가?
- React의 `useEffect` 클린업(cleanup) 함수 누락이 프런트엔드에서 메모리 누수를 유발하는 기술적 원리는 무엇이며, 이를 방지하기 위한 프레임워크별 모범 사례는 무엇인가?
- 서버 사이드(Node.js) 애플리케이션에서 발생하는 메모리 누수는 클라이언트 사이드(브라우저) 환경과 비교했을 때 원인 및 디버깅 방법(V8 inspector protocol 활용) 측면에서 어떤 차이가 있는가?
- Puppeteer를 활용한 자동화된 메모리 누수 테스트 스크립트를 CI/CD 파이프라인에 구축할 때 유의해야 할 기술적 제약 사항은 무엇인가?
- 메모리 누수(Memory Leak)와 메모리 팽창(Memory Bloat)을 개발 과정에서 조기에 식별하고 구별하기 위한 가장 정량적이고 신뢰할 수 있는 지표는 무엇인가?

### Practical Application Contexts
- **Implementation:** React, Vue 등의 SPA 프레임워크 개발 시, 컴포넌트가 언마운트되는 시점(`useEffect` return 함수, `beforeUnmount` 등)에 이벤트 리스너와 타이머, 옵저버블 구독을 명시적으로 해제하는 클린업 코드를 작성합니다 [15, 16].
- **System Design:** 장기 실행되는 캐시 시스템 구축 시, 누수로 인한 성능 저하를 방지하기 위해 일반 객체(Object) 대신 `WeakMap`을 도입하여 GC가 정상적으로 이루어지도록 설계합니다 [16].
- **Operation / Maintenance:** 프로덕션 환경의 복잡한 사용자 상호작용 후 성능 저하가 보고되면, Chrome Task Manager와 Performance 탭을 사용해 주기적인 강제 GC 이후에도 우상향하는 'JavaScript Memory' 지표를 확인하는 유지보수 절차를 수립합니다 [6, 7, 12].
- **Learning Path:** Chrome DevTools의 'Memory' 탭에서 스냅샷을 캡처하고 'Comparison' 뷰를 통해 'Delta' 및 'Retained Size'를 분석하는 실습을 거쳐, 메모리 성능 개선의 기초를 다집니다 [9, 18].
- **My Project Relevance:** 모바일이나 저사양 기기에서 사용자들의 대시보드 무한 스크롤 및 화면 전환 중 앱 크래시 현상이 발생할 경우, Detached DOM 또는 쌓여 있는 이벤트 리스너가 있는지 타임라인 프로파일링을 통해 점검해야 합니다 [2, 3, 14].

### Adjacent Topics
- [[Core Web Vitals]]
  - 확장 방향: 메모리 누수로 인해 브라우저의 메인 스레드가 과부하에 걸리거나 가비지 컬렉션이 빈번하게 발생하여 실행을 중단시킬 때, 이것이 INP(Interaction to Next Paint)와 같은 사용자 체감 성능 지표에 어떻게 치명적인 영향을 미치는지 분석합니다.
- [[React Server Components (RSC)]]
  - 확장 방향: 클라이언트 측에 전송되는 JavaScript의 양 자체를 줄이고 상호작용 상태 관리를 서버로 옮김으로써, 브라우저 단의 메모리 누수 및 팽창 위험을 아키텍처 수준에서 어떻게 경감시킬 수 있는지 탐구합니다.

---
*Last updated: 2026-04-30*