벡터DB, 정말 필요한가? 과잉 설계 논쟁 정리
은 의미적으로 비슷한 데이터를 찾아주는 기술로, LSH 같은 방식은 수십 년 전부터 있었지만 최근 LLM에서 나온 임베딩 때문에 규모가 커지면서 다시 주목받고 있다. 현재 나온 대부분은 사실 기존 키-값 저장소나 Elasticsearch·OpenSearch 같은 검색 엔진에 HNSW·IVF 같은 벡터 색인 기능을 얹은 형태다.
이런 시스템은 벡터 저장, 색인 생성, 메타데이터 저장, 유사도 검색·필터링 기능을 함께 제공한다. 문제는 원본 데이터가 보통 이나 MongoDB 같은 일반 데이터베이스에 있고, 벡터는 별도의 벡터DB에 중복 저장된다는 점이다.
이 때문에 두 시스템 간 데이터를 계속 맞춰줘야 하는 동기화 문제, 데이터 일관성 문제, 저장 비용 증가가 발생한다. 또한 별도의 분산 시스템을 하나 더 운영해야 해서 인프라 관리 부담도 커진다.
핵심 포인트
- 기술 자체는 새로운 게 아니라 수십 년 된 기법(LSH)에서 출발했다
- 최근 벡터DB 대부분은 키-값 저장소나 검색 엔진에 HNSW·IVF 색인을 추가한 형태다
- 원본 데이터와 벡터를 별도 시스템에 나눠 저장하면 동기화·일관성·비용 문제가 생긴다
- 벡터DB를 추가로 운영하는 것 자체가 인프라 복잡도를 높인다