35년 전 게임을 뜯어본다는 것
혹시 옛날 게임이 어떻게 만들어졌는지 궁금했던 적 있으세요? 한 개발자가 1990년에 나온 DOS 레이싱 게임 Test Drive III의 월드맵 데이터를 통째로 역설계(리버스 엔지니어링)해서 공개했어요. 역설계가 뭐냐면, 소스코드 없이 완성된 프로그램이나 데이터 파일만 보고 "이게 안에서 어떻게 돌아가는지"를 거꾸로 알아내는 작업이에요. 마치 레시피 없이 완성된 요리를 먹어보면서 재료와 조리법을 추리하는 거랑 비슷해요.
이게 왜 흥미롭냐면, 1990년이면 컴퓨터 사양이 정말 처참하던 시절이거든요. 메모리는 640KB 남짓, 저장 매체는 1.44MB 플로피 디스크였어요. 요즘 사진 한 장도 안 들어가는 용량에 "드라이브하며 돌아다니는 3D 세계"를 욱여넣어야 했어요. 그걸 어떻게 했는지가 이 프로젝트의 핵심이에요.
비트맵이 아니라 '수식과 도형'으로 세계를 그렸어요
요즘 게임은 지형을 보통 하이트맵(heightmap)이라는 거대한 이미지로 저장해요. 픽셀 하나하나가 그 지점의 높이를 나타내는 방식이죠. 그런데 이러면 용량이 어마어마해져요. 1990년엔 그럴 여유가 없었어요.
Test Drive III는 대신 벡터/폴리곤 기반으로 세계를 표현했어요. 이게 무슨 말이냐면, 산이나 도로, 건물을 픽셀 그림으로 저장하는 게 아니라 "여기서 저기까지 선을 긋고, 이 좌표들을 이어서 면을 만들어라" 하는 좌표와 명령의 묶음으로 저장한 거예요. 점 몇 개와 연결 규칙만 있으면 큰 지형도 아주 작은 데이터로 표현되거든요. 글자로 "반지름 5인 원"이라고 쓰는 게 원을 픽셀로 다 그린 이미지보다 훨씬 가벼운 것과 같은 원리예요.
역설계한 개발자는 게임의 데이터 파일을 바이트 단위로 뜯어보면서, 어떤 숫자가 도로의 좌표인지, 어떤 값이 지형의 높이나 오브젝트 배치인지를 하나하나 알아냈어요. 그리고 그 해독한 규칙을 코드로 다시 짜서, 게임 속 월드맵 전체를 현대 컴퓨터에서 이미지로 렌더링해 복원하는 데까지 성공했어요. 즉 "데이터 포맷의 설계도"를 통째로 재구성한 거죠. 이런 작업은 보통 헥스 에디터(파일을 16진수 숫자 그대로 보여주는 도구)와 끝없는 추론, 그리고 값을 살짝 바꿔보고 결과를 관찰하는 노가다의 반복이에요.
업계 맥락: 레트로 역설계는 살아있는 학문이에요
이런 작업이 한 사람의 취미로만 끝나는 게 아니에요. 비슷한 흐름으로 옛 게임을 분석해 현대 환경에서 돌리는 디컴파일 프로젝트들이 활발하거든요. 슈퍼 마리오 64나 젤다의 전설을 C 코드로 완전 복원한 사례, 둠(DOOM)의 엔진을 온갖 기기에 이식한 사례가 대표적이에요. 게임 보존(preservation) 관점에서도 중요해요. 원본 디스크가 썩어 없어지기 전에 그 안의 데이터 구조를 사람이 읽을 수 있는 형태로 기록해두면, 문화유산을 디지털로 박제하는 셈이 되니까요.
한국 개발자에게 주는 시사점
"옛날 게임 분석이 나랑 무슨 상관이야" 싶을 수 있는데요, 의외로 실무 근육이 길러져요. 우리가 일하다 보면 문서 하나 없는 레거시 시스템, 출처 불명의 바이너리 로그 파일, 사양서 사라진 외부 장비 프로토콜을 만날 때가 있거든요. 그럴 때 필요한 게 바로 이 "규칙 없는 데이터에서 패턴을 찾아내는 감각"이에요. 데이터를 16진수로 펼쳐놓고 가설을 세우고 검증하는 과정 자체가 똑같아요.
또 하나, 이 사례는 제약이 창의를 만든다는 걸 보여줘요. 용량이 부족했기에 절차적 생성과 벡터 표현이라는 영리한 해법이 나왔어요. 요즘처럼 자원이 넘치는 시대에도, 모바일이나 임베디드처럼 빡빡한 환경에선 이런 발상이 그대로 무기가 돼요.
마무리
디스켓 한 장에 세계를 담으려던 35년 전 엔지니어의 고민을, 한 개발자의 끈질긴 역설계가 다시 세상에 꺼내줬어요. 여러분도 분석해보고 싶은 추억의 게임이나 정체 모를 바이너리 파일이 있나요? 어떤 걸 뜯어보고 싶으신지 궁금하네요.
🔗 출처: Hacker News