Gemini 3.6 Flash: 비용을 30배 바꾸는 Thinking 다이얼 실측

Gemini 3.6 Flash는 답변 token뿐 아니라 thinking token에도 요금을 부과하며, 요청마다 사용량을 직접 조절할 수 있다. 동일한 120단어 작성 작업의 비용은 기본 설정에서 $0.03316, minimal 설정에서 $0.00110이었다. 결과물은 독자가 구분하기 어려웠지만 비용은 30배 차이였다. 이 다이얼은 이 모델의 비용을 좌우하는 가장 중요한 설정이며, 한 가지 뚜렷한 함정도 있다. Gemini 3.6 Flash는 2026-07-21에 정식 출시됐다. 가격은 입력 token 100만 개당 $1.50, 출력 token 100만 개당 $7.50으로, 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배 차이가 났다. 단일 단계, structured output, tool calling 작업에서는 정확도 손실이 없었지만, 다단계 수학 문제의 정확도는 3/3 → 0/3으로 떨어졌다.
• Google의 “출력 token 17% 감소” 주장은 워크로드에 따라 달라진다. reasoning 비중이 높은 작업에서는 token이 19% 줄고 비용은 32% 낮아졌다. agent 테스트에서는 token이 9% 늘었지만 비용은 6% 낮아졌다.
• 1M 컨텍스트 윈도우는 실제로 제공된다. 972K token에 배치한 needle도 정확히 찾아냈다. prompt caching도 Google이 공개한 4,096-token 최소 기준과 정확히 일치했다. “1M 컨텍스트”를 표방하면서 실제 지원량은 부족한 일부 모델과 달리 사양대로 동작했다.

아래 결과는 모두 2026-07-24에 Synthorai gateway를 통해 측정했다. 반복 prompt에는 cache를 피하기 위해 salt를 추가했으며, 모든 수치는 원본 usage record로 확인했다.

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

출력 비용의 대부분은 reasoning에서 발생하며, 사용자에게 보이지 않아도 요금은 청구된다. 기본 effort에서 모델은 답변보다 thinking에 훨씬 많은 token을 사용한다. 이 reasoning token에는 출력과 동일한 $7.50/M 요금이 적용된다.

핵심은 이 패턴이다. 사실을 답하는 2-token 응답에도 reasoning token 69개가 붙었고, 120단어 문단에서는 글을 쓰는 데 사용한 token보다 thinking에 사용한 token이 30배 많았다. Reasoning token 수는 completion_tokens_details.reasoning_tokens에서 확인할 수 있지만, 내용은 공개되지 않는다. Gemini는 thinking 요약이나 trace를 전혀 반환하지 않는다. token 사용량 구조 조사에서 확인한 모델 중 가장 폐쇄적인 방식이다. Kimi K3는 전체 chain of thought를 반환하고, GPT-5.6은 요약을 반환한다. 다음 섹션에서는 이 비용을 줄이는 방법을 살펴본다.

Thinking 다이얼은 실제로 어떻게 동작하는가?

비용은 설정 단계에 따라 일관되게 달라졌으며, 대부분의 작업에서는 정확도 저하 없이 큰 폭으로 줄일 수 있었다. reasoning_effort 또는 native 설정인 thinking_config.thinking_level을 minimal로 지정하자 reasoning token이 0으로 내려갔고, 작업당 비용은 91-97% 감소했다.

다이얼에서 사용할 수 있는 값은 minimal, low, medium(기본값), high다. 테스트에서는 단계가 높아질수록 reasoning token도 일관되게 늘었다. minimal은 0 token, low는 약 180, medium은 약 530, high는 약 650이었다. 문제는 minimal에서는 thinking이 불가능하다는 점이다. 다단계 산술 문제에는 중간 추론이 필요하다. 연필과 가방이 나오는 문장형 문제에 짧게 답하도록 강제하자 3번 모두 틀렸고, 하나의 일관된 실수가 아니라 매번 다른 오답을 냈다. 반면 retrieval, classification, formatting, 단일 단계 질문에서는 정확도를 유지하면서 비용을 10분의 1 수준으로 줄였다.

실무 기준은 Kimi K3에서 확인한 결과와 같다. extraction, lookup, formatting에는 minimal을 기본값으로 선택해도 무리가 없지만, 중간 단계가 필요한 작업에는 위험한 설정이다. 전역으로 적용하지 말고 route별로 설정해야 한다. reasoning 비중이 높은 작업에 배포하기 전에는 자체 데이터로 정확도를 검증해야 한다.

호출량이 많은 대표적인 운영 패턴인 structured output과 function calling을 보면 효과가 더 명확하다. 둘 다 기본 설정에서는 reasoning token을 사용하지만, minimal로 실행해도 문제가 없었다. JSON schema를 지정한 schema-constrained extraction(response_format)은 기본 설정에서 reasoning token 337개를 청구하고 유효한 JSON을 반환했다. minimal에서는 reasoning token이 0이었고, 여전히 schema에 맞는 유효한 JSON을 반환했으며, 비용은 9배 낮았다. Function call도 같았다. 기본 설정에서는 reasoning token 74개를 사용해 올바른 get_weather(city) 호출을 생성했다. minimal에서는 reasoning token 없이 동일한 호출을 생성했고 비용은 4배 낮았다. 둘 다 겉으로는 “structured” 작업이지만 실제로는 단일 단계다. 지정된 field를 채우는 데 별도의 thinking은 필요하지 않다. 트래픽 대부분이 extraction이나 tool routing이라면 minimal로 비용을 거의 그대로 절감할 수 있다.

”출력 token 17% 감소” 주장은 실제로 맞는가?

워크로드에 따라 다르며, 테스트 유형별 결과 차이가 뚜렷했다. Google은 출시 당시 3.6 Flash가 Artificial Analysis Index에서 3.5 Flash보다 출력 token을 약 17% 적게 사용한다고 밝혔다. 개별 agentic 평가에서는 최대 65%까지 줄어든다고 설명했다. 자체 테스트베드 2개에서 두 모델을 실행한 결과, 서로 반대 방향의 수치가 나왔다.

Reasoning 비중이 높은 짧은 작업에서는 공개 수치보다 더 크게 개선됐다. 전체 출력 token은 19% 줄어 Google이 밝힌 17%와 비슷했으며, 감소분은 대부분 답변이 아니라 thinking에서 나왔다. 두 모델을 같은 조건에서 다시 실행해 출력 token을 분리해 보니, 사용자에게 보이는 답변은 4%만 줄었지만 reasoning은 19% 감소했다. 특히 수학과 글쓰기 작업에서 차이가 컸다. 3.6은 같은 결과에 도달하면서 추론량을 줄였다. 이 결과가 benchmark 개선의 원인이다. Thinking budget 의존도가 높은 작업에서 3.6은 같은 수준의 답변을 더 효율적으로 생성한다.

Agentic multi-turn 트래픽에서는 방향이 반대였다. 전체 테스트에서 3.6은 3.5보다 출력 token을 약 9% 더 사용했다. 효율 개선은 reasoning 단계에 집중되어 있다. Agent loop는 전체 budget에서 reasoning이 차지하는 비중이 작기 때문에 절감 여지가 적고, 3.6의 turn이 조금 더 길어진 효과가 더 크게 나타났다. 그래도 최종 비용은 두 경우 모두 낮아졌다. 다만 원인이 다르다. Reasoning 비중이 높은 작업은 token 감소와 $9→$7.50 요금 인하가 함께 적용돼 32% 절감됐다. Agent 트래픽은 사실상 요금 인하만으로 6% 절감됐다. “출력 token 17% 감소”는 thinking이 출력의 대부분을 차지하는 워크로드에서는 맞지만, 그렇지 않은 워크로드에서는 반대로 나타난다. 공개 수치를 그대로 가정하지 말고 실제 트래픽 구성으로 측정해야 한다. 앞서 설명한 다이얼은 버전 변경보다 비용에 훨씬 큰 영향을 준다.

1M 컨텍스트 윈도우는 실제로 제공되는가?

그렇다. 한도를 넘으면 조용히 내용을 버리지 않고 명확한 오류를 반환한다. 크기를 점점 늘린 prompt의 앞부분에 recall needle을 넣었다. 입력이 972K token일 때도 정확히 찾아냈다. 한도를 초과한 prompt에는 내용을 임의로 자르는 대신 400 input token count exceeds the maximum 오류를 반환했다. 시중의 모든 “1M 컨텍스트” 모델이 실제 endpoint에서 광고한 크기를 제공하는 것은 아니기 때문에 중요한 차이다. 테스트를 재현할 때는 문장 형태의 다양한 filler로 padding해야 한다. 단일 token을 반복해 만든 prompt는 크기 제한에 도달하기 훨씬 전부터 모델이 무의미한 출력을 반복하게 만들었다.

Prompt caching도 핵심 수치가 사양과 일치했다. Google 문서에는 Flash 모델의 context caching 최소 길이가 4,096 token으로 명시돼 있다. 테스트 결과도 정확히 같았다. 약 2.1K 이하의 prefix는 cache되지 않았고, 약 4.1K token부터 hit가 발생했다. 각 hit에서는 마지막 약 2.1K가 cache되지 않은 상태로 남았다. Cache warm-up에는 5~8회 호출이 필요했다. Cached input read 가격은 $0.15/M으로, 신규 입력 요금 $1.50의 10분의 1이다. 이전에 측정한 일부 모델은 공개 사양보다 endpoint의 실제 지원 범위가 작았다. 반면 Gemini 3.6 Flash의 cache 최소 길이와 1M 컨텍스트 윈도우는 모두 문서대로 동작했다. Caching은 길고 안정적인 prefix에만 실질적인 이점이 있다. 또한 Flash 계열은 automatic(implicit) caching만 지원하고 explicit cached-content API는 지원하지 않는다. 따라서 큰 문서를 수동으로 고정해 최소 길이 아래에서 재사용할 수는 없다.

Gemini 3.5 Flash-Lite는 어디에 적합한가?

Flash-Lite는 비용을 예측하기 쉬운 tier다. 보이지 않는 reasoning token을 사용하지 않으므로 요금이 사용자에게 보이는 출력량과 일대일로 대응한다. 같은 다단계 수학 문제에서 Flash-Lite의 비용은 $0.00057, 3.6 Flash의 기본 설정은 $0.00368이었다. Flash-Lite가 약 6배 저렴했다. 또한 추론 과정이 hidden reasoning field가 아니라 출력에 드러났다. 가격은 입력 $0.30/M, 출력 $2.50/M이다. 호출량이 많고 latency에 민감한 단일 단계 작업에는 Flash-Lite를 기본으로 사용하면 된다. 작업에 reasoning이 필요할 때 3.6 Flash로 올리고 다이얼을 조정하는 방식이 적합하다. Tokenizer는 새 모델 3개뿐 아니라 Gemini 2.5 Flash부터 바뀌지 않았다. 확인한 모든 세대에서 영어, 중국어, 일본어, 한국어, Python의 token 수가 동일했다. 따라서 2.5를 기준으로 만든 언어별 budget은 기준을 다시 잡지 않고도 3.6에 그대로 적용할 수 있다.

자주 묻는 질문

Gemini 3.6 Flash에서 reasoning을 완전히 끌 수 있는가?

테스트에서는 reasoning_effort: "minimal" 또는 thinking_level: "minimal"을 사용했을 때 reasoning token이 0으로 내려갔다. 다이얼의 최저 단계이며, 사용 가능한 값은 minimal, low, medium, high다. 별도의 “disabled” 상태는 없다. Reasoning을 강제로 비활성화하려는 요청은 upstream에서 거부된다. 따라서 minimal이 가능한 최저 설정이며, 단일 단계 작업에는 충분히 낮다.

화면에 보이는 답변보다 Gemini 요금이 더 많이 나오는 이유는 무엇인가?

Reasoning token에는 출력과 동일한 요금이 부과되지만 반환되는 text에는 포함되지 않기 때문이다. 답변 자체는 2 token이어도 과금되는 reasoning token은 수십 개에서 수천 개에 이를 수 있다. completion_tokens_details.reasoning_tokens를 확인하거나 total_tokens − prompt − completion으로 계산하면 실제 출력 비용을 확인할 수 있다. 작업 특성상 가능하다면 다이얼을 낮춰야 한다.

Gemini 3.6 Flash와 Claude Haiku 4.5 중 어느 쪽을 선택해야 하는가?

둘 다 가격대가 비슷한 fast tier이며, 절대적인 우위보다 워크로드에 따라 선택이 갈린다. 비용 관점에서 3.6 Flash의 차별점은 thinking 다이얼이다. minimal은 단일 단계 트래픽의 비용을 10분의 1 수준으로 낮춘다. 반면 기본 설정에서는 reasoning 비용이 발생한다. $1/$5인 Haiku 4.5에는 이 비용이 없다. 공개 benchmark에서는 Haiku 4.5가 깊이 있는 coding에서 앞서고, 3.6 Flash는 수학과 순수 token 가격에서 앞선다. 실제 트래픽의 작업 유형에 따라 선택하고, 결정하기 전에 자체 작업으로 둘 다 측정해야 한다.

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

측정한 모든 워크로드에서 저렴했다. 절감 폭은 작업 유형에 따라 달랐다. 출력 요금이 $9/M에서 $7.50/M으로 낮아졌다. Reasoning 비중이 높은 짧은 작업에서는 3.6이 출력 token도 적게 사용해 비용이 약 32% 줄었다. Agent 트래픽에서는 token을 조금 더 사용했으며, 약 6%의 절감은 요금 인하에서 나왔다. 어느 경우든 더 저렴하다. 마이그레이션한 뒤 실제 트래픽 구성으로 다시 측정해야 한다. 모델 계열별 token 비용 구성을 비교하려면 token 사용량 구조 조사를 참고하면 된다.

2026-07-24에 Synthorai gateway를 통해 gemini-3.6-flash, gemini-3.5-flash, gemini-3.5-flash-lite를 측정했다. 작업 매트릭스와 agent 테스트의 token 수는 호출별 usage record에서 가져왔다. Effort 다이얼 결과는 salt를 추가한 5개 작업의 ablation에서 측정했으며 각 cell의 n=3이다. 컨텍스트와 cache는 needle-recall 및 prefix sweep으로 테스트했다. 정확도는 정답을 하나로 검증할 수 있는 작업만 집계했다. 가격과 동작은 변경될 수 있으므로 자체 usage record로 확인해야 한다.

← 블로그로 돌아가기