벡터 데이터베이스

한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

책 링크

 

 

LLM을 서비스에 붙이는 일은 이제 특별하지 않다. 사내 문서를 찾아 답해 주는 챗봇이나 고객 문의를 분류하는 기능 정도는 웬만한 팀이라면 이미 만들어 봤거나 만들고 있을 것이다. 그리고 직접 만들어 본 사람이라면 이런 상황을 한 번쯤 겪었을 것이다. 분명 문서에 있는 내용인데 AI는 모른다고 답하거나, 엉뚱한 문서를 근거로 그럴듯한 답을 내놓는다. 이럴 때 보통은 모델을 바꾸거나 프롬프트를 고쳐 보지만, 정작 문제는 그 앞 단계인 검색에 있는 경우가 많다. 모델이 아무리 뛰어나도 엉뚱한 문서를 건네받으면 엉뚱한 답을 할 수밖에 없다.

 

벡터 데이터베이스는 바로 이 검색을 맡는 핵심 기술이다. 그런데 서버 개발자에게 벡터 DB라는 말은 기술보다 운영을 먼저 떠올리게 한다. 저장소를 하나 더 들인다는 건 모니터링하고, 백업하고, 장애에 대응해야 할 대상이 하나 늘어난다는 뜻이기 때문이다. Pinecone, Milvus, Qdrant 같은 이름은 많이 들어 봤지만, 정작 무엇이 다른지, 꼭 따로 둬야 하는지는 막연했다.

 

이 책은 그 막연함을 의외로 익숙한 곳에서 풀어낸다. 특정 벡터 DB 제품의 사용법 대신, SQLite3와 PostgreSQL처럼 이미 알고 있는 데이터베이스에 벡터 검색 기능을 더하는 데서 출발한다. 임베딩은 어떻게 만들어지는지, 유사도는 어떻게 계산하는지, 인덱스는 왜 필요한지를 FAISS, sqlite-vss, pgvector, Ollama 같은 무료 도구로 하나씩 구현하며 따라간다. 유료 클라우드나 대규모 인프라 없이 로컬에서 끝까지 실습할 수 있다는 점도 좋았다. 읽으면서 기억에 남은 내용을 몇 가지 정리해 봤다.

 

벡터 검색은 정답을 찾는 일이 아니라 가까운 후보를 빠르게 찾는 일이다. 데이터가 많아지면 질문과 모든 벡터 사이의 거리를 일일이 계산할 수 없으므로, ANN(근사 최근접 이웃) 검색으로 정확도를 조금 내주고 속도를 얻는다. HNSW 같은 인덱스는 이 절충을 구현하는 방법이다. 그래서 인덱스를 어떻게 설정하느냐에 따라 무엇을 놓칠 수 있는지도 함께 따져 봐야 한다.

 

벡터와 원문, 메타데이터를 한 데이터베이스에 두면 SQL 조건과 의미 검색을 한 번에 섞을 수 있다. '의미가 비슷한 문서 중 현재 유효한 규정만'처럼 업무 맥락이 담긴 조건은 결국 WHERE 절로 표현된다. 벡터 전용 저장소를 따로 두지 않고도 시작할 수 있는 이유가 여기에 있다.

 

검색 품질은 저장소에 넣기 전에 이미 상당 부분 정해진다. PDF에서 텍스트를 제대로 뽑아냈는지, 청크를 어떤 크기로 나눴는지, 어떤 임베딩 모델을 썼는지에 따라 같은 인덱스를 써도 결과가 크게 달라진다. arXiv 논문으로 검색 시스템과 RAG를 만드는 5장과 7장에서 이 과정을 처음부터 끝까지 따라가 볼 수 있다.

 

마지막 장의 벡터 쿼리 언어(VQL)도 흥미로웠다. 관계형 데이터베이스에는 SQL이라는 표준이 있어 벤더가 바뀌어도 쿼리를 크게 고칠 필요가 없지만, 벡터 데이터베이스는 아직 제품마다 문법도 연산자도 제각각이다. 저자는 여기에 특정 벤더에 종속되지 않는 쿼리 언어를 제안한다. 아직 업계 표준이라 부르기는 이르지만, 벡터 DB를 별개의 제품이 아닌 데이터베이스의 한 갈래로 바라보는 관점이 신선했다.

 

너무 얕지도 깊지도 않은 깊이로 벡터 검색의 원리부터 RAG까지를 한 흐름으로 엮어 낸 책이다. RAG를 만들어 봤지만 검색 결과가 왜 그렇게 나오는지 설명하기 어려웠던 개발자, 벡터 DB를 새로 들이기 전에 지금 쓰는 데이터베이스로 어디까지 할 수 있는지 알고 싶은 백엔드 개발자라면 한번 읽어 봐도 좋겠다.