Benzi가 DOOM 엔진의 시대를 앞선 설계를 코드에서 확인함

이 코드를 높이 평가해야 하는 이유는 옛날 기술을 낭만적으로 추억하게 해서가 아니라, 하드웨어 제약을 설계 원칙으로 번역한 방식이 지금도 유효하기 때문입니다. DOOM 엔진은 게임플레이 중 malloc()에 의존하지 않고 하나의 메모리 아레나를 블록으로 관리했으며, PU_CACHE 블록을 필요할 때 축출했습니다. 이는 단순히 빠른 할당기를 만든 사례가 아니라, 어떤 데이터가 반드시 살아 있어야 하고 어떤 데이터는 다시 만들 수 있는지를 엔진의 메모리 모델에 새겨 넣은 사례라고 봅니다.

특히 메모리 지역성과 수명 관리가 한 덩어리로 결합된 점이 중요합니다. 오늘날에는 범용 할당기와 가비지 컬렉터, 운영체제의 가상 메모리가 많은 부담을 대신 처리하지만, 그 편리함은 데이터의 생존 기간과 회수 비용을 흐리게 만들 가능성이 큽니다. DOOM의 태그 기반 구조는 개발자가 데이터의 중요도와 재생성 가능성을 명시하도록 강제했습니다. 이 방식은 현대의 아레나 할당기나 데이터 지향 엔진에서도 다시 나타나고 있으니, 오래된 기법이라기보다 상황에 따라 반복해서 돌아오는 기본 원리에 가깝습니다.

고정소수점 연산과 룩업 테이블도 단순한 최적화 이상의 의미를 가집니다. tables.c에 삼각함수 값을 미리 담고 렌더링을 정수 연산으로 처리한 사실은, 성능을 높이려면 계산 한 줄을 빠르게 만드는 것보다 계산 자체를 실행 경로에서 제거하는 편이 낫다는 판단을 보여줍니다. 물론 현대 CPU와 GPU에서는 이런 선택을 그대로 복사하면 오히려 정밀도와 유지보수성을 해칠 수 있습니다. 그럼에도 반복되는 비용을 테이블, 캐시, 전처리 단계로 옮기는 발상은 지금의 렌더링과 시뮬레이션에서도 여전히 설득력이 있습니다.

화면 버퍼와 UI의 관계는 더 근본적인 질문을 던집니다. DOOM에서는 3D 월드, HUD, 몬스터, 무기가 같은 픽셀 블리팅 경로를 공유했고, 별도의 위젯 트리나 GUI 계층은 없었습니다. 이것은 당시에는 화면 전체를 직접 소유해야 했기 때문에 합리적이었지만, 그 결과 UI와 게임 렌더링의 경계가 사실상 사라졌습니다. 저는 이 부분이 효율의 승리인 동시에 확장성의 대가였다고 봅니다. 해상도, 입력 장치, 접근성, 해상도별 레이아웃이 중요해진 현대 게임에서 같은 구조를 고집하면 기능 추가가 급격히 어려워질 가능성이 큽니다.

블록맵 역시 오늘날의 용어로 포장하기보다 문제에 맞는 인덱스를 직접 선택한 사례로 보는 편이 정확합니다. 모든 지오메트리를 순회하지 않고 인접한 영역만 검사했다는 사실은, 거창한 범용 공간 자료구조보다 질의 패턴에 맞춘 단순한 인덱스가 더 좋은 결과를 낼 수 있음을 보여줍니다. 다만 이 설계가 모든 게임에 적합하다는 뜻은 아닙니다. 맵 규모와 이동 방식이 달라지면 격자 해상도, 메모리 낭비, 경계 처리 문제가 커질 수 있으므로, DOOM의 코드를 정답집으로 읽기보다 의사결정의 기록으로 읽어야 합니다.

결국 이 사례가 놓치고 있는 것은 천재적인 비법보다 트레이드오프의 가시성입니다. DOOM은 추상화를 몰라서 생략한 것이 아니라, 1993년의 CPU와 메모리에서 추상화 비용을 감당하지 않기로 선택했습니다. 오늘날에는 자동화된 도구가 그 비용을 낮췄지만, 모든 비용이 사라진 것은 아닙니다. 데이터가 언제 생성되고 사라지는지, 어떤 계산을 미리 할 수 있는지, 어떤 범위만 탐색해야 하는지를 모호하게 두면 최신 하드웨어에서도 병목은 다시 나타날 겁니다. 그래서 DOOM 엔진의 유산은 특정 코드 조각이 아니라, 제약을 숨기지 않고 구조로 드러내는 태도에 있다고 봅니다.