Unity 엔진 핵심 (3) - Unity 실행 순서 - soo:bak

작성일 :

매 프레임 코드가 실행되는 순서

Unity 엔진 핵심 (2) - Transform 계층과 씬 그래프에서 Transform의 부모-자식 관계, 좌표 변환 전파, 변경 비용을 다루었습니다.


Unity의 MonoBehaviour는 Awake, Start, Update, FixedUpdate, LateUpdate 등 다양한 콜백을 제공합니다. 하나의 프레임 안에서 물리 시뮬레이션, 입력 처리, 게임 로직, 애니메이션, 렌더링이 정해진 순서로 수행되며, 각 콜백은 이 과정의 특정 시점에서 호출됩니다.

카메라 추적과 캐릭터 이동을 모두 Update에서 처리하면, 카메라가 캐릭터보다 먼저 실행되어 캐릭터가 아직 이동하기 전의 위치를 따라가는 현상이 생길 수 있습니다. 입력을 FixedUpdate에서 읽으면, FixedUpdate가 해당 프레임에서 호출되지 않는 경우 입력이 아예 누락됩니다.


이 글에서는 Unity가 매 프레임 이런 작업들을 어떤 순서로 수행하는지 정리합니다. Awake부터 렌더링까지, 모든 콜백의 호출 시점과 순서를 다룹니다. 실행 순서를 이해해야 로직을 올바른 콜백에 배치할 수 있고, 콜백 간 의존 관계에서 발생하는 타이밍 버그를 방지할 수 있습니다.

초기화 단계

Awake

씬이 로드되거나 Instantiate()로 오브젝트가 생성되면, 해당 오브젝트에 부착된 모든 MonoBehaviour의 Awake()가 호출됩니다.


Awake는 자기 자신의 초기화에 사용합니다. Unity 엔진 핵심 (1)에서 다룬 GetComponent 캐싱이 대표적입니다.


1
2
3
4
5
6
7
8
9

// Awake에서 수행하는 작업
void Awake() {
    _rb = GetComponent<Rigidbody>();       // 자기 컴포넌트 캐싱
    _health = maxHealth;                    // 내부 변수 초기화
    _moveDirection = Vector3.zero;          // 상태 초기화
}

// → 자기 자신에 대한 설정만 수행
// → 다른 오브젝트를 참조하지 않음

개별 오브젝트 내에서는 Awake → OnEnable 순서가 보장되지만, 오브젝트 간의 호출 순서는 비결정적입니다. 오브젝트 A의 Awake가 호출되는 시점에 오브젝트 B의 Awake가 이미 완료되었을 수도 있고, 아직 호출되지 않았을 수도 있습니다.

따라서 Awake에서 다른 오브젝트의 컴포넌트를 참조하면, 참조 대상이 아직 초기화되지 않은 상태일 수 있습니다. 이 문제를 피하기 위해 다른 오브젝트에 대한 참조는 Start에서 수행합니다. Start는 모든 오브젝트의 Awake가 완료된 후에 호출되므로, 참조 대상의 초기화가 이미 끝난 상태가 보장됩니다.


Awake는 GameObject가 씬 계층 전체에서 활성 상태(activeInHierarchy가 true)일 때만 호출됩니다. activeSelf가 true여도 부모가 비활성이면 activeInHierarchy는 false이므로 Awake가 실행되지 않습니다. 씬 로드 시점에 비활성 상태였던 GameObject는, SetActive(true)로 처음 활성화되는 시점에 Awake가 실행됩니다.


한편, MonoBehaviour의 enabled와 GameObject의 활성 상태는 별개입니다. enabled가 false인 경우에도 Awake는 정상적으로 호출됩니다. 다만 enabled가 false인 동안에는 Start, Update, FixedUpdate, LateUpdate 등의 콜백이 호출되지 않습니다. 이후 enabled를 true로 변경하면, 해당 스크립트의 첫 번째 Update 직전에 Start가 호출됩니다.

OnEnable

Awake가 자기 자신의 1회 초기화라면, OnEnable()은 활성화될 때마다 반복 호출되는 콜백입니다. Awake 직후에 오브젝트가 활성 상태이면 OnEnable이 바로 실행됩니다. 이후에도 SetActive(true)나 enabled = true로 다시 활성화할 때마다 OnEnable이 호출됩니다.


Awake와 OnEnable의 호출 패턴 최초 활성화 Awake OnEnable Start 첫 프레임의 Update 직전 비활성화 후 재활성화 OnEnable Start 호출되지 않음 → Start는 오브젝트 생애 동안 한 번만 호출


OnEnable()은 이벤트 구독(특정 이벤트 발생 시 호출될 함수를 등록하는 것), 리소스 연결 등 활성화 시마다 필요한 설정에 사용합니다. 반대로 OnDisable()은 비활성화 시마다 호출되며, 이벤트 해제와 리소스 해제를 담당합니다.

Start

Start()는 해당 스크립트의 첫 번째 Update가 호출되기 직전, 한 번만 호출됩니다. 씬 로드 시점에 존재하는 오브젝트들의 경우, 모든 오브젝트의 Awake와 OnEnable이 완료된 후에 Start가 호출됩니다.


Instantiate()로 런타임에 생성된 오브젝트는 생성 즉시 Awake와 OnEnable이 호출되고, 해당 오브젝트의 첫 번째 Update 직전에 Start가 호출됩니다. 씬 로드 시점과 달리, 런타임 생성 오브젝트의 Awake는 Instantiate() 호출 시점에 즉시 실행되므로, 이미 진행 중인 프레임의 다른 오브젝트들과 초기화 순서가 겹칠 수 있습니다. 예를 들어, 오브젝트 A의 Update에서 Instantiate()를 호출하면, 새 오브젝트의 Awake는 Update 단계 도중에 실행됩니다. 씬 로드 시점처럼 모든 Awake가 먼저 완료되는 구조가 아니므로, 초기화 타이밍에 주의해야 합니다.


Awake와 Start의 역할 분리 Awake 자기 자신 초기화 GetComponent 캐싱, 내부 변수 설정 Start 다른 오브젝트 참조 다른 오브젝트의 컴포넌트 접근, 다른 매니저의 초기화 결과 사용 호출 순서 (씬 로드 시점 오브젝트) 오브젝트별로 Awake → OnEnable 쌍이 순차 실행 (A: Awake → OnEnable → B: Awake → OnEnable → ...) 모든 오브젝트의 Awake/OnEnable 완료 첫 프레임 시작 Start (첫 Update 직전에 한 번) Update → 개별 오브젝트 내에서는 Awake → OnEnable 순서가 보장됨 → 오브젝트 간 순서는 비결정적 (A의 OnEnable이 B의 Awake보다 먼저 실행될 수 있음) → 모든 Awake/OnEnable이 끝난 후에야 Start가 호출됨


Awake에서 자기 참조를 설정하고, Start에서 다른 오브젝트의 Awake 결과를 참조하는 패턴을 따르면 초기화 순서로 인한 null 참조 문제를 피할 수 있습니다.

비활성화 후 재활성화해도 Start는 재호출되지 않으므로, 재활성화 시마다 필요한 초기화 로직은 OnEnable에 작성하는 것이 적절합니다.

물리 루프

FixedUpdate

초기화 단계가 끝나면 매 프레임 반복되는 루프에 진입합니다. 이 루프의 첫 번째 단계가 물리 루프입니다.


FixedUpdate()는 고정된 시간 간격으로 호출됩니다. 기본값은 0.02초(50Hz)이며, Project Settings > Time > Fixed Timestep에서 변경할 수 있습니다.


FixedUpdate의 호출 패턴 (Fixed Timestep = 20ms) 시간 프레임 1 16.6ms FixedUpdate ×0 Update ×1 프레임 2 16.6ms FixedUpdate ×1 Update ×1 프레임 3 50ms (프레임 드롭) FixedUpdate ×3 Update ×1 누적 시간 계산 프레임 1 : 0 + 16.6 = 16.6ms < 20ms → 호출 0회 프레임 2 : 16.6 + 16.6 = 33.2ms ≥ 20ms → 1회 호출, 잔여 13.2ms 프레임 3 : 13.2 + 50 = 63.2ms ≥ 20ms × 3 → 3회 호출, 잔여 3.2ms FixedUpdate는 누적된 물리 시간에 따라 0~N회 호출 Update는 프레임당 정확히 1회

FixedUpdate의 호출 횟수는 프레임 시간에 따라 달라집니다. Unity는 내부적으로 경과한 물리 시간을 누적하여 추적합니다. 매 프레임 시작 시 이전 프레임의 경과 시간이 이 누적 시간에 더해집니다. 누적 시간이 Fixed Timestep 이상이면 FixedUpdate를 호출하고 Fixed Timestep만큼 차감하며, 누적 시간이 Fixed Timestep 미만이 될 때까지 이 과정을 반복합니다.


FixedUpdate에서는 물리 관련 로직을 처리합니다. Rigidbody에 힘을 가하거나(AddForce), 속도를 설정하거나(velocity), 물리적 이동(MovePosition)을 수행합니다. 물리 연산을 고정 간격으로 실행하면 시뮬레이션 결과가 프레임률에 의존하지 않고 일정하게 유지됩니다. 게임 루프의 원리 (1) - 프레임의 구조에서 고정 타임스텝과 가변 타임스텝의 원리를 다룹니다.

물리 시뮬레이션과 충돌 콜백

FixedUpdate가 호출된 후, Unity의 물리 엔진이 시뮬레이션 단계를 수행합니다. 모든 Rigidbody의 위치와 속도가 갱신되고, Collider 간의 충돌이 검사됩니다. 충돌이 감지되면 해당 콜백이 호출됩니다.


물리 루프의 세부 순서 FixedUpdate() 물리 시뮬레이션 (Physics.Simulate) Rigidbody 위치/속도 갱신 Collider 간 충돌 검사 충돌 콜백 호출 콜백 시점 OnCollisionEnter() 충돌 시작 OnCollisionStay() 충돌 지속 OnCollisionExit() 충돌 종료 OnTriggerEnter() 트리거 진입 OnTriggerStay() 트리거 체류 OnTriggerExit() 트리거 이탈


충돌 콜백은 물리 시뮬레이션 이후에 호출되므로, 콜백 안에서 읽는 Rigidbody의 위치와 속도는 물리 엔진(3D는 PhysX, 2D는 Box2D)이 힘, 중력, 충돌을 모두 계산한 뒤의 최종값입니다.

입력 처리 시점

물리 루프가 끝나면 Update가 호출되기 전에 OnMouseDown() 같은 입력 이벤트 콜백이 호출됩니다. Input.GetKeyDown() 같은 폴링 함수는 Update에서 직접 호출하여 읽습니다.


입력 이벤트의 처리 시점 FixedUpdate (0~N회) 물리 시뮬레이션 + 충돌 콜백 입력 이벤트 OnMouseDown(), OnMouseUp(), OnMouseOver() 등 Input.GetKeyDown(), Input.GetAxis() 등은 Update에서 읽는 것이 일반적 Update


OnMouseDown() 같은 마우스 이벤트 콜백은 Update 이전에 호출됩니다. Input.GetKeyDown(), Input.GetAxis() 같은 입력 조회 함수는 이벤트 발생 시 자동으로 호출되는 콜백이 아니라, 호출할 때마다 현재 상태를 확인하는 폴링(Polling) 방식입니다. 따라서 Update에서 매 프레임 호출하여 입력 상태를 확인합니다.


입력 처리를 FixedUpdate에서 수행하면 문제가 생깁니다. Input.GetKeyDown()은 키가 눌린 프레임에서만 true를 반환합니다. FixedUpdate가 해당 프레임에서 0회 호출되면 입력을 읽는 코드 자체가 실행되지 않으므로, 그 입력은 사라집니다. 반대로 FixedUpdate가 2회 호출되면 같은 입력을 2번 처리합니다. 따라서 입력 감지는 프레임당 정확히 1회 호출되는 Update에서, 물리적 반응(힘 적용 등)은 FixedUpdate에서 수행하는 것이 일반적인 분리 패턴입니다.


New Input System

위 내용은 Legacy Input Manager(UnityEngine.Input) 기준입니다. Unity 6에서는 New Input System(UnityEngine.InputSystem 패키지)도 함께 지원됩니다. 두 시스템은 입력을 읽는 방식 자체가 다릅니다.


Legacy Input Manager는 폴링 방식입니다. Update에서 매 프레임 Input.GetKeyDown()을 호출하여 현재 상태를 확인합니다. New Input System은 이벤트 기반입니다. InputAction을 정의하고 performed, started, canceled 콜백을 등록하면, 입력이 발생할 때 콜백이 자동으로 호출됩니다.


1
2
3
4
5
6

// Legacy Input Manager — 폴링 방식

void Update() {
    if (Input.GetKeyDown(KeyCode.Space))  // 매 프레임 상태를 직접 확인
        Jump();
}

1
2
3
4
5
6

// New Input System — 이벤트 방식

void OnEnable() {
    jumpAction.performed += ctx => Jump();  // 콜백 등록
    jumpAction.Enable();
}


프레임 루프 내 처리 시점은 New Input System의 Update Mode 설정에 따라 달라집니다.


New Input System — Update Mode별 처리 시점 Dynamic Update (기본값) FixedUpdate (0~N회) 물리 시뮬레이션 InputSystem 갱신 + 콜백 → 여기서 performed 등 호출 Update Fixed Update InputSystem 갱신 + 콜백 → FixedUpdate 직전에 처리 FixedUpdate (0~N회) 물리 시뮬레이션 Update


기본값인 Dynamic Update 모드는 Legacy Input Manager와 같은 시점, 즉 Update 직전에 입력 상태를 갱신하고 콜백을 호출합니다.


Fixed Update 모드는 FixedUpdate 직전에 입력을 처리합니다. 물리 기반 캐릭터 컨트롤러처럼 힘 적용과 입력 감지를 같은 타이밍에 수행해야 할 때 적합합니다.

앞서 Legacy Input Manager에서는 FixedUpdate 호출 횟수가 프레임마다 달라, Input.GetKeyDown()을 FixedUpdate에서 읽으면 입력이 누락되거나 중복 처리되는 문제가 있었습니다.

New Input System의 Fixed Update 모드는 이벤트 버퍼링으로 이 문제를 해결합니다. 입력 이벤트를 즉시 처리하지 않고 내부 버퍼에 쌓아 둔 뒤, 각 FixedUpdate 직전에 해당 시간 구간의 이벤트만 꺼내 전달하는 방식입니다. FixedUpdate가 한 프레임에서 몇 번 호출되든 각 호출이 자기 시간 구간의 입력만 받으므로, 누락이나 중복이 발생하지 않습니다.

Update

Update()는 입력 이벤트 처리 이후, 매 프레임 정확히 한 번 호출됩니다. 게임 로직의 핵심이 실행되는 콜백입니다. 캐릭터 이동(물리 기반이 아닌), 입력 확인, 게임 상태 갱신, AI 판단 등 대부분의 게임 로직이 Update에서 수행됩니다.


1
2
3
4
5
6
7
8
9
10
11
12
13

// Update에서 수행하는 일반적인 작업

void Update() {
    // 입력 확인
    float h = Input.GetAxis("Horizontal");
    float v = Input.GetAxis("Vertical");

    // 이동 방향 계산
    Vector3 dir = new Vector3(h, 0, v);

    // Time.deltaTime으로 프레임 독립적 이동
    transform.Translate(dir * speed * Time.deltaTime);
}

Time.deltaTime

Update는 프레임마다 호출되지만, 프레임 간 시간 간격은 일정하지 않습니다. 한 프레임이 16.6ms에 끝날 수도, 33ms가 걸릴 수도 있습니다. 이동 거리를 프레임당 고정값으로 계산하면 60fps 기기에서는 초당 60회, 30fps 기기에서는 초당 30회 이동이 누적되어 속도 차이가 생깁니다.

Time.deltaTime은 이전 프레임에서 현재 프레임까지 경과한 시간(초)입니다. 이동 거리를 속도 × Time.deltaTime으로 계산하면, 프레임률이 달라져도 1초 동안의 총 이동 거리는 동일합니다.

게임 루프의 원리 (1) - 프레임의 구조에서 이 가변 타임스텝 방식의 역사와 원리를 다룹니다.

Update의 호출 순서

같은 씬에 여러 MonoBehaviour의 Update가 존재할 때, 호출 순서는 보장되지 않습니다. 오브젝트 A의 Update가 오브젝트 B의 Update보다 먼저 호출된다고 가정할 수 없습니다.


호출 순서를 명시적으로 제어해야 하는 경우, Script Execution Order(Project Settings > Script Execution Order)에서 스크립트의 실행 순서를 지정할 수 있습니다. 기본값은 0이며, 값이 작을수록 먼저 실행됩니다.

다만 Script Execution Order에 의존하면 스크립트 간 의존 관계가 코드가 아닌 프로젝트 설정 파일에 숨게 됩니다. 코드만 봐서는 실행 순서를 파악할 수 없고, 스크립트가 늘어날수록 순서 관리가 복잡해집니다.

순서에 의존하는 로직이 있다면, 코드 구조 자체에서 순서가 드러나도록 설계하는 것이 바람직합니다.

LateUpdate

LateUpdate()는 같은 프레임에서 모든 오브젝트의 Update가 완료된 후 호출됩니다.


Update와 LateUpdate의 실행 순서 A의 Update B의 Update C의 Update (모든 Update 완료) LateUpdate 단계 A의 LateUpdate B의 LateUpdate C의 LateUpdate


LateUpdate의 대표적인 사용처는 카메라 추적입니다.

카메라가 캐릭터를 따라가야 할 때, 캐릭터의 이동이 Update에서 끝난 후에 카메라 위치를 갱신해야 합니다. 카메라 로직을 Update에 작성하면, 카메라의 Update가 캐릭터의 Update보다 먼저 실행될 수 있습니다. 이 경우 카메라가 캐릭터의 이전 프레임 위치를 기준으로 배치되어 1프레임의 지연이 발생합니다.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 카메라 추적의 올바른 구현

// 캐릭터 스크립트
void Update() {
    transform.position += moveDir * speed * Time.deltaTime;
    // → 캐릭터 위치 갱신
}


// 카메라 스크립트
void LateUpdate() {
    transform.position = target.position + offset;
    // → 캐릭터의 최종 위치를 기준으로 카메라 위치 결정
    // → 모든 Update가 끝났으므로 target.position은 최종값
}


카메라 추적 외에도, 다른 오브젝트의 Update 결과에 의존하는 로직은 LateUpdate에 배치합니다. 캐릭터의 본(Bone) 보정이나 IK(Inverse Kinematics) 보정이 대표적입니다. IK는 손이나 발이 특정 위치에 닿도록 중간 관절의 각도를 자동 계산하는 기법으로, 대상 오브젝트의 최종 위치가 확정된 뒤에 계산해야 정확합니다.

렌더링 콜백

LateUpdate까지 끝나면 렌더링 단계가 시작됩니다. URP에서는 Built-in Render Pipeline의 MonoBehaviour 콜백(OnPreRender(), OnPostRender(), OnRenderImage())이 동작하지 않습니다. 대신 RenderPipelineManager의 이벤트로 렌더링 전후에 개입합니다.


URP 렌더링 콜백 LateUpdate 완료 beginFrameRendering 프레임 렌더링 시작 전 beginCameraRendering 각 카메라의 렌더링 시작 전 URP Render Passes Opaque → Skybox → Transparent → Post-processing endCameraRendering 각 카메라의 렌더링 완료 후 endFrameRendering 프레임 렌더링 완료 후


beginFrameRendering / endFrameRendering은 프레임 단위, beginCameraRendering / endCameraRendering은 카메라 단위로 호출됩니다. 씬에 카메라가 여러 대 있으면 beginCameraRendering ~ endCameraRendering 구간이 카메라 수만큼 반복됩니다.


1
2
3
4
5
6
7
8
9
10
11
12
13

// URP 렌더링 이벤트 구독 예시

void OnEnable() {
    RenderPipelineManager.beginCameraRendering += OnBeginCameraRendering;
}

void OnDisable() {
    RenderPipelineManager.beginCameraRendering -= OnBeginCameraRendering;
}

void OnBeginCameraRendering(ScriptableRenderContext ctx, Camera cam) {
    // 카메라 렌더링 직전에 수행할 작업
}


렌더링 파이프라인 내부에 더 깊이 개입해야 하는 경우(커스텀 렌더링, 후처리 효과, 디버그 시각화 등)에는 ScriptableRendererFeature와 ScriptableRenderPass를 작성하여 URP 파이프라인의 특정 지점에 커스텀 패스를 삽입합니다. Unity 렌더 파이프라인 (1) - Built-in과 URP의 구조에서 렌더링 파이프라인의 구조를 자세히 다룹니다.

코루틴 실행 시점

지금까지의 콜백은 프레임 내 정해진 순서에 따라 호출됩니다. 코루틴은 이와 달리 재개 시점이 고정되어 있지 않습니다.

Unity와 코루틴에서 다룬 것처럼, 코루틴은 별도의 스레드가 아니라 메인 스레드에서 실행됩니다. yield 문의 종류에 따라 재개(Resume) 시점이 달라집니다.


yield 문에 따른 코루틴 재개 시점

yield 문 재개 시점
yield return null 다음 프레임의 Update 직후 (LateUpdate 이전)
yield return new WaitForEndOfFrame() 현재 프레임의 렌더링 완료 후
yield return new WaitForFixedUpdate() 다음 FixedUpdate 직후 (물리 시뮬레이션 이전)
yield return new WaitForSeconds(t) t초 경과 후, Update 직후 (LateUpdate 이전)
yield return StartCoroutine(other) other 코루틴 완료 후

yield return null이 가장 흔하게 사용되며, 프레임 내에서의 정확한 재개 시점은 Update와 LateUpdate 사이입니다.


코루틴 재개 시점 (yield return null) FixedUpdate (0~N회) Update 코루틴 재개 (yield return null 이후) ← 여기 LateUpdate 렌더링


WaitForEndOfFrame은 렌더링이 완료된 후에 재개됩니다. 화면 캡처(ReadPixels)처럼 렌더링 결과를 읽어야 하는 경우에 사용합니다. WaitForFixedUpdate는 다음 FixedUpdate 호출 직후, 물리 시뮬레이션이 실행되기 전에 재개됩니다. 고정 시간 간격으로 실행해야 하지만 FixedUpdate 본체와 분리하고 싶은 로직에 사용합니다.

OnDisable과 OnDestroy

매 프레임 반복되는 루프 외에, 오브젝트의 비활성화와 파괴 시점에 호출되는 콜백들이 있습니다.

OnDisable

OnDisable()은 스크립트나 오브젝트가 비활성화될 때 호출됩니다. SetActive(false)로 GameObject를 비활성화하거나, enabled = false로 개별 컴포넌트를 비활성화하거나, 오브젝트가 파괴되기 직전에 호출됩니다.

OnDisable은 OnDestroy보다 먼저 호출되므로, OnEnable에서 구독한 이벤트를 OnDisable에서 해제하면 비활성화와 파괴 두 경우를 모두 처리합니다. 해제하지 않으면 비활성화된 오브젝트에 이벤트가 전달되거나, 파괴된 오브젝트의 참조가 델리게이트에 남아 NullReferenceException이 발생합니다. 앞서 URP 렌더링 콜백 섹션의 beginCameraRendering 구독/해제 코드가 이 패턴의 예시입니다.


1
2
3
4
5
6
7
8
9

// OnEnable / OnDisable 쌍

void OnEnable() {
    EventManager.OnGamePaused += HandlePause;  // 활성화 시 구독
}

void OnDisable() {
    EventManager.OnGamePaused -= HandlePause;  // 비활성화 시 해제
}

OnDestroy

OnDestroy()는 오브젝트가 파괴될 때 호출됩니다. Destroy(gameObject) 호출 후, 또는 씬이 언로드될 때 실행됩니다.


OnDisable이 이벤트 구독 해제를 담당한다면, OnDestroy는 오브젝트가 생존하는 동안 점유하던 리소스를 정리하는 역할입니다. NativeArray 같은 네이티브 리소스 해제, 정적 리스트에서 자신에 대한 참조 제거 등이 여기에 해당합니다.


1
2
3
4
5
6
7
8
9
10

// OnDestroy에서 수행하는 정리 작업

void OnDestroy() {
    // 정적 리스트에서 자신 제거
    EnemyManager.allEnemies.Remove(this);

    // 네이티브 리소스 해제
    if (_nativeBuffer.IsCreated)
        _nativeBuffer.Dispose();
}

OnDestroy는 이전에 활성화된 적 있는 GameObject에서만 호출됩니다. Awake조차 호출되지 않은 오브젝트는 초기화에서 할당한 리소스 자체가 존재하지 않으므로, OnDestroy 미호출이 문제가 되지 않습니다. 활성화된 적 있는 오브젝트에 대해서는 OnDisable과 OnDestroy가 모두 호출되므로, OnDisable에서 이벤트를 해제하고 OnDestroy에서 네이티브 리소스를 정리하는 구조가 일반적입니다.

전체 순서 다이어그램

지금까지 다룬 콜백들의 실행 순서를 하나의 다이어그램으로 나타내면 다음과 같습니다.


Unity 한 프레임의 전체 실행 순서 초기화 (최초 1회) Awake() → OnEnable() 쌍 실행 (오브젝트 간 순서는 비결정적) Start() 첫 프레임의 Update 직전 매 프레임 반복 물리 루프 (0~N회) FixedUpdate() 물리 시뮬레이션 (내부) OnCollisionEnter/Stay/Exit() OnTriggerEnter/Stay/Exit() 입력 이벤트 (OnMouseDown 등) Update() 코루틴 재개 (yield return null) 애니메이션 갱신 (내부) LateUpdate() 렌더링 OnWillRenderObject() 카메라 렌더링 (컬링, 드로우 콜 등) OnRenderObject() OnPostRender() OnRenderImage() (후처리) 코루틴 재개 (yield return WaitForEndOfFrame) 화면 표시 (Present) 정리 (파괴/비활성화 시) OnDisable() OnDestroy()


이 순서를 기반으로 각 콜백에 적합한 로직을 정리합니다.


콜백별 적합한 로직

콜백 적합한 로직
Awake 자기 컴포넌트 캐싱, 내부 변수 초기화
OnEnable 이벤트 구독, 활성화 시 설정
Start 다른 오브젝트 참조, 초기 배치
FixedUpdate 물리 연산 (AddForce, MovePosition)
Update 입력 처리, 게임 로직, 비물리 이동
LateUpdate 카메라 추적, 본 보정, 후처리 로직
OnDisable 이벤트 해제, 활성 상태 정리
OnDestroy 리소스 해제, 정적 참조 제거

마무리

Unity는 매 프레임 정해진 순서로 콜백을 호출합니다. 초기화(Awake, OnEnable, Start), 물리 루프(FixedUpdate, 시뮬레이션, 충돌 콜백), 입력 처리, Update, 코루틴 재개, LateUpdate, 렌더링 순서로 진행됩니다.

  • Awake는 자기 자신의 초기화에, Start는 다른 오브젝트 참조에 사용합니다. 오브젝트 간 Awake/OnEnable 호출 순서는 비결정적이며, 모든 Awake/OnEnable이 끝난 후에야 Start가 호출됩니다
  • FixedUpdate는 고정 간격으로 호출되며 프레임당 0~N회 실행됩니다. 물리 연산은 FixedUpdate에서 수행해야 프레임률에 독립적인 결과를 얻습니다
  • Legacy Input Manager의 입력 이벤트 콜백(OnMouseDown() 등)은 Update 이전에 호출됩니다. New Input System은 Update Mode 설정에 따라 Update 직전 또는 FixedUpdate 직전에 입력을 처리합니다
  • Update는 매 프레임 1회 호출되며, Time.deltaTime을 곱하여 프레임 독립적 동작을 구현합니다
  • LateUpdate는 모든 Update 완료 후 호출되며, 카메라 추적처럼 다른 오브젝트의 최종 위치에 의존하는 로직에 사용합니다
  • URP에서는 RenderPipelineManager의 이벤트(beginCameraRendering, endCameraRendering 등)로 렌더링 전후에 개입합니다
  • 코루틴의 재개 시점은 yield 문의 종류에 따라 달라집니다. yield return null은 Update 이후, WaitForEndOfFrame은 렌더링 이후에 재개됩니다
  • OnDisable에서 이벤트를 해제하고, OnDestroy에서 네이티브 리소스를 정리합니다. 한 번도 활성화된 적 없는 오브젝트에서는 두 콜백 모두 호출되지 않습니다

이 실행 순서를 기반으로, 초기화는 Awake/Start로 단계를 나누고, 물리와 게임 로직은 FixedUpdate/Update로 분리하며, 후처리는 LateUpdate에 배치합니다.


이 글에서 다룬 실행 순서는 한 프레임 안에서의 작업 흐름입니다. 이 콜백들이 모두 하나의 스레드에서 순차 실행되는 것은 아닙니다. Unity 엔진 핵심 (4) - Unity의 스레딩 모델에서는 MonoBehaviour 콜백이 실제로 어떤 스레드에서 실행되는지, 잡 시스템과의 관계를 다룹니다. 게임 루프의 원리 (1) - 프레임의 구조에서는 16.6ms라는 시간 제약 안에서 CPU와 GPU가 어떻게 병렬로 동작하는지 다룹니다.


관련 글

시리즈

전체 시리즈

Tags: Unity, Update, 모바일, 실행순서, 엔진

Categories: ,

관련 문제