Unity 에셋 시스템 (3) - Scene Management - soo:bak

작성일 : 2026년 03월 05일

에셋이 모여 이루는 가장 큰 단위

Part 2에서 에셋이 직렬화되어 디스크에 저장되고, 역직렬화되어 메모리에 올라가는 과정을 다루었습니다. Instantiate가 오브젝트를 복제할 때 공유 에셋은 참조만 복사한다는 점, Resources 폴더의 한계도 확인했습니다.

이 글에서는 에셋들이 모여 구성하는 가장 큰 단위인 씬(Scene)의 관리 방법을 살펴봅니다. 로딩과 언로딩을 통해 게임의 흐름(메뉴 → 게임 플레이 → 결과 화면)을 제어하는 기본 메커니즘이며, 전환 시점마다 대규모 메모리 할당과 해제가 발생합니다. 한 번의 전환에 수십~수백 MB의 에셋이 해제되고 다시 로드되므로, 씬 관리 전략은 곧 메모리 관리의 핵심 축이 됩니다.

씬(Scene)의 구조

씬은 GameObject들의 집합입니다. 카메라, 조명, 캐릭터, 배경, UI 등 게임 화면을 구성하는 모든 오브젝트가 하나의 씬에 포함됩니다.

Part 2에서 다루었듯이, 씬 파일(.unity)은 YAML 형식으로 저장됩니다. 씬에 포함된 모든 GameObject와 컴포넌트가 직렬화되어 기록되고, 각 오브젝트는 fileID로 식별됩니다. 에디터에서 씬을 저장하면 이 YAML 데이터가 디스크에 기록되고, 씬을 로드하면 역직렬화를 통해 메모리에 오브젝트를 복원합니다.

Build Settings에 씬 등록

빌드에 포함할 씬은 Build Settings(File → Build Settings)의 Scenes In Build 목록에 등록해야 합니다. 등록된 씬은 인덱스 번호를 부여받으며, 인덱스 0번 씬이 앱 실행 시 가장 먼저 로드되는 씬입니다.

Unity의 Addressables 시스템을 사용하면 Build Settings에 등록하지 않은 씬도 런타임에 로드할 수 있지만, SceneManager를 통한 기본적인 씬 전환에는 Build Settings 등록이 필요합니다.

SceneManager.LoadScene — 동기 로딩

SceneManager.LoadScene은 씬을 동기적(Synchronous)으로 로드합니다. 호출 자체는 즉시 반환되어 같은 프레임 내 나머지 코드가 계속 실행되지만, 실제 씬 로딩은 다음 프레임에서 수행됩니다. 로딩이 완료될 때까지 메인 스레드가 블로킹되는데, Unity는 게임 로직, 렌더링 명령 생성, 입력 처리를 모두 메인 스레드에서 순차 실행하므로 블로킹 동안 화면 갱신과 입력 처리가 멈춥니다.

동기 로딩의 가장 큰 문제는 프레임 정지입니다. 씬의 에셋 총량이 클수록, 참조하는 에셋이 많을수록 정지 시간이 길어집니다. 에셋이 많은 게임 씬을 동기 로딩하면 2~5초 이상 화면이 멈출 수 있습니다. 사용자에게는 앱이 멈춘 것처럼 보이며, 모바일 OS가 응답 없음으로 판단하여 앱을 강제 종료하는 경우도 발생합니다.

동기 로딩이 적합한 경우는 제한적입니다. 앱 시작 시 첫 번째 씬을 로드하는 경우(어차피 스플래시 화면이 표시됨), 또는 에셋이 거의 없는 작은 씬을 로드하는 경우에만 사용합니다.

기존 씬의 처리

기본 동작(LoadSceneMode.Single)에서는 새 씬을 로드하기 전에 현재 씬의 모든 오브젝트를 파괴합니다. 각 오브젝트의 OnDisable, OnDestroy 순서로 콜백이 호출됩니다. 새 씬 로드가 완료되면 Unity가 자동으로 Resources.UnloadUnusedAssets()를 호출하여, 이전 씬의 오브젝트만 참조하던 에셋을 메모리에서 해제합니다. 다만 이 자동 해제는 새 씬의 에셋 로딩이 끝난 뒤에 수행되므로, 전환 중에는 이전 씬과 새 씬의 에셋이 동시에 메모리에 올라가는 피크 구간이 생길 수 있습니다.

SceneManager.LoadSceneAsync — 비동기 로딩

SceneManager.LoadSceneAsync는 씬을 비동기적(Asynchronous)으로 로드하여 동기 로딩의 프레임 정지 문제를 해결합니다. 파일 읽기(I/O)와 역직렬화의 상당 부분은 백그라운드 스레드에서 수행되고, 로드된 오브젝트를 씬에 통합(Integration)하는 작업은 메인 스레드에서 여러 프레임에 걸쳐 분산 처리됩니다. 따라서 로딩이 진행되는 동안에도 게임이 계속 실행됩니다.

AsyncOperation과 progress

LoadSceneAsync는 로딩 상태를 추적할 수 있는 AsyncOperation 객체를 반환합니다. progress 프로퍼티의 값은 0에서 1까지 변화하지만, 실제 로딩 작업은 0~0.9 구간에서 수행됩니다. 0.9에서 1.0으로의 전환은 씬 활성화(오브젝트 초기화) 단계에 해당합니다.

allowSceneActivation으로 활성화 시점 제어

AsyncOperation.allowSceneActivation을 false로 설정하면, progress가 0.9에 도달해도 씬이 활성화되지 않고 대기합니다. 데이터 로딩이 끝난 뒤 원하는 시점(사용자 입력, 애니메이션 종료 등)에 allowSceneActivation = true로 설정하면 씬이 활성화됩니다.

allowSceneActivation이 false인 동안에는 AsyncOperation.isDone도 true가 되지 않습니다. 로딩 완료를 isDone으로 검사하는 코드(예: 코루틴의 yield return operation)는 allowSceneActivation이 true로 전환될 때까지 완료되지 않습니다. 로딩 완료 여부를 판단하려면 progress >= 0.9f 조건을 사용해야 합니다.

동기 로딩과 비동기 로딩을 혼용할 때 주의할 점이 있습니다. SceneManager.LoadScene은 호출 시점에 진행 중인 모든 AsyncOperation을 강제 완료시킵니다. allowSceneActivation을 false로 설정하여 활성화를 보류한 비동기 로딩이 있더라도 즉시 완료 처리되므로, 의도하지 않은 씬 활성화가 발생할 수 있습니다.

비동기 로딩이 프레임 드롭을 완전히 제거하지는 않습니다. Unity는 매 프레임 메인 스레드에서 오브젝트 통합에 쓸 수 있는 시간을 제한하지만, 단일 에셋의 통합 작업이 이 시간 예산을 초과하면 해당 프레임에서 스파이크가 발생합니다. 씬 활성화 시점에 호출되는 Awake/Start 콜백에서 무거운 초기화(대량의 오브젝트 생성, 복잡한 데이터 구조 구축 등)를 수행하는 경우에도 스파이크의 원인이 됩니다.

Application.backgroundLoadingPriority는 매 프레임 오브젝트 통합에 허용되는 메인 스레드 시간의 상한을 결정합니다. 기본값(ThreadPriority.Normal)은 프레임당 최대 10ms입니다. 60 FPS 기준으로 한 프레임의 전체 시간은 약 16.7ms이므로, 통합에 10ms를 쓰면 게임 로직과 렌더링에 남는 시간은 약 6.7ms뿐입니다. ThreadPriority.Low로 낮추면 프레임당 통합 시간이 2ms로 줄어들어 프레임 드롭이 완화되지만, 프레임당 처리량이 줄어든 만큼 총 로딩 시간은 길어집니다.

Additive 씬 로딩

지금까지 다룬 씬 로딩은 모두 기존 씬을 파괴하고 새 씬으로 교체하는 LoadSceneMode.Single 방식이었습니다. 이와 달리, Additive 모드는 기존 씬을 유지한 채 추가 씬을 함께 로드합니다.

Additive 씬의 활용

Additive 씬 로딩을 활용하면 UI, 게임 플레이, 환경을 각각 별도 씬으로 분리하고, 필요한 부분만 독립적으로 로드하거나 교체할 수 있습니다.

SetActiveScene

Additive로 여러 씬이 동시에 로드되어 있으면, 런타임에 생성하는 오브젝트(Instantiate, new GameObject 등)의 소속 씬을 결정해야 합니다.

nity는 Active Scene으로 지정된 씬에 새 오브젝트를 소속시키며, SceneManager.SetActiveScene(scene)으로 Active Scene을 전환할 수 있습니다.

// 로드된 씬: [UI Scene] + [GamePlay Scene (Active)]

Instantiate(bulletPrefab);
// → bulletPrefab의 인스턴스는 GamePlay Scene에 소속

SceneManager.SetActiveScene(uiScene);

Instantiate(tooltipPrefab);
// → tooltipPrefab의 인스턴스는 UI Scene에 소속

// Active Scene 설정은 오브젝트의 소속 씬을 결정
// 씬 언로드 시 해당 씬에 소속된 오브젝트만 파괴됨

Active Scene을 올바르게 설정해야 하는 이유는 두 가지입니다.

첫째, 오브젝트의 소속 씬이 언로딩 동작에 영향을 줍니다. 특정 씬을 언로드하면 그 씬에 소속된 오브젝트만 파괴됩니다. 오브젝트가 잘못된 씬에 소속되어 있으면, 의도하지 않은 시점에 파괴되거나 파괴되지 않는 문제가 발생합니다.

둘째, Active Scene이 전역 라이팅 설정을 결정합니다. 라이트맵은 각 씬에 독립적으로 베이크되어 Additive로 로드된 씬도 자기 자신의 라이트맵을 사용하지만, 환경 조명·스카이박스·포그 같은 전역 설정은 Active Scene의 것이 적용됩니다. 콘텐츠 씬을 교체할 때 SetActiveScene을 올바른 씬으로 전환하지 않으면, 이전 씬의 환경 라이팅이 그대로 남아 시각적 이상이 발생할 수 있습니다.

DontDestroyOnLoad

씬을 전환(LoadSceneMode.Single)하면 현재 씬의 모든 오브젝트가 파괴됩니다. 그런데 게임 매니저, 오디오 매니저, 네트워크 매니저처럼 게임 전체 수명 동안 유지되어야 하는 오브젝트가 있습니다. DontDestroyOnLoad(gameObject)를 호출하면, 해당 오브젝트는 씬 전환 시에도 파괴되지 않고 유지됩니다.

DontDestroyOnLoad를 호출하면 해당 오브젝트는 기존 씬에서 분리되어, Unity가 내부적으로 관리하는 별도의 DontDestroyOnLoad 씬으로 이동합니다. 이 씬은 Hierarchy 창에서 별도로 표시되며, 런타임에서 gameObject.scene.name을 확인하면 "DontDestroyOnLoad"라는 이름이 반환됩니다.

DontDestroyOnLoad는 루트 GameObject에만 동작합니다. 자식 오브젝트에 DontDestroyOnLoad(childObject)를 호출하면 Unity는 “DontDestroyOnLoad only works for root GameObjects or components on root GameObjects”라는 경고를 출력하며, 해당 호출은 무시됩니다. 루트 GameObject에 DontDestroyOnLoad를 적용하면, 그 오브젝트의 모든 자식도 함께 보존됩니다.

반대로, DontDestroyOnLoad 씬에 있는 오브젝트를 다시 특정 씬으로 되돌리고 싶다면 SceneManager.MoveGameObjectToScene(gameObject, targetScene)을 사용합니다.

이 메서드 역시 루트 GameObject에만 동작하며, 자식 오브젝트에 호출하면 InvalidOperationException이 발생합니다. 더 이상 영구 보존할 필요가 없는 오브젝트를 일반 씬으로 옮겨, 해당 씬이 언로드될 때 함께 파괴되도록 할 때 활용합니다.

일반적인 사용 대상

DontDestroyOnLoad는 게임 전체 수명 동안 유지되어야 하는 시스템 오브젝트에 사용합니다.

EventSystem을 DontDestroyOnLoad로 설정하는 경우, 새 씬에도 EventSystem이 있으면 두 개가 동시에 존재하게 됩니다. Unity는 하나의 활성 EventSystem만 허용하므로, 중복을 감지하여 자기 자신을 파괴하는 로직을 추가해야 합니다.

반대로, 특정 화면에서만 쓰이는 UI 패널이나 임시 이펙트처럼 수명이 한정된 오브젝트에 DontDestroyOnLoad를 적용하면, 씬이 바뀐 뒤에도 메모리에 남아 낭비로 이어집니다.

싱글턴 중복 인스턴스 문제

DontDestroyOnLoad 오브젝트는 대부분 싱글턴 패턴으로 구현됩니다. 그런데 씬 A에서 GameManager를 DontDestroyOnLoad로 등록한 뒤, 게임 도중 씬 A로 다시 돌아오면 씬 A가 새로 로드되면서 GameManager가 한 번 더 생성됩니다. 기존 인스턴스는 DontDestroyOnLoad 씬에 이미 존재하므로, 두 개의 GameManager가 동시에 존재하게 됩니다. 이 중복을 방지하려면 Awake에서 기존 인스턴스 여부를 확인하고, 이미 존재하면 새로 생성된 자신을 즉시 파괴하는 로직이 필요합니다.

남용 시 메모리 누수 위험

DontDestroyOnLoad 오브젝트에서 대량의 텍스처나 오디오 클립을 직접 참조하고 있으면, 그 에셋들은 씬 전환과 무관하게 게임 전체 수명 동안 메모리에 상주합니다.

DontDestroyOnLoad 오브젝트는 가능한 한 가볍게 유지해야 합니다. 에셋 데이터를 직접 참조하지 않고 Addressables 등으로 동적 로드/해제하며, 씬별로 필요한 리소스는 해당 씬에서만 로드하는 것이 원칙입니다. 적용 대상의 수 자체도 최소한으로 제한해야 합니다.

씬 언로딩과 메모리 해제

씬을 전환하거나 Additive 씬을 제거할 때, 메모리가 즉시 해제되지는 않습니다. 오브젝트 파괴와 에셋 메모리 해제는 별도의 과정이기 때문입니다.

오브젝트 파괴 vs 에셋 해제

씬을 언로드하면 그 씬에 소속된 GameObject와 컴포넌트가 파괴됩니다. 파괴되는 오브젝트에서 실행 중이던 코루틴(Coroutine)은 자동으로 중단됩니다. 코루틴은 MonoBehaviour가 소유하고 실행하는 함수이므로, 해당 오브젝트와 생명주기를 공유하기 때문입니다.

반면, 해당 오브젝트가 다른 시스템에 등록한 이벤트 핸들러(예: 버튼의 onClick, C# 이벤트 구독 등)는 자동으로 해제되지 않습니다. 이벤트 시스템은 구독자의 생존 여부를 추적하지 않기 때문입니다. 파괴된 오브젝트의 메서드를 콜백으로 여전히 참조하게 되면 MissingReferenceException이 발생하므로, OnDestroy에서 이벤트 구독을 해제하는 것이 안전합니다.

오브젝트가 파괴되어도, 그 오브젝트가 참조하던 에셋(텍스처, 메쉬, 오디오 클립 등)의 메모리는 즉시 해제되지 않습니다.

오브젝트가 파괴되면 그 오브젝트의 에셋 참조는 사라지지만, 다른 오브젝트나 DDOL 씬에서 같은 에셋을 여전히 참조하고 있을 수 있습니다. Unity는 Resources.UnloadUnusedAssets()를 통해 모든 참조를 확인한 뒤에야 에셋 메모리를 해제합니다.

Resources.UnloadUnusedAssets()

이 함수는 현재 메모리에 로드된 에셋들의 참조 상태를 추적하여, 어디에서도 참조되지 않는 에셋을 메모리에서 해제합니다.

UnloadUnusedAssets는 비용이 높은 연산입니다. 프로젝트에 에셋이 많을수록 추적 시간이 길어지며, 매 프레임 호출하면 성능 저하를 유발합니다.

GC.Collect와의 관계

가비지 컬렉션(Garbage Collection)은 C#의 관리 힙(Managed Heap)에서 더 이상 도달할 수 없는(unreachable) 객체를 수거하는 과정이며, GC.Collect()는 이를 즉시 실행하는 함수입니다.

UnloadUnusedAssets의 참조 추적이 정확하려면 관리 힙의 도달 불가능한 객체가 먼저 수거되어야 하므로, UnloadUnusedAssets는 내부적으로 GC.Collect()를 호출합니다. 개발자가 별도로 GC.Collect()를 호출할 필요는 없습니다.

Unity에서 텍스처나 메쉬 같은 에셋의 실제 데이터는 네이티브(C++) 메모리에 저장되고, C# 코드에서는 Texture2D, Mesh 같은 래퍼 객체를 통해 이를 참조합니다.

씬이 언로드되면 GameObject와 컴포넌트는 파괴되어 == null이 true를 반환하지만, 가비지 컬렉터가 수거하기 전까지 관리 힙에는 남아 있습니다.

이 객체가 참조하던 Texture2D 래퍼도 도달 가능한 상태로 유지되어, Unity는 해당 네이티브 에셋을 아직 사용 중으로 판단합니다.

GC.Collect()를 실행해야 이런 객체들이 수거되고, 네이티브 에셋에 대한 참조가 완전히 제거되어 비로소 해제 대상이 됩니다.

씬 전환 시 전체 흐름

씬 전환의 최적 패턴은 로딩 화면을 경유하는 것입니다. 메모리 관리 (2) - 네이티브 메모리와 에셋에서 다룬 메모리 피크 관리와 직접 연결됩니다.

3단계의 Resources.UnloadUnusedAssets() 명시 호출은 필수입니다. LoadScene(Single) 방식에서는 Unity가 새 씬 로드 후 UnloadUnusedAssets를 자동으로 호출하지만, UnloadSceneAsync(Additive 씬 언로드)에서는 자동 호출이 없습니다. 따라서 Additive 기반 씬 전환에서는 개발자가 직접 호출해야 이전 씬의 에셋이 해제됩니다.

각 단계 사이에 yield return(코루틴) 또는 await(async/await)로 완료를 대기하는 것도 필수입니다. UnloadSceneAsync와 UnloadUnusedAssets는 모두 비동기로 실행되므로, 완료를 기다리지 않고 다음 단계를 시작하면 이전 에셋이 해제되기 전에 새 에셋이 로드되어 메모리 피크가 줄어들지 않습니다.

메모리 피크가 높아지면 모바일에서 OOM(Out Of Memory)이 발생할 수 있습니다. OOM은 앱의 메모리 사용량이 OS 허용 한도를 초과했을 때 OS가 앱을 강제 종료하는 현상입니다. 모바일 기기의 RAM이 4~8GB이더라도 OS가 앱 하나에 허용하는 메모리는 대체로 1~2GB 수준이므로, 두 씬의 에셋이 겹치는 순간 이 한도를 넘기기 쉽습니다.

대규모 월드를 위한 씬 분할 전략

지금까지 다룬 씬 전환 패턴은 메뉴 → 게임 → 결과처럼 단계가 명확히 나뉘는 구조에 적합합니다. 오픈 월드나 대규모 맵을 가진 게임에서는 전체 월드를 하나의 씬에 담을 수 없습니다. 에셋 총량이 기기의 메모리 한계를 초과하기 때문입니다.

이 문제를 해결하는 방법이 씬 분할(Scene Splitting)입니다.

그리드 기반 월드 분할

월드를 격자(Grid)로 나누어 각 셀을 별도의 씬으로 구성합니다. 플레이어 위치에 따라 현재 셀과 인접 셀만 Additive로 로드하고, 로드 범위를 벗어난 셀은 언로드하면 전체 월드 중 플레이어 주변의 에셋만 메모리에 유지됩니다.

스트리밍: 미리 로드하기

플레이어가 셀 사이를 이동하면 로드 범위도 함께 이동합니다. 스트리밍(Streaming)은 플레이어가 셀 경계에 가까워질 때 이동 방향의 인접 셀을 미리 비동기 로드하고, 반대쪽 셀을 언로드하여 끊김 없이 월드를 탐색할 수 있게 하는 방식입니다.

플레이어가 현재 셀을 이동하는 동안, 이동 방향의 다음 셀이 백그라운드에서 비동기 로드됩니다. 셀 경계에 도착할 때 로딩이 이미 완료되어 있으면 끊김 없이 새 영역이 나타납니다. 비동기 로딩은 셀의 에셋 양에 따라 수백 ms에서 수 초까지 걸리므로, 플레이어의 이동 속도와 로딩 시간을 고려하여 경계 도달 전에 충분한 여유를 두고 로딩을 시작해야 합니다. 로딩이 완료되기 전에 플레이어가 새 셀에 진입하면, 빈 공간이 보이거나 오브젝트가 갑자기 나타나는 팝인(pop-in)이 발생합니다.

메모리 측면에서는 로드된 셀의 총 수가 항상 일정하게 유지됩니다. 위 예시에서 로드 범위가 3×3이면 항상 9개 셀의 에셋만 메모리에 올라가므로, 월드 전체 크기와 무관하게 메모리 사용량의 상한을 예측할 수 있습니다.

씬 간 공유 에셋 관리

인접한 셀들은 같은 나무 프리팹이나 지형 텍스처를 공유하는 경우가 많습니다. 각 셀을 AssetBundle로 패키징할 때, 공유 에셋을 별도 번들로 분리하지 않으면 동일한 에셋이 셀마다 복사되어 메모리에 중복으로 올라갑니다.

Unity는 같은 에셋 파일(같은 GUID)을 참조하면 메모리에 한 번만 로드합니다.

AssetBundle은 번들 단위로 독립된 파일을 생성합니다. 위 예시에서 Tree_A가 Cell_11 번들에도 Cell_12 번들에도 필요한데 어떤 번들에도 배정되어 있지 않으면, Unity는 런타임에 Tree_A를 찾을 곳이 없으므로 각 번들 안에 데이터를 복사합니다. 복사된 데이터는 번들마다 별개이므로, 두 번들을 동시에 로드하면 같은 에셋이 메모리에 두 벌 존재합니다.

Tree_A를 별도의 공유 번들에 배정하면, 각 셀 번들에는 “공유 번들에서 로드”라는 의존성 기록만 남아 에셋이 한 번만 로드됩니다. Addressables의 그룹 구성과 의존성 분석 기능을 활용하면 이 문제를 체계적으로 관리할 수 있습니다. 구체적인 방법은 메모리 관리 (3) - Addressables와 에셋 전략에서 다룹니다.

공통 씬과 콘텐츠 씬 분리

대규모 프로젝트에서는 씬을 공통 씬(Persistent Scene)과 콘텐츠 씬(Content Scene)으로 분리하는 구조가 일반적입니다.

공통 씬에는 씬 전환과 무관하게 유지되어야 하는 오브젝트를, 콘텐츠 씬에는 스테이지별로 달라지는 요소만 배치합니다. 스테이지 전환 시 콘텐츠 씬만 교체하므로 공통 요소의 재로딩이 발생하지 않습니다.

DontDestroyOnLoad 씬은 Unity가 내부적으로 관리하므로 개발자가 씬 자체를 언로드할 수 없고, 오브젝트를 해제하려면 하나씩 Destroy()를 호출해야 합니다. 공통 씬 방식에서는 씬의 로드/언로드 시점을 개발자가 직접 제어하므로, 공통 씬을 언로드하면 그 안의 모든 오브젝트가 함께 파괴됩니다.

마무리

동기 로딩은 메인 스레드를 블로킹하여 프레임 정지를 유발하며, 비동기 로딩은 여러 프레임에 걸쳐 작업을 분산합니다. allowSceneActivation으로 활성화 시점을 제어할 수 있습니다.
Additive 씬 로딩으로 UI, 게임플레이, 환경을 독립된 씬으로 분리하여 개별적으로 로드/언로드할 수 있습니다.
DontDestroyOnLoad는 씬 전환 시 오브젝트를 유지하지만, 참조 에셋이 해제되지 않으므로 최소한으로 사용해야 합니다.
오브젝트 파괴 후에도 에셋 메모리는 즉시 해제되지 않으며, Resources.UnloadUnusedAssets()로 명시적 해제가 필요합니다.
대규모 월드에서는 그리드 씬 분할과 공통 씬/콘텐츠 씬 분리로 메모리 사용량의 상한을 예측 가능하게 유지합니다.

씬 관리의 본질은 메모리의 할당과 해제 시점을 제어하는 것입니다. 어떤 에셋을 언제 로드하고 언제 해제할지, 씬 전환 시 메모리 피크를 어떻게 최소화할지가 모바일 환경에서의 안정성을 결정합니다.

에셋의 메모리 생명주기를 직접 제어하는 AssetBundle과 Addressables의 로드/해제 패턴은 메모리 관리 (3) - Addressables와 에셋 전략에서, Unity 엔진의 기본 구조와 실행 흐름은 Unity 엔진 핵심 (1) - GameObject와 Component에서 각각 확인할 수 있습니다.

관련 글

시리즈

Unity 에셋 시스템 (1) - Asset Import Pipeline
Unity 에셋 시스템 (2) - Serialization과 Instantiation
Unity 에셋 시스템 (3) - Scene Management (현재 글)

전체 시리즈