벡터 데이터베이스 — 좌표로 검색하는 창고
Article
18강에서 문장을 숫자 좌표로 바꾸는 법을 봤다. 그런데 회사 문서가 수백, 수천, 어쩌면 수백만 개라면? 그 좌표를 전부 만들어뒀다가, 질문이 올 때마다 그중 가장 가까운 몇 개를 순식간에 찾아내야 한다. 이 일을 전담하는 저장소가 **벡터 데이터베이스(vector database)**다.
일반 데이터베이스로는 안 되나
회사에 이미 데이터베이스가 있는데, 왜 새로운 게 필요할까. 일반 데이터베이스가 잘하는 검색과, 벡터DB가 잘하는 검색이 다르기 때문이다.
일반 데이터베이스
정확히 일치하거나, 범위 안인지 본다
- "이름이 정확히 '홍길동'인 행"을 빠르게 찾는다
- "가격이 만 원에서 이만 원 사이"도 빠르다
- "이 문장과 뜻이 비슷한 행"은 애초에 질문 형태가 아니다
벡터 데이터베이스
좌표끼리 거리가 가까운지 본다
- 좌표(임베딩)를 저장해두고, 새 좌표가 오면 가장 가까운 것들을 찾는다
- "이 질문과 뜻이 비슷한 문서 5개"가 기본 질의 형태다
- 일치가 아니라 거리로 순위를 매긴다
왜 그냥 하나씩 다 재보면 안 되나
좌표 사이의 거리를 재는 계산 자체는 어렵지 않다. 문제는 양이다.
전부 다 비교하는 대신, 미리 좌표들을 몇 개의 구역으로 나눠 정리해두고, 질문이 오면 관련 구역만 빠르게 훑는 식이다. 도서관에서 책을 찾을 때 서가 전체를 뒤지지 않고 분류 번호부터 찾아가는 것과 비슷하다.
- 문서마다 임베딩을 만든다18강에서 본 그 변환 — 문서마다 좌표 하나
- 좌표를 벡터DB 에 저장한다저장할 때 미리 찾기 쉬운 구조로 정리해둔다
- 질문이 오면 질문도 좌표로 바꾼다질문 문장도 같은 임베딩 모델을 통과시킨다
- 가장 가까운 좌표 몇 개를 찾는다그 좌표에 연결된 원본 문서를 함께 돌려준다
저장하는 건 좌표만이 아니다
벡터DB가 저장하는 건 숫자 좌표뿐이 아니다. 그 좌표가 어느 원본 문서를 가리키는지도 함께 저장한다. 검색 결과로 좌표가 아니라 실제 문서 내용을 받아야 쓸모가 있기 때문이다.
| 항목 | 예시 | 역할 |
|---|---|---|
| 좌표(임베딩) | [0.12, -0.87, …] | 거리를 재는 데 쓰인다 |
| 원본 텍스트 | "환불은 구매 후 7일 이내…" | 찾은 뒤 실제로 보여줄 내용 |
| 출처 정보 | "환불정책.pdf, 3쪽" | 이 답이 어디서 나왔는지 근거로 남긴다 |
벡터DB로 쓰이는 도구는 여러 종류가 있고, 회사마다 규모와 목적에 따라 고른다. 특정 제품 하나가 표준은 아니다 — 이 편에서는 어떤 문제를 푸는 창고인지만 잡으면 된다.
정리하면
벡터 데이터베이스는 임베딩 좌표를 저장해두고, 질문이 올 때마다 가장 가까운 것들을 빠르게 찾아주는 창고다. 전부 다 비교하지 않고도 거의 정확하게 찾아내는 색인 방식을 쓴다.
- 01
일반 DB 는 일치를, 벡터DB 는 거리를 본다
"뜻이 비슷한 것 찾기"는 일반 데이터베이스의 질의 형태가 아니다.
- 02
문서가 많아지면 전수 비교는 느려진다
벡터DB 는 근사 최근접 탐색으로 거의 정확하되 훨씬 빠르게 찾는다.
- 03
좌표와 함께 원본·출처도 저장한다
검색 결과로 실제 문서 내용과 근거를 함께 돌려주기 위해서다.
- 04
이제 이 결과를 모델에게 붙여줄 차례다
찾아낸 문서를 어떻게 답으로 이어붙이는지, 다음 강의에서 RAG 전체 흐름을 완성한다.
다음 강의에서는 17강의 문제 제기, 18강의 임베딩, 19강의 벡터DB를 한 줄로 잇는다. 그리고 한 걸음 더 — 검색만이 아니라 도구를 직접 쥐고 행동하는 에이전트까지 본다.