절망편: 지옥에서 돌아온 개발자의 고백
안녕하세요. 게임 개발 5년차, 현재 번아웃 상태로 치킨집 알바를 고민하고 있는 개발자입니다.
여러분들이 제가 겪은 지옥을 반복하지 않기를 바라면서, 피눈물로 얻은 교훈들을 공유합니다.
MonoBehaviour 지옥의 시작
처음 게임 개발을 시작했을 때의 나는 정말 순진했습니다. MonoBehaviour에 모든 로직을 때려박으면 되겠다 싶었어요. Update() 함수 안에 플레이어 조작, 애니메이션, 사운드, UI 업데이트까지 전부 넣고, 각 GameObject마다 스크립트 하나씩 붙이면 완벽하다고 생각했죠. 그렇게 태어난 것이 1000줄짜리 PlayerController.cs였습니다. 디버깅할 때마다 어디서 뭐가 터졌는지 찾기 위해 Ctrl+F만 몇백 번을 눌렀는지 모르겠어요. 다른 개발자가 제 코드를 보더니 “이게 뭔 개떡같은…” 하며 도망가는 모습을 보고서야 뭔가 잘못됐다는 걸 깨달았습니다.
싱글톤 만능주의의 함정
그 다음엔 싱글톤 패턴이라는 걸 알게 됐어요. 오, 이거다 싶었죠. GameManager, SoundManager, UIManager… 뭐든 Manager 붙이고 싱글톤으로 만들면 어디서든 접근할 수 있으니까 엄청 편하잖아요? 그런데 시간이 지날수록 모든 클래스가 서로를 참조하는 의존성 지옥이 펼쳐졌습니다. 유닛 테스트를 하려고 해도 모든 게 연결되어 있어서 불가능했고, 나중에 멀티플레이어 모드를 추가하려니 싱글톤들이 발목을 잡더라고요. 메모리 누수는 덤이었습니다.
bool 변수로 때운 상태 관리
상태 관리는 또 어떻게 했냐면, bool 변수로 대충 때웠어요. isJumping, isAttacking, isDead, isInvincible, isSliding… 이런 식으로 스무 개쯤 만들어놓고 if문으로 체크했죠. 그 결과 플레이어가 죽었는데 점프하는 버그, 공격 중인데 슬라이딩하는 기괴한 모션이 나오기 시작했습니다. QA팀에서는 매일 버그 리포트 폭격이 날아왔고, 저는 if문 지옥에서 헤어나올 수 없었어요.
“나중에 최적화하자”는 착각
최적화는 당연히 나중에 하면 된다고 생각했습니다. “일단 돌아가게 만들고 나중에 최적화하자”는 마음으로 닥치는 대로 코딩했죠. 그 결과 프레임드랍으로 게임이 슬라이드쇼가 됐고, 메모리 사용량은 2GB를 넘나들었습니다. 모바일에서는 3초 만에 앱이 크래시 났고, 출시 2주 전에 전체 시스템을 리팩토링해야 하는 지옥을 맛봤어요.
문서화를 무시한 댓가
코드 리뷰와 문서화는 아예 무시했습니다. “코드가 곧 문서다”, “나만 이해하면 된다”라고 생각했거든요. 그런데 6개월 후에 제가 짠 코드를 제가 이해할 수 없더라고요. 팀원들과는 소통이 불가능했고, 버그를 수정하려다가 더 큰 버그를 만들어내는 일이 반복됐습니다. 새 기능을 추가할 때마다 기존 기능이 망가지는 건 일상이었어요.
절망의 늪에서
매일 밤늦게까지 사무실에서 버그와 씨름했습니다. 코드를 고치면 다른 곳이 터지고, 그걸 고치면 또 다른 곳이 터지는 무한 루프였어요. 게임 개발이 꿈이었는데, 어느 순간 코드만 봐도 구역질이 나더라고요. “내가 뭘 잘못했을까?” 매일 자책하며 집에 돌아갔습니다. 동료들도 하나둘 퇴사하고, 프로젝트는 계속 지연되고… 정말 모든 걸 포기하고 싶었어요.
그런데…
절망적이던 어느 날, 우연히 이 책을 발견했습니다.
“Unity 6 Scriptable Object 활용 가이드” https://batstudio.gumroad.com/l/unity6so/
처음엔 “또 다른 이론서겠지…”라고 생각했는데, 목차를 보는 순간 충격이었어요.
희망편: 다시 살아날 수 있었던 이유
ScriptableObject의 깨달음
이 책을 통해 ScriptableObject의 진짜 위력을 알게 되었습니다. 지금까지 저는 ScriptableObject를 단순한 데이터 컨테이너 정도로만 생각했는데, 이 책에서는 게임 아키텍처의 핵심으로 사용하는 방법을 보여줬어요. 몬스터 스탯이나 아이템 데이터를 ScriptableObject로 분리하니까 기획자가 직접 밸런싱을 할 수 있게 됐고, 이벤트 시스템을 ScriptableObject 기반으로 구축하니까 그 끔찍했던 의존성 문제들이 해결되기 시작했습니다. 게임 설정을 모듈화하니까 A/B 테스트도 쉬워졌어요.
새로운 아키텍처 패턴의 발견
책에서 소개하는 Event-Driven Architecture를 적용하니까 정말 다른 세상이 펼쳐졌습니다. ScriptableObject 기반 이벤트 시스템으로 각 시스템들이 서로 독립적으로 동작하면서도 필요할 때만 소통할 수 있게 됐어요. Data-Oriented Design을 통해 데이터와 로직을 완전히 분리하니까 코드의 가독성이 엄청나게 향상됐고, Modular System 덕분에 플러그 앤 플레이 방식으로 새로운 기능을 추가할 수 있게 됐습니다. Runtime Sets라는 개념을 통해서는 동적 객체 관리가 이렇게 쉬울 수가 없더라고요.
코드의 변화와 팀워크의 기적
예전에 500줄짜리 PlayerController를 썼다면, 이제는 PlayerStats ScriptableObject를 만들어서 깔끔하게 구조화할 수 있게 됐어요. 진짜 코드가 시처럼 아름다워진 기분이었습니다.
무엇보다 팀워크에 기적이 일어났습니다. 기획자가 ScriptableObject로 직접 게임 밸런싱을 할 수 있게 됐고, 아티스트는 이펙트 데이터를 직접 설정할 수 있게 됐어요. 개발자인 저는 로직에만 집중할 수 있게 됐고, 버그는 90% 정도 감소했습니다. 더 이상 밤늦게 사무실에 남아있을 필요도 없어졌어요.
지금의 나
이제 매일 정시에 퇴근합니다. 코드가 깔끔해지니까 디버깅도 쉽고, 새 기능을 추가하는 것도 두렵지 않아요. 무엇보다 게임 개발이 다시 즐거워졌습니다. 동료들도 “코드가 이렇게 읽기 쉬울 수가 있냐”며 놀라워하고, 신입 개발자들도 금방 적응하더라고요.
만약 지금 저처럼 스파게티 코드의 지옥에서 헤매고 계신다면, 늦지 않았습니다. ScriptableObject 기반 아키텍처는 단순히 Unity의 기능이 아니라, 게임 개발 사고 방식의 패러다임 전환이에요. 이 책 하나로 제 개발자 인생이 180도 바뀌었습니다. 여러분도 저처럼 번아웃에서 벗어나 다시 게임 개발의 즐거움을 찾으시길 바라며…
치킨집 알바는 접었습니다. 이제 게임 개발이 다시 제 천직이라고 확신해요.
(이 글은 가상의 인물을 통해 스토리를 전달하는 픽션입니다)
