N64에서 오픈월드 엔진을 돌린다고? 극한의 하드웨어 제약을 극복하는 엔지니어링

솔직히 말해서, 처음에 이 영상을 봤을 때는 흔한 레트로 에뮬레이터 해킹이겠거니 했습니다. 요즘 우리는 16GB RAM도 부족하다며 최적화를 미루고 클라우드 인스턴스의 스케일업 버튼을 누르곤 하니까요. 하지만 최근 Hacker News를 뜨겁게 달군 이 영상은 제 뼈를 세게 때렸습니다. 1996년에 출시된 닌텐도 64(N64)에서 Open-World Engine 을 밑바닥부터 구현한 제임스 램버트(James Lambert)의 프로젝트는 단순한 장난감이 아닙니다.

이것은 극단적인 제약 속에서 엔지니어가 어떻게 아키텍처를 설계하고 병목을 해결하는지 보여주는 완벽한 마스터클래스입니다. 이게 왜 대단한지, 그리고 우리가 여기서 무엇을 배울 수 있는지 시니어 엔지니어 관점에서 파헤쳐 보겠습니다.

4MB RAM의 악몽: N64의 진짜 병목

N64는 악명 높은 하드웨어 구조를 가지고 있습니다. 흔히 VRAM이 느리다고 오해하지만, N64의 진짜 문제는 4MB(확장팩 사용 시 8MB)에 불과한 통합 RAM과 고작 4KB 크기의 텍스처 캐시(TMEM)입니다.

이런 환경에서 수 킬로미터에 달하는 오픈월드 지형을 렌더링한다? 일반적인 렌더링 파이프라인으로는 어림도 없는 소리입니다. 메모리에 모든 에셋을 올려두는 현대적인 방식은 시작부터 불가능하며, 철저한 스트리밍과 메모리 관리가 필수적입니다.

Custom RSP Microcode: 제약을 부수는 열쇠

이번 프로젝트에서 가장 인상 깊었던 기술적 성취는 RSP(Reality Signal Processor) Microcode 를 직접 작성했다는 점입니다.

대부분의 N64 Homebrew 게임들은 닌텐도의 공식 마이크로코드나 libdragon의 호환 경로를 사용합니다. 하지만 이 경우 Geometry 파이프라인에 심각한 제약이 생깁니다. 제임스는 62MHz로 동작하는 RSP의 벡터 유닛을 최대한 활용하기 위해, 오픈월드 지형 스트리밍에 최적화된 마이크로코드를 새로 짰습니다.

  • Spatial Partitioning: 메인 MIPS CPU는 게임 로직에 집중하고, 무거운 공간 분할 및 컬링(Culling) 작업은 RSP로 오프로딩합니다.
  • Texture Streaming: N64 시절에는 존재하지도 않았던 텍스처 스트리밍 기법을 구현해 4KB TMEM의 한계를 우회했습니다.

이 구조를 보면서, 과거 모바일 초기 시절 제한된 메모리 대역폭을 해결하기 위해 GPU 파이프라인을 직접 뜯어고치던 때가 생각나더군요. 공식 라이브러리가 제공하는 추상화의 장막을 걷어내고 베어메탈(Bare-metal)과 직접 대화하는 것, 이것이 진짜 엔지니어링의 묘미 아닐까요?

LOD와 Billboard Imposters의 미학

지평선 너머의 오브젝트를 처리하는 방식도 훌륭합니다. 멀리 있는 객체를 Billboard imposter (특정 각도에서 시점에 맞게 바뀌는 평면 텍스처)로 대체하는 기법을 사용했습니다.

현대의 GTA V나 Just Cause 2, 심지어 Simplygon 같은 상용 미들웨어에서도 여전히 핵심적으로 쓰이는 방식입니다. 과거 Shadow of the Colossus가 원경을 스카이박스에 렌더링했던 꼼수나, Trespasser에서 나무를 2D 이미지로 처리했던 기법들과 맥락을 같이 합니다. 결국 하드웨어의 한계는 엔지니어의 창의력을 강제로 끌어올리는 최고의 촉매제입니다.

Hacker News의 생생한 회고록

이번 HN 스레드에서 가장 흥미로웠던 부분은 1998년 N64용 ‘Road Rash 64’를 개발했던 시니어 엔지니어의 등판이었습니다.

그의 회고에 따르면, 당시 뼈를 깎는 최적화를 통해 초당 750k개의 셰이딩된 폴리곤을 뽑아냈다고 합니다. 하지만 N64 Reality Coprocessor의 안개(Fog) 효과에 치명적인 하드웨어 버그가 있어서 사실상 “안 쓰느니만 못한” 기능이었다는 뒷이야기는 꽤 충격적이었습니다. 하드웨어 벤더의 스펙 시트만 믿고 밤을 새우다 절망해 본 우리 모두의 PTSD를 자극하기에 충분했죠.

또한, 이전에 N64용 Portal 디메이크를 만들었던 프로젝트가 밸브(Valve)와 닌텐도의 법적 문제로 중단된 사연도 언급되었습니다. 닌텐도를 “250kg짜리 복수심에 불타는 고릴라”에 비유한 댓글은 IP 보호라는 명목 아래 기술적 탐구가 가로막히는 업계의 냉혹한 현실을 보여주는 씁쓸한 유머였습니다.

결론: 우리는 너무 편하게 개발하고 있는가?

물론 이 엔진이 당장 상용 프로덕션에 쓰일 일은 없습니다. 레트로 콘솔을 위한 장난감(Toy) 프로젝트에 가깝습니다. 하지만 이 N64 오픈월드 엔진은 우리에게 중요한 화두를 던집니다.

“우리는 정말 시스템의 한계까지 성능을 쥐어짜내고 있는가?”

풍부한 클라우드 리소스와 고성능 프레임워크에 취해 아키텍처 설계 단계부터 최적화를 등한시하고 있다면, 가끔은 이런 Extreme Engineering 사례를 보며 초심을 다잡을 필요가 있습니다. 제약은 변명이 아니라, 혁신을 위한 가장 강력한 도구입니다.