AI 애플리케이션과 RAG 파이프라인이 늘면서 한 가지 데이터를 관계(그래프), 의미(벡터), 텍스트(전문 검색)라는 세 가지 방식으로 동시에 다뤄야 하는 상황이 흔해졌다. 지금까지 실무자들은 이를 위해 그래프 DB, 벡터 검색 엔진, 검색 라이브러리를 각각 붙이거나, 관계형 DB에 확장을 얹어 억지로 맞추는 식으로 대응해 왔다. 최근 Hacker News에 'Show HN'으로 공개된 LatticeDB는 이 세 가지를 하나의 엔진과 하나의 쿼리 계층에서 처리하겠다는 목표를 내세운 오픈소스 프로젝트다. 스스로를 'SQLite와 같지만 그래프 DB를 위한 것'이라고 소개하는 점이 이 프로젝트의 성격을 압축해 보여준다.
단일 파일, 단일 작성자 모델
LatticeDB의 핵심 설계는 SQLite와 닮아 있다. 별도의 서버 프로세스 없이 애플리케이션에 임베드되며, 모든 데이터를 로컬의 단일 파일 하나에 담는다. 설정이 필요 없는 zero-config 운영을 지향하고, 하나의 프로세스가 파일을 열어 소유하는 단일 작성자(single-writer) 모델을 채택했다. 여기에 프로퍼티 그래프 구조를 기본으로 두고 벡터 인덱싱과 BM25 기반 전문 검색을 네이티브로 내장했다. 관계를 따라가는 그래프 탐색, 벡터 유사도 검색, 텍스트 검색을 같은 데이터셋 위에서 수행할 수 있다는 것이 차별점이다. 프로젝트 측은 Graph RAG, 에이전트 메모리, 로컬 지식 도구 같은 워크로드를 대표적인 활용 사례로 들면서도, 이는 엔진이 제공하는 기본 요소(primitive) 위에 세워진 응용일 뿐 엔진 자체의 정의는 아니라고 선을 긋는다.
배포 방식도 임베디드 지향을 반영한다. 파이썬 휠(wheel)과 npm 패키지는 지원 플랫폼에서 네이티브 라이브러리 liblattice를 함께 번들링하는 것을 전제로 하며, 소스 설치 시에는 LATTICE_BUNDLE_LIB_DIR 환경변수로 스테이징된 네이티브 라이브러리를 포함시킬 수 있다. Go의 경우 cgo 워크플로를 통해 연동하며, 기본 소비 경로는 설치된 pkg-config 메타데이터를 사용하고 저장소 내 개발 시에는 repolocal 태그를 쓰도록 안내한다. 그래프·벡터·텍스트 검색을 한 번에 보여주는 실행 가능한 예제도 함께 제공된다.
벤치마크가 말하는 것과 조건
프로젝트가 제시하는 성능 수치는 눈길을 끈다. 모든 벤치마크는 애플 M1, 단일 스레드, 자동 스케일 버퍼 풀 환경에서 측정됐다고 명시돼 있다. B+Tree는 캐시된 조회에서 마이크로초 미만의 응답을 내며 인메모리 RocksDB에 준하고 디스크 기반 SQLite보다 23배 빠르다고 한다. 벡터 검색은 128차원 코사인 벡터, HNSW 파라미터(M=16, ef_construction=200, ef_search=64, k=10) 기준으로 100만 건에서 평균 0.83ms에 recall@10 100%를 기록했으며, 단일 스레드 FAISS HNSW보다 빠르고 네트워크 오버헤드가 붙는 Weaviate·Qdrant 같은 서버형 시스템과 견줄 만하다고 설명한다. 전문 검색의 역색인과 BM25 스코어링은 SQLite FTS5보다 약 300배 빠르고 러스트 검색 라이브러리 Tantivy와 경쟁 가능한 수준으로 제시된다.
그래프 탐색 비교는 조건을 함께 읽어야 한다. 1만 노드·5만 엣지의 파워로 분포 소셜 그래프에서 인접 캐시를 미리 예열한 상태로 깊이 제한 탐색을 수행한 결과, LatticeDB는 인접 캐시와 비트셋 방문 추적을 쓰는 BFS로, SQLite는 재귀 CTE로 동일한 도달 노드 집합(약 8000개)을 계산했고, 재귀 깊이가 깊어질수록 CTE 오버헤드 때문에 격차가 벌어진다고 한다. 다만 이 수치들은 모두 특정 하드웨어와 사전 예열·특정 파라미터라는 유리한 조건에서 재현된 값이라는 점을 감안해야 한다. 실무 도입 전에는 zig build로 제공되는 각 벤치마크를 자신의 데이터와 환경에서 직접 돌려보는 것이 안전하다.
언제 쓰지 말아야 하는가
주목할 만한 점은 프로젝트가 자신에게 맞지 않는 경우를 스스로 명확히 밝힌다는 것이다. 여러 애플리케이션이 동시에 같은 DB에 써야 한다면 단일 작성자 모델인 LatticeDB는 적합하지 않으며 Neo4j나 PostgreSQL 같은 클라이언트-서버 DB가 필요하다. 데이터가 본질적으로 행과 열에 맞는 표 형태라면 관계형 DB가 더 단순하고 충분히 빠르다. 단일 머신을 넘어 샤딩·복제·분산 쿼리가 필요하면 Neo4j 클러스터, Dgraph, Neptune 같은 선택지를 봐야 한다. 그래프 DB는 레코드 간 관계 자체가 핵심일 때 빛을 발한다는 것이 이들의 입장이다.
기능과 생태계 측면의 한계도 분명하다. LatticeDB는 Cypher를 대부분 지원하지만 전부는 아니며, OPTIONAL MATCH나 CALL 프로시저 같은 기능은 아직 구현되지 않았다. 이런 쿼리에 의존한다면 완전한 구현체인 Neo4j가 답이다. 또한 시각화 도구, 관리 대시보드, 모니터링, 다양한 언어 드라이버, 축적된 커뮤니티 자료 같은 운영 생태계는 신생 프로젝트인 만큼 부족하다. 얇고 가벼운 구조는 임베딩에는 강점이지만 풍부한 운영 도구가 필요한 조직에는 약점이 된다. 결국 LatticeDB의 가치는 '로컬 단일 머신에서 관계·의미·텍스트를 한 파일로 다루는 임베디드 워크로드'라는 좁고 뚜렷한 지점에 있으며, 이 범위를 벗어난 요구에는 여전히 성숙한 기존 도구가 정답이라는 점을 개발자 스스로 인정하고 있는 셈이다.