메인 콘텐츠로 건너뛰기

모델 카드

전체 가격 비교, 요청당 과금과 token 기반 과금 비교, token 선택 관련 조언은 Nano Banana 시리즈 가격을 참고하십시오.

샘플 결과

아래 두 이미지는 모두 Nano Banana 2 Lite(gemini-3.1-flash-lite-image)로 생성한 텍스트-이미지 및 이미지 편집 결과입니다. 이 결과는 해당 모델과 프롬프트만을 보여 주며, 시리즈의 다른 모델에 대한 성능을 보장하지 않습니다. 텍스트-이미지 · 16:9 거리 풍경 (프롬프트만 사용: 비가 그친 뒤의 오래된 마을 골목, 젖은 판석에 비친 따뜻한 가로등, 우산을 쓰고 지나가는 사람, 16:9 구도): 8.3초, aspectRatio: 16:9이 적용되며 老茶馆, 客栈, 酒肆라고 적힌 간판이 모두 선명하게 보입니다.
Nano Banana 2 Lite 텍스트-이미지 샘플: 따뜻한 가로등과 선명한 중국어 상점 간판이 있는 16:9 비 내리는 오래된 마을 골목
이미지 편집 · 해 질 녘 조명으로 변경 및 간판 추가 (참조 이미지: 길가 카페; 프롬프트: 조명을 따뜻한 해 질 녘 색조로 바꾸고, 다른 모든 요소는 그대로 유지하면서 매장 위에 转角咖啡라고 적힌 중국어 간판 추가): 19.3초, 간판의 획이 선명하고 벽의 원근을 따르며, 조명에 따라 식물과 자전거의 그림자도 따뜻한 색조로 바뀝니다.
Nano Banana 2 Lite 편집 샘플: 转角咖啡라고 적힌 중국어 간판을 추가하고 해 질 녘 조명으로 바꾼 카페 외관

크기 제어

  • 원본 이미지 비율 따르기: aspectRatio를 생략하면 됩니다. 여러 이미지를 편집하는 경우 마지막 이미지의 크기가 우선 적용됩니다
  • 해상도 imageSize: 1K / 2K / 4K 지원
    • Nano Banana(1세대)는 1K만 지원
    • Nano Banana 2는 512px를 추가 지원
    • Nano Banana 2 Lite는 1K만 지원(2K/4K/512px는 지원하지 않음)
1세대 gemini-2.5-flash-image를 호출할 때 동일한 코드를 사용한다면 imageSize 매개변수를 반드시 제거해야 합니다(2K / 4K을 지원하지 않음). 그렇지 않으면 호출에 실패합니다.

통합 방법

공식 문서

  • Google 공식 문서: ai.google.dev/gemini-api/docs/image-generation
  • APIYI와 통합하려면 요청 URL + 키를 APIYI의 값으로 바꾸기만 하면 됩니다. 그 외의 모든 매개변수는 공식 문서와 동일합니다.

공식 상태 확인(업스트림 문제 진단)

Nano Banana 시리즈는 Google AIStudio / Gemini API를 기반으로 작동합니다. 드물게 2K / 4K 출력이 흐릿하거나 실패하는 문제가 통합 계층이 아니라 Google 측에서 발생할 수 있습니다. Google 공식 상태 페이지를 확인할 수 있습니다(직접 복사해 방문하세요): aistudio.google.com/status. 예를 들어, 2026년 6월 19일 해당 페이지에는 “Nano Banana 관련 문제”가 보고되었습니다. Gemini API 및 AI Studio의 Nano Banana 2 / Pro에서 2K 또는 4K 해상도 문제가 발생했습니다. 비슷한 증상이 나타나면 먼저 공식 상태 페이지와 비교해 업스트림 장애인지 신속하게 확인하세요.
APIYI는 이중화된 AIStudio + Vertex 채널을 통해 Nano Banana 시리즈를 제공합니다. 한 공식 채널에 문제가 발생하면 다른 채널이 대신 처리해 서비스를 계속 이용할 수 있습니다.

엔드포인트 지원

  • 권장 엔드포인트(Gemini 네이티브): https://api.apiyi.com/v1beta/models/gemini-3-pro-image:generateContent
  • OpenAI 호환 모드를 통한 호출을 지원합니다(/v1/chat/completions; Base64 또는 공개 링크를 image_url을 통해 전달하세요).
  • /v1/image/generations은(는) 지원하지 않습니다.

개발 형식(기본 권장 사항)

  • [권장] Google 네이티브 엔드포인트 형식을 사용하세요
  • 이미지: Base64로 업로드하고, 다운로드한 뒤 다시 호스팅하세요
  • 호출 방식: 동기식 멀티스레드 호출입니다. 비동기 호출은 아직 지원되지 않습니다.

입력 이미지 요구 사항

  • 단일 이미지는 7MB를 초과할 수 없습니다(Google의 규정입니다); Google Cloud Storage를 통해 가져오는 경우 파일당 제한은 30MB입니다
  • prompt당 최대 14개 이미지
  • 지원되는 MIME 유형: image/png, image/jpeg, image/webp, image/heic, image/heif (jpg 형식은 이미 APIYI에서 지원됩니다)
  • Base64 크기 증가: 이미지를 Base64로 변환하면 크기가 약 33.3% 증가합니다(7MB 이미지는 약 9.3MB가 됩니다)
  • APIYI 제한: 단일 요청에서 업로드되는 이미지의 총 용량은 100MB 미만이어야 합니다 — 모든 호출은 동기식이며, 너무 큰 페이로드는 메모리 급증을 일으킬 수 있습니다
Google Gemini 3 Pro Image 공식 기술 사양 표: 단일 이미지 제한 7MB, prompt당 최대 14개 이미지, 지원되는 종횡비 및 MIME 유형

Google official technical specs: inline / console upload per-file limit is 7MB, supporting png/jpeg/webp/heic/heif

Base64 크기 계산: 7MB 원본 이미지는 4/3 비율로 인코딩하면 약 9.33MB입니다

Base64 encoding increases size by about 33.3%: a 7MB image is roughly equal to 9.3MB

권장 사항: API로 전송하기 전에 이미지에 무손실 압축을 적용하여, 너무 큰 해상도로 인해 요청이 느려지는 것을 방지하십시오. Google 공식 사양 참고 자료(직접 복사하여 방문하십시오): docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-pro-image

URL 이미지 입력

Base64 외에도 Gemini 네이티브 엔드포인트는 fileData.fileUri를 통해 이미지 URL을 직접 전달받을 수 있습니다. 이를 통해 요청 본문 크기를 작게 유지할 수 있으며, 이미지를 직접 다운로드하고 인코딩할 필요가 없습니다. URL 입력 방식을 사용할 경우, APIYI가 아닌 Google 서버가 이미지를 다운로드합니다. 정상 작동 여부와 처리 속도는 사용자의 브라우저에서 링크가 열리는지가 아니라, Google이 이미지 호스트에 얼마나 원활하게 접근할 수 있는지에 따라 결정됩니다. 아래의 요구 사항과 문제 해결 단계는 실제 기술 지원 문의 및 자체 테스트(2026-10-16, NB2 / Pro, 3개 경로) 결과를 바탕으로 작성되었습니다.
가능한 한 Base64(inlineData) 방식을 사용하는 것을 권장합니다. 이미지를 직접 다운로드하여 요청 본문에 포함하므로 Google의 이미지 가져오기 작업에 영향을 받지 않습니다. 이는 가장 안정적인 방법입니다. URL 입력 방식은 요청 크기를 작게 유지하면서 이미지가 이미 중국 본토 외부의 글로벌 CDN에 호스팅되어 있는 경우에 적합합니다.

사용 가능한 링크의 요건

자체 테스트 결과 http:// 및 https:// 링크는 모두 정상 작동했습니다. gs://(Google Cloud Storage)는 일부 경로에서만 읽을 수 있으므로 APIYI를 통한 사용은 권장하지 않습니다.

요청 형식

  • 다중 이미지: 이미지당 하나의 fileData를 parts 내에 순서대로 전달합니다. inlineData와 혼합하여 사용할 수도 있으며, 테스트 결과 단일 요청에 URL 이미지 2개와 Base64 이미지 1개를 함께 전달해도 정상적으로 생성되었습니다.
  • mimeType: 이미지의 실제 형식으로 설정하십시오. 테스트 결과, 현재 라우트에서는 해당 값이 잘못되었거나 누락되어도 이미지를 계속 읽어왔으나, 이에 의존하지 마십시오.
  • 필드명: Google 공식 문서에 맞춰 camelCase 형태인 fileData / fileUri / mimeType를 사용하십시오. 현재는 snake_case 형태인 file_data / file_uri도 허용됩니다.

참조 이미지를 실제로 읽었는지 확인

일부 라우트는 가져오기에 실패해도 오류를 반환하지 않습니다: 200을 반환하고 평소처럼 이미지를 생성하며 과금하지만, 결과물에서는 이미지를 완전히 무시합니다. 따라서 상태 코드에만 의존하지 마십시오. 응답에서 usageMetadata.promptTokensDetails을 확인하십시오:
IMAGE 항목이 있다는 것은 이미지를 읽었음을 의미합니다(기본 설정 기준으로 Nano Banana 2에서는 이미지당 약 1120 tokens, Pro에서는 약 560 tokens로 측정되었습니다). TEXT만 있는 경우 Google이 이미지를 가져오지 못한 것이며, 결과물에도 해당 이미지가 반영되지 않습니다. 아래 Python 예제에 이 확인 과정이 포함되어 있습니다.

가져오기 실패가 나타나는 형태

동일한 링크를 재시도했을 때 속도가 빨라졌다고 해서 문제가 해결된 것은 아닙니다. Google은 한 번 가져온 이미지를 캐시하므로 동일한 URL에 대한 두 번째 요청은 캐시 적중이 발생하는 경우가 많지만, 새로 업로드한 이미지는 다시 시간 초과가 발생합니다. 테스트할 때는 임의의 쿼리 파라미터(예: ?v=<random>)를 추가하여 캐시를 우회하고 실제 가져오기 속도를 측정하십시오.
시간 초과에 대한 전체 사례 분석은 이미지 편집에서 Unable to Process Input Image가 반환되나요? 문서를 참고하시기 바랍니다. 해당 문서에서는 이와 자주 혼동되는 빈 Base64 오류에 대해서도 함께 다룹니다.

Curl 예시 (fileUri)

Python 예제 (fileUri)

OpenAI 호환 엔드포인트에 URL을 전달할 수 있습니까?

네, 가능합니다. /v1/chat/completions에서 공개 링크를 image_url(으)로 전달할 수 있으며, 테스트 결과 Nano Banana 2와 Pro 모두 이미지를 정상적으로 읽고 생성했습니다. 동일한 링크 요구사항이 적용됩니다. 멀티턴 편집이나 정밀한 해상도 제어를 위해서는 여전히 네이티브 엔드포인트를 사용하는 것을 권장합니다.

청구 기본 사항 (중요)

  • 동기 호출 지속 시간: Pro / 2 at 4K는 대략 30–150초의 적절한 생성 시간이 걸립니다
  • 타임아웃 시 연결이 끊겨도 요금이 부과됩니다: 예를 들어 생성에 120초가 걸리지만 클라이언트가 타임아웃을 100초로 설정해 연결을 끊더라도, 요금은 계속 부과됩니다
  • 429 / 503은 과금되지 않습니다: 실패한 요청은 청구되지 않습니다(저희는 고객이 오래 기다리거나 이미지 없이 멈춰 있게 두지 않으려 합니다)
  • 콘텐츠 안전 거부도 요금이 부과됩니다: 고객의 입력에 콘텐츠 안전 문제가 있어 Google이 이미지 생성을 거부하는 경우에도, 상태 코드 200은 과금됩니다 — 아래의 오류 처리와 보장 플랜을 참조하십시오

Google 검색 그라운딩은 호출당 가격에 추가로 청구됩니다

Pro는 googleSearch 도구를 지원합니다(3/3번의 테스트 실행에서 grounding이 트리거되어 전체 groundingMetadata을 반환함). 날씨 카드, 주가 차트, 그리고 실시간 정보가 필요한 그 밖의 모든 용도에 유용합니다. 하지만 검색 호출 요금은 $0.09 호출당 가격에 포함되지 않고 별도로 추가됩니다:
모델이 실행할 검색 횟수를 결정하며, 미리 설정할 수는 없습니다. 테스트에서는 단일 이미지 요청이 자체적으로 1–3개의 쿼리를 실행했으므로, 이 도구를 활성화하면 호출당 비용이 고정된 $0.09가 아니라 범위($0.104–$0.132)가 됩니다. 상한을 기준으로 예산을 잡으십시오.
이미지 검색 그라운딩 (searchTypes.imageSearch)은 Pro에서 작동하지 않습니다 — 0/2회 실행에서 트리거되지 않았고, imageSearchQueries은 groundingMetadata에 한 번도 나타나지 않았습니다. 이는 Nano Banana 2 (gemini-3.1-flash-image) 전용입니다. Nano Banana 2 · 과금에 영향을 주는 세 가지 매개변수를 참조하십시오.

thinkingLevel은 Pro에서 효과가 없습니다 — NB2에서 그대로 복사하지 마십시오

generationConfig.thinkingConfig.thinkingLevel는 Nano Banana 2 시리즈 전용입니다. high을 Pro에 전달하면:
  • 오류가 발생하지 않습니다 — 요청은 정상적으로 200을 반환합니다
  • 하지만 효과가 없습니다: 측정된 thoughtsTokenCount는 108–156 범위였으며, 파라미터 없이 관측된 130–159 범위와 완전히 겹쳤습니다
  • Google의 문서에서도 설명하듯 Pro의 추론은 항상 활성화되어 있으며 조정할 수 없습니다
게다가 Pro는 호출당 정액 요금이 적용되므로 추론은 청구서에 반영되지 않습니다 — Pro에서 이 파라미터를 조정해도 효과도 없고 비용상의 근거도 없습니다. 추론 오버헤드를 제어하려면 대신 Nano Banana 2의 종량제 과금을 사용하십시오.

타임아웃 설정 (중요)

4K 이미지 생성은 이미지 업로드, API 처리, Base64 이미지 다운로드와 같은 단계를 포함하므로 전체 소요 시간이 더 깁니다(백엔드는 API 처리 시간 기준으로 과금합니다). 일반적인 경우 4K는 약 50초(폴링 제외)가 걸리지만, 클라이언트가 타임아웃을 너무 짧게 설정하면 생성이 완료되기 전에 조기에 연결이 끊기고 오류를 보고합니다:
호출 로그: gemini-3-pro 4K 생성의 첫 바이트까지 걸리는 시간은 43초에서 61초입니다

Call logs: time-to-first-byte for 4K generation is about 43–61s, so the default 120s timeout is too tight

더 안전하게 하려면 해상도별로 타임아웃을 설정하는 것을 권장합니다:

다중 턴 대화형 편집(네이티브 방식은 지원하지만 역방향 모델은 지원하지 않음)

Nano Banana 시리즈는 Gemini 네이티브 형식을 사용하며 실제 대화형 다중 턴 편집을 지원합니다. 각 턴에서 생성된 이미지를 contents에 **role: "model" inlineData**로 다시 추가한 다음, 다음 사용자 지시를 보냅니다. 모델은 전체 대화 기록을 기반으로 편집하고 변경 사항을 누적합니다(예: 먼저 소파의 색을 바꾼 다음 액세서리를 추가하면 이전 변경 사항이 유지됩니다). 이는 역방향 이미지 모델과 근본적으로 다르므로 통합하기 전에 이 점을 명확히 이해해야 합니다.
테스트 결과: 이전 이미지를 model 역할의 턴으로 다시 추가하면 Nano Banana 2(gemini-3.1-flash-image)가 편집을 이어 가면서 변경 사항을 올바르게 누적합니다. 역방향 모델은 마지막 사용자 메시지의 참조 이미지만 읽으므로, 대화 기록을 유지해도 다중 턴 편집은 작동하지 않습니다.
최소 예시(각 출력을 동일한 contents에 다시 추가):
자세한 내용(기록에 추가하는 방식과 다시 입력하는 방식 비교, 기존 이미지에서 다중 턴 편집 시작하기)은 이미지 편집 API · 다중 턴 대화형 편집을 참조하세요.

이미지를 얻으려면 항상 parts를 순회하십시오 — 절대로 인덱스로 접근하지 마십시오

parts는 이질적 배열입니다. 이미지 세그먼트만 담을 수도 있고, 텍스트와 이미지 세그먼트가 섞여 있을 수도 있으며, 길이도 순서도 보장되지 않습니다. 따라서 parts[0] / parts[1] 같은 하드코딩된 접근은 간헐적으로 실패할 수밖에 없습니다. 테스트에서 다음 세 가지 레이아웃이 관찰되었습니다. 텍스트 세그먼트는 한 가지가 아닌 여러 이유로 생길 수 있습니다. TEXT를 responseModalities에 포함하는 경우도 그렇고, 모델이 스스로를 설명하도록 요청하는 prompt도 그렇습니다. 이 경우 모델은 이미지와 함께 텍스트를 반환하며, 그 텍스트가 이미지 앞에 올지 뒤에 올지도 역시 고정되어 있지 않습니다. 따라서 이미지가 놓이는 인덱스는 상수가 아닙니다, 그리고 같은 code라도 요청마다 서로 다른 구조를 받을 수 있습니다.
두 개의 하드코딩된 인덱스 패턴은 상보적입니다. 이미지는 항상 [0] 또는 [1] 중 한 곳에 놓이므로, 무엇을 선택하든 일부 요청에서는 이미지가 없는 응답을 받게 됩니다. [0]와 [1]를 번갈아 쓰는 것은 아무것도 해결하지 못합니다 — 필드 형태로 선택하는 방법만이 안정적입니다.
올바른 방법은 위치가 아니라 필드 형태로 선택하는 것입니다. 마지막 inlineData를 취해야 하며 첫 번째가 아닙니다 — 복잡한 작업은 여러 이미지를 반환하고, 마지막 것이 최종 버전입니다(다음 섹션 참조):
하드닝: responseModalities: ["IMAGE"]를 generationConfig에 선언하면 이미지만 원한다는 뜻이 되어 추가 텍스트 세그먼트가 줄어듭니다.이는 하드닝이지 대체가 아닙니다 — 필터링이 먼저여야 합니다. 역방향은 성립하지 않습니다: ["TEXT","IMAGE"]를 전달해도 텍스트 세그먼트가 보장되지는 않으며, 모델은 여전히 이미지만 반환할 수 있습니다.
mimeType도 하드코딩하지 마십시오. 응답의 이미지 형식은 일정하지 않으며 — image/png와 image/jpeg가 모두 나타납니다. 고정된 .png 확장자로 파일을 쓰면 확장자가 내용과 어긋나는 파일이 생성됩니다 — 항상 응답의 mimeType가 확장자를 결정하게 하십시오.

응답에 가끔 여러 이미지가 포함되는 이유

gemini-3-pro-image를 호출할 때, 가끔 **하나의 응답에 여러 이미지 파트(테스트에서는 2–10개 관찰)**가 포함되는 것을 볼 수 있으며, 이는 로그에 간헐적으로 나타나는 6000+ (심지어 5자리 수) output-token 항목과 일치합니다. 이는 이상 현상이 아닙니다. Google 공식 문서에 따르면 Gemini 3 이미지 모델은 기본적으로 “Thinking”이 활성화되어 있으며(API에서 비활성화할 수 없습니다), 모델은 구도와 로직을 시험하기 위해 중간 이미지를 생성하고, 이러한 초안은 최종 버전과 함께 parts에 나타나며, “Thinking 내의 마지막 이미지가 최종 렌더링 이미지이기도 합니다”(공식 문서: ai.google.dev/gemini-api/docs/image-generation). 2026년 7월에 수행한 테스트에 따르면(Google 네이티브 generateContent 형식): 트리거는 prompt의 작업 복잡도이지, “이미지 편집” 그 자체가 아닙니다. 여러 이미지는 여전히 단일 후보 안에 있으며(여러 후보가 아님), 각 이미지는 완전한 이미지입니다. 즉, 같은 디자인(같은 구도, 약간 다른 세부 사항)에 대한 Thinking 과정의 연속 초안이며, 마지막 파트가 최종 버전입니다. 이러한 초안은 thoughtSignature 필드를 가진 일반적인 이미지 파트로 반환되며, thought: true 플래그는 없습니다. Google 문서에는 Thinking이 최대 두 개의 중간 이미지만 생성한다고 되어 있지만, 복잡한 작업에서는 최대 10개까지 관찰되었습니다. 과금 영향: 각 이미지는 고정 token 수로 과금됩니다(1K/2K 해상도에서는 이미지당 1120 token, 4K에서는 2000 token). 따라서 output tokens는 이미지 수에 따라 엄밀히 선형적으로 증가합니다. 로그에 간헐적으로 보이는 6000+ (극단적인 경우 약 13.5k까지) output-token 항목은 단순히 4–10장 이미지 응답일 뿐이며, 과금 이상이 아닙니다. 권장 후속 코드:
  • 항상 parts를 순회하십시오 — 응답당 이미지 1개라고 가정하지 마십시오. 이미지별 카운팅이나 저장 로직은 반드시 실제 part 수를 기준으로 해야 합니다
  • 하나만 필요할 때는 마지막 이미지를 사용하십시오: 앞선 초안들은 세부 사항이 완성되지 않았고 품질도 약간 낮으므로, 첫 번째 이미지를 선택하지 마십시오
  • prompt를 통해 이미지 수를 제어하는 것은 대체로 효과가 없습니다(테스트에서는 “이미지 하나만 출력해 주세요” 지시가 무시되었습니다) — 코드에서 처리하십시오
  • 여러 이미지 응답은 35–142초가 걸립니다(1K 해상도 기준이며, 이미지 수가 많을수록 더 길어짐). 단일 이미지 응답보다 눈에 띄게 더 오래 걸리므로, 위의 timeout 권장값(5분 이상)을 유지하십시오
usageMetadata 필드의 전체 내역(세부 정보와 합계 사이의 차이, 거부 응답에서의 카운팅 특이점 등)에 대한 자세한 설명은 Usage 필드 및 출력 설명을 참조하십시오.

자주 묻는 질문

오류 처리 가이드

실패한 생성, 콘텐츠 모더레이션 정책, 친화적인 prompt 전략을 진단하는 데 필요한 세 가지 핵심 지표입니다

꼭 읽어야 하는 일반 개발 질문

실패한 생성 문제 해결과 일반적인 질문을 다룹니다

실패한 생성 보장 플랜

입력으로 인해 발생하지 않은 실패의 경우, 실패한 요청 수에 따라 크레딧이 환불됩니다
전체 오류는 다음과 같습니다:
이는 대개 크기가 너무 큰 이미지 업로드로 인해 발생합니다 — 요청 본문이 너무 커져 연결이 끊어집니다. 다음 모범 사례를 따르십시오:
  • 이미지 수를 제한합니다: 공식 규칙 범위 내에서 유지하십시오(프롬프트당 최대 14장 — 위의 공식 사양을 참조하십시오).
  • 이미지별 크기를 제한합니다: 각 이미지를 5MB 미만으로 유지하십시오 — 공식 이미지별 상한은 7MB이며, base64 인코딩은 크기를 대략 1/3 정도 늘리므로 여유를 두십시오.
  • 업로드 전에 프런트엔드에서 압축합니다: 이미지를 API로 보내기 전에 프런트엔드(또는 서버 측 릴레이)에서 압축하십시오 — 일반적인 방식은 긴 변을 제한하고, JPEG/WebP로 변환하며, quality 매개변수를 조정하는 것입니다.
  • URL 입력으로 전환합니다: Gemini 네이티브 형식은 fileData.fileUri를 통해 이미지 URL 전달을 지원하므로, 과도하게 큰 base64 요청 본문을 완전히 피할 수 있습니다 — 위의 URL Image Input을 참조하십시오.

활용 사례

  • AI 채팅 클라이언트: Cherry Studio 같은 클라이언트는 APIYI를 통해 직접 이미지 생성하도록 설정할 수 있습니다
  • 생성 테스트: 챗 클라이언트나 콘솔에서 모델 성능을 빠르게 검증합니다

고급 요구사항

  • URL을 통해 이미지를 업로드하고 싶으신가요? Gemini 네이티브 엔드포인트에서는 fileData.fileUri을(를), OpenAI 호환 엔드포인트에서는 image_url을(를) 사용하십시오. Google 서버가 이미지를 직접 다운로드하므로 호스트 환경이 중요합니다. 링크 요구사항, 가져오기 실패 감지 방법 및 코드 예제는 위의 URL 이미지 입력을 참조하십시오.
  • (Base64 대신) 다운로드 URL을 직접 받고 싶으신가요? NB-OSS 그룹을 사용하십시오 — Nano Banana OSS 그룹을 참조하십시오.