2014년 9월, 필립 오툴은 rqlite를 세상에 알리는 짧은 글을 올렸다. 발상은 단순했다. SQLite 앞에 Raft 로그를 두고 모든 쓰기를 클러스터에 복제해, 노드 하나가 사라져도 데이터가 사라지지 않게 만드는 것이다. 소스 코드는 그 주말 바로 깃허브에 올라갔다. 저자의 기억으로는 Raft와 SQLite를 결합한 최초의 오픈소스 시스템이었고, 이후 몇 년 동안 비슷한 시도를 하는 사람은 없었다. 그러나 지금 '분산 SQLite'는 열 개 넘는 프로젝트가 경쟁하는 하나의 카테고리가 되었고, 그중 몇몇은 벤처 투자를 받았으며 둘은 인수되었다. 이 글은 흔히 2021년부터 시작되는 그 이야기를, 2014년부터 처음 자리에 있었던 사람의 시점으로 다시 쓴 기록이다.
출발점은 추상적 실험이 아니라 구체적인 필요였다. 저자가 다루던 클러스터형 시스템에 소량의 관계형 저장소가 필요했는데, 그 데이터를 어느 노드가 보관해야 하는지에 대한 좋은 답이 없었다. SQLite를 합의 프로토콜로 복제하면 그 질문 자체가 사라졌다. 회사에서는 다른 방향으로 갔지만, 문제는 일반적이고 해법은 작았기에 저자는 rqlite를 계속 만들었다. 초기 버전은 당시 InfluxDB와 etcd가 쓰던 goraft 라이브러리를 사용했고, 2016년 초에 Hashicorp의 Raft 구현으로 교체한 뒤 지금까지 유지하고 있다.
CP라는 선택과 그 함의
설계에서 가장 중요한 결정은 초기에 내려졌고 한 번도 바뀌지 않았다. rqlite는 CP 시스템이다. 쓰기는 반드시 리더를 거쳐야 하고, 과반수가 이를 승인해야 하며, 네트워크 분단으로 소수파가 된 쪽은 쓰기를 거부한다. HTTP API, 읽기 일관성 수준, 스냅샷 처리 같은 나머지 설계는 모두 이 원칙에서 파생되었다. 실무자 입장에서 이 결정은 곧 트레이드오프의 선언이다. 분단 상황에서도 가용성을 유지하기보다 일관성을 지키겠다는 뜻이며, '머신이 죽었는데 복구를 기다릴 수 없을 때'라는 질문에 답하는 데이터베이스라는 정체성을 규정한다.
정직을 위해 짚을 선례도 있다. Expensify는 자체 인프라 안에서 Paxos 계열 프로토콜로 수년간 SQLite를 복제해 왔고 2016년에 이를 Bedrock으로 공개했다. 또 각 '액터'에게 Raft로 복제되는 SQLite를 하나씩 부여한 얼랭 기반 시스템 ActorDB도 비슷한 시기에 등장했다. 둘 다 각자의 출발지 밖에서 널리 쓰이지는 못했지만, 아이디어가 공기 중에 떠 있었음을 보여준다. rqlite가 한 일은 그것을 누구나 돌릴 수 있는 독립적이고 범용적인 오픈소스로 만든 것이었다.
세 모서리로 갈라진 설계 공간
이후 등장한 프로젝트들은 이 설계 공간의 서로 다른 모서리를 차지했다. Canonical은 etcd를 돌리지 않고도 LXD와 MicroK8s에 내장형 복제 저장소를 넣기 위해 dqlite를 만들었다. 마크 셔틀워스가 저자에게 직접 전화를 걸어 rqlite를 활용할 수 있을지 논의했지만 끝내 맞지 않았고, dqlite는 Go로 시작했다가 자체 Raft 라이브러리를 갖춘 C로 다시 쓰였다. 의도는 rqlite와 가장 비슷하지만 차이는 포장에 있다. dqlite는 제품 안에 끼워 넣는 라이브러리이고, rqlite는 제품 곁에서 돌리는 서버다.
2021년 초 벤 존슨이 내놓은 Litestream은 합의를 전혀 쓰지 않는다. SQLite의 WAL을 감시해 S3로 스트리밍함으로써, 단일 노드 SQLite에 거의 공짜에 가까운 재해 복구를 제공한다. 대부분의 애플리케이션은 클러스터가 필요 없고 한 대의 머신으로 돌아가며 죽었을 때 복구할 방법만 있으면 된다는 그의 주장은 이후 'SQLite만으로 충분하다'는 흐름에 큰 영향을 남겼다. Litestream과 rqlite는 다른 질문에 답한다. 전자는 '머신이 죽으면 어떻게 하나'이고, 후자는 '머신이 죽었는데 복구를 기다릴 수 없으면 어떻게 하나'이다. 2022년 Fly.io는 벤을 영입해 Consul 리스로 파일시스템 수준에서 SQLite를 복제하는 LiteFS를 출시했고, 복제 SQLite를 배포 대상이 아니라 플랫폼 기능으로 만든 첫 시도가 되었다. 흥미롭게도 Litestream은 거꾸로 rqlite v8.0의 WAL 처리 방식에도 영감을 주었다.
같은 해 다른 두 프로젝트는 또 다른 모서리로 갔다. cr-sqlite는 CRDT를 SQLite 확장으로 더해, 리더 없이 여러 작성자가 갈라졌다 병합되도록 했다. 이는 설계 공간의 AP 모서리로, rqlite의 CP 보장이 오히려 방해가 되는 로컬 퍼스트 애플리케이션에 어울린다. libSQL은 SQLite 엔진 자체를 포크했다. 외부 기여를 받지 않는 SQLite 프로젝트가 바꿔주지 않을 부분을 엔진 안에서 바꾸려 한 것으로, 그 위에 엣지 복제본을 둔 호스팅 서비스를 올려 Turso가 되었고 벤처 자금을 모았으며 2026년 Supabase에 인수되었다. 비슷한 시기 SQLite Cloud는 Raft로 복제하는 호스팅 SQLite를 선보여 rqlite 원래 설계에 가장 가까운 모습을 보였다.
아이디어는 열려 있었고, 돈은 플랫폼으로 갔다
Cloudflare는 2022년 엣지 네트워크 안의 서버리스 SQLite인 D1을 발표하고, 이후 Durable Objects 안에 SQLite 저장소를 넣었다. 내부 동작을 공개할 필요가 없는 회사가 복제 SQLite를 관리형 제품으로 파는 형태다. 카테고리는 '직접 돌리는 것'에서 '구매하는 것'으로 옮겨 갔다. 저자의 정리에 따르면 설계 공간은 세 모서리로 나뉘고 등장 순서도 그랬다. 합의가 먼저(rqlite, dqlite), 스트리밍이 그다음(Litestream), 병합이 마지막(cr-sqlite와 로컬 퍼스트 흐름)이다. 각각은 서로 다른 질문에 대해 옳으며, 대부분의 논쟁은 사실 '지금 던지는 질문이 무엇인가'를 둘러싼 다툼이다.
그리고 자본은 플랫폼으로 흘렀다. rqlite와 dqlite, Litestream은 오픈소스이자 무료이고, 자금을 모으거나 인수된 쪽은 복제 SQLite를 청구서가 따라붙는 서비스로 바꾼 프로젝트들이다. 인프라 아이디어가 흔히 맞는 운명이지만, 이 아이디어가 누군가 팔기 8년 전부터 오픈소스로 존재했다는 사실은 기록해 둘 만하다. rqlite는 여전히 남아 있고 2014년과 같은 일을 훨씬 잘해내며, 직접 돌리고 완전히 이해하며 누구에게도 비용을 내지 않는 내결함성 관계형 데이터베이스가 필요할 때 집어 드는 선택지로 남아 있다. 스스로 서비스를 운영하는 한국 실무자라면, 이 세 모서리의 구분은 곧 '내 애플리케이션이 던지는 질문이 무엇인지'를 먼저 확정하라는 실용적 체크리스트이기도 하다.