21.07.08 - Recovering From Recompilation

해당 강의는 Cat Like Coding의 다음 글을 참고했습니다.

영어가 되신다면 좋은 공부가 되실 것 같습니다.

 

https://catlikecoding.com/unity/tutorials/object-management/multiple-scenes/

Multiple Scenes

 

굉장히 어려운 파트였네요.

사실 전부 다 한것도 아니고, 한 1/4 했습니다. 그 한 쿼터로 2시간 넘게 붙잡았네요...

 

해당 파트에서 하려는 것에 대해서 이야기를 하자면

기존에 만들어둔 Shape Factory.cs (Scriptable Object = Asset)를 이용해서 사용자는 prefab들을 Shape의 형태에 따라 분류를 해서 일괄적으로 생산할 수 있습니다.

(그리고 한 강 전에는 recycle 방식을 이용해 Destroy를 쓰지 않고 물체를 제거한 듯하게 보이는 방식을 했고요)

 

문제는 Instantiate를 하게 되면 hierarchy 상에서 계속 목록이 늘어난다는 것입니다.

'보기 힘들다'라고 할 수 있죠. 물론 Create Empty를 해서 빈 Object를 만들어 parent로 하고, Instantiate된 Object들을 자식 계층으로 넣어주면 보기에는 편하겠지만, parenting이 컴퓨터에게는 그렇게 쉬운 것도 아니고, 코드적으로도 신경써야 할 부분들이 좀 생깁니다; (라고 하네요.)

 

그래서 사용하는 방법이 뭐냐, 제목에서도 보시다시피 'Multiple Scene'을 만들어, 그 부분에 Object들을 보관하는 것입니다.

 

의도는 쉬운데, 저에게 좀 어려운 표현들이 많았던지라 이래저래 잊어먹지 말라고 정리했습니다.

 

(1) Recompile

1/4동안 자주 등장한 표현입니다. 저도 정확히는 모르겠습니다만, 아마 hot reload처럼 editor상에 runtime에서 코드를 수정했을 때 이것이 바로 컴파일되어 다시 적용되는 방식을 의미하는게 아닐까 추측합니다.

 

이 예제가 recompile을 필요로 할지는 좀 의문입니다만 일단 '그렇다'라고 가정을 하면 다음 문제가 생깁니다.

Unity는 '모든 것'에 대해서 recompile을 해주는 것은 아니라는 것.

 

대표적으로 Shape Factory.cs의 경우는 Scriptable Object를 상속받기 때문에 Recompile 대상에서 벗어납니다.

만약 run time에서 다른 쪽의 코드를 고치게 된다, 그렇다면 이 Shape Factory는 그냥 '처음부터 다시' 시작되게 됩니다.

 

이것의 가장 큰 문제점이자, Shape Factory에 이후 추가하는 코드들의 의미가 중요하겠죠.

Recompile이 지원되지 않기 때문에 해당 스크립트가 참조하고 있던 데이터와의 링크가 끊어집니다. (즉 데이터 자체는 남아있는데, 이를 참조하던 변수의 값이 초기화되는 것)

 

이 정도만 알면... 됩니다.

 

(2) Root Object

사실 지금 생각해보면 hierarchy 상에서 최상위에 있는 Object를 의미하는 것이겠지만 

'그래서 이 용어가 왜 등장하는데?'에 포커스가 더 맞춰졌던 것 같습니다.

 

다음 '표현'을 보면 그 의미가 조금 더 명확해지겠습니다.

"Root Object without Parents"

 

지금 우리의 최종 목표는 'Object들의 계층적 가시화 용이'입니다. 눈에 보이기 쉽도록 정리하는 것이라고요.

그래서 별도의 empty object를 부모로 parenting하는 대신, 새로운 scene을 만들어서 넣기로 합니다.

 

그러면 '겉으로 보기에는' 어떤가. 마치 Scene이 Instantiate된 물체들의 parent처럼 보입니다.

(물론 다시 말하지만 진짜로 parent인게 아닙니다!)

 

일단 실질적인 부모가 없으니, 새로운 scene으로 옮겨진 각 물체들은 일단 최상위 object인 root이며,

동시에 한번 더 강조해서 without parents가 된 겁니다.

 

아무튼 이 파트에서 계속 나오는 Root Object는 그냥 Instantiate하고 새로운 Scene으로 옮긴 녀석들을 지칭하는 말이라고 생각하면 됩니다.

 

(3) Data Serialization

직역하면 '데이터 직렬화'

조금 풀어서 설명하면 데이터를 저장하기 위한 조치/조정이라고 하면 되겠다.

 

이건 (1)에서 말한 Recompile과 상통하는 것 같은데, 이 Recompile과정에서 data serialization이 발생한다.

반대로 recompile을 해주지 않는 Shape Factory 같은 것들은 data serialization 과정이 없다.

 

그러니 결국은 (1)에서 한 이야기의 연장선상일 뿐이다.

 

(4) 결론: 그래서 우리가 뭘 하려던 건가

위 이야기들을 다 합치면, Shape Factory에 추가하던 그 코드들이 무엇인지 이해가 갑니다.

 

우리는 hierarchy 상에 Instantiate된 물체들이 막 떠도는 게 싫었고, 그래서 별도의 Scene을 만들어 옮기기로 합니다.

이를 위해서는 Instantiate된 물체들과 새로운 Scene의 데이터를 참조할 변수가 필요했고, 이는 Shape Factory에서 초기화/관리합니다.

 

문제는 Recompile이(혹시나) 발생할 경우, Shape Factory에 변수들은 data serialization을 거치지 못하고 그냥 초기화되는데 이 때문에 Shape Factory와 방금 만든 데이터 사이에 참조 즉 링크가 끊어지게 됩니다.

 

그래서 이 링크를 다시 되찾고, 데이터가 중복 생성되지 않도록 조정해주는 과정이 필요한 것이죠.