지난주 유니티 입문 개인과제 피드백이 나왔다.
결과는 참혹했다.
"고민이 실제 '게임'이라는 결과물로 이어지지 못한 점이 가장 큰 문제로 보입니다. 복잡한 구조나 기교보다는, 실제로 작동하는 게임을 만들고, 플레이 가능한 형태로 완성해보는 것이 우선입니다."
뼈를 맞은 기분이었다.
더 뼈아픈 건, 나도 알고 있던 문제였다는 것이다.
착각의 시작
튜터님의 피드백 중 이런 부분이 있었다.
"ServiceLocator의 존재 목적이 불분명하며, 단순히 씬별 매니저를 관리하기 위한 용도라면 RuntimeSceneLoader에서 매니저들을 직접 로드하는 쪽이 훨씬 단순하고 명확합니다."
처음엔 이해가 안 갔다.
내 RuntimeSceneLoader는 BootstrapSceneLoader가 전달한 SceneName을 받아 씬을 로딩하는 단순한 클래스였고, ServiceLocator 역시 "이 정도 프로젝트면 이 정도 구조가 적당하겠지"라는 생각으로 만든 것이었다.
그래서 직접 찾아가 물었다.
"그렇다면 이런 프로젝트에선 의존성을 어떻게 처리하는 게 좋을까요?"
돌아온 답은 예상치 못했지만, 너무나 명확했다.
"애초에 그런 걸 고민하는 것부터가 틀렸어요."
YAGNI를 체화하지 못한 이유
YAGNI (You Aren't Gonna Need It)
몇 번을 되새겨도 체화되지 않는다.
프로덕션 레벨이라면 설계가 선행되어야 하는 게 맞다. 하지만 이런 규모에서 완벽한 설계가 가능할까?
뼈대만 짜고, 개발하고, 필요하면 리팩토링한다.
그게 개발의 기본 원칙인데, 난 계속 반대로 했다.
컴플렉스일까, 트라우마일까.
"나중을 위한 설계"라는 핑계로 불필요한 복잡도만 쌓아 올렸다.
진짜 문제는 결과물이었다
만약 내가 합리적인 구조를 만들었고, 그 구조를 토대로 그럴듯한 결과물을 냈다면 문제가 되지 않았을 것이다.
하지만 현실은:
- 기존 프로젝트에서 대충 복사해온 소스코드는 당위성을 잃은 채 복잡함만 가져왔고
- "이틀 만에 완성했다"며 내팽개친 프로젝트는 제대로 된 디버깅도 없이 방치됐다
- 소스코드 구조도 망가졌고, 불필요한 코드로 가득 찼고, 결과물도 형편없었다
- 필수과제조차 완성하지 못했다
무엇을 놓쳤나
ServiceLocator를 쓴 이유가 "이 정도면 적당하겠지"였다면, 그건 이유가 아니라 변명이다.
튜터님 말대로 RuntimeSceneLoader에서 직접 로드하는 게 더 단순하고 명확했는데, 난 "괜찮은 구조"를 만들겠다고 불필요한 레이어만 추가했다.
더 웃긴 건, 그 "괜찮은 구조" 덕분에 게임이 나아진 게 하나도 없다는 것이다.
플레이어는 ServiceLocator가 있든 없든 신경 안 쓴다. 그들은 그냥 재밌는 게임을 원할 뿐이다.
배운 것
1. 결과물이 먼저다
설계는 결과를 내기 위한 수단이지, 그 자체가 목적이 아니다.
"이렇게 구조 짜면 나중에 편하겠지"가 아니라 "이게 지금 필요한가?"를 먼저 물어야 한다.
2. YAGNI는 구호가 아니라 원칙이다
You Aren't Gonna Need It.
필요하지 않으면 만들지 마라. 필요해지면 그때 만들어라.
이게 개발의 기본인데, 난 계속 "미래를 대비한다"는 핑계로 과잉설계를 정당화했다.
3. 완성도는 코드가 아니라 경험에서 나온다
내 코드는 "그럴싸해" 보였을지 몰라도, 게임은 "그럴싸하지" 않았다.
코드 구조를 고민하는 시간에 버그 하나라도 더 고쳤어야 했다.
- 일단 돌아가는 걸 만들자. 완벽한 설계는 그다음이다.
- 복잡한 구조보다 단순하고 명확한 코드가 낫다.
- 그리고 무엇보다, 결과물로 말하자.
이번 과제는 뼈아팠지만, 덕분에 명확해졌다.
다음엔 쓸데없는 고민 말고, 게임부터 완성하자.
