벡터 DB Vector database, 벡터 데이터베이스
벡터 DB는 글·이미지 같은 데이터를 숫자 목록(벡터, 임베딩)으로 바꿔 저장해 두고, 질문과 '뜻이 가까운' 데이터를 빠르게 찾아 주는 데이터베이스다.
어떻게 작동하나
먼저 AI 모델이 문서나 이미지를 임베딩이라는 숫자 목록으로 바꾼다. 뜻이 비슷한 데이터일수록 이 숫자 목록끼리의 거리가 가깝게 나온다. 벡터 DB는 이 벡터를 저장해 두었다가 질문도 같은 방식으로 벡터로 바꾼 뒤, 가장 가까운 벡터들을 찾아 돌려준다. 데이터가 아주 많으면 하나하나 다 비교하기 어려우므로, 약간의 정확도를 양보하고 속도를 크게 높이는 '근사 최근접 이웃 검색'을 주로 쓴다. 여기에 일반 데이터베이스처럼 추가·수정·삭제나 조건(메타데이터) 필터 기능을 더한 것이 벡터 DB다.
어떻게 발전해 왔나
벡터 DB의 핵심은 '가까운 벡터를 빨리 찾는 방법'이고, 이를 위한 연구가 꾸준히 쌓여 왔다. 2016년 Malkov와 Yashunin의 HNSW 논문은 데이터를 여러 층의 그래프로 연결해, 위층에서 큰 걸음으로 이동하고 아래층에서 세밀하게 찾아가는 검색 방식을 새로 제안했다. 2017년 Johnson, Douze, Jégou의 논문은 GPU를 효율적으로 써서 10억 개 규모의 벡터에서도 비슷한 것을 찾을 수 있게 만들었고, 이를 공개했다. 이 연구는 주로 Meta AI Research에서 개발하는 오픈소스 라이브러리 Faiss로 이어졌다. 이후 이런 검색 기법을 저장·관리 기능과 묶은 전용 벡터 DB와, 기존 데이터베이스(예: Postgres)에 벡터 검색을 더하는 확장 기능이 함께 쓰이고 있다.
왜 중요한가
LLM은 학습한 내용 밖의 사내 문서나 최신 정보를 모르기 때문에, 필요한 자료를 찾아 함께 건네주는 RAG 방식이 널리 쓰인다. 이때 질문과 관련된 문서 조각을 찾아 주는 역할을 벡터 DB가 맡는다. 단어가 정확히 일치하지 않아도 뜻이 비슷하면 찾아 주므로, '환불 방법'을 물어도 '반품 절차' 문서를 찾을 수 있다. AI 에이전트가 이전 대화나 작업 기록을 기억하는 '장기 기억' 저장소로도 쓰인다.
알아 둘 점
근사 검색이라 가장 가까운 결과를 가끔 놓칠 수 있고, 속도와 정확도 사이에서 설정을 조절해야 한다. 검색 품질은 벡터 DB 자체보다 어떤 임베딩 모델을 쓰고 문서를 어떻게 나누는지(청킹)에 크게 좌우된다. 뜻 기반 검색은 제품 코드나 고유명사처럼 정확한 단어 일치가 중요한 경우에 약할 수 있어, 키워드 검색을 섞는 하이브리드 검색이나 결과를 다시 정렬하는 리랭커를 함께 쓰는 경우가 많다. 데이터가 적다면 전용 벡터 DB 없이 기존 데이터베이스의 확장 기능만으로도 충분할 수 있다.
예시
회사가 사내 규정 문서를 바탕으로 답하는 챗봇을 만든다고 하자. 문서를 문단 단위로 나눠 임베딩한 뒤 벡터 DB에 넣어 두면, 직원이 질문할 때 가장 관련 있는 문단 몇 개를 찾아 LLM에 함께 건넬 수 있다. 이때 Pinecone 같은 전용 서비스를 쓰거나, 이미 Postgres를 쓰고 있다면 오픈소스 확장인 pgvector를 설치해 기존 데이터 옆에 벡터를 함께 저장하고 검색하는 방법을 고를 수 있다. 직접 검색 엔진을 만들 때는 Faiss 같은 라이브러리를 쓰기도 한다.
함께 보면 좋은 용어
참고
- Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs (2016)
- Billion-scale similarity search with GPUs (2017)
- What is a Vector Database & How Does it Work? Use Cases + Examples | Pinecone
- Vector database - Wikipedia
- GitHub - pgvector/pgvector: Open-source vector similarity search for Postgres · GitHub
- Home · facebookresearch/faiss Wiki · GitHub