사람들은 흔히 말하죠. 게임 개발에서 컨텐츠가 잘려나가는 건 '완성도'를 위한 숭고한 희생이라고. 순 엉터리입니다. 적어도 제가 2014년에 '언던'이라는 인디 게임을 만들다가 스팀에서 출시 3일 만에 판매 중단 크리를 맞았을 때 깨달은 진실은, 컨텐츠 삭제는 거의 대부분 '기능적 결함'을 감추기 위한 땜빵이라는 거예요. 그걸 가장 극명하게 보여주는 사례가 바로 다크소울 1편의 E3 2011 데모 빌드에만 존재했던 언데드 교구의 하부 구조입니다. 이 얘기는 그냥 '미공개 데이터' 덕후들의 가십이 아니고, 저 같은 망한 개발자의 피눈물과 직결된 이야기라서 꺼내봅니다.
### 아노르 론도가 아니라 '그곳'이었다
다크소울 1편의 첫 데모 빌드를 데이터 마이닝해보면, 지금은 흔적만 남은 몇몇 지역의 완전한 지오메트리가 존재했어요. 가장 충격적인 건 불사의 교구에서 지하 묘지로 이어지는 '썩은 수도원'이라는 미완성 던전입니다. 현재 버전에서는 그냥 낭떠러지에 난간 쳐놓고 못 가게 막아뒀죠. 그런데 이 던전의 적 배치가 아주 가관이었어요. 지금은 망자의 묘지에서나 보는 휠 스켈레톤이 무려 6마리, 그것도 어둠 속에서 튀어나오도록 스폰 포인트가 찍혀 있었습니다.
다들 아시겠지만, 휠 스켈레톤의 회전 히트박스는 당시 물리 엔진인 하복(Havok)의 연산 최적화에 심각한 악영향을 주는 놈이었어요. 프롬소프트웨어의 엔지니어들이 이 던전을 통째로 날려버린 건, PS3의 256MB밖에 안 되는 시스템 메모리에서 이 미친 회전 히트박스가 초당 60프레임 검사를 못 버텨서 발생하는 프레임 드랍을 감당할 수 없었기 때문이라고 확신합니다. 미학적인 판단이 아니라, 하드웨어의 물리적 한계에 부딪힌 거죠.
### 비아냥거리는 개구리와 프레임의 상관관계
이걸 제 게임에 대입해보면, 저는 당시 유니티 2017.3으로 2D 로그라이크를 만들면서 스프라이트가 200개 넘게 겹치는 슬라임 합체 보스를 구현했어요. 데모 빌드에서 깔쌈하게 돌아갔거든요. 그런데 스팀의 실제 배포 환경에서 그래픽 카드가 120종 넘게 달라지면서, 그 합체 연산이 특정 AMD 구형 드라이버와 충돌을 일으켜서 게임이 무한 로딩에 빠지는 현상이 터졌습니다. 저는 프롬처럼 던전을 날릴 배짱도 없었고, 결국 그 보스를 게임에서 삭제하는 대신 밋밋한 화염구 하나 던지고 끝나는 놈으로 교체했죠. 유저 평가는 "보스전이 초라하다"로 박살났고요.
핵심은 여기 있어요. 여러분이 어떤 창작물에서 '미완성'이라며 잘라내거나 마케팅에서 '의도된 방향성'이라고 포장하는 던전들, 그 본질은 대부분 엔지니어가 "아 이거 콘솔에서 돌아가긴 하냐?"라고 내뱉은 한마디에서 시작된 버그 리포터예요. 그런 걸 마치 신비로운 이스터에그나 전설의 무대인 양 숭배하는 건, 개발자 입장에서는 그저 웃픈 일일 뿐이죠. 저는 그 '썩의 수도원'을 볼 때마다, 3일 만에 내려야 했던 제 게임의 비참한 리뷰 점수가 떠올라서 마음이 몹시 헛헛해집니다.
그러니까 이런 미공개 데이터를 볼 때는 "와 미친 숨겨진 보스가 있었네" 같은 감상보다는, "이걸 짜른 개발자는 당시에 어떤 기술 부채에 시달렸을까?" 라는 좀 더 삐딱한 시선을 가져보는 게 좋다고 조언해주고 싶네요. 여러분 생각은 어떤지 모르겠지만, 저는 그게 더 게임을 진짜로 이해하는 길이라고 봐요. 당신이 만약 이걸 그저 낭만으로 소비하는 플레이어라면, 지금 당장 그 던전이 왜 사라졌는지에 대한 메모리 할당 그래프를 한번 찾아보시길 권합니다. 세상에 낭만은 없고, 오직 하드웨어 한계와의 처절한 싸움뿐이라는 걸 깨닫게 될 테니까.