Gemini '사고 과정' 완벽 이해: API 제어, 비용, 멀티턴 전략

1. Gemini의 핵심 정체성: '사고 과정'을 통한 추론 및 다단계 계획 수행 능력

Gemini의 핵심적인 정체성은 복잡한 문제 해결과 다단계 작업을 수행하기 위한 독자적인 '사고 과정' 활용 능력에 기반을 두고 있습니다.
이는 단순한 정보 검색이나 패턴 인식 수준을 넘어, 인간과 유사한 추론 능력을 통해 복잡한 상황을 이해하고 최적의 해결책을 도출하는 Gemini만의 독보적인 강점입니다.
내부적인 사고 과정을 거쳐 문제의 본질을 파악하고 여러 단계를 거쳐 목표를 달성하는 이 능력은, 코딩, 고급 수학, 데이터 분석과 같은 고도의 복합적인 작업에서 특히 빛을 발합니다.
각 단계별로 심층적인 판단과 계획을 수립하고 실행함으로써, Gemini는 단순한 도구를 넘어 실제적인 문제 해결 파트너로서의 역할을 수행합니다.

'사고 과정'의 심층 작동 방식과 개발자 인터페이스

Gemini의 '사고 과정'은 모델이 내부적으로 여러 대안을 탐색하고, 논리적 추론을 통해 결정을 내리며, 다음 행동을 계획하는 일련의 과정을 의미합니다.
개발자는 Interactions API(정식 버전 출시 완료)를 통해 이 강력한 기능을 제어하고 활용할 수 있습니다.
특히, includeThoughts를 true로 설정하여 모델의 내부 사고 요약(Thought Summaries)을 받아볼 수 있습니다.
이 요약은 비스트리밍 방식에서는 단일 최종 사고 요약으로, 스트리밍 방식에서는 롤링 증분 요약으로 제공되어 모델이 어떻게 추론하고 있는지 실시간으로 파악할 수 있게 해줍니다.

모델의 '사고' 수준을 제어하기 위해 Gemini 3.x 모델에서는 thinkingLevel 매개변수를 사용합니다.
지원되는 사고 수준은 minimal, low, medium, high로 구분되며, 예를 들어 Gemini 3.1 Pro는 기본값으로 medium 또는 high(동적)을, Gemini 3.5 Flash는 medium을 사용합니다.
이러한 세밀한 제어는 개발자가 특정 작업의 복잡성에 따라 모델의 사고 자원을 최적화할 수 있도록 돕습니다.
반면, Gemini 2.5 모델의 경우 thinkingBudget 매개변수를 통해 사고 예산을 제어합니다.
2.5 Pro 모델은 128에서 32768까지의 예산 범위를 가지며, thinkingBudget = 0으로 설정하여 사고를 비활성화하거나 thinkingBudget = -1로 설정하여 동적 사고를 활성화할 수 있습니다.
이러한 유연한 제어는 모델의 성능과 비용 효율성 사이에서 균형을 맞추는 데 필수적입니다.

멀티턴 상호작용에서 Gemini의 '사고 과정' 연속성을 유지하는 데에는 사고 서명(Thought Signatures)이 핵심적인 역할을 합니다.
이 서명은 모델의 내부 사고 과정을 암호화한 표현으로, 이전 턴의 사고 컨텍스트를 다음 턴으로 전달하여 일관된 추론 흐름을 가능하게 합니다.
특히 함수 호출 서명은 반드시 재전달해야 하며, 이는 Gemini API가 기본적으로 상태 비저장(Stateless)이기 때문에 개발자가 명시적으로 컨텍스트를 관리해야 함을 의미합니다.
사고 사용이 설정되고 함수 호출(선언 포함)이 있을 때 Gemini 2.5 모델에서 사고 서명이 반환되며, Gemini 3 모델에서는 모든 유형의 파트에 대해 반환될 수 있어 더욱 정교한 컨텍스트 유지가 가능합니다.

종합 AI 에이전트로서의 Gemini

Gemini는 단순한 언어 모델을 넘어선 Google의 AI 어시스턴트로서 광범위한 역할을 수행합니다.
내부적인 '사고 과정'을 기반으로 글쓰기, 계획, 브레인스토밍 등 다양한 작업을 지원하며, 생성형 AI 기술을 활용하여 창의적이고 실용적인 결과물을 제공합니다.
특히, Google DeepMind에 의해 개발된 Gemini는 최첨단 인텔리전스와 행동을 결합하여 복잡하고 다단계의 워크플로 실행에 특화되어 있습니다.
이는 단순히 주어진 프롬프트에 응답하는 것을 넘어, 사용자의 목표를 이해하고 이를 달성하기 위한 구체적인 단계를 스스로 수립하고 실행하는 능력을 의미합니다.

Gemini Spark는 이러한 능력을 개인화된 AI 에이전트로 확장합니다.
사용자의 장기적인 목표를 받아들여 이를 관리 가능한 작은 단계로 분해하고, 앱 연동을 통해 실제 행동으로 옮길 수 있도록 지원합니다.
예를 들어, 복잡한 프로젝트 계획 수립부터 여행 일정 관리, 학습 목표 달성까지, Gemini Spark는 사용자의 생산성을 극대화하는 강력한 도구입니다.
또한, Gemini Live는 채팅 환경에 통합되어 말하기와 입력 간 작업 전환을 가능하게 함으로써, AI와의 상호작용을 더욱 자연스럽고 효율적으로 만듭니다.
2025년 9월부터 제공되고 있는 2.5 Flash Live 네이티브 오디오 프리뷰는 이러한 멀티모달 상호작용의 가능성을 더욱 확장하며, Gemini가 단순한 텍스트 기반 에이전트가 아닌 전방위적인 AI 동반자로 발전하고 있음을 보여줍니다.

'사고 과정'의 비용 및 제약 사항

Gemini의 '사고 과정'은 모델의 강력한 기능인 만큼, 그 활용에 대한 이해가 중요합니다.
사고가 사용 설정될 경우, API 호출에 대한 가격은 출력 토큰과 모델이 생성한 사고 토큰의 합계를 기준으로 책정됩니다.
이는 사고 요약만 출력되더라도 모델이 요약을 생성하기 위해 사용한 전체 사고 토큰이 비용에 반영됨을 의미하며, 개발자는 이를 통해 리소스 사용량을 정확히 예측할 수 있습니다.
thoughts_token_count 및 candidates_token_count와 같은 토큰 사용 메타데이터 필드는 이러한 비용 분석에 중요한 정보를 제공합니다.

한편, '사고 과정' 제어에는 일부 제약도 존재합니다.
예를 들어, Gemini 3.1 Pro 모델은 사고 사용을 완전히 중지할 수 없으며, Gemini 3 Flash 및 Flash-Lite 모델도 완전한 사고 사용 중지를 지원하지 않습니다.
마찬가지로 Gemini 2.5 Pro는 사고 사용 중지가 불가능하며, Gemini 2.5 시리즈 모델은 thinkingLevel 매개변수를 지원하지 않고 thinkingBudget을 사용해야 합니다.
또한, 모델이 프롬프트에 따라 토큰 예산을 초과하거나 부족하게 사용할 수 있으므로, 개발자는 이러한 변동성을 고려해야 합니다.
Gemini API가 상태 비저장이라는 점은 멀티턴 상호작용에서 사고 서명의 중요성을 더욱 부각시키며, 개발자는 수신된 모든 서명을 재전달하고, 서명이 있는 파트들을 함께 연결하거나 서명이 있는 파트와 서명이 없는 파트를 병합하는 것을 피해야 하는 등의 사고 서명 처리 규칙을 준수해야 합니다.
이러한 세부적인 이해를 통해 Gemini의 '사고 과정'을 최대한 활용하고 최적화할 수 있습니다.

2. 모델 버전별 '사고(Thinking)' 기능 제어: thinkingLevel vs. thinkingBudget

Google의 Gemini 모델군은 복잡한 작업을 처리하기 위한 핵심 역량으로 '사고 과정'을 활용하여 추론 및 다단계 계획 기능을 획기적으로 개선했습니다.
특히 코딩, 고급 수학, 데이터 분석과 같은 정교한 태스크에서 이 내부 사고 과정의 역할은 매우 중요합니다.
이러한 모델의 '사고' 기능을 제어하는 방식은 Gemini 모델군 버전에 따라 `thinkingLevel`과 `thinkingBudget`이라는 두 가지 주요 파라미터로 명확히 구분됩니다.

Gemini 3 모델군: 정교한 '사고 수준(thinkingLevel)' 제어

최신 Gemini 3 모델군에서는 `thinkingLevel` 파라미터를 사용하여 모델의 사고 깊이와 복잡성을 제어합니다.
이는 `minimal`, `low`, `medium`, `high`의 네 가지 수준으로 나뉘며, 사용자는 특정 작업의 요구사항에 맞춰 모델의 추론 강도를 조절할 수 있습니다.
각 사고 수준은 지원하는 모델과 기본 설정에 차이가 있습니다.

thinkingLevel: 세부 지원 모델 및 기본값

사고 수준	지원 모델	기본값 / 특징
minimal	Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Flash-Lite, Gemini 3.1 Flash-Lite 이미지, Gemini 3 Flash	Gemini 3.1 Flash-Lite (기본값), Gemini 3.1 Flash-Lite 이미지 (기본값) / 효율성 및 경량성 작업 적합
low	Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Pro, Gemini 3.1 Flash-Lite, Gemini 3 Flash	- / minimal보다 깊은 추론
medium	Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Pro, Gemini 3.1 Flash-Lite, Gemini 3 Flash	Gemini 3.1 Pro (기본값), Gemini 3.5 Flash (기본값) / 중간 복잡성 문제 해결
high	Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Pro, Gemini 3.1 Flash-Lite, Gemini 3 Flash	Gemini 3.1 Pro (기본값, 동적), Gemini 3 Flash (기본값, 동적), Gemini 3.1 Flash-Lite (동적) / 깊은 추론 및 동적 조절

다만, Gemini 3 모델군의 사고 기능 제어에는 일부 제한사항이 있습니다.
예를 들어, Gemini 3.1 Pro는 사고 기능을 완전히 사용 중지할 수 없으며, Gemini 3 Flash 및 Flash-Lite 모델군 역시 완전한 사고 사용 중지를 지원하지 않습니다.
이는 해당 모델들이 기본적으로 일정 수준 이상의 추론 능력을 전제로 설계되었음을 의미합니다.

Gemini 2.5 모델군: '사고 예산(thinkingBudget)'으로 제어

이전 세대인 Gemini 2.5 모델군에서는 `thinkingBudget` 파라미터를 사용하여 모델의 사고 과정을 제어합니다.
이는 '토큰' 단위의 예산을 할당하여 모델이 사고하는 데 사용할 수 있는 자원의 양을 직접적으로 지정하는 방식입니다.
Gemini 2.5 시리즈 모델은 `thinkingLevel` 매개변수를 지원하지 않으며, 오직 `thinkingBudget`만을 사용합니다.

thinkingBudget: 모델별 범위, 비활성화, 동적 설정

모델	`thinkingBudget` 지원 범위 (토큰)
2.5 Pro	128 ~ 32768
2.5 Flash, 2.5 Flash 프리뷰, Robotics-ER 1.6 프리뷰, 2.5 Flash Live 네이티브 오디오 프리뷰	0 ~ 24576
2.5 Flash Lite, 2.5 Flash Lite 프리뷰	512 ~ 24576

모델	`thinkingBudget = 0` (사고 비활성화)
2.5 Flash, 2.5 Flash 프리뷰, 2.5 Flash Lite, 2.5 Flash Lite 프리뷰, Robotics-ER 1.6 프리뷰, 2.5 Flash Live 네이티브 오디오 프리뷰	가능
Gemini 2.5 Pro	불가능 (최소한의 사고 과정 필수)

모델	`thinkingBudget = -1` (동적 사고) / 기본 동작
2.5 Pro	기본값으로 동적 사고 활성화
2.5 Flash, 2.5 Flash 프리뷰, Robotics-ER 1.6 프리뷰, 2.5 Flash Live 네이티브 오디오 프리뷰	기본값으로 동적 사고 활성화
2.5 Flash Lite, 2.5 Flash Lite 프리뷰	명시 설정 시 동적 사고 활성화, 미설정 시 기본적으로 사고하지 않음

사고 기능을 완전히 비활성화하려면 `thinkingBudget` 값을 0으로 설정합니다.
이는 2.5 Flash, 2.5 Flash 프리뷰, 2.5 Flash Lite, 2.5 Flash Lite 프리뷰, Robotics-ER 1.6 프리뷰, 2.5 Flash Live 네이티브 오디오 프리뷰 등 대부분의 Flash 및 Lite 계열 모델에서 가능합니다.
그러나 Gemini 2.5 Pro는 사고 기능을 완전히 사용 중지할 수 없으므로, 이 모델에서는 `thinkingBudget = 0` 설정이 지원되지 않습니다.
이러한 모델은 최소한의 사고 과정을 필수적으로 수행합니다.

모델이 상황에 맞춰 최적의 사고 예산을 동적으로 결정하도록 하려면 `thinkingBudget` 값을 -1로 설정합니다.
이는 2.5 Pro (기본값), 2.5 Flash (기본값), 2.5 Flash 프리뷰 (기본값), 2.5 Flash Lite, 2.5 Flash Lite 프리뷰, Robotics-ER 1.6 프리뷰 (기본값), 2.5 Flash Live 네이티브 오디오 프리뷰 (기본값) 등 많은 2.5 모델의 기본 동작 방식입니다.
다만, 2.5 Flash Lite 시리즈의 경우, `thinkingBudget`을 명시적으로 설정하지 않으면 모델이 기본적으로 사고하지 않도록 설계되어 있습니다.
이는 효율성을 극대화하기 위한 기본값으로 해석될 수 있습니다.

사고 기능 제어의 중요성 및 비용

모델의 '사고' 기능 제어는 단순히 성능을 넘어 비용 효율성에도 직접적인 영향을 미칩니다.
사고가 사용 설정될 경우, API 요청에 대한 가격은 최종 출력 토큰과 모델이 사고 과정에서 생성한 사고 토큰의 합계를 기준으로 책정됩니다.
특히 중요한 점은 API에서 사고 요약만 출력된다고 하더라도, 모델이 해당 요약을 생성하기 위해 사용한 전체 사고 토큰을 기준으로 가격이 산정된다는 것입니다.
개발자는 API 응답에서 `thoughts_token_count` 및 `candidates_token_count`와 같은 메타데이터 필드를 통해 토큰 사용량을 확인할 수 있습니다.
따라서 작업의 복잡성과 비용 제어 요구사항에 맞춰 `thinkingLevel` 또는 `thinkingBudget`을 신중하게 설정하는 것이 매우 중요합니다.

3. 개발자 가이드: Interactions API와 사고 서명(Thought Signature) 활용법

개발자가 Gemini의 강력한 추론 및 다단계 계획 기능을 활용하여 혁신적인 애플리케이션을 구축하기 위해서는 Interactions API와 사고 서명(Thought Signature)의 이해가 필수적입니다.
오늘날, Gemini는 단순한 생성형 AI를 넘어, 복잡한 태스크를 효과적으로 수행하고 개인화된 AI 에이전트로서의 역할을 수행하며 최첨단 인텔리전스를 제공하는 핵심 기술로 자리매김했습니다.
이 가이드에서는 Gemini를 효율적으로 연동하고 멀티턴 대화의 컨텍스트를 완벽하게 유지하는 방법에 대해 심층적으로 다룹니다.

Gemini 연동의 핵심: Interactions API로의 전환

Gemini 모델과의 상호작용을 위해 구글은 Interactions API를 권장하고 있으며, 이 API는 현재 정식 버전으로 출시되어 활발히 사용되고 있습니다.
이전에는 Gemini Generate Content API (Legacy)가 주로 사용되었으나, 복잡한 다단계 워크플로 실행에 특화된 Gemini의 최첨단 인텔리전스와 행동 결합 능력을 극대화하기 위해서는 새로운 Interactions API로의 전환이 필수적입니다.
Interactions API는 Gemini의 내부 '사고 과정'을 활용하여 추론 및 다단계 계획 기능을 획기적으로 개선하며, 코딩, 고급 수학, 데이터 분석 등 복잡한 태스크에서 뛰어난 효과를 발휘하도록 설계되었습니다.
따라서 개발자는 레거시 API 대신 Interactions API를 사용하여 Gemini의 잠재력을 최대한 발휘할 수 있습니다.

사고 서명(Thought Signature)의 본질과 역할

사고 서명(Thought Signature)은 Gemini 모델의 내부 사고 과정을 암호화하여 표현한 것으로, 멀티턴 상호작용에서 중요한 사고 컨텍스트를 유지하는 데 필수적인 요소입니다.
Gemini API는 본질적으로 상태 비저장(Stateless) 방식이므로, 개발자가 명시적으로 이전 턴의 정보를 전달하지 않으면 멀티턴 대화에서 모델이 이전 턴의 사고 컨텍스트에 직접 접근할 수 없습니다.
이러한 한계를 극복하기 위해 사고 서명은 모델이 복잡한 추론과 계획을 이어갈 수 있도록 돕는 일종의 '메모리' 역할을 수행합니다.
이를 통해 사용자와의 대화 흐름이 끊기지 않고, 모델이 보다 일관되고 심층적인 응답을 생성할 수 있게 됩니다.

모델 버전별 사고 서명 반환 조건

사고 서명이 모델로부터 반환되는 조건은 Gemini 모델 버전에 따라 다소 차이가 있습니다.
Gemini 2.5 모델의 경우, 사고 서명은 모델의 '사고' 기능이 사용 설정되어 있고 함수 호출(선언 포함)이 발생했을 때만 반환됩니다.
이는 Gemini 2.5가 특정 조건에서만 내부 사고 과정을 명시적으로 외부에 드러내는 방식을 채택했음을 의미합니다.
반면, Gemini 3 모델은 보다 유연하게 설계되어 모든 유형의 파트에 대해 사고 서명을 반환할 수 있습니다.
이러한 변화는 Gemini 3가 다양한 상호작용 시나리오에서 사고 컨텍스트를 더욱 폭넓게 활용할 수 있도록 지원하며, 개발자가 모델의 내부 작동 방식에 더 깊이 접근할 수 있는 기회를 제공합니다.

멀티턴 컨텍스트 유지를 위한 사고 서명 처리 규칙

Gemini API의 상태 비저장(Stateless) 특성으로 인해, 멀티턴 대화에서 사고 컨텍스트를 성공적으로 유지하려면 개발자가 사고 서명을 올바르게 처리하는 것이 매우 중요합니다.
가장 중요한 규칙 중 하나는 모델로부터 수신된 모든 사고 서명을 다음 요청으로 재전달(re-transmission)하는 것을 강력히 권장한다는 점입니다.
특히, 함수 호출과 관련된 사고 서명은 모델이 의도한 작업을 정확히 이해하고 이어서 수행하는 데 필수적이므로, 반드시 재전달해야 합니다.
또한, 사고 서명을 처리할 때는 특정 규칙을 엄격히 준수해야 합니다.

첫째, 서명이 있는 파트(parts with signatures)들을 임의로 함께 연결해서는 안 됩니다.
둘째, 서명이 있는 파트와 서명이 없는 파트를 병합하는 것도 금지됩니다.

이러한 규칙들을 지키지 않으면 모델의 사고 컨텍스트가 손상되어 의도하지 않은 응답이나 오류가 발생할 수 있습니다.

Gemini 모델의 '사고' 메커니즘 이해

Gemini 모델의 핵심 역량 중 하나는 추론 및 다단계 계획 기능 개선을 위한 내부 '사고 과정' 활용입니다.
이 '사고 과정'은 모델이 복잡한 문제를 단계적으로 분석하고, 가능한 해결책을 탐색하며, 최적의 응답을 구성하는 데 사용되는 내부적인 생각의 흐름을 의미합니다.
개발자는 includeThoughts 매개변수를 true로 설정하여 이 내부 사고 과정을 Thought Summaries 형태로 출력받을 수 있습니다.
Thought Summaries는 비스트리밍 방식에서는 단일 최종 사고 요약으로, 스트리밍 방식에서는 롤링 증분 요약으로 제공되어 모델이 어떤 과정을 거쳐 결과에 도달했는지 투명하게 파악할 수 있게 합니다.
이러한 기능은 특히 Gemini Spark와 같이 목표를 관리 가능한 단계로 분해하고 앱 연동을 통해 복잡한 워크플로를 실행하는 개인 AI 에이전트 개발에 큰 도움이 됩니다.

사고 수준 제어: Gemini 3 모델의 thinkingLevel

Gemini 3 모델에서는 thinkingLevel 매개변수를 통해 모델의 사고 수준을 세밀하게 제어할 수 있습니다.
이 매개변수는 'minimal', 'low', 'medium', 'high'의 네 가지 수준을 지원하며, 각 수준은 모델이 문제 해결에 얼마나 깊이 사고할지를 결정합니다.
예를 들어, Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Flash-Lite (기본값), Gemini 3.1 Flash-Lite 이미지 (기본값), Gemini 3 Flash 모델은 'minimal' 수준을 지원합니다.
'low' 수준은 Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Pro, Gemini 3.1 Flash-Lite, Gemini 3 Flash에서 사용 가능합니다.
'medium' 수준은 Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Pro (기본값), Gemini 3.1 Flash-Lite, Gemini 3 Flash에서 기본적으로 제공됩니다.
가장 높은 'high' 수준은 Gemini 3.6 Flash, Gemini 3.5 Flash, Gemini 3.1 Pro (기본값, 동적), Gemini 3.1 Flash-Lite (동적), Gemini 3 Flash (기본값, 동적) 모델에서 지원됩니다.
주의할 점은 Gemini 3.1 Pro는 사고 사용을 완전히 중지할 수 없으며, Gemini 3 Flash 및 Flash-Lite는 완전한 사고 사용 중지를 지원하지 않는다는 것입니다.
thinkingLevel이 명시되지 않을 경우, Gemini 3.1 Pro는 'high'가, Gemini 3.5 Flash는 'medium'이 기본값으로 적용됩니다.

사고 예산 제어: Gemini 2.5 모델의 thinkingBudget

Gemini 2.5 모델 시리즈에서는 thinkingBudget 매개변수를 사용하여 모델의 사고 예산을 제어합니다.
이 매개변수는 모델이 사고 과정에 할당할 토큰의 양을 결정하며, 각 모델마다 지원하는 범위가 다릅니다.
예를 들어, 2.5 Pro는 128~32768, 2.5 Flash와 2.5 Flash 프리뷰는 0~24576, 2.5 Flash Lite와 2.5 Flash Lite 프리뷰는 512~24576의 범위를 가집니다.
또한, Robotics-ER 1.6 프리뷰와 2.5 Flash Live 네이티브 오디오 프리뷰 (2025년 9월부터 제공 중)도 0~24576의 범위를 지원합니다.
모델의 사고 기능을 완전히 중지하려면 thinkingBudget = 0으로 설정하면 되지만, 이는 2.5 Flash, 2.5 Flash 프리뷰, 2.5 Flash Lite, 2.5 Flash Lite 프리뷰, Robotics-ER 1.6 프리뷰, 2.5 Flash Live 네이티브 오디오 프리뷰 모델에만 적용 가능합니다.
2.5 Pro는 사고 사용 중지가 불가능하며, Gemini 2.5 시리즈 모델은 thinkingLevel 매개변수를 지원하지 않고 오직 thinkingBudget만 사용합니다.
모델이 동적으로 사고 예산을 관리하도록 하려면 thinkingBudget = -1로 설정할 수 있으며, 이는 2.5 Pro (기본값), 2.5 Flash (기본값), 2.5 Flash 프리뷰 (기본값), Robotics-ER 1.6 프리뷰 (기본값), 2.5 Flash Live 네이티브 오디오 프리뷰 (기본값) 모델에서 기본 동작입니다.
반면, 2.5 Flash Lite 시리즈 모델의 경우, 기본적으로 모델이 생각하지 않도록 설정되어 있습니다.
개발자는 프롬프트에 따라 모델이 토큰 예산을 초과하거나 부족할 수 있다는 점을 인지하고 thinkingBudget을 신중하게 조절해야 합니다.

사고 활성화 시 비용 모델

Gemini API를 통해 사고(thinking) 기능이 활성화될 경우, API 사용에 대한 비용은 출력 토큰과 사고 토큰(thoughts_token_count)의 합계를 기반으로 계산됩니다.
이는 API에서 사고 요약만 출력된다고 하더라도, 모델이 해당 요약을 생성하기 위해 내부적으로 사용한 전체 사고 토큰 양을 기준으로 가격이 책정됨을 의미합니다.
따라서 개발자는 includeThoughts 설정을 true로 하거나 thinkingBudget 또는 thinkingLevel 매개변수를 조정할 때, thoughts_token_count 메타데이터 필드를 주의 깊게 모니터링하여 예상치 못한 비용 증가를 방지해야 합니다.
모델의 복잡한 추론 과정은 더 많은 사고 토큰을 발생시킬 수 있으므로, 효율적인 비용 관리를 위해 필요한 경우에만 사고 기능을 활성화하고 적절한 사고 수준/예산을 설정하는 것이 중요합니다.

4. 실사용자를 위한 핵심 정보: 토큰 기반 과금 체계와 주요 제한 사항

Gemini 모델을 효율적으로 활용하고 예측 가능한 비용 관리를 위해서는 토큰 기반 과금 체계와 모델의 주요 제약 사항을 정확히 이해하는 것이 필수적입니다.
특히, Gemini의 핵심 역량인 '추론 및 다단계 계획 기능'을 구현하는 내부 '사고 과정'이 어떻게 과금으로 이어지는지 숙지해야 합니다.
이러한 정보는 사용자가 불필요한 비용 지출을 막고, 복잡한 태스크를 최적화하는 데 중요한 지침이 될 것입니다.

사고 토큰 기반 과금 체계의 이해

Gemini 모델의 과금은 단순히 최종 결과물로 출력되는 토큰 수에만 국한되지 않습니다.
가장 중요한 과금 기준은 모델 내부에 '사고 기능'이 활성화될 경우, 출력 토큰과 모델이 내부적으로 생성한 '사고 토큰'의 합계로 이루어진다는 점입니다.
이는 사용자가 'includeThoughts' 설정을 통해 사고 요약을 받든 받지 않든, 모델이 추론 과정을 거치기 위해 사용한 모든 내부 토큰에 대해 비용이 청구된다는 의미입니다.

다시 말해, API 응답으로 단일 최종 사고 요약이나 롤링 증분 요약 등 사고 요약만 출력된다고 하더라도, 모델이 그 요약을 생성하기 위해 내부적으로 발생시킨 전체 사고 토큰이 가격 책정의 기준이 됩니다.
따라서 사용자는 최종 출력 토큰뿐만 아니라, 모델의 복잡한 추론 과정에 투입된 '사고 토큰'의 양까지 고려하여 비용을 예측해야 합니다.
이는 특히 코딩, 고급 수학, 데이터 분석 등 복잡하고 다단계의 워크플로를 실행하는 데 특화된 Gemini의 경우 더욱 중요합니다.

모델별 사고 기능 제어 및 제약 사항

Gemini 모델은 내부 사고 과정을 제어할 수 있는 매개변수를 제공하지만, 모델 버전에 따라 그 기능과 제약이 다릅니다.
이를 정확히 아는 것은 비용 효율적인 모델 사용에 직결됩니다.

Gemini 3 시리즈 모델의 사고 제어

• Gemini 3.1 Pro 모델은 사고 사용 중지가 불가합니다.
  기본 `thinkingLevel`은 `high`이며, 필요에 따라 동적으로 조정됩니다.

• Gemini 3 Flash 및 Flash-Lite 모델 또한 완전한 사고 사용 중지를 지원하지 않습니다.
  이 모델들은 `minimal` 사고 수준이 기본값으로 설정되어 있거나, `high` 수준에서 동적으로 작동할 수 있습니다.

• 이러한 제약은 Gemini 3 모델이 기본적으로 어느 정도의 내부 추론 과정을 필수로 거치도록 설계되었음을 의미하며, 이는 복잡한 태스크 처리 능력의 핵심이기도 합니다.

Gemini 2.5 시리즈 모델의 사고 제어

Gemini 2.5 시리즈 모델은 `thinkingBudget` 매개변수를 사용하여 사고 기능을 제어합니다.
이 모델들은 `thinkingLevel` 매개변수를 지원하지 않습니다.

• 사고 사용 중지는 `thinkingBudget`을 0으로 설정하여 가능합니다.
  이는 2.5 Flash, 2.5 Flash 프리뷰, 2.5 Flash Lite, 2.5 Flash Lite 프리뷰, Robotics-ER 1.6 프리뷰, 2.5 Flash Live 네이티브 오디오 프리뷰 모델에 적용됩니다.

• 하지만 Gemini 2.5 Pro 모델은 사고 사용 중지가 불가합니다.
  기본적으로 `thinkingBudget = -1` (동적 사고)으로 설정되어 있으며, 128에서 32768 토큰 범위 내에서 사고 예산을 조절할 수 있습니다.

• 2.5 Flash 모델 또한 기본적으로 `thinkingBudget = -1` (동적 사고)으로 설정되어 있으며, 0에서 24576 토큰 범위를 가집니다.

• 흥미롭게도 2.5 Flash Lite 시리즈 모델은 `thinkingBudget = -1`로 설정했을 때 모델이 생각하지 않는 것이 기본 동작입니다.
  이 모델들은 512에서 24576 토큰 범위 내에서 사고 예산을 조절할 수 있습니다.

• 이러한 차이점을 인지하고 각 모델의 특성에 맞춰 `thinkingBudget` 매개변수를 적절히 활용하는 것이 중요합니다.

토큰 예산의 변동성과 API의 상태 비저장 특성

토큰 예산 사용의 비예측성

모델이 내부적으로 사용하는 사고 토큰 예산은 프롬프트의 복잡도와 내용에 따라 유동적으로 변동할 수 있습니다.
즉, 설정된 토큰 예산을 모델이 초과하거나 부족하게 사용할 수 있으며, 이는 정확한 비용 예측을 어렵게 만드는 요소 중 하나입니다.
따라서 사용자는 모델의 응답 길이나 복잡성을 단순히 예측하여 토큰 예산을 고정하기보다는, 실제 사용량 변화에 대한 유연한 대응이 필요합니다.

API의 상태 비저장 특성과 컨텍스트 관리

Gemini API는 상태 비저장(stateless) 특성을 가집니다.
이는 API가 각 요청을 독립적으로 처리하며, 이전 턴의 상호작용 컨텍스트(특히 사고 과정)에 직접 접근할 수 없음을 의미합니다.
따라서 멀티턴(multi-turn) 대화와 같이 연속적인 상호작용에서 이전 턴의 사고 컨텍스트를 유지하기 위해서는 특별한 조치가 필요합니다.

이러한 컨텍스트 유지를 위해 '사고 서명(Thought Signatures)'이라는 메커니즘이 도입되었습니다.
사고 서명은 모델의 내부 사고 과정을 암호화한 표현으로, 멀티턴 상호작용에서 사고 컨텍스트를 유지하는 데 사용됩니다.
Gemini 2.5 모델의 경우, 사고 사용이 설정되고 함수 호출(선언 포함)이 있을 때 사고 서명이 반환되며, Gemini 3 모델에서는 모든 유형의 파트에 대해 반환될 수 있습니다.

사고 서명을 활용할 때 몇 가지 중요한 규칙을 준수해야 합니다.
우선, 수신된 모든 서명을 다음 턴에 재전달하는 것이 권장됩니다.
특히, 함수 호출 서명은 다음 요청에 필수적으로 재전달해야만 올바른 멀티턴 상호작용이 가능합니다.
또한, 서명이 있는 파트들을 함께 연결하거나, 서명이 있는 파트와 서명이 없는 파트를 병합하는 것은 금지되어 있습니다.
이러한 규칙을 준수하지 않으면 모델의 일관된 추론 과정을 방해하고 예기치 않은 동작을 유발할 수 있습니다.

요약하자면, Gemini 모델을 효과적으로 사용하려면 사고 토큰 기반의 과금 방식을 명확히 이해하고, 각 모델 버전별 사고 제어 매개변수의 특성 및 제한 사항을 숙지해야 합니다.
또한, API의 상태 비저장 특성으로 인해 발생하는 멀티턴 컨텍스트 관리의 중요성을 인지하고, 사고 서명 메커니즘을 올바르게 활용하여 효율적인 모델 상호작용을 구축해야 합니다.