수단의 목적화 경계
“게임(유니티) 샘플 프로젝트를 공부하자!” 라고 할 때, 99% 주니어가 이렇게 학습함
- 일단 이 Scene 하나부터 씹어 먹어야겠다
- 일단 이 Folder에 있는 Script부터 씹어 먹어야겠다
정말 최악임.
웬만하면 “저” 방법들은 효율이 안 나온다.
왜냐!!
게임 엔진 기반의 프로젝트들은. Web & App 과는 견줄 수 없는 복잡성이 있음.
[Code] [Inspector] [Hierarchy] ⇒ 이 3가지를 모두 확인해야 하는 미친 난이도를 요한다.
(그래서 ChapGPT 활용도 영리하게 해야 함. 이건 다음에 말해보고)
중요한 건 목적을 생각해야 됨.
보통 목적은 딱 2가지다.
기능 구현이 목적인 경우 ex) 플레이어 스폰하기, 이동시키기 등
개발 구조 습득이 목적인 경우 ex) 얕게는 코드/폴더 컨벤션 + 깊게는 추상화 구조/Scene 구조
거의 95% 이상은 전자이고... (XR 한정. 다른 게임은 안 만들어봐서)
기능 구현이 목적일 때
기능과 관련된 C# Script, Prefab, Scene, 관련 Asset 들은
단언하건대. 한 Scene에 있거나, 한 Folder에 있을 확률이 적다.
기본적으로 유니티에서는 ‘GameObject’를 중심으로 실행이 이루어지기 때문에-
나는 Prefab부터 보는 걸 좋아함.
1. 이름 검색으로 가장 Core “같은” Prefab을 찾고
2. 어떤 Mono 컴포넌트가 있는지 적어놓고
3. 코드 에디터 열어서, “참조”로 엮인 구조를 뜯어보기 시작함
4. 그러면 자동으로 연관된 [추상화 개념, 분기되어 있는 Prefab, 관련 Scriptable Asset] 까지 리스트업할 수 있음
개발 구조 습득이 목적일 때
여기서는! [Folder 하나만 조진다] 라는 마인드가 괜찮을 수 있다
특히. “개발자 생산성”을 압도적으로 중요시하는 우리 팀에서는 Utils 폴더를 정말 자주 해킹함.
결국 DX가 좋으면, 복리로 시간을 벌어주기 때문.
chatGPT 형님이 Editor 관련 코드 하나 만큼은 전지구 1위의 실력자라고 한들
DX는 “정말 아는 만큼만 원하게 되는 분야”임.
왜냐면. 게임 엔진의 UI에 사고의 틀이 제한되거든! (모든 걸 당연하게 여기게 됨. 이건 내가 감내해야 하는 거야~ 라는 마인드가 자리잡히기 쉽다)
마치 노션만 쓰다보면 사고의 틀이 “수직적”이 되듯이.
그래서 선배 개발자님들의 샘플을 많이 들여다 봐야 함.
결국 게임 개발자 뿐만 아니라
수단이 목적화 되는 것을 정말로. 정말로. 정말로. 경계해야 함.