RAG 구현 전 Vector DB 선택 (PGVector VS Qdrant 중 무엇이 좋을까?)

 

 

https://kimfishes.tistory.com/3

SpringAI 사용해서 LLM (Ollama) 연결 + Resilience4j 도입 (Spring Boot)

 

 

 

 

기존 Ollama로 LLM을 사용하던 상황에서도 기본적인 대화는 가능하다.
하지만 예를 들어:

• “고객센터 몇 시에 종료되나요?”
• “환불은 언제까지 가능하죠?”
• “구독 해지는 바로 되나요?”

이 질문들은 정확한 정책/운영 정보를 요구한다.

LLM은:

• 일반적인 지식은 잘 답하지만
• 우리 회사의 최신 정책은 모른다
• 잘못된 정보를 그럴듯하게 만들어낼 수 있다 (hallucination)

즉, 단순히 “학습시킨다”는 개념으로 해결할 수 없다.

그래서 등장하는 개념이 바로 RAG다.

 

 

 

 

RAG란 무엇인가

RAG(Retrieval-Augmented Generation)는

“LLM이 답을 만들기 전에, 먼저 관련 정보를 검색해서 참고하게 만드는 구조”

 

1. 사용자가 질문한다.
2. 질문을 벡터로 변환한다.
3. 의미가 비슷한 문서를 검색한다.
4. 검색된 문서를 LLM 프롬프트에 넣는다.
5. LLM이 해당 문서를 기반으로 답변을 생성한다.

즉,

• LLM = 답변 생성기
• Vector DB = 의미 기반 검색 엔진
• DB/파일 = 정답 원문 저장소

이 세 가지가 조합되는 구조다.

 

왜 Vector DB가 필요한가

기존 LIKE 검색으로는 부족하다.

FAQ에 이런 문장이 있다고 해보자.

“고객센터 게시물에 계좌번호와 성함을 남기시면 2~3일 내 환불 처리됩니다.”

사용자 질문:

• “환불은 어떻게 하나요?”
• “돈 돌려받으려면 어디에 써야 돼요?”
• “결제 취소하면 언제 입금돼요?”

키워드 검색은 표현이 조금만 달라져도 놓친다.

반면 벡터 검색은:

• “환불”
• “돈 돌려받다”
• “결제 취소”

를 의미적으로 가깝게 인식한다.

문장을 숫자 벡터로 변환하고, 코사인 유사도 기반으로 가장 가까운 문서를 찾는다.

Vector DB는 이 벡터 저장/검색을 빠르게 처리해 주는 DB다.

 

 

 

 

이때 답변 데이터는 어디에 저장해야 하는가?

정답이 절대 틀리면 안 되는 정책은 반드시 정형 DB에 저장해야 한다.

예:

• 환불 가능 기간
• 운영 시간
• 약관
• 적용 시작/종료일
• 회원 등급별 정책

 

DB = 정책 원문 + 메타데이터 (정답 SSOT)
Vector DB = 검색 인덱스 (임베딩) 사용

 

 

 

 

흐름

1. 정책을 DB에 저장
2. 정책 텍스트를 임베딩 생성
3. 벡터를 Vector DB에 저장
4. 질문이 오면 Vector DB에서 후보 검색
5. 최종 출력은 DB의 최신 활성 정책 사용

즉, Vector DB는 검색용 인덱스일 뿐, 정답 저장소가 아니다.

 

 

 

 

pgvector vs Qdrant

Vector DB를 위해 이 둘을 선택하는 과정에서 고민이 발생했다.

• Postgres + pgvector
• Qdrant (전용 Vector DB)

 

 

 

벤치마크 

https://www.tigerdata.com/blog/pgvector-vs-qdrant

 

이 블로그의 벤치마크를 보면 결론은 의외로 단순하다.

사용 패턴에 따라 달라지지만 둘 사이에 성능 차이는 크지 않다.

• Qdrant는 단일 쿼리 latency 측면에서 강점
• pgvector(+pgvectorscale)는 throughput 측면에서 강점
• 대규모(수천만 벡터) 환경에서도 둘 다 충분히 고성능

 

“Qdrant가 압도적으로 빠르다”도 아니고
“pgvector가 압도적으로 낫다”도 아니다.

 

---

만약 나의 상황이 MySQL만 사용 중이라면?

• 현재 메인 DB는 MySQL
• pgvector를 쓰려면 Postgres를 새로 띄워야 한다
• Qdrant를 써도 서버를 새로 띄워야 한다

결론:

어차피 서버 하나는 추가된다.

그렇다면 선택 기준은 “성능”이 아니라 역할 분리와 단순성이 된다.

 

 

 

 

Qdrant를 선택하는 경우 장점은?

1) 벡터 검색에만 집중된 구조

• 벡터 저장
• 유사도 검색
• ANN 인덱싱

이러한 목적에 최적화된 DB로 불필요한 SQL 레이어가 없다.

 

 

2) MySQL과 역할이 명확히 분리됨

• MySQL = 정책 원문 + 비즈니스 데이터
• Qdrant = 검색 인덱스

도메인 분리가 명확하다.

 

 

 

3) RAG에 바로 맞는 API 구조

REST 기반으로 바로 연동 가능하고, Collection 개념도 직관적이다.

 

 

 

4) 운영 부담이 크게 다르지 않음

pgvector를 쓰려면 Postgres를 도입해야 한다.

• 백업
• 모니터링
• 권한 관리
• 운영 전략

어차피 새로운 DB를 관리해야 한다면, 벡터 전용 DB를 두는 것이 구조적으로 더 명확하다라고도 볼 수 있음

Spring Boot
├─ MySQL (정책/정답 저장)
├─ Qdrant (벡터 검색 인덱스)
└─ Ollama (LLM)

 

흐름:

1. 정책은 MySQL에 저장
2. 임베딩 생성 후 Qdrant에 저장
3. 질문 들어오면 Qdrant로 후보 검색
4. MySQL에서 최신 활성 정책 조회
5. Ollama가 답변 생성