Nano Banana API 선택: Original, Nano Banana 2, Pro를 언제 써야 할까

API에서 Nano Banana 모델을 고를 때는 하나의 최강 모델을 찾기보다 요청을 어느 경로로 보낼지 정하는 편이 안전합니다. 새 이미지 생성의 기본값은 Nano Banana 2(gemini-3.1-flash-image-preview)입니다. 0.5K부터 4K까지 지원하고 Pro보다 저렴하며, 제품 이미지, 콘텐츠 이미지, 도움말용 시각 자료, 현지화 이미지 같은 대부분의 API 작업을 맡기기 좋습니다. Original Nano Banana(gemini-2.5-flash-image)는 단순하고 위험이 낮은 1024px급 이미지에 남겨 두고, Nano Banana Pro(gemini-3-pro-image-preview)는 텍스트, 도표, 촘촘한 레이아웃, 브랜드 자산, 최종 산출물에 사용합니다.

먼저 세 가지 경로를 분리합니다.

Standard라는 표현은 API 구현에서 모델 ID가 아닙니다. Google의 가격 모드를 말할 때는 쓸 수 있지만, 코드에서는 위 세 가지 모델 문자열 중 하나로 해결해야 합니다. 가격과 preview 상태는 2026년 4월 20일 Google AI 문서 기준으로 확인한 것입니다. 실제 프로젝트 quota, 계정 자격, rate limit, 사용 가능 여부는 현재 Google Console 또는 AI Studio에서 다시 확인해야 합니다.

세 경로는 같은 모델의 이름 차이가 아니다

Nano Banana는 이미지 모델 제품군처럼 쓰이지만, 운영 코드에서는 별칭만으로 라우팅할 수 없습니다. 필요한 것은 모델 ID, 출력 크기, 가격 경로, 전환 이유입니다. 막연히 “무엇이 더 좋은가”보다 “이 이미지가 실패하면 어떤 비용이 생기는가”를 먼저 보는 편이 제품 운영에 맞습니다.

Original Nano Banana는 저비용 기준선입니다. 내부용 플레이스홀더, 단순 썸네일, 기존 1K 워크로드, 다시 생성해도 부담이 작은 대량 초안에는 여전히 쓸모가 있습니다. 하지만 새 서비스의 기본값으로 두면 2K/4K, 텍스트 안정성, 복잡한 구성에서 한계가 빨리 드러납니다.

Nano Banana 2는 기본 경로입니다. 0.5K 미리보기부터 4K 출력까지 같은 모델 계열로 처리할 수 있어 SaaS 기능, 블로그 이미지, 상품 콘셉트, 도움말 이미지, 웹 그래픽, 현지화 시각 자료에 맞습니다. Pro보다 비용이 낮고 Original보다 범위가 넓기 때문에 새 API 흐름의 중심에 두기 좋습니다.

Nano Banana Pro는 프리미엄 승급 경로입니다. 모든 이미지를 비싸게 만들기 위한 모델이 아니라, 실패 비용이 큰 이미지를 줄이기 위한 모델입니다. 텍스트가 깨지면 안 되거나, 도표 구조가 중요하거나, 레이아웃이 엄격하거나, 브랜드 검수를 통과해야 한다면 Pro가 총비용 면에서 더 나을 수 있습니다.

가격은 해상도와 실패 비용을 함께 봐야 한다

1K 가격만 비교하면 결정을 잘못할 수 있습니다. Original은 1024px급에서 가장 저렴하고, Nano Banana 2는 0.5K부터 4K까지 가장 유연하며, Pro는 높은 책임을 지는 출력물에 맞는 고가 경로입니다. 해상도 지원은 부가 정보가 아니라 라우팅 조건입니다.

2026년 4월 20일 확인한 Google 가격 행은 다음과 같습니다.

저렴한 모델은 한 번에 통과할 때만 저렴합니다. 텍스트가 깨져 여러 번 다시 만들고 사람이 확인해야 한다면, 처음부터 Pro를 쓰는 편이 전체 비용을 낮출 수 있습니다. 반대로 내부 초안이나 작은 미리보기에 Pro를 쓰면 품질 차이를 활용하지 못하고 비용만 늘어납니다.

대량 작업은 지연 허용 여부도 봐야 합니다. 즉시 응답이 필요 없는 카탈로그 이미지, 야간 생성, 정기 콘텐츠 소재라면 Batch/Flex를 통해 고해상도 Nano Banana 2나 Pro도 더 부담 없이 사용할 수 있습니다. 실시간 사용자 경험은 Nano Banana 2를 중심으로 두고, Pro는 명확한 일부 요청만 가져가는 구조가 좋습니다.

Nano Banana 2를 기본값으로 두고 예외 두 개를 붙인다

가장 관리하기 쉬운 규칙은 “항상 최신 모델”이 아니라 “Nano Banana 2가 기본, Original은 저비용 예외, Pro는 고품질 예외”입니다. 이 방식은 제품 기본 동작을 단순하게 만들고 비용 설명도 쉬워집니다.

Nano Banana 2는 일반적인 제품 이미지 생성, 글에 들어가는 시각 자료, 앱 일러스트, 가벼운 소셜 이미지, 도움말용 그림, 현지화 이미지, 웹 그래픽에 적합합니다. 1K를 넘는 크기가 필요할 가능성이 있거나, 요청 종류가 자주 바뀌는 워크로드라면 기본값으로 더 자연스럽습니다.

Original로 내리는 조건은 좁게 둡니다. 출력이 단순하고, 1K면 충분하고, 중요한 텍스트가 없고, 실패해도 재생성하거나 버릴 수 있고, 비용이 최우선일 때만 사용합니다. 기존 저위험 배치 작업, 내부 플레이스홀더, 단순 썸네일이 여기에 해당합니다.

Pro로 올리는 조건은 이름 붙여 관리합니다. 읽을 수 있는 텍스트, 도표 구조, 다중 객체 배치, 브랜드 핵심 이미지, 광고, 문서용 그림, 고객 전달물, 최종 산출물 같은 트리거가 있으면 Pro를 고려합니다. Nano Banana 2가 특정 유형에서 반복적으로 실패한다면 그 유형만 Pro 승급 규칙으로 고정합니다.

운영 라우터는 먼저 요청을 분류해야 한다

API 레이어에서 모델 문자열을 바꾸는 것은 쉽지만, 분류 없는 전환은 비용과 품질을 설명하기 어렵습니다. 운영 라우터는 요청을 먼저 분류하고, 모델을 선택하고, 선택 이유에 맞게 결과를 검증해야 합니다.

실행 순서는 다음처럼 둘 수 있습니다.

1. 새 이미지 생성 트래픽은 Nano Banana 2에서 시작한다.
2. 텍스트, 도표, 레이아웃 제약, 최종 산출물, 브랜드 중요도가 있으면 생성 전 Pro로 올린다.
3. 단순하고 1K이며 저위험이고 비용 민감한 요청만 Original로 내린다.
4. 즉시성이 필요 없는 대량 작업은 Batch/Flex로 분리한다.
5. 선택 이유에 따라 결과를 검증한다. Pro는 텍스트와 구조, Nano Banana 2는 크기와 충분한 품질, Original은 저위험 1K 조건을 본다.

quota나 429는 모델 선택과 분리해야 합니다. 제한이 걸렸다고 더 비싼 모델로 보내면 비용 구조가 무너집니다. 모델 경로를 정한 뒤, 프로젝트 제한과 재시도 전략은 Gemini API rate limits guide에서 따로 설계하는 편이 안전합니다.

코드에서는 별칭이 아니라 모델 ID로 해결한다

안전한 구현은 내부 route 이름을 쓰고, 공식 모델 ID 매핑을 한 곳에 두는 것입니다. UI 문구, 가격 표시, 제공업체 별칭을 API client에 그대로 넘기면 안 됩니다.

python
from google import genai
from google.genai import types

client = genai.Client(api_key="GEMINI_API_KEY")

MODEL_BY_ROUTE = {
    "cheap_1k": "gemini-2.5-flash-image",
    "default": "gemini-3.1-flash-image-preview",
    "premium": "gemini-3-pro-image-preview",
}

def choose_image_route(job):
    if job.get("final_asset") or job.get("has_text") or job.get("diagram"):
        return "premium"
    if job.get("simple") and job.get("max_size") == "1k" and job.get("low_risk"):
        return "cheap_1k"
    return "default"

job = {
    "prompt": "Create a clean product release diagram with readable labels",
    "has_text": True,
    "diagram": True,
    "final_asset": False,
}

route = choose_image_route(job)
response = client.models.generate_content(
    model=MODEL_BY_ROUTE[route],
    contents=job["prompt"],
    config=types.GenerateContentConfig(response_modalities=["IMAGE"]),
)

모델별 설정은 route를 고른 뒤 적용해야 합니다. 특정 크기나 파라미터가 일부 모델에서만 지원된다면 fallback 경로 전체에 넘기지 않습니다. 로그에는 route, 공식 모델 ID, 요청 크기, 가격 경로, 승급 트리거, 검증 결과를 남겨야 합니다. 그래야 비용 설명, 지원 대응, 라우팅 조정이 모두 가능합니다.

기존 파이프라인은 언제 옮길까

Original Nano Banana를 쓰는 기존 파이프라인이 단순 이미지에서 잘 동작한다면, 새 모델이 나왔다고 즉시 옮길 필요는 없습니다. 실제 프롬프트로 작은 샘플을 돌리고, 승인률, 수동 수정 시간, 재시도 횟수, 총비용을 비교해야 합니다.

더 큰 이미지 크기, 더 강한 지시 따르기, 여러 작업을 처리하는 하나의 기본 경로가 필요해지면 Nano Banana 2로 단계적으로 옮깁니다. 작은 트래픽 비율에서 시작해 승인된 출력 비율과 수동 수정 시간을 비교한 뒤 default를 바꾸는 방식이 안전합니다.

Nano Banana 2가 특정 유형에서 반복적으로 실패하면 그 유형만 Pro로 올립니다. 텍스트 실패, 도표 구조 실패, 브랜드 검수 실패, 최종 산출물 수동 수정 과다, 복잡한 레이아웃 불안정 같은 이름 있는 트리거가 필요합니다. Nano Banana 2와 Pro만 깊게 비교할 때는 Nano Banana Pro vs Nano Banana 2 비교를 참고하면 됩니다.

자주 묻는 질문

새 API 통합의 기본값은 무엇이 좋을까?

Nano Banana 2, 즉 gemini-3.1-flash-image-preview가 가장 적합합니다. 기능, 지원 크기, 가격의 균형이 좋아 일반적인 이미지 생성 route로 두기 쉽습니다. Original은 저렴한 1K 예외, Pro는 고품질 예외로 추가합니다.

Nano Banana Pro는 언제 비용을 낼 만한가?

이미지에 읽을 수 있는 텍스트, 도표, 구조화된 레이아웃, 브랜드 핵심 요소, 고객용 자료, 최종 산출물이 있을 때입니다. 한 장의 실패가 검수나 수동 수정을 만들면 Pro가 전체 비용을 낮출 수 있습니다.

Original Nano Banana를 계속 써도 되나?

네. 다만 단순하고 저위험인 1024px급 출력으로 좁혀야 합니다. 기존 파이프라인, 내부 플레이스홀더, 대량 초안, 간단한 썸네일에는 유용하지만, 새 혼합 워크로드의 기본값으로는 적합하지 않습니다.

표의 가격은 계정 quota나 보장 조건인가?

아닙니다. 가격은 2026년 4월 20일 확인한 Google API 가격 행입니다. 프로젝트 quota, 계정 자격, rate limit, 사용 가능 여부는 계정과 결제 상태에 따라 달라질 수 있으므로 운영 전 현재 Google Console 또는 AI Studio에서 확인해야 합니다.

모델을 바꾸면 이미지 생성 파이프라인을 다시 써야 하나?

대부분은 아닙니다. 모델 선택, 프롬프트, 출력 크기, 검증 규칙이 분리되어 있다면 route와 모델 ID만 바꾸면 됩니다. 모델별 파라미터를 route 뒤에서 적용하면 Nano Banana 2나 Pro로 안전하게 전환할 수 있습니다.