오래된 게임의 원본 소스 코드를 복원하는 디컴파일(decompilation)은 팬 커뮤니티와 보존 활동가들 사이에서 오랫동안 이어져 온 작업이다. 목표는 단순하다. 컴파일된 기계어를 사람이 읽을 수 있는 C 코드로 되살리되, 그 C를 다시 컴파일하면 원본과 완전히 동일한 기계어가 나오도록 맞추는 것이다. 이번에 화제가 된 사례는 닌텐도 64용 스노보드 키즈(Snowboard Kids) 초대작으로, 프로젝트 기준 84일 만에 전 함수의 100% 매칭이 완료됐다. 후속작인 스노보드 키즈 2가 596일이 걸렸던 것과 비교하면 약 7분의 1 수준의 기간이다.
작성자 본인은 이 격차를 두고 "2026년이니 답의 일부는 AI"라고 인정하면서도, 그것으로 전부를 설명하는 것은 지나친 단순화라고 못 박는다. 실제로 이번 프로젝트에서 전문가의 직접 개입이 필요했던 매칭 커밋은 약 4.8%에 불과했지만, 작성자는 그 소수의 개입이 없었다면 프로젝트가 89~90% 지점에서 멈췄을 것이라고 평가한다. 또한 이미 2년 가까이 유사 프로젝트를 진행하며 숙련도가 크게 올라간 점, 그리고 초대작이 2,145개 함수로 후속작(2,995개)보다 규모가 작았던 점도 함께 작용했다. AI, 누적된 숙련, 작은 규모가 겹친 결과라는 것이다.
컴파일러가 만든 진짜 난관
흥미로운 대목은 어려움의 성격이다. 함수가 무엇을 하는지 이해하는 일 자체는 대체로 큰 장벽이 아니었다. 문제는 그 로직이 C로 어떻게 표현됐고, 당시 컴파일러가 그것을 어떻게 기계어로 바꿨는지를 역으로 재현하는 데 있었다. 초대작은 후속작이 쓴 GCC 2.7.2가 아니라 SGI의 독점 컴파일러 IDO 5.3으로 빌드됐다. IDO는 소스가 공개되지 않았고 개발 환경이 이미 폐기된 SGI 하드웨어에 묶여 있어, 커뮤니티가 툴체인 일부를 역공학하고 현대 하드웨어에서 돌아가도록 정적 재컴파일까지 해야 했다.
IDO는 최적화와 코드 생성을 여러 패스로 나눠 공격적으로 코드를 변형한다. 그래서 C를 조금만 바꿔도 레지스터 할당이 전혀 다른 결과로 튀어나온다. 작성자는 IDO의 동작을 재현하는 일이 아직 과학보다 예술에 가깝다고 표현하며, 사람도 LLM도 그 출력을 그대로 뽑아내는 데 능하지 않다고 인정한다. 통상적인 작업 흐름은 함수의 목적을 파악해 근사한 C를 쓴 뒤, permuter로 미세한 차이를 좁히는 방식이었지만, 구조 자체가 틀렸을 때는 permuter만으로 매칭에 도달할 수 없었다.
에이전트를 굴리는 실전 기법
이번 프로젝트가 이전과 달랐던 점은 처음부터 최신 모델과 성숙한 에이전트 하네스를 쓸 수 있었다는 것이다. 실무적으로 눈여겨볼 만한 기법이 여럿 등장한다. 우선 libultra나 libmus 같은 표준 라이브러리 코드는 게임 고유 코드가 아니어서 온라인에 원본이 존재하는데, N64Sym 같은 도구로 후보를 식별한 뒤 에이전트에게 "밑바닥부터 다시 짜지 말고 기존 라이브러리 소스를 출발점으로 삼아 SDK 버전과 컴파일 옵션을 먼저 소진하라"고 강하게 프롬프트하는 것이 관건이었다. 또 m2c를 미매칭 함수 전체에 자동으로 돌려 완전 일치만 통합하는 스크립트도 만들었는데, 1,830개 중 17개(0.93%)만 맞췄지만 토큰을 태우는 것보다 저렴했다.
반복되는 IDO의 버릇을 축적하기 위해, 에이전트가 발견한 컴파일러 특성을 DECOMPILATION_LEARNINGS.md에 기록하도록 유도한 점도 주목할 만하다. 한 에이전트가 발견한 일반화 가능한 단서가 문서로 남아 이후 에이전트의 매칭 성공률을 높이는 피드백 루프가 형성됐다. 가장 유용했던 자원은 N64 Decomp Workbench로, 후기 단계 MIPS 불일치를 분류하고 릴로케이션을 반영하며 개별 컴파일러 패스를 재현해, 단순 어셈블리 diff가 알려주지 못하는 "왜 다른가"를 짚어준다. 작업은 네 개의 Git 워크트리로 병렬 진행했고, 각 태스크에 명시적 마감을 부여해 permuter가 무한정 도는 문제를 통제했다.
병렬화는 새로운 문제도 낳았다. 워크트리들이 갈라지면서, 한쪽에서 매칭된 99% 유사 함수가 다른 쪽 에이전트에게는 병합 전까지 보이지 않았다. 네 개를 주기적으로 병합해 동기화했지만 한 번에 한 시간이 넘게 걸렸다. 해법으로 유사도 검색이 모든 워크트리를 들여다보게 바꿔, 새로 매칭된 함수가 즉시 다른 에이전트의 참조가 되도록 했다. 동기화는 여전히 변경을 통합·푸시하는 데 필요했지만, 에이전트끼리 배우기 위한 필수 절차에서는 벗어난 셈이다.
모델 비교와 남은 과제
모델 비교는 작성자 스스로 "전혀 과학적이지 않다"고 전제한 인상평이다. 변화하는 난이도의 함수들에, 때로는 다른 모델이 이미 손댄 상태에서 시험했기 때문이다. 그래도 대체로 Codex 계열이 Claude를 앞섰고, 이용 가능해진 뒤의 Sol xhigh가 특히 효과적이었다고 한다. 반면 z.ai가 서빙하는 GLM 5.2는 예전의 넉넉하던 사용 한도가 줄고 지연이 심해 피드백 주기가 길어지면서 결국 구독을 해지했다고 밝혔다. 특정 도구에 대한 개인 경험담인 만큼 성능 지표로 받아들이기보다 워크플로 적합성 참고로 읽는 편이 안전하다.
한 가지 분명히 해둘 점은 100% 매칭이 곧 완전한 이해를 뜻하지 않는다는 것이다. 모든 함수의 C 코드는 확보했지만, 자동 생성된 이름을 바꾸고 미상의 구조체 필드를 식별하며 데이터를 서술하는 문서화 작업은 이제부터다. 작성자는 비교 대상으로 74일 만에 끝난 파일럿윙스 64를 들며, 적절한 전문성과 직관을 갖춘 인간 팀이라면 AI 없이도 이 속도에 필적하거나 능가할 수 있다고 선을 긋는다. 한국의 실무자에게 이 사례가 주는 함의는 게임 보존이라는 특수 영역을 넘어선다. 즉 정답을 기계적으로 검증할 수 있는 문제(재컴파일 결과의 바이트 단위 일치)에서, 에이전트 병렬화·마감 강제·학습 문서 축적·워크트리 간 즉시 참조 같은 하네스 설계가 성과를 좌우하며, 소수의 인간 전문가 개입이 마지막 10%를 여는 열쇠가 된다는 점이다.