# [[Memory Leaks]]

## 📌 Brief Summary
메모리 누수(Memory Leaks)는 애플리케이션이 메모리를 할당한 후, 더 이상 필요하지 않음에도 불구하고 자바스크립트의 가비지 컬렉터(Garbage Collector)가 이를 회수하지 못해 발생하는 현상입니다 [1]. 이는 개발자가 코드 내에서 더 이상 사용하지 않는 객체나 DOM 노드에 대한 참조(Reference)를 해제하지 않을 때 발생하며, 시간이 지남에 따라 애플리케이션의 메모리 사용량이 지속적으로 증가하게 만듭니다 [1, 2]. 결과적으로 사용자 인터페이스가 느려지고, 브라우저 탭이 멈추거나 앱이 강제 종료되는 치명적인 성능 저하를 초래합니다 [2-4].

## 📖 Core 대Content
* **발생 원리 및 주요 패턴:**
  자바스크립트에서 가비지 컬렉터는 남아있는 참조가 없을 때만 메모리를 자동으로 회수합니다 [1]. 최신 자바스크립트 프레임워크 환경에서 메모리 누수를 일으키는 가장 흔한 원인은 다음과 같습니다:
  * **Detached DOM Nodes:** 문서(DOM 트리)에서는 제거되었으나, 자바스크립트 변수에서 계속 참조하고 있어 메모리에서 해제되지 못하는 고아(Orphaned) 노드입니다 [5-7].
  * **이벤트 리스너 누적:** 컴포넌트가 마운트 해제(Unmount)될 때 등록된 이벤트 리스너를 제거하지 않아 지속적으로 축적되는 현상입니다 [7].
  * **클로저(Closure)에 의한 참조:** 클로저가 부모 스코프의 변수를 계속 유지하여 불필요하게 큰 객체들을 메모리에 남겨두는 경우입니다 [8].
  * **React 특화 요인:** `useEffect` 훅(Hook)을 사용할 때 정리(Cleanup) 함수를 반환하지 않아 이벤트 리스너나 구독(Subscription) 자원이 컴포넌트 소멸 후에도 남아있는 경우가 대표적인 원인입니다 [5, 9].

* **증상 및 감지:**
  메모리가 단순히 많이 사용되는 '메모리 블로트(Memory Bloat)'와 달리, 메모리 누수는 일정한 작업 부하 속에서도 메모리 소비가 지속적으로 증가하여 안정되지 않는 특성이 있습니다 [2, 4]. 주요 증상으로는 잦은 가비지 컬렉션으로 인한 스크립트 실행 일시 정지(Jank), 시간이 지날수록 느려지는 성능, 기능 종료 후에도 감소하지 않는 메모리 점유율 등이 있습니다 [2, 4, 10, 11].

* **디버깅 및 프로파일링 방법:**
  * **Chrome Task Manager:** 애플리케이션의 실시간 'JavaScript Memory' 사용량을 모니터링하여 누수 여부의 첫 단서를 잡습니다 [12, 13].
  * **Heap Snapshots (힙 스냅샷):** Chrome DevTools를 이용해 여러 시점의 스냅샷을 찍고 비교(Comparison view)하여 지속적으로 증가하는 객체(Delta 값이 양수)를 찾습니다. 'Detached'를 검색하여 고아 DOM 노드를 찾고, GC 루트로부터 어떤 참조(Retainers)가 객체를 유지하고 있는지 추적합니다 [8, 11, 14, 15].
  * **Allocation Timeline (할당 타임라인):** 실시간으로 메모리 할당 패턴을 파악하여 파란색 막대가 나타난 후 회색으로 변하지 않고 유지되는(메모리가 해제되지 않는) 구간을 확인합니다 [16-18].
  * **Performance Recordings:** 시간에 따른 메모리 사용량을 시각화하며, 강제 가비지 컬렉션을 수행한 후에도 JS 힙(Heap) 크기가 시작 시점보다 높게 유지되면 누수를 의심할 수 있습니다 [19, 20].

* **예방 전략:**
  객체 캐시를 관리할 때는 가비지 컬렉션이 가능한 `WeakMap`을 사용해야 합니다 [21]. 또한 CI 파이프라인에 Puppeteer 등을 활용한 자동화된 메모리 누수 감지 테스트를 통합하고, 각 프레임워크의 생명주기(예: React의 `useEffect` 반환부, Vue의 `beforeUnmount` 등)에 맞는 적절한 정리(Cleanup) 패턴을 준수해야 합니다 [21].

## ⚖️ Trade-offs & Caveats
소스에 관련 정보가 제한적이나, 메모리 누수 최적화 및 디버깅에는 다음과 같은 제약과 개발 리소스 측면의 트레이드오프가 존재합니다:
* **디버깅 복잡성 및 리소스 소모:** Chrome DevTools의 힙 스냅샷 비교와 할당 타임라인 분석은 개발 과정에서 상당한 시간과 체계적인 분석 능력을 요구합니다. 또한 GC 루트로부터의 참조 경로(Retainer Path)를 수동으로 추적해야 하므로 복잡성이 높습니다 [8, 11, 22].
* **자료 구조의 제약:** 메모리 누수를 예방하기 위해 표준 객체(Object) 캐시 대신 `WeakMap`을 사용하면, 참조가 해제될 수 있다는 장점은 있으나 반복(Iteration)이 불가능하고 키(Key)를 객체로만 설정해야 하는 등의 기능적 제약이 따릅니다 [21].
* **프로덕션 환경에서의 비용:** 프로덕션 환경에 도달하기 전 개발 단계에서 정기적으로 메모리를 프로파일링하지 않으면, 프로덕션 단계에서는 진단하기 훨씬 어렵고 수정하는 데 훨씬 더 큰 비용이 발생합니다 [22].

## 🔗 Knowledge Connections

### Related Concepts

#### [분석 및 진단 도구]
- [[Chrome DevTools Memory Profiler]]
  - 연결 이유: 메모리 누수를 감지, 진단, 추적하기 위한 가장 핵심적인 실무 도구입니다 [3, 11].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 힙 스냅샷과 할당 타임라인을 통해 애플리케이션의 메모리 분배 현황을 시각적으로 파악하고, GC(가비지 컬렉터)가 회수하지 못한 객체의 원인을 분석하는 방법을 이해할 수 있습니다 [11, 14, 16].

#### [프론트엔드 아키텍처 및 현상]
- [[Detached DOM Nodes]]
  - 연결 이유: 컴포넌트 기반 UI 개발에서 가장 빈번하게 발생하는 메모리 누수 패턴입니다 [6, 7].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 노드가 DOM 트리에서 제거되었음에도 불구하고 자바스크립트 변수 등에 의한 참조가 남아있어 메모리 누수를 유발하는 원리와 이를 방지하기 위한 참조 해제 방법을 알 수 있습니다 [6, 7, 15].
- [[Garbage Collection]]
  - 연결 이유: 자바스크립트 메모리 누수의 근본 원인은 가비지 컬렉터의 동작 방식(참조가 없어야 메모리 회수)과 직결됩니다 [1, 2].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 메모리가 시스템에 반환되는 시점과 잦은 가비지 컬렉션이 스크립트 실행을 일시 중단시켜(Pause) 렌더링 성능에 미치는 영향을 파악할 수 있습니다 [2, 23].

#### [React 패턴 및 구현]
- [[useEffect Cleanup]]
  - 연결 이유: React 애플리케이션 내에서 구독 해제 및 이벤트 리스너 제거 실패로 인한 메모리 누수를 막는 직접적인 해결책입니다 [5, 9, 21].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 함수형 컴포넌트의 생명주기 관리와 컴포넌트 언마운트 시 부수 효과(Side-effects)를 안전하게 처리하는 메커니즘을 이해할 수 있습니다 [9, 21].

### Deeper Research Questions
- 가비지 컬렉션의 동작 원리와 비교하여, 클로저(Closure)에 의해 참조가 유지되는 메모리 누수는 구체적으로 DevTools의 Retainer 패널에서 어떻게 추적할 수 있는가?
- 캐시 관리에 `WeakMap`을 사용하는 전략이 전통적인 `Map`이나 객체 리터럴을 사용할 때의 메모리 보존 방식과 기술적으로 어떻게 다른가?
- 프로덕션 파이프라인(CI/CD) 환경에서 Puppeteer를 활용하여 메모리 누수를 자동으로 테스트하고 잡아내는 구체적인 구현 방법론은 무엇인가?
- 메모리 블로트(Memory Bloat)와 메모리 누수(Memory Leak)를 구분하기 위해 Chrome Task Manager에서 관찰해야 하는 주요 지표와 패턴은 어떻게 다른가?
- React 이외의 모던 프레임워크(예: Angular의 `takeUntil`, Vue의 `beforeUnmount` 등)에서는 메모리 누수 방지를 위해 어떤 구조적 패턴을 사용하는가?

### Practical Application Contexts
- **Implementation:** React 컴포넌트를 작성할 때, `useEffect` 내에서 설정한 타이머나 외부 라이브러리 이벤트 리스너는 반드시 반환(return) 함수를 통해 해제하여 메모리 누수를 차단해야 합니다 [7, 9, 21].
- **System Design:** 장기 실행되는 SPA 환경에서는 컴포넌트 트리가 자주 변경되므로, 데이터 캐싱 계층 설계 시 `WeakMap`을 도입하여 전역 상태에서 제거된 객체가 자연스럽게 메모리에서 소멸되도록 설계합니다 [21].
- **Operation / Maintenance:** 프로덕션 앱에서 사용자가 장시간 이용 후 '앱이 멈추거나 느려짐'을 보고할 경우, 개발팀은 크롬 개발자 도구의 Performance 탭 및 Memory 패널을 켜서 유저 시나리오를 재현하고 힙 스냅샷 간의 Delta를 비교하여 유지되고 있는 객체(Retained Size)를 디버깅합니다 [2, 11].
- **Learning Path:** 자바스크립트의 참조 및 스코프(Closure) 기초 학습 -> 프레임워크의 생명주기 훅(useEffect 등) 이해 -> Chrome DevTools를 활용한 Memory Profiling 기법 숙달 -> CI 환경에서의 자동화 테스트 구축 단계로 나아갑니다 [9, 11, 21].
- **My Project Relevance:** 현재 진행 중인 React 코드베이스 리팩토링 시, 기존 학생들이 작성한 코드 중 `useEffect`의 반환 함수 누락이나 불필요한 이벤트 리스너 중복 등록을 식별하고 개선하여 앱의 장기적인 구동 안정성을 확보하는 데 필수적인 지식입니다 [9, 24, 25].

### Adjacent Topics
- [[Memory Bloat]]
  - 확장 방향: 메모리 누수처럼 계속 증가하지는 않지만, 초기부터 최적의 페이지 속도를 위해 필요한 수준보다 과도하게 많은 메모리를 사용하는 상태를 진단하고 최적화하는 방법으로 확장이 가능합니다 [2, 10].
- [[Core Web Vitals]]
  - 확장 방향: 잦은 가비지 컬렉션과 메모리 누수로 인해 스크립트 실행이 지연되면서 FID(First Input Delay)나 INP(Interaction to Next Paint) 같은 실제 사용자 체감 성능 지표에 미치는 영향을 심층적으로 분석할 수 있습니다 [23, 26].

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