Vector DB 완전 정복: 개념부터 실무 활용까지
들어가면서
최근 LLM(Large Language Model) 기반의 AI 서비스들이 급부상하면서, 그 핵심 기술 중 하나인 Vector DB에 대한 관심이 뜨겁습니다. 저 역시 백엔드 개발자로서 기존의 키워드 기반 검색 방식으로는 해결하기 어려운 문제들을 마주하며, ‘의미’를 이해하는 검색의 필요성을 절감했습니다. 예를 들어, “환불”, “돈 돌려받기”, “금액 반환”처럼 표현은 다르지만 본질적으로 같은 의미를 가진 질문들을 시스템이 어떻게 이해하고 정확한 정보를 제공할 수 있을까 하는 고민이었습니다. 이러한 배경에서 Vector DB를 깊이 있게 학습하게 되었고, 그 과정에서 얻은 지식과 실무적 관점을 공유하고자 합니다.
Vector DB가 필요한 이유
우리가 익숙한 검색은 보통 단어에서 시작합니다. LIKE 검색이나 풀텍스트 검색은 특정 키워드가 문서에 포함되어 있는지, 혹은 얼마나 자주 등장하는지를 기반으로 결과를 찾아줍니다. 이는 정확한 키워드 매칭에는 강하지만, 의미의 유사성을 파악하는 데는 한계가 명확합니다.
예를 들어, 데이터베이스에 “반품 절차가 승인되면 영업일 기준 3일 이내에 결제 수단으로 금액이 반환됩니다.”라는 내용이 있을 때, 사용자가 “결제 취소하고 돈 돌려받는 방법 알려줘.”라고 질문하면 기존 검색 방식으로는 원하는 답변을 찾기 어렵습니다. 사람은 “환불”, “돈 돌려받기”, “금액 반환”이 비슷한 의미라는 것을 이해하지만, 시스템은 이를 문자열로만 인식하기 때문입니다.
| 검색 방식 | 기준 | 잘하는 일 | 어려운 일 |
|---|---|---|---|
LIKE 검색 | 문자열 포함 여부 | 간단한 부분 일치 | 오타, 동의어, 표현 차이 |
| 풀텍스트 검색 | 단어, 형태소, 역색인 | 문서 검색, 키워드 랭킹 | 단어가 다르면 의미를 놓칠 수 있음 |
| 벡터 검색 | 임베딩 벡터 간 거리 | 의미가 비슷한 문서 찾기 | 정확한 키워드 조건만 필요한 검색 |
| 하이브리드 검색 | 키워드 + 벡터 | 정확한 용어와 의미 검색을 함께 처리 | 구현과 튜닝이 복잡해짐 |
Vector DB는 텍스트, 이미지, 코드 같은 데이터를 숫자 벡터로 변환하여 저장하고, 이 벡터 간의 거리를 통해 의미적 유사성을 판단합니다. 이는 기존 키워드 검색이 놓칠 수 있는 ‘의미’를 찾아내는 데 결정적인 역할을 합니다. 특히 RAG 챗봇, 추천 시스템, 중복 탐지, 이미지 검색, 코드 검색 등 다양한 분야에서 Vector DB의 활용도가 높아지고 있습니다.
Vector DB란 무엇인가
Vector DB는 말 그대로 벡터를 저장하는 데이터베이스입니다. 하지만 단순히 벡터만 저장하는 것이 아니라, 일반적으로 아래와 같은 데이터들을 함께 저장하고 관리합니다.
- 원본 텍스트 또는 청크 내용: 검색 결과로 사용자에게 보여줄 원본 데이터의 일부 또는 전체.
- 해당 텍스트를 숫자로 바꾼 임베딩 벡터: 텍스트의 의미를 다차원 공간의 한 점으로 표현한 숫자 배열.
- 출처, 문서 ID, 페이지, 권한 같은 메타데이터: 검색 결과에 대한 추가 정보나 필터링 조건으로 활용될 수 있는 데이터.
- 빠른 유사도 검색을 위한 인덱스: 대규모 벡터 데이터에서 효율적으로 유사한 벡터를 찾기 위한 구조.
1
2
3
4
5
6
7
documents
---------------------------------------------------------------
id 101
content "연차는 최소 3일 전에 사내 포털에서 신청해야 합니다."
embedding [0.012, -0.031, 0.887, ...] (예: 1024차원)
metadata {"source": "company-policy", "section": "휴가 규정"}
---------------------------------------------------------------
Vector DB가 저장하는 것은 “의미의 좌표”
임베딩 모델은 “강아지 사료 추천”과 “반려견 먹이 고르는 법”처럼 표현은 다르지만 의미가 비슷한 문장들을 벡터 공간에서 가까운 위치에 배치하도록 학습됩니다. 반면 “법인카드 정산 규정”처럼 의미가 다른 문장은 멀리 떨어뜨려 놓습니다. 이때 Vector DB는 질문 벡터와 가장 가까운 문서 벡터를 찾아주는 역할을 합니다.
질문 벡터와 가장 가까운 문서 벡터를 찾는다.
Vector DB는 꼭 별도 제품이어야 할까
반드시 그렇지는 않습니다. Vector DB는 단일 제품으로 존재하기도 하지만, 기존 데이터베이스의 확장 기능으로 제공되기도 합니다. 실무에서는 프로젝트의 규모와 요구사항에 따라 다양한 선택지가 있습니다.
| 선택지 | 예시 | 특징 |
|---|---|---|
| 기존 RDB 확장 | PostgreSQL + pgvector | 기존 테이블, 트랜잭션, 조인과 함께 쓰기 좋음 |
| 전용 Vector DB | Qdrant, Milvus, Weaviate | 대규모 벡터 검색과 분산 처리에 특화 |
| 매니지드 서비스 | Pinecone 등 | 운영 부담이 적고 빠르게 시작 가능 |
| 검색엔진 확장 | Elasticsearch, OpenSearch | 키워드 검색과 벡터 검색을 같이 쓰기 좋음 |
| 기존 DB의 벡터 기능 | Redis, MongoDB Atlas 등 | 이미 쓰는 인프라에 기능을 추가하기 쉬움 |
데이터 적재 흐름
Vector DB에 데이터를 단순히 넣는다고 해서 검색이 잘 되는 것은 아닙니다. 검색 품질을 높이기 위해서는 데이터를 적재하는 과정, 즉 인제스천(Ingestion) 파이프라인이 매우 중요합니다.
1. 문서 준비
가장 먼저 원본 문서를 검색 가능한 텍스트 형태로 준비합니다. PDF, Word 문서, 위키, HTML 페이지, FAQ 데이터, 고객 상담 로그 등 다양한 형태의 원본에서 필요한 텍스트를 추출하고, 메뉴, 푸터, 광고 등 불필요한 내용을 제거하여 정제합니다.
2. 청크 분할
정제된 문서는 검색 가능한 작은 단위인 청크(Chunk)로 분할됩니다. 청크의 크기와 분할 전략은 검색 품질에 큰 영향을 미칩니다. 너무 크면 여러 의미가 섞여 정확도가 떨어지고, 너무 작으면 문맥이 부족해질 수 있습니다. 문맥을 유지하면서도 적절한 크기로 나누는 것이 중요합니다.
3. 임베딩 생성
분할된 각 청크는 임베딩 모델을 통해 다차원 벡터로 변환됩니다. 이 벡터는 청크의 의미를 숫자로 표현한 “의미의 좌표”가 됩니다. 이때, 저장할 때 사용한 임베딩 모델과 검색할 때 사용할 임베딩 모델은 반드시 동일해야 합니다. 서로 다른 모델은 다른 좌표계를 사용하므로, 일관성 없는 모델 사용은 검색 오류로 이어집니다.
4. Vector DB 저장
생성된 임베딩 벡터는 원본 청크 내용, 그리고 출처, 권한, 날짜 등의 메타데이터와 함께 Vector DB에 저장됩니다.
5. 인덱스 생성 또는 갱신
대규모 벡터 데이터에서 빠른 유사도 검색을 위해 인덱스를 생성하거나 갱신합니다. 이 인덱스는 뒤에서 설명할 ANN(Approximate Nearest Neighbor) 검색의 핵심 요소가 됩니다.
검색 흐름
사용자의 질문이 들어왔을 때 Vector DB는 어떤 과정을 거쳐 검색 결과를 반환할까요? RAG(Retrieval-Augmented Generation) 시스템의 관점에서 검색 흐름을 살펴보겠습니다.
sequenceDiagram
participant U as 사용자
participant A as 애플리케이션
participant E as 임베딩 모델
participant V as Vector DB
participant L as LLM
U->>A: "연차 신청은 언제까지 해야 해?"
A->>E: 질문을 임베딩해 주세요
E-->>A: 질문 벡터 반환
A->>V: 질문 벡터와 가까운 청크 top-K 검색
V-->>A: 관련 청크와 메타데이터 반환
A->>L: 질문 + 검색된 근거 전달
L-->>A: 근거 기반 답변 생성
A-->>U: 답변과 출처 반환
Vector DB 자체의 검색 단계만 보면 아래와 같습니다.
1
질문 -> 질문 임베딩 -> 유사도 검색 -> top-K 청크 반환
1. 질문을 임베딩한다
사용자의 질문 또한 문서 청크와 동일한 임베딩 모델을 사용하여 벡터화됩니다. 이 질문 벡터는 Vector DB에서 유사한 문서 벡터를 찾기 위한 기준점이 됩니다.
2. Vector DB에서 가까운 벡터를 찾는다
Vector DB는 질문 벡터와 가장 가까운(즉, 의미적으로 유사한) 문서 벡터들을 찾아냅니다. SQL로 표현하면 다음과 같은 형태가 될 수 있습니다.
1
2
3
4
5
6
7
8
9
SELECT
id,
content,
metadata,
embedding <=> :query_embedding AS distance
FROM document_chunks
WHERE metadata->>'source' = 'company-policy'
ORDER BY embedding <=> :query_embedding
LIMIT 3;
여기서 :query_embedding은 사용자의 질문을 임베딩한 벡터이며, embedding <=> :query_embedding은 벡터 간의 코사인 거리를 계산하는 연산자입니다.
3. 결과는 보통 top-K로 가져온다
Vector DB 검색은 일반적으로 가장 유사한 문서 하나만을 반환하지 않고, top-K개의 결과를 반환합니다. 이는 다음과 같은 이유 때문입니다.
- 하나의 질문에 답하기 위해 여러 문서 조각이 필요할 수 있습니다.
- 가장 가까운 1개가 항상 충분한 근거를 제공하지 않을 수 있습니다.
- LLM이 여러 근거를 종합하여 더 안정적이고 풍부한 답변을 생성할 수 있습니다.
하지만 top-K 값이 너무 크면 관련 없는 문서가 섞이거나, LLM 프롬프트가 길어져 비용과 지연 시간이 증가할 수 있으므로 적절한 K 값 설정이 중요합니다.
4. similarityThreshold로 너무 먼 결과를 거른다
top-K만으로는 질문과 관련성이 낮은 문서까지 억지로 반환될 수 있습니다. 예를 들어, 회사 규정 문서에 주차장 규정이 없는데 사용자가 “우리 회사 주차장 이용 규정 알려줘.”라고 물으면, Vector DB는 그래도 가장 가까운 몇 개의 문서를 찾으려 할 것입니다. 이때 “가장 가까움”이 “충분히 가까움”을 의미하지는 않습니다.
따라서 실무에서는 similarityThreshold와 같은 거리 또는 유사도 기준을 함께 사용하여, 일정 임계값보다 멀리 떨어진 결과는 제외함으로써 검색 품질을 높입니다.
5. 메타데이터 필터를 함께 쓴다
Vector DB 검색은 단순히 벡터 거리만으로 끝나지 않습니다. 실무에서는 특정 문서 묶음에서만 검색하거나, 최신 버전 문서만 검색, 특정 부서 문서만 검색, 로그인한 사용자가 볼 수 있는 문서만 검색하는 등 다양한 조건이 필요합니다. 이러한 조건들은 메타데이터 필터를 통해 적용되며, 효과적인 메타데이터 설계는 검색의 정확성과 유용성을 크게 향상시킵니다.
pgvector로 이해하는 벡터 검색
PostgreSQL의 확장 기능인 pgvector는 관계형 데이터베이스에서 벡터 검색을 수행할 수 있게 해줍니다. pgvector는 벡터 간 거리를 계산하는 다양한 연산자를 제공합니다.
| 연산자 | 의미 | 값의 해석 |
|---|---|---|
<=> | cosine distance (코사인 거리) | 작을수록 유사 |
<-> | L2 distance (유클리드 거리) | 작을수록 유사 |
<#> | negative inner product (음수 내적) | 작을수록 내적이 큼 |
예를 들어, 3차원 벡터를 저장하는 items 테이블이 있다고 가정해 봅시다.
1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE items (
id bigserial PRIMARY KEY,
name text NOT NULL,
embedding vector(3)
);
INSERT INTO items (name, embedding) VALUES
('강아지', '[1.0, 0.9, 0.1]'),
('고양이', '[0.9, 1.0, 0.2]'),
('자동차', '[0.1, 0.2, 1.0]'),
('오토바이', '[0.2, 0.1, 0.9]');
“강아지”와 가까운 항목을 코사인 거리로 찾으려면 다음과 같은 SQL 쿼리를 사용할 수 있습니다.
1
2
3
4
5
6
SELECT
name,
embedding <=> '[1.0, 0.9, 0.1]' AS cosine_distance
FROM items
ORDER BY embedding <=> '[1.0, 0.9, 0.1]'
LIMIT 3;
이 쿼리는 “강아지” 벡터와 가장 가까운 벡터들을 코사인 거리를 기준으로 정렬하여 반환합니다. 여기서 중요한 점은 “고양이”가 “강아지”와 문자열로 비슷해서가 아니라, 벡터 공간에서 의미적으로 가깝기 때문에 검색된다는 것입니다.
pgvector 인덱스 연산자 클래스
대규모 데이터에서 빠른 검색을 위해서는 인덱스가 필수적입니다. pgvector는 각 거리 기준에 맞는 인덱스 연산자 클래스를 제공합니다.
| 거리 기준 | 정렬 연산자 | 인덱스 연산자 클래스 |
|---|---|---|
| 코사인 거리 | <=> | vector_cosine_ops |
| L2 거리 | <-> | vector_l2_ops |
| 내적 | <#> | vector_ip_ops |
인덱스를 생성할 때 사용할 거리 기준에 맞는 연산자 클래스를 지정해야 합니다.
kNN과 ANN
Vector DB의 핵심 작업은 가장 가까운 이웃(Nearest Neighbor) 검색입니다. 즉, 질문 벡터와 가장 가까운 K개의 벡터를 찾는 kNN(k-Nearest Neighbors) 검색입니다.
정확한 kNN
정확한 kNN은 저장된 모든 벡터와 질문 벡터 간의 거리를 일일이 계산하여 가장 가까운 K개를 찾아냅니다. 데이터의 양이 적을 때는 문제가 없지만, 수백만 건 이상의 대규모 데이터에서는 모든 벡터를 스캔해야 하므로 검색 속도가 매우 느려집니다.
| 데이터 규모 | 정확한 kNN 체감 |
|---|---|
| 수백~수천 건 | 충분히 가능 |
| 수만~수십만 건 | 쿼리와 환경에 따라 부담 |
| 수백만 건 이상 | 인덱스 없이 매번 풀스캔은 부담이 큼 |
ANN (Approximate Nearest Neighbor)
ANN(Approximate Nearest Neighbor)은 정확한 kNN의 속도 문제를 해결하기 위해 등장했습니다. ANN은 가장 가까운 벡터를 ‘정확히’ 찾는 대신, ‘가까울 가능성이 높은’ 후보들을 빠르게 찾아냅니다. 즉, 정확도의 일부를 양보하고 검색 속도를 얻는 방식입니다.
정확도 일부를 양보하고 검색 속도를 얻는다.
ANN의 성능을 평가할 때는 재현율(Recall)이 중요합니다. 재현율은 정확한 top-K 결과 중 ANN이 몇 개를 찾아냈는지를 나타내는 지표입니다. 예를 들어, 정확한 top-10 결과 중 ANN이 9개를 찾아냈다면 재현율은 90%입니다.
Callout - ANN의 본질
ANN은 “틀려도 되는 검색”이 아니라, “대부분 맞으면서 훨씬 빠른 검색”을 목표로 합니다.
kNN과 ANN 비교
| 구분 | kNN | ANN |
|---|---|---|
| 검색 방식 | 모든 벡터와 거리 계산 | 인덱스를 이용해 후보를 빠르게 탐색 |
| 정확도 | 가장 정확 | 근사값, 일부 누락 가능 |
| 속도 | 데이터가 커지면 느림 | 대규모에서 빠름 |
| 인덱스 | 없어도 가능 | HNSW, IVFFlat 같은 인덱스 필요 |
| 사용 상황 | 작은 데이터, 품질 검증, 오프라인 평가 | 실시간 검색, 대규모 서비스 |
실무에서는 대규모 서비스에서 실시간 검색을 위해 HNSW, IVFFlat과 같은 ANN 인덱스를 주로 사용하며, 정확도와 속도 사이의 트레이드오프를 고려하여 적절한 인덱스 전략을 선택해야 합니다.
RAG에서 Vector DB의 역할
RAG(Retrieval-Augmented Generation)는 “검색으로 보강한 생성”을 의미하며, LLM의 한계를 보완하기 위한 중요한 기술입니다. LLM은 뛰어난 언어 생성 능력을 가지고 있지만, 최신 정보나 특정 도메인의 지식에 대한 한계, 그리고 때로는 사실과 다른 내용을 지어내는 환각(Hallucination) 문제가 있습니다.
RAG는 LLM이 답변을 생성하기 전에 관련 문서를 검색하여 근거(Context)로 제공함으로써 이러한 문제를 해결합니다. Vector DB는 이 과정에서 LLM에게 제공할 관련 문서를 효율적으로 찾아내는 핵심적인 역할을 합니다.
RAG에서 역할 분담
| 구성 요소 | 역할 |
|---|---|
| 문서 파이프라인 | 문서를 읽고, 청크로 나누고, 임베딩해서 저장 |
| 임베딩 모델 | 문서와 질문을 같은 벡터 공간으로 변환 |
| Vector DB | 질문과 가까운 문서 청크 검색 |
| 애플리케이션 | 검색 조건, 권한, top-K, 프롬프트 구성 관리 |
| LLM | 검색된 근거를 읽고 자연어 답변 생성 |
Vector DB는 LLM이 직접 답변을 생성하는 것이 아니라, LLM에게 답변의 근거가 될 문서를 제공하는 역할을 합니다. LLM은 이 근거를 바탕으로 자연어 답변을 생성하게 됩니다.
프롬프트에는 보통 검색 결과가 들어간다
RAG 시스템에서 LLM에게 전달되는 프롬프트는 일반적으로 사용자의 질문과 함께 Vector DB에서 검색된 관련 문서 청크들을 포함합니다.
1
2
3
4
5
6
7
8
9
10
11
아래 문서 내용을 근거로 사용자의 질문에 답하세요.
문서에 없는 내용은 모른다고 답하세요.
[문서 1]
연차 신청은 사내 포털에서 최소 3일 전에 신청해야 합니다.
[문서 2]
연차는 입사일 기준으로 매년 15일이 부여됩니다.
[질문]
연차 신청은 언제까지 해야 해?
LLM은 이 프롬프트를 통해 “연차는 사내 포털에서 최소 3일 전에 신청해야 합니다.”와 같은 근거 기반의 답변을 생성합니다.
Vector DB가 RAG 품질에 미치는 영향
RAG 시스템의 답변 품질은 Vector DB의 검색 결과 품질에 직접적인 영향을 받습니다. 관련 청크가 정확히 검색되지 않거나, 엉뚱한 청크가 섞이거나, 필요한 청크가 누락되면 LLM은 부정확하거나 불완전한 답변을 생성할 수 있습니다. 따라서 Vector DB의 효율적인 구성과 검색 품질 최적화는 RAG 시스템 성공의 핵심 요소입니다.
실무 선택 기준
Vector DB를 선택할 때는 “가장 유명한 제품”보다는 “우리 문제에 맞는가”를 기준으로 삼아야 합니다. 각 Vector DB 솔루션은 고유한 장단점과 적합한 사용 사례를 가지고 있습니다.
pgvector가 잘 맞는 경우
- 이미 PostgreSQL을 사용하고 있고, 벡터 검색 기능이 필요한 경우
- 기존 관계형 데이터와 벡터 데이터를 함께 관리하고 싶을 때
- 복잡한 조인이나 트랜잭션이 필요한 경우
- 데이터 규모가 아주 크지 않고, QPS(Query Per Second)가 매우 높지 않은 경우
전용 Vector DB (Qdrant, Milvus, Weaviate 등)가 잘 맞는 경우
- 대규모 벡터 데이터셋을 다루고, 높은 QPS가 필요한 경우
- 분산 처리 및 확장성이 중요한 경우
- 벡터 검색 기능에 특화된 고급 기능(예: 필터링, 스케일링)이 필요한 경우
검색엔진 확장 (Elasticsearch, OpenSearch)과 하이브리드 검색
- 키워드 검색과 벡터 검색을 모두 중요하게 다루는 경우
- 기존에 Elasticsearch나 OpenSearch를 사용하고 있어 통합 관리가 용이한 경우
- 정확한 키워드 매칭과 의미 기반 검색을 결합하여 더 정교한 검색 결과를 얻고자 할 때
실무에서는 단순히 Vector DB 제품만을 고려하는 것이 아니라, 권한 관리, 최신성 유지, 메타데이터 필터링, 그리고 임베딩 모델 변경 시 재임베딩 전략까지 함께 고려해야 합니다. 이전에 AOP를 정리하면서 공통 로직의 중요성을 느꼈듯이, Vector DB 역시 전체 시스템 아키텍처 내에서 어떻게 유기적으로 동작할지 설계하는 것이 중요합니다.
흔한 오해와 오류
Vector DB를 처음 도입하거나 사용할 때 흔히 발생할 수 있는 오해와 실무 오류들을 정리했습니다.
- Vector DB에 넣는다고 LLM이 학습하는 것은 아님: Vector DB는 LLM에게 근거를 제공할 뿐, LLM 자체의 지식을 업데이트하지 않습니다.
- 검색 결과 1등이 항상 정답은 아님: 가장 가까운 벡터가 항상 사용자 질문에 대한 최적의 답변을 포함하는 것은 아닙니다.
similarityThreshold와 같은 추가적인 필터링이 필요할 수 있습니다. - 청크를 대충 나누면 검색 품질이 떨어짐: 청크 분할 전략은 검색 품질에 결정적인 영향을 미칩니다. 문맥을 고려하지 않은 무분별한 분할은 검색 정확도를 저하시킵니다.
- Vector DB만으로 키워드 검색을 완전히 대체할 수 없음: 정확한 제품명, 코드, 고유명사 등은 키워드 검색이 더 효과적일 수 있습니다. 하이브리드 검색을 고려해야 합니다.
- 임베딩 모델을 바꾸면 기존 문서도 다시 임베딩해야 함: 임베딩 모델은 벡터 공간의 좌표계를 정의합니다. 모델이 바뀌면 기존 벡터들의 의미적 위치가 달라지므로, 반드시 재임베딩을 수행해야 합니다.
- dimension mismatch, 모델 불일치, 권한 필터 누락: 임베딩 벡터의 차원 불일치, 저장/검색 시 다른 임베딩 모델 사용, 메타데이터 필터링 누락 등은 실무에서 자주 발생하는 오류입니다.
공부하면서 느낀 점
Vector DB를 학습하면서 가장 크게 느낀 점은 단순히 새로운 데이터베이스 기술을 넘어, ‘의미’를 다루는 새로운 패러다임의 시작이라는 것입니다. 기존의 관계형 데이터베이스나 검색 엔진이 ‘정확한 매칭’에 집중했다면, Vector DB는 ‘유사한 의미’를 찾아내는 데 특화되어 있습니다. 이는 백엔드 개발자로서 데이터를 다루는 방식과 사용자에게 정보를 제공하는 방식에 대한 깊은 고민을 안겨주었습니다.
특히 RAG 아키텍처에서 Vector DB의 역할은 LLM의 한계를 보완하고, 더 신뢰할 수 있는 AI 서비스를 구축하는 데 필수적임을 깨달았습니다. 단순히 기술을 도입하는 것을 넘어, 데이터 적재 파이프라인 설계, 청크 전략, 메타데이터 관리, 그리고 ANN 인덱스 튜닝 등 실무적인 고려사항이 많다는 점도 흥미로웠습니다. 앞으로 AI 기반 서비스 개발에 있어 Vector DB는 핵심적인 인프라 요소가 될 것이며, 백엔드 개발자에게는 이를 효과적으로 활용하고 최적화하는 역량이 더욱 중요해질 것이라고 생각합니다.
한 줄 정리
Vector DB는 텍스트, 이미지, 코드 같은 데이터를 숫자 벡터로 바꿔 저장하고, 질문과 의미가 가까운 데이터를 빠르게 찾기 위한 데이터베이스이며, 키워드 검색이 “같은 단어가 들어 있는가?”를 묻는다면, Vector DB는 “의미가 가까운가?”를 묻습니다.
References
- Spring AI로 AI 앱 개발 시작하기: ChatClient와 Structured Output
- Spring AI 실전: Tool Calling 설계와 멀티 모델 활용 전략
- pgvector GitHub Repository
- What is a Vector Database? - Pinecone
- Retrieval-Augmented Generation (RAG) - LlamaIndex
오늘의 핵심 정리
Vector DB는 의미 기반 검색을 가능하게 하는 강력한 도구입니다. 기존 키워드 검색의 한계를 넘어, 데이터의 ‘의미’를 이해하고 유사한 정보를 찾아내는 데 특화되어 있습니다. 특히 RAG와 같은 LLM 기반 시스템에서 Vector DB는 LLM의 환각을 줄이고 신뢰성 높은 답변을 제공하는 핵심적인 역할을 수행합니다. 효율적인 Vector DB 활용을 위해서는 데이터 적재 파이프라인, 청크 전략, 메타데이터 설계, 그리고 ANN 인덱스 선택 등 다양한 실무적 고려가 필요합니다. 백엔드 개발자로서 이러한 개념들을 이해하고 적절히 활용하는 것은 AI 시대의 필수 역량이 될 것입니다.