Gemini 3.6 Flash: 비용을 30배 움직이는 사고량 다이얼 (측정 결과)

Gemini 3.6 Flash 는 답변에 더해 thinking token 에도 요금을 매기며, 얼마나 쓸지는 요청마다 직접 조절할 수 있는 다이얼이다. 같은 120 단어 작문 작업에서 기본 설정은 $0.03316，minimal 설정은 $0.00110 이 청구됐다. 독자가 구분할 수 없는 결과물에 대해 30배 차이가 난 셈이다. 이 다이얼은 이 모델에서 가장 중요한 비용 결정이며, 날카로운 함정 하나를 동반한다. Gemini 3.6 Flash 는 2026-07-21 에 정식 출시됐고, 가격은 입력 100 만 token 당 $1.50，출력 100 만 token 당 $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배 차이). 단일 단계, 구조화 출력, tool-calling 작업에서는 공짜나 다름없지만, 다단계 수학은 3/3 → 0/3 으로 무너뜨렸다.
• Google 이 말하는 “출력 token 17% 감소”는 워크로드에 따라 다르다. 추론이 많은 우리 작업은 19% 가벼워졌고 (32% 저렴), 에이전트 스위트는 9% 무거워졌다 (6% 저렴).
• 1M context 는 실제였다 (972K token 위치의 needle 을 회수). prompt caching 도 Google 이 공표한 4,096 token 하한과 정확히 일치했다. 광고한 값에 못 미치는 일부 “1M context” 모델들과 달리 스펙이 깔끔하게 맞았다.

아래 내용은 2026-07-24 에 Synthorai 게이트웨이를 통해 측정했으며, 반복 프롬프트에는 캐시를 무력화하려고 salt 를 넣었다. 모든 수치는 raw usage 기록으로 뒷받침된다.

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

출력 요금은 추론이 지배하며, 눈에 보이든 안 보이든 요금이 매겨진다. 기본 effort 에서 모델은 답하는 것보다 훨씬 많은 token 을 사고에 쓰고, 이 reasoning token 은 $7.50/M 출력 요율 전액으로 청구된다.

여기서 새겨둘 패턴은 이것이다. token 두 개짜리 사실 답변에도 69 개의 추론 token 이 붙었고, 120 단어 문단은 쓰는 것보다 30배 많은 token 을 사고에 썼다. reasoning token 은 completion_tokens_details.reasoning_tokens 에 항목으로 잡히므로 개수는 볼 수 있지만 내용은 절대 볼 수 없다. Gemini 는 thinking 요약도 trace 도 전혀 반환하지 않는다. 우리가 token 사용 해부 연구에서 정리한 스펙트럼에서 가장 폐쇄적인 끝단이다. 그 연구에서 Kimi K3 는 전체 chain of thought 를 반환하고 GPT-5.6 은 요약을 반환한다. 다음 절에서는 이 지출을 낮추는 방법을 다룬다.

thinking 다이얼은 실제로 무슨 일을 하나

이건 진짜로 작동하는, 단조롭게 움직이는 비용 조절 장치다. 대부분의 작업 유형에서는 거의 공짜나 다름없다. reasoning_effort（또는 네이티브 thinking_config.thinking_level）를 minimal로 설정하면 reasoning 토큰이 0으로 떨어지고 작업당 비용이 91～97% 줄었다:

이 다이얼은 실제로 작동하고, 허용되는 값은 minimal, low, medium（기본값）, high다. 우리 측정에서는 단계를 올릴수록 reasoning이 단조롭게 늘었다（minimal 0 토큰, low 약 180, medium 약 530, high 약 650）. minimal이 못 하는 단 하나는 사고 자체다. 그런데 여러 단계 산수는 사고가 필요하다. 연필과 가방 문장제를 짧게 답하라고 강제하자 모델은 세 번 다 틀렸고, 일관된 한 가지 실수가 아니라 매번 다른 오답을 냈다. 반면 검색, 분류, 포매팅, 단일 단계 질문에서는 minimal이 정확도를 유지하면서 비용을 10분의 1로 줄였다.

실무 규칙은 Kimi K3에서 확인한 것과 같다. minimal은 추출, 조회, 포매팅에는 무난한 기본값이지만, 중간 단계가 필요한 작업에는 지뢰다. 전역이 아니라 라우트별로 설정하고, reasoning 비중이 큰 작업에 적용하기 전에는 자기 작업으로 정확도를 검증하라.

트래픽이 많은 프로덕션 패턴 두 가지가 이를 구체적으로 보여준다. 구조화된 출력과 함수 호출 둘 다 기본값에서는 reasoning을 소모하지만, 둘 다 minimal로 돌려도 안전하다. 스키마로 제약한 추출（JSON 스키마를 쓴 response_format）은 기본값에서 reasoning 토큰 337개를 청구하며 유효한 JSON을 반환했다. minimal에서는 reasoning이 0으로 청구되었고, 여전히 스키마에 맞는 유효한 JSON을 반환했으며, 비용은 9배 저렴했다. 함수 호출도 마찬가지였다. 기본값에서는 reasoning 토큰 74개와 함께 올바른 get_weather(city) 호출을 냈고, minimal에서는 reasoning 없이 같은 올바른 호출을 4배 싸게 냈다. 이들은 “구조화”로 포장된 단일 단계 작업이고, 채우라고 지정된 필드에 값을 넣는 데 모델이 굳이 사고할 필요는 없다. 그러니 트래픽이 추출이나 tool 라우팅이라면 minimal은 거의 공짜나 다름없다.

”출력 토큰 17% 감소” 주장은 사실인가?

워크로드에 따라 다르고, 그 차이가 시사하는 바가 크다. Google은 출시 당시 3.6 Flash가 Artificial Analysis Index 기준으로 3.5 Flash보다 출력 토큰을 약 17% 적게 쓴다고 홍보했다(개별 agentic 평가에서는 최대 65%). 우리는 자체 테스트베드 두 곳에 두 모델을 모두 돌려봤는데, 부호가 정반대로 나왔다:

reasoning 비중이 큰 짧은 태스크에서는 주장이 재현됐을 뿐 아니라 발표 수치를 뛰어넘었다. 총 출력이 19% 줄어 Google의 17%에 근접했고, 이 감소는 거의 전부 thinking에서 나왔지 답변에서 나온 게 아니었다. 두 모델을 짝지어 재실행하며 출력 토큰을 쪼개보니, 눈에 보이는 답변은 4%만 줄어든 반면 reasoning은 19% 줄었고, 그 감소는 3.6이 더 적은 숙고로 같은 결과에 도달하는 수학·글쓰기 태스크에 몰려 있었다. 이것이 벤치마크 뒤에 있는 메커니즘이다. thinking budget에 의존하는 작업에서 3.6은 같은 답변을 내면서도 실제로 더 효율적이다.

agentic한 멀티턴 트래픽에서는 부호가 뒤집힌다. suite 전체에서 3.6은 3.5보다 출력을 약 9% 더 썼다. 효율 향상은 reasoning 단계에 있는데, agent loop는 budget 중 reasoning에 쓰는 비중이 상대적으로 작다. 그래서 아낄 게 적고, 3.6의 살짝 더 긴 턴이 그 차이를 넘어선다. 어느 쪽이든 청구액은 줄지만, 두 효과가 다르게 겹치기 때문이다. reasoning 비중이 큰 태스크는 토큰과 $9→$7.50 요금 인하 양쪽에서 아끼고(−32%), agent 트래픽은 가격에서만 아낀다(−6%). 정직하게 정리하면, “출력 토큰 17% 감소”는 thinking이 출력을 지배하는 곳에서는 진짜고 그렇지 않은 곳에서는 뒤집힌다. 그러니 발표 수치를 그대로 믿지 말고 자기 워크로드 구성을 직접 측정하라. 그리고 앞 절에서 다룬 다이얼이 버전 업그레이드보다 이걸 훨씬 크게 움직인다는 점을 기억하라.

1M 컨텍스트 윈도우는 진짜인가?

그렇다. 게다가 조용히 실패하지 않고 요란하게 실패한다. 크기를 점점 키운 프롬프트의 맨 앞에 recall needle을 넣어봤다. 972K input 토큰에서도 여전히 정확히 회수됐고, 한도를 넘긴 프롬프트는 내용을 조용히 버리는 대신 깔끔하게 400 input token count exceeds the maximum를 반환했다. 시장에 나온 “1M 컨텍스트” 모델이 다 광고한 윈도우를 실제로 제공하는 건 아니기 때문에 짚어둘 만하다. 이걸 재현하려는 사람을 위한 테스트 팁 하나: 문장 형태의 다양한 filler로 채워라. 단일 토큰을 반복해 만든 프롬프트는 크기 한도에 도달하기 한참 전에 모델을 알아볼 수 없는 헛소리 상태로 밀어넣었다.

Prompt caching은 자동이고, 중요한 숫자에서 스펙과 일치한다. Google은 Flash 모델의 context caching에 4,096 토큰 최소치를 문서화했는데, 우리 스윕 결과도 정확히 거기에 떨어졌다. 2.1K 이하 prefix는 절대 캐시되지 않았고, 히트는 약 4.1K 토큰부터 시작됐으며, 58회 호출로 워밍업한 뒤 각 히트마다 마지막 ~2.1K 정도가 캐시되지 않은 채 남았다. 캐시된 input은 $0.15/M로 읽히는데, 신규 요금 $1.50 대비 10배 할인이다. 이건 안심되는 사례라 분명히 짚어둘 만하다. 우리가 측정한 일부 모델은 광고 수치가 엔드포인트의 실제 제공량을 과장했지만, Gemini 3.6 Flash의 캐시 하한과 1M 윈도우는 둘 다 문서 그대로 동작한다. 그래도 caching은 진짜로 길고 안정적인 prefix에서만 이득이고, Flash 티어는 자동(implicit) caching만 지원하고 명시적 cached-content API는 지원하지 않는다는 점에 유의하라. 큰 문서를 수동으로 고정해두고 하한 아래에서 재사용할 수는 없다.

Gemini 3.5 Flash-Lite는 어디에 쓰나

Flash-Lite는 비용을 예측할 수 있는 등급이다. reasoning token을 몰래 소모하는 일이 없어서 청구액이 눈에 보이는 output과 1:1로 맞아떨어진다. 같은 다단계 수학 문제에서 Flash-Lite는 $0.00057이 청구된 반면 3.6 Flash는 기본값으로 $0.00368이 나왔다. 약 6배 저렴하고, 답도 숨은 reasoning 필드가 아니라 밖으로 드러나게 계산한다. input $0.30/M, output $2.50/M으로, 대량 처리에 지연 시간이 중요한 단일 단계 작업의 기본값으로 알맞다. dial로 reasoning을 되살려야 하는 작업이라면 3.6 Flash로 올려라. tokenizer는 새 모델 세 개끼리는 물론 Gemini 2.5 Flash까지 거슬러 올라가도 그대로다. 우리가 확인한 모든 세대에서 영어, 중국어, 일본어, 한국어, Python의 token 수가 동일했으므로, 2.5용으로 잡아둔 언어별 예산을 재산정 없이 3.6에 그대로 쓸 수 있다.

FAQ

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

reasoning_effort: "minimal"(또는 thinking_level: "minimal")은 우리 테스트에서 reasoning token을 0으로 떨어뜨렸고, dial의 최저값이다. 허용되는 단계는 minimal, low, medium, high다. 별도의 “disabled” 상태는 없고, reasoning을 강제로 끄려는 시도는 upstream에서 거부된다. 그러니 minimal이 갈 수 있는 최저값이고, 단일 단계 작업에는 이 정도면 충분히 낮다.

Gemini 청구액이 눈에 보이는 답보다 큰 이유는?

reasoning token이 output 요율 전액으로 청구되는데 정작 돌려받는 텍스트에는 포함되지 않기 때문이다. token 두 개짜리 답이라도 수십에서 수천 개의 reasoning token이 청구될 수 있다. completion_tokens_details.reasoning_tokens를 확인하거나 total_tokens − prompt − completion으로 맞춰보면 실제 output 요금을 알 수 있다. 작업이 허용하는 선에서 dial을 낮춰라.

Gemini 3.6 Flash와 Claude Haiku 4.5 중 무엇을?

둘 다 비슷한 가격대의 빠른 등급 자리를 차지하고 있고, 갈림은 workload에 따라 나뉘지 어느 한쪽이 무조건 이기지 않는다. 비용 관점에서 3.6 Flash의 thinking dial이 차이를 만든다. minimal이면 단일 단계 트래픽에서 한 자릿수 배 더 저렴하고, 기본값으로는 $1/$5인 Haiku 4.5가 쓰지 않는 reasoning을 소모한다. 공개된 벤치마크에서는 코딩 깊이는 Haiku 4.5가 앞서고, 수학과 순수 token 가격은 3.6 Flash가 앞선다. 트래픽이 무엇으로 이뤄져 있는지에 맞춰 고르고, 결정하기 전에 자기 작업으로 둘 다 측정해봐라.

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

우리가 측정한 모든 workload에서 그렇다. 다만 얼마나 저렴한지는 작업 형태에 달렸다. output이 $9/M에서 $7.50/M으로 내렸고, reasoning이 많은 짧은 작업에서는 3.6이 output 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에서 측정. task-matrix와 agent-suite의 token 수는 호출별 usage 기록에서, effort-dial 결과는 salt를 넣은 5개 작업 ablation(셀당 n=3)에서, context 및 cache 테스트는 needle-recall과 prefix sweep에서 얻었다. 정확도 집계는 확인 가능한 단일 답이 있는 작업만 사용했다. 가격과 동작은 바뀔 수 있으니 자기 usage 기록으로 확인하라.

← 블로그로 돌아가기