Gemini 2.5 자동 전환 예고: 12월 1일 전에 요청·출력 계약 점검하기

입구의 이름은 같아도 내부 처리 경로가 달라지는 상황을 표현한 생성형 개념 이미지다. 실제 Gemini 시스템이나 제품 화면은 아니다.

모델 이름을 바꾸지 않았는데 응답 형식이나 도구 호출이 달라질 수 있을까? Gemini 2.5를 사용하는 서비스라면 이번에는 그 가능성을 전제로 준비해야 한다. Google은 기존 모델 ID의 요청을 새 모델로 연결하는 일정을 발표했다. 핵심은 모델 문자열 검색에 그치지 않고 요청 옵션, 대화 상태, 출력 검증과 비용을 함께 점검하는 것이다.

12월 1일에 무엇이 바뀌나

Google의 2026년 11월 2일 공식 릴리스 노트에 따르면, 2026년 12월 1일부터 다음 요청은 새 모델로 자동 연결된다.

gemini-2.5-flash → gemini-3.5-flash-lite

gemini-2.5-pro → gemini-3.8-flash

요금도 연결되는 모델을 기준으로 적용된다. 예전 모델 ID를 계속 보낸다고 기존 모델의 동작이나 비용이 고정되는 것은 아니다. 정확한 전환 시각과 시간대는 이 공지에 없으므로 한국 시간 자정으로 단정하지 않는다. Google 공식 릴리스 노트

범위도 구분해야 한다. gemini-2.5-flash-lite는 이번 두 모델의 종료 대상이 아니다. -preview-tts가 붙은 음성 모델은 다른 항목이다. 비슷한 접두어를 모두 같은 일정으로 처리하면 불필요한 수정이나 누락이 생긴다. 모델별 종료 일정과 예외

모델명 검색은 출발점이다

다음 명령은 로컬 프로젝트에서 두 모델 ID의 후보 위치를 찾는다. ripgrep이 설치된 환경에서 실행하며 코드를 수정하거나 API를 호출하지 않는다.

이 패턴은 뒤에 -lite나 -preview-tts가 붙은 이름을 제외한다. 합성 입력으로 두 대상 ID가 검출되고 Flash-Lite와 preview-TTS가 제외되는 것은 확인했다. 실제 서비스의 전체 사용 위치를 검증한 결과는 아니다.

문자열 검색은 주석과 문서도 잡는다. 반대로 런타임에 조합한 이름, 기본적으로 무시되는 파일, 배포 환경변수, 관리 화면의 설정은 놓칠 수 있다. 따라서 발견한 위치마다 다음 내용을 확인하는 편이 좋다.

실행 코드인지 예제·주석인지 구분한다.

현재 배포된 버전과 설정에도 같은 값이 있는지 확인한다.

해당 호출이 요약, 분류, 구조화 출력, 도구 호출 중 무엇을 하는지 적는다.

요청 옵션과 응답을 소비하는 코드를 함께 찾는다.

검색 결과에는 같은 줄의 인증정보나 내부 프롬프트가 포함될 수 있다. 출력 전체를 그대로 이슈나 외부 서비스에 붙이지 않는다.

오류가 안 나도 바뀌는 설정이 있다

공식 전환 지침은 기존 요청의 옵션을 함께 검토하라고 안내한다. 특히 무시되는 설정과 명시적인 오류를 구분해야 한다.

현재 전환 문서는 temperature, top_p, top_k 같은 샘플링 값이 무시된다고 명시한다. 낮은 temperature로 분류 결과를 안정화했다고 가정한 코드라면, 요청 성공만으로 이전 동작이 유지됐다고 판단하기 어렵다.

마지막의 비어 있지 않은 모델 역할 메시지를 미리 채우는 prefill은 HTTP 400으로 실패한다. 둘 이상의 후보를 요청하는 방식도 지원되지 않으므로 candidate_count 설정을 별도로 확인한다. 스트리밍 여부와 무관하게 실제 요청 본문을 비교하는 것이 먼저다. Gemini 3.5 Flash-Lite 전환 지침

추론 설정도 숫자 예산을 그대로 옮기면 안 된다. thinking_budget과 thinking_level은 같은 형태의 설정이 아니다. 특히 3.8 Flash는 minimal을 지원하지 않으므로, Flash-Lite용 설정을 공유하는 어댑터에서 그대로 재사용하지 않도록 점검한다. Gemini 3.8 Flash 전환 지침

도구 호출은 한 번의 응답만 확인하면 부족하다

단일 요약 요청은 새 모델의 답을 받아 보는 것으로 기본 호환성을 살펴볼 수 있다. 하지만 도구 호출은 모델 응답, 실행 결과, 다음 요청이 연결된 상태 전이다.

공식 문서는 이전 턴의 thought signature를 보존할 것을 안내한다. generateContent API를 사용한다면 함수 응답이 원래 호출의 식별자와 이름에 맞는지도 확인한다. Interactions API는 상태 유지 방식이 다르므로 해당 API의 previous_interaction_id 지침을 따른다. 응답에서 눈에 보이는 텍스트만 저장한 뒤 다음 턴을 새로 조립하는 구현은 이 정보를 잃을 수 있다. 사용 중인 SDK와 API의 필드 이름을 확인하고, 응답 객체를 임의로 축약하는 어댑터를 특히 살펴본다. 3.8 Flash의 도구 호출 호환성

실무에서는 다음 흐름을 하나의 검증 사례로 잡을 수 있다. 이는 운영 점검 제안이며 실제 실행 결과가 아니다.

모델이 도구 호출을 반환한다.

호출 ID와 인자를 보존한 채 허용된 도구만 실행한다.

대응하는 결과를 다음 요청에 넣는다.

모델이 결과를 반영한 최종 응답을 반환하는지 확인한다.

도구 오류나 중복 응답이 있을 때 같은 외부 작업을 다시 실행하지 않는지 검사한다.

모델 변경을 계기로 도구의 권한이나 실행 범위를 넓힐 필요는 없다. 승인과 중복 실행 방지는 모델 밖에서도 유지해야 한다.

전환 완료의 기준을 먼저 정한다

운영 모델을 일괄 치환하기 전에 대표 입력과 합격 기준을 고정하면 비교가 쉬워진다. 비식별·합성 입력부터 준비하고, 유료 호출은 별도의 예산과 승인 범위 안에서 수행한다.

JSON 출력: 파싱 성공뿐 아니라 필수 필드, 타입, 허용 값과 빈 값 처리까지 확인한다.

요약·분류: 중요한 사실 누락, 분류 기준 이탈, 긴 입력과 모호한 입력의 차이를 확인한다.

도구 호출: 첫 호출뿐 아니라 결과를 돌려준 다음 턴과 오류 경로도 확인한다.

운영 지표: 지연, 오류율, 입력·출력 사용량과 요청당 비용을 같은 입력 묶음으로 비교한다.

단가가 달라지는 것과 전체 비용이 줄어드는 것은 별개다. 응답 길이, 추론 사용량, 실패 후 재시도가 함께 달라질 수 있기 때문이다. 가격은 도입 시점의 공식 요금표로 다시 계산해야 한다. Gemini API 가격

검증 후에는 선택한 모델 ID와 옵션을 명시하고 작은 트래픽부터 관찰하는 편이 낫다. 예전 2.5 alias로 되돌리는 것을 장기적인 롤백 수단으로 가정해서는 안 된다. 자동 연결 이후에는 같은 예전 이름도 새 모델을 가리키기 때문이다. 대체 경로 역시 실제로 사용 가능한 모델과 검증된 요청 조합이어야 한다.

이 글은 2026년 11월 3일 한국 시간 기준 공식 공개 문서를 검토한 설명이다. 로컬 검색 패턴의 합성 확인 외에 실제 Gemini API 호출, 성능 측정, 서비스 설정 변경은 수행하지 않았다. 운영 적용 전 최신 공지와 사용 중인 SDK의 전환 지침을 다시 확인해야 한다.