애플이 1990년대부터 2000년대 초까지 사용한 클래식 Mac OS는 PowerPC 프로세서 위에서 돌아갔다. 그런데 같은 PowerPC 계열 칩을 쓰면서도 전혀 다른 길을 걸은 하드웨어가 있다. 바로 닌텐도의 게임큐브, Wii, Wii U다. 이들 기기의 그래픽·시스템 칩셋은 ArtX라는 회사가 설계했는데, 게임큐브의 Flipper는 ATI가 ArtX를 인수할 당시 사실상 완성돼 있었고, Wii의 Vegas(개정판 Bollywood)와 Wii U의 Latte는 그 직계 후속작이다. 한 개발자가 이 비주류 PowerPC 하드웨어 위에 클래식 Mac OS를 올려 데스크톱 화면까지 띄우는 데 성공했다고 자신의 블로그에 기록을 남겼다. 그는 이것이 CHRP 클론 시대 이후 애플 외부의 누군가가 새로운 시스템에서 클래식 Mac OS를 데스크톱까지 부팅시킨 첫 사례일 가능성이 높다고 본다.
이 프로젝트는 취미이자 학습의 결과물이다. 개발자는 2025년 6월 22일 openbios를 포크하며 작업을 시작했고, 코딩·리버싱·디버깅 전 과정에서 LLM이나 코딩 에이전트를 전혀 쓰지 않았다고 명시했다. AI를 쓰면 재미도 없고 배우는 것도 없기 때문이라는 이유다. 애초에 그가 이 하드웨어에 눈을 돌린 계기도 연쇄적이었다. 먼저 Windows NT를 이 기기들에 포팅했고, 그 과정에서 PowerPC 맥 노트북 몇 대를 손에 넣어 거기에도 NT를 올렸으며, 그러다 클래식 Mac OS 특유의 '잼(jank)'—1980년대부터 쌓이고 쌓인 핵(hack) 더미—에 매료됐다고 한다.
부트로더부터 다시 짜다
뉴월드 방식의 클래식 Mac OS는 Open Firmware 환경에서 도는 'Trampoline'이라는 부트로더로 시작한다. 그래서 OpenBIOS 포팅이 첫 관문이었다. 마침 Goldfish64가 Wii용 Mac OS X 포팅을 진행하며 만든 OpenBIOS 포팅에서 일부 드라이버를 가져다 쓸 수 있었다. 다만 그 포팅이 Wii/Wii U만 겨냥한 반면, 그는 게임큐브까지 지원하길 원해 그대로 쓰지는 않았다. 초기 부팅에 필요한 디스크 드라이버로는 EXI 버스(닌텐도와 Macronix가 SPI를 부르는 이름)용으로 만들어둔 SD Gecko와 EXI-IDE 드라이버를 이식했다. 초기 테스트 단계에서는 'Mac OS ROM' TBXI 파일을 FAT 파일시스템에 직접 올려 OpenBIOS가 부팅 시 불러오게 했다.
가장 먼저 부딪친 벽은 주소 공간에 대한 Trampoline의 가정이었다. Trampoline은 물리 주소 0x8000_0000 이후를 메모리 맵 I/O(기존 시스템에서는 PCI 버스 주소 공간)로 간주하는데, 이 하드웨어에서는 사실이 아니다. 심지어 Wii U에서는 그 주소가 RAM의 일부에 해당한다. RAM 영역 사이에 구멍이 있고 그 일부가 MMIO로 채워지는 구조도 문제였다. 그는 커널 메모리 청크 리스트의 MMIO 매핑 초기화를 패치해 특정 물리 주소를 유효한 가상 주소에 재배치하는 방식으로 이를 우회했다. Trampoline 버전에 따라 페이지 카운트가 16비트에서 32비트로 바뀐 점까지 감지해 구버전 함수를 후킹해야 했다.
핵 위에 다시 핵을 쌓다
이 하드웨어에 없는 장치를 전제로 한 코드가 곳곳에 있었다. 모든 PowerPC 매킨토시에 있는 마이크로컨트롤러의 존재를 나타내는 비트플래그 설정, 특정 하드웨어 타이머로 버스 주파수를 재계산하는 코드, PCI 버스에 붙은 리틀엔디언 인터럽트 컨트롤러 관련 레지스터 조작 등이 모두 패치 대상이 됐다. 장치 트리도 Trampoline이 받아들일 형태로 손봐야 했다. 인터럽트 컨트롤러는 레지스터 수준에서 Flipper와 가장 가까운 기존 리틀엔디언 컨트롤러로 위장했고, 가짜 Mac99 호환 전원 관리 장치도 추가했다.
흥미로운 대목은 애플 원본 코드에 숨어 있던 버그들이다. 참고로 PowerPC 시대 내내 Mac OS의 m68k 핵심 코드 모듈 이름은 'SuperMario'였다. 글쓴이는 1990년대 초의 어느 개발자가 마리오 팬이었는지 궁금해한다. 이 m68k 코드에는 하드웨어 인터럽트를 초기화하는 함수에 복사·붙여넣기 실수가 있었다. 시리얼 포트 1 코드를 복제해 포트 2용으로 만들면서 점프 레이블을 바꾸지 않은 탓에, 시리얼 포트 2가 없으면 무한 루프에 빠진다. USBShimKeyboard 드라이버는 USB 컨트롤러가 없는 상태를 처리하지 못해 m68k 에뮬레이터 안에서 널 포인터를 호출했다. ADB·전원 관리 초기화 함수는 하드웨어 존재 여부를 확인하지 않고 로우 메모리를 망가뜨렸다.
이렇게 해서 깜빡이는 플로피 아이콘까지 띄운 뒤, Elliott Nunn의 virtio 드라이버를 참고해 디스플레이 드라이버를 쓰고, NT용 드라이버를 이식해 게임큐브 컨트롤러 포트로 USB 없이 마우스 커서를 움직였다. 이후 디스크 포맷 설계에서 한동안 막혔다가 거의 1년 만에 돌아와, 여러 SATA 컨트롤러용 클래식 Mac OS 드라이버가 쓰던 수법처럼 SCSI를 흉내 내는 가짜 드라이버를 만들었다. StartLib!GetStartupDevice가 내장 SCSI 장치를 전제로 한 탓에 내부 구조체의 인덱스를 세 군데에서 0이 아닌 값으로 고쳐야 했고, 마침내 '행복한 맥' 아이콘을 처음 봤다. 그다음엔 자신이 만든 드라이버 버그가 발목을 잡았다. IDE의 PIO 모드는 16비트 워드 단위로 데이터를 다루는데, 하위 4비트가 1인 완전히 어긋난 버퍼 주소가 들어올 경우를 예상하지 못해 한 바이트가 밀려 쓰이는 문제였다. 리소스 포크 헤더를 읽을 때 터져준 덕분에 유효성 검사가 걸려 비교적 쉽게 잡을 수 있었다.
아직 공개 배포와는 거리가 먼 단계지만, 이 작업은 복고 컴퓨팅 애호가와 임베디드·펌웨어 실무자 모두에게 생각할 거리를 남긴다. 운영체제가 특정 하드웨어 레이아웃에 얼마나 깊이 묶여 있는지, 주소 공간·인터럽트 컨트롤러·장치 트리 같은 저수준 가정이 포팅의 실질적 난관이 된다는 점을 구체적으로 보여준다. 동시에 수십 년 묵은 상용 코드에 복사·붙여넣기 버그나 하드웨어 존재 검사 누락 같은 결함이 조용히 남아 있다는 사실은, 레거시 자산을 다루는 이들에게 익숙하면서도 경각심을 주는 장면이다.