DX11-B01 | DX11-SpongeBob-BFBB — Prototype에서 Runtime Object가 되기까지

한 줄 결론

Prototype은 “만들 수 있는 원형”일 뿐이고, 실제 게임에 존재하려면 Clone → Component Binding → Layer → Update / Late_Update → Render Group → Draw까지 이어져야 합니다. 이 글에서는 그 경계를 Source와 실제 Runtime 결과로 나눠서 따라갑니다.

Object Lifecycle Snapshot

먼저 아래 흐름만 잡으면 뒤의 Source를 훨씬 쉽게 읽을 수 있습니다.

Prototype
= 생성 가능한 원형
 
Runtime Clone
= 실제 게임에서 살아 있는 Instance
 
Prototype
→ Clone
→ Component
→ Layer
→ Update / Late_Update
→ Render Group
→ Draw
→ Player-visible Result

이 글의 핵심은 Class 이름을 많이 외우는 것이 아니라, “어느 단계까지 정상이고 어디에서 처음 끊겼는가?”를 Runtime Flow로 판단하는 것입니다.

DX11-SpongeBob-BFBB의 Object 구조를 다시 따라가면서 가장 중요하게 본 것은 Prototype이 등록되어 있다는 것과 실제 Runtime에서 Object가 살아 움직이는 것은 다른 단계라는 점이었습니다.

전체 흐름은 다음처럼 이어집니다.

Prototype 등록
→ Runtime Clone 생성
→ Initialize / Ready_Components
→ Component Clone / Binding
→ Layer 삽입
→ Priority_Update / Update / Late_Update
→ Render Group 등록
→ Render Pass
→ Player-visible Result

이 흐름을 나눠서 보기 시작한 뒤에는 Object가 보이지 않거나 동작하지 않을 때 Shader나 Resource부터 바로 의심하기보다, 처음 흐름이 끊긴 지점부터 확인하게 됐습니다.

Contribution Boundary

이 프로젝트는 학습 과정에서 사용한 DirectX11 Custom Framework를 기반으로 합니다.

따라서 Prototype / Clone / Layer / Component 구조 자체를 제가 처음부터 설계한 독자 엔진 구조라고 설명하지 않습니다.

제가 이 글에서 보여주려는 것은 기존 Object Runtime을 Source에서 읽고, 그 위에서 Client 기능을 확장하면서 실제 실행 경계를 추적한 경험입니다.

구체적으로 다음 질문에 답할 수 있도록 구조를 따라갔습니다.

• 원형은 어디에 저장되는가?
• 언제 Runtime Clone이 만들어지는가?
• Clone은 누가 보관하는가?
• Component는 어디서 복제되는가?
• Object는 언제 Update 대상이 되는가?
• 어떤 경로로 Renderer까지 넘어가는가?

그 위에서 SpongeBob Gameplay, Enemy / Boss, UI, Map Runtime, Runtime Tool, Save / Load 같은 Client 기능을 확장했습니다.

Prototype이 있다고 Object가 존재하는 것은 아닙니다

제가 가장 먼저 구분한 것은 생성 가능한 원형과 실제로 살아 있는 Instance였습니다.

예를 들어 Enemy의 GameObject Prototype이 등록되어 있어도 그것만으로 게임 안에 Enemy가 존재한다고 볼 수는 없습니다.

실제 Player-visible Result까지 가려면 다음 단계가 이어져야 합니다.

GameObject Prototype 등록
→ Spawn 요청
→ Prototype 검색
→ Clone 생성
→ Initialize / Ready_Components
→ Component Clone / Binding
→ Layer 삽입
→ Update / Late_Update
→ Render Group 등록
→ 실제 Draw

따라서 Class 존재, Prototype 등록, Runtime Spawn, 화면에서 정상 동작은 각각 다른 단계입니다.

이 구분은 포트폴리오 설명보다 실제 문제를 좁힐 때 더 도움이 됐습니다.

Loader는 Object를 Spawn하지 않고 원형을 준비합니다

Gameplay에 필요한 원형은 Loading 단계에서 먼저 준비됩니다.

CLoader는 다음 Level에 필요한 GameObject Prototype과 Component Prototype을 등록합니다.

CLevel_Loading
→ CLoader
→ Loading Thread
→ GameObject Prototype 등록
→ Component Prototype 등록
→ Loading 완료
→ Gameplay 진입

여기서 CLoader의 책임은 실제 Gameplay Object를 World에 배치하는 것이 아니라, 나중에 Clone할 수 있는 원형을 준비하는 것에 가깝습니다.

GameObject Prototype과 Component Prototype의 관리 범위도 다릅니다.

그래서 Object 생성 문제가 생기면 GameObject Prototype이 등록됐는가?와 현재 Level에 필요한 Component Prototype이 준비됐는가?를 따로 확인했습니다.

Runtime Object가 만들어지는 핵심 경계는 Add_GameObject_ToLayer입니다

원형이 준비된 뒤 실제 Object가 필요해지면 CObject_Manager::Add_GameObject_ToLayer 흐름으로 들어갑니다.

핵심 순서는 다음과 같습니다.

Add_GameObject_ToLayer
→ Find_Prototype
→ Prototype::Clone
→ Clone 내부 Initialize
→ Ready_Components
→ Component Clone / Binding
→ 대상 Layer 검색
→ 필요하면 Layer 생성
→ CLayer::Add_GameObject
→ Runtime Object가 Layer에 들어감

함수 이름만 보면 Layer에 Object를 넣는 기능처럼 보이지만, 실제로는 Prototype과 Runtime Instance가 갈리는 중요한 경계였습니다.

실패 지점도 서로 의미가 다릅니다.

그래서 Spawn 문제는 Prototype Tag → Find_Prototype → Clone Result → Component Binding → Layer Tag 순서로 앞에서부터 확인했습니다.

🔡 Source 1A~1C. CObject_Manager::Add_GameObject_ToLayer — Prototype이 Runtime Instance로 넘어가는 경계

Add_GameObject_ToLayer는 한 화면에 억지로 넣지 않고, Prototype Resolve → Clone → Layer Handoff의 세 단계로 나눠 읽습니다.

세 장이 담당하는 질문은 하나입니다.

Prototype 검색
→ Runtime Clone 생성
→ 대상 Layer 확인 / 생성
→ Runtime Object를 Layer에 삽입

Source 1A — Prototype 검색 경계

파일: DX11-B01_Screenshot_01_Source_AddGameObject_ToLayer0.png

CObject_Manager::Add_GameObject_ToLayer 안에서 Spawn 요청에 사용된 Prototype을 찾는 시작 경계를 보여줍니다.

Spawn Request
→ Find_Prototype
→ Prototype Resolve

여기서 중요한 점은 Prototype이 Source에 등록되어 있다는 사실과, 실제 Spawn 요청에서 올바른 Prototype을 찾는 것은 다른 단계라는 것입니다.

Source 1B — Runtime Clone 생성 경계

파일: DX11-B01_Screenshot_01_Source_AddGameObject_ToLayer1.png

찾은 Prototype으로부터 실제 Runtime Instance를 만드는 Clone 구간을 보여줍니다.

Resolved Prototype
→ Clone
→ Runtime Instance 생성 경계

이 단계에서 Prototype과 Runtime Clone의 의미가 갈립니다.

Prototype
= 생성 가능한 원형
 
Runtime Clone
= 실제 게임에 들어갈 Instance

Source 1C — Layer Handoff

파일: DX11-B01_Screenshot_01_Source_AddGameObject_ToLayer2.png

생성된 Runtime Object가 대상 Layer 경계로 넘어가는 구간을 보여줍니다.

Runtime Clone
→ Find / Create Layer
→ CLayer::Add_GameObject
→ Runtime Update Container 진입

함수 이름만 보면 단순히 “Layer에 추가”하는 기능처럼 보이지만, 실제로는 Prototype에서 Runtime Instance로 넘어간 Object가 게임의 Update 흐름에 편입되는 경계입니다.

이 세 장으로 증명하는 것

Add_GameObject_ToLayer의 Source 구조에서 Prototype 검색 → Clone → Layer 삽입이 어떻게 이어지는지 확인할 수 있습니다.

이 세 장만으로 증명하지 않는 것

이번 실행에서 특정 Watch 값이 무엇이었는지, 그리고 Object가 최종 화면까지 정상적으로 보였는지는 별도 Runtime Evidence가 담당합니다.

현재 SpongeBobEvidence에는 B01 전용 Debugger / Watch Screenshot을 별도 공개 Evidence로 두지 않았습니다. 따라서 Source Screenshot을 “실제 Runtime Watch까지 증명했다”고 과장하지 않고, 실제 Spawn → Visible 결과는 뒤의 Video 1로 닫습니다.

Clone이 만들어졌다고 Object 준비가 끝난 것도 아닙니다

GameObject Clone이 성공했다고 해서 Object가 바로 모든 기능을 갖는 것은 아닙니다.

움직임, 충돌, Navigation, Mesh, Shader 같은 기능을 사용하려면 필요한 Component가 준비되어야 합니다.

Component 쪽 흐름은 다음처럼 이어집니다.

Component Prototype 등록
→ CComponent_Manager[level]
→ CGameObject::Add_Component
→ CGameInstance::Clone_Component
→ CComponent_Manager::Clone_Component
→ Runtime Component 반환
→ CGameObject가 Runtime Component 보관

대표적인 역할은 다음과 같습니다.

즉 GameObject Clone 성공과 Component Binding 성공은 같은 의미가 아닙니다.

Collider가 없다면 Collision이 실패할 수 있고, Model이나 Shader가 없다면 Layer에는 존재하지만 화면에 보이지 않을 수 있습니다. 그래서 Object 생성 문제와 Component 문제를 같은 것으로 보지 않았습니다.

Layer는 단순한 이름표가 아니라 Runtime Object Container입니다

Layer_SpongeBob, Layer_Chomper, Layer_UI_* 같은 Tag는 단순한 분류 문자열이 아닙니다.

CLayer는 실제 Runtime GameObject들을 보관합니다.

CObject_Manager
→ Level별 Layer Map
→ CLayer
→ Runtime GameObject List

Frame Update에서는 각 Layer가 자신이 가진 Object에게 Priority_Update → Update → Late_Update를 위임합니다.

따라서 Runtime Clone이 Layer에 들어간다는 것은 단순히 이름이 붙는 것이 아니라 실제 Runtime Update 흐름에 들어가는 것에 가깝습니다.

Layer는 Gameplay Collision, UI, Tooling 등에서 Object를 찾는 Runtime 조회 경로로도 사용됩니다.

그래서 Prototype Tag, Layer Tag, Component Tag 같은 문자열도 Build만 통과하면 끝나는 값이 아니라 Runtime에서 서로 맞아야 하는 Contract로 봤습니다.

Layer에 있다고 자동으로 화면에 보이는 것도 아닙니다

Object가 정상적으로 Spawn되고 Component까지 준비됐다고 해서 화면에 자동으로 그려지는 것은 아닙니다.

대표 GameObject는 Late_Update에서 해당 Frame의 Render Group에 자신을 등록합니다.

Runtime Object
→ Late_Update
→ Add_RenderObject
→ CRenderer Render Group Queue
→ Draw
→ Render Pass
→ Player-visible Result

Render Group은 영구 Object List가 아닙니다. Object가 매 Frame 다시 등록하고, Renderer가 그 Frame의 Queue를 소비합니다.

따라서 Layer에 Object가 존재하는 것과 이번 Frame의 Render Group에 등록되는 것도 다른 단계입니다.

Object가 Layer 안에는 존재하지만 화면에 보이지 않는다면 다음 순서로 범위를 나눠볼 수 있습니다.

1. Spawn 자체가 실패했는가?
2. 필요한 Component가 빠졌는가?
3. Late_Update가 호출되는가?
4. Render Group 등록이 되었는가?
5. 올바른 Group에 들어갔는가?
6. 해당 Render Pass에서 Draw되는가?

이 구분을 알게 된 뒤에는 “안 보인다”는 증상만 보고 바로 Shader 문제라고 단정하지 않게 됐습니다.

🔡 Source 2A~2B. Late_Update → Add_RenderObject — 이번 Frame의 Render 대상으로 넘어가는 경계

Layer에 Object가 존재하는 것과, 이번 Frame에 실제로 그려질 Object로 등록되는 것은 다른 단계입니다.

이 Handoff는 GameObject 쪽 호출과 Renderer 쪽 Queue 등록을 분리해서 두 장으로 읽습니다.

Source 2A — CBody_SpongeBob::Late_Update

파일: DX11-B01_Screenshot_02_Source_RenderGroup_Handoff0_CBody_SpongeBob_LateUpdate.png

대표 Runtime Object인 SpongeBob Body가 Late_Update에서 Renderer 쪽으로 자신을 넘기는 호출 경계를 보여줍니다.

Layer에 존재하는 Runtime Object
→ Late_Update
→ Add_RenderObject(...)

이 장에서 볼 핵심은 “SpongeBob Class가 있다”가 아니라, 이미 살아 있는 Runtime Object가 이번 Frame의 Render 후보로 등록되는 시점입니다.

Source 2B — CRenderer::Add_RenderObject

파일: DX11-B01_Screenshot_02_Source_RenderGroup_Handoff1_CRenderer_AddRenderObject.png

CRenderer::Add_RenderObject가 전달받은 Object를 해당 Render Group Queue에 넣는 경계를 보여줍니다.

GameObject::Late_Update
→ CRenderer::Add_RenderObject
→ Render Group Queue
→ 이후 Draw Pass에서 소비

두 장을 연결하면 다음 구분이 명확해집니다.

Layer
= Runtime Object가 살아 있는 Container
 
Render Group
= 이번 Frame에 Renderer가 소비할 Queue

즉:

Layer에 존재한다 ≠ 이번 Frame에 자동으로 Draw된다

이 Evidence는 특정 Runtime 숫자보다 Owner / Handoff / Frame Responsibility가 핵심이기 때문에 정적 Source로 보여주는 편이 더 읽기 좋습니다.

실제 Runtime에서는 Source와 Player-visible Result를 같이 봅니다

B01의 목적은 Manager 이름을 많이 보여주는 것이 아닙니다.

대표 Object 하나를 기준으로:

Prototype
→ Clone
→ Component
→ Layer
→ Update / Late_Update
→ Render Group
→ Screen

까지 이어지는 흐름을 설명할 수 있는지가 더 중요했습니다.

그래서 내부 Watch 화면을 여러 장 붙이기보다, 실제 Object가 생성되고 World에 나타나는 Runtime 결과를 함께 사용합니다.

🎥 Video 1. 대표 Object가 Runtime에 Spawn되고 실제 World에 표시되는 과정

파일: DX11-B01_Video_01_Runtime_Object_Spawn_To_Visible.mkv

이 영상은 B01에서 가장 중요한 Player-visible Runtime Evidence입니다.

촬영 흐름은 단순합니다.

처음에는 해당 Object가 없음
→ Spawn 실행
→ Object가 World에 등장
→ Camera를 조금 이동
→ Scene 안에서 계속 정상적으로 표시됨

이 영상이 담당하는 Claim은 다음 한 줄입니다.

Source에서 확인한 Prototype → Clone → Layer → Render 경로가 실제 Client Runtime에서 Object Spawn과 Player-visible Result까지 이어집니다.

여기서 Video가 모든 내부 구현을 증명한다고 말하지 않습니다.

역할을 나누면:

Source 1A~1C
→ Prototype → Clone → Layer 구조
 
Source 2A~2B
→ Late_Update → Render Group Handoff
 
Video 1
→ 실제 Spawn → World Visible Result

입니다.

즉 Source는 책임과 경계를 설명하고, Video는 실제 실행 결과를 닫습니다.

같은 Spawn 경로는 Runtime Tool에서도 다시 사용합니다

이 Object Lifecycle은 Gameplay Object에만 쓰이지 않습니다.

Runtime Tool에서 Scene Object를 배치할 때도 기존 Spawn 경로를 다시 사용합니다.

Prototype 선택
→ Layer 선택
→ World Position
→ Add_GameObject_ToLayer
→ Runtime Clone
→ Layer 삽입

Tool 전용 Object Creation System을 따로 두는 대신 게임이 원래 사용하는 Runtime Spawn Path로 연결했습니다.

그래서 Tool에서 생성한 Object도 기존 Layer의 Update / Collision / Render 흐름으로 들어갑니다.

저장된 Scene Object를 다시 불러올 때도 같은 원리가 이어집니다.

Saved Object State
→ Prototype / Layer Identity
→ Transform State
→ GAMEOBJECT_DESC
→ Add_GameObject_ToLayer
→ Runtime Clone Reconstruction

현재 Source에서는 Position / Scale / Rotation을 저장하고 복원하는 경로가 있지만, Rotation 단위 변환과 Save / Load Roundtrip 같은 Persistence 상세는 B03에서 따로 다룹니다.

B01에서는 Tool과 Load도 동일한 Runtime Spawn Path를 다시 사용한다는 연결만 가져갑니다.

Object가 안 보일 때는 마지막 단계부터 추측하지 않습니다

이 구조를 정리한 가장 큰 이유는 Class 이름을 외우기 위해서가 아니라, 문제가 생겼을 때 확인 순서를 만들기 위해서였습니다.

1. Prototype이 등록됐는가?
2. Spawn 요청이 들어왔는가?
3. Find_Prototype이 성공했는가?
4. Clone이 성공했는가?
5. Initialize / Ready_Components가 성공했는가?
6. 필요한 Component가 붙었는가?
7. 올바른 Layer에 들어갔는가?
8. Update / Late_Update가 호출되는가?
9. Render Group에 등록됐는가?
10. 올바른 Render Pass에서 Draw되는가?
11. 화면에 실제로 보이는가?

이 순서를 사용하면 “안 보인다 → Shader 문제인가?”처럼 마지막 단계부터 추측하지 않고, 처음 Expected와 Actual이 달라지는 지점을 찾을 수 있습니다.

이 사고방식은 이후 B04의 Map Transition 문제를 좁힐 때도 그대로 이어졌습니다.

Source에서 확인한 구조와 Runtime 결과는 구분합니다

현재 Source에서 확인되는 Object Lifecycle의 역할을 정리하면 다음과 같습니다.

다만 Source에서 Lifecycle을 확인했다는 것이 모든 내부 단계를 최신 Runtime Trace로 전부 증명했다는 뜻은 아닙니다.

그래서 Evidence마다 역할을 분리했습니다.

현재 공개 Evidence에는 B01 전용 Breakpoint / Watch Screenshot을 별도로 두지 않았습니다.

따라서 정적 Source를 **“이번 실행에서 Watch 값까지 확인한 증거”**라고 설명하지 않습니다. 더 깊은 면접 질문이 들어오면 Prototype Tag / Clone Result / Layer Tag 같은 Runtime State를 Debugger로 추가 확인할 수 있지만, 공개 글의 핵심 Claim은 현재의 Source + Runtime Video만으로 닫습니다.

B01 Evidence Map — 각 자료가 맡는 질문

B01의 Evidence는 역할 기준으로 세 묶음입니다.

Spawn Source
Render Handoff Source
Runtime Result

실제 파일은 Source를 읽기 좋은 크기로 나눠 총 6개입니다.

Evidence를 읽는 순서는 다음처럼 가져가면 가장 쉽습니다.

① Add_GameObject_ToLayer0
Prototype Resolve
 
→ ② Add_GameObject_ToLayer1
Runtime Clone
 
→ ③ Add_GameObject_ToLayer2
Layer Insert
 
→ ④ CBody_SpongeBob::Late_Update
Render Handoff 시작
 
→ ⑤ CRenderer::Add_RenderObject
Frame Render Queue 등록
 
→ ⑥ Runtime Video
실제 World Visible

여섯 자료의 목적은 코드 양을 보여주는 것이 아닙니다.

독자가 Source를 직접 해석하지 않아도 Prototype → Runtime Instance → Layer → Frame Render Queue → Player-visible Result의 순서를 따라갈 수 있게 배치합니다.

게임 클라이언트 관점에서 이 흐름이 중요한 이유

Object가 보이지 않는 문제를 하나의 “렌더링 버그”로 묶으면 확인 범위가 너무 넓어집니다.

B01의 Lifecycle을 기준으로 나누면 문제를 단계별로 좁힐 수 있습니다.

Spawn 자체가 안 됨
→ Prototype / Clone / Layer
 
Object는 살아 있는데 동작이 이상함
→ Component / Update
 
Object는 살아 있는데 화면에 안 보임
→ Late_Update / Render Group / Draw

즉 이 구조를 이해하는 목적은 Framework 용어를 외우는 것이 아니라, 증상에 따라 최초 실패 경계를 빠르게 찾는 것입니다.

면접에서 30초로 설명한다면

“이 Framework에서는 Prototype 등록만으로 Object가 World에 존재하는 것이 아닙니다. Spawn 요청이 Add_GameObject_ToLayer로 들어오면 Prototype을 찾고 Clone해서 Runtime Instance를 만든 뒤 Layer에 넣습니다. Layer의 Object는 Update 흐름을 거치고, Late_Update에서 Renderer의 Render Group에 등록돼야 이번 Frame의 Draw 대상으로 이어집니다. 저는 이 경계를 Source로 나눠 확인했고, 실제 Spawn 결과가 World에 표시되는 것은 Runtime Video로 별도 검증했습니다.”

이 답변에서 중요한 것은 Manager 이름의 나열이 아니라:

Prototype
→ Runtime Instance
→ Runtime Container
→ Frame Render Queue
→ Player-visible Result

를 한 흐름으로 설명하는 것입니다.

정리

DX11-SpongeBob-BFBB의 Object Runtime을 가장 짧게 줄이면:

Prototype
= 생성 가능한 원형
 
Runtime Clone
= 실제 게임에서 살아 있는 Instance

이고, Runtime Clone은 다음 흐름을 거쳐야 실제 Player-visible Result까지 이어집니다.

Clone
→ Initialize / Component
→ Layer
→ Update / Late_Update
→ Render Group
→ Render

제가 이 구조에서 가져간 핵심은 Prototype / Layer라는 용어 자체가 아니라, Runtime Object가 살아나는 각 단계의 Owner와 실패 지점을 나눠서 추적하고, Source에서 본 구조가 실제 Runtime State와 Player-visible Result로 이어지는지 확인할 수 있게 된 경험입니다.

다음 B02에서는 여기서 한 단계 뒤로 이어서, Render Group에 들어간 불투명 World Object가 GBuffer → Lighting → Deferred Composite를 거쳐 최종 화면이 되는 흐름을 정리합니다.