반응형

게임을 개발하다 보면 어느 순간부터 프레임이 터지는 순간이 온다.
하지만 이게 GPU 때문인지, CPU 때문인지, 메모리 문제인지 쉽게 판단하긴 어렵다.
정답은 없다. 대신 "가장 자주 문제를 일으키는 순서"는 있다.
1. UI – Canvas Rebuild & 드로우콜 폭발
- Unity UI 시스템은 Canvas 단위로 갱신되며,
UI 하나만 바뀌어도 전체를 다시 그리는 구조가 될 수 있다 - 특히 Canvas 안에 LayoutGroup, ContentSizeFitter, Mask가 중첩되어 있으면
수천 단위 드로우콜이 발생하고도 모르고 지나치는 경우가 많다
게임이 무거워졌는데, 화면에 뭔가 새로 뜨기만 해도 버벅인다면 UI부터 본다
2. GC Alloc – 프레임마다 생기는 힙 메모리
- Update()에서 new 연산, string.Format, LINQ, foreach 같은 구문이
매 프레임마다 힙 메모리를 생성 → 결국 GC가 개입하면서 끊김 발생 - 특히 모바일 게임은 0.1MB만 할당돼도 체감이 온다
Profiler → CPU Usage → GC Alloc 탭만 켜봐도 바로 보인다
3. FixedUpdate + 물리 시스템 오남용
- FixedUpdate()는 물리 프레임 기준으로 계속 돌기 때문에
여기에 무거운 연산 넣으면 프레임 간섭 발생 - 물리 연산이 필요 없는 상황에서도 Rigidbody, Collider 등을 붙여두는 경우 많다
의도 없는 Rigidbody는 지우는 게 성능에 도움 된다
4. 오브젝트 풀 없이 Instantiate 반복
- 게임에서 계속 Instantiate()로 생성하고 Destroy()로 삭제하면
내부적으로 메모리 단편화 + GC + CPU 낭비가 누적된다 - 특히 이펙트나 총알처럼 반복적으로 쓰는 오브젝트일수록
오브젝트 풀링 시스템으로 관리하는 게 기본이다
풀링이 무조건 정답은 아니지만, 반복 생성/삭제에는 필수다
5. 타이머/코루틴 오남용
- 코루틴을 너무 많이 쓰면 StartCoroutine 자체보다
종료 조건 관리, 동시 실행 제어, Nested Coroutine에서 병목 생긴다 - 모든 상태 관리를 코루틴으로만 처리하려는 구조는 유지보수도 어렵고 느려지기 쉬움
코루틴은 ‘흐름용’이지 ‘로직 반복’용이 아니다
6. 렌더링 – 다중 카메라 / 투명 오브젝트 / 그림자 과다
- 3D 게임에서는
- 카메라 여러 개
- 투명 쉐이더(반투명 UI 포함)
- 실시간 그림자
이 3가지가 렌더링 비용의 주범이다
씬이 무거워졌다면, 히어로보다 그림자가 문제일 수 있다
어디부터 의심할까?
| 1 | UI | Canvas 재빌드, 드로우콜 수, Layout 사용 여부 |
| 2 | GC | GC Alloc 발생량, string/foreach 남용 여부 |
| 3 | 물리 | Rigidbody, Collider, FixedUpdate 내용 |
| 4 | Instantiate | 풀링 여부, 생성/삭제 반복 구조 |
| 5 | 코루틴 | 상태 로직 대체 여부, 관리 난이도 |
| 6 | 렌더링 | 그림자, 투명 UI, 카메라 개수 |
반응형
'겜언니의 게임개발' 카테고리의 다른 글
| 이펙트 최적화는 누구의 역할인가? (1) | 2025.06.25 |
|---|---|
| 리팩토링이 진짜로 필요한 순간은 ? (4) | 2025.06.25 |
| GC도 없고 코드도 가벼운데 왜 끊기지? – 보이지 않는 병목들 (0) | 2025.06.24 |
| 오브젝트 풀링 == 성능 최적화? (0) | 2025.06.24 |
| 플레이어 이동이 밀리고 끊겨 보여요! (0) | 2025.06.23 |