한 개발자가 열다섯 살 무렵 고등학생 시절에 시작해 수년에 걸쳐 완성한 3D 오픈월드 게임이 공개됐다. 'Project Hedra'로 불리는 이 프로젝트는 로우폴리 스타일의 RPG로, 플레이어가 직업을 선택하고 절차적으로 생성되는 끝없는 세계를 탐험하며 스킬을 해금하고 역시 절차적으로 만들어지는 퀘스트를 수행하는 구조다. 코드베이스 규모는 약 10만 줄에 이르며, 리눅스와 윈도우를 모두 1차 지원 대상으로 삼는다. 개발자 본인의 설명에 따르면 처음 목표는 거창하지 않았다. OpenGL이 어떻게 동작하는지 배우려는 학습용 실험이 출발점이었고, 이른바 '스코프 크립(scope creep)', 즉 범위가 계속 불어나는 현상을 거치면서 결국 게임 한 편과 그것을 돌리는 자체 엔진으로까지 발전했다.
이 프로젝트가 단순한 습작 수준을 넘어선다는 점은 내부 구조를 들여다볼 때 드러난다. 흥미로운 대목은 게임 본체를 하나의 '모드(mod)'로, 그 아래를 '베이스 엔진'으로 분리한 아키텍처 결정이다. 개발자는 이렇게 나눈 이유를 모드 API를 항상 최신 상태로 유지하도록 스스로를 강제하기 위해서라고 밝혔다. 자신이 만든 게임조차 모드 API를 통해 엔진에 접근하게 만들면, 외부 사람들이 모드를 제작하기도 그만큼 쉬워진다는 발상이다. 혼자 만드는 프로젝트에서 확장성과 API 안정성을 미리 설계에 녹여 넣은 셈인데, 이는 실무에서 플랫폼과 애플리케이션을 분리할 때 쓰는 사고방식과 맞닿아 있다.
성능을 위한 저수준 선택들
엔진의 설계에서 눈에 띄는 것은 성능을 의식한 저수준 기법들이다. 월드 렌더링을 담당하는 WorldRenderer는 세계 전체를 물, 지형, 인스턴스드 오브젝트로 나눠 대략 세 번의 드로우 콜만으로 그리도록 설계됐다. 이때 glMultiDrawElements를 활용하는데, 실제 드로우 콜 수는 데이터 버퍼가 얼마나 분할돼 있느냐에 따라 달라진다고 한다. 드로우 콜을 최소화하는 것은 OpenGL 기반 렌더링에서 CPU-GPU 간 호출 오버헤드를 줄이는 전형적인 최적화 방향이다.
또 하나는 메모리 관리다. 이 프로젝트는 C#으로 작성됐지만, 게임 프레임이 도는 도중 발생하는 자동 힙 할당과 그로 인한 가비지 컬렉션(GC)을 피하기 위해 커스텀 할당자를 직접 구현했다. NativeArray는 자체 할당자 위에 올린 배열 프리미티브이며, 힙 기반 할당자뿐 아니라 stackalloc을 쓰는 스택 기반 할당자도 함께 제공한다. 이 밖에도 커스텀 리스트와 배열, 네이티브 포인터 래퍼 같은 핵심 프리미티브가 별도 레이어로 묶여 있다. 관리형 언어를 쓰면서도 실시간 게임의 프레임 안정성을 지키기 위해 GC 압력을 줄이는 접근은, 유니티를 비롯한 C# 게임 개발 현장에서 오래 논의돼 온 실전 과제와 같은 선상에 있다.
모드 스크립트와 자산 파이프라인
확장성 측면도 구체적이다. 낚시 기능인 Fishing은 C#이 아니라 IronPython을 이용한 파이썬 모드 스크립트로 작성돼, C# API를 직접 호출하는 방식으로 동작한다. 게임 로직 일부를 스크립트 언어로 빼내 모딩 가능성을 실제로 증명해 보인 것이다. 자산 관리를 위해서는 별도의 커맨드라인 도구를 두어 이미지, 모델, 사운드, 셰이더를 빠른 조회에 유리한 구조의 단일 바이너리 파일로 압축해 결합한다. 빌드 과정은 비교적 단순하며, 리눅스와 윈도우용 예시는 깃허브 액션 워크플로에서 확인할 수 있다고 안내한다. 한편 Hedra는 한때 멀티플레이어를 지원했는데, UDP 홀 펀칭으로 클라이언트 간 P2P 통신을 중개하는 서버 구조였고 지금도 엔진 코드 곳곳에 네트워킹 흔적이 남아 있다고 한다.
실무자가 눈여겨볼 지점과 한계
한국의 IT 실무자 입장에서 이 프로젝트가 주는 함의는 분명하다. 렌더러, 할당자, 자산 파이프라인, 스크립팅 레이어를 모두 직접 쌓아 올린 사례는, 상용 엔진이 추상화해 숨겨 둔 계층에서 실제로 무슨 일이 벌어지는지를 학습하는 살아 있는 교재가 된다. 드로우 콜 묶기나 GC 회피 같은 선택은 교과서 속 개념이 아니라 10만 줄짜리 실동작 코드 안에서 구현된 결과물이기 때문이다. 공개된 브랜치 이름이 'pre-ai'라는 점도 시사적인데, 이는 생성형 AI 보조 도구가 보편화되기 이전에 한 사람의 손으로 작성됐음을 드러내는 맥락으로 읽힌다.
다만 참고할 때 유의할 지점도 있다. 공개된 설명만으로는 성능 수치나 현재의 유지보수 상태, 멀티플레이어 기능의 작동 여부 같은 구체적 지표를 확인하기 어렵다. 개발자 스스로 일부 코드가 아직 엔진과 게임 레이어로 깔끔히 분리되지 않았다고 인정했고, 멀티플레이어는 과거형으로 서술된다. 오랜 기간 혼자 성장시킨 코드베이스인 만큼 설계 일관성과 문서화 수준은 직접 저장소를 열어 판단할 필요가 있다. 그럼에도 학습 동기에서 출발해 자체 엔진까지 이르는 성장 궤적 자체는, 규모 있는 사이드 프로젝트가 어떻게 기술 역량으로 축적되는지를 보여 주는 설득력 있는 사례다.