임베딩 모델을 바꾸면 벡터 색인 운영도 함께 바뀐다

임베딩 모델 교체는 모델 파일만 바꿔 끼우는 배포가 아니다. 벡터가 놓인 공간이 바뀌므로 저장된 벡터, 색인, 서빙 코드를 함께 바꾸는 데이터 마이그레이션에 가깝다.

이 글은 Embedding에서 다룬 "문서와 질문은 같은 모델로 임베딩해야 한다"는 규칙이 운영 단계에서 어떤 작업으로 바뀌는지 정리한다. 토스증권 ML 엔지니어의 발표를 글로 정리한 토스증권 추천과 검색은 어떻게 진화하고 있을까?(황호익, 토스 기술 블로그, 2026-08-26)의 추천 사례를 바탕으로, 일반화할 수 있는 부분만 추렸다. 발표 영상은 테크톡톡 2026 | ML Engineer - 토스증권 추천과 검색은 어떻게 진화하고 있을까?다.

왜 모델 교체가 데이터 마이그레이션인가

서로 다른 임베딩 모델이 만든 벡터는 같은 좌표계에 있다고 볼 수 없다. 기존 벡터 위에 새 모델의 질문 벡터를 놓고 거리를 재면 숫자는 나오지만 의미는 없다.

그래서 모델을 바꿀 수 있게 열어 두는 순간부터 다음 세 가지가 필요해진다.

교체 절차

세 번째 항목은 순서를 지키지 않으면 장애로 이어진다. 모델 서빙만 먼저 바꾸면 새 질문 벡터가 옛 색인을 조회하고, 색인만 먼저 바꾸면 반대가 된다.

이전 색인은 전환이 끝난 뒤에도 한동안 남겨 두어야 한다. 새 색인에서 문제가 보이면 모델과 색인을 함께 이전 버전으로 되돌릴 수 있어야 하기 때문이다. 이 보관과 원자적 전환은 발표 자료가 직접 설명한 부분이 아니라 위 요구에서 이끌어 낸 운영 원칙이다.

재색인 비용은 벡터 DB 5종을 실제로 벤치마크했다에서 다룬 색인 빌드 시간과 직접 이어진다. 모델 교체 주기가 짧을수록 빌드 시간이 곧 운영 비용이 된다.

벡터 저장소는 검색 지연만으로 검증하면 부족하다

추천에서 사용자의 과거 선호 아이템이나 최근 행동을 피처로 쓰면 유사도 검색 외의 요청이 생긴다. 여러 아이템의 임베딩을 한 번에 읽어 오는 대량 조회(multi-get)다.

발표에서는 이 워크로드에서 고차원 벡터를 응답에 담는 과정이 JVM 메모리 압력을 키울 수 있었다고 설명한다. 그래서 검색 지연 시간만 보지 않고 대량 조회 처리량과 GC 추이를 실제 요청 패턴으로 함께 검증했다.

백엔드 관점에서 정리하면 다음과 같다.

• 검색 요청과 대량 조회 요청은 트래픽 모양이 다르므로 따로 측정한다.
• 공개 벤치마크 수치는 이 부하를 드러내지 않는다. 서비스의 실제 요청 형태를 재현해야 한다.
• 지연 시간, 처리량, GC 추이를 같은 시나리오에서 함께 본다.

정리

• 임베딩 모델 버전은 벡터 데이터의 속성으로 저장한다.
• 질문 임베딩 모델과 검색 색인은 같은 버전으로 묶어 함께 전환한다.
• 벡터 저장소 검증에는 유사도 검색뿐 아니라 서비스가 실제로 내는 대량 조회 요청을 포함한다.

추천 쪽에서 이 요구가 어떻게 생기는지는 배치 추천에서 실시간 루프로 옮기는 조건과 구성에서 이어서 다룬다.