SQLDoom, 1,300줄의 SQL로 Doom을 렌더링하다 — 89개의 CTE로 구성된 게임 엔진, 35fps

"데이터베이스에서 Doom을 렌더링하는 것은 분명히 나쁜 생각이다"라고 Lukas Vogel은 자신의 프로젝트 SQLDoom을 설명하는 블로그 글에서 썼다. 이 프로젝트는 SQL 데이터베이스를 사용해 Doom을 렌더링한다. 구조는 이렇다. 작은 Python 클라이언트가 입력, 출력, 게임 타이밍, 프레임 표시를 처리하고, 그 뒤에서 일련의 CedarDB 테이블이 게임 지오메트리와 상태를 추적한다. 게임 자체는 89개의 공통 테이블 표현식(CTE)에 걸쳐 펼쳐진 약 1,300줄의 SQL로, 게임 로직을 구현하고 초당 35개의 비트맵 프레임버퍼를 생성한다.

SQLDoom은 Vogel의 이전 프로젝트 DoomQL에서 크게 발전한 것이다. DoomQL은 작년에 '전적으로 SQL로 구현된 멀티플레이어 Doom류 슈터'를 만들려 했지만 결국 레이캐스팅 기반의 흑백 ASCII 근사치로 끝났다. 2026년 버전은 성능 통계와 파이프라인 세부 정보를 보여주는 디버그 뷰까지 갖춘, 지옥의 정확한 비트맵 뷰를 35fps로 렌더링한다.

이 기행은 사실 위장된 데이터베이스 벤치마크이기도 하다. 한 프레임을 렌더링한다는 것은 매 틱마다 세계 상태 테이블을 소비하는 쿼리 파이프라인을 실행하는 것이며, 이는 쿼리 계획, 공통 테이블 표현식 평가, 구체화를 일반적인 OLTP 워크로드보다 훨씬 크게 압박한다. 바로 그 점이 CedarDB 팀에게는 핵심이다.

쿼리 엔진은 연산 엔진이다. 지오메트리와 상태가 테이블에 있다면, 조인, CTE, 집계가 프레임별 연산을 수행할 수 있다. 프레임버퍼는 쿼리 결과다.

이것은 'Doom이 돌아가는가'라는 질문에 기기 수준이 아니라 추상화 수준에서 답한다. 새 하드웨어로의 포팅이 아니라 새로운 수학, 즉 렌더링 파이프라인으로서의 관계형 쿼리다.

숫자들이 이것을 개념이 아닌 현실로 만든다. 1,300줄의 SQL, 89개의 CTE, 정확한 비트맵 출력의 초당 35프레임.

이는 저자 자신의 이전 실패, 즉 DoomQL의 ASCII 레이캐스터 위에 세워졌으며, 'SQL로 계산적으로 가능함'과 'SQL로 엔진급임' 사이의 간극을 보여준다.

데이터베이스 스타트업에게 Doom은 마케팅 자료로는 속일 수 없는 스트레스 테스트다. 프레임별 쿼리 파이프라인은 계획과 실행 성능을 누구에게나 드러낸다.

엔진은 그저 연산 파이프라인이다. 시스템을 의도된 추상화 너머로 밀어붙일 때, 즉 SQL을 그래픽 파이프라인으로 쓸 때, 그 실제 한계가 어디인지 정확히 알게 된다.

SQLDoom은 2026년 10월에 방대한 기술 블로그 글과 GitHub 소스와 함께 공개되었으며, Ars Technica가 같은 주에 이를 보도했다. 소스에는 후속 계획이 보고되지 않았다.