지금 공식 Nano Banana API를 찾는다면, 찾아야 할 것은 별도의 Nano Banana 개발자 제품이 아닙니다. 실제로는 Gemini API 또는 Google AI Studio 안의 Gemini 네이티브 이미지 생성 모델입니다. 대부분의 API 워크로드에서 가장 안전한 기본값은 Nano Banana 2이며, 현재 공식 model ID는 gemini-3.1-flash-image-preview입니다. Nano Banana Pro(gemini-3-pro-image-preview)로 올려야 하는 경우는 text rendering, 더 복잡한 instruction following, 혹은 professional asset production 급 품질이 실제로 필요하다고 설명할 수 있을 때뿐입니다.
이 직접적인 답이 중요한 이유는, 이 query 주변에 잘못된 지름길이 너무 많기 때문입니다. 어떤 페이지는 Nano Banana를 독립 앱처럼 다루고, 어떤 페이지는 AI Mode를 API처럼 보이게 만들며, 어떤 페이지는 wrapper/gateway를 제품 자체처럼 소개합니다. 올바른 그림은 더 단순합니다. Nano Banana는 Gemini의 네이티브 이미지 모델 패밀리이고, 공식 개발자 경로는 Gemini API + AI Studio이며, 대부분의 팀이 먼저 시도해야 할 모델은 Nano Banana 2입니다.
아래의 model ID, 가격, consumer limits는 모두 2026년 3월 29일 기준으로 Google의 현행 docs, Help, Pricing을 다시 확인했습니다.
핵심 요약
가장 짧은 정답부터 보겠습니다.
| 실제로 풀고 싶은 일 | 여기서 시작 | 왜 이 경로가 최선인가 | 가장 큰 주의점 |
|---|---|---|---|
| 공식 Google 이미지 API를 쓰고 싶다 | Gemini API + Nano Banana 2 | 현재 Google의 고효율 기본 image generation / editing 경로이기 때문 | 현행 preview image API는 유료 계약 |
| 더 높은 fidelity, 강한 text rendering, 복잡한 visual reasoning이 필요하다 | Nano Banana Pro | premium professional tier이기 때문 | 더 비싸고, default가 아니라 override여야 함 |
| Google UI에서 먼저 프롬프트를 시험하고 싶다 | AI Studio | 같은 공식 스택을 UI로 검증하기 쉽다 | Google은 Nano Banana 2에 paid API key가 필요하다고 밝힘 |
| 그냥 소비자 제품 안에서 이미지를 만들고 싶다 | Gemini Apps / AI Mode | 코드 없이 일상적으로 쓰기 쉽다 | 이것은 consumer contract이지 API contract가 아님 |
| OpenAI 호환 호출이나 multi-vendor billing이 필요하다 | 선택적 gateway / wrapper | 인프라 목적이 분명하면 편리할 수 있다 | 하지만 이는 공식 경로 이해 뒤에 오는 두 번째 판단 |
가장 중요한 한 줄은 이것입니다. "Nano Banana API"는 Gemini API 질문으로 이해해야지, 하나의 Nano Banana 사이트를 찾는 문제로 보면 안 됩니다.
Nano Banana API는 지금 무엇을 뜻하나
Google의 현행 image-generation docs는 Nano Banana를 Gemini의 네이티브 이미지 생성 능력으로 정의하고 있으며, 하나의 surface로 보지 않습니다. API 관점에서 보면 현재는 다음 family를 생각하는 것이 정확합니다.
| 패밀리 이름 | 공식 model ID | 현재 역할 |
|---|---|---|
| Nano Banana 2 | gemini-3.1-flash-image-preview | 속도, throughput, 가격 균형이 좋은 default API 시작점 |
| Nano Banana Pro | gemini-3-pro-image-preview | 더 높은 fidelity와 text-heavy 작업을 위한 상위 tier |
| Nano Banana | gemini-2.5-flash-image | 이전 세대의 low-latency fast route |
많은 검색 결과가 아직도 여기서 미끄러집니다. query만 보면 하나의 "Nano Banana API" 제품, 하나의 account flow, 하나의 obvious model이 있을 것처럼 느껴집니다. 하지만 Google의 현재 설명 방식은 다릅니다. 지금 필요한 것은 family choice와 surface choice의 분리입니다.
- 패밀리 안에서 어떤 version이 필요한가
- 공식 API가 필요한가, 공식 testing UI가 필요한가, consumer surface가 필요한가
또 하나 중요한 점은 이미지 생성 자체가 Gemini의 일반적인 요청/응답 계약 안에 들어와 있다는 것입니다. 현행 docs에는 request shape, image editing, aspect ratio, image size, search grounding까지 포함되어 있습니다. Google은 또한 모든 generated images에 SynthID watermark가 포함된다고 명시합니다. provenance나 AI disclosure를 신경 쓰는 팀이라면 이 부분이 작지 않습니다.
더 넓은 현행 접근 가이드가 필요하다면 Nano Banana AI 이미지 생성 가이드를 보세요. 이 글은 거기서 한 단계 더 좁혀서, 공식 API로 어떻게 들어가야 하는지에만 집중합니다.
무엇이 공식 API 경로이고 무엇이 아닌가
가장 빨리 혼란스러워지는 방법은 Gemini Apps, AI Mode, AI Studio, Gemini API, wrapper를 모두 같은 상자에 넣는 것입니다. 서로 관련은 있지만, 같은 계약은 아닙니다.

Gemini API가 공식 programmatic path입니다. generateContent를 호출하고, prompt나 input image를 보내고, inline image output을 받고, aspect ratio와 image size를 제어해야 한다면 답은 여기입니다.
Google AI Studio는 같은 스택을 시험하는 공식 testing / development surface입니다. prompt를 먼저 돌려 보고, model behavior를 보고, 결과를 UI에서 확인한 뒤 코드로 옮기고 싶을 때 적합합니다. 여기서 중요한 것은 Google의 2026년 2월 26일 Nano Banana 2 rollout post로, AI Studio에서 Nano Banana 2를 쓰려면 paid API key가 필요하다고 명시한다는 점입니다. 즉, AI Studio는 공식 개발자 UI이지, 현행 preview-image pricing을 우회하는 무료 통로가 아닙니다.
Gemini Apps와 AI Mode는 실제 product surface이지만 소비자용 경로이며, API query의 직접적인 답은 아닙니다. Gemini Apps Help는 Nano Banana와 Nano Banana Pro의 everyday use와 advanced output 역할을 나눠 설명하고, AI Mode Help는 image limits와 Pro의 infographic / diagram 용도를 따로 설명합니다. 이런 정보는 사용자 선택에는 중요하지만, API 계약 자체를 바꾸지는 않습니다.
Wrapper / gateway는 별도의 infrastructure choice입니다. OpenAI-compatible requests, multi-vendor routing, 통합 billing처럼 명확한 인프라 이유가 있다면 가치가 있을 수 있습니다. 하지만 그것은 두 번째 판단이지 첫 번째 판단이 아닙니다.
가장 간단한 routing rule은 이렇습니다.
- 코드를 쓴다면 Gemini API
- 공식 UI에서 prompt를 시험하려면 AI Studio
- API가 아니라 consumer use를 풀고 있다면 Gemini Apps 또는 AI Mode
- gateway는 인프라 이유를 설명할 수 있을 때만
기본은 Nano Banana 2, Pro는 이유가 있을 때만 override
대부분의 독자에게 여기서의 판단이 가장 큰 가치입니다.
Google의 현행 image-generation docs는 Nano Banana 2를 Pro의 고효율 counterpart로 설명하며, speed와 high-volume developer use cases에 최적화된 모델이라고 합니다. Google의 2026년 2월 rollout post는 아예 Nano Banana 2를 **"our best image generation and editing model"**이라고 부릅니다. API 가이드로 읽으면 의미는 분명합니다. Pro가 더 premium하게 들린다는 이유만으로 default라고 가정하면 안 됩니다.

다음과 같은 경우 Nano Banana 2로 시작하는 것이 맞습니다.
- 첫 번째 integration을 만들고 있다
- iteration speed와 price efficiency가 중요하다
- 일정한 volume을 예상한다
- general image generation / editing을 위한 안전한 default가 필요하다
- 아직 Pro로 올려야 할 명확한 이유가 없다
다음과 같은 경우 Nano Banana Pro로 올리는 것이 맞습니다.
- text rendering quality가 결과의 핵심이다
- 이미지가 draft가 아니라 final asset이다
- complex visual instructions를 더 강한 reasoning으로 처리해야 한다
- diagram-heavy, layout-sensitive, brand-critical한 작업이다
그리고 Nano Banana(gemini-2.5-flash-image)도 여전히 자리가 있습니다.
- 이미 그 old fast route에 맞춰진 workload가 있다
- Nano Banana 2의 behavior보다 low latency가 더 중요하다
중요한 점은 이것이 단순한 quality ladder가 아니라는 것입니다. 이것은 workload fit 문제입니다. Nano Banana 2는 Pro의 "싸구려 버전"이 아니라, Google이 현행 docs 안에서 중심에 놓고 있는 default입니다. Pro는 premium override입니다. 이 판단 규칙이 wrapper 페이지에서 흔히 보이는 모호한 "더 좋은 퀄리티가 필요하면 Pro"보다 훨씬 실무적입니다.
더 깊은 workload-level 비교가 필요하다면 Nano Banana Pro vs Nano Banana 2 비교를 보세요. 이 글의 목적은 거기까지가 아니라, 올바른 시작점을 빠르게 정해 주는 것입니다.
Quickstart: 첫 번째 요청을 실행하기
공식 path는 많은 third-party tutorial이 보이게 만드는 것보다 훨씬 짧습니다.
1. Gemini API key를 만든다
먼저 Google AI Studio에서 key를 만듭니다. Google은 key creation 자체를 쉽게 해 두었지만, 그렇다고 image output 계약까지 무료라는 뜻은 아닙니다. 현행 preview-image pricing을 있는 그대로 읽으면 결론은 두 줄입니다.
- key를 만드는 것은 쉽다
- 현행 preview image models를 쓰는 것은 paid API path다
2. 현행 공식 SDK를 설치한다
Google의 libraries page는 현재 Google GenAI SDK를 권장 경로로 두고 있으며, 오래된 Gemini client libraries를 중심 경로로 두지 않습니다.
bashnpm install @google/genai # Python pip install -U google-genai
google-generativeai 기반의 오래된 예제를 보더라도, 그것은 history로 읽어야지 지금의 최적 경로로 읽어서는 안 됩니다.
3. 최소 image-generation request를 보낸다
새 integration이라면 먼저 Nano Banana 2를 쓰면 됩니다.
javascriptimport { GoogleGenAI } from "@google/genai"; import fs from "node:fs"; const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY }); const response = await ai.models.generateContent({ model: "gemini-3.1-flash-image-preview", contents: "Create a clean editorial illustration of a robot sketching a website wireframe.", config: { responseModalities: ["IMAGE"], imageConfig: { aspectRatio: "16:9", imageSize: "2K", }, }, }); for (const part of response.candidates[0].content.parts) { if (part.inlineData) { fs.writeFileSync("output.png", Buffer.from(part.inlineData.data, "base64")); } }
Python 버전도 논리는 같습니다.
pythonimport os from google import genai from google.genai import types client = genai.Client(api_key=os.environ["GEMINI_API_KEY"]) response = client.models.generate_content( model="gemini-3.1-flash-image-preview", contents="Create a clean editorial illustration of a robot sketching a website wireframe.", config=types.GenerateContentConfig( response_modalities=["IMAGE"], image_config=types.ImageConfig( aspect_ratio="16:9", image_size="2K", ), ), ) for part in response.parts: if part.inline_data is not None: part.as_image().save("output.png")
raw HTTP shape를 확인하고 싶다면, 공식 REST request도 매우 짧습니다.
bashcurl -X POST \ "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-image-preview:generateContent" \ -H "x-goog-api-key: ${GEMINI_API_KEY}" \ -H "Content-Type: application/json" \ -d '{ "contents": [{ "parts": [ {"text": "Create a clean editorial illustration of a robot sketching a website wireframe."} ] }], "generationConfig": { "responseModalities": ["IMAGE"], "imageConfig": { "aspectRatio": "16:9", "imageSize": "2K" } } }'
Pro로 바꾸는 방법이 "지루하게" 단순한 것은 오히려 장점입니다. request shape는 그대로 두고 model ID만 gemini-3-pro-image-preview로 바꾸면 되기 때문입니다. 그래서 "먼저 Nano Banana 2, 필요하면 Pro" workflow가 실제로 매우 실용적입니다.

Wrapper를 기준으로 설계하기 전에 알아야 할 공식 API의 강점
공식 Gemini route를 baseline으로 삼아야 하는 이유는 단순히 "공식이니까"가 아닙니다. 실제 capability가 wrapper landing page가 암시하는 것보다 넓기 때문입니다.
Image editing이 기본 지원됩니다. 현행 image-generation docs는 prompt-only generation뿐 아니라 text-and-image-to-image workflow도 보여 줍니다. 제품이 editing workflow를 필요로 한다면 중요한 차이입니다.
Aspect ratio와 image size를 명시적으로 제어할 수 있습니다. 공식 API는 imageConfig.aspectRatio를 지원하고, 현행 preview image models에 대해 0.5K부터 4K까지 image sizes를 Google이 문서화하고 있습니다. 즉, cost와 latency의 tradeoff를 여러분의 product 안에서 명확하게 설계할 수 있습니다.
Search grounding도 공식 stack 안에 있습니다. image-generation docs는 google_search tool을 image generation에 붙이는 현재 경로를 보여 줍니다. chart, weather visual, grounded infographic 같은 작업에 특히 유용합니다. 물론 이것이 "무료 마법"이라는 뜻은 아닙니다. pricing page는 shared free allowance 이후 search grounding을 별도 과금 레이어로 다룹니다.
SynthID도 플랫폼이 처리합니다. provenance, disclosure, AI-content labeling이 중요하다면 이 부분은 꽤 중요합니다. Google은 모든 generated images가 SynthID watermark를 포함한다고 밝힙니다.
처음부터 wrapper를 통해 Nano Banana를 이해하면 이런 장점이 쉽게 가려집니다. 하지만 실제로 비교해야 하는 기준은 바로 이 capability baseline입니다.
가격과 "무료"의 경계: 가장 많이 섞이는 부분
Nano Banana API에 대한 나쁜 조언은 대부분 여기서 무너집니다.
현행 Gemini Developer API pricing page는 두 preview image models에 모두 **Free Tier: Not available**라고 표시합니다. 2026년 3월 29일 기준 공식 가격은 다음과 같습니다.
| 모델 | Standard pricing | Batch pricing |
|---|---|---|
Nano Banana 2 (gemini-3.1-flash-image-preview) | \$0.045 / 0.5K, \$0.067 / 1K, \$0.101 / 2K, \$0.151 / 4K | \$0.022 / 0.5K, \$0.034 / 1K, \$0.050 / 2K, \$0.076 / 4K |
Nano Banana Pro (gemini-3-pro-image-preview) | \$0.134 / 1K-2K, \$0.24 / 4K | \$0.067 / 1K-2K, \$0.12 / 4K |
이 표를 기억하면 많은 검색 결과가 무엇을 섞고 있는지 바로 보입니다. 만약 어떤 페이지가 현행 Nano Banana preview-image API를 "free to start"처럼 말하면서도 계약 차이를 설명하지 않는다면, 거의 확실히 다음을 섞고 있습니다.
- free key creation
- AI Studio의 trial-like wording
- Gemini나 AI Mode의 consumer quotas
- 예전 혹은 다른 family의 free-tier story
이것들은 같은 계약이 아닙니다.
소비자용 표면에는 소비자용 규칙이 있습니다. Gemini Apps Help는 현재 Nano Banana 2의 image generation / editing에 대해 20 / 50 / 100 / 1000 images / day 구조를 no plan / Google AI Plus / Google AI Pro / Google AI Ultra 기준으로 보여 줍니다. AI Mode Help도 20 / 50 / 100 / 1000 images in a 24-hour period 구조를 제시하고, Nano Banana Pro in AI Mode is optimized for infographics and diagrams라고 따로 설명합니다. 이런 정보는 사용자 쪽 경로를 고를 때는 유용하지만, 현행 preview image API를 무료로 만들지는 않습니다.
관심사가 "Nano Banana API가 실제로 얼마인가"라면 Nano Banana 2 API 가격 가이드와 Gemini Image API 가이드 2026를 함께 읽는 편이 더 좋습니다. 이 글은 경로 선택과 도입을 먼저 해결합니다.
30초 결정 트리
가장 짧은 판단표만 원한다면 이렇습니다.
새로운 공식 연동을 만든다면 Gemini API + Nano Banana 2.
작업이 text rendering, visual fidelity, professional asset quality에 정말 의존한다면 Nano Banana Pro.
Google의 UI에서 먼저 prompts를 시험하고 싶다면 AI Studio.
API integration이 아니라 일반 사용자용 활용을 해결하는 것이라면 Gemini Apps 또는 AI Mode.
wrapper가 필요하다면 OpenAI 호환 라우팅 같은 인프라 이유를 먼저 말할 수 있을 때만.
이것이 지금 이 query에 대한 가장 깔끔하고 실행 가능한 답입니다.
FAQ
공식 Nano Banana API란 무엇인가요?
Gemini의 네이티브 이미지 패밀리가 Gemini API와 Google AI Studio를 통해 노출된 것이며, 별도의 Nano Banana 개발자 제품이 아닙니다.
어떤 모델부터 시작해야 하나요?
대부분은 gemini-3.1-flash-image-preview부터 시작하면 충분합니다. 더 비싼 Pro가 정말 필요하다는 것을 처음부터 알고 있는 경우만 예외입니다.
Nano Banana Pro의 공식 model ID는 무엇인가요?
gemini-3-pro-image-preview입니다.
Nano Banana API는 무료인가요?
현행 pricing page 기준 preview image models 자체에는 free tier image output이 없습니다. consumer quotas와 AI Mode usage는 별도 계약입니다.
AI Studio와 Gemini API 중 무엇을 써야 하나요?
둘 다 함께 쓰는 것이 가장 현실적입니다. AI Studio는 공식 prompt 검증용, Gemini API는 애플리케이션 통합용입니다.
AI Mode는 API의 일부인가요?
아니요. AI Mode는 Search의 consumer surface이며, 자체 image limits와 product behavior를 가집니다.
API는 image editing도 지원하나요?
네. Google의 image-generation docs는 image-to-image workflow를 공식 경로로 보여 줍니다.
생성된 이미지에는 watermark가 들어가나요?
네. Google은 generated images에 SynthID watermark가 포함된다고 설명합니다.
그래도 gateway가 필요하면 어떻게 하나요?
현재 공식 Gemini API는 많은 팀이 실제로 필요한 핵심 control points, 즉 model selection, image editing, aspect ratio, image size, search grounding을 이미 제공합니다. 그래도 부족할 때만 gateway를 명확한 infrastructure choice로 추가하는 것이 올바른 순서입니다.
