Nano Banana Pro는 Gemini 3 Pro Image Preview 모델입니다. Gemini API에서는 gemini-3-pro-image-preview, Gemini 앱에서는 “이미지 생성 → Thinking”이 해당됩니다.
핵심은 닉네임은 UI에, model ID는 코드에 있다는 점입니다. 이미지 생성 문서에는 Nano Banana 계열과 모델 ID 매핑이 있지만, 검색 결과는 대부분 이를 앞에 두지 않습니다.
2026년 3월 28일 기준 공식 매핑은 다음과 같습니다.
| Nano Banana 명칭 | 공식 모델명 | API model ID | 주로 보이는 곳 |
|---|---|---|---|
| Nano Banana Pro | Gemini 3 Pro Image Preview | gemini-3-pro-image-preview | Gemini 앱(Thinking), AI Studio, Gemini API, Vertex AI |
| Nano Banana 2 | Gemini 3.1 Flash Image Preview | gemini-3.1-flash-image-preview | 앱 기본 이미지 레인, AI Studio, Gemini API |
| Nano Banana | Gemini 2.5 Flash Image | gemini-2.5-flash-image | 기존 빠른 레인, API fallback |
품질과 텍스트 정확도가 중요하면 Nano Banana Pro, 속도와 대량 생성이 우선이면 Nano Banana 2가 적합합니다. 비교는 Gemini 3.1 Flash Image Preview vs Gemini 3 Pro Image Preview을 참고하세요.
핵심 요약
- Nano Banana Pro = Gemini 3 Pro Image Preview, API에서는
gemini-3-pro-image-preview. - 앱 경로: 이미지 생성 → Thinking.
- AI Studio: Gemini 3 Pro Image Preview 선택.
- 속도 우선: Nano Banana 2 (Gemini 3.1 Flash Image Preview).
| 궁금한 점 | 첫 단계 | 이유 |
|---|---|---|
| “Nano Banana Pro가 뭔가요?” | Gemini 3 Pro Image Preview로 이해 | 공식 문서 모델명 |
| “API ID는?” | gemini-3-pro-image-preview | 공식 ID |
| “앱에서 어디?” | 이미지 생성 → Thinking | UI는 닉네임 표시 |
한 줄 요약: 닉네임은 UI, model ID는 코드입니다. 헷갈리면 gemini-3-pro-image-preview를 쓰세요.
왜 닉네임이 있고 model ID가 중요한가
Google은 사용자용 화면에 친숙한 이름을 쓰고, 개발 문서는 model ID를 기준으로 합니다. Gemini API 설명은 Nano Banana를 네이티브 이미지 생성으로 정의하고 각 닉네임을 모델에 연결합니다. 따라서 앱에서 Nano Banana Pro가 보여도 코드에서는 gemini-3-pro-image-preview가 정답입니다.
UI와 API를 함께 쓰는 팀이라면 model ID를 기준으로 합의해 두는 것이 안전합니다.
내부 문서에는 “Nano Banana Pro (Gemini 3 Pro Image Preview / gemini-3-pro-image-preview)”처럼 병기하세요.
흔한 명칭 오류와 해결
“Gemini 3 Pro”와 “Gemini 3 Pro Image Preview”를 혼동하는 경우가 많습니다. 전자는 텍스트 모델, 후자는 이미지 모델입니다.
또 다른 오류는 중개 플랫폼의 별칭을 그대로 쓰는 것입니다. 네이티브 API는 gemini-3-pro-image-preview를 요구합니다.
“Preview”를 빼는 것도 위험합니다. 공식적으로는 여전히 preview이므로 이름과 공개 범위가 바뀔 수 있습니다.
그리고 Pro는 가장 빠른 레인이 아닙니다. 실시간 또는 대량 생성이라면 Nano Banana 2를 기본으로 두고, 고품질이 필요한 작업만 Pro를 쓰세요.
Nano Banana Pro가 보이는 곳 (앱 / AI Studio / API)
Nano Banana Pro는 사용자용, 개발자용, 엔터프라이즈 채널에 걸쳐 나타나며 표시명이 다릅니다. 표시명과 실제 선택 동작을 연결하는 것이 핵심입니다.
- Gemini 앱: 이미지 생성 → Thinking에서 Nano Banana Pro 표시
- Google AI Studio: Gemini 3 Pro Image Preview가 모델 리스트에 표시
- Gemini API / Vertex AI:
gemini-3-pro-image-preview사용
무료 플랜이나 지역에 따라 UI가 자동으로 더 빠른 레인으로 돌아갈 수 있습니다. 생성 전에 표시 라벨을 확인하고, 최종 판단은 model ID 기준으로 하는 것이 안전합니다.
공식 발표는 플랜/지역에 따라 이용 가능 여부가 다를 수 있다고 말합니다. UI에서 안 보이면 rollout 이슈일 가능성이 큽니다.
앱에서 안 보이더라도 AI Studio나 API에서 먼저 확인해 보면 롤아웃 상태를 빠르게 파악할 수 있습니다.
기업 환경에서도 model ID는 동일하므로 한 번 합의하면 환경 간 재사용이 가능합니다.
UI 표시명은 제품이나 플랜에 따라 바뀔 수 있지만 model ID는 계약 기준입니다. 이 기준을 고정하면 혼란이 줄어듭니다.
| 표면 | 표시명 | 선택해야 할 것 |
|---|---|---|
| Gemini 앱 | Nano Banana Pro(닉네임) | 이미지 생성 → Thinking |
| Google AI Studio | Gemini 3 Pro Image Preview | 모델명 선택 |
| Gemini API / Vertex AI | gemini-3-pro-image-preview | 요청에 ID 지정 |
이 표를 기억하면 UI 명칭을 곧바로 model ID로 변환할 수 있습니다.
검증은 AI Studio가 빠르고, 실제 운영은 Gemini API가 기준입니다.
UI 표시명은 힌트일 뿐이므로 최종 판단은 model ID 기준으로 하세요.
가격은 Gemini 3 Pro Image Preview Pricing, 제한은 Gemini 3 Pro Image Preview Rate Limit을 참고하세요.
공식 명칭을 직접 확인하는 방법
의심이 들면 1차 자료로 돌아가세요.
이 내용이 바뀌면 명칭 또는 가용성 변화의 신호입니다.
변경을 발견하면 내부 매핑 표와 온보딩 문서를 즉시 업데이트하세요. 오래된 명칭이 남아 있으면 UI와 API 혼선이 반복됩니다.
모델 카드의 업데이트 날짜도 좋은 기준입니다. 최근 업데이트가 있었다면 재확인이 필요합니다.
preview 상태 확인은 Gemini API changelog이 가장 빠릅니다.
changelog는 레이트 리밋이나 가용성 변화도 알려주므로 업데이트가 보이면 내부 QA를 다시 돌리는 것이 안전합니다.
model ID와 확인 날짜를 함께 기록해 두면 다음 검증이 훨씬 빠릅니다.
정기 재검토 루틴을 만들면 갑작스러운 명칭 변경에도 대응이 쉽습니다.
문서가 업데이트될 때 앱과 API 양쪽에서 실제 표기를 확인하면 혼란이 줄어듭니다.
변경이 확인되면 대응표의 모델명과 ID만 교체하는 방식으로 운영하면 절차가 단순해집니다.
Nano Banana Pro / Nano Banana 2 / Nano Banana 비교
기본 원칙은 품질 vs 속도입니다.
- Nano Banana Pro (Gemini 3 Pro Image Preview): 고품질, 텍스트 정확성
- Nano Banana 2 (Gemini 3.1 Flash Image Preview): 속도, 대량 생성
- Nano Banana (Gemini 2.5 Flash Image): 이전 빠른 레인
Pro는 품질, Flash는 속도입니다. 텍스트/브랜딩이 중요하면 Pro, 속도라면 Nano Banana 2.
기억용 요약:
- Pro: 고정밀, 텍스트/레이아웃
- Nano Banana 2: 속도/볼륨
- Nano Banana: 다른 선택지가 없을 때
먼저 Pro로 품질 기준을 만들고, 가능하면 Nano Banana 2로 전환하는 방식이 실무적으로 안전합니다.
텍스트가 들어간 결과물이나 브랜드 톤이 중요한 경우에는 Pro를 기준으로 시작하는 것이 좋습니다. 대량 변형이나 속도가 중요한 작업만 Nano Banana 2로 넘기면 균형이 맞습니다.
구형 모델이나 타사 모델에서 이전하는 경우라면, Pro로 첫 비교를 진행한 뒤 빠른 레인을 시험하는 편이 판단 오류를 줄입니다.
텍스트가 들어간 이미지나 UI 구성에는 Pro가 더 안정적입니다. 속도 중심 작업만 Nano Banana 2로 분리하면 품질과 효율을 동시에 확보할 수 있습니다.
먼저 Pro로 기준을 잡고, 충분히 빠른 레인이 필요할 때만 Nano Banana 2로 내려가는 방식이 실무적으로 안전합니다.
Pro를 실제로 쓰고 있는지 확인
Gemini 앱
- 이미지 생성 화면에서 모델 확인
- Thinking 선택
- 여러 번 생성 후 빠른 레인으로 돌아가면 플랜/쿼터 영향을 의심
Google AI Studio
- Gemini 3 Pro Image Preview 선택
- Flash 모델만 보이면 계정/지역이 아직 미지원일 수 있음
Gemini API
gemini-3-pro-image-preview지정- 로그에 model ID 기록
- 요청 payload에 model ID를 남기면 운영 중 확인이 쉬움
모델이 다르게 나오는 경우는 기본값 복귀, 플랜/지역 제한, ID 오류 중 하나입니다.
SDK 경유라면 실제 model ID를 로그로 남기는 것이 좋습니다.
운영 중 기본값이 바뀌어도 로그가 있으면 원인 추적이 빨라집니다.
그래도 다른 모델이 나온다면 기본값 복귀, 플랜/지역 제한, ID 오기입을 순서대로 의심하는 것이 빠릅니다.
Pro가 아예 보이지 않는 경우에는 계정 권한이나 지역 rollout을 우선 확인하세요.
워터마크와 검증
공식 문서에 따르면 모든 이미지에 SynthID가 포함됩니다. 앱 쪽에서는 보이는 워터마크가 붙을 수 있으며 플랜에 따라 다릅니다.
- SynthID는 항상 존재
- 보이는 워터마크는 플랜/rollout 의존
- 필요한 경우 최신 정책 확인
보이는 워터마크는 사용자 경험의 문제이고, SynthID는 출처 추적의 문제입니다. 외부 공유나 고객 약속 전에 현재 정책을 반드시 확인하세요.
플랜이나 롤아웃 변경으로 정책이 달라질 수 있으니 정기적으로 재확인하는 습관이 좋습니다.
외부 공유가 잦다면 워터마크 정책을 내부 가이드에 함께 적어 두는 것이 안전합니다.
샘플 출력을 주기적으로 확인하면 정책 변경을 빠르게 체감할 수 있습니다.
빠른 문제 해결
- 앱에서 Nano Banana Pro가 안 보임 → 업데이트/플랜 확인
- 금방 Nano Banana로 복귀 → 한도 또는 기본값 복귀
- API 실패 →
gemini-3-pro-image-preview확인 - 속도 우선 → Nano Banana 2
문제가 반복되면 앱 표시명, AI Studio 모델명, API model ID를 함께 확인해 원인을 빠르게 분리하세요。
내부 공유에는 “model ID + 확인 날짜”를 남겨 두면 업데이트가 빨라집니다。
UI 이름과 API 이름은 다르므로 반드시 model ID를 기준으로 하세요。
앱 사용자와 API 개발자가 섞여 있다면 닉네임, 공식 모델명, model ID를 한 표에 넣어 공유하는 것만으로도 혼선이 크게 줄어듭니다。
그래도 헷갈리면 공식 문서와 최근 출시 안내를 다시 확인해 이름이나 공개 범위가 바뀌지 않았는지 점검하세요。
문서가 바뀌어 있다면 내부 가이드도 즉시 업데이트하는 것이 좋습니다。
빠른 확인은 AI Studio, 최종 판단은 API라는 원칙을 두면 실무에서 흔들리지 않습니다。
내부 FAQ나 위키에 닉네임, 공식 모델명, model ID를 한 줄 요약으로 넣어두면 신규 멤버가 빠르게 이해합니다。
월 1회 정도 앱 표시명, AI Studio 모델명, API ID를 간단히 확인하면 변경을 빠르게 감지할 수 있습니다。
확인 결과를 문서에 기록하면 팀이 같은 기준을 유지할 수 있고, 문의 대응 속도도 빨라집니다。
간단한 날짜 기록만 남겨도 다음 점검이 훨씬 쉬워집니다。
차이가 보이면 매핑 표를 바로 갱신해 두는 것이 좋습니다。
월간 리마인더를 설정해 두면 체크를 잊지 않게 됩니다。
동일한 체크리스트를 반복 사용하면 비교가 쉬워지고, 작은 기록이 큰 혼선을 막습니다。
몇 분이면 끝나므로 부담 없이 반복할 수 있습니다。
짧은 기록이 문제를 예방하는 가장 쉬운 방법입니다。
정해진 시간에만 확인해도 효과가 큽니다. 짧은 점검이 장기 혼선을 줄입니다。
최소한의 기록만 남겨도 충분합니다。
몇 번만 해보면 금방 익숙해집니다。
큰 시간이 필요하지 않습니다。
익숙해지면 확인 시간이 거의 들지 않습니다. 작은 루틴이 큰 리스크를 줄입니다。
한두 번만 체크해도 추세를 파악할 수 있습니다. 기록이 쌓이면 이상 징후를 빨리 알아챌 수 있습니다。
추가 점검도 5분 이내로 끝납니다。
이 정도면 기준을 넘기기 충분합니다。
조금만 추가로 기록해도 충분합니다。
짧은 메모 몇 줄이면 됩니다. 금방 끝납니다。
이 작은 루틴이 실제 운영 리스크를 크게 낮춥니다. 매달 한 번이면 충분합니다。
짧은 점검만으로도 충분합니다。
그 정도면 충분합니다。
충분히 넉넉합니다。
문제없습니다。
여유입니다。