JIT 없이 안드로이드 VR 앱을 비전 프로에서 돌리는 Klepton의 접근법

애플 비전 프로와 메타 퀘스트는 같은 ARM 기반 하드웨어를 쓰면서도 소프트웨어 생태계가 완전히 분리돼 있다. 퀘스트용으로 나온 수많은 VR 게임과 앱은 안드로이드 APK 형태로 배포되지만, visionOS에서는 이를 그대로 실행할 방법이 없다. 여기에는 단순한 정책 문제뿐 아니라 기술적 장벽도 있다. 특히 애플 플랫폼은 서명되지 않은 코드를 실행 중에 생성하는 JIT(Just-In-Time) 컴파일을 강하게 제한하기 때문에, 안드로이드 런타임을 그대로 이식하는 방식은 통하지 않는다. 최근 공개된 오픈소스 프로젝트 Klepton은 바로 이 지점을 우회하는 실험적인 호환 계층으로, JIT를 요구하지 않고 안드로이드 ARM64 VR APK를 비전 프로와 macOS에서 구동하는 것을 목표로 한다.

리링커라는 우회 전략

Klepton의 핵심은 에뮬레이션이 아니라 재링킹(relinking)이다. 프로젝트에 포함된 klepton-ld 도구는 안드로이드용 네이티브 라이브러리인 .so 파일을 애플이 로드할 수 있는 .dylib 및 .framework 형태로 변환하고, 이를 Klepton 런타임에 직접 연결한다. 즉 명령어를 실시간으로 재해석하는 대신, 바이너리를 애플 플랫폼이 이해하는 형식으로 미리 번역해 네이티브 코드로 실행시키는 방식이다. 이 접근 덕분에 JIT가 필요 없고, 실행 성능 면에서도 인터프리터 기반 에뮬레이션보다 유리하다. 다만 현재 Klepton은 자바 코드 비중이 얇은(Java-thin) 애플리케이션에만 집중하고 있으며, 안드로이드의 ART나 JVM 자체를 구현하지는 않는다. 앱 로직 상당 부분이 자바/코틀린 계층에 있는 일반 안드로이드 앱은 대상이 아니고, 게임 엔진처럼 핵심 로직이 네이티브 라이브러리에 몰려 있는 경우가 현실적인 타깃이라는 뜻이다.

그래픽과 레지스터라는 두 가지 난관

VR 앱에서 그래픽 API 호환은 사활이 걸린 문제다. Klepton은 안드로이드가 쓰는 OpenGL ES 3.2 호출을 프로젝트에 포함된 ANGLE의 GLES 3.0 구현으로 옮기고, 그 ANGLE은 다시 애플의 메탈(Metal) 백엔드 위에서 동작한다. 불칸(Vulkan) 호출은 MoltenVK를 통해 메탈로 번역된다. 결국 안드로이드 그래픽 명령이 여러 변환 계층을 거쳐 최종적으로 메탈에 도달하는 구조인데, 계층이 늘어나는 만큼 기능 커버리지와 성능에서 손실이 생길 여지가 있다.

더 미묘한 문제는 CPU 레지스터 처리다. ARM64에서 x18 레지스터는 안드로이드와 macOS 모두 예약(reserved)해 두지만 사용 규약이 다르다. 상당수의 오래된 안드로이드 앱은 여전히 x18을 직접 사용하는데, macOS는 컨텍스트 전환 시마다 x18을 0으로 밀어버린다. 그대로 두면 앱이 저장해 둔 값이 사라져 오작동하게 된다. Klepton은 klepton-ld 단계에서 x18을 사용하는 코드를 모두 찾아 라이브러리별 TLS(스레드 로컬 저장소) 슬롯을 쓰도록 패치해 이 충돌을 회피한다. 플랫폼 간 이식에서 흔히 간과되는 ABI 차원의 세부 사항까지 손대야 한다는 점을 잘 보여주는 대목이다.

JIT의 벽과 남은 과제

Klepton은 실행 중에 mmap으로 .so 파일을 로드하고 패치하는 기능도 갖추고 있지만, 이는 사실상 macOS에서만 의미가 있다. JIT가 실제로 허용되는 환경이 macOS이기 때문이다. 반대로 말하면 스크립팅 런타임을 내장한 앱은 이식이 까다로워진다. LuaJIT나 V8처럼 실행 시 코드 생성을 전제로 하는 엔진을 쓰는 애플리케이션은 JIT를 요구할 가능성이 높고, JIT가 제약된 비전 프로에서는 이런 앱이 걸림돌이 될 수 있다. 결국 Klepton의 무(無)JIT 전략은 폭넓은 호환성을 보장하는 만병통치약이 아니라, JIT에 의존하지 않는 앱군에서 성립하는 조건부 해법이다.

현재 공개된 성과로는 리듬 게임 Beat Saber가 macOS와 visionOS 양쪽에서 동작하며, 다만 사소한 그래픽 문제가 남아 있다고 명시돼 있다. SteamVR Link 지원과 범용성 개선, 빌드 도구 정비는 아직 진행 중(WIP)이다. 전체 빌드 절차는 저장소의 BUILDING.md에 정리돼 있다. 상용 제품이라기보다 기술적 가능성을 증명하는 초기 단계 프로젝트로 보는 편이 정확하다.

실무자가 눈여겨볼 지점

XR 개발이나 크로스플랫폼 이식을 다루는 실무자 입장에서 Klepton이 흥미로운 이유는 결과물 자체보다 방법론에 있다. 런타임 에뮬레이션 대신 정적 재링킹으로 접근하고, 그래픽은 ANGLE·MoltenVK 같은 기존 번역 계층을 재활용하며, ABI 불일치는 바이너리 패치로 메우는 조합은 폐쇄적인 애플 생태계에서 외부 바이너리를 돌리려 할 때 참고할 만한 설계 패턴이다. 동시에 한계도 분명하다. 자바 로직이 두꺼운 앱, JIT 의존 앱, 다층 그래픽 변환에서 발생하는 미세한 렌더링 오류 등은 이 방식이 근본적으로 감수해야 하는 비용이다. 라이선스와 배포 정책 측면의 불확실성까지 감안하면, 당장 제품에 도입하기보다는 애플 플랫폼의 제약을 우회하는 기술적 접근이 어디까지 가능한지를 가늠하는 참고 사례로 접근하는 편이 합리적이다.