1996년 애플이 내놓은 애플 네트워크 서버(ANS)는 외형만 맥일 뿐 속은 철저히 유닉스 머신이었다. 하드웨어 기반은 파워 매킨토시 9500에 가까웠지만, 운영체제로는 AIX 계열(하푼 AIX)을 돌리도록 설계됐다. 개발 과정에서 애플은 ANS가 맥 OS로 부팅하는 모습을 시연하기도 했는데, 이것이 오히려 잠재 구매자들에게 혼란을 줬다. 결국 양산 제품에서는 맥 OS 부팅 기능 자체가 제거됐고, ANS는 '맥처럼 보이지만 맥 OS는 못 쓰는' 서버로 출시됐다.
당시 CTO였던 엘렌 행콕은 1997년 ROM만 교체하면 ANS가 다시 맥 OS와 윈도우 NT를 부팅할 수 있다고 주장했다. 그러나 이 ROM은 오랫동안 실체 없는 소문으로 여겨졌다. 전환점은 한 전직 애플 직원이 프리프로덕션 ROM과 이후의 ANS 맥 OS ROM 덤프가 실제로 동작하는 것을 공개하면서 찾아왔다. 또 다른 전직 직원을 통해 윈도우 NT용 프로토타입 ROM도 등장했지만, 일부가 누락돼 NT 네이티브 부팅은 여전히 미완성 상태다. 글쓴이는 자신이 보유하고 있던 ROM이 바로 그 프리프로덕션 버전이라는 사실을 뒤늦게 알아차렸다고 한다.
왜 소프트웨어로 메워야 했나
두 ROM은 각기 다른 한계를 지닌다. 나중 버전의 맥 OS ROM은 미완성이어서 L2 캐시를 제대로 지원하지 못해 눈에 띄게 느리고, AIX를 부팅할 수 없다. 반면 프리프로덕션 ROM은 맥 OS와 AIX를 모두 부팅하고 캐시도 지원하지만, 온보드 비디오와 전면 Fast Wide SCSI-2 컨트롤러를 지원하지 않고 온보드 MACE 이더넷도 동작하지 않는다. 게다가 맥 OS로 한 번 부팅한 뒤 PRAM을 초기화하지 않고 재시작하면 검은 화면이 뜨는 문제까지 있었다.
핵심은 이런 결함 상당수가 소프트웨어로 해결 가능했다는 점이다. 글쓴이는 MACE 이더넷을 고치고, 온보드 비디오를 지원하도록 만들었으며, 재시작 시 정상적으로 맥 OS로 복귀하도록 손봤다. 프리프로덕션 ROM인 덕분에 AIX 부팅 능력도 그대로 유지돼, ANS(코드네임 Shiner)가 존재한 역사적 이유인 유닉스 서버로서의 정체성도 보존됐다. 실제 설치는 외장 부팅 가능 SCSI 볼륨에 맥 OS를 올리는 방식으로 진행된다. 후면 SCSI 포트에 직결하는 블루SCSI를 SCSI ID 2로 설정하고, 9.1까지는 ANS에서 직접 부팅되므로 최소 8.1 이상을 권장한다.
코플랜드가 남긴 드라이버 구조
이 작업을 이해하려면 PCI 파워맥의 드라이버 구조를 알아야 한다. 애플은 실패로 끝난 차세대 OS '코플랜드'에서 새 드라이버 아키텍처를 도입했는데, 68K 코드는 권한이 제한된 협조적(cooperative) 주소 공간에 격리하고 드라이버는 PowerPC 네이티브 코드 조각으로 분리했다. 이 네이티브 드라이버는 HAL과 네임 레지스트리(장치를 추적하는 객체 데이터베이스)에 연결돼 부팅 초기에 로드되며 사용자 코드로부터 보호된다. 시스템 ROM이 오픈 펌웨어로 제어를 넘기면 장치 트리가 만들어지고, 코드 프래그먼트 매니저가 PCI 확장 ROM과 Mac ROM의 드라이버를 실행한다. 이후 디스플레이·SCSI·ATA 매니저가 '패밀리 익스퍼트'로서 확장 폴더의 ndrv 조각을 다른 확장보다 먼저 로드한다.
흥미로운 점은 네임 레지스트리에 PCI 카드뿐 아니라 CPU, L2 캐시, Mac ROM, 그리고 그랜드 센트럴에 붙은 AWACS 사운드 칩, SWIM III 플로피 컨트롤러, NCR 53C96 SCSI와 85C30 시리얼, MACE 이더넷을 담은 CURIO 칩까지 노드로 올라온다는 것이다. 글쓴이는 이 구조를 활용해 비디오 드라이버를 2.0 ANS 맥 OS ROM에서 직접 추출해 사용했다. 재부팅 문제의 원인은 맥 OS가 ANS를 일반 9500으로 오인해 부적절한 nvramrc 오픈 펌웨어 스크립트를 심고 입출력 장치를 시리얼 포트 ttya로 바꿔버리는 데 있었다. 베이지 파워맥의 OF 1.0.5에서는 무해하지만, ANS의 1.1.x 펌웨어는 이 설정을 실제로 따르기 때문에 화면이 전혀 나오지 않는다. 글쓴이는 표준 OS 구성요소를 수정하는 대신 ANS 전용 설정(플랫폼 문자열 AAPL,ShinerESB)을 더하는 방식으로 우회했다.
실무자가 눈여겨볼 지점
이 프로젝트는 단순한 레트로 취미를 넘어, 운영체제가 하드웨어를 어떻게 인식하고 드라이버를 매칭하는지를 실물로 보여준다. 펌웨어가 만든 장치 트리, 레지스트리 기반 드라이버 바인딩, 부팅 초기에 격리된 네이티브 드라이버라는 개념은 이름만 다를 뿐 오늘날 디바이스 트리나 커널 드라이버 모델과 본질이 닿아 있다. 또한 하드웨어가 지원하지 않는 기능을 펌웨어 덤프 분석과 NVRAM 패치, 드라이버 이식으로 메워 나가는 과정은 문서 없는 플랫폼을 리버스 엔지니어링할 때의 전형적인 접근법을 그대로 보여준다.
다만 한계도 분명하다. 이 확장 팩은 어디까지나 '첫 번째 버전'이며, 프리프로덕션 ROM이라는 희귀 부품과 AAUI 전용 이더넷, 구하기 어려운 ANS 전용 PCI 카드 같은 특수 하드웨어에 의존한다. 윈도우 NT 네이티브 부팅은 ROM 일부 누락으로 여전히 미완성이고, 이더넷의 PLSCC 레지스터 설정처럼 아직 완전히 규명되지 않은 부분도 남아 있다. 결국 이 작업은 극소수 장비를 가진 사람에게만 직접적 효용이 있지만, 거기서 드러나는 드라이버 로딩과 펌웨어 상호작용의 원리는 플랫폼을 가리지 않고 참고할 가치가 있다.