데이터베이스 전문가가 단 5,900줄의 코드로 SQL에서 Doom을 실행하다

시간은 2026년이고, 'X에서 Doom 실행하기'는 여전히 가장 인기 있는 소프트웨어 해킹 취미일 것입니다. 임신 테스트기부터 [우주 위성](https://www.tomshardware.com/video-games/doom-can-run-just-about-anywhere-including-space-hacker-recounts-tale-of-running-the-game-on-an-orbiting-satellite]에 이르기까지, 1993년 작 이 게임은 CPU와 메모리만 있다면 태양 아래의 거의 모든 것에 포팅되었습니다. 이제는 데이터베이스에서 게임을 실행할 차례입니다. 이번에는 Lukas Vogel이 작성한 SQLDoom 프로젝트 덕분에 CedarDB를 사용합니다. 그는 이전에 DoomQL을 저술했습니다.

게임을 SQL로 어떻게 실행하는지 궁금해하실 수도 있지만, 데이터베이스 아키텍트처럼 생각하기만 한다면 실제로는 상상했던 것보다 훨씬 쉽습니다. 그래픽 표시, 사운드 재생, 입력 처리를 담당하는 실제 프론트엔드는 Python으로 작성되었지만, 이 부분은 PC의 주변 장치 역할만 할 뿐이며, 모든 계산은 데이터베이스 내부에서 이루어집니다.

백엔드는 성능에 중점을 둔 Postgres 호환 RDBMS인 CedarDB용으로 작성되었습니다. 최신 Doom 포트와 마찬가지로 SQLDoom은 두 가지 경로를 사용합니다: 하나는 게임의 원래 35Hz로 모든 로직을 처리하고, 다른 하나는 그래픽 표시 및 게임 업데이트 사이에서 카메라 위치를 보간(interpolating)하는 별도의 스레드입니다.

시작하기 위해 Vogel은 Doom's WAD 패키지 파일 내 엔티티들을 데이터베이스로 변환해야 했습니다. 이는 예상보다 쉬웠는데, 그 안의 데이터가

메인 게임 플레이 루프의 경우, Vogel은 다시 한번 놀라울 정도로 게임 로직을 변환하기 쉬웠다고 느꼈습니다. 결과 코드는 5,900줄의 SQL로, 원래 C 소스 코드의 9,000줄과 비교됩니다. 절감된 분량의 상당 부분은 값을 업데이트하기 위해

멀티플레이어의 경우, 데이터베이스를 사용하는 것이 원래 게임보다 훨씬 좋았습니다. 그 이유는 간단합니다. 방대한 상호 의존성을 가진 여러 테이블에 걸쳐 동기화된 상태(synced states)를 유지하는 것은 말 그대로 데이터베이스가 설계된 목적이기 때문입니다. 따라서 스냅샷(snapshots), 인증(authentication), 접근 제어(access control) 등 모든 것이 효과적으로 무료이며 구현되어 있습니다. 게임 틱(game tick)을 실행하려면