---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Memory Leaks|Memory Leaks]]
last_updated: 2026-05-02
---

# [[Memory Leaks|Memory Leaks]]

## 📌 Brief Summary
> Three.js 및 [[WebGL|WebGL]] 환경에서 메모리 누수(Memory Leaks)는 GPU 리소스가 자동으로 가비지 컬렉션([[Garbage Collection|Garbage Collection]])되지 않아 VRAM 등 메모리 사용량이 지속적으로 증가하는 현상을 의미합니다 [1]. 이는 주로 지오메트리, 재질, 텍스처 등의 렌더링 리소스를 코드 상에서 명시적으로 해제하지 않았을 때 발생합니다 [1, 2]. 메모리 누수를 방지하려면 렌더러 정보를 통한 지속적인 모니터링과 올바른 메모리 관리 기법의 적용이 필수적입니다 [2].

---

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

## 📖 Core Content
*   **GPU 리소스의 수동 해제:** Three.js는 GPU 리소스를 자동으로 가비지 컬렉션하지 않기 때문에, 더 이상 사용하지 않는 자원은 반드시 개발자가 직접 **`geometry.dispose()`, `material.dispose()`, `texture.dispose()`, `renderTarget.dispose()`**를 호출하여 해제해야 합니다 [1-3].
*   **GLTF ImageBitmap 특수 처리:** GLTF 모델에서 불러온 텍스처는 `ImageBitmap` 객체로 로드되므로 누수를 막기 위한 추가적인 처리가 필요합니다 [3]. 이러한 텍스처는 일반적인 `dispose()` 외에도 반드시 **`texture.source.data.close?.()`**를 호출하여 명시적으로 닫아주어야 ImageBitmap 객체의 메모리 누수를 막을 수 있습니다 [2, 3].
*   **오브젝트 풀링(Object [[Pooling|Pooling]]) 도입:** 런타임 중 빈번하게 생성되고 파괴되는 오브젝트(예: 총알, 파티클, 적 등)는 메모리 할당 오버헤드와 이로 인한 가비지 컬렉션 지연(GC pauses)을 유발할 수 있습니다 [3]. 이를 방지하기 위해 새로운 객체를 매번 할당하는 대신 기존 객체를 재활용하는 **객체 풀링([[Object Pooling|Object Pooling]])** 패턴을 구현해야 합니다 [2, 3].
*   **메모리 누수 모니터링:** 런타임에 메모리 누수가 발생하고 있는지 확인하려면 **`renderer.info.memory`** 지표를 주기적으로 모니터링해야 합니다 [1, 2]. 해당 지표에서 지오메트리와 텍스처의 카운트가 떨어지지 않고 계속해서 상승하기만 한다면, 명확한 메모리 누수로 판단할 수 있습니다 [1, 2].
*   **에셋 스트리밍(Asset Streaming) 및 메모리 한계:** WebGL 컨텍스트는 제한된 메모리 용량(통상 256MB~1GB)을 지니고 있어 이를 초과하면 브라우저 크래시나 프리징이 발생할 수 있습니다 [4]. 무한한 크기의 씬이라도 카메라에서 100 유닛 이상 멀어진 자원들에 대해 `dispose()`를 호출해 메모리를 해제하는 스트리밍 방식을 적용하면, 활성화된 모델만 메모리에 유지하여 메모리 누수 및 고갈을 방지할 수 있습니다 [5].

---

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

## ⚖️ Trade-offs & Caveats
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.

---

- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 Knowledge Connections
- **Related Topics:** [[Garbage Collection|Garbage Collection]], [[Object Pooling|Object Pooling]], Dispose(), ImageBitmap
- **Projects/Contexts:** Three.js Memory [[Management|Management]], Asset Streaming in WebGL
- **Contradictions/Notes:** 소스 간의 모순점은 발견되지 않았으며, 제공된 소스들은 모두 공통적으로 Three.js 엔진 환경에서 메모리 누수를 방지하기 위해 '사용이 끝난 자원의 명시적 해제(dispose)'가 절대적으로 필요함을 강조하고 있습니다.

---
*Last updated: 2026-04-19*

---

---

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

---
*Last updated: 2026-04-19*

---