온디바이스 벡터 데이터베이스 2026, livero LSM·HNSW 로컬 RAG 도입 기준
온디바이스 벡터 검색은 서버 비용을 줄일 수 있지만, 인덱스·동기화·삭제 정책을 앱 안으로 끌고 온다. 온디바이스 벡터 데이터베이스를 검토할 때 먼저 볼 것은 “서버가 없어져서 싸진다”가 아니라 “데이터와 인덱스 책임이 기기 안으로 들어온다”는 점이다. livero는 C로 작성된 임베디드 벡터 데이터베이스로, WAL·memtable·SST 기반 LSM-tree와 HNSW 인덱스를 묶어 기기 안에서 필터 결합 벡터 검색을 수행하는 프로젝트다. README 기준으로 ARM64 환경, ARM NEON SIMD, 외부 의존성 0, FFI 바인딩을 염두에 둔 문자열 API가 핵심 특징이다. 다만 v1 상태라는 설명도 같이 봐야 한다. x86 미지원, 동시성 한계, 모바일 바인딩 작업, HNSW 그래프 재빌드, crash recovery 테스트 보강 같은 로드맵이 남아 있기 때문이다. 핵심 요약 온디바이스 벡터 데이터베이스는 개인정보와 지연 시간에는 유리하지만, 앱 크기·배터리·동기화·삭제 책임이 커진다. livero 같은 구조는 LSM-tree로 레코드를 저장하고 HNSW로 근사 최근접 검색을 처리하므로 저장 안정성과 검색 품질을 따로 검증해야 한다. 서버형 벡터 DB를 완전히 대체하기보다 오프라인 FAQ, 개인 노트, 현장 매뉴얼처럼 데이터 범위가 작고 민감한 사용처부터 검토하는 편이 안전하다. 배포 전에는 모델 버전 고정, reindex 조건, 로컬 암호화, 로그 수집 금지, 삭제 테스트, recall 샘플링을 게이트로 묶어야 한다. 이 글이 필요한 사람 모바일 앱 안에 로컬 RAG나 시맨틱 검색을 넣으려는 앱 개발 리드 서버 벡터 DB 비용과 개인정보 반출 리스크를 줄이고 싶은 데이터 플랫폼 담당자 ARM 기기, 엣지 장비, 오프라인 현장 앱에서 검색 품질을 검증해야 하는 AI 엔지니어 벡터 인덱스가 개인정보, 로그, 삭제 정책에 미치는 영향을 확인해야 하는 보안팀 HNSW, LSM-tree, FFI 바인딩이 제품 운영 비용에 어떤 차이를 만드는지...
