벡터 DB를 도입하자는 제안은 “AI를 하니까”라는 이유로 너무 쉽게 통과됩니다. 실제로는 검색 문제가 의미 유사 검색인지, 정확한 키워드·필터 검색인지부터 나눠야 합니다. 상품코드, SKU, 주문번호, FAQ 고정 문구처럼 표기가 일정한 질의는 기존 검색 엔진이나 DB 인덱스로도 충분한 경우가 많습니다.
벡터가 빛나는 지점은 표현이 다양한 자연어 질문입니다. “환불은 며칠이야?”와 “결제 취소 기한”처럼 단어가 달라도 같은 문서를 찾아야 할 때입니다. 동의어가 많고, 문서가 길고, 사용자가 정확한 용어를 모르는 서비스일수록 이득이 큽니다.
반대로 벡터만 쓰면 고유명사·숫자·정확한 조항 인용에서 약해질 수 있습니다. 그래서 실무에서는 키워드 검색과 벡터 검색을 합친 하이브리드로 시작하는 편이 안전합니다. 초기에 가중치를 5:5로 두고, 실패 로그를 모아 키워드 비중을 올리면 됩니다.
인프라 비용도 판단 기준입니다. 문서 수가 수천 건 수준이고 갱신이 드물다면 관리형 검색이나 가벼운 임베딩 인덱스로도 PoC가 됩니다. 수백만 건·초당 높은 QPS·실시간 업데이트가 필요해질 때 전용 벡터 DB 검토를 미뤄도 늦지 않습니다.
운영 체크: 재인덱싱 시간, 필터(권한·카테고리) 지원, 백업, 모니터링, 임베딩 모델 교체 시 마이그레이션 비용을 견적에 포함하세요. “검색 품질”만 보고 고르면 나중에 운영비가 더 커집니다.
결정 가이드: (1) 질의에 고유 ID·정확한 키워드가 많은가 → 기존 검색 우선 (2) 표현 변형이 많은가 → 벡터 또는 하이브리드 (3) 권한 필터가 필수인가 → 메타데이터 필터가 강한 쪽 (4) 팀 규모가 작은가 → 하이브리드 PoC 후 확장.
