05/27 TIL 오브젝트 풀에 관한 고찰

✅ 오늘 배운 것

1. 프리팹이 다르면 풀도 나눠야 한다

• WoodItem, RockItem처럼 ResourceItem을 상속한 클래스가 여러 개 있더라도,
  프리팹(GameObject) 이 다르면 하나의 풀에서 관리하면 안 됨.
• ObjectPool<T>의 createFunc는 단 하나의 프리팹으로 고정되기 때문에
  나중에 다른 프리팹을 넣거나 생성하면 의도하지 않은 결과가 발생함.

2. 풀은 '타입'이 아닌 '프리팹 단위'로 관리

• PoolManager<ResourceItem> 같은 구조에서 한 풀에 여러 종류의 아이템을 넣고 싶을 수 있으나,
  각 프리팹마다 별개의 PoolManager를 생성하는 방식이 안전하고 명확하다.
• 따라서 Dictionary<GameObject, PoolManager<ResourceItem>> 혹은
  Dictionary<string, PoolManager<ResourceItem>> 와 같은 구조를 사용하는 것이 좋다.

3. 프리팹 기준 키로 풀 분기 처리

if (!pools.ContainsKey(prefab)) 
{
 	pools[prefab] = new PoolManager<ResourceItem>(prefab.GetComponent<ResourceItem>(), transform);
}

• 프리팹 기준으로 풀을 만들어두고, 같은 프리팹이면 재사용.
• 다른 프리팹이 들어오면 새로 풀을 만들어 할당.

---

🧩 정리

 

구분	잘못된 예	올바른 예
풀 기준	ResourceItem 타입으로 하나의 풀	프리팹마다 PoolManager 분리
생성 방식	createFunc 하나로 여러 종류 생성	프리팹 기준으로 개별 생성 함수
사용 구조	PoolManager<ResourceItem> 하나로 다 처리	Dictionary<Prefab, PoolManager<ResourceItem>> 사용

 

 

---

🗒️ 느낀 점

• 처음에는 "같은 타입인데 왜 다른 풀로 나눠야 하지?"라고 생각했지만,
  Unity에서 프리팹 = 생성의 기준이기 때문에 풀도 프리팹 단위로 쪼개는 것이 자연스러움.
• 프리팹 별로 풀이 생성되는 측면이 유지/보수 측면에서 더 유리하다.(기능별로  인터페이스를 받거나 상속 구조로 갈 수는 있긴 하다)
• 설계를 미리 고려하지 않으면 풀 구조가 꼬일 수 있기 때문에
  프리팹 ↔ 풀의 관계를 명확히 분리하는 설계가 중요하다는 걸 체감했다.

---

🛠️ 내일 할 일

• SpawnManager 내에서 프리팹 기준으로 풀을 관리하는 구조 완성
• ItemData에 GetPrefab() 같은 접근자를 두어 풀 등록 시 사용하기 쉽게 개선
• 풀 생성과 반환 시 디버깅 로그 추가로 흐름 추적