[내일배움캠프_2025AUG21] 팀 프로젝트 5일차: Interaction 및 병합, 챌린지반 특강

팀 프로젝트 5일차: Interaction 및 병합, 챌린지반 특강

오늘은 어제 정리했던 대로!

플레이어가 아이템을 장착했을 때 손 위치에 생성되도록 하는 것이 목표다.

레이를 쏴서 인게임 아이템을 수확하해야하는 데, 어떤 장비를 장착했느냐에 따라 수확이 되고, 안되고가 나뉘어야 한다.

 

우리 팀의 에이스 한 분이 자리를 비우셔야하는 상황이었기 때문에 시간이 갑자기 부족해졌다.

따라서 처음 설계했던 부분들을 유지하지 못하고, 막무가내 GameManager를 하나 만들고 그를 중심으로.. 구현하게 되었다.

EquipmentController를 만들고, 여기에서 PlayerInteractionController에 현재 장착하고 있는 아이템을 보내주었다.

현재 장착중인 아이템을 관리하는 것인데, 사실 여기서 보내줄 것이 아니라 InventoryManager이 EquipmentModel을 다룰 때 보내줬어야했는데 InventoryManager -> EquipmentController -> PlayerInteractionController 이런식으로 보내게 된다.

어떻게 보면 이게 맞는 것 같기도 하고 아닌 것 같기도 하고... 일단 작동하게 만들겠다는 생각에 고민을 하지 않고 구현한 거라 나중에 시간이 나면 

 

---

챌린지반 특강: 최적화

최적화는 결국 자원(메모리, CPU, GPU, 배터리)을 적게 쓰면서도 같은 성능을 내는 과정

단순히 빠르게 만드는 게 아니라 성능 + 자원 + 경험 세 가지 균형을 맞춰야함

그래서 최적화는 맨 마지막에 땜질하는 것이 아니라 처음 설계 단계부터 고려해야 추후 비용이 안커짐.

모든 걸 최적화할 필요는 없고, Profiler로 병목 구간을 찾아서 집중적으로 고치는 것이 핵심.

 

유니티에서는 Profiler로 CPU/GPU/메모리/렌더링 지표 확인 가능함.

CPU 쪽은 Update이 너무 많거나 GC 자주 돌면 문제가 됨.

GPU 쪽은 Draw Call 과다나 셰이더 복잡도가 문제가 됨.

Memory 탭에서 GC Alloc 확인하면 매 프레임 어디서 메모리 터지고 있는지 바로 알 수 있다.

Frame Debugger 쓰면 왜 드로우 콜이 배칭 안되는 지도 구체적으로 나옴.

 

GC문제는 특히 심각한데, 실행 시험마다 게임이 툭 끊기기 때문에 유저 경험에 치명적임.

문자열 더하기, LINQ, foreach, Intantiate/Destroy 반복 같은 게 대표적인 원인.

그래서 오브젝트 풀링 (Object Pooiling), String Builder, NonAlloc API 쓰는 게 필수.

드로우 콜을 줄이려면 Material 공유, 아틀라스, 배칭/인스턴싱, SRP Batcher 같은 기법을 활용하는 것이 좋음.

 

필요한 계산만, 한번만, 빠르게라는 원칙으로 불필요한 연산/메모리 할당을 줄이는 게 최적화의 본질이다.

---

느낀점

 

 

---

내일 학습 할 것은 무엇인지