무슨 일이 있었나요?
1996년 닌텐도 64로 나온 슈퍼 마리오 64를 애플의 공간 컴퓨터 Vision Pro에서 플레이하는 방법을 다룬 글이 나왔어요. 30년 가까이 된 게임을 최신 헤드셋에서 돌린다니 그냥 재밌는 해킹처럼 들리는데요, 이게 어떻게 가능해졌는지 따라가 보면 리버스 엔지니어링, 컴파일러, 그래픽 API 추상화까지 개발자가 배울 거리가 잔뜩 숨어 있어요.
물론 어떤 플랫폼이든 에뮬레이터로 돌리는 방법도 있어요. 그런데 슈퍼 마리오 64가 특별한 건 에뮬레이션을 넘어서 새 플랫폼용으로 직접 컴파일하는 네이티브 이식까지 되는 게임이라는 점이에요. 그 출발점이 바로 디컴파일 프로젝트예요.
디컴파일 프로젝트가 뭐냐면
2019년에 팬 개발자들이 슈퍼 마리오 64 ROM 안의 기계어를 사람이 읽을 수 있는 C 코드로 되돌리는 작업을 사실상 끝냈어요. 더 놀라운 건 이게 매칭 디컴파일(matching decompilation)이라는 거예요. 복원한 C 코드를 당시와 같은 컴파일러로 다시 빌드하면 원본 ROM과 바이트 하나까지 똑같은 결과물이 나와요.
완성된 케이크를 분석해서 레시피를 거꾸로 써냈는데, 그 레시피대로 구우면 원래 케이크와 분자 하나까지 똑같은 케이크가 나오는 셈이에요. 이 작업이 비교적 수월했던 이유로는 원본 게임 일부가 컴파일러 최적화 없이 빌드됐다는 점이 자주 언급돼요. 최적화를 거치면 코드가 많이 뒤섞이는데 그게 덜해서 원래 구조를 추적하기 쉬웠던 거죠.
소스 코드가 생기면 뭐가 달라질까요?
소스 코드가 있으면 다른 CPU, 다른 운영체제용으로 다시 컴파일할 수 있어요. 남은 숙제는 그래픽이었어요. N64 게임은 그래픽 칩에 보내는 전용 명령(디스플레이 리스트)으로 화면을 그리는데요, 이 명령을 OpenGL이나 DirectX 같은 현대 그래픽 API 호출로 바꿔주는 번역 계층을 중간에 끼워 넣은 거예요.
그렇게 2020년 무렵 PC 네이티브 포트가 나왔고, 와이드스크린과 높은 해상도, 높은 프레임레이트 같은 개선도 붙었어요. 그 뒤로 안드로이드, 웹어셈블리로 도는 브라우저 버전, 각종 휴대용 기기까지 퍼져서 이제는 안 돌아가는 곳을 찾기가 더 어려워요. Vision Pro 이야기도 이 흐름에서 나온 거라고 보시면 돼요.
Vision Pro에서는 뭐가 다를까요?
Vision Pro가 일반 화면과 다른 점은 두 눈에 각각 다른 이미지를 보여준다는 거예요. 제대로 된 입체감을 주려면 카메라를 두 대 두고, 사람 눈 사이 거리만큼 살짝 떨어뜨려서 장면을 두 번 그려야 해요. 이걸 스테레오스코픽(stereoscopic) 렌더링이라고 해요. 슈퍼 마리오 64는 원래 3D 게임이라 장면에 깊이 정보가 다 들어 있어서, 이렇게 입체로 확장하기에 유리한 편이에요.
물론 그냥 되는 건 아니에요. visionOS에서 몰입형 화면을 직접 그리려면 Metal 같은 애플 그래픽 API에 맞춰 렌더링 계층을 손봐야 해요. 30fps 기준으로 돌던 게임 로직을 헤드셋의 높은 주사율에서 부드럽게 보여주려면 프레임 보간 같은 처리도 고민해야 하고요. 다행히 visionOS는 블루투스 게임 컨트롤러를 지원해서 조작 쪽은 비교적 간단해요.
업계 맥락: 디컴파일과 리컴파일의 시대
슈퍼 마리오 64 이후로 레트로 게임 디컴파일은 하나의 흐름이 됐어요. 젤다의 전설 시간의 오카리나도 디컴파일을 거쳐 PC 포트가 나왔고, 포켓몬스터 초기작들은 훨씬 전부터 디스어셈블리 프로젝트가 진행돼 왔어요. 2024년에는 N64Recomp라는 도구도 나왔어요. 사람이 C 코드를 한 줄씩 복원하는 대신 N64 기계어를 C 코드로 자동 변환하는 정적 리컴파일 방식이라 이식 속도가 훨씬 빨라졌어요.
법적인 부분도 짚고 넘어갈게요. 이런 프로젝트들은 보통 원본 게임 에셋을 포함하지 않고, 사용자가 직접 가진 ROM에서 에셋을 추출해서 빌드하게 되어 있어요. ROM 파일을 공유하면 저작권 문제가 되니까 조심하셔야 해요.
한국 개발자에게 주는 시사점
게임 개발자가 아니어도 배울 게 많아요. 우선 컴파일러와 어셈블리 공부에 이만한 교재가 없어요. 코드가 어떻게 기계어가 되는지 거꾸로 따라가 볼 수 있거든요. 소스는 사라지고 바이너리만 남은 레거시 시스템을 옮겨야 할 때도 비슷한 사고방식이 그대로 쓰여요.
그래픽 명령 번역 계층은 소프트웨어 설계 사례로도 좋아요. 렌더링 백엔드를 추상화해 두면 OpenGL에서 Metal이나 Vulkan으로 갈아끼우기 쉬워지잖아요. 우리 서비스도 외부 의존성을 인터페이스 뒤에 숨겨두면 플랫폼이 바뀔 때 훨씬 잘 버틸 수 있어요.
마무리
한 줄 정리: 30년 된 게임이 최신 헤드셋에서 돌아가는 건 코드를 다시 읽어낸 사람들 덕분이에요.
여러분은 디컴파일이나 네이티브 포트로 다시 해보고 싶은 옛날 게임이 있나요? 바이너리만 남은 레거시 시스템을 다뤄본 경험이 있다면 그 얘기도 들려주세요.
🔗 출처: Hacker News