SQLDoom - 오리지널 Doom을 SQL로 포팅하기

“복잡한 게임 로직을 SQL로 표현하기가 의외로 쉬웠고, 전체가 약 5,900줄”이라는 대목을 보니, HN은 여전히 현대 SQL의 역량을 크게 과소평가하는 것 같음.
업무가 너무 복잡해서 절차형 코드로 유지하기가 사실상 불가능한 기업도 있음. 업무 규칙을 SQL로 구현하면 문제를 분해해 훨씬 많은 사람이 동시에 다룰 수 있음.
반도체 제조업에서 일할 때는 공장 운영을 저장 프로시저와 SQL에 크게 의존했고, 일반 애플리케이션 코드에는 운영 의사결정 로직이 거의 없었음. 수백 명이 같은 프로시저들을 검토하고 변경을 제안했으며, 매일 아침 운영 DB를 복제해 실제 데이터로 실험했기에 테스트도 간단했음. 업무 정보와 로직 사이에 간극이 없었던 셈임. 하지만 대부분은 DB를 데이터와 로직의 중심이 아니라 단순한 CRUD 조회 엔진으로 취급함.
Microsoft, Oracle, IBM에 큰돈을 쓰자고 하는 쪽은 대체로 이런 구성을 원함. 기업 전체가 하나의 시스템 안에서 운영되기를 바라는 것임. 하나로 해결할 수 있는데도 공급업체와 도구를 10개 넘게 동원해 분산시키는 것은, 조직 내 역할에 따라 직무 태만에 가까울 수도 있음.

복잡한 로직을 SQL로 구현하는 일은 정말 하고 싶지 않은 일 중 하나임. 요즘은 적어도 SpacetimeDB 함수라는 대안이 있음. https://spacetimedb.com/docs/functions.
하지만 MSSQL처럼 표준 라이브러리가 빈약하고 모든 것을 문자열 중심으로 다루는 환경이라면 사양하겠음. 널리 쓰이는 패턴이 아닌 데는 이유가 있음.

현재 회사에서 데이터 분석 플랫폼 개발을 맡고 있는데, 데이터 중심 시스템이라 로직의 약 95%를 DB 함수와 저장 프로시저로 구현할 수 있었음. 나머지 5%는 대부분 Python으로, HTTP 게이트웨이에서 해당 함수를 호출하고 결과를 XLSX 파일로 만드는 연결부 역할만 함.
SQL만으로 할 수 있는 일이 놀라울 정도로 많았음. 절차적 처리가 필요한 부분은 가끔 PL/pgSQL을 써야 했지만 예외적인 경우였음. 지금은 부하가 큰 분석 작업 일부를 DuckDB로 옮기는 중이며, 이 과정도 아주 만족스러움. SQL 만세!

업무 로직을 어느 계층에 둘지는 늘 흥미로운 아키텍처 질문임. 일부를 SQL에 둘 타당한 이유는 분명 있지만, 아주 까다롭고 복잡한 로직은 가급적 피하는 편임.
로직이 지나치게 복잡하거나 계속 바뀌면, 대부분은 애플리케이션 계층에 두고 DB에는 최후의 안전장치가 될 제약 조건을 넣으려 함.
함께 일한 사람 중 DB 계층의 복잡한 업무 로직을 쉽게 이해하고 수정할 만큼 SQL에 능숙한 사람은 손에 꼽을 정도임. 지난 10년간 주로 작은 회사에서 일했으니, 큰 조직에는 이를 맡을 데이터 엔지니어가 더 많을 것 같음.

2010년대에 2000년대 레거시 애플리케이션의 저장 프로시저를 디버깅하고 수정하는 일이 정말 싫었음. 프로시저는 일반 코드처럼 취급되지 않았고 버전 관리도 하지 않았음. 업무 로직을 애플리케이션 코드가 아닌 DB에 넣는 방식에는 주로 나쁜 기억이 남아 있음.

우리도 이렇게 운영하며, 단점은 있지만 전반적으로 수년간 잘 작동해 왔음. 그런데 저장 프로시저를 쓴다는 이유로 제품을 폐기해야 한다는 소리를 들었음. 정작 대체 제품의 의존성 그래프를 보면 기가 막힘.

일반 C보다 코드가 짧으면서 쿼리 계획을 상태 머신으로 악용하다니, 공학적 무리수의 정점이라 오히려 마음에 듦.

지금 직접 해보는 중인데, 처음부터 끝까지 SQL이라는 점을 고려하면 예상보다 훨씬 잘 작동함. 언젠가 SQL 쿼리로 LLM 추론을 실행해도 지구 나이만큼 기다리지 않아도 되는 날이 오기를 바람.
현재 cedardb.com의 프로젝트 소개 글은 접속 폭주로 마비된 듯하지만, 게임 자체는 잘 실행됨.

게임 상태를 SQL 테이블에 둔다는 걸 보니 1년간 최적화에 매달렸던 때가 떠오름. 2010년에 카지노 게임을 만들면서 모든 원격 호출이 유일한 기준 데이터인 SQL 테이블의 게임 상태를 갱신하도록 했는데, 지금도 좋은 결정이었는지 확신하지 못함. 여러 플레이어가 동시에 접근하다 보니 초반 교착 상태는 끔찍했고 확장도 악몽이었음.
대신 모든 처리가 원자적이었음. 한 턴의 요청이 서버에 도달하지 못하거나 교착 상태에 걸리는 정도를 넘어 데이터를 잃을 위험은 없었음. 거대한 Node.js 프로세스가 모든 요청을 동시에 받다가 멎거나 메모리 속 상태를 잃는 일과 달리, 상태는 언제나 남아 있었음.
돌이켜보면 까다로운 부분만 해결할 수 있다면 다중 사용자 턴제 게임에는 나쁘지 않은 설계 같음. 원자성 덕분에 적어도 유실되지 않는 일관된 상태를 보장할 수 있음. 액션 게임에서 이런 읽기·쓰기 반복을 한다면 무모하겠지만, 그래서 더 재미있게 느껴짐.