Gemini thinking budget, 공식 문서를 살펴보았습니다.

budget을 512로 잡았는데, 이 숫자가 뭔지 몰랐다

이전 글에서 RAG 채팅 응답을 37초 → 16초로 줄인 이야기를 했습니다. 핵심 최적화 중 하나가 Gemini 2.5 Flash의 thinking budget을 질문 복잡도에 따라 동적으로 조절한 거였거든요.

그런데 글을 쓰고 나서 한 가지 찝찝한 게 남았습니다. "잡담은 0, 간단한 질문은 512, 보통 질문은 1024, 복잡한 질문은 2048"이라고 썼는데, 이 숫자들이 실제로 뭘 의미하는지 정확히 설명하지 못하겠더라고요.

512가 512토큰인 건 알겠는데, 모델이 이 범위 안에서 어떻게 동작하는 건지, 범위를 넘을 수도 있는 건지, 왜 0이 thinking OFF인 건지. 공식 문서를 제대로 읽어본 적이 없었습니다.

그래서 이번에 Gemini 공식 문서를 뜯어봤어요.

Gemini Thinking 공식 문서

thinking budget은 "상한선"이지 "고정값"이 아니다

가장 먼저 알게 된 건, budget이 "정확히 이만큼 생각해라"가 아니라 "최대 이만큼까지 생각해도 된다"라는 뜻이라는 점이었습니다.

budget을 1024로 설정하면 모델이 무조건 1024토큰을 써서 생각하는 게 아니에요. 모델이 스스로 "이 질문은 300토큰이면 충분하겠다"고 판단하면 300토큰만 쓰고, "이건 1024토큰 다 써야겠다"고 판단하면 전부 씁니다.

공식 문서에서 인상적이었던 건 이 문장이에요. "모델은 주어진 프롬프트의 복잡도에 따라 얼마나 생각할지를 스스로 결정하도록 훈련되어 있다." 즉, budget은 모델의 판단에 천장만 씌우는 거지, 바닥을 강제하는 게 아닌 거죠.

그리고 한 가지 더 — budget을 넘거나(overflow) 미달(underflow)할 수 있다고 명시돼 있습니다. budget을 512로 잡아도 모델이 600토큰을 쓸 수 있고, 200토큰만 쓸 수도 있다는 거예요. 완전한 하드 리밋이 아니라 가이드라인에 가깝습니다.

이걸 알고 나니까, "budget을 얼마로 잡아야 하나"에 대한 접근이 달라졌어요. 정밀한 값을 찾으려고 할 필요가 없고, 대략적인 범위만 맞추면 모델이 알아서 조절한다는 걸 이해하게 됐거든요.

모델마다 budget 범위가 다르다

공식 문서를 보면서 놀랐던 게, 모델별로 budget 설정 범위가 전부 다르다는 점이었습니다.

여기서 중요한 차이점이 두 가지 있어요.

첫째, 2.5 Pro는 thinking을 끌 수 없습니다. 최소값이 128이에요. Pro는 항상 어느 정도는 생각하도록 설계된 거죠. 반면 Flash와 Flash-Lite는 0으로 설정해서 완전히 끌 수 있습니다.

둘째, Flash-Lite는 기본값이 thinking OFF입니다. 다른 모델들은 기본적으로 동적 thinking이 켜져 있는데, Flash-Lite만 명시적으로 켜야 합니다. 속도와 비용에 최적화된 모델이니까, thinking은 필요할 때만 쓰라는 설계 의도가 보이더라고요.

그리고 하나 더 — budget을 -1로 설정하면 동적 thinking이 켜집니다. 이게 기본값과 같은 건데, 모델이 질문 복잡도에 따라 자동으로 budget을 조절하는 모드예요. 동적 thinking이 켜진 상태에서 최대 thinking 토큰은 8,192로 고정됩니다.

비용은 full thought 기준으로 부과된다

thinking budget을 다루면서 반드시 알아야 하는 게 비용 구조입니다.

Gemini는 thought summary라는 기능이 있어요. 모델이 생각한 과정의 요약본을 response에 포함시킬 수 있는 건데, API에서 돌아오는 건 이 요약본입니다.

그런데 비용은 요약본이 아니라 full thought 기준으로 부과됩니다. 모델이 내부적으로 2,000토큰을 써서 생각하고 그걸 500토큰으로 요약해서 돌려줘도, 요금은 2,000토큰 기준이에요.

이게 왜 중요하냐면, budget을 높게 잡으면 보이지 않는 비용이 생긴다는 뜻이거든요. 응답에는 요약본 500토큰만 보이니까 "별로 안 쓴 것 같은데?"라고 생각할 수 있는데, 실제 청구는 full thought 기준입니다.

비용 계산식은 이렇습니다.

응답 비용 = 출력 토큰 + thinking 토큰 (full thought 기준)

usage_metadata.thoughts_token_count로 실제 thinking 토큰 수를 확인할 수 있으니까, 비용 최적화를 하려면 이 값을 모니터링해야 합니다.

이 구조를 알고 나니까, "budget을 높게 잡아도 모델이 알아서 조절하니까 괜찮겠지"라는 생각이 위험하다는 걸 깨달았어요. budget을 24,576으로 잡아두면 모델이 복잡한 질문에서 실제로 20,000토큰을 쓸 수 있고, 그만큼 비용이 나가거든요.

Gemini 3에서는 thinkingLevel로 바뀐다

문서를 읽으면서 한 가지 더 발견한 게 있는데, Gemini 3 모델에서는 thinkingBudget 대신 thinkingLevel을 쓰도록 바뀌었습니다.

토큰 수를 직접 지정하는 대신, 추상적인 레벨로 바뀐 거예요. 공식 문서에서는 "Gemini 3 모델에 thinkingBudget을 쓰면 하위 호환은 되지만 성능이 최적이 아닐 수 있다"고 경고하고 있습니다.

이건 실무적으로 중요한 포인트예요. 지금 thinkingBudget으로 동적 조절 로직을 짜놨다면, Gemini 3으로 마이그레이션할 때 thinkingLevel 기반으로 전환해야 하거든요. 우리 프로젝트도 결국 이 전환을 해야 할 거예요.

그래서 우리 프로젝트에서는 어떤 기준으로 잡았나

공식 문서의 best practice를 보면, 작업 난이도를 세 단계로 나누고 있습니다.

Easy (분류, 팩트 검색) → thinking OFF

Medium (비교, 유추) → 기본값/적당한 budget

Hard (수학, 코딩) → 높은 budget

우리 RAG 파이프라인에 이걸 매핑하면 이렇거든요.

처음에 이 값들을 감으로 잡았는데, 문서를 읽고 나서 보니까 방향은 맞았어요. 다만 몇 가지 조정이 필요했습니다.

첫째, 최대값을 2048보다 더 올려도 됩니다. Flash 기준 최대가 24,576이니까 2048은 보수적인 편이에요. 복잡한 질문에서 답변 품질이 부족하다면 4096이나 8192까지 올려볼 수 있습니다.

둘째, -1(동적 thinking)도 선택지입니다. 검색 결과 건수 기반 조절이 귀찮으면, budget을 -1로 두고 모델에게 맡기는 방법도 있어요. 다만 동적 thinking은 최대 8,192토큰까지 쓸 수 있어서, 비용을 타이트하게 관리하고 싶으면 직접 조절하는 게 낫습니다.

셋째, 의도분석/리랭크에는 budget 자체가 불필요합니다. 이 작업들은 gemini-2.0-flash(thinking 기능 없는 모델)를 쓰고 있어서, budget 설정이 아예 의미가 없어요. 모델 분리가 먼저고, budget 조절은 답변생성에만 적용하는 겁니다.

budget은 정밀하게 맞추는 게 아니라 범위를 잡는 것이다

공식 문서를 뜯어보면서 가장 크게 바뀐 인식은, thinking budget은 정밀 튜닝 대상이 아니라 대략적인 범위를 잡는 도구라는 점이었어요.

512와 600의 차이는 거의 없습니다. 모델이 알아서 조절하니까요. 중요한 건 "0이냐 아니냐", "500 수준이냐 2000 수준이냐"의 구간 차이예요. 구간만 맞추면 모델이 그 안에서 최적의 thinking을 합니다.

정리하면 세 가지를 기억하면 됩니다.

budget은 상한선이지 고정값이 아닙니다. 모델이 알아서 조절하되, 천장만 정해주는 겁니다

비용은 full thought 기준입니다. summary만 보고 "적게 썼네"라고 판단하면 안 됩니다. thoughts_token_count를 모니터링하는 게 좋습니다

Gemini 3에서는 thinkingLevel로 바뀝니다. 지금 budget 기반 로직을 짜고 있다면, level 기반 전환도 미리 생각해두는 게 좋습니다

Gemini Thinking 공식 문서
Google Developers Blog — Gemini 2.5 Flash