62 lines
5.6 KiB
Markdown
62 lines
5.6 KiB
Markdown
---
|
|
category: Unified
|
|
tags: [auto-consolidated, technical-documentation]
|
|
title: [[Object Pooling (오브젝트 풀링)|Object [[Pooling]] (오브젝트 풀링)]]
|
|
last_updated: 2026-05-02
|
|
---
|
|
|
|
# [[Object Pooling (오브젝트 풀링)|Object [[Pooling]] (오브젝트 풀링)]]
|
|
|
|
## 📌 Brief Summary
|
|
> "빌려 쓰고 다시 채우는 자원 관리: 가비지 컬렉터(GC)의 습격으로부터 프레임워크를 보호하기 위해, 객체를 파괴하지 않고 재사용 창고에 보관하는 최적화의 기본형."
|
|
|
|
---
|
|
|
|
> Object Pooling(오브젝트 풀링)은 총알, 파티클, 적 캐릭터와 같이 런타임 중 빈번하게 생성되고 파괴되는 개체들의 성능을 최적화하기 위해 사용되는 메모리 관리 기법입니다 [1]. 매번 새로운 객체를 메모리에 할당하는 대신, 사전에 생성해 둔 객체들의 풀(Pool)을 구축하여 이를 재사용하는 방식으로 동작합니다 [1]. 이를 통해 애플리케이션 실행 중 발생하는 메모리 할당 오버헤드와 가비지 컬렉션([[Garbage Collection|Garbage Collection]], GC)으로 인한 프레임 멈춤 현상을 효과적으로 방지할 수 있습니다 [1, 2]. 대규모 3D 씬과 동적인 렌더링 환경에서는 안정적인 메모리 제어와 누수 방지를 위해 객체 풀링 전략을 사전에 수립하는 것이 필수적입니다 [3, 4].
|
|
|
|
## 📖 Core Content
|
|
오브젝트 풀링([[Object Pooling|Object Pooling]])은 빈번하게 생성되고 파괴되는 객체(총알, 파티클, 적 유닛 등)를 메모리 할당/해제 과정 없이 미리 생성해 둔 목록에서 꺼내 쓰는 기법입니다.
|
|
|
|
1. **동작 매커니즘**:
|
|
* **In-use List / Pool List**: 현재 화면에 표시되는 객체와 대기 중인 객체를 분리 관리.
|
|
* **Get/Release**: 필요할 때 풀에서 꺼내 활성화(Reset & Reactivate)하고, 필요 없어지면 파괴하는 대신 다시 풀로 반환(Deactivate).
|
|
2. **이점**:
|
|
* **GC Spike 방지**: C#이나 Java 같은 환경에서 빈번한 메모리 해제로 인한 '프레임 드랍' 예방.
|
|
* **할당 오버헤드 감소**: 런타임 중의 힙(Heap) 메모리 파편화 방지.
|
|
3. **설계 시 고려사항**:
|
|
* **Pre-warming**: 로딩 중에 필요한 객체를 미리 생성하여 런타임 지연 방지.
|
|
* **Over-allocation**: 풀이 부족할 때 동적으로 확장할 것인지, 아니면 생성을 포기할 것인지에 대한 전략 필요.
|
|
|
|
---
|
|
|
|
- **가비지 컬렉션(GC) 부하 및 오버헤드 방지:** 객체의 지속적인 생성과 소멸은 가비지 컬렉터를 잦게 작동시켜 시스템에 부하를 줍니다. 객체 풀링을 도입하면 빈번하게 사용되는 리소스를 재사용하므로, 메모리 할당 오버헤드와 GC에 의한 일시 정지(Pauses)를 피할 수 있습니다 [1].
|
|
- **프리워밍(Pre-warming) 전략:** 런타임에 객체를 할당할 때 생기는 갑작스러운 성능 저하(Allocation spike)를 피하기 위해, 애플리케이션 로딩 단계에서 풀을 미리 생성하고 데워두는(Pre-warm) 방식이 강력히 권장됩니다 [1].
|
|
- **메모리 누수([[memory|memory]] Leak) 관리:** Three.js와 같은 3D 그래픽스 환경에서 메모리 누수를 처리하는 핵심 지침 중 하나는, 수명이 짧고 빈번히 등장하는 리소스들에 대해 자원 풀링(Resource pooling)을 구현하여 메모리 할당을 통제하는 것입니다 [3].
|
|
- **메쉬 재활용(Recycling Meshes)을 통한 CPU 최적화:** 한 번에 너무 많은 메쉬를 처리해야 할 때, 논리적인 데이터 맵을 사용하여 객체의 상태를 추적하고, 화면에 보이는 객체만을 '사전 빌드된 메쉬 풀(pool of pre-built meshes)'을 이용해 렌더링함으로써 CPU 부담을 크게 낮출 수 있습니다 [2].
|
|
- **대규모 메모리 대역폭 제어:** 동적인 환경에서 인스턴스 버퍼가 한계를 초과하여 재할당되는 일이 잦아지면 치명적인 GC 부하가 발생합니다. 이를 방지하기 위해 엄격한 메모리 예산 설정과 함께 객체 풀링 전략이 사전에 철저히 수립되어야 합니다 [4].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
- **과거 데이터와의 충돌**: 과거에는 메모리가 부족하여 무조건 풀링을 썼으나, 현대의 개선된 GC(Incremental GC 등) 환경에서는 작고 수명이 짧은 객체는 오히려 풀링 관리 비용이 더 클 수 있으므로 '프로파일링 후 도입'이 원칙임.
|
|
- **정책 변화(RL Update)**: [[Unity|Unity]] 2021+ 이후 엔진 자체적으로 `UnityEngine.Pool` API를 제공함에 따라, 개발자가 직접 바퀴를 재발명하지 않고 표준화된 풀링 인터페이스를 사용하는 정책이 권고됨.
|
|
|
|
---
|
|
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 Knowledge Connections
|
|
- **Related**: Graphics & Performance, Memory &[[_system|system]]s, [[Game-Feel-and-Juiciness|Game-Feel-and-Juiciness]], Design Patterns
|
|
- **Modern Tech/Tools**: Unity ObjectPool API, Entitas (ECS Framework).
|
|
---
|
|
|
|
---
|
|
|
|
- **Related Topics:** [[Memory Management|Memory Management]], Garbage Collection, [[Memory Leaks|Memory Leaks]]
|
|
- **Projects/Contexts:** Three.js, Babylon.js
|
|
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (주어진 소스 내에서 오브젝트 풀링의 효과나 방식에 대해 상충하는 의견은 존재하지 않으며, 모두 성능 최적화를 위해 적극적으로 권장하고 있습니다.)
|
|
|
|
---
|
|
*Last updated: 2026-04-19*
|
|
|
|
---
|