6강. 벡터 DB를 도입하면 생기는 새로운 문제들

🤔 Question

👉 “벡터 DB만 도입하면 RAG 품질이 확 올라가는 거 아닌가요?”

이 질문은 실무에서 가장 많이 터지는 착각 중 하나입니다.

 

🎯 벡터 DB는 문제 해결이 아니라 문제 생성기다

👉 벡터 DB를 도입하면 분명히 이런 효과는 있습니다.

• 의미 기반 검색 가능
• 추상적인 질문 대응
• RAG 정확도 향상

하지만 동시에 새로운 종류의 문제가 무더기로 생깁니다.

실무에서 벡터 DB는 “도입이 끝이 아니라 시작”입니다.

 

🎯 문제 1 — 임베딩은 언제 다시 만들어야 하는가

👉 가장 먼저 터지는 질문입니다.

“문서 내용이 바뀌면 임베딩도 다시 해야 하나요?”

정답은 “거의 항상 다시 해야 한다” 입니다.

• 문서 내용 변경
• Chunk 전략 변경
• 임베딩 모델 변경

이 중 하나라도 바뀌면 기존 벡터는 더 이상 신뢰할 수 없습니다.

그래서 실무에서는 임베딩 재생성 전략이 필수입니다.

 

🎯 문제 2 — 임베딩 버전 관리 지옥

👉 벡터 DB에는 보통 이런 정보가 섞여 있습니다.

• 옛날 문서 임베딩
• 최신 문서 임베딩
• 서로 다른 모델로 생성된 벡터

이 상태에서 검색하면?

결과는 나오지만, 왜 그런 결과가 나왔는지는 아무도 모릅니다.

그래서 실무에서는 반드시:

• embedding_version
• chunk_strategy_version
• source_timestamp

같은 메타데이터를 검색 필터로 함께 관리합니다.

벡터 DB는 스키마 없는 저장소가 아닙니다.

 

🎯 문제 3 — 비용이 눈에 보이지 않는다

👉 벡터 DB 비용은 천천히, 그러나 확실하게 올라갑니다.

• 임베딩 생성 비용
• 벡터 저장 비용
• 검색 쿼리 비용

특히 문제는 “임베딩 재생성”입니다.

문서 수가 많아질수록 재임베딩은 곧 폭탄이 됩니다.

그래서 실무에서는:

• 전체 재생성 금지
• 변경 감지 기반 재임베딩
• Batch 단위 처리

같은 전략을 반드시 씁니다.

 

🎯 문제 4 — 검색 결과를 설명할 수 없다

👉 벡터 검색의 가장 큰 단점은 이것입니다.

“왜 이 문서가 나왔는지 설명하기 어렵다”

실무에서는 이게 치명적입니다.

• 디버깅이 어렵고
• 품질 개선 포인트를 찾기 힘들고
• 신뢰성을 설명할 수 없습니다

그래서 키워드 검색 + 벡터 검색을 같이 씁니다.

키워드 검색은 “왜 이게 나왔는지”를 설명해줍니다.

설명 가능한 시스템만이 운영 가능한 시스템입니다.

 

🎯 문제 5 — 데이터 파이프라인이 없으면 바로 무너진다

👉 벡터 DB는 단독으로 존재할 수 없습니다.

• 문서 수집
• 정제
• 분할
• 임베딩
• 저장

이 모든 과정이 파이프라인으로 자동화되어야 합니다.

그렇지 않으면:

• 누락된 문서
• 오래된 임베딩
• 품질 저하

가 필연적으로 발생합니다.

벡터 DB 도입 = 데이터 파이프라인 도입입니다.

 

☔ 정리

👉 벡터 DB는 마법의 해결책이 아닙니다.

• 임베딩 재생성
• 버전 관리
• 비용 통제
• 설명 가능성
• 데이터 파이프라인

이걸 함께 설계하지 않으면 RAG는 반드시 망합니다.

그래서 실무 AI 아키텍처에서 벡터 DB는 ‘중앙’이 아니라 ‘하위 구성요소’입니다.

 

 

다음 글에서는 임베딩 파이프라인을 설계하지 않으면 왜 서비스가 망하는지를 다룹니다.

 

If I was of any help to you, please buy me coffee 😿😢😥

If you have any questions, please leave them in the comments

Buy me a coffee

▶ Youtube Sub

🧭 References

[1] reference : https://doctorson0309.tistory.com/

[2] Ads : https://apps.apple.com/us/app/beluga-classic-film-filters/id6744041061