기본 패턴
text
매 frame 필요 없으면
-> Update를 만들지 않는다
상태 변화 시에만 필요하면
-> event / callback
대상이 아주 많으면
-> 중앙 Update Manager
순차 대기 흐름이면
-> Coroutine설명
- Unity는
MonoBehaviour에 정의된 메시지 함수를 엔진 라이프사이클에 따라 검사하고 호출합니다. 그래서Update,FixedUpdate,LateUpdate가 실제로 아무 일도 하지 않더라도, 함수가 존재하는 수가 많아질수록 프레임마다 관리해야 할 대상이 늘어납니다. - 작은 프로젝트에서는 체감이 약할 수 있지만, 많은 수의 컴포넌트가 붙은 대형 씬이나 수천 개의 에이전트가 있는 구조에서는 이 비용이 무시하기 어렵습니다. 핵심은 "한 함수 호출이 비싸다"보다 "작은 호출 비용이 매우 많이 반복된다"는 데 있습니다.
- 그래서 사용하지 않는 메시지 함수는 빈 채로 두지 말고 아예 제거하는 편이 좋습니다. 특히 습관처럼
Update템플릿을 만들어 두고 나중에 쓰지 않는 경우가 누적되면, 코드 가독성과 성능 둘 다 손해를 봅니다. - 대안은 문제 성격에 따라 다릅니다. 상태가 바뀔 때만 반응하면 되는 UI나 시스템은 event 기반이 더 낫고, 아주 많은 객체를 갱신해야 하면
Update Manager같은 중앙 순회 구조가 효과적입니다. 일정 시간 기다렸다가 이어지는 순차 흐름은Coroutine이 더 읽기 쉬운 경우가 많습니다. FixedUpdate와LateUpdate도 "Update를 줄이기 위한 대체재"로 막 쓰는 것이 아니라, 물리 타임스텝과 후처리 보정이라는 정확한 역할이 있을 때만 써야 합니다. 메시지 함수 선택은 문법 취향이 아니라 호출 빈도와 책임 분리의 문제입니다.
짧은 예제
csharp
public sealed class HealthBar : MonoBehaviour
{
private void OnEnable()
{
health.Changed += Refresh;
}
private void OnDisable()
{
health.Changed -= Refresh;
}
}빠른 정리
| 상황 | 더 나은 선택 |
|---|---|
| 매 frame 계속 관측해야 함 | Update |
| 물리 step에 맞춰야 함 | FixedUpdate |
| 다른 이동 뒤 최종 보정 | LateUpdate |
| 상태 변화 때만 반응 | event / callback |
| 순차 대기 흐름 | Coroutine |
| 수많은 대상 갱신 | 중앙 Update Manager |
주의할 점
Update를 제거한다고 해서 무조건 빨라지는 것은 아니고, event나 manager로 옮겼다고 자동으로 좋은 구조가 되는 것도 아닙니다.
중요한 것은 "매 frame 정말 필요한가"를 먼저 묻고, 빈 메시지 함수와 습관적 polling을 쌓아두지 않는 것입니다.
참고 링크
3 sources