여러 시스템에 상태가 흩어지는 것은 현대 애플리케이션의 고질적인 문제다. 캐시는 낡아 있고, 분석 플랫폼은 며칠씩 뒤처지며, 검색 인덱스는 데이터를 흘린다. 서로 다른 시스템을 가로지르는 트랜잭션 갱신은 여전히 미해결 연구 과제로 남아 있다. Orkes가 개발한 ParticleDB는 바로 이 지점을 겨냥한다. 트랜잭션 SQL, 키-값 저장소, 벡터 검색, 실시간 분석, 그리고 Particle이라 불리는 사용자 정의 함수를 하나의 엔진에 담고, Postgres·Redis 프로토콜은 물론 자체 gRPC·HTTP2 API까지 제공한다. Rust로 처음부터 다시 쓰여 'Postgres보다 수십 배 빠르면서도 같은 안전성을 유지한다'고 내세운다. 원래는 Orkes의 워크플로 오케스트레이션 플랫폼 Conductor를 위해 만들어졌고, 더 넓은 공개를 앞두고 와이어 프로토콜과 데이터타입, OLAP 질의 등을 대거 추가한 리팩터링 버전을 Jepsen이 1.1.4부터 검증했다.
문서와 마케팅이 서로 어긋났다
검증에서 가장 먼저 드러난 것은 코드가 아니라 설명의 혼란이었다. 홈페이지는 ParticleDB가 TLA+로 '형식적으로 증명되었다'고 광고했지만, 협업 기간 내내 실제 TLA+ 명세는 제공되지 않았다. 무엇이 증명되었는지, 그 증명이 지금의 구현을 설명하는지조차 불분명했다. '완전한 ACID, 159K TPS'라는 문구 바로 아래에는 '스냅샷 격리'가 적혀 있었는데, 스냅샷 격리는 완전한 격리가 아니다. WAL 동기화 방식(sync·groupsync·nosync)을 둘러싼 설명도 출처마다 달랐다. 트랜잭션 엔진 문서는 sync가 groupsync보다 '더 강한 내구성'을 준다고 했지만, CLI 도움말과 내부 운영 가이드는 groupsync가 sync와 '동일한 내구성'을 보장한다고 적어 서로 모순됐다.
격리 수준 제어는 더 큰 함정이었다. 대부분의 SQL 데이터베이스가 쓰는 SET TRANSACTION ISOLATION LEVEL 구문을 ParticleDB는 무시하거나 거부했고, 어떤 경우에는 요청을 받아들인 뒤 문서와 달리 조용히 무시했다. 실제 격리는 시작 시점에 넘기는 --txn-mode 설정(fast·occ·zero-copy-occ·table-2pl)이 좌우했다. 그런데 문서는 이 모드들이 무엇을 보장하는지 설명하지 않았다. '신중하게 고르라'면서도 fast가 Read Atomic인지 Read Uncommitted인지, occ가 Serializable인지, zero-copy-occ가 어떤 점에서 안전하지 않은지 밝히지 않았다. 심지어 OCC는 락을 피하는 기법인데도 문서에는 테이블 락과 row-2pl 별칭이 등장했다. Orkes는 이 문서가 틀렸으며 occ는 실제로 낙관적 방식이고 row-2pl은 과거 호환용 별칭이라고 해명했다. 결국 occ-v3와 groupsync가 사실상 기본값으로 정리됐다.
안전성을 따지기 전에 멈춰 섰다
Jepsen은 rw, append 같은 기존 워크로드에 더해 단일 트랜잭션 내부 일관성을 검사하는 internal, PostgreSQL과 결과를 직접 대조하는 compare, 복잡한 트랜잭션을 공략하는 internal-sim 워크로드를 새로 설계했다. 특히 Clojure의 test.check로 무작위 테이블과 SQL을 생성해 ParticleDB와 PostgreSQL의 동작이 어긋나면 최소 재현 사례로 좁혀가는 compare 방식은 비교적 단순한 생성기만으로도 놀라운 성과를 냈다. 공식 Java SDK는 Maven 의존성으로 안내돼 있었으나 실제로는 JAR도 소스도 없어, Postgres JDBC 클라이언트로 시작해야 했다.
결과는 가혹했다. Debian 13 위 컨테이너와 EC2에서 1.1.4부터 1.1.18.11.rc-22까지 검증하며 총 96건의 문제를 찾았고, 그중 세 건을 제외한 전부가 장애를 주입하지 않은 건강한 단일 노드에서 발생했다. 많은 경우 격리 위반을 논하기도 전에 데이터베이스 자체가 쓸 수 없었다. table-2pl 모드는 1.1.4~1.1.18.4에서 대부분의 트랜잭션이 10초, 20초, 심하면 30초를 멈춰 있다가 '동시 갱신으로 직렬화 불가' 오류나 IO 오류를 냈다. 지연 문제(#62)는 1.1.18.6에서 나아졌지만, 같은 버전은 아무 오류 메시지 없이 수백~수천 초 만에 노드가 죽는 잦은 크래시(#81)를 동반했다. 1.1.18.8에서는 동시 트랜잭션 단 두 건만으로도 교착이 발생했고(#27), table-2pl의 교착은 rc-6까지도 남아 약 30초 뒤 노드가 영구히 멈추곤 했다(#71).
실무자가 읽어야 할 지점
이 보고서가 다루는 범위가 단일 노드에 한정된다는 점은 중요하다. Raft 기반 복제는 엔터프라이즈 클라우드 전용 기능이고, Orkes가 제공한 빌드가 복제를 지원하지 않았기 때문이다. 즉 분산 환경의 합의·장애 조치는 아직 검증 대상조차 되지 못했으며, 단일 노드에서 드러난 성능·안정성 문제가 먼저 해결되어야 할 선결 과제다. 다수의 버그가 후속 릴리스 후보(rc)에서 수정됐다는 사실은 Orkes가 적극적으로 대응했음을 보여주지만, 동시에 공개를 준비하던 제품이 기본적인 동시성 처리에서 반복적으로 멈췄다는 신호이기도 하다.
한국의 실무자에게 이 사례의 교훈은 특정 제품의 성패를 넘어선다. 'Rust로 다시 썼다', '형식 증명', '완전한 ACID' 같은 표현은 그 자체로 안전성을 담보하지 않는다. 바로 아래 줄의 '스냅샷 격리'처럼, 마케팅 문구와 실제 보장 사이의 간극은 흔히 작은 글씨에 숨어 있다. 격리 수준을 표준 SQL 구문이 아니라 기동 플래그로 바꾸고, 그 플래그가 무엇을 보장하는지 문서가 말하지 않는다면, 도입 전 스테이징 환경에서 자신의 워크로드로 직접 동시성과 내구성을 재현해 보는 수밖에 없다. 새로운 통합형 데이터 엔진을 검토할 때는 벤치마크 수치보다 먼저 '이 모드에서 무엇이 보장되는가'를 문서로, 그리고 테스트로 확인하는 습관이 필요하다.