벡터DB는 왜 벡터만으로 부족할까: AI 검색의 다음 숙제

핵심 요약

• 벡터 검색은 의미가 비슷한 내용을 찾지만, 제품 코드의 정확한 일치나 사용자의 접근 권한까지 보장하지는 않습니다.
• 하이브리드 검색은 의미 검색과 키워드 검색을 결합해 서로 다른 단서로 문서를 찾습니다.
• 검색 품질은 필요한 후보를 잘 찾는지, 그 후보를 적절한 순서로 보여주는지에 달려 있습니다.
• 저장소와 캐시를 어떻게 구성하느냐에 따라 데이터 보관 비용과 검색 응답 시간이 달라집니다.

AI가 사내 문서를 찾아 답하는 서비스에서는 질문과 비슷한 문서를 찾는 것만으로는 부족합니다. 제품 버전이 다르거나 사용자가 열람할 수 없는 자료라면 답변의 근거로 쓰기 어렵습니다. 그래서 turbopuffer 같은 검색 인프라를 평가할 때는 벡터 검색 외의 기능도 함께 살펴야 합니다.

의미가 비슷해도 필요한 문서는 다릅니다

벡터 검색은 문장이나 이미지를 숫자 배열로 바꿔 비교합니다. 이 숫자 배열을 임베딩이라고 부릅니다. 서로 다른 표현을 쓰더라도 의미가 가까운 내용을 찾는 데 유용합니다.

예를 들어 사용자가 “물건을 돌려보내려면 어떻게 하나요?”라고 물었을 때, “반품 절차”라는 제목의 문서를 찾는 식입니다. 질문과 문서에 같은 단어가 없어도 의미를 바탕으로 연결할 수 있습니다.

하지만 질문이 “ZX-410의 반품 조건은 무엇인가요?”라면 제품 코드도 살펴야 합니다. 여기서 제품 코드는 예시입니다. ZX-420의 반품 안내는 의미상 매우 비슷해도 사용자가 물어본 제품에 대한 답은 아닐 수 있습니다.

이때는 제품 코드가 정확히 일치하는지 확인하는 조건이 필요합니다. “현재 적용되는 정책”을 찾는다면 시행일이나 문서 상태도 확인해야 합니다.

실제 검색 요청에는 이런 요구가 한꺼번에 담깁니다. 질문과 의미가 가까운 문서를 찾되, 사용자가 지목한 대상과 맞는지도 확인해야 합니다. 여기에 필요한 조건까지 충족해야 검색 결과로 쓸 수 있습니다.

하이브리드 검색은 단서를 모으고 순서를 정합니다

하이브리드 검색은 벡터 검색과 키워드 검색처럼 서로 다른 검색 방식을 함께 사용합니다.

벡터 검색은 같은 뜻을 다르게 표현한 문장을 연결하는 데 유용합니다. 키워드 검색은 제품명이나 오류 메시지처럼 문서에 실제로 쓰인 표현을 찾는 데 도움이 됩니다. 제품 코드가 정확히 일치해야 한다면 별도 필드에 필터 조건을 걸 수도 있습니다.

두 방식으로 후보를 찾은 뒤에는 순서도 정해야 합니다. 어떤 문서를 먼저 보여줄지에 따라 사용자가 접하는 검색 결과가 달라집니다.

벡터 검색에서 높은 점수를 받은 문서가 키워드 검색에서도 높은 점수를 받는다는 보장은 없습니다. 두 방식은 점수를 매기는 체계도 다를 수 있습니다. 따라서 점수를 단순히 더하면 원하는 순서로 문서를 보여주지 못할 수 있습니다.

각 검색 결과의 순위를 이용해 후보를 합치는 방법이 있습니다. 질문과 후보 문서를 다시 비교해 순서를 매길 수도 있습니다. 이처럼 다시 순서를 정하는 방식을 재순위화라고 합니다.

AI에 전달할 문서가 몇 개로 제한된다면 순서는 더 중요해집니다. 필요한 문서를 후보 목록에 포함하는 데서 그치지 않고, 실제로 AI에 전달할 수 있도록 앞쪽에 올려야 합니다.

검색 기능이 넓어지면 저장 설계도 복잡해집니다

검색 시스템이 보관하는 데이터는 벡터만이 아닙니다. 구성에 따라 원문과 키워드 검색용 색인을 관리하고, 제품명이나 날짜 같은 속성도 저장해야 합니다. 색인은 원하는 데이터를 빠르게 찾도록 돕는 보조 구조입니다.

문서 하나를 수정할 때도 이런 데이터가 함께 영향을 받습니다. 본문이 바뀌면 임베딩을 다시 만들어야 할 수 있습니다. 키워드 색인과 문서의 상태 정보도 함께 갱신해야 합니다.

각 데이터를 갱신하는 시점이 어긋나면 최신 본문에 예전 검색 정보가 연결될 수 있습니다. 검색 기능을 추가할 때는 데이터끼리 일관성을 유지할 방법과 변경 사항을 언제 반영할지도 설계해야 합니다.

저장 비용과 검색 속도 사이의 균형도 잡아야 합니다. 예를 들어 데이터를 객체 단위로 보관하는 오브젝트 스토리지를 기본 저장소로 쓰고, 자주 읽는 데이터는 SSD나 메모리에 두는 구성이 가능합니다.

이렇게 저장소를 계층으로 나누면 모든 데이터를 빠른 저장장치에 두는 부담을 줄일 수 있습니다. 다만 빠른 임시 저장 공간인 캐시에 필요한 데이터가 없을 때는 원격 저장소에서 가져오는 시간이 더 걸릴 수 있습니다.

평균 응답 시간만 봐서는 이런 차이를 알기 어렵습니다. 처음 검색할 때와 같은 내용을 반복해서 검색할 때 얼마나 차이가 나는지도 확인해야 합니다. 자주 찾는 문서와 드물게 찾는 문서의 검색 속도 차이 역시 사용자 경험에 영향을 줍니다.

범용화는 개발팀이 직접 연결할 일을 줄여줍니다

개발팀이 검색 서비스를 만들려면 여러 기능을 연결해야 합니다. 의미 검색 결과를 가져와 키워드 검색 결과와 합친 뒤, 권한을 확인하고 최종적으로 보여줄 순서를 정해야 합니다.

각 기능을 별도 시스템으로 구성할 수도 있습니다. 다만 이 경우 문서를 수정하거나 삭제할 때 여러 시스템에 변경 사항을 반영해야 합니다. 검색이 느려지면 어느 시스템에서 문제가 생겼는지 추적하는 일도 복잡해질 수 있습니다.

검색 인프라가 이런 기능을 함께 제공하면 개발팀이 직접 연결하고 관리할 부분을 줄일 수 있습니다. 제가 검색 인프라 범용화에서 기대하는 이점도 개발팀의 이런 작업이 줄어드는 데 있습니다.

기능 목록이 길다고 무조건 좋은 시스템은 아닙니다. 실제 서비스에서 나오는 질문으로 확인해야 합니다. 제품 코드가 들어간 질문을 잘 처리하는지 살펴보고, 권한 조건이 붙었을 때도 충분히 빠른지 확인해야 합니다. 수정한 문서가 언제부터 검색에 반영되는지도 판단 기준입니다.

벡터 중심 설계를 넓힌다는 말도 이런 맥락에서 이해할 수 있습니다. 벡터를 중요한 검색 수단으로 계속 쓰면서, 문서를 저장하는 단계부터 최종 결과를 고르는 단계까지 함께 다루는 방향입니다.

AI 검색용 데이터베이스를 평가할 때는 의미 검색의 정확도와 함께 조건을 처리하고 데이터를 갱신하는 방식도 살펴야 합니다. 저장 비용도 따져봐야 합니다. 서비스에서 검색 인프라에 어디까지 맡길지 정해두면 필요한 기능을 고르기 쉽습니다. 그 기능을 운영하면서 어느 정도의 부담을 감수할지도 구체적으로 판단할 수 있습니다.