Google, 6월 24일에 모든 Imagen 모델 은퇴 — 그리고 Gemini 이미지 마이그레이션이 4곳에서 조용히 실패함

2026년 6월 24일, Google은 Gemini API의 모든 남은 Imagen 모델을 종료합니다:

• imagen-4.0-generate-001
• imagen-4.0-ultra-generate-001
• imagen-4.0-fast-generate-001

(imagen-3.0-generate-002는 이미 2025년 11월 10일에 종료되었습니다 — 만약 그 상황을 어떻게든 버텨냈다면, 당신은 이미 빌려온 시간을 쓰고 있었던 셈입니다.)

권장되는 대체 모델은 gemini-2.5-flash-image — Google이 "Nano Banana"라고 마케팅하는 모델 — 또는 gemini-3-pro-image-preview입니다.

이 상황을 위험하게 만드는 부분은 바로 여기입니다. 은퇴(Retirement) 자체는 요란합니다: 6월 24일 이후 imagen-4.0-generate-001에 대한 요청은 에러를 반환하고, 파이프라인(Pipeline)이 중단되며, 누군가 호출을 받게 됩니다. 그건 괜찮습니다. 요란한 실패는 수정될 수 있으니까요.

마이그레이션(Migration)은 요란하지 않습니다. Imagen과 Gemini의 이미지 생성은 단순히 모델 문자열만 다른 동일한 API가 아닙니다. 이들은 두 개의 서로 다른 요청 형태(Request shapes), 두 개의 서로 다른 엔드포인트(Endpoints), 그리고 두 개의 서로 다른 파라미터 어휘(Parameter vocabularies)를 가지고 있습니다. 그리고 Gemini의 이미지 엔드포인트는 Imagen 시대의 파라미터로 가득 찬 요청을 기꺼이 수락하고, 인식하지 못하는 파라미터는 무시한 채, 당신이 요청한 이미지가 아닌 어떤 이미지를 담아 200 OK를 반환할 것입니다.

그것이 함정입니다. 팀들은 마감 압박 속에서 마이그레이션을 진행하고, 이미지가 돌아오는 것을 확인하며, 초록색 상태 코드를 보고 배포할 것입니다. 결함은 몇 주 후, 아무런 에러도 첨부되지 않은 채 다운스트림(Downstream)에 도달하게 됩니다.

다음은 조용한 실패(Silent-fail)가 발생하는 지점들입니다.

1. 엔드포인트와 응답 형태가 변경됨 — 그리고 절반만 마이그레이션된 파서(Parser)가 조용히 실패함

Imagen은 :predict 엔드포인트에서 실행됩니다. instances와 parameters를 보내면 다음과 같은 응답을 받습니다:

{ "predictions": [ { "bytesBase64Encoded": "...", "mimeType": "image/png" } ] }

Gemini 이미지 생성은 **:generateContent**에서 실행됩니다. parts가 포함된 contents를 보내면 이미지는 다음과 같이 돌아옵니다:

{ "candidates": [ { "content": { "parts": [ { "inlineData": { "data": "...", "mimeType": "image/png" } } ] } } ] }

만약 코드를 새 모델로 지정해 두고 계속해서 :predict를 호출한다면, 명확한 에러가 발생합니다. 이는 오히려 다행입니다. 하지만 실제로 배포되어 발생하는 실패는 '절반만 이루어진' 마이그레이션(half migration)입니다. 즉, :generateContent로 전환은 했지만, 하위 헬퍼(downstream helper) 함수가 여전히 response.predictions[0].bytesBase64Encoded를 참조하는 경우입니다.

해당 경로는 Gemini 응답에는 존재하지 않습니다. JavaScript에서는 undefined로 평가됩니다. Python에서는 인덱스를 직접 지정(hard index)할 때만 KeyError가 발생하는데, 대부분의 이미지 처리 코드는 방어적으로 작성되었기 때문에 직접 지정하지 않습니다:

img = resp.get("predictions", [{}])[0].get("bytesBase64Encoded")
if img:
    save(img)

predictions가 누락되었으므로 img는 None이 되고, if 문은 건너뛰어집니다. 예외(exception)도 발생하지 않고, 이미지도 저장되지 않습니다. 로그에는 200 OK가 기록됩니다. 함수는 깔끔하게 반환됩니다. 자산 버킷(asset bucket)에 데이터가 쌓이지 않는다는 것을 누군가 알아차렸을 때야 비로소 문제를 발견하게 되며, 그때는 이미 언제부터 시작되었는지 알 수 없는 상태가 됩니다.

2. sampleCount가 사라짐 — 배치(batch) 작업이 호출당 이미지 1개로 조용히 축소됨

이것이 가장 치명적인 문제입니다.

Imagen의 :predict 요청은 sampleCount 파라미터를 사용합니다. 단일 호출에서 최대 4개의 이미지를 요청하거나(imagen-4.0-generate-001), Ultra 티어에서는 한 번에 1개를 요청할 수 있습니다. 수많은 파이프라인이 이 기능에 의존하고 있습니다. 즉, 프롬프트당 4개의 후보를 생성하고, 점수를 매긴 뒤, 가장 좋은 것을 선택하는 방식입니다. sampleCount: 4는 시스템을 지탱하는 핵심적인 요소입니다.

Gemini의 이미지 API에는 sampleCount가 없습니다. Gemini는 호출당 단 하나의 이미지만 생성하며, Google의 자체 문서에서도 이 점을 명확히 밝히고 있습니다: "모델이 사용자가 명시적으로 요청한 이미지 출력 개수를 항상 정확히 따르지는 않습니다."

따라서 마이그레이션된 요청에 sampleCount: 4가 포함되어 있거나, 대화형으로 "4가지 변형(four variations)"을 요청하더라도 Gemini는 에러를 내지 않습니다. 대신 이미지 1개를 반환하며 200 OK를 보냅니다. 당신의 후보군(candidate pool)은 순식간에 4개에서 1개로 줄어듭니다. "4개 중 최고를 선택"하는 단계는 여전히 실행되지만, 이제는

만약 당신의 시스템 중 어떤 부분이라도 반환받는 이미지의 '개수'에 대해 추론하고 있다면, 그 가정은 이제 틀렸으며, 심지어 조용히 틀리게 됩니다.

3. 종횡비(Aspect ratio) 네임스페이스 이동 — 그리고 제안 사항으로 전락

Imagen은 aspectRatio를 parameters의 최상위 항목(top-level entry)으로 받으며, 이는 엄격한 제약 조건(hard constraint)입니다. 즉, 16:9를 요청하면 16:9를 받게 됩니다.

Gemini 이미지 생성에서는 종횡비가 최상위 파라미터(top-level parameter)가 아닙니다. 이는 생성 설정(generation config) 내의 이미지 설정(image-config) 블록 안에 중첩되어 존재합니다. Imagen 스타일의 최상위 aspectRatio 필드를 그대로 가져오면 아무 곳에도 도달하지 못합니다. 이는 인식되지 않는 키(unrecognized key)가 되어 조용히 삭제되며, Gemini는 기본값(정사각형, 또는 프롬프트에서 추론한 값)으로 되돌아갑니다(fallback).

결과: 200 OK 응답과 함께 완벽하게 유효한 이미지가 생성되지만, 잘못된 규격(dimensions)으로 생성됩니다. 고정된 종횡비를 가정했던 모든 다운스트림 소비자(downstream consumer)—CSS 그리드, 비디오 프레임, 썸네일 크롭 도구(thumbnail cropper), 인쇄 레이아웃 등—는 이제 자신들이 설계되지 않은 형태의 이미지를 받게 됩니다. 최선의 경우 모양이 이상해 보일 뿐이지만, 최악의 경우 크롭 도구가 오류 없이 자동으로 피사체의 머리를 잘라버리며 문제를

결국 남는 것은 Gemini의 기본 인물 생성 (people-generation) 동작이며, 이는 당신이 신중하게 선택한 Imagen 설정과 일치한다는 보장이 없습니다. dont_allow로 고정된 파이프라인 (pipeline)이 인물이 포함된 이미지를 반환하기 시작할 수 있습니다. allow_all에 의존하던 파이프라인은 이전에는 수용했던 프롬프트(prompt)를 거부하기 시작할 수도 있습니다. 어느 쪽이든, 경고 없이 200 OK가 반환되며, 이를 제어하던 코드를 수정한 적이 없음에도 안전/준수 (safety/compliance) 태세가 변경됩니다. 이것이 보안 검토 (security review)에서 실제로 관심을 가져야 할 표면적인 문제이며, 이를 포착할 수 있는 오류나 스키마 차이 (schema diff)는 존재하지 않습니다.

5. 또한 예산(budget)에 반영해야 할 두 가지 사항

프롬프트 재작성 (Prompt rewriting). Imagen은 기본적으로 LLM 기반의 프롬프트 재작성기 (prompt rewriter)를 실행합니다. 즉, 이미지를 생성하기 전에 당신의 간결한 프롬프트를 조용히 확장합니다. Gemini는 프롬프트를 네이티브하게, 그리고 다르게 처리합니다. 마이그레이션(migration)을 수행하며 바이트 단위로 동일한 (byte-identical) 프롬프트를 보내더라도, 이미지의 스타일, 구도, 디테일 수준이 변하게 됩니다. 왜냐하면 당신의 결과물이 암묵적으로 조정되었던 사전 작성 (prewriting) 레이어가 사라졌기 때문입니다. 무엇인가가 고장 나는 것은 아닙니다. 단지 결과물이 표류(drift)할 뿐입니다. 브랜드나 스타일의 기준점 (baseline)이 있다면, 마이그레이션 후에 다시 승인하십시오.

마스크 기반 편집 (Mask-based editing)을 대체할 수 있는 수단이 없습니다. 이는 일부 팀이 실제로 수행할 수 없는 마이그레이션입니다. Imagen의 기능/편집 모델은 정밀하고 프로그래밍 가능한 마스크 기반의 인페인팅 (inpainting) 및 아웃페인팅 (outpainting)을 수행합니다. 즉, 참조 이미지와 마스크를 제공하면 편집 내용이 마스크 내부의 정확한 위치에 적용됩니다. Gemini 2.5 Flash Image는 대화형 (conversational) 편집을 수행합니다. 즉, 변경 사항을 말로 설명해야 합니다. 픽셀 단위로 정밀한 마스크 파라미터 (mask parameter)는 존재하지 않습니다. 제품 사진 촬영, 자동 리터칭, 합성 (compositing)과 같이 결정론적 (deterministic)인 마스크 기반 편집을 수행하는 파이프라인을 보유하고 있다면, 즉시 대체할 수 있는 경로는 없습니다. 이를 7월의 스프린트 계획 회의(sprint planning meeting)에서가 아니라, 지금 6월에 미리 파악하십시오.

실제로 해야 할 일

1. 모든 곳에서 폐기된 모델 ID를 grep으로 검색하십시오 — 앱 코드, IaC, 노트북, 프롬프트 설정, 배치 작업 정의 (batch-job definitions) 등:

   git grep -nE "imagen-(4\.0-(generate|ultra-generate|fast-generate)-001|3\.0)"

1. 이것을 단순한 문자열 교체가 아닌 재작성(rewrite)으로 간주하십시오. 엔드포인트(endpoint), 요청 형태(request shape), 응답 형태(response shape)가 모두 변경됩니다. 이것이 하나의 API 마이그레이션(migration)임을 인지하고 이에 대한 예산을 편성하십시오.

2. 새로운 API를 기준으로 모든 Imagen 시대의 파라미터(parameter)를 감사(audit)하십시오. 다음과 같은 항목으로 실제 체크리스트를 만드십시오: sampleCount, aspectRatio, personGeneration, 프롬프트 재작성(prompt-rewrite) 동작. 각 항목에 대해, 당신이 연결한 실제 대응 항목이 있는지 확인하거나, 해당 기능을 잃게 된다는 점을 명시적으로 문서화하여 수용하십시오. 위험한 것은 마이그레이션하지도 않았고, 그렇다고 의식적으로 버리지도 않은 파라미터입니다.

3. 응답을 가정하지 말고 단언(assert)하십시오. 마이그레이션 후에는 반환된 이미지의 개수(count)와 각 이미지의 크기(dimensions)가 요청한 내용과 일치하는지 확인하십시오. 두 가지 모두 조용히 달라질 수 있습니다. 세 줄의 단언(assertion)만으로도 이 게시물의 섹션 2와 3을 잡아낼 수 있습니다.

4. 출력 베이스라인(output baseline)을 재승인하십시오. 프롬프트 재작성(prompt rewriting) 기능은 사라졌고 기반 모델(underlying model)도 다릅니다. 당신의 제품에서 무엇이 "올바르게 보이는가"에 대한 기준이 무엇이었든, 6월 24일 이후가 아닌 그 이전에 실제 Gemini 출력물을 바탕으로 기준을 재정립하십시오.

모델 은퇴(retirement)는 요란한 부분이며, 요란한 부분은 처리될 것입니다. 마이그레이션은 조용한 부분입니다. 조용한 부분을 위해 계획하십시오.

FlareCanary는 모델 은퇴, 응답 형태 변경, 조용히 삭제된 파라미터와 같은 파괴적 변경 사항(breaking changes)을 감시하여 프로덕션(production)에 도달하기 전에 이를 알려줍니다. 무료 티어는 5개의 엔드포인트를 모니터링합니다.