Antigravity Agent
9.0 KiB
9.0 KiB
category, tags, title, last_updated
| category | tags | title | last_updated | ||||
|---|---|---|---|---|---|---|---|
| Unified |
|
|
2026-05-02 |
Memory Leaks
📌 Brief Summary
Three.js 및 WebGL 환경에서 메모리 누수(Memory Leaks)는 GPU 리소스가 자동으로 가비지 컬렉션(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) 도입: 런타임 중 빈번하게 생성되고 파괴되는 오브젝트(예: 총알, 파티클, 적 등)는 메모리 할당 오버헤드와 이로 인한 가비지 컬렉션 지연(GC pauses)을 유발할 수 있습니다 [3]. 이를 방지하기 위해 새로운 객체를 매번 할당하는 대신 기존 객체를 재활용하는 객체 풀링(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' 영역 사용량이 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].
- 이벤트 리스너 및 타이머 축적: 렌더링 주기나 인터벌 콜백에서 추가된 리스너 및 타이머(setInterval 등)를 적절히 제거하지 않으면, 해당 콜백의 클로저와 참조된 객체들이 무기한 메모리에 남게 된다 [11-14]. Node.js 환경에서 단일 이벤트에 10개 이상의 리스너가 추가될 때 발생하는
- 진단 및 프로파일링 도구:
- 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].
⚖️ Trade-offs & Caveats
- 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- 정책 변화: Graphics & Performance 분야의 자동 자산화 수행.
- 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- 정책 변화: Programming & Language 분야의 자동 자산화 수행.
🔗 Knowledge Connections
- Related Topics: Garbage Collection, Object Pooling, Dispose(), ImageBitmap
- Projects/Contexts: Three.js Memory Management, Asset Streaming in WebGL
- Contradictions/Notes: 소스 간의 모순점은 발견되지 않았으며, 제공된 소스들은 모두 공통적으로 Three.js 엔진 환경에서 메모리 누수를 방지하기 위해 '사용이 끝난 자원의 명시적 해제(dispose)'가 절대적으로 필요함을 강조하고 있습니다.
Last updated: 2026-04-19
- Related Topics: 가비지 컬렉션(Garbage Collection), V8 Heap Architecture, 힙 스냅샷(Heap Snapshot), 클로저(Closure)
- Projects/Contexts: Node.js Memory Leaks in Production, Browser Memory Leak Detection
- Contradictions/Notes: C/C++ 프로그램 등에 사용되는 컴파일러 지원이 없는 보수적(Conservative) 가비지 컬렉터의 경우, 포인터처럼 보이는 일반 정수 데이터로 인해 거대한 객체 서브그래프가 유지되는 독특한 형태의 메모리 누수를 유발할 가능성이 존재한다고 소스에서 지적한다 [32]. 또한 프론트엔드 최신 도구인
WeakRef와FinalizationRegistry를 사용해 누수에 강한 패턴을 작성할 수 있으나, 가비지 컬렉터는 자체 일정에 따라 실행되어 결정론적이지 않으므로 적절한 객체 수명 주기 관리를 완벽히 대체할 수는 없음에 유의해야 한다 [12].
Last updated: 2026-04-19