RAG 서비스에 벡터 데이터베이스가 꼭 필요할까?

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

“사내 문서를 검색하는 AI를 만들려는데 벡터 데이터베이스부터 도입해야 하나요?” 생성형 AI 기반 서비스를 준비하는 스타트업이라면 한 번쯤 부딪히는 질문입니다. 검색 증강 생성, 즉 RAG가 주목받으면서 벡터 데이터베이스가 필수 인프라처럼 소개되지만, 데이터 규모와 검색 방식에 따라서는 기존 데이터베이스만으로도 충분합니다.

이번 글에서는 검색 시스템을 설계해 온 데이터 엔지니어 이현석 씨에게 RAG 서비스와 벡터 데이터베이스의 현실적인 도입 기준을 물었습니다. 기술 이름보다 사용자의 질문, 문서 구조, 운영 인력을 먼저 살펴야 한다는 것이 인터뷰의 핵심입니다.

Q. 벡터 데이터베이스는 일반 검색과 무엇이 다른가요?

A. 단어가 아니라 의미의 거리를 계산합니다

Q. 먼저 벡터 검색을 쉽게 설명해 주시겠어요?
문장이나 이미지의 특징을 여러 개의 숫자로 변환한 값을 벡터라고 합니다. 임베딩 모델은 “배송이 늦어요”와 “주문한 물건이 아직 도착하지 않았어요”처럼 표현은 달라도 의미가 가까운 문장을 비슷한 위치에 배치합니다. 벡터 데이터베이스는 이 숫자들 사이의 거리를 빠르게 계산해 질문과 의미가 가까운 자료를 찾아냅니다.

Q. 그렇다면 키워드 검색은 이제 필요 없나요?
아닙니다. 제품 코드, 오류 번호, 계약서 조항처럼 정확한 문자열이 중요한 데이터는 키워드 검색이 더 강합니다. 반대로 상담 기록이나 업무 매뉴얼처럼 같은 뜻이 여러 표현으로 등장하면 벡터 검색이 유리합니다. 실제 RAG 서비스에서는 두 방식을 결합한 하이브리드 검색이 안정적인 경우가 많습니다.

데이터를 숫자로 표현하고 처리하는 배경은 디지털의 기본 개념과도 연결됩니다. 다만 문서를 벡터로 바꿨다고 해서 답변 품질이 자동으로 좋아지는 것은 아닙니다. 어떤 단위로 문서를 나누고, 어떤 메타데이터를 붙이며, 검색 결과를 어떤 순서로 재평가하는지가 더 큰 영향을 미칩니다.

• 키워드 검색: 모델명, 사번, 주문번호와 같은 정확한 값에 적합합니다.
• 벡터 검색: 자연어 질문, 유사 문서, 표현이 다양한 고객 문의에 적합합니다.
• 하이브리드 검색: 정확한 용어와 문맥상의 의미를 함께 찾아야 할 때 효과적입니다.
• 재순위화: 처음 찾은 후보 문서를 별도 모델로 다시 평가해 관련성이 높은 순서로 배열합니다.

“벡터 데이터베이스를 고르기 전에 실제 사용자가 입력할 질문 50개를 먼저 모으세요. 검색 기술보다 평가 질문을 확보하는 일이 앞입니다.”

Q. 어느 규모부터 전용 벡터 데이터베이스가 필요한가요?

A. 문서 개수보다 검색량과 운영 조건을 보세요

Q. 문서가 몇 건 이상이면 전용 제품을 써야 한다는 기준이 있습니까?
일률적인 숫자는 없습니다. 같은 10만 건이라도 하루에 열 번 검색하는 내부 도구와 초당 수십 건의 요청이 들어오는 고객용 서비스는 요구 조건이 완전히 다릅니다. 임베딩 차원, 문서 조각 수, 필터 조건, 동시 사용자, 응답 지연 목표를 함께 봐야 합니다. 원본 문서 한 개가 여러 조각으로 나뉘기 때문에 파일 수만 보고 규모를 판단해서도 안 됩니다.

Q. 초기 스타트업은 무엇으로 시작하는 편이 좋을까요?
이미 관계형 데이터베이스를 운영한다면 벡터 확장 기능을 활용해 검증하는 방법이 실용적입니다. 데이터와 권한 정보를 한곳에서 관리할 수 있고 백업, 접근 제어, 모니터링 체계를 재사용할 수 있기 때문입니다. 검색량이 늘거나 복잡한 필터와 낮은 지연 시간이 사업의 핵심 조건이 될 때 전용 관리형 서비스나 독립 클러스터를 검토해도 늦지 않습니다.

IT 인프라는 단일 제품이 아니라 데이터 수집, 저장, 처리, 서비스 운영이 이어지는 체계입니다. IT의 의미와 활용 범위를 함께 살펴보면 벡터 데이터베이스 역시 전체 정보 시스템 안에서 선택해야 하는 구성 요소라는 점을 이해하기 쉽습니다.

1. 실험 단계: 수백~수만 개 문서 조각으로 검색 정확도를 확인합니다. 로컬 인덱스나 기존 DB 확장 기능도 충분합니다.
2. 내부 배포 단계: 사용자별 권한 필터, 문서 갱신 주기, 장애 시 복구 방식을 추가합니다.
3. 고객 서비스 단계: 동시 요청, 지연 시간 상한, 다중 리전, 비용 예측 가능성을 측정합니다.
4. 대규모 운영 단계: 인덱스 분할, 복제, 검색 품질 저하 감지와 무중단 재색인을 설계합니다.

A. 도입 신호와 보류 신호를 구분해야 합니다

필터가 복잡해질수록 벡터 검색의 난도는 높아집니다. 예를 들어 고객사, 부서, 문서 등급, 작성 시점까지 동시에 제한해야 한다면 검색 속도뿐 아니라 권한 누락 위험도 점검해야 합니다. 반면 자료가 자주 바뀌지 않고 사용자가 적으며 기존 DB에서 목표 응답 시간을 충족한다면, 전용 시스템을 추가하는 것이 오히려 운영 부담을 키울 수 있습니다.

• 도입을 검토할 신호: 검색 지연이 반복적으로 목표치를 넘고 인덱스 확장이 기존 DB의 주 업무를 방해합니다.
• 보류해도 되는 신호: 트래픽이 작고 검색 품질 문제가 데이터 정리나 문서 분할에서 발생합니다.
• 주의할 신호: 특정 공급자의 기능에 맞춰 데이터 구조와 애플리케이션 전체가 강하게 결합됩니다.

Q. 제품을 비교할 때 가격표 외에 무엇을 봐야 하나요?

A. 총비용은 임베딩부터 재색인까지 이어집니다

Q. 무료 등급이 있는 제품으로 시작하면 비용 문제는 해결되지 않나요?
초기 검증에는 도움이 되지만 저장 용량만 비교하면 실제 비용을 놓치기 쉽습니다. RAG에는 문서 파싱, 임베딩 생성, 인덱스 저장, 검색 요청, 재순위화, 생성형 AI 호출 비용이 연쇄적으로 발생합니다. 모델을 바꾸거나 문서 분할 정책을 수정하면 전체 임베딩을 다시 만들 수 있어 재색인 비용과 소요 시간도 예산에 포함해야 합니다.

Q. 관리형 서비스와 직접 구축 중 어느 쪽이 저렴합니까?
소규모 팀은 관리형 서비스가 운영 시간을 줄여 총비용을 낮추는 경우가 많습니다. 직접 구축하면 소프트웨어 비용은 줄일 수 있지만 버전 업그레이드, 백업, 장애 대응, 용량 계획을 담당할 사람이 필요합니다. 반대로 요청량이 크고 시스템 운영 역량이 충분하다면 직접 구축이 단위 검색 비용을 낮출 여지가 있습니다.

비교 실험에서는 공급자마다 동일한 문서, 임베딩 모델, 검색 후보 수를 적용해야 합니다. 조건이 다르면 속도와 정확도 수치를 공정하게 해석할 수 없습니다. 또한 평균 응답 시간만 보지 말고 사용자가 느린 요청에서 실제로 경험하는 상위 지연 구간도 확인해야 합니다.

A. 검색 정확도는 자체 질문 세트로 측정해야 합니다

데모에서 답변이 자연스럽다는 이유만으로 도입을 결정해서는 안 됩니다. 질문마다 반드시 찾아야 할 근거 문서를 미리 표시하고, 상위 검색 결과 안에 해당 문서가 포함되는 비율을 측정해야 합니다. 생성된 답변에는 인용 출처가 실제 내용을 뒷받침하는지도 사람이 표본 검사해야 합니다.

• 일반 질문뿐 아니라 오탈자, 줄임말, 사내 약어가 포함된 질문을 넣습니다.
• 답이 문서에 없는 질문을 포함해 모델이 모른다고 말하는지 확인합니다.
• 퇴사자나 다른 고객사의 비공개 문서가 검색되지 않는지 권한 테스트를 수행합니다.
• 같은 질문을 반복해 검색 결과와 답변의 변동 폭을 기록합니다.
• 문서가 갱신된 뒤 오래된 내용이 언제까지 노출되는지 측정합니다.

“RAG의 실패는 대개 문장을 예쁘게 만들지 못해서가 아니라, 틀린 근거를 자신 있게 가져오는 데서 시작합니다. 검색 평가와 권한 검사는 출시 전 기능입니다.”

고객지원 AI를 만든 8명 팀은 어떤 순서로 결정했을까요?

상담 문서 3만 조각에서 시작한 실제형 시나리오

직원 8명의 SaaS 스타트업이 고객지원 담당자의 반복 업무를 줄이기 위해 RAG 서비스를 만든다고 가정해 보겠습니다. 팀이 보유한 자료는 제품 매뉴얼, 장애 대응 기록, 상담 답변을 합쳐 약 3만 개의 문서 조각이었습니다. 처음에는 전용 벡터 데이터베이스를 계약하려 했지만, 담당 엔지니어는 먼저 실제 상담 질문 120개와 각 질문의 정답 근거를 모았습니다.

첫 실험은 기존 관계형 데이터베이스의 벡터 확장 기능으로 진행했습니다. 제품명과 오류 코드는 키워드 검색으로, 증상 설명은 벡터 검색으로 찾은 뒤 두 점수를 결합했습니다. 그 결과 “로그인이 계속 풀려요” 같은 자연어 질문은 잘 찾았지만, 비슷한 증상을 다룬 오래된 매뉴얼이 최신 문서보다 앞에 나타나는 문제가 발견됐습니다.

팀은 데이터베이스를 교체하는 대신 문서 버전, 제품 플랜, 공개 범위를 메타데이터로 추가했습니다. 최신 문서에 가중치를 주고 폐기된 매뉴얼을 검색 대상에서 제외하자 정확도가 개선됐습니다. 디지털 전환은 도구 구매 자체보다 업무 과정과 정보 흐름을 다시 설계하는 일에 가깝다는 점은 디지털 관련 용어 설명을 참고하면 맥락을 넓혀 이해할 수 있습니다.

1. 첫째 주: 상담원이 자주 묻는 질문 120개와 근거 문서를 연결했습니다.
2. 둘째 주: 문서를 제목, 본문, 절차 단위로 나누고 서로 다른 분할 크기를 시험했습니다.
3. 셋째 주: 키워드 검색과 벡터 검색을 결합하고 최신 버전에 가중치를 부여했습니다.
4. 넷째 주: 고객사별 권한 필터와 답변 출처 링크를 넣어 내부 사용자에게 공개했습니다.
5. 배포 이후: 답변을 찾지 못한 질문과 상담원이 수정한 문장을 매주 평가 세트에 추가했습니다.

두 달 뒤 문서 조각은 7만 개로 늘었지만 검색 속도는 내부 목표 범위에 머물렀습니다. 팀은 전용 벡터 데이터베이스 도입을 미루고, 대신 검색 실패 로그와 문서 갱신 자동화에 시간을 투자했습니다. 향후 외부 고객에게 기능을 개방해 동시 요청이 급증하거나 기존 DB의 거래 처리에 영향을 주는 시점에는 동일한 평가 세트를 이용해 관리형 제품을 다시 시험하기로 했습니다.

이 사례에서 중요한 결정은 특정 기술을 선택하거나 거부한 것이 아닙니다. 작은 데이터로 품질 기준을 만들고, 병목이 확인된 뒤 인프라를 분리했다는 순서입니다. 만약 당신의 팀이 아직 대표 질문과 정답 근거를 준비하지 못했다면, 다음 구매 미팅보다 먼저 사용자 질문 50개가 담긴 문서부터 만드는 편이 RAG 서비스의 성공 가능성을 높여 줍니다.