Gemini Embedding 2 Preview 자동 전환: 벡터 재색인 없이 모델 이름 정리하기

모델 호출 경로를 바꾸면서 기존 벡터 저장소를 유지하는 상황을 표현한 생성형 에디토리얼 이미지. 실제 서비스 구조나 제품 화면을 나타내지는 않는다.

gemini-embedding-2-preview를 쓰는 검색·RAG 서비스라면 모델 이름을 gemini-embedding-2로 정리할 시점이다. Google은 November 6, 2026부터 Preview 이름으로 들어오는 API 요청을 정식 모델로 라우팅한다고 밝혔다. 이번 Preview → 정식 전환은 API 스키마·가격·임베딩 공간이 같아 벡터 재색인이 필요하지 않다. 11월 6일 공식 릴리스 노트

운영자가 할 일은 전체 문서를 다시 임베딩하는 작업보다 호출 설정과 검색 경로를 확인하는 것이다. 다만 이 안내를 다른 임베딩 모델 간 전환에 그대로 적용하면 안 된다.

1. 11월 6일에 바뀐 것은 Preview 이름의 처리다

공식 수명주기 문서에서 gemini-embedding-2의 출시일은 April 22, 2026다. 이번 소식은 정식 모델의 신규 출시가 아니라, gemini-embedding-2-preview 폐기와 자동 라우팅 적용이다. 폐기 목록의 날짜만 보고 모든 기존 요청이 즉시 실패한다고 해석하지 말고, 같은 행의 대체 모델 설명까지 읽어야 한다. 모델 수명주기

현재 요청이 성공하더라도 코드에 남은 Preview 이름을 계속 유지할 이유는 적다. 설정·로그·운영 문서에 실제로 사용할 모델 이름을 명확히 남기는 편이 추후 장애 대응에 유리하다. 확인한 공식 안내에는 이 자동 라우팅의 종료일이 별도로 제시돼 있지 않다. 따라서 임의의 마감 날짜를 만들거나 영구 지원으로 단정하지 않는다.

가격이 같다는 설명도 이 전환으로 단가가 바뀌지 않는다는 범위다. 호출량 증가, 중복 인덱싱, 입력 길이 변화까지 포함해 월 청구액이 같아진다는 보장은 아니다. 불필요한 전체 재임베딩을 시작하기 전에 변경 범위를 확인하는 이유다.

2. Preview 2 전환과 001 마이그레이션을 구분한다

재색인 여부는 모델 이름이 비슷한지가 아니라 기존 벡터와 새 벡터를 같은 공간에서 비교할 수 있는지에 달려 있다.

• gemini-embedding-2-preview → gemini-embedding-2: Google이 같은 임베딩 공간을 명시한 이번 전환이다. 이름 변경만으로 기존 벡터를 다시 만들 필요는 없다.

• gemini-embedding-001 → gemini-embedding-2: 공식 문서는 두 공간이 호환되지 않는다고 설명한다. 기존 데이터 전체를 새 모델로 다시 임베딩해야 한다. 두 모델의 벡터를 같은 검색 집합에 섞어 직접 비교해서는 안 된다. 001에서 이전할 때의 차이

001에서 넘어올 때는 task_type 처리와 여러 입력의 집계 방식 등도 달라진다. 따라서 “모델 문자열 한 줄만 바꾸면 된다”는 결론은 이번 Preview 2 전환에 한정한다.

기존 데이터가 어떤 모델로 생성됐는지 기록이 없다면 먼저 적재 작업의 설정과 데이터 계보를 확인한다. 벡터 길이가 같다는 사실만으로 같은 모델이나 같은 임베딩 공간임을 증명할 수는 없다.

3. 적재기와 검색기의 설정을 함께 찾는다

모델 이름은 웹 서버 코드 한 곳에만 있지 않을 수 있다. 문서 적재 배치, 질의 임베딩 서버, 배포 환경 변수, 노트북, 모델 허용 목록을 함께 확인한다.

Git이 추적하는 파일에서는 다음과 같이 사용 위치를 찾을 수 있다.

이 명령은 저장소 밖의 배포 환경 변수나 관리형 작업 설정까지 찾지 않는다. 검색 결과가 없으면 명령의 종료 코드는 1일 수 있으므로, 이를 곧바로 실행 오류로 해석하지 않는다. 출력에 내부 경로나 설정이 포함될 수 있으니 공개 이슈나 로그에 그대로 붙이지 않는다.

환경 변수로 모델을 선택하는 애플리케이션이라면 변경은 다음처럼 작게 나눌 수 있다. 변수 이름은 설명용 예시이며, 실제 애플리케이션이 읽는 설정 키를 사용해야 한다.

이 배포에서 청크 분할, 전처리, 출력 차원, 검색용 입력 형식까지 함께 바꾸지 않는 편이 원인 추적에 좋다. 공식 문서는 출력 차원을 output_dimensionality로 지정할 수 있다고 설명한다. 기존 인덱스와 질의 벡터가 기대하는 차원을 유지해야 한다. 출력 차원 설정

4. 모델 이름을 키로 쓰는 주변 코드를 점검한다

공급자의 API 호환성과 애플리케이션의 문자열 비교는 별개다. 다음은 제품의 추가 요구사항이 아니라, 배포 전에 점검할 구현상의 사례다.

캐시와 저장소 이름. 모델 이름을 캐시 키나 컬렉션 이름에 그대로 넣는 코드에서는 새 이름 때문에 빈 캐시나 새 컬렉션이 선택될 수 있다. 기존 벡터를 사용할 수 있는데도 애플리케이션이 데이터가 없다고 판단해 전체 적재를 시작하지 않는지 확인한다.

모델 허용 목록. 설정 검증이나 프록시가 Preview 이름만 허용한다면 정식 이름을 넣은 뒤 로컬 검증 단계에서 거절될 수 있다. 호출 지점뿐 아니라 모델 이름을 검사하는 코드도 찾는다.

저장된 생성 이력. 과거 벡터에 기록한 모델 이름은 생성 당시의 이력이다. 문자열을 맞추려고 과거 기록을 일괄 덮어쓰기보다, 이번 두 이름의 호환 관계를 운영 문서나 별도 메타데이터로 명확히 관리하는 편이 낫다. 다른 모델까지 같은 것으로 취급하는 포괄적인 규칙은 피한다.

이 점검은 “추가 API 코드 변경이 필요 없다”는 공식 설명과 충돌하지 않는다. 애플리케이션이 모델 이름을 저장소 선택이나 검증 규칙에 사용했는지를 확인하는 작업이다.

5. 요청 성공보다 검색 경로의 연속성을 확인한다

배포 검증은 다음 순서로 진행할 수 있다. 아래는 운영자가 실행할 검증 계획이며, 이 글에서 유료 API 요청이나 실제 서비스 시험을 수행한 결과는 아니다.

1. 변경 전 기준을 남긴다. 인덱스 이름, 벡터 개수, 출력 차원, 전처리와 입력 형식을 기록한다. API 키와 원문 사용자 질의는 기록하지 않는다.

2. 정식 이름으로 작은 범위를 검증한다. 새 질의 벡터가 기존 인덱스에서 정상 검색되는지, 적재기와 검색기가 같은 설정을 사용하는지 확인한다.

3. 대표 질의의 검색 결과를 비교한다. 단순 HTTP 성공 외에 예상 문서가 상위 결과에 나오는지와 차원 불일치·빈 검색·잘못된 컬렉션 선택을 확인한다.

4. 중복 작업을 감시한다. 전체 재임베딩 작업이 의도 없이 시작되지 않았는지, 벡터 개수와 호출량이 갑자기 늘지 않았는지 본다.

5. 적용 범위를 넓힌다. 배치 작업과 예약 실행에 오래된 설정이 남지 않았는지 확인하고 배포 문서도 정리한다.

자동 라우팅이 이미 적용된 뒤에는 Preview 이름과 정식 이름을 각각 호출해도 과거 Preview 모델과 현재 모델을 비교하는 시험이 되지 않는다. 이전 이름으로 되돌리는 것 역시 과거 모델 동작의 복구를 보장하지 않는다. 되돌릴 수 있는 애플리케이션 설정과 공급자가 관리하는 모델 수명주기를 구분해야 한다.

이번 변경의 완료 기준은 정식 모델 이름으로 호출하고, 기존 인덱스와 검색 계약을 유지하며, 불필요한 재임베딩이 발생하지 않는 것이다. 모델 이름 변경과 검색 품질 개선 작업을 분리하면 비용과 원인 분석을 모두 관리하기 쉬워진다.

확인 기준: November 7, 2026 한국 시간. Google의 공개 릴리스 노트·수명주기·임베딩 문서를 기준으로 작성했다. API 호출 성공률이나 검색 품질을 직접 측정했다고 주장하지 않는다.