핵심 내용
GeekNews 최신 글에 올라온 LatticeDB를 원본 GitHub 저장소까지 확인했다. LatticeDB는 relationship graph, HNSW vector search, BM25 full-text search를 하나의 embedded single-file 데이터베이스와 query layer 안에서 제공하는 오픈소스 프로젝트다.
Graph RAG나 Agent memory처럼 같은 데이터에서 '누가 누구와 연결되어 있는가', '의미가 비슷한가', '정확한 키워드가 포함되는가'를 동시에 조회해야 하는 애플리케이션을 서버 없이 로컬에서 구성하는 것을 목표로 한다. property graph node·edge, ACID transaction, crash recovery, vector index, BM25와 fuzzy search, Cypher 계열 query를 지원한다.
프로젝트는 Python, TypeScript, Go, Java, C binding을 제공하며 core는 Zig로 작성됐다. MIT 라이선스다. 다만 embedded single-writer 구조이고 한 머신의 한 파일에 저장되므로 여러 서버가 동시에 쓰는 서비스, sharding, multi-node replica가 필요한 대규모 production database를 대체하는 제품은 아니다. 프로젝트 README도 이런 경우 Neo4j, PostgreSQL, Neptune 같은 다른 시스템을 권장한다.
배경
RAG 초기에는 vector database 하나로 충분하다고 보는 경우가 많았지만 Agent가 복잡한 entity와 관계를 기억해야 할수록 vector similarity만으로는 부족해진다. 반대로 graph DB와 vector DB, full-text engine을 각각 운영하면 작은 앱이나 local-first AI 도구에서는 운영복잡성이 지나치게 커질 수 있다.
LatticeDB는 SQLite처럼 애플리케이션 안에 포함되는 방식으로 이 세 검색방식을 하나의 파일에 합치려는 접근이다.
산업·시장에 미치는 영향
AI 데이터계층에서 '대규모 managed vector DB'와 별도로 local-first embedded retrieval 시장이 커질 가능성을 보여준다. 로컬 AI, 개인 Agent, 데스크톱 앱, 개발용 prototype에서는 별도 서버 없이 graph와 semantic retrieval을 함께 사용할 수 있다는 점이 장점이다.
반면 중앙 서비스의 핵심 DB로 사용하기에는 single-writer, single-node, 아직 짧은 운영이력이라는 제한이 크다.
실무에서 바로 활용할 수 있는 시사점
로컬 Agent나 소규모 RAG prototype을 만들고 있다면 PostgreSQL+pgvector+graph extension이나 여러 별도 서비스를 띄우기 전에 LatticeDB 같은 embedded 구조를 POC해볼 수 있다. 실제 평가에서는 벤치마크 숫자보다 데이터 증가 후 latency, crash recovery, backup/restore, schema migration과 binding 안정성을 확인해야 한다.
production에서 여러 process가 동시에 쓰거나 수평확장이 필요한 서비스라면 기존 client-server DB가 더 적합하다.