에뮬레이터 개발은 언제나 타협의 연속입니다. 특히 PowerPC 아키텍처를 사용하는 Xbox 360 같은 복잡한 콘솔을 x86 기반의 PC 환경에서 구동하려면, JIT(Just-In-Time) 컴파일러가 만들어내는 런타임 오버헤드와 캐시 미스 문제를 피할 수 없죠. 최근 Hacker News에서 크게 화제가 된 ReXGlue 인터뷰 기사를 읽으면서, 저는 이 프로젝트가 단순한 게임 에뮬레이터를 넘어 시스템 엔지니어링 관점에서 대단히 우아한 해결책을 제시하고 있다고 느꼈습니다.

오늘은 ReXGlue가 어떻게 JIT의 한계를 벗어나 정적 재컴파일(Static Recompilation) 시대를 열고 있는지, 그리고 이것이 기술적으로 어떤 의미를 갖는지 깊게 파헤쳐 보겠습니다.

JIT의 한계와 AOT의 우아함

기존의 대표적인 Xbox 360 에뮬레이터인 Xenia는 JIT 방식을 사용합니다. 스레드가 실행될 때 PowerPC 인스트럭션을 실시간으로 번역하고, 코드 캐시를 관리하며, 런타임 최적화 결정을 내립니다. 이 방식은 호환성 면에서는 훌륭하지만, 필연적으로 컨텍스트 스위칭과 번역 오버헤드가 발생합니다.

ReXGlue의 창립자인 Tom은 이 문제를 AOT(Ahead-Of-Time) 컴파일로 해결했습니다. 게임의 원본 바이너리에 있는 모든 PowerPC 인스트럭션을 오프라인 상태에서 분석하고, 이를 네이티브 C++ 코드로 변환한 뒤 Clang을 통해 컴파일합니다.

솔직히 처음 이 접근법을 들었을 때 저는 약간 반신반의했습니다. 복잡한 콘솔 아키텍처, 특히 분기 예측이나 메모리 배리어가 독특한 PowerPC 코드를 정적으로 완벽히 번역한다는 건 엄청난 예외 처리 지옥을 의미하기 때문입니다. 하지만 ReXGlue의 실행 모델을 보면 고개가 끄덕여집니다.

// ReXGlue의 Dispatch Table 개념적 예시
void ExecuteGuestFunction(uint32_t guest_address) {
    // JIT처럼 런타임에 명령어를 해석하거나 캐시를 뒤지지 않음
    // 시작 시점에 채워진 네이티브 함수 포인터를 직접 호출
    auto native_func = DispatchTable::Lookup(guest_address);
    if (native_func) {
        native_func();
    }
}

런타임에는 인스트럭션 해석도, 캐시 관리도 없습니다. 함수 디스패치 테이블은 시작 시점에 네이티브 함수 포인터로 한 번만 채워집니다. 이 방식의 가장 큰 장점은 디버깅 과 프로파일링 입니다. GDB나 LLDB 같은 표준 디버거를 연결해 코드를 스텝 단위로 실행할 수 있고, Clang의 강력한 최적화 파이프라인(O3, LTO 등)을 그대로 활용할 수 있습니다. 레거시 시스템을 마이그레이션 해본 엔지니어라면, 블랙박스 같던 JIT 환경이 투명한 네이티브 환경으로 바뀌었을 때의 쾌감을 잘 아실 겁니다.

에뮬레이션인가, 포팅인가? GPU 백엔드의 분리

이 프로젝트를 둘러싼 커뮤니티의 가장 큰 오해는 “어차피 Xenia 코드를 가져다 쓰는데 이게 무슨 네이티브 포팅이냐”는 것입니다. Tom은 인터뷰에서 이 부분을 명확히 짚고 넘어갑니다.

게임의 핵심 로직, 물리 엔진, AI, 스크립팅은 모두 정적으로 재컴파일된 네이티브 코드입니다. 하지만 렌더링을 담당하는 GPU 백엔드는 현재 Xenia의 Xenos 에뮬레이션 레이어를 사용하고 있죠. 저는 이 아키텍처 분리가 매우 현명한 선택이라고 봅니다.

PC 게임이 DirectX나 Vulkan API와 통신하듯, ReXGlue의 재컴파일된 CPU 코드는 단순히 GPU 백엔드라는 서브시스템과 통신할 뿐입니다. 모든 것을 처음부터 새로 짜는(Reinventing the wheel) 대신, Xenia의 커널 레이어와 GPU 레이어를 SDK의 추상화된 인터페이스로 주입(Inject)한 것입니다. 향후 이 인터페이스를 네이티브 렌더러로 교체하기만 하면, 완벽한 네이티브 PC 포팅이 완성되는 구조입니다.

• CPU Logic: 정적 재컴파일된 네이티브 C++ 코드 (Clang 최적화 적용)
• GPU/Kernel: Xenia 기반의 추상화된 서브시스템 (향후 네이티브로 교체 예정)
• Execution: JIT 캐시 없이 직접 함수 포인터 호출

Hacker News의 반응과 엔지니어링 챌린지

Hacker News 스레드에서는 이 기술의 한계점과 가능성에 대한 심도 있는 논의가 있었습니다. 특히 동적 라이브러리 로딩이나 자기 수정 코드(Self-Modifying Code)를 AOT가 어떻게 처리할 것인지에 대한 엔지니어들의 날카로운 질문들이 오갔죠.

저 역시 이 부분이 가장 큰 허들이라고 생각합니다. 정적 분석만으로는 실행 시간에 동적으로 계산되는 점프(Indirect Jumps)의 모든 목적지를 알아내기 어렵습니다. 보통 이런 경우 폴백(Fallback)으로 가벼운 인터프리터를 내장하거나 런타임 패칭을 수행해야 하는데, ReXGlue가 이 엣지 케이스들을 어떻게 우아하게 처리해 나갈지 지켜보는 것도 관전 포인트입니다.

Principal Engineer의 시선: 프로덕션 레벨인가?

결론부터 말하자면, ReXGlue는 아직 우리가 흔히 말하는 프로덕션 레벨 의 툴은 아닙니다. Tom 스스로도 “부팅이 된다는 것은 시작점일 뿐, 사람들이 플레이할 수 있는 수준과는 거리가 멀다”고 인정하고 있죠.

하지만 이 프로젝트가 갖는 의미는 남다릅니다. 과거 콘솔 게임의 보존은 닫힌 상자(Black box) 안에서 이루어지는 에뮬레이션에 의존했습니다. ReXGlue는 이 상자를 열어젖히고, 15년 전의 게임을 현대적인 SDK와 모딩 가능한 플랫폼 위로 끌어올렸습니다.

단순히 게임을 PC에서 돌리기 위한 해킹이 아니라, 확장이 가능하고 유지보수가 용이한 아키텍처를 설계했다는 점에서 저는 이 프로젝트에 높은 점수를 주고 싶습니다. 언젠가 Blue Dragon이나 Lost Odyssey 같은 명작들이 Clang으로 빌드된 네이티브 바이너리로 제 PC에서 144fps로 돌아가는 날을 기대해 봅니다.