Unity성능과 프로파일링

불필요한 Unity 메시지 함수 제거

빈 `Update`, `FixedUpdate`, `LateUpdate` 같은 Unity 메시지 함수도 비용이 될 수 있다는 점과, 이벤트·매니저·코루틴 대안을 정리합니다.

마지막 수정 2026년 3월 22일

기본 패턴

text
매 frame 필요 없으면
  -> Update를 만들지 않는다
상태 변화 시에만 필요하면
  -> event / callback
대상이 아주 많으면
  -> 중앙 Update Manager
순차 대기 흐름이면
  -> Coroutine

설명

  • Unity는 MonoBehaviour에 정의된 메시지 함수를 엔진 라이프사이클에 따라 검사하고 호출합니다. 그래서 Update, FixedUpdate, LateUpdate가 실제로 아무 일도 하지 않더라도, 함수가 존재하는 수가 많아질수록 프레임마다 관리해야 할 대상이 늘어납니다.
  • 작은 프로젝트에서는 체감이 약할 수 있지만, 많은 수의 컴포넌트가 붙은 대형 씬이나 수천 개의 에이전트가 있는 구조에서는 이 비용이 무시하기 어렵습니다. 핵심은 "한 함수 호출이 비싸다"보다 "작은 호출 비용이 매우 많이 반복된다"는 데 있습니다.
  • 그래서 사용하지 않는 메시지 함수는 빈 채로 두지 말고 아예 제거하는 편이 좋습니다. 특히 습관처럼 Update 템플릿을 만들어 두고 나중에 쓰지 않는 경우가 누적되면, 코드 가독성과 성능 둘 다 손해를 봅니다.
  • 대안은 문제 성격에 따라 다릅니다. 상태가 바뀔 때만 반응하면 되는 UI나 시스템은 event 기반이 더 낫고, 아주 많은 객체를 갱신해야 하면 Update Manager 같은 중앙 순회 구조가 효과적입니다. 일정 시간 기다렸다가 이어지는 순차 흐름은 Coroutine이 더 읽기 쉬운 경우가 많습니다.
  • FixedUpdateLateUpdate도 "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