온디바이스 벡터 데이터베이스 2026, livero LSM·HNSW 로컬 RAG 도입 기준

온디바이스 벡터 데이터베이스와 로컬 AI 검색을 스마트폰과 엣지 보드에서 점검하는 장면 — 온디바이스 벡터 검색은 서버 비용을 줄일 수 있지만, 인덱스·동기화·삭제 정책을 앱 안으로 끌고 온다.

온디바이스 벡터 데이터베이스를 검토할 때 먼저 볼 것은 “서버가 없어져서 싸진다”가 아니라 “데이터와 인덱스 책임이 기기 안으로 들어온다”는 점이다.

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 바인딩이 제품 운영 비용에 어떤 차이를 만드는지 판단해야 하는 제품 책임자

서버형 벡터 DB와 온디바이스 벡터 DB의 선택 기준

구분	서버형 벡터 DB	온디바이스 벡터 데이터베이스	판단 기준
데이터 위치	임베딩과 원문 일부가 서버 또는 클라우드에 모인다	검색 대상과 인덱스가 사용자 기기 안에 남는다	민감 데이터와 오프라인 요구가 강하면 온디바이스 쪽을 먼저 검토한다
비용 구조	쿼리, 저장, 백업, 네트워크, 모니터링 비용이 서버에서 발생한다	앱 크기, 배터리, 로컬 저장소, QA 기기 매트릭스 비용이 커진다	사용자 수가 크고 데이터 범위가 작으면 로컬이 유리할 수 있다
운영 난이도	중앙 배포와 관측은 쉽지만 장애 범위가 넓다	기기별 성능 차이와 인덱스 포맷 호환성을 봐야 한다	장애 원인을 서버 로그만으로 보려는 팀은 보류가 낫다
검색 품질	고사양 서버에서 큰 인덱스와 reranker를 붙이기 쉽다	메모리와 배터리 때문에 인덱스 규모와 search width가 제한된다	작은 개인화 검색은 로컬, 대규모 지식검색은 서버가 맞다
보안 통제	IAM, 네트워크, 감사 로그로 중앙 통제가 가능하다	앱 탈옥, 백업, 디버그 추출, 로그 누출을 막아야 한다	기기 보안 모델과 삭제 테스트가 준비돼야 한다

이 표에서 중요한 결론은 온디바이스 방식이 서버형보다 항상 싸거나 안전하지 않다는 점이다.

클라우드 청구서는 줄어도 모바일 QA, 인덱스 마이그레이션, 고객지원 로그 분석, 배터리 민원 비용이 새로 생긴다.

이 조건이면 검토할 만하다.

검색 대상이 사용자 개인 데이터나 현장 매뉴얼처럼 작고, 네트워크가 불안정하며, 서버 전송 자체가 규제나 신뢰 이슈를 만든다면 온디바이스 벡터 데이터베이스가 맞다.

반대로 수백만 문서, 자주 바뀌는 권한, 중앙 감사, 복잡한 reranking이 필요하면 서버형 벡터 DB가 더 단순하다.

livero 구조에서 확인할 기술 포인트

livero README는 레코드를 key, value, optional vector, typed metadata로 저장하고 필터 결합 nearest-neighbor query를 기기 안에서 수행한다고 설명한다.

저장 계층은 WAL, memtable, SST, compaction으로 구성된 LSM-tree 계열이다.

검색 계층은 HNSW 그래프를 사용하며, 벡터 ID에서 SST offset으로 이어지는 companion file을 둬 검색 결과와 저장 레코드를 연결한다.

HNSW 그래프 자체는 디스크에 저장하지 않고 open 시 레코드를 replay해 메모리에서 재구성한다는 점도 운영 판단에 중요하다.

이 방식은 on-disk 포맷을 단순하게 만들지만, 앱 cold start와 인덱스 재빌드 시간이 사용자 경험을 흔들 수 있다.

구성 요소	좋은 점	검증해야 할 점	실패하면 생기는 문제
WAL	쓰기 중단 뒤에도 복구 단서를 남긴다	torn write, truncate, 앱 강제 종료 테스트	인덱스와 레코드가 어긋나 검색 결과가 사라진다
SST와 compaction	순차 쓰기와 정렬 파일로 로컬 저장소에 맞춘다	쓰기 폭주, 삭제 누적, compaction 지연	앱 저장소가 커지고 배터리와 I/O가 늘어난다
HNSW	전체 스캔 없이 근사 최근접 검색을 빠르게 만든다	recall@k, search width, 삭제와 업데이트 처리	빠르지만 엉뚱한 답을 보여 사용자 신뢰가 떨어진다
ARM NEON SIMD	ARM64 모바일과 엣지 기기에서 거리 계산을 빠르게 한다	x86 fallback, 테스트 기기 범위, 빌드 플래그	일부 환경에서 빌드가 막히거나 성능이 크게 달라진다
FFI 문자열 API	JNI나 Swift 바인딩이 비교적 단순해진다	쿼리 문자열 파싱, escape, 타입 검증	필터 오동작이나 injection성 입력이 버그로 이어진다

HNSW 논문은 계층형 그래프를 통해 근사 최근접 검색을 빠르게 만드는 아이디어를 제시한다.

hnswlib 문서도 M, ef_construction, ef 같은 파라미터가 정확도와 속도 사이의 교환 관계를 만든다고 설명한다.

따라서 앱 배포에서는 p95 query latency만 보면 안 된다.

recall@10, 잘못된 답변율, 필터 누락률, 삭제 후 잔존 결과, 모델 버전 변경 시 재색인 시간을 함께 봐야 한다.

실무 시나리오 1: 현장 기술지원 앱의 오프라인 매뉴얼 검색

제조 장비 유지보수팀은 공장 내부 네트워크가 불안정한 상황에서도 오류 코드와 수리 절차를 찾아야 한다.

이 경우 서버형 RAG는 네트워크 장애와 권한 터널링이 병목이 되고, 온디바이스 벡터 데이터베이스는 오프라인 검색 경험을 안정시킬 수 있다.

검색 대상은 공개 매뉴얼과 장비별 FAQ로 제한하고, 고객명이나 현장 사진 설명은 임베딩 대상에서 제외한다.

제품팀은 매뉴얼 버전과 임베딩 모델 버전을 함께 고정해야 한다.

매뉴얼이 바뀌었는데 인덱스만 오래된 상태로 남으면 로컬 검색은 빠르지만 틀린 절차를 안내한다.

이 조건이면 선택이 맞다.

문서 수가 수만 개 이하이고 업데이트 주기가 명확하며, 현장 담당자가 네트워크 없이도 같은 답을 받아야 한다면 로컬 인덱스가 실용적이다.

실무 시나리오 2: 개인 노트 앱의 프라이버시 검색

개인 노트, 상담 메모, 건강 기록처럼 서버 전송 자체가 신뢰 이슈인 데이터는 온디바이스 검색의 명분이 강하다.

사용자는 “내 데이터가 서버로 올라가지 않는다”는 설명을 기대하고, 보안팀은 실제로 임베딩 payload가 분석 로그로 나가지 않는지 확인해야 한다.

이 경우에는 벡터 DB보다 로그 정책이 더 중요하다.

검색어, top-k 결과, vector score, 디버그 dump가 원격 분석에 섞이면 온디바이스 구조의 장점이 사라진다.

삭제 테스트도 필수다.

로그아웃, 앱 삭제, 계정 전환, 백업 복원 뒤에도 로컬 인덱스와 WAL 조각이 남지 않는지 확인해야 한다.

실무 시나리오 3: 매장 POS의 로컬 상품 추천

매장 POS나 키오스크는 네트워크 지연이 매출 손실로 바로 연결되므로 작은 상품 카탈로그를 로컬에 둔 검색이 매력적이다.

다만 상품 가격, 프로모션, 재고는 서버 기준 원장이므로 로컬 벡터 결과가 구매 결정을 확정하면 안 된다.

온디바이스 벡터 데이터베이스는 후보 검색까지만 담당하고, 최종 가격과 재고 확인은 서버 API로 검증하는 구조가 안전하다.

이 경우는 보류가 맞다.

카탈로그가 매시간 크게 바뀌거나 매장별 권한이 복잡하면 로컬 인덱스 동기화가 서버형 검색보다 비싸질 수 있다.

비용 리스크: 서버 청구서 대신 앱 운영비가 생긴다

서버 벡터 DB를 줄이면 저장소, 네트워크, 쿼리, 백업, 모니터링 비용 일부가 줄어든다.

하지만 온디바이스 구조는 앱 설치 용량, 로컬 저장소, 배터리, 크래시 분석, 기기별 QA, 고객지원 재현 비용을 만든다.

특히 HNSW 인덱스는 search breadth를 올리면 recall이 좋아지지만 메모리와 CPU 사용량이 늘어난다.

LSM 계열 저장소는 쓰기에는 유리하지만 compaction이 앱 사용 중 튀면 체감 성능과 배터리 소모가 나빠질 수 있다.

예산표에는 클라우드 DB 비용만 넣지 말고 모바일 QA 기기, 성능 실험, 앱스토어 릴리스 지연, 롤백 대응 시간을 넣어야 한다.

보안 리스크: 벡터도 개인정보가 될 수 있다

원문을 서버로 보내지 않는다고 해서 벡터가 자동으로 안전한 것은 아니다.

민감한 문장에서 만든 임베딩은 원문 일부를 직접 담지 않더라도 개인 식별, 주제 추론, 멤버십 추론 리스크를 만들 수 있다.

보안팀은 로컬 암호화, 키 보관 위치, 디버그 export 금지, 크래시 로그 필터링, 백업 제외 규칙을 확인해야 한다.

앱이 원격 분석을 쓰는 경우에는 vector payload, 검색어, top-k result key, metadata filter가 전송되지 않는지 별도 테스트가 필요하다.

규제 대상 데이터라면 “서버로 안 보냈다”보다 “기기에 남은 데이터를 언제 어떻게 지웠다”가 감사 포인트가 된다.

운영 리스크: 모델 버전과 인덱스 포맷을 같이 관리한다

임베딩 모델이 바뀌면 기존 벡터와 새 벡터가 같은 공간에 있다고 가정하기 어렵다.

따라서 모델 버전, vector dimension, normalization 방식, distance metric, index format version을 manifest로 묶어야 한다.

앱 업데이트 후 새 바이너리가 예전 인덱스를 읽지 못하면 사용자는 검색 불가 상태를 만난다.

반대로 예전 바이너리가 새 인덱스를 잘못 읽으면 조용히 틀린 검색 결과가 나온다.

운영팀은 이전 포맷 읽기, 재색인, 부분 다운로드, 롤백 바이너리, 사용자 데이터 삭제를 release gate에 넣어야 한다.

배포 전 정책 스켈레톤

아래 YAML은 온디바이스 벡터 데이터베이스를 제품에 넣기 전 데이터 범위, 모델 버전, 인덱스 한도, 보안 통제를 한곳에 고정하는 예시다.

# on-device-vector-db-policy.yaml
# 목적: 온디바이스 벡터 데이터베이스를 앱에 넣기 전에 데이터, 인덱스, 동기화, 삭제 정책을 먼저 고정한다.
# 실제 값은 제품 보안 정책, 모바일 OS 권한, 데이터 보존 규칙, 모델 라이선스에 맞게 조정한다.

application:
  name: field-support-local-rag
  platform:
    - android-arm64
    - ios-arm64
  network_dependency: optional
  server_vector_db_fallback: disabled_by_default

data_scope:
  allowed_content:
    - public_product_manuals
    - user_owned_notes
    - offline_faq_cache
  blocked_content:
    - payment_data
    - government_id
    - raw_customer_chat_without_consent
    - biometric_template

embedding:
  model_version_pin: required
  vector_dimension: fixed_per_index
  normalization: required_when_dot_product
  reindex_on_model_change: required

index:
  storage_engine: lsm_tree_or_equivalent
  ann_index: hnsw_or_equivalent
  metadata_filter_required: true
  max_local_records: 50000
  rebuild_budget_seconds: 20
  crash_recovery_test: required

security:
  encrypt_at_rest: required
  delete_user_data_on_logout: required
  export_debug_index: forbidden
  analytics_vector_payload: forbidden
  pii_scan_before_embedding: required

operations:
  battery_budget_percent_per_session: 3
  memory_budget_mb: 256
  cold_start_rebuild_allowed: false
  recall_test_sample_size: 200
  rollback_plan: keep_previous_index_format

이 파일에서 비어 있으면 안 되는 항목은 allowed_content, blocked_content, reindex_on_model_change, delete_user_data_on_logout, rollback_plan이다.

기술 선택보다 데이터 범위와 삭제 조건이 먼저 정리돼야 보안 검토가 빨라진다.

로컬 인덱스 사전 점검 스크립트

아래 Python 예시는 배포 전 manifest를 읽어 플랫폼, 레코드 수, 모델 버전, 개인정보, 재빌드 시간, 암호화 여부를 확인하는 스켈레톤이다.

#!/usr/bin/env python3
# edge_vector_preflight.py
# 목적: 온디바이스 벡터 데이터베이스를 배포하기 전 인덱스 크기, 모델 변경, 개인정보, 재빌드 시간을 점검하는 예시다.
# 실제 앱에서는 모바일 기기별 벤치마크와 OS 보안 저장소 검증을 추가해야 한다.

import json
import sys
from pathlib import Path

manifest = json.loads(Path("edge_vector_manifest.json").read_text())
problems = []

if manifest.get("platform") not in {"android-arm64", "ios-arm64", "arm-linux"}:
    problems.append("unsupported platform for current native vector build")

if manifest.get("record_count", 0) > manifest.get("max_local_records", 50000):
    problems.append("local record count exceeds approved limit")

if manifest.get("embedding_model_version") != manifest.get("index_model_version"):
    problems.append("embedding model changed, full reindex is required")

if manifest.get("contains_pii") is True:
    problems.append("PII must be removed or explicitly consented before embedding")

if manifest.get("rebuild_seconds", 9999) > manifest.get("rebuild_budget_seconds", 20):
    problems.append("cold-start rebuild is too slow for offline UX")

if manifest.get("encrypted_at_rest") is not True:
    problems.append("local vector store must be encrypted at rest")

print({"ok": not problems, "problems": problems})
sys.exit(1 if problems else 0)

실제 제품에서는 기기별 벤치마크 결과와 모바일 OS 저장소 정책을 이 점검에 붙여야 한다.

CI에서 통과했더라도 저가형 기기, 저장소 부족 상태, 앱 강제 종료 시나리오는 별도 실기기로 확인해야 한다.

CI 게이트는 정확도와 삭제를 같이 본다

온디바이스 벡터 검색은 검색 품질 테스트와 개인정보 삭제 테스트를 분리하면 사고가 난다.

# edge-vector-ci-check.yml
# 실제 CI 문법은 조직의 빌드 시스템에 맞게 바꾼다.
# 핵심은 정확도, 삭제, 복구, 배터리 예산을 같은 게이트에서 본다는 점이다.

checks:
  unit:
    - vector_insert_get_delete
    - metadata_filter_query
    - crash_recovery_replay
  quality:
    recall_at_10_min: 0.85
    stale_answer_rate_max: 0.02
  privacy:
    pii_embedding_sample_scan: required
    logout_delete_test: required
  performance:
    p95_query_ms_max: 80
    cold_open_ms_max: 500
    memory_mb_max: 256
    battery_percent_per_session_max: 3
  release:
    previous_index_format_readable: required
    rollback_binary_available: required

recall 기준을 통과했지만 로그아웃 삭제 테스트가 실패하면 배포하지 않는 식의 단순한 원칙이 필요하다.

반대로 삭제는 완벽해도 cold open이 너무 느리면 사용자는 검색 기능을 꺼버린다.