벡터 DB

임베딩 벡터를 저장하고, 수백만 개 중에서 가장 유사한 항목을 밀리초 단위로 찾아주는 전문 데이터베이스. RAG의 검색 엔진 역할을 한다.

비슷함을 찾는 데이터베이스

우리가 흔히 쓰는 데이터베이스는 정확히 일치하는 걸 찾는 데 강하다. "이름이 홍길동인 사람", "주문번호가 12345인 건"처럼 값이 딱 맞아떨어지는 걸 골라낸다. 그런데 AI가 다루는 데이터는 그렇게 딱 떨어지지 않는다. 문장의 의미나 이미지의 분위기 같은 건 숫자 하나로 표현할 수 없어서, 임베딩이라는 기술로 수백 개의 숫자 묶음(벡터)으로 바꿔 놓는다. 벡터 DB는 바로 이 숫자 묶음을 저장하고, "이것과 의미가 가장 비슷한 것"을 찾아주는 데 특화된 데이터베이스다.

여기서 문제가 하나 있다. 수백만 개의 벡터가 있을 때 질문으로 들어온 벡터를 저장된 모든 벡터와 하나하나 비교하면 너무 오래 걸린다. 그래서 벡터 DB는 미리 벡터들을 끼리끼리 묶고 지도처럼 정리해 둔다. 대표적인 방식이 HNSW와 IVF다. HNSW는 가까운 벡터끼리 연결한 여러 층의 지도를 만들어, 위층에서 대략적인 방향을 잡고 아래층으로 내려가며 목적지를 정밀하게 좁혀 간다. IVF는 벡터들을 미리 여러 구역으로 나눠 두고 질문이 들어오면 가장 가까운 구역 몇 개만 뒤진다. 둘 다 모든 걸 다 보지 않고 가까운 후보만 살핀다는 발상이라, 정답을 아주 가끔 놓치는 대신 속도를 크게 끌어올린다. 이걸 근사 최근접 이웃(ANN) 검색이라 부른다.

어떻게 쓰나

가장 흔한 쓰임새는 RAG다. AI에게 사내 문서나 매뉴얼을 참고해 답하게 하려면, 먼저 그 문서들을 잘게 쪼개 임베딩으로 바꿔 벡터 DB에 넣어 둔다. 사용자가 질문하면 질문도 벡터로 바꿔서 벡터 DB에 던지고, 의미가 가까운 문서 조각 몇 개를 순식간에 받아온 뒤 그걸 함께 넣어 답을 만들게 한다. 벡터 DB가 RAG의 검색 엔진 역할을 하는 셈이다.

처음 프로토타입을 만들 땐 Chroma처럼 노트북에 바로 깔아 쓰는 걸로 시작했다가, 규모가 커지면 Pinecone 같은 관리형 서비스나 Qdrant, Milvus, Weaviate 같은 전용 엔진으로 옮겨 간다. 이미 Postgres를 쓰던 팀이라면 pgvector 확장을 붙여 기존 데이터 옆에 벡터를 함께 두기도 한다. 사용자 정보나 권한 같은 조건을 SQL로 걸면서 벡터 검색까지 한 번에 처리할 수 있어 편하기 때문이다.

의미만으로는 부족할 때

벡터 검색이 만능은 아니다. 의미가 비슷한 걸 폭넓게 데려오는 데는 강하지만, 정확히 그 단어가 들어간 문서를 콕 집는 데는 오히려 약하다. 예를 들어 특정 제품 코드나 오류 번호처럼 글자 그대로 일치해야 하는 검색은 벡터가 놓치기 쉽다. 그래서 요즘은 단어 그대로 찾는 전통적인 키워드 검색과 의미 기반 벡터 검색을 함께 돌리고 결과를 합치는 하이브리드 검색이 사실상 기본으로 자리 잡았다. Weaviate처럼 두 방식을 한 질문 안에서 섞어 주는 걸 강점으로 내세우는 제품도 있다.

규모에 대한 감각도 중요하다. 벡터가 수백만 개 수준까지는 pgvector로 충분한 경우가 많지만, 수천만 개를 넘어가며 응답을 빠르게 유지해야 하면 전용 엔진이 제 값을 한다. 처음부터 무거운 인프라를 세우기보다 검색이 핵심 경로가 되고 데이터가 커졌을 때 옮겨 가는 순서가 자연스럽다.