구글이 오늘 Imagen 4 엔드포인트 셋을 껐다

오늘 구글의 이미지 생성 엔드포인트 세 개가 응답을 멈춘다. imagen-4.0-generate-001, imagen-4.0-fast-generate-001, imagen-4.0-ultra-generate-001. 표준·빠름·울트라 라인이 한꺼번이다. 같은 정리가 Vertex 계열에서는 6월 30일에 이미 끝났고 오늘은 Gemini Developer API 차례다.

갈아탈 모델은 준비돼 있다. Gemini 3.1 Flash Image, 흔히 나노 바나나 2로 불리는 그 모델이다. 품질도 올라간다. 그런데 구글 마이그레이션 문서의 첫 줄은 품질 얘기가 아니다. generate_images() 메서드가 통째로 사라진다는 안내다.

한눈에 보기

모델 교체가 아니라 인터페이스 교체다

보통 모델이 바뀌면 문자열 하나를 고친다. 옛 모델 ID를 지우고 새 이름을 넣으면 끝난다. 이번은 다르다. 이미지 생성이 generate_content() 안으로 들어갔다. 텍스트를 부를 때 쓰던 바로 그 호출이다.

부르는 함수가 달라지면 요청 모양이 달라지고 응답 모양도 따라 달라진다. 프롬프트를 어디에 담는지, 몇 장을 달라고 어떻게 말하는지, 돌아온 바이트를 어느 필드에서 꺼내는지가 전부 새 규격이다. 래퍼 한 겹을 두고 그 안에서만 이미지 API를 부르는 코드라면 고칠 자리가 한 군데다. 호출이 라우트 여기저기 흩어져 있으면 오늘 하루는 그 자리를 세는 데 쓴다.

더 곤란한 쪽은 실패하는 방식이다. 값이 오르거나 화질이 내려가는 식으로 조용히 나빠지지 않는다. 없는 모델을 부르면 요청이 그냥 거절된다. 사용자 눈에는 이미지가 안 뜨는 빈 화면으로 보인다.

종료 공지가 자동화 시대에 비싸진 이유

몇 해 전만 해도 이미지 생성은 사람이 대시보드에서 버튼을 누르는 일이었다. 안 되면 그 자리에서 안다. 지금은 다르다. 상품이 등록될 때, 블로그 초안이 나올 때, 광고 소재를 A/B로 돌릴 때 백그라운드 잡이 알아서 부른다.

사람이 안 보는 경로일수록 깨진 사실을 늦게 안다. 새벽에 도는 소재 생성기가 오늘부터 빈 결과를 뱉기 시작하면 그 사실은 광고 성과가 이상해진 다음 주에나 드러난다. 자동화의 이득은 사람 손이 빠지는 데서 오고 자동화의 위험도 같은 자리에서 온다.

구글은 이 일정을 모델 문서와 릴리스 노트에 몇 달 전부터 적어 뒀다. 놓친 쪽은 규모가 작아서가 아니라 공지를 읽는 습관이 없어서 놓쳤다. 쓰는 API가 다섯 개면 릴리스 노트도 다섯 개다. 그걸 매주 훑는 30분이 오늘 같은 날을 사고에서 작업으로 바꾼다.

오늘 확인할 자리는 세 곳이다

첫째, 코드에서 imagen-4.0 문자열을 전부 찾는다. 파이썬 파일뿐 아니라 환경 변수, 설정 JSON, 노코드 도구의 HTTP 노드 안까지 본다. 자동화 도구에 모델 이름을 손으로 적어 둔 경우가 코드에 박아 둔 경우보다 찾기 어렵다. Make나 n8n 시나리오 안에 들어간 모델 ID는 검색이 안 되는 자리라 하나씩 열어야 나온다.

둘째, 실패했을 때 무슨 일이 벌어지는지 본다. 이미지 생성이 실패하면 게시가 멈추는가, 아니면 이미지 없이 그대로 나가는가. 후자면 오늘부터 이미지 없는 상품 페이지와 이미지 없는 광고 소재가 조용히 쌓인다.

셋째, 지난 사흘치 로그에서 이미지 생성 성공 건수를 센다. 평소 하루 몇 건인지 모르면 0건이 된 날에도 모른다. 기준선 하나를 적어 두는 데 5분이면 된다.

옮기는 작업 자체는 크지 않다. 프롬프트를 콘텐츠 배열에 담고 응답에서 이미지 파트를 찾아 바이트를 꺼내면 된다. 다만 옛 전용 메서드에 있던 인자들이 그대로 대응되지는 않는다. 장수, 화면비, 안전 필터 수위 같은 옵션을 어디에 어떻게 넣는지가 새 규격을 따르니 마이그레이션 문서에서 하나씩 대조해야 한다. 소재 변형을 여러 장씩 굽던 파이프라인이면 호출 수와 값이 같이 달라질 수 있어 옮긴 다음 하루치를 실제로 재 보는 편이 낫다.

anyAX 관점

써 보는 것과 박아 두는 것의 차이가 오늘 청구된다. 지난달에 이미지 API를 한 번 만져 봤다면 오늘 아무 일도 없다. 상품 페이지 배너를 매일 자동으로 굽도록 박아 뒀다면 오늘부터 배너가 없다. 도구를 워크플로에 박는 순간 그 도구의 종료 일정이 내 운영 일정으로 넘어온다.

그래서 붙일 때 같이 만들어 둘 게 두 가지다. 하나는 외부 모델을 부르는 자리를 한 파일로 모으는 일이다. generate_images() 가 generate_content() 로 바뀌는 정도의 변경은 앞으로도 계속 온다. 6월 30일 Vertex, 8월 17일 Gemini API. 이런 날짜가 분기마다 하나씩 붙는다. 모아 두면 반나절이고 흩어 두면 사흘이다.

다른 하나는 결과가 비었을 때 시끄럽게 구는 코드다. 이미지 생성 실패를 예외로 던지지 않고 빈 값으로 넘기는 구현이 의외로 많다. 사람이 화면을 보고 있던 시절에는 그게 친절이었다. 새벽 세 시에 크론이 도는 지금은 그게 침묵이다. 실패 카운터 하나와 문자 한 통이면 오늘 오전에 알았을 일이다.

이 두 가지를 갖춘 팀과 안 갖춘 팀의 차이는 오늘 하루로 끝나지 않는다. 지난 두 달만 봐도 값을 시간대로 나눈 벤더가 있었고 컨텍스트 길이로 요율을 꺾은 벤더가 있었고 오늘은 엔드포인트를 없앤 벤더가 있다. 셋 다 예고돼 있었고 셋 다 문서에 적혀 있었다. 자동화를 깊이 붙일수록 읽어야 할 문서가 늘고 그 읽기가 운영 업무로 편입된다. 혼자 일하는 사람에게 이건 새 부담이 아니라 새 직무다.

마지막으로 이번 종료는 값 인상이 아니라 라인업 정리다. 세 종을 없애고 이미지 모델 하나로 합쳤다. 벤더가 선택지를 줄이면 고르는 일은 쉬워지고 떠나는 일은 어려워진다. 이미지가 제품의 곁가지면 그대로 따라가는 게 싸다. 이미지가 제품 자체라면 오픈웨이트 이미지 모델 한 종을 서버리스 GPU에 얹어 두는 값이 보험료로 비싸지 않다. 오늘 같은 날짜가 다음에 또 온다는 것만 확실하다.

참고

• Gemini API의 Imagen 모델 문서와 지원 종료 일정 (Google AI for Developers)
• Imagen에서 Gemini 이미지 모델로 옮길 때 바뀌는 호출 규격 (Firebase AI Logic)
• Gemini API 변경 이력과 모델 종료 공지 (Google AI for Developers)