임베딩 모델을 바꿀 때 검색도 함께 이사한다

임베딩 모델만 교체하면 기존 문서 벡터도 그대로 쓸 수 있을까. 벡터 공간의 호환성, 질의와 문서의 인코딩, 이전 중 수정·삭제, 검색 전환과 복구 조건을 공식 문서에 근거해 살핀다.

표지는 검색 표현의 이전을 나타낸 AI 생성 개념 이미지다. 실제 벡터 분포나 제품 화면을 시각화한 자료는 아니다.

사내 검색팀이 새 임베딩 모델을 시험한다고 가정해 보자. 짧은 질문을 잘 처리하고 비용도 적당해 보인다. 담당자는 질문을 벡터로 만드는 모델 설정을 바꾼다. 기존 문서 벡터와 길이가 같아 검색 API는 정상 응답한다. 그러나 직원이 자주 찾던 안내문이 결과에서 밀리기 시작한다. 오류 메시지가 없다는 사실만으로 교체가 성공했다고 판단하기 어려운 장면이다.

임베딩은 텍스트를 숫자 배열로 표현한다. 의미 검색은 질문과 문서를 비교 가능한 공간에 놓고 가까운 대상을 찾는다. 따라서 교체 대상에는 질문을 처리하는 모델뿐 아니라 이미 저장한 문서의 표현도 포함된다. 새 모델을 고르는 결정은 검색 자료를 다시 만들고, 운영 중인 검색을 옮기는 작업으로 이어진다.

앞선 문서 수명 관리 글은 원본이 개정되거나 폐기될 때 색인도 그 변화를 따라야 한다고 설명했다. 모델 교체는 그 문제에 한 층을 더한다. 문서의 내용은 같아도 검색에 사용하는 표현의 버전이 달라진다.

같은 길이의 벡터가 같은 의미 공간을 보장하지는 않는다

벡터의 차원 수는 배열에 들어 있는 숫자의 개수다. 두 배열의 길이가 같으면 거리를 계산할 수 있지만, 그 거리가 업무상 관련성을 제대로 나타내는지는 별도 문제다. MongoDB의 Voyage AI 이전 문서는 차원 수와 원소 형식이 같아도 다른 모델로 옮길 때 문서 전체를 다시 임베딩하도록 안내한다. 단순히 계산 가능한 상태와 검색 의미가 유지되는 상태를 구분한 것이다. 모델 이전 안내

여기에는 제품별 예외도 있다. 같은 문서는 voyage-4 계열 사이의 임베딩 호환성을 명시하면서도 이전 시 문서 재생성을 권한다. 따라서 모든 모델 조합이 무조건 호환되지 않는다고 단정할 필요는 없다. 확인할 것은 두 모델의 출력 길이가 아니라 제공자가 밝힌 호환 범위와 실제 업무 질의에서의 결과다. 호환성 설명이 없다면 기존 벡터를 그대로 써도 된다고 추정하지 않는 편이 타당하다.

질문과 문서가 반드시 똑같은 입력 형식을 사용한다는 뜻도 아니다. 짧은 질문으로 긴 문단을 찾는 검색에서는 양쪽의 역할이 다르다. Sentence Transformers는 이를 비대칭 의미 검색으로 설명하고 질의에는 encode_query(), 문서에는 encode_document()를 권한다. 역할별 프롬프트나 처리가 없는 모델에서는 두 경로의 결과가 같을 수도 있다. 공식 의미 검색 설명

2026년 10월 22일 확인한 공식 저장소의 기본 브랜치 main 구현도 이 역할을 나눈다. encode_query()는 질의 프롬프트를 선택하고 task="query"를 전달한다. encode_document()는 문서용 프롬프트 후보를 확인하고 task="document"를 전달한다. 같은 함수 호출 문자열을 양쪽에 복사하기보다, 해당 모델이 요구하는 질의·문서의 짝을 유지해야 한다. 확인한 고정 버전의 구현

무엇으로 만든 검색 표현인지 남긴다

운영팀이 남길 기록은 모델 이름 하나보다 구체적이어야 한다. 다음 표는 제품의 표준 스키마를 옮긴 것이 아니라, 교체를 준비하는 팀에 제안하는 기록 항목이다.

기존 문서 벡터만 보관하고 원문이나 청크를 재구성할 수 없다면 새 모델로 무엇을 다시 계산할지도 불명확해진다. 모델 교체 전에 원문 접근 가능성과 현재 버전을 확인해야 한다. 재생성 비용을 산정할 때도 벡터 개수뿐 아니라 입력 텍스트의 분량과 처리 제한을 함께 살펴야 한다.

청크 규칙까지 함께 바꾸면 문서 수와 벡터 수의 관계도 달라진다. 예전 청크 하나가 새 청크 여러 개로 나뉠 수 있다. 이때 두 저장소의 항목 수가 같다는 사실만으로 이전의 완전성을 판단할 수는 없다. 원본의 어떤 구간이 새 검색 표현에 들어갔는지를 대조해야 한다. 모델만 바꾸는 실험과 청크까지 바꾸는 실험을 나누면 품질 변화의 원인도 더 읽기 쉬워진다.

다시 채우는 동안에도 문서는 바뀐다

Qdrant의 공식 이전 안내는 새 컬렉션을 나란히 만드는 방식과 한 컬렉션 안에 새 이름의 벡터를 추가하는 방식을 제시한다. 후자는 처음부터 named vectors를 사용하는 컬렉션과 버전 조건이 필요하다. 현재 안내는 Qdrant 1.19.0에서 시험됐으며, 기존 컬렉션에 이 방식으로 벡터를 추가하는 경로를 1.18 이상으로 설명한다. 저장소 구성에 따라 이전 방식이 달라진다는 뜻이다. Qdrant 모델 이전 안내

새 저장소를 만드는 경우에는 신규 쓰기를 양쪽에 반영하면서 기존 자료를 순차적으로 채운다. 공식 예제는 이미 들어온 최신 항목을 과거 자료로 덮지 않도록 처리하지만, 삭제나 부분 수정까지 그대로 해결하는 예제는 아니다. 문서는 해당 작업을 잠시 멈추거나 별도 처리 논리를 마련하라고 명시한다. named vectors 방식에서도 뒤에서 채우는 동안 기존 항목의 수정·삭제를 멈추도록 안내한다.

가상의 안내문 하나를 생각해 보자. 이전 작업이 오전의 문서 내용을 읽은 뒤 담당자가 오후에 그 문서를 철회한다. 늦게 끝난 이전 작업이 오전 내용을 새 저장소에 넣으면, 기존 검색에서는 사라진 자료가 새 검색에서 되살아날 수 있다. 문서가 수정된 경우에는 새 메타데이터와 옛 내용의 벡터가 한 항목에 묶이는 상황도 고려해야 한다. 이는 모델의 이해력보다 변경 순서를 다루는 문제다.

조직에서 수정·삭제를 멈출 수 없다면 별도 설계가 필요하다. 원본 버전을 대조해 오래된 결과의 반영을 거부하거나, 변경 사건을 기록해 이전 후 다시 적용하는 방법을 검토할 수 있다. 이 방법들이 어떤 저장소에서도 자동으로 제공된다는 뜻은 아니다. 담당자는 선택한 제품과 쓰기 경로에서 충돌이 어떻게 처리되는지 확인하고, 문서 철회 사례로 직접 시험해야 한다.

검색의 전환 단위와 돌아올 조건을 함께 정한다

Qdrant의 컬렉션 별칭은 같은 이름이 가리키는 컬렉션을 바꿀 수 있게 한다. 공식 문서는 여러 별칭 변경을 원자적으로 처리한다고 설명한다. 그러나 그 기능의 범위는 컬렉션 별칭이다. 별도 애플리케이션의 질의 모델 설정까지 같은 순간에 바뀐다고 해석해서는 안 된다. 컬렉션 별칭 문서

팀은 요청 하나가 사용하는 질의 인코더와 검색 대상의 조합을 하나의 배포 설정으로 관리할 수 있다. 예를 들어 새 설정에는 새 질의 모델과 새 벡터 필드를 함께 적고, 요청을 처리하는 동안 그 조합을 유지한다. 모델은 새것인데 검색 대상은 옛것인 중간 상태가 생기는지, 여러 서버에 설정이 순차 배포될 때는 어떤 조합이 공존하는지 확인한다. 이는 별칭 기능 위에 팀이 설계할 전환 조건이다.

전환 전에는 같은 업무 질문으로 두 검색 경로를 비교한다. 단순한 결과 목록의 일치율보다 필요한 근거가 검색됐는지, 철회한 문서가 섞였는지, 긴 문서와 짧은 문의에서 어떤 실패가 생겼는지 살피는 편이 유용하다. 모델을 바꾼 이유가 비용이나 지연이라면 품질과 함께 그 조건도 확인한다. 이 글은 실제 검색 시스템을 이전해 측정한 성능 보고가 아니라 공개된 문서와 구현에 근거한 운영 논의다.

되돌릴 수 있는 기간도 명시해야 한다. Qdrant 안내는 새 검색으로 전환한 뒤에도 관찰 기간에는 양쪽 쓰기를 유지하고, 되돌릴 때 검색 대상과 모델을 함께 복원하도록 설명한다. 옛 저장소의 갱신을 멈췄다면 그 뒤의 문서 변경은 별도로 따라잡아야 한다. 예전 저장소가 남아 있다는 사실만으로 현재 업무를 복구할 준비가 끝난 것은 아니다.

임베딩 교체의 완료는 새 모델이 응답하는 순간에 정해지지 않는다. 현재 원본에서 만든 문서 표현, 그 표현과 맞는 질의 처리, 이전 중 발생한 변경, 실제 검색 결과가 한 조합으로 확인될 때 판단할 수 있다. 모델 선택을 데이터 이전과 연결해 다루면 검색 품질이 흔들렸을 때도 무엇을 비교하고 어디로 돌아갈지 설명할 수 있다.