Antigravity Agent
35 lines
4.6 KiB
Markdown
35 lines
4.6 KiB
Markdown
---
|
|
id: P-REINFORCE-AUTO-F27A16
|
|
category: "10_Wiki/💡 Topics/Graphics & Performance"
|
|
confidence_score: 0.90
|
|
tags: [auto-reinforced]
|
|
last_reinforced: 2026-04-20
|
|
github_commit: "[P-Reinforce] Continuous Worker - Memory Management"
|
|
---
|
|
|
|
# [[Memory Management|Memory Management]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> 3D 웹 렌더링 및 그래픽스 환경에서 'Memory Management(메모리 관리)'는 시스템의 제한된 RAM과 GPU VRAM을 효율적으로 통제하여 애플리케이션의 크래시, 메모리 누수, 그리고 가비지 컬렉션(GC)으로 인한 프레임 지연을 방지하는 필수적인 최적화 과정입니다 [1, 2]. 이는 불필요한 GPU 자원의 명시적 폐기, 객체 풀링, 버퍼의 사전 할당 및 텍스처 압축 기술을 포괄합니다 [3-6].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
- **명시적 자원 폐기 및 누수 방지:** Three.js와 같은 엔진은 GPU 자원을 자동으로 가비지 컬렉션(GC)하지 않으므로, 사용이 끝난 Geometry, Material, Texture, Render Target은 반드시 명시적으로 폐기(`dispose()`)해야 합니다 [3, 4, 7, 8]. 특히 GLTF 모델에서 불러온 ImageBitmap 텍스처는 `close()`를 호출해야 메모리 누수를 차단할 수 있습니다 [4, 7]. 렌더러의 메모리 지표(`renderer.info.memory`)를 모니터링하여 누수 여부를 지속적으로 확인해야 합니다 [1, 3, 7].
|
|
- **가비지 컬렉션(GC) 부하 최소화:** 런타임 중 빈번하게 생성 및 파괴되는 객체에 대해서는 매번 새로 메모리를 할당하는 대신 객체 풀링(Object Pooling)을 사용하여 할당 오버헤드와 GC로 인한 일시적인 프레임 끊김(Stuttering) 현상을 방지해야 합니다 [2, 4, 7].
|
|
- **동적 버퍼 할당 문제 통제:** 인스턴싱 환경에서 인스턴스 수가 변경될 때 버퍼 용량을 동적으로 확장하게 두면 잦은 메모리 재할당과 가비지 컬렉션 부하를 야기합니다 [2, 5, 9]. 이를 피하기 위해 최대 예상 인스턴스 수에 맞춰 초기 버퍼를 미리 크게 할당(Preallocate)하거나 링 버퍼(Ring Buffer) 구조를 활용하는 것이 권장됩니다 [2, 5].
|
|
- **텍스처 및 지오메트리 압축:** 4K 해상도와 같은 고해상도 텍스처는 하나당 64MB 이상의 VRAM을 소모하며, 기기의 메모리 한계를 초과할 경우 브라우저 크래시를 유발할 수 있습니다 [1, 3, 10]. KTX2나 Basis Universal 같은 GPU 압축 텍스처 포맷을 도입하면 대역폭 및 메모리 사용량을 75% 이상 절감할 수 있으며 [6, 11, 12], 지오메트리 속성 역시 정밀도를 낮춰 양자화(Quantization)함으로써 버퍼 크기를 대폭 줄일 수 있습니다 [13]. 텍스처는 한 번만 로드하여 캐시한 뒤 여러 곳에서 재사용해야 합니다 [4, 14].
|
|
- **멀티스레딩 환경의 메모리 최적화:** Electron과 같은 환경에서 대규모 CAD 모델을 로드할 때 메인 스레드와 워커 간의 메시지 전달(Structured Cloning)은 메모리 사용량을 두 배로 폭증시킬 위험이 있습니다 [15]. 이를 방지하기 위해 `SharedArrayBuffer`를 활용하여 메모리 복사 없이(Zero-copy) 데이터를 공유하는 아키텍처를 도입해야 합니다 [15, 16].
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[Garbage Collection|Garbage Collection]], [[Object Pooling|Object Pooling]], [[Texture Compression|Texture Compression]], [[GPU Resources|GPU Resources]], [[Buffer Allocation|Buffer Allocation]]
|
|
- **Projects/Contexts:** [[Three.js|Three.js]], [[WebGL|WebGL]], [[Electron|Electron]], [[Needle Engine|Needle Engine]]
|
|
- **Contradictions/Notes:** 웹 기반 프론트엔드 개발에서는 자바스크립트의 자동 메모리 관리에 의존하기 쉬우나, 소스에 따르면 WebGL과 같은 GPU 자원은 가비지 컬렉터의 대상이 아니므로 개발자가 수동으로 자원 해제를 관리해야만 크래시와 누수를 막을 수 있다고 강력히 지적합니다 [3, 7, 17]. 또한, 드로우 콜을 줄이는 인스턴싱 기법이 성능에 유리해 보이지만, 동적으로 크기가 늘어나는 버퍼를 방치할 경우 오히려 심각한 가비지 컬렉션 병목을 초래해 전체 성능을 깎아먹을 수 있음을 경고합니다 [2, 9].
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
- Raw Source: 00_Raw/2026-04-20/Memory Management.md
|
|
---
|