2006년에 출시된 '소닉 더 헤지혹'(통칭 소닉 06)이 완성도 낮은 게임으로 악명 높다는 사실은 널리 알려져 있다. 그러나 이 게임에 '잘려 나간 콘텐츠'가 얼마나 많은지, 그리고 그것이 왜 그렇게 되었는지는 의외로 잘 알려져 있지 않다. 최근 'Marathon Recompiled' 프로젝트를 진행하던 개발자들이 소닉 06의 핵심 시스템, 특히 렌더링 구조를 깊이 뜯어보면서 그 전말이 조금씩 드러나고 있다. 같은 게임 안에서도 크라이시스 시티처럼 반사, 파티클, 극적인 조명이 살아 있는 구역이 있는가 하면, 캐슬 타운처럼 평면적이고 생기 없는 구역이 공존하는 이유가 바로 여기에 있다.
베타 영상을 보면 최종판에 없는 효과들이 다수 확인된다. 킹덤 밸리에는 범프 맵이 적용돼 있었고, 캐슬 타운에는 더 복잡한 지오메트리와 식물, 제대로 된 조명과 그림자가 있었으며, 뉴 시티의 충돌 데이터는 한때 전혀 다른 건물 배치를 염두에 두었음을 시사한다. 흥미로운 점은 이렇게 잘려 나간 요소 상당수가 실제로는 게임 파일 안에 여전히 남아 있다는 것이다. 다만 성능 문제 때문에 활성화되지 않았을 뿐이다. 축소된 비주얼로도 실기에서 목표 프레임에 도달하기 버거웠던 만큼, 개발 막판 크런치 속에서 이런 기능들이 가장 먼저 희생된 것은 놀라운 일이 아니다.
셰이더 변형으로 깎아낸 비주얼
이 기능들이 어떻게 꺼졌는지는 셰이더 구조를 보면 드러난다. 소닉 06의 대부분은 Terrain 셰이더 또는 Billboard 셰이더로 렌더링되는데(이름과 달리 Billboard는 실제 빌보드 처리가 아니다), 둘 다 00~07번까지 기능 수준이 다른 여러 변형을 가진다. 일반적으로 숫자가 높을수록 더 풍부한 기능 집합을 지원한다. 그런데 게임에서 가장 많이 쓰인 셰이더가 하필 Billboard02다. 이 변형은 정점 단위 조명만 지원할 뿐 캐스케이드 섀도 맵(CSM)도, 점광원도 지원하지 않는다. 게임의 상당 부분이 기본 알베도 텍스처와 환경광만으로 그려져 칙칙해 보이는 근본 이유다.
문제는 단순히 더 높은 변형으로 교체하면 되는 일이 아니라는 점이다. 변형마다 입출력 레이아웃이 다르고, 각 재질이 쓰는 텍스처는 오브젝트의 .xno 파일에 정의돼 있다. 노멀 맵이나 범프 맵이 파일에는 존재해도 .xno가 이를 참조하지 않는 경우가 있어, 셰이더만 바꿔서는 효과가 살아나지 않는다. 실제 교체 시도는 대부분 각종 기법이 깨지는 결과로 이어졌다.
그림자와 조명의 어긋남
그림자 역시 온전치 않다. 게임은 최대 4개의 캐스케이드를 쓰도록 설계됐지만, GenerateCSMLevels와 GenerateCSMObjects 설정을 통해 twn_a 등 일부 구역에서는 레벨이 3, 오브젝트가 2로 낮춰져 그림자가 닿는 거리가 크게 줄었다. 멀티플레이는 전 구역에서 이 축소된 값을 쓴다. 제대로 그려질 때조차 섀도 액니(shadow acne) 아티팩트가 심한데, 보통 셰도 맵 샘플에 작은 엡실론 값을 더해 해결하지만 소닉 팀은 이 처리를 하지 않았다. 또 오브젝트마다 그림자 기여 여부를 잘못 설정한 사례가 있어, 크라이시스 시티 스노보드나 특정 컷신 속 엘리제의 치마에 그림자가 빠지는 문제가 생긴다.
조명 시스템 자체는 이론상 꽤 유연하다. 오브젝트마다 고정 환경광 몇 개와 그림자를 드리우지 않는 저렴한 점광원 여러 개를 둘 수 있다. 그러나 소닉 팀은 오브젝트당 점광원을 2개로 제한했고, 더 큰 문제는 스테이지 설계가 이 한도를 지키지 않았다는 데 있다. 킹덤 밸리는 비교적 충실히 지킨 반면, 플레임 코어와 더스티 데저트는 오브젝트당 8개 이상을 욕심내 광원들이 우선순위를 두고 '다투며' 무작위로 켜지고 꺼진다. 개발 막판 한도가 급격히 낮아지고 상당수 오브젝트가 픽셀 단위에서 정점 단위 조명으로 바뀐 것이 겹치면서, 바닐라에서는 점광원이 한도를 지킨 스테이지에서조차 거의 작동하지 않는다.
리컴파일이 되찾은 것과 남은 과제
리컴파일판에서는 점광원을 망가뜨리던 최적화 로직을 걷어내 바닐라보다 훨씬 안정적으로 광원을 표시하는 데 성공했다. 다만 2개 제한 자체는 그대로 남아 있다. 점광원 기여를 더하는 조명 계산이 최종 셰이더 바이트코드 안에 모두 인라인·언롤돼 있어, 셰이더마다 코드 모양이 달라 식별과 수정이 까다롭기 때문이다. 반사 처리도 비슷하다. 싱글플레이는 실시간 평면 반사를 쓰는데(해상도가 프레임버퍼의 1/4로 제한되지만 이는 쉽게 패치된다), 멀티플레이는 비용을 아끼려 이를 밋밋한 고정 큐브맵으로 대체했다. 렌더 그래프를 Lua 스크립트로 구성하는 구조상, 멀티용 render_gamemode_multi.lua에는 핵심인 RenderReflection() 호출이 아예 빠져 있고, 싱글용 스크립트를 그대로 가져다 쓸 수도 없다. 멀티 렌더러는 분할 화면을 위한 두 개의 프레임버퍼 처리 단계를 따로 갖고 있어, 반사를 넣어도 이 환경에서는 의도대로 동작하지 않는다.
이 분석이 한국의 실무 개발자에게 주는 시사점은 분명하다. 성능 예산을 맞추기 위한 막판 조정—조명 한도 축소, 셰이더 다운그레이드, 캐스케이드 삭감—이 서로 맞물리면, 개별 결정 하나하나는 합리적이어도 전체적으로는 복구조차 어려운 부채로 남는다는 점이다. 특히 셰이더 바이트코드에 로직이 인라인되고 재질 참조가 데이터 파일에 흩어져 있으면, 자산과 코드가 강하게 결합돼 사후 교체가 사실상 불가능해진다. 소닉 06의 많은 문제는 역량이 아니라 시간 부족에서 비롯됐고, 게임 파일 안에는 아직 꺼내지 못한 가능성이 남아 있다. 설령 모든 수정이 리컴파일에 반영되지 못하더라도, 이 게임의 백엔드를 이해하는 과정 자체가 향후 개선과 패치의 토대가 되고 있다.