PostgREST 대신 Rust·LUA·SQLite 기반 REST 서비스를 구축하는 이유

이 프로젝트의 가장 큰 장점은 PostgREST를 그대로 복제하려는 대신 SQLite와 셀프 호스팅이라는 분명한 출발점을 택했다는 데 있습니다. 다만 성공 여부는 Rust나 LUA의 속도보다, SQL·DSL·스크립팅·인증을 한 제품 안에서 얼마나 작고 예측 가능하게 묶느냐에 달려 있을 가능성이 큽니다. 기능을 많이 넣는 것보다 사용자가 안심하고 배포할 수 있는 경계를 정하는 일이 더 중요해 보입니다.

SQLite에 먼저 집중하는 판단은 현실적입니다. 기사에서 제시한 것처럼 WAL 모드와 Xepak을 조합하면 별도의 데이터베이스 서버를 운영하지 않는 간단하고 저렴한 배포 모델을 만들 수 있습니다. 특히 개인 프로젝트나 소규모 서비스에서는 이 단순성이 강력한 경쟁력이 될 수 있습니다. 그러나 WAL이 읽기 성능과 동시성을 개선하더라도 쓰기 중심의 서비스나 여러 인스턴스가 같은 저장소를 적극적으로 갱신하는 환경까지 자동으로 해결해 주지는 않습니다. 따라서 이 제품은 처음부터 대규모 범용 API 서버라기보다, 작은 팀과 단일 서비스에 강한 데이터 게이트웨이로 포지셔닝하는 편이 설득력 있을 겁니다.

문제는 DSL과 스크립팅이 SQL의 복잡성을 줄이는 동시에 새로운 복잡성을 만들 수 있다는 점입니다. 엔드포인트 응답을 SQL 결과로 구성하는 방식은 직관적이지만, 동적 쿼리 생성과 LUA·Rhai 로직까지 합쳐지면 사용자는 결국 Xepak의 실행 모델과 보안 규칙까지 배워야 합니다. 여러 데이터베이스를 지원하려는 목표도 이 지점에서 긴장 관계에 놓입니다. 데이터베이스마다 쿼리와 트랜잭션 의미가 다른데, 범용 스크립트 계층이 이를 감추려 할수록 가장 낮은 공통분모만 남을 가능성이 큽니다. 오히려 SQLite에서 잘 작동하는 명확한 모델을 먼저 완성하는 편이 장기적인 확장성에도 유리할 수 있습니다.

현재 인증이 단순한 수준이고 비공개 엔드포인트마다 인증 프로세서를 추가해야 한다는 사실은 MVP의 부차적인 미완성 항목이 아닙니다. API 키와 역할 정의만으로는 운영 중인 서비스의 최소 보안 요구를 모두 설명하기 어렵고, 세밀한 권한 표현식은 잘못 작성했을 때 데이터 노출로 이어질 수 있습니다. 기본 거부 정책, 권한 실패 로그, 키 폐기와 교체, 스크립트의 권한 범위 같은 요소가 함께 제공되지 않는다면 개발자는 편리함보다 불안을 먼저 느낄 겁니다. 인증과 권한 부여는 선택 기능이 아니라 제품 신뢰도의 핵심으로 다뤄야 합니다.

LUA와 Rhai 중 하나를 성능으로 결정하겠다는 계획도 조금은 좁은 기준입니다. 실제 벤치마크에서 LUA가 더 빠르게 나오면 Rhai를 제외할 수 있다는 입장은 합리적이지만, 성능 차이는 스크립트 길이와 호출 빈도, 데이터베이스 대기 시간에 따라 달라질 수 있습니다. 샌드박싱, 오류 메시지, 디버깅 편의성, 라이브러리 생태계, 실행의 결정성까지 함께 평가해야 합니다. 두 언어를 계속 유지하면 문서와 테스트 비용이 커질 가능성이 있고, 하나를 고르면 사용자의 선택권이 줄어듭니다. 이 결정은 단일 수치가 아니라 대표적인 인증·검증·필터링 시나리오를 기준으로 내려야 합니다.

다음 달 첫 MVP를 목표로 하면서 해결할 작업과 아키텍처 결정이 많이 남았다는 점은 양면적입니다. 빠르게 공개해 실제 사용자의 요구를 확인하려는 태도는 좋지만, DSL 문법과 권한 모델처럼 나중에 바꾸기 어려운 부분을 서둘러 고정하면 초기 사용자에게 호환성 비용을 떠넘길 수 있습니다. 첫 버전에서는 다른 DB 지원, 다중 스크립트 언어, 복잡한 표현식보다 안전한 기본값·마이그레이션·백업과 복구·관찰 가능성을 우선해야 합니다. 이 네 가지가 갖춰져야 사용자는 기술 데모가 아니라 운영 도구로 받아들일 겁니다.

라이선스 설명도 가볍게 넘기기 어렵습니다. 기사에는 MIT 라이선스이지만 LICENSE-TERMS의 특정 조건을 따라야 하고, 자체 라이선스는 나중에 작성할 예정이라고 적혀 있습니다. 이런 표현은 법적으로 어떤 권리와 의무가 적용되는지 즉시 판단하기 어렵게 만들 수 있으며, 기업 사용자는 코드의 품질보다 먼저 도입 가능성을 검토하게 됩니다. 기능이 아무리 매력적이어도 라이선스가 불명확하면 생태계와 기여자를 끌어들이기 어렵습니다.

결국 이 프로젝트는 SQLite를 중심으로 한 작고 안전한 REST 계층이 될 때 가장 가능성이 커 보입니다. 반대로 PostgREST의 대안이자 여러 DB와 두 스크립트 언어를 포괄하는 범용 플랫폼까지 한꺼번에 노리면, 단순성을 내세운 출발점이 스스로 무너질 가능성이 큽니다. MVP에서는 기능의 폭보다 운영자가 예측할 수 있는 동작과 명확한 계약을 증명해야 하며, 그 증명이 이루어질 때 Xepak은 흥미로운 실험을 넘어 실제로 선택할 만한 도구가 될 겁니다.