Gemini 3.6 Flash는 답변 외에 사고 토큰 (thinking tokens)에 대해서도 비용을 청구하며, 요청당 얼마나 많은 토큰을 사용할지는 사용자가 조절할 수 있는 다이얼과 같습니다. 동일한 120단어 쓰기 작업에서 기본 설정은 $0.03316이 청구된 반면, minimal 설정은 $0.00110이 청구되어, 독자가 차이를 느낄 수 없는 결과물임에도 30배의 비용 차이가 발생했습니다. 이 다이얼은 이 모델에서 가장 중요한 비용 결정 요소이지만, 날카로운 단점도 하나 가지고 있습니다. Gemini 3.6 Flash는 2026-07-21에 입력 토큰 100만 개당 $1.50, 출력 토큰 100만 개당 $7.50의 가격으로 일반 공개(GA)되었으며, 이는 3.5 Flash의 출력 비용인 $9에서 인하된 수치입니다. 이 모델은 Gemini 3.5 Flash-Lite 및 보안에 특화된 3.5 Flash Cyber와 함께 출시되었습니다. 본 포스트에서는 두 가지 범용 티어인 3.6 Flash와 Flash-Lite를 측정합니다.

요약 (TL;DR)

• reasoning_effort: "minimal" 설정은 기본값 대비 호출당 비용을 91~97% 절감합니다 (120단어 작업 기준 30배 차이). 단일 단계(single-step), 구조화된 출력(structured-output), 도구 호출(tool-calling) 작업에서는 무료로 작동하지만, 다단계 수학 문제 해결 능력은 3/3에서 0/3으로 떨어집니다.
• Google이 주장하는 "출력 토큰 17% 감소"는 작업 부하에 따라 다릅니다. 당사의 추론 중심 작업에서는 19% 더 가볍게(32% 저렴하게) 실행되었고, 에이전트 제품군에서는 9% 더 무겁게(6% 저렴하게) 실행되었습니다.
• 1M 컨텍스트(context)는 실제이며 (972K 토큰 지점에서 바늘 찾기 성공), 프롬프트 캐싱(prompt caching)은 Google이 발표한 4,096 토큰 하한선과 정확히 일치합니다. 이는 광고하는 것보다 성능이 낮은 일부 "1M 컨텍스트" 모델들과 달리 깔끔하게 사양을 충족함을 의미합니다.

아래의 모든 수치는 2026-07-24에 Synthorai 게이트웨이를 통해 측정되었으며, 캐시를 무력화하기 위해 반복적인 프롬프트에 솔트(salt)를 추가했습니다. 원본 사용 기록이 모든 수치를 뒷받침합니다.

기본 설정에서 Gemini 3.6 Flash의 작업당 비용은 얼마인가?

추론 (Reasoning)이 출력 비용의 대부분을 차지하며, 사용자가 이를 눈으로 확인하든 못하든 비용이 청구됩니다. 기본 노력(default effort) 설정에서 모델은 답변하는 것보다 사고하는 데 훨씬 더 많은 토큰을 소비하며, 이러한 추론 토큰은 출력 토큰과 동일한 100만 개당 $7.50의 요율로 청구됩니다:

내재화해야 할 패턴은 다음과 같습니다: 단 두 개의 토큰으로 이루어진 사실 기반 답변에도 여전히 69개의 추론 토큰이 수반되었으며, 120단어 분량의 단락은 작성하는 것보다 생각하는 데 30배 더 많은 토큰을 소비했습니다. 추론 토큰은 completion_tokens_details.reasoning_tokens에 항목별로 나열되므로 개수는 확인할 수 있지만, 그 내용은 결코 볼 수 없습니다. Gemini는 사고 요약이나 추적(trace)을 전혀 반환하지 않는데, 이는 우리가 토큰 사용 구조 (token usage anatomy) 연구에서 매핑한 스펙트럼 중 가장 폐쇄적인 형태입니다. Kimi K3는 전체 사고 사슬 (chain of thought)을 반환하고 GPT-5.6은 요약을 반환하는 것과 대조적입니다. 다음 섹션은 이러한 비용 지출을 줄이는 방법에 관한 것입니다.

사고 조절 다이얼 (thinking dial)은 실제로 무엇을 하는가?

이것은 진정한 단조적 (monotonic) 비용 레버이며, 대부분의 작업 유형에서 거의 공짜나 다름없는 이득을 제공합니다. reasoning_effort (또는 네이티브 thinking_config.thinking_level)를 minimal로 설정하면 추론 토큰이 0으로 수렴하며 작업당 비용을 91~97% 절감했습니다:

이 다이얼은 실재하며 허용되는 값은 minimal, low, medium (기본값), high입니다. 우리의 조사 결과, 각 단계는 단조적으로 더 많은 추론을 수행했습니다 (minimal 0 토큰, low ~180, medium ~530, high ~650). minimal이 할 수 없는 단 한 가지는 '생각하기'이며, 다단계 산술 (multi-step arithmetic)에는 생각이 필요합니다. 연필과 가방에 관한 문장제 문제를 간결하게 답변하도록 강제했을 때, 모델은 체계적인 실수 하나를 범하기보다는 산발적인 오답을 내놓으며 세 번 모두 틀렸습니다. 반면 검색 (retrieval), 분류 (classification), 포맷팅 (formatting) 및 단일 단계 질문에서는 minimal 설정이 정확도를 유지하면서 비용을 한 자릿수(an order of magnitude)만큼 절감했습니다.

실질적인 규칙은 Kimi K3에서 발견한 것과 유사합니다. 즉, 추출 (extraction), 조회 (lookup), 포맷팅 (formatting) 작업에는 minimal 설정이 방어 가능한 기본값(default)이지만, 중간 단계가 필요한 작업에는 실수하기 쉬운 설정(footgun)이 됩니다. 이를 전역적으로 적용하지 말고 경로(route)별로 설정하십시오. 또한, 추론 집약적인 (reasoning-heavy) 작업에 적용하기 전에는 반드시 본인의 작업에서 정확도를 검증해야 합니다.

두 가지 고볼륨 프로덕션 사례를 통해 이를 구체적으로 살펴보겠습니다. 구조화된 출력 (structured output)과 함수 호출 (function calling)은 모두 기본 설정에서 추론 (reasoning) 비용을 소모하며, 두 경우 모두 minimal로 실행해도 안전합니다. 스키마 제약이 있는 추출 (JSON 스키마를 사용하는 response_format)의 경우, 기본 설정에서는 337개의 추론 토큰 (reasoning tokens)이 청구되었고 유효한 JSON을 반환했습니다. 반면 minimal 설정에서는 추론 토큰이 0개 청구되었음에도 여전히 스키마를 준수하는 유효한 JSON을 반환했으며, 비용은 9배 더 저렴했습니다. 함수 호출 (function call)도 동일하게 작동했습니다. 기본 설정에서는 74개의 추론 토큰과 함께 정확한 get_weather(city) 호출이 이루어졌으나, minimal 설정에서는 추론 토큰이 0개이면서도 동일하게 정확한 호출이 이루어져 4배 더 저렴했습니다. 이들은

추론 비중이 높은 짧은 작업(reasoning-heavy short tasks)의 경우, 해당 주장은 단순히 재현되는 것을 넘어 헤드라인의 내용을 뛰어넘었습니다. 총 출력(total output)은 19% 감소하여 Google의 17% 감소치에 근접했으며, 이는 답변(answer)이 아닌 거의 전적으로 사고(thinking) 과정에서 발생한 결과였습니다. 두 모델을 쌍으로 재실행하여 출력 토큰(output tokens)을 분리해 본 결과, 가시적인 답변은 4%만 줄어든 반면 추론(reasoning)은 19% 감소했습니다. 이는 3.6 버전이 더 적은 숙고(deliberation)로도 동일한 결과에 도달하는 수학 및 작문 작업에 집중되어 있었습니다. 이것이 벤치마크 이면에 있는 메커니즘입니다. 즉, 사고 예산(thinking budget)에 의존하는 작업에서 3.6은 동일한 답변을 내놓으면서도 진정으로 더 효율적입니다.

에이전트 방식의 다회차 트래픽(agentic, multi-turn traffic)에서는 양상이 반전됩니다. 3.6은 전체 스위트(suite)에 걸쳐 3.5보다 출력(output)을 약 9% 더 많이 사용했습니다. 효율성 이득은 추론 단계(reasoning phase)에 존재하는데, 에이전트 루프(agent loops)는 예산 중 추론에 할당하는 비중이 상대적으로 적기 때문에 절약할 수 있는 부분이 적으며, 결과적으로 3.6의 약간 더 긴 턴(turns)이 우세하게 됩니다. 어느 쪽이든 비용은 줄어듭니다. 두 효과가 다르게 중첩되기 때문입니다. 추론 비중이 높은 작업은 토큰 절감과 더불어 가격 인하($9 o $7.50, -32%) 효과를 동시에 누리는 반면, 에이전트 트래픽은 가격 인하(-6%) 효과만 누립니다. 솔직한 요약은 "출력 토큰 17% 감소"라는 수치는 사고(thinking)가 출력을 지배할 때는 실제이며, 그렇지 않을 때는 반대로 나타난다는 것입니다. 따라서 헤드라인을 맹신하기보다 자신의 작업 혼합(mix)을 측정해야 하며, 이전 섹션에서 언급한 다이얼(dial)이 버전 업데이트보다 훨씬 더 큰 변화를 만들어낸다는 점을 기억하십시오.

1M 컨텍스트 윈도우(context window)는 실제인가?

네, 실제이며 조용히 실패하기보다 명확하게 실패합니다. 우리는 점진적으로 크기가 커지는 프롬프트의 맨 앞에 회상 니들(recall needle)을 배치했습니다. 입력 토큰이 972K에 달할 때까지도 정확하게 회상되었으며, 한계를 초과한 프롬프트는 콘텐츠를 조용히 누락시키는 대신 400 input token count exceeds the maximum이라는 명확한 오류를 반환했습니다. 이는 시장의 모든 "1M 컨텍스트" 모델이 광고하는 윈도우를 실제로 제공하는 것은 아니기에 언급할 가치가 있습니다. 이 테스트를 재현하려는 분들을 위한 한 가지 테스트 참고 사항: 다양한 문장 형태의 채우기 텍스트(filler)로 패딩(pad)하십시오. 단일 반복 토큰으로 구성된 프롬프트는 크기 제한에 도달하기 훨씬 전에 모델을 퇴보적인 횡설수설(degenerate gibberish) 상태로 몰아넣었습니다.

프롬프트 캐싱 (Prompt caching)은 자동으로 이루어지며, 중요한 수치에 대한 명세(spec)와 일치합니다. Google은 Flash 모델의 컨텍스트 캐싱 (context caching)에 대해 최소 4,096토큰을 문서화하고 있으며, 우리의 전수 조사 결과도 정확히 그 지점에 도달했습니다. 약 2.1K 이하의 접두사 (prefixes)는 전혀 캐싱되지 않았고, 히트 (hits)는 약 4.1K 토큰 부근에서 시작되었으며, 5~8회의 호출 워밍업 (warm-up) 이후 각 히트는 마지막 약 2.1K를 캐싱되지 않은 상태로 남겨두었습니다. 캐싱된 입력은 $0.15/M로, 신규 입력 요금인 $1.50 대비 10배 저렴합니다. 이 점은 명확히 언급할 가치가 있는데, 왜냐하면 이는 안심할 수 있는 사례이기 때문입니다. 광고된 수치가 엔드포인트 (endpoint)가 실제로 제공하는 것보다 과장된 일부 모델들과 달리, Gemini 3.6 Flash의 캐시 하한선 (cache floor)과 1M 컨텍스트 창 (window)은 모두 문서에 명시된 대로 작동합니다. 캐싱은 여전히 진정으로 길고 안정적인 접두사 (prefixes)에 대해서만 비용 절감 효과가 있으며, Flash 티어는 명시적 캐시 콘텐츠 API (explicit cached-content API)가 아닌 자동 (암시적) 캐싱만을 지원하므로, 큰 문서를 수동으로 고정(pin)하여 하한선 미만에서 재사용할 수는 없다는 점에 유의하십시오.

Gemini 3.5 Flash-Lite는 어디에 위치하는가?

Flash-Lite는 비용 예측이 가능한 티어입니다. 이 모델은 추론 토큰 (reasoning tokens)을 조용히 소비하지 않으므로, 청구 금액이 가시적인 출력과 일대일로 일치합니다. 동일한 다단계 수학 문제에서 Flash-Lite는 3.6 Flash의 기본 요금인 $0.00368 대비 약 6배 저렴한 $0.00057를 청구했으며, 숨겨진 추론 필드 대신 공개적으로 정답을 도출했습니다. 입력 $0.30/M, 출력 $2.50/M의 가격을 가진 이 모델은 대량의 작업, 지연 시간 (latency)에 민감한 작업, 단일 단계 작업에 적합한 기본 모델입니다. 작업에 다이얼 (dial)을 통해 다시 추가할 수 있는 추론이 필요할 때는 3.6 Flash로 업그레이드하십시오. 토크나이저 (tokenizer)는 세 가지 신규 모델뿐만 아니라 Gemini 2.5 Flash와도 동일하게 변경되지 않았습니다. 우리가 확인한 모든 세대에서 영어, 중국어, 일본어, 한국어, Python에 대해 동일한 토큰 수를 기록했으므로, 2.5를 위해 구축된 언어별 예산은 재설정 없이 3.6으로 그대로 이어집니다.

FAQ

Gemini 3.6 Flash에서 추론을 완전히 끌 수 있습니까?

reasoning_effort: "minimal" (또는 thinking_level: "minimal") 설정은 우리의 테스트에서 추론 토큰 (reasoning tokens)을 0으로 만들었으며, 이 다이얼의 최저점입니다. 허용되는 단계는 minimal, low, medium, high입니다. 별도의 "비활성화 (disabled)" 상태는 없으며, 추론을 강제로 비활성화하려는 시도는 상위 단계에서 거부되므로 minimal이 가장 낮은 단계이며, 단일 단계 (single-step) 작업에는 충분히 낮습니다.

왜 제 Gemini 청구 금액이 눈에 보이는 답변보다 더 높게 나오나요?

추론 토큰 (reasoning tokens)은 전체 출력 요율 (output rate)로 청구되며, 사용자가 돌려받는 텍스트에는 포함되지 않기 때문입니다. 두 개의 토큰으로 구성된 답변이라도 수십 개에서 수천 개의 청구 대상 추론 토큰을 포함할 수 있습니다. 실제 출력 비용을 확인하려면 completion_tokens_details.reasoning_tokens를 읽거나 (total_tokens − prompt − completion으로 계산), 작업이 허용하는 범위 내에서 다이얼을 낮추십시오.

Gemini 3.6 Flash인가요, 아니면 Claude Haiku 4.5인가요?

두 모델은 유사한 가격대의 동일한 빠른 계층 (fast-tier) 슬롯을 차지하고 있으며, 선택은 단일 승자가 아닌 워크로드 (workload)에 따라 결정됩니다. 비용 관점에서 볼 때, 3.6 Flash의 사고 다이얼 (thinking dial)이 차별화 요소입니다. minimal 설정은 단일 단계 트래픽에서 비용을 한 자릿수만큼 저렴하게 만들며, 기본 설정 시에는 Haiku 4.5 ($1/$5)가 사용하지 않는 추론 비용을 소비합니다. 공개된 벤치마크에 따르면 Haiku 4.5는 코딩 깊이에서 우위를 점하고, 3.6 Flash는 수학 및 순수 토큰 가격에서 앞서 있습니다. 귀하의 트래픽이 무엇으로 구성되어 있는지에 따라 선택하고, 도입하기 전에 귀하의 작업으로 두 모델을 모두 측정해 보십시오.

Gemini 3.6 Flash가 3.5 Flash보다 저렴한가요?

네, 우리가 측정한 모든 워크로드에서 더 저렴했습니다. 다만 그 정도는 워크로드의 형태에 따라 다릅니다. 출력 비용은 $9/M에서 $7.50/M로 감소했으며, 추론 집약적인 짧은 작업의 경우 3.6은 출력 토큰 (output tokens)도 더 적게 사용하여 비용이 약 32% 감소했습니다. 에이전트 (agent) 트래픽의 경우 토큰을 약간 더 많이 사용했으나, 요율 인하만으로 약 6%의 절감 효과가 있었습니다. 어떤 경우든 더 저렴합니다. 마이그레이션(migrate)한 후 귀하의 믹스(mix)를 다시 측정해 보십시오. 모델군별 토큰당 비용 분해에 대해서는 우리의 token usage anatomy 연구를 참조하십시오.

Synthorai 게이트웨이를 통해 gemini-3.6-flash, gemini-3.5-flash, gemini-3.5-flash-lite 모델을 대상으로 2026-07-24에 측정되었습니다. 태스크 매트릭스 (task-matrix) 및 에이전트 스위트 (agent-suite) 토큰 수는 호출당 사용 기록을 기반으로 하며, 노력 조절 다이얼 (effort-dial) 결과는 솔트(salted) 처리된 5개 태스크 절제 실험 (ablation, 셀당 n=3)을 통해 도출되었습니다. 컨텍스트 (context) 및 캐시 (cache) 조사(probe)는 니들-리콜 (needle-recall) 및 프리픽스 스윕 (prefix sweeps)을 통해 수행되었습니다. 정확도(Accuracy) 카운트는 단일 확인 가능한 정답이 있는 태스크를 사용했습니다. 가격 및 동작은 변경될 수 있으므로, 귀하의 자체 사용 기록을 통해 확인하십시오.