나노바나나 2 사고 수준 설정: minimal과 high, 언제 바꿔야 할까?

나노바나나 2의 사고 수준은 minimal과 high이며, 기본값은 minimal입니다. 현재 안정 모델 ID는 gemini-3.1-flash-image입니다. 간단한 시안을 만들 때는 기본값으로 시작하고, 여러 조건을 동시에 맞춰야 하는 이미지라면 같은 요청을 high로도 보내 비교하는 편이 좋습니다. High가 모든 이미지의 완성도를 높여 주거나 수정 횟수를 줄여 준다는 보장은 없습니다. 모델 식별자와 설정값은 2026년 9월 8일 확인한 Google 모델 문서와 사고 수준 설정 안내를 기준으로 합니다.

핵심은 쓰고 있는 API에 맞는 위치에 값을 넣는 것입니다. Interactions 예제를 기존 generateContent 코드에 그대로 붙여 넣으면 설정 구조가 맞지 않습니다. Gemini 앱에서 선택한 사고 모드도 이미지 API의 같은 이름의 설정과 대응한다고 단정하면 안 됩니다.

내 코드에서는 어디에 넣어야 하나요?

먼저 요청을 보내는 주소나 SDK 호출을 확인하세요. 모델 이름이 같아도 두 API의 요청과 응답 구조는 다릅니다.

이 표는 Interactions 이미지 안내와 generateContent 이미지 안내를 함께 정리한 것입니다. Python generateContent의 공식 예제는 types.ThinkingConfig(thinking_level="High", include_thoughts=True)를 사용합니다. SDK의 열거형이나 값 표기를 확인할 때도 해당 API의 예제를 기준으로 삼으세요.

새 Interactions 요청에서 High를 지정하는 REST 예제는 다음과 같습니다. GEMINI_API_KEY는 로컬 환경 변수로 설정해 두고 실행합니다. 실제 실행하면 API 사용 요금이 발생할 수 있습니다.

bash
curl --fail-with-body \
  'https://generativelanguage.googleapis.com/v1beta/interactions' \
  -H "x-goog-api-key: ${GEMINI_API_KEY}" \
  -H 'Content-Type: application/json' \
  --data-binary @- > response.json <<'JSON'
{
  "model": "gemini-3.1-flash-image",
  "input": "온라인 서점의 독서 주간 배너를 만들어 줘. 중앙에는 펼친 책, 왼쪽 위에는 정확히 '독서 주간', 오른쪽 아래에는 날짜를 넣을 수 있는 빈 공간을 남겨 줘. 다른 문구는 넣지 마.",
  "generation_config": {
    "thinking_level": "high"
  }
}
JSON

기본값과 비교할 때는 이 요청의 "high"만 "minimal"로 바꿉니다. 예제에서는 해상도나 종횡비를 따로 지정하지 않았습니다. 실제 작업에 사용할 때는 해당 API의 이미지 설정으로 필요한 값을 명시하고, 비교하는 두 요청에 똑같이 적용하세요. 모델 문서상 기본 해상도는 1K입니다.

기존 generateContent REST 요청을 유지한다면 사고 설정 부분은 다음 구조입니다. 아래는 전체 요청이 아니라 generationConfig에 들어갈 부분입니다. 기존 contents나 이미지 출력 설정을 없애고 이 조각만 보내지 마세요.

json
{
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "high"
    }
  }
}

응답이 왔다면 최종 이미지부터 확인하세요

HTTP 200은 서버가 요청을 처리했다는 뜻이지, 게시할 수 있는 이미지가 저장됐다는 뜻은 아닙니다. 텍스트 응답을 받았는지, 최종 이미지 데이터가 있는지, 그 파일을 실제로 열 수 있는지까지 확인해야 합니다.

Interactions 안내에서는 최종 이미지에 interaction.output_image.data로 접근합니다. Python SDK를 쓴다면 호출 뒤에 다음과 같은 확인을 둘 수 있습니다. 이 코드는 위 REST 응답 파일을 파싱하는 예제가 아니라, SDK가 반환한 interaction 객체를 처리하는 예제입니다.

python
import base64
from pathlib import Path

image = getattr(interaction, "output_image", None)
if image is None or not getattr(image, "data", None):
    raise RuntimeError("최종 이미지가 없습니다. 응답 내용을 확인하세요.")

extensions = {
    "image/png": ".png",
    "image/jpeg": ".jpg",
    "image/webp": ".webp",
}
mime_type = getattr(image, "mime_type", None)
if mime_type not in extensions:
    raise RuntimeError(f"지원하지 않는 이미지 형식: {mime_type}")

image_bytes = base64.b64decode(image.data, validate=True)
if not image_bytes:
    raise RuntimeError("이미지 데이터가 비어 있습니다.")

output_path = Path("banner" + extensions[mime_type])
output_path.write_bytes(image_bytes)
print(output_path)

저장 후에는 이미지 뷰어에서 파일을 열고 요청한 문구와 배치가 맞는지 살펴보세요. 데이터가 있다는 확인과 작업에 쓸 수 있다는 판단은 별개입니다. 이 글의 코드는 문서에 근거한 구현 예시이며, 실제 호출의 성공 결과나 생성 속도를 제시하는 벤치마크는 아닙니다.

generateContent를 사용한다면 응답의 parts를 처리하는 기존 방식에 맞춰야 합니다. 사고 과정에 속하는 thought 표시가 있는 부분을 최종 납품 이미지로 선택하지 않도록 구분하세요. Interactions의 output_image와 generateContent의 parts를 한 가지 응답 형식처럼 처리하면, 이미지가 없다고 오판하거나 다른 출력을 저장할 수 있습니다. Google generateContent 이미지 안내

High를 시험할 만한 작업은 무엇인가요?

사고 수준을 올릴지 판단하기 전에 결과의 합격 조건부터 정하는 것이 좋습니다. “더 예쁜가”만 비교하면 우연히 마음에 드는 한 장을 고른 것인지, 실제로 수정 작업이 줄었는지 알기 어렵습니다.

예를 들어 위 독서 주간 배너라면 확인할 항목은 구체적입니다. 한글 문구가 정확한지, 책이 중앙에 있는지, 오른쪽 아래의 빈 공간을 확보했는지, 요청하지 않은 문구가 추가됐는지를 봅니다. 제품 광고라면 제품 형태와 로고, 시리즈 이미지라면 인물의 특징과 의상 등 실제 작업에서 고칠 부분을 기준으로 삼으세요.

단일 피사체의 분위기나 색상을 탐색하는 단계에서는 minimal로 시안을 모으는 방식부터 시작할 수 있습니다. 반면 문구·위치·여러 사물의 관계를 한꺼번에 맞추거나 참고 이미지의 특징을 유지해야 하는 작업은 High를 비교해 볼 이유가 있습니다. 이는 설정을 고르기 위한 제안이며, High의 한글 렌더링이나 인물 일관성이 실측으로 더 좋다는 주장은 아닙니다.

비교할 때는 프롬프트, 참고 이미지, 해상도, 종횡비, 검색 사용 여부를 고정하고 사고 수준만 바꿉니다. 요청 순서를 번갈아 실행하면 한쪽 설정이 특정 시간대에만 몰리는 것을 피할 수 있습니다. 한 번의 결과로 결론을 내리기보다, 실제 업무에서 반복되는 몇 가지 작업으로 확인하세요.

High에서 합격 이미지가 더 자주 나오더라도 기다리는 시간이 길어져 업무에 맞지 않을 수 있습니다. 반대로 요청 한 번의 비용이 조금 늘어도 재생성이 줄어들면 최종 한 장을 얻는 비용은 내려갈 수 있습니다. 따라서 비교에 쓴 총비용을 합격 이미지 수로 나눈 값을 함께 보세요. 합격 이미지가 0장인 경우에는 이 값을 계산하지 말고 해당 작업의 실패로 남깁니다.

사고 토큰 요금은 이미지 가격에 포함되나요?

Google 표준 API 요금표는 텍스트·사고 출력과 이미지 출력을 구분합니다. 2026년 9월 8일 기준 Nano Banana 2의 텍스트·이미지 입력은 100만 토큰당 0.50달러, 텍스트·사고 출력은 100만 토큰당 3달러입니다. 이미지 출력은 100만 토큰당 60달러이며, 요금표의 1K 이미지 환산 금액은 0.067달러입니다. Google 공식 요금표

여기서 0.067달러는 이미지 출력분입니다. 입력과 사고 출력, 별도로 사용하는 도구의 비용까지 포함한 고정 요청 가격으로 보면 안 됩니다. 예를 들어 다른 조건이 같고 사고 출력이 1,000토큰 추가됐다면 추가분은 1,000 ÷ 1,000,000 × 3 = 0.003달러입니다. 이 숫자는 단순 요금 계산이며, High가 보통 1,000토큰을 더 사용한다는 측정 결과가 아닙니다.

따라서 “High는 장당 얼마가 더 드나요?”라는 질문에는 고정 금액으로 답하기 어렵습니다. 반환된 사용량과 실제 청구 내역을 함께 기록하고, 재생성 요청까지 합산해야 합니다. 해상도별 이미지 요금과 다른 비용 항목은 나노바나나 2 API 요금 안내에서 이어서 확인할 수 있습니다.

설정할 때 자주 헷갈리는 세 가지

minimal이면 사고 기능이 완전히 꺼지나요?

아닙니다. Google은 minimal이 사고 토큰을 전혀 사용하지 않는다는 뜻은 아니라고 설명합니다. 최소 수준과 사고 기능 비활성화를 같은 것으로 보지 마세요. 다른 Gemini 모델의 예제를 보고 thinkingBudget=0이나 off를 이 모델에 그대로 적용하는 것도 피해야 합니다. generateContent 사고 수준 안내

발표문에 있는 High/Dynamic에서 dynamic을 넣어도 되나요?

현재 모델별 API 안내에서 확인되는 값은 minimal과 high입니다. Google 발표문의 High/Dynamic이라는 설명만으로 "dynamic"이 API에서 허용되는 별도 값이라고 판단할 수는 없습니다. low나 medium도 다른 모델의 설정을 가져와 쓰지 말고 Nano Banana 2 문서에 맞추세요.

사고 내용을 숨기면 요금도 줄어드나요?

includeThoughts는 사고 내용을 응답에 포함할지 정하는 옵션입니다. 표시를 끄는 것과 사고에 대한 과금이 사라지는 것은 다릅니다. 사고 설명이 응답에 없다는 이유로 사고 토큰이 0개였다고 판단하지 마세요. generateContent로 여러 차례 이미지를 편집하는 경우에는 응답의 thought signature도 임의로 수정하거나 제거하지 않고 다음 요청에 전달해야 합니다. Google thought signature 안내

앱이나 중계 서비스에서 설정했다면 마지막으로 실제 요청 형식을 확인하세요. 화면에 “사고 모드”나 “High”가 보인다는 사실만으로 gemini-3.1-flash-image에 해당 값이 전달됐다고 알 수는 없습니다. 직접 API를 호출하는 경우에는 요청 본문을, 서비스에서 호출하는 경우에는 해당 서비스의 모델·매개변수 지원 문서를 확인한 뒤 같은 비교 방법을 적용하면 됩니다.