20년 된 N64 게임 스노보드 키즈 2, 마침내 100% 디컴파일 완료

디컴파일이 뭐고, 왜 사람들이 이걸 할까요?

게임 좋아하시는 분이라면 한 번쯤 들어보셨을 거예요. 디컴파일(decompile) 이라는 단어. 쉽게 설명하면 이래요. 우리가 짠 C 코드는 컴파일러를 거쳐 0과 1로 된 기계어로 바뀌어서 게임 ROM 안에 들어가잖아요. 디컴파일은 그 반대 작업이에요. 기계어를 거꾸로 분석해서 "원본 C 코드가 어떻게 생겼을지" 복원하는 거죠. 그것도 그냥 비슷한 코드가 아니라, 다시 컴파일했을 때 원본 ROM과 한 바이트도 틀리지 않게 똑같이 나오는 정도까지 맞춰내는 작업이에요.

이걸 영어로 "matching decompilation"이라고 하는데, 보통 N64나 GameCube 같은 옛날 콘솔 게임을 대상으로 커뮤니티가 자발적으로 모여서 진행해요. Super Mario 64, Ocarina of Time, Paper Mario 같은 굵직한 작품들이 이미 100% 디컴파일됐고, 최근에는 1999년에 나온 N64 레이싱 게임 스노보드 키즈 2(Snowboard Kids 2) 가 이 리스트에 합류했어요.

100%라는 게 어떤 의미인가요?

많은 분들이 오해하시는데, 100% 디컴파일은 "게임을 다 분석했다"는 단순한 의미가 아니에요. ROM 안에 있는 모든 어셈블리 명령어 하나하나가 사람이 읽을 수 있는 C 코드로 대응되고, 그 C 코드를 다시 컴파일하면 원본과 바이트 단위로 완벽히 같은 ROM이 나오는 상태를 말해요. "byte-perfect match" 또는 "OK" 상태라고 부르죠.

이게 왜 어렵냐면, 똑같은 동작을 하는 C 코드라도 어떻게 짜느냐에 따라 컴파일러가 다른 어셈블리를 뱉어내거든요. 변수 선언 순서, 루프를 for로 짤지 while로 짤지, 임시 변수를 쓸지 말지 — 이런 미세한 차이가 결과 바이너리를 바꿔버려요. 그래서 디컴파일러들은 IDO나 GCC 같은 당시 사용된 컴파일러 버전을 그대로 띄워놓고, 자기가 짠 C 코드의 컴파일 결과를 원본과 끊임없이 비교하면서 "왜 다르지?"를 추적해요. 마치 역공학으로 컴파일러의 마음을 읽는 작업인 셈이에요.

어떻게 진행됐을까요?

스노보드 키즈 2 프로젝트는 비교적 적은 인원이 매달려서 끝낸 케이스예요. 기존에 잘 정리된 N64 디컴파일 도구 생태계가 있어서 가능했죠. splat 이라는 도구로 ROM을 코드, 데이터, 그래픽 같은 섹션으로 쪼개고, m2c 나 mips_to_c 같은 도구로 MIPS 어셈블리를 일단 대략적인 C로 변환해요. 그다음 사람이 그걸 가독성 있게 다듬고, decomp.me 같은 온라인 매처에서 원본과 1:1로 맞을 때까지 코드를 조정하는 거예요.

특히 이 게임이 흥미로운 건 일본 개발사 Racdym이 만든 작품이라 일본 내수용 코드 스타일이나 한자 처리, 캐릭터셋 같은 디테일까지 복원해야 했다는 점이에요. 게임에 등장하는 캐릭터 데이터 구조, 보드 물리 시뮬레이션, AI 경로 탐색 로직 같은 것들이 전부 사람이 읽을 수 있는 형태로 살아났다는 게 이번 작업의 결실이에요.

왜 이런 일을 할까요?

"옛날 게임 분석해서 뭐가 그렇게 좋은데?" 싶을 수 있어요. 그런데 100% 디컴파일이 되면 진짜 많은 일이 가능해져요. 우선 PC 포팅이 쉬워져요. 소스가 있으니까 윈도우, 리눅스, 맥, 심지어 웹 브라우저로도 네이티브 포팅이 가능해지죠. Mario 64 PC 포트가 4K 60fps로 돌아가는 영상 보신 분들 많을 텐데, 그게 다 디컴파일 덕분이에요.

그리고 모드와 ROM 해킹의 차원이 달라져요. 기존엔 어셈블리 패치로 깨작깨작 수정하던 걸, 이제 C 코드를 직접 고쳐서 빌드할 수 있어요. 신규 캐릭터 추가, 신규 코스 제작, 멀티플레이어 강화 같은 대규모 개조가 가능해지는 거죠. 버그 수정과 QoL(Quality of Life) 패치도 마찬가지로 훨씬 쉬워져요. 또 에뮬레이터 개발자들에게도 큰 도움이 돼요. 게임이 하드웨어를 정확히 어떻게 사용하는지 코드로 볼 수 있으니까, 정확도 높은 에뮬레이션을 만드는 레퍼런스가 되거든요.

업계 흐름에서 보면

레트로 게임 보존(preservation)은 지난 몇 년간 큰 흐름을 이루고 있어요. zeldaret 팀의 Ocarina of Time, Majora's Mask, pmret 팀의 Paper Mario, sm64 팀의 Mario 64가 대표적인 성공 사례죠. 닌텐도가 공식적으로 옛날 게임을 다시 살려주지 않는 상황에서, 팬 커뮤니티가 자발적으로 "게임을 디지털 화석에서 살아있는 코드베이스로" 되살리고 있는 거예요.

법적으로는 회색 지대예요. 디컴파일된 코드만 공개하고 원본 에셋(그래픽, 사운드, 텍스트)은 포함하지 않는 방식, 즉 "빌드하려면 원본 ROM이 있어야 한다"는 구조로 권리 문제를 우회해요. 그래도 닌텐도가 마음먹으면 언제든 법적 조치가 들어올 수 있는 위태로운 균형이긴 해요. 실제로 Yuzu 에뮬레이터 사건처럼 압박이 가해진 사례도 있고요.

한국 개발자에게 주는 시사점

직접적인 업무 연관은 적지만, 배워둘 가치가 있는 영역이에요. 우선 리버스 엔지니어링 스킬 자체가 보안, 임베디드, 성능 분석 등 다양한 분야에서 쓰여요. MIPS 어셈블리를 읽고 C로 옮기는 훈련은 어떤 아키텍처를 만나도 응용할 수 있는 기본기예요. 그리고 빌드 시스템과 컴파일러 동작 원리를 깊이 이해하게 돼요. 같은 C 코드가 컴파일러 버전, 최적화 옵션, 코드 배치에 따라 어떻게 다른 어셈블리로 변하는지 직접 보게 되니까요.

관심 있다면 decomp.me에 들어가서 작은 함수 매칭부터 도전해볼 수 있어요. 한국에서 만든 옛날 게임 — 슈퍼 쥬쥬, 어스토니시아 스토리 같은 — 도 누군가는 보존해야 하잖아요. 한국 게임의 역사를 코드 레벨로 남기는 일에 동참해볼 수도 있고요.