실행 파일이 SQLite 데이터베이스라면: '질의 가능한 바이너리'의 실험

실행 파일을 단순한 바이트 배열이 아니라 하나의 데이터베이스로 다시 정의하면 어떤 일이 벌어질까. 개발자 파리드 자카리아(Farid Zakaria)는 앞선 글 '당신의 실행 파일은 SQLite 데이터베이스다'에서 SELF라는 포맷을 제안했다. 프로그램 자체를 SQLite 데이터베이스로 만들고, 리눅스의 binfmt_misc 기능으로 커스텀 인터프리터를 등록해 데이터베이스의 segments 테이블에 담긴 행들을 메모리에 매핑한 뒤 진입점으로 점프하는 방식이다. 이렇게 하면 심볼, 재배치, 세그먼트를 다루던 각종 바이너리 도구가 전부 SQL 질의로 수렴한다는 것이 핵심 아이디어였다. 이번 후속 글은 그 착상을 한 단계 더 밀어붙인다.

프로그램이 곧 상태 저장소

반응이 컸던 지점은 단순했다. 실행 파일이 데이터베이스이고, 데이터베이스는 쓰기가 가능하다면, 실행 중인 프로그램이 바로 그 파일에 자신의 상태까지 저장할 수 있지 않겠느냐는 물음이다. 자카리아의 답은 '그렇다'였다. 프로그램은 자신이 실행되는 바로 그 파일에 상태를 기록할 수 있고, 그것도 트랜잭션으로 처리한다. 그의 표현을 빌리면 애플리케이션 전체 배포판과 모든 상태를 단일 파일로 접어 넣을 수 있어, /var나 /tmp, /home 같은 별도의 파일시스템 경로가 원리적으로 필요 없어진다.

이를 증명하는 실물이 self-httpd다. 데이터베이스에서 실행되는 단일 파일 웹서버로, 프로그램 코드와 웹사이트 콘텐츠, 라우팅 정보, 그리고 방문 로그까지 전부 같은 SQLite 파일 안에 들어 있다. 이 서버는 selfdb.exe.xyz에 실제로 배포돼 있으며, 세 개의 테이블(routes, visits, presses)로 모든 방문자와 버튼 클릭을 기록한다. 페이지에 놓인 버튼을 누르면 그 동작은 방금 이 페이지를 응답한 실행 파일 자체에 INSERT를 수행하는 일이 된다. 애플리케이션을 만드는 과정도 낯설지 않다. DDL로 스키마를 만들고 웹사이트를 INSERT하면 끝이다. 다만 자산 파이프라인이 SQL로 자기 자신을 질의해 콘텐츠를 가져온다는 점, 그 '자기 자신'이 곧 데이터베이스라는 점이 다를 뿐이다.

프로세스는 어떻게 자기 파일에 접근하는가

기술적으로 가장 까다로운 부분은 실행 중인 프로세스가 자기 파일 경로를 확보하는 방법이다. 현재로서는 /proc/self/exe를 쓸 수 없다. binfmt_misc가 매칭되면 커널은 원래 파일을 execve하지 않고 인터프리터를 실행한 뒤 파일 경로를 넘겨주기 때문이다. 대신 self-exec가 argv+1을 프로그램에 그대로 전달해, 프로그램의 argv[0]이 자기 실행 파일 경로가 되도록 한다. 인터프리터는 진입점으로 점프하기 전에 자신이 쥐고 있던 SQLite 연결을 해제하므로, 프로그램은 곧바로 자기 파일을 열어 질의할 수 있다. 참고로 글은 리눅스 VFS 관리자가 최근 투명한 binfmt_misc 지원을 커널에 반영해, 앞으로는 /proc/self/exe가 원본 파일을 가리키게 될 수 있다는 점도 언급한다.

일단 자기 자신을 열 수 있게 되면 흥미로운 일들이 이어진다. selfdb.exe.xyz 페이지가 방문 로그와 버튼 클릭 외에 세그먼트, 심볼, 재배치 정보까지 보여주는데, 이는 빌드 시점에 박아 넣은 값이 아니라 실행 중에 자기 자신을 질의해 얻은 결과다. ACID 트랜잭션이 가능해지면서 웹서버는 구동 중에 자기 콘텐츠를 편집할 수 있고, UPDATE는 같은 파일에 커밋되며 ROLLBACK으로 되돌릴 수 있다.

SQLite 생태계를 공짜로 물려받다

이 접근의 실용적 강점은 자카리아가 직접 만들지 않은 도구들을 그대로 쓸 수 있다는 데 있다. sqldiff로 두 버전 사이의 차이를 뽑아내면 배포가 실제로 무엇을 바꿨는지 감사할 수 있고, FTS5 가상 테이블을 하나 만들면 웹서버가 자기 페이지를 스스로 색인해 전문 검색을 제공하면서도 여전히 웹서버로 남는다. 프로그램이 데이터베이스라는 이유만으로 SQLite가 이미 갖춘 기능을 공짜로 상속받는 셈이다. 배포 역시 데이터 마이그레이션으로 재해석된다. 프로그램과 데이터가 같은 파일이므로 재배포는 두 번의 INSERT ... SELECT가 된다. 파일을 교체하고 재시작해도 방문 로그는 새 빌드에서 살아남고, segments 테이블도 다른 테이블과 다를 바 없으니 반대로 프로그램 자체를 갈아끼우는 것도 가능하다.

비교 대상으로 자주 거론되는 것은 저스틴 터니(Justine Tunney)의 redbean이다. redbean은 자기 압축 해제 ZIP을 품은 Actually Portable Executable로 어디서나 실행되는 단일 파일 웹서버였고, SELF의 착상에 영감을 줬다. 자카리아는 SELF가 여러 면에서 덜 정교하다고 인정하면서도 대비를 명확히 한다. redbean이 ZIP이라는 별도 아카이브 포맷을 안고 있어야 한다면 SELF는 데이터베이스 자체가 컨테이너이고, redbean이 응답 조작을 Lua 훅으로 처리한다면 SELF에서는 handlers 테이블에 행을 하나 추가하는 일이 된다. 그의 정리를 빌리면 redbean이 '어디서나 실행되는' 실행 파일이라면 SELF는 'SELECT 할 수 있는' 실행 파일이다.

실무자가 짚어야 할 한계

다만 이 프로젝트를 그대로 실무에 옮기려는 시도는 신중해야 한다. 저자 스스로 selfdb 코드가 다소 설익었고 AI의 도움을 상당 부분 받았다고 밝혔으며, 데모 서버도 가장 저렴한 요금제에 올려둔 개념 증명 수준이다. 코드와 데이터가 한 파일에 얽혀 있다는 특성은 우아한 만큼 백업, 동시 접근, 파일 손상 시 복구, 권한 분리 같은 운영상의 질문을 새로 던진다. multicast DNS로 트랜잭션을 퍼뜨려 프로그램 업데이트를 배포하자는 지인의 제안처럼 확장 아이디어도 아직 스케치 단계에 머물러 있다. 그럼에도 이 실험이 주는 통찰은 분명하다. 수십 년간 당연하게 여겨온 '바이트 배치 명세'를 데이터베이스로 다시 상상하는 순간, 그 위에 쌓아 올렸던 많은 도구와 디렉터리 구조가 더 이상 필요치 않을 수 있다는 것이다. 정적 사이트 생성기나 scp·ssh 단일 파일 배포에 대한 향수를 SQL이라는 단일 영역으로 흡수해내려는 시도로서, 최소한 '재미'라는 가치만큼은 충분히 증명한 프로토타입이다.