27년 된 N64 게임이 PC 네이티브로 돌아온다
1999년에 닌텐도64로 나온 '오우거 배틀 64: Person of Lordly Caliber'라는 게임이 있어요. 스퀘어에 합병되기 전 퀘스트(Quest)라는 회사가 만든 택티컬 RPG인데, 부대를 편성해서 맵 위에서 실시간으로 움직이는 독특한 시스템 덕분에 지금도 팬층이 두터운 작품이거든요. 이 게임을 에뮬레이터 없이 PC에서 바로 실행할 수 있게 만드는 프로젝트가 있는데, lfarroco라는 개발자가 진행 중인 'Ogre Battle 64 Recompiled'가 진행률 99.05%에 도달했다는 소식이에요.
숫자만 보면 '거의 다 됐네' 싶지만, 이런 프로젝트에서 마지막 1%가 앞의 99%만큼 어려운 경우가 많아요. 그래서 오늘은 이 프로젝트가 어떤 기술 위에 서 있는지, 왜 이런 방식이 최근 레트로 게임 씬에서 유행하는지 차근차근 풀어볼게요.
에뮬레이션과 리컴파일, 뭐가 다를까
먼저 리컴파일(recompilation)이 뭐냐면, 게임 롬 안에 들어 있는 N64 CPU용 기계어를 미리 C 코드로 번역해 놓고, 그걸 다시 내 PC용으로 컴파일하는 방식이에요. 흔히 쓰는 에뮬레이터와 비교하면 차이가 확실히 보이는데요.
에뮬레이터는 통역사예요. 게임이 실행되는 동안 N64의 CPU(MIPS R4300i)가 할 일을 한 줄 한 줄 실시간으로 읽어서 내 PC의 CPU가 알아듣게 옮겨줘요. 그래서 원본 하드웨어의 타이밍이나 특이한 동작까지 흉내 내야 하고, 그만큼 CPU를 많이 쓰죠. 반면 정적 리컴파일은 번역서예요. 게임을 실행하기 전에 기계어 전체를 한 번에 C 코드로 바꿔놓기 때문에, 실행할 때는 그냥 일반적인 PC 프로그램처럼 돌아가요.
이 방식을 대중화한 게 Wiseguy라는 개발자가 만든 N64Recomp라는 도구예요. 2024년에 이 도구로 만든 '젤다의 전설 무쥬라의 가면' 리컴파일 버전(Zelda 64: Recompiled)이 나오면서 이 방식이 널리 알려졌죠. 원본은 20fps 언저리에서 돌아가던 게임이 네이티브로 옮겨지니까 고해상도, 와이드스크린, 높은 프레임레이트, 입력 지연 감소 같은 걸 훨씬 자연스럽게 붙일 수 있게 됐거든요. 그래픽은 RT64라는 전용 렌더러가 담당해서, N64의 그래픽 명령(디스플레이 리스트)을 현대 GPU API로 그려주는 구조예요.
디컴파일과는 또 다른 이야기
여기서 헷갈리기 쉬운 게 디컴파일(decompilation)이에요. 슈퍼 마리오 64나 시간의 오카리나 디컴파일 프로젝트처럼, 사람이 기계어를 읽고 원래 개발자가 썼을 법한 C 소스코드를 손으로 복원하는 작업이거든요. 컴파일했을 때 원본 롬과 바이트 단위로 똑같아질 때까지 맞추는 거라 몇 년씩 걸려요. 대신 결과물은 사람이 읽고 고칠 수 있는 진짜 소스코드가 되죠.
반면 리컴파일은 기계적으로 번역하는 거라 훨씬 빠르지만, 나오는 C 코드는 사람이 읽기엔 거의 불가능한 형태예요. 레지스터 이름이 변수가 되고, 분기문이 goto로 도배되는 식이죠. 하지만 목적이 '게임을 현대 PC에서 잘 돌리는 것'이라면 그걸로 충분해요.
그럼 99.05%라는 숫자는 뭘까요? 이런 프로젝트에서는 롬 안의 코드를 얼마나 문제없이 변환하고 동작을 확인했는지를 추적하는 경우가 많아요. 남은 부분은 보통 골치 아픈 것들이에요. 실행 중에 메모리에 코드를 올렸다 내렸다 하는 오버레이, 실행 중에 자기 자신을 고쳐 쓰는 코드, 그래픽 마이크로코드처럼 CPU 밖에서 도는 부분, 그리고 게임마다 다른 사운드 처리 같은 것들이죠. 이런 건 도구가 자동으로 처리 못 하니까 사람이 하나씩 손봐야 해요. 마지막 1%가 오래 걸리는 이유예요.
법적인 부분은 어떻게 되나
이런 프로젝트가 배포하는 건 '변환 도구와 패치'이지 게임 자체가 아니에요. 사용자가 본인이 소유한 롬 파일을 직접 넣어야 실행 파일이 만들어지는 구조예요. 리컴파일 결과물에 원본 저작물이 들어가지 않도록 신경 쓰는 거죠. 그래도 닌텐도가 유주(Yuzu) 에뮬레이터를 소송으로 문 닫게 한 전례가 있어서, 이 씬의 개발자들은 늘 조심스럽게 움직여요.
레트로 게임 보존 씬의 흐름
지금 레트로 게임 보존 쪽에는 크게 세 갈래 흐름이 있어요. 첫째는 전통적인 에뮬레이터 개선(Mupen64Plus, ares 등), 둘째는 손으로 하는 디컴파일(SM64, 시간의 오카리나 기반 Ship of Harkinian, 퍼펙트 다크), 셋째가 바로 이 자동 리컴파일이에요. 디컴파일이 '완벽하지만 느린' 길이라면, 리컴파일은 '충분히 좋고 빠른' 길이라 최근에 여러 N64 게임들이 이 방식으로 옮겨지고 있죠. 오우거 배틀 64처럼 디컴파일 팀이 붙기엔 팬층이 작은 게임에는 특히 현실적인 선택이에요.
한국 개발자에게 주는 시사점
게임에 관심 없어도 배울 게 많은 분야예요. 정적 바이너리 번역은 애플이 인텔 맥 앱을 애플 실리콘에서 돌리려고 만든 Rosetta 2의 핵심 원리이기도 하거든요. 소스코드가 없는 레거시 바이너리를 새 플랫폼으로 옮겨야 하는 상황은 산업 현장에도 꽤 있어요. 그리고 컴파일러 백엔드, 명령어 집합(ISA), 링커 동작 같은 저수준 지식을 실전으로 익히기에 이만한 교재가 없어요. N64Recomp 소스는 공개돼 있으니 MIPS 명령어가 어떻게 C 코드로 바뀌는지 한 번 따라가 보는 것만으로도 공부가 돼요.
정리하며
핵심 한 줄로 요약하면, 오우거 배틀 64 리컴파일은 '에뮬레이터 없이 27년 된 게임을 네이티브 PC 프로그램으로 되살리는' 프로젝트고, 이제 마지막 1%의 어려운 구간을 지나고 있어요.
여러분은 어떻게 생각하세요? 게임 보존을 위해 이런 기술적 우회로가 계속 발전하는 게 맞다고 보시나요, 아니면 결국 권리사가 공식 리마스터로 풀어야 할 문제일까요? 그리고 손으로 하는 디컴파일과 자동 리컴파일 중 어느 쪽이 장기적으로 더 가치 있다고 보시는지도 궁금해요.
🔗 출처: Hacker News