생각을 정리하는 마인드맵, 풀맵 →
기술 딥다이브

닌텐도 위에서 Mac OS X을 돌린 프로젝트


한 줄 요약: 닌텐도 Wii에서 Mac OS X를 구동하는 포팅 프로젝트가 실존한다 — Wii의 PowerPC 계열 CPU 덕에 가능했고, 실제로 돌린 버전은 10.0 치타다.

최근 SNS에서 ’닌텐도 Wii에서 맥북을 만들었다’는 게시물이 화제였어요. 거실에서 볼링을 치던 게임기 위에서 Apple의 Mac OS X이 실행된다는 내용입니다. 짧은 영상은 ‘PowerPC라서 가능했다’ 정도만 짚고 지나가기에, 이 글은 개발자의 원문 글과 리포를 대조하며 그 안의 기술을 풀어 봤어요.

확인: 게시물 화면에는 ’Mac OS X 10.4 타이거’로 표기됐지만, 원본 프로젝트가 포팅한 버전은 10.0 치타(Cheetah)예요. 타이거는 아직 포팅되지 않았어요. (원문 블로그 기준)

같은 PowerPC 계열이라 가능한 일

핵심은 CPU 아키텍처예요. 위(닌텐도 Wii)의 CPU인 ’브로드웨이(Broadway)’는 IBM이 제작한 PowerPC 750CL로, 729MHz로 동작해요. 애플이 과거 G3 아이북과 아이맥에 사용했던 PowerPC 750CXe의 후속 모델이라, 위와 그 시절 Mac은 같은 계열의 CPU를 쓰는 셈입니다.

애플은 2005년부터 2006년 Intel 전환 전까지 Mac을 PowerPC 아키텍처로 구동했어요. 그래서 PowerPC용으로 만들어진 옛 Mac OS X을 위의 PowerPC CPU에서 돌리는 가능성이 존재했고, 그 근거는 명령어 집합이 같다는 단순한 사실입니다.

위의 스펙, 현실의 벽

’처참한 스펙’이라는 평은 사실이에요.

  • CPU: 브로드웨이(PowerPC 750CL) 729MHz — 요즘 스마트워치보다 성능이 낮은 단일 코어
  • RAM: 24MB(1T-SRAM, MEM1) + 64MB(GDDR3, MEM2)를 합쳐 총 88MB
  • GPU: ‘할리우드(Hollywood)’ 시스템 칩. 그 안에 ARM 기반 보조 프로세서 ’스타렛(Starlet)’도 포함

bryankeller/wiiMac 리포 — ’닌텐도 위용 Mac OS X 부트로더’라는 소개와 스타 671개가 보인다

장벽은 메모리였어요. Mac OS X 10.0 치타의 공식 최소 메모리는 128MB인데 위는 88MB가 전부입니다. 개발자 Bryan Keller는 QEMU(에뮬레이터)로 64MB에서도 치타가 부팅되는지 먼저 검증한 뒤, 시스템에서 불필요한 구성 요소를 제거하는 방식으로 88MB에 맞췄어요.

부트로더: 전원 뒤 첫 프로그램

부트로더는 전원을 켰을 때 운영체제를 메모리에 올리고 실행을 넘겨주는 첫 번째 프로그램이에요.

옛 PowerPC Mac의 부팅 순서는 Open Firmware(펌웨어)가 BootX(Mac OS X 부트로더)를 거쳐 XNU(커널)로 제어를 넘기는 것이었어요. Keller는 여기서 Open Firmware와 BootX를 건너뛰고, 위 전용 부트로더를 처음부터 직접 작성했어요(wiiMac). 위의 하드웨어는 고정돼 있으니 하드웨어를 일일이 스캔할 필요 없이, 최소한의 초기화와 커널 로드, 디바이스 트리 생성만 하면 되었거든요.

커널 패치: XNU를 위에 맞게

Mac OS X의 코어(Darwin)는 오픈소스라서, XNU라는 커널의 소스 코드를 직접 수정할 수 있어요. Keller는 위에 맞게 커널을 패치했어요.

  • 커널은 Mach-O라는 실행 파일 포맷으로 저장돼요. 부트로더가 이 포맷을 해독해 커널을 메모리에 올려요.
  • 위의 메모리 배치(MEM1은 0x00000000, MEM2는 0x10000000)가 Mac OS X가 기대하는 배치와 달라서, 메모리 주소 변환(BAT, Block Address Translation) 설정을 수정했어요.
  • 디버깅은 위 앞면 LED를 깜빡이는 방식으로 했어요. 직렬 디버그 출력이 불가능하니, 커널 안의 특정 명령을 ‘LED 켜기’ 명령으로 교체(바이너리 패치)하며 진행 상황을 추적했고, 디스어셈블러(Hopper)로 커널 이진 파일을 분석했어요.

디바이스 트리: 하드웨어 목록 심기

운영체제는 ’이 기기에 어떤 하드웨어가 연결돼 있다’는 목록(디바이스 트리)을 알아야 해요. 실제 Mac에서는 부트로더가 하드웨어를 스캔해 목록을 만들지만, 위는 하드웨어가 항상 동일하므로 Keller는 트리를 코드에 하드코딩했어요.

IOKit 드라이버: 운영체제와 위의 다리

드라이버는 운영체제가 하드웨어를 제어하게 해주는 코드예요. Mac OS X은 IOKit이라는 드라이버 모델을 쓰며, C++로 작성되고 ‘제공자-클라이언트(provider-client)’ 구조로 연결돼요. 드라이버가 ’눕(nub)’이라는 연결점에 부착되고, 그 눕이 상위 드라이버와 통신하는 방식이에요.

Keller가 위에 맞춰 새로 작성한 드라이버들이 핵심이에요.

  • 할리우드(Hollywood) 드라이버: 위는 Mac처럼 PCI 버스를 쓰지 않고 ‘할리우드’ 전용 SoC로 하드웨어를 연결해요. 그 안의 ARM 코프로세서 ’스타렛’이 실제 하드웨어 접근을 담당하고, PowerPC 코어와는 IPC(프로세서 간 통신)로 대화해요.
  • SD 카드 드라이버: 시스템이 설치된 SD 카드를 읽기 위해 필요해요. 스타렛(ARM)에서 실행되는 MINI 프로그램에 IPC로 명령을 보내 SD 카드를 읽고 썼어요. 까다로운 부분은 ’캐시 일관성’이었어요 — ARM이 쓴 데이터를 PowerPC가 읽을 때 캐시 이전 값이 나오지 않도록, 캐시가 적용되지 않는(uncached) 메모리를 사용했어요.
  • 프레임버퍼 드라이버: 화면에는 픽셀 데이터가 들어 있는 메모리(프레임버퍼)가 필요한데, 위의 영상 하드웨어는 YUV 포맷을 요구하고 Mac OS X은 RGB를 써요. RGB 프레임버퍼와 YUV 프레임버퍼 둘을 준비하고, 초당 60번 RGB를 YUV로 변환해 출력하는 방식으로 해결했어요.
  • USB 드라이버: 키보드와 마우스를 쓰려면 위의 USB 포트가 동작해야 해요. Mac OS X의 USB 드라이버(AppleUSBOHCI)는 ’리틀 엔디안’을 가정하지만 위는 ’역 리틀 엔디안(reversed-little-endian)’이라 바이트 순서가 안 맞았어요. 게다가 당시 USB 스택 소스가 없어서 IRC에서 공유받은 과거 소스를 구해 수정했고, 역어셈블러(Ghidra)로 바이트 스왑 명령을 찾아 패치하기도 했어요.

홈브류와 BootMii: 전제 조건

이 모든 작업의 전제는 ’위에서 자기 코드를 실행할 수 있어야 한다’였어요. 위는 ’탈옥(jailbreak)’이 가능한 기기라 Homebrew Channel과 BootMii 같은 도구로 하드웨어에 직접 접근해 임의 프로그램을 실행할 수 있어요. Keller의 부트로더도 이 경로로 실행됐습니다.

어떻게 활용되나요

한 줄로 정리하면: 같은 PowerPC 계열 CPU라는 공통분모가 가능성을 만들었고, 직접 작성한 부트로더와 패치한 XNU 커널, 위 전용 IOKit 드라이버가 그 가능성을 현실로 만든 프로젝트예요. 핵심은 Mac OS X의 오픈소스 코어(Darwin/XNU/IOKit)를 수정할 수 있었다는 점 — 닫힌 상위 GUI는 그대로 두고 열린 부분만 위에 맞춰 바꿨어요.

여기서 얻는 경험칙은 이래요. 오래된 기기의 ’한계’는 하드웨어 스펙표가 아니라, 그 아래에 열린 코어가 남아 있는지로 갈린다. 아키텍처가 닿아 있고 소스가 열려 있으면, 88MB도 한 세대 전의 운영체제를 품을 수 있습니다.

이 글의 내용은 아래 자료를 기준으로 확인했어요. 화면 캡처는 정리 시점(2026-10-07)에 직접 접속해 찍은 것이에요.