많은 개발자가 Nano Banana 2 라고 부르던 모델의 공식 이름은 Gemini 3.1 Flash Image(gemini-3.1-flash-image-preview)입니다. 이제 중요한 것은 이름보다 해상도별 공식 가격이 확실해졌다는 점입니다. Google은 이 모델을 2026년 2월 26일 Nano Banana 2 공식 발표에서 소개했습니다. 그리고 2026년 4월 4일 기준으로 Google의 Gemini API pricing 페이지를 다시 확인해 보면, 현재 공식 가격은 1K가 $0.067, 2K가 $0.101, 4K가 $0.151이고, Batch 를 쓰면 각각 $0.034, $0.050, $0.076 입니다.
그래서 이제 중요한 질문은 "Gemini 3.1 Flash Image가 무엇인가?"가 아닙니다. 실제 운영에서 중요한 질문은 기본 출력 크기를 1K, 2K, 4K 중 무엇으로 둘 것인가입니다. 이 결정을 먼저 하지 않으면 API 비용, 자산 재사용성, 제품 기본값이 전부 흔들립니다. 먼저 결론부터 말하면, 대부분의 경우 기본은 1K, 크롭 여유나 재사용성이 중요하면 2K, 4K는 명확한 후속 활용 이유가 있을 때만 쓰는 것이 가장 실무적입니다.
먼저 결론
| 크기 | 표준가 | Batch 가격 | 이런 경우에 적합 |
|---|---|---|---|
512 | $0.045 | $0.022 | 빠른 초안, 아주 작은 화면, 내부 검토 |
1K | $0.067 | $0.034 | 대부분의 웹 전달과 일반 제품 이미지의 기본값 |
2K | $0.101 | $0.050 | 크롭 여유, Retina 자산, 재사용 가능한 원본 |
4K | $0.151 | $0.076 | 대형 출력, 마스터 자산, 무거운 다채널 재사용 |
시작 전에 세 가지 사실은 고정해 두는 편이 좋습니다.
gemini-3.1-flash-image-preview에는 무료 티어가 없습니다.- 공식 image generation 가이드에 따르면 크기를 지정하지 않으면 기본값은
1K입니다. 1K,2K,4K는 대문자K를 써야 하며1k,2k는 허용되지 않습니다.
Gemini 3.1 Flash Image의 공식 가격을 해상도별로 보면
이번 Google pricing 페이지가 실무적으로 좋은 이유는, 단순히 "백만 output tokens당 얼마"만 보여주는 것이 아니라 크기별 1장당 환산 가격까지 함께 보여주기 때문입니다. Gemini 3.1 Flash Image의 표준 image output 가격은 1,000,000 output tokens당 $60 이고, 이를 크기별로 풀면 다음과 같습니다.
imageSize | 표준가 | Batch 가격 | Output tokens | 실무 해석 |
|---|---|---|---|---|
512 | $0.045 | $0.022 | 747 | 1K보다 싸지만 일반 운영 기본값으로는 너무 작음 |
1K | $0.067 | $0.034 | 1120 | 가장 무난한 기본 크기 |
2K | $0.101 | $0.050 | 1680 | 더 오래 버티는 원본 자산이 필요할 때 |
4K | $0.151 | $0.076 | 2520 | 별도 정당화가 필요한 고비용 구간 |
여기서 중요한 것은 숫자 자체보다 차이의 성격입니다. 1K 에서 2K 로 올라가는 것은 분명 비용 증가이지만, 여전히 "실무용 상향 설정"으로 볼 수 있습니다. 반면 1K 에서 4K 는 다른 판단입니다. 4K는 1K의 약 2.25배 비용입니다. 이건 미세 조정이 아니라 기본 전략의 문제입니다.
그래서 초기의 "Nano Banana 2 pricing" 글들이 금방 낡아 버렸습니다. Google이 해상도별 공식 가격을 정리하기 전에는 커뮤니티 추정치나 초기 공개 시점의 단서에 의존할 수밖에 없었기 때문입니다. 이제는 대략적인 기억값보다 공식 가격 사다리를 기준으로 보는 편이 훨씬 낫습니다.
Google은 실제로 어디에서 비용이 움직이는가
이 주제에서 가장 흔한 오해는 "프롬프트가 길수록 비용이 커지니까 그쪽을 먼저 최적화해야 한다"는 생각입니다. Gemini 3.1 Flash Image에서는 대부분의 경우 비용 차이를 크게 만드는 요인은 출력 이미지 크기입니다.
Google의 표준 가격에서 text/image input은 1,000,000 tokens당 $0.50, Batch input은 $0.25 입니다. 일반적인 image-generation 워크로드에서는 이 입력 비용이 출력 이미지 비용보다 훨씬 작습니다. 다시 말해, 프롬프트가 극단적으로 길지 않다면 실제 청구액을 흔드는 것은 프롬프트 길이가 아니라 1K, 2K, 4K 선택입니다.
따라서 예산을 계산할 때 순서는 먼저 해상도별 출력 비용, 그다음 프롬프트 길이와 입력 토큰 정리가 맞습니다. 후자도 의미는 있지만, 이 모델에서는 주된 비용 레버가 아닙니다.
또 하나의 경계조건은 Google Search grounding은 별도 과금이라는 점입니다. pricing 페이지에는 한 번의 사용자 요청이 하나 이상의 검색 질의를 만들 수 있고, 무료 월간 한도를 넘으면 질의 단위로 과금된다고 적혀 있습니다. Search grounding이 들어간 이미지 생성 흐름이라면 단순한 이미지 단가만 보고 전체 비용을 판단하면 안 됩니다. 다만 일반적인 생성에서는 여전히 핵심이 해상도 사다리입니다.
1K, 2K, 4K 중 무엇을 기본값으로 둘까

대부분의 제품에서는 1K 가 맞는 기본값입니다. 이유는 1K 가 무조건 최고라서가 아니라, 현실적인 전달 경로를 버티는 가장 작은 크기가 되기 쉽기 때문입니다. 웹 페이지, 상품 카드, 앱 화면, 블로그 헤더, 일반적인 소셜 채널이라면 1K면 충분한 경우가 많고, 동시에 비용도 안정적으로 유지됩니다.
2K 로 올리는 시점은 이미지를 나중에 많이 자르거나, 여러 화면에 재사용하거나, Retina 자산으로 쓰거나, 조금 더 오래 버티는 원본으로 보관해야 할 때입니다. 2K는 "고급 모드"라기보다 재사용성을 위한 실무용 상향 설정이라고 보는 편이 맞습니다.
4K 는 예외 경로로 두면 충분합니다. 대형 출력, 인쇄 근접 사용, 마스터 자산, 한 번 만든 결과물을 여러 채널에 무겁게 재활용하는 경우처럼 명확한 후속 활용 요구가 있을 때만 쓸 이유가 생깁니다. 반대로 그런 이유를 분명하게 말할 수 없다면, 4K는 대개 과한 기본값입니다.
512 는 Gemini 3.1 Flash Image에만 추가된 작은 단계로서 초안이나 작은 표면에서는 유용합니다. 하지만 일반 운영의 기본 크기로 생각할 필요는 없습니다.
월간 비용으로 보면 차이가 어디까지 벌어지는가

장당 가격만 보면 큰 차이처럼 보이지 않아도, 볼륨이 붙으면 의미가 달라집니다.
| 수량 | 1K 표준 | 1K Batch | 2K 표준 | 2K Batch | 4K 표준 | 4K Batch |
|---|---|---|---|---|---|---|
100장 | $6.70 | $3.40 | $10.10 | $5.00 | $15.10 | $7.60 |
1,000장 | $67 | $34 | $101 | $50 | $151 | $76 |
10,000장 | $670 | $340 | $1,010 | $500 | $1,510 | $760 |
이 표가 보여주는 핵심은, 기본값을 1K로 둘지 4K로 둘지는 서로 다른 예산 전략이라는 점입니다. 1,000장 규모에서도 표준가 기준으로 차이는 월 $84 입니다. 10,000장 이 되면 월 $840 로 커집니다. 이미지 생성이 여러 유료 모델 호출 중 하나일 뿐인 제품이라면, 이 정도 차이는 단위 경제성에 분명한 영향을 줍니다.
Batch는 답을 바꾸지만, 기본 원칙을 뒤집지는 않습니다. 야간 처리, 비실시간 생성, 예약 배포용 마케팅 자산처럼 기다릴 수 있는 작업에는 매우 좋은 절감 수단입니다. 4K도 $0.076 까지 내려갑니다. 하지만 그렇다고 해서 4K가 기본값이 되어야 하는 것은 아닙니다. Batch는 고해상도를 덜 비싸게 만들 뿐, 자동으로 올바른 기본값으로 만들어 주지는 않습니다.
실무적으로는 실시간용 기본 크기 하나, 예외적 고해상도 경로 하나, 기다릴 수 있는 일은 Batch로 라는 구성으로 가는 것이 가장 안정적입니다.
Flash에 남아야 할 때와 모델을 바꿔야 할 때

때로는 핵심 질문이 "어떤 크기인가"가 아니라 모델 계열 자체가 맞는가입니다.
만약 필요한 것이 가장 싼 공식 Gemini 1K 이미지 경로 라면, 오래된 Gemini 2.5 Flash Image 는 여전히 의미가 있습니다. Google 공식 가격은 표준 $0.039/장, Batch $0.0195/장 입니다. 1K 하나만 보면 Gemini 3.1 Flash Image보다 확실히 저렴합니다. 그 대신 512 부터 4K 까지 이어지는 더 깔끔한 새 라더는 포기하게 됩니다.
반대로 작은 초안부터 4K까지를 하나의 공식 Google 라인으로 다루고 싶다면, Gemini 3.1 Flash Image가 현재의 기본 답입니다. 이것이 이 모델의 핵심 가치입니다. 512 는 초안, 1K 는 표준, 2K 는 더 오래 쓰는 원본, 4K 는 요구 수준이 높은 최종 결과물이라는 식으로 하나의 경로 안에서 정리할 수 있습니다.
정말로 필요한 것이 더 높은 품질, 더 비싼 프리미엄 운용, 혹은 무거운 reference image 작업 이라면 Gemini 3 Pro Image 를 보는 편이 맞습니다. 공식 가격은 1K-2K가 $0.134, 4K가 $0.24 이고 Batch는 그 절반입니다. Flash와는 다른 비용 구조이기 때문에, 그런 운용이 실제로 가치가 있을 때만 올라가야 합니다. 이 경로를 더 보고 싶다면 다음 읽을 글은 Nano Banana Pro API 가이드 입니다.
요약하면 라우팅은 이렇게 정리할 수 있습니다.
- 가장 싼 1K 가 최우선이면 Gemini 2.5 Flash Image
512부터4K까지 이어지는 현재의 기본 라인 이 필요하면 Gemini 3.1 Flash Image- 프리미엄 품질과 무거운 참조 이미지 운용 이 필요하면 Gemini 3 Pro Image
imageSize 를 명시하지 않으면 예산 판단은 실제와 어긋난다
운영에서 가장 흔한 함정은, 비용 계산은 2K 기준으로 해 놓고 실제 요청은 명시적으로 사이즈를 지정하지 않는 경우입니다. Google의 image generation 가이드는 Gemini 3 계열 이미지 모델의 기본 출력이 1K 이며, 허용 값이 512, 1K, 2K, 4K 라고 분명히 적고 있습니다.
따라서 파라미터는 명시적으로 넣는 편이 낫습니다.
javascriptimport { GoogleGenAI, Modality } from "@google/genai"; 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 ecommerce hero image of a ceramic mug on a stone surface.", config: { responseModalities: [Modality.TEXT, Modality.IMAGE], imageConfig: { imageSize: "2K", aspectRatio: "1:1", }, }, });
실수하기 쉬운 부분은 두 가지뿐입니다.
1K,2K,4K는 대문자K512는 그냥512
작아 보이는 규칙이지만, 운영에서는 중요합니다. 팀이 2K 기준으로 예산을 잡았다면 SDK 래퍼와 요청 파라미터도 실제로 2K를 요구해야 합니다. 그렇지 않으면 글에서 설명하는 가격 논리와 실제 시스템 동작이 서로 달라집니다.
실무 기본 결론
2026년 4월 4일 기준으로 Gemini 3.1 Flash Image의 공식 답은 충분히 명확합니다. 가격은 1K $0.067, 2K $0.101, 4K $0.151 이고, Batch는 $0.034, $0.050, $0.076 입니다. 지원 크기는 512, 1K, 2K, 4K, 기본값은 1K, 그리고 무료 티어는 없습니다.
따라서 가장 실용적인 운영 규칙은 이렇습니다. 평소에는 1K 를 기본값으로 두고, 재사용성이나 크롭 여유가 중요할 때만 2K 로 올리며, 4K 는 후속 사용 요건이 명확할 때만 예외적으로 열어 둔다. 이것이 보수적으로 보인다면 월간 비용 표를 다시 보면 됩니다. 대부분의 경우 그것은 보수적인 판단이 아니라, 가격 계약과 실제 전달 요구가 제대로 맞물리는 지점입니다.
