Apple Silicon 기기에서 Windows 게임을 구동할 때 발생하는 주된 성능 저하는 더 이상 CPU 명령어 번역 단계에서 오지 않는다. 진짜 기술적 걸림돌은 시스템 전체의 메모리 페이지 크기를 하나로 묶어둔 리눅스 커널의 기본 설계였다. 2026년 11월 7일, Asahi Linux 팀은 Linux 7.3 개발 진척 보고서를 발표했다. 개발진은 Android 진영의 P3S 패치를 접목하여 가상머신의 개입 없이 x86 게임을 직접 구동하는 데 성공했다.
3중 오버헤드로 성능 20% 증발, 병목의 원인은 4K 메모리 페이지
지금까지 Asahi Linux에서 PC 패키지 게임을 즐기려면 세 겹의 런타임 환경을 겹쳐 써야 했다. 가장 밑단에서는 FEX가 x86 명령어를 arm64 명령어로 동적 변환하고, 중간 계층의 WINE이 Windows API 호출을 받아 처리했다. 그리고 최상단에서는 muvm이 가벼운 가상머신을 띄워 오래된 프로그램에 맞춰 4 KiB 메모리 페이지 환경을 흉내 냈다.
초기에 muvm을 설계했던 목적은 DRM Native Context 기술을 통해 네이티브에 근접한 그래픽 처리량을 뽑아내려는 것이었다. 그러나 실제 엔지니어링 벤치마크 결과는 기대를 빗나갔다. 가상화 계층으로 인해 약 20%의 성능 손실이 발생했다. 여러 계층의 변환 과정에 가상머신 오버헤드까지 더해지면서 하드웨어가 지닌 본래 그래픽 연산력의 5분의 1이 허공으로 날아간 셈이다.
프레임 손실뿐만 아니라 가상머신 구조는 각종 부수적인 문제들도 야기했다. muvm은 Wayland 데스크톱 프로토콜과 깔끔하게 맞물리지 못해 창 관리나 클립보드 동기화가 자주 멈췄다. 가상화된 파일시스템의 I/O 처리량이 눈에 띄게 떨어졌고, 게임패드 같은 외부 입력 기기를 안정적으로 매핑하기도 까다로웠다.
프로세스별로 유연한 macOS, 시스템 단일 페이지에 묶인 리눅스
오래된 명작 게임들이 4 KiB 메모리 페이지에 매달리는 이유는 x86 아키텍처의 오랜 역사적 유산 때문이다. 초기 Windows 게임과 32비트 프로그램들은 운영체제의 페이지 크기가 무조건 4 KiB라고 가정하고 만들어졌다. 상당수 메모리 할당기가 4096바이트 경계를 바이너리 로직 안에 하드코딩해 두었기에, 더 큰 페이지 크기를 가진 운영체제에서 실행하면 메모리 경계를 침범해 즉시 튕겨버린다.
Apple Silicon 하드웨어는 기본적으로 16 KiB 메모리 페이지를 사용한다. macOS는 XNU 커널의 유연한 가상 메모리 설계를 바탕으로 사용자 공간의 프로세스가 원하는 매핑 단위를 직접 지정할 수 있도록 지원한다. Rosetta가 x86 게임을 실행할 때 커널이 해당 자식 프로세스만을 위해 별도의 4 KiB 주소 공간을 할당하므로 시스템 전체가 타협할 필요가 없다.
반면 리눅스 커널은 여기서 근본적인 아키텍처 분기점을 맞닥뜨린다. 전통적인 리눅스는 시스템 내 모든 프로세스가 단일한 메모리 페이지 크기를 공유하도록 강제한다. 작년에 Asahi 팀은 FEX 내부에서 4 KiB 환경을 소프트웨어적으로 흉내 내는 실험을 진행하기도 했으나, 코드 유지보수성과 명령어 번역의 정확도를 담보하기 위해 이러한 임시 땜질 패치들을 결국 걷어냈다.
ARM64 레지스터 하나로 전환: 프로세스별 페이지 크기 지정
이 교착 상태를 풀어낸 돌파구는 모바일 생태계에서 날아왔다. Android 시스템은 현재 4 KiB에서 16 KiB 페이지로의 전환 작업을 대대적으로 추진 중이다. Google Play가 신규 앱에 16 KiB 대응을 의무화하면서 관리가 중단된 수많은 레거시 앱들이 구동 실패 위험에 처했다. Google 엔지니어들은 16 KiB 커널 환경 위에서 4 KiB 기반 프로세스를 호환 구동할 수 있는 일반적인 해법을 찾아내야 했다.
Linux Plumbers Conference에서 Google 엔지니어들은 P3S라는 메커니즘을 제안했다. 정식 명칭은 프로세스별 페이지 크기(Per Process Page Size)다. ARM64 아키텍처의 페이지 테이블 단위는 변환 제어 레지스터(TCR_EL1) 내부의 특정 플래그 비트에 의해 제어된다. 하드웨어 자체는 이미 주소 변환 단위를 동적으로 바꿀 수 있는 준비를 마쳐두고 있었던 것이다.
P3S 패치는 커널 내부에서 각 프로세스가 요구하는 페이지 테이블 단위를 추적한다. 스케줄러가 문맥 교환(Context Switch)을 수행할 때 시스템이 이에 맞춰 TCR 레지스터에 해당 설정을 써 넣는다. 네이티브 프로세스 입장에서 단일 레지스터 쓰기 작업은 아무런 영향을 주지 않는 빈 동작에 가까우며, CPU 오버헤드는 사실상 0이다. 이 하드웨어 수준의 즉각적인 전환 방식은 무거운 가상머신을 띄워야 했던 근본적인 이유를 단숨에 무너뜨렸다.
4종의 고전 게임, 가상머신 벗어던지고 144 FPS 돌파
Asahi 팀은 P3S 패치 세트를 자사의 Linux 7.3 커널 브랜치로 가져와 이식했다. 상징적인 고전 PC 게임들이 가상머신 없이 네이티브 상태로 구동 테스트를 마쳤다. 2004년에 출시된 《스타워즈: 배틀프론트》는 WineD3D 기반에서 부드럽게 시동되었다. 화면 그래픽이 완벽하게 출력되었으며, 예전에 자주 겪었던 메모리 주소 오류도 전혀 나타나지 않았다.
그림: 《스타워즈: 배틀프론트》(2004)가 muvm 외부에서 WineD3D를 통해 구동되는 모습. 출처: Asahi Linux 공식 진척 보고서
그래픽 부하가 훨씬 무거운 2014년작 《울펜슈타인: 더 뉴 오더》는 더욱 놀라운 성능 해방감을 보여주었다. M2 Max 칩을 탑재한 Mac Studio에서 게임 프레임은 가볍게 144 FPS를 돌파했다. 가상머신을 걷어낸 것만으로 20%의 그래픽 손실을 고스란히 되찾았으며, ARM64 번역 계층이 고주사율 게이밍을 충분히 뒷받침할 수 있음을 증명했다.
그림: 《울펜슈타인: 더 뉴 오더》(2014)가 muvm 외부에서 구동되며 M2 Max Mac Studio에서 144+ FPS를 기록한 모습. 출처: Asahi Linux 공식 진척 보고서
개발팀은 호환성이 까다롭기로 악명 높은 2008년작 《GTA IV》도 테스트 목록에 올렸다. 이 32비트 고전작은 윈도우 실제 PC에서도 커뮤니티 패치가 없으면 제대로 돌아가지 않는 경우가 다반사다. 하지만 DXVK를 통한 Vulkan 변환을 거쳐 muvm을 벗어나자 눈에 띄게 매끄러운 플레이 환경을 보여주었다. 함께 테스트한 《폴아웃: 뉴 베가스》 역시 가상머신 특유의 끊김 현상 없이 쾌적하게 구동되었다.
그림: 《GTA IV》(2008)가 muvm 외부에서 DXVK를 통해 실행되는 장면. 호환성 테스트를 위해 의도적으로 가장 까다로운 32비트 표본으로 선정한 사례다. 출처: Asahi Linux 공식 진척 보고서
가상머신을 없앤 결과는 프레임 향상에 그치지 않고 그래픽 드라이버의 디버깅 부담도 크게 덜어주었다. 예전에는 렌더링 결함을 조사하려면 호스트 드라이버와 게스트 드라이버라는 이중 스택을 오가야 했다. 이제 그래픽 명령어가 네이티브 드라이버로 바로 전달되므로 GPU 오류 원인을 짚어내는 시간이 몇 배 이상 단축되었다.
커널에 임시 하드코딩: 업스트림 반영은 여전히 미지수
P3S가 거둔 성과는 눈부시지만 현재로서는 실험적인 엔지니어링 단계에 머물러 있다. 지금의 패치는 16 KiB 호스트 환경과 4 KiB 프로세스의 조합으로 하드코딩되어 있다. 이 구현은 Google의 비즈니스적 필요에는 딱 들어맞지만 전반적인 아키텍처 관점에서의 유연한 추상화는 부족하다. 특정 크기 조합만을 가정한 코드를 리눅스 커널의 핵심 메모리 관리 하위 시스템에 집어넣는 일은 업스트림 메인테이너들의 매우 엄격한 검증을 거쳐야만 한다.
사용자 공간 쪽의 연동 작업도 만만치 않은 기술적 과제다. P3S는 실행 파일의 세션 정렬 특성을 보고 동작 여부를 결정한다. 최신 arm64 바이너리는 폭넓은 호환성을 위해 보통 64 KiB 단위로 배치되어 있다. 따라서 자식 프로세스가 4 KiB 페이지를 정상적으로 상속받으려면 P3S 동작을 강제로 켜주는 별도의 심(shim) 도구를 제작해 물려주어야 한다.
업스트림 반영의 불확실성을 감안해 Asahi 팀은 신중한 릴리스 기조를 유지하고 있다. Google이 업스트림 메인라인 반영 계획을 분명히 밝히기 전까지는 Asahi 공식 배포판에 이 기능을 기본값으로 활성화하지 않겠다고 못 박았다. 핵심 메커니즘이 리눅스 공식 메인라인에 정식 수용되는 것을 지켜본 뒤에 전면적인 적용을 검토하겠다는 판단이다.
이번 보고서에는 다른 하드웨어 지원 성과들도 다수 담겼다. M3 시리즈 칩셋이 실험적 꼬리표를 떼고 공식 지원 단계로 올라섰으며, DCP 디스플레이 엔진을 통해 절전 모드 복귀와 맥북의 노치 영역 제어가 가능해졌다. 썬더볼트 초기 패치가 적용되어 USB3 및 네트워크 연결이 지원되기 시작했고, Fedora Asahi Remix 역시 상위 배포판인 Fedora Linux 45와 사상 처음으로 같은 날 동시 배포를 달성했다.
ARM64 환경에서 Windows 게임을 돌리기 위한 엔지니어링의 흐름은 사용자 공간의 단순한 흉내내기를 지나 커널의 토대를 뜯어고치는 단계로 나아가고 있다. FEX가 명령어 동적 변환의 높은 효율을 입증한 지금, 마지막 남은 장벽은 운영체제의 메모리 관리라는 가장 깊은 바닥에 놓여 있었다. 가벼운 레지스터 쓰기 한 번으로 가상머신을 대체하여 20%의 손실을 거둬낸 P3S처럼, 커널 수준의 메모리 페이지 족쇄가 풀릴 때 비로소 크로스 아키텍처 게이밍은 무거운 짐을 벗어던지게 될 것이다.
참고 링크:
- Asahi Linux 공식 진척 보고서 (James Calligeros)
- Linux Plumbers Conference 2026 발표 (Kalesh Singh, Frederick Mayle)
