Gemini thinking level, 질문에 따라 낮추고 높이는 기준

AI를 활용하여 생성한 이미지입니다.

핵심부터 말하면: Gemini API의 thinking_level은 답변에 사용할 추론 노력을 조절하는 설정입니다. 짧은 분류나 형식 변환은 낮은 수준부터 시작하고, 여러 조건을 비교하거나 코드·수학·계획을 다루는 요청은 높은 수준을 시험해 볼 수 있어요. 다만 높은 값을 고른다고 답이 자동으로 정확해지지는 않습니다. 모델과 요청 방식마다 지원하는 값과 기본 동작이 다르므로 공식 문서를 먼저 확인해야 합니다.[1]

thinking level이 바꾸는 것과 바꾸지 않는 것

Thinking 모델은 답을 내놓기 전에 복잡한 문제를 나누고 추론하는 과정을 거칩니다. Google은 Gemini 3 및 2.5 계열에서 복잡한 작업의 추론과 다단계 계획을 활용한다고 설명하며, API 사용자는 thinking_level로 그 동작을 조절할 수 있다고 안내합니다.[1] 이 설정은 모델의 지식 최신성이나 입력 자료의 진위를 보장하지 않아요. 틀린 자료를 더 오래 처리하면 더 길고 복잡한 오답이 될 수도 있습니다.

질문 유형별 출발점

표의 값은 모든 모델에 그대로 적용하는 규칙이 아닙니다. 현재 모델이 minimal·low·medium·high 중 무엇을 지원하는지 먼저 확인하세요. 지원하지 않는 값을 보내면 요청이 실패하거나 SDK가 설정을 무시할 수 있으므로, 오류가 나면 무작정 높은 값을 반복하지 말고 모델 문서와 요청 JSON의 위치를 대조하는 것이 먼저입니다.[1]

낮은 level이 잘 맞는 경우

입력과 출력의 관계가 단순하고 검토가 쉬운 작업이라면 낮은 level이 효율적입니다. 예를 들어 정해진 목록에서 카테고리 하나를 고르거나, 이미 제공한 문장을 짧게 요약하거나, JSON 형식으로 필드를 옮기는 작업은 긴 추론보다 명확한 스키마와 검증이 더 중요할 수 있어요. 출력 형식이 틀렸을 때 다시 요청하기 쉽도록 허용 값과 필수 필드를 애플리케이션에서 확인하세요.

짧은 질문에 높은 level을 고정하면 답변 품질의 이득보다 지연과 사용량 증가가 먼저 보일 수 있습니다. 특히 많은 사용자가 동시에 요청하는 서비스라면 먼저 낮은 수준을 기본으로 두고, 실패하거나 검증 부담이 큰 사례만 별도 경로로 올리는 방식이 운영하기 좋습니다.

높은 level을 시험할 경우

여러 조건을 동시에 만족해야 하거나, 반례를 찾아야 하거나, 단계가 서로 의존하는 코드·수학·계획 작업이라면 중간 또는 높은 수준을 비교해 볼 수 있습니다. 하지만 “더 오래 생각했다”는 사실을 정답의 증거로 사용해서는 안 됩니다. 계산 결과를 별도 코드로 확인하고, 코드라면 테스트를 실행하며, 계획이라면 일정·예산·권한 같은 입력 조건이 빠지지 않았는지 검토하세요.

비교할 때는 같은 모델, 같은 입력, 같은 출력 형식, 같은 도구 사용 조건을 고정하세요. 한 번은 낮은 level의 답을, 한 번은 높은 level의 답을 받은 뒤 정확성만 보지 말고 응답 시간, 토큰 사용량, 재시도 횟수, 사람이 수정한 부분까지 기록해야 실제 선택 기준이 됩니다.

API에서 적용하고 검증하는 순서

1. 사용할 모델의 공식 문서에서 thinking_level 지원 범위와 기본값을 확인합니다.
2. 현재 사용하는 SDK 또는 REST 요청에서 설정이 들어갈 위치를 확인합니다.[1][2]
3. 같은 입력을 낮은 수준과 높은 수준으로 각각 요청해 결과·지연·사용량을 기록합니다.
4. 응답을 JSON으로 받는다면 파싱과 스키마 검증을 별도로 수행합니다.
5. 높은 level의 답도 원문, 계산기, 테스트, 사람 검토로 확인합니다.

소비자용 Gemini 앱의 ‘생각하기’ 버튼과 Gemini API의 매개변수는 같은 화면이나 같은 기능 집합이 아닐 수 있습니다. 앱에서 보이는 선택지를 API 코드에 그대로 옮기지 말고, 개발자 문서와 실제 모델 응답을 기준으로 판단하세요.

잘못된 기대와 예외 상황

• 최신 뉴스나 가격처럼 입력 자체가 낡았다면 thinking level을 올려도 최신 정보가 생기지 않습니다.
• 질문이 모호하면 높은 수준이 누락된 조건을 스스로 지어낼 수 있으므로 필요한 조건을 먼저 명시하세요.
• 긴 문서를 넣는 문제는 추론량보다 컨텍스트 창, 입력 순서, 문서 품질이 더 큰 원인일 수 있습니다.
• 민감한 업무에서는 응답이 길어지는 것보다 데이터 접근 권한과 로그 보존 정책을 먼저 확인하세요.

간단한 비교 실험을 설계하는 법

thinking level의 차이를 보려면 질문을 바꿔 가며 인상만 비교하지 말고 작은 평가 세트를 만드세요. 단순 분류 다섯 건, 조건 비교 다섯 건, 코드나 수학처럼 검증 가능한 다섯 건처럼 작업 종류를 나누고, 같은 모델·같은 입력·같은 출력 형식을 유지합니다. 결과는 정답 여부만이 아니라 누락, 근거의 위치, 사람이 고친 횟수, 첫 토큰까지의 시간과 전체 응답 시간을 함께 기록하세요.

운영에서는 낮은 level을 기본값으로 두고, 출력 검증이 실패하거나 작업이 복잡하다고 분류된 요청만 다음 수준으로 보내는 단계적 전략을 고려할 수 있습니다. 다만 자동 승격 조건이 모델의 자기평가 문장 하나에만 의존하지 않도록 하세요. 필수 필드 누락, 테스트 실패, 조건 충돌처럼 애플리케이션이 확인할 수 있는 신호를 기준으로 삼고, 높은 level에서도 검증을 통과하지 못하면 사람에게 넘기는 종료 조건을 정해 두는 편이 안전합니다. 반대로 높은 level의 답이 지나치게 길어져 사람이 핵심을 놓친다면 출력 길이 제한과 요약 단계를 별도로 두세요. 추론 수준과 최종 답변의 길이는 같은 설정이 아닙니다. 설정을 바꾼 날짜와 모델 버전도 기록해야 나중에 결과 차이를 설명할 수 있습니다.

이력에는 요청 유형과 검증 결과도 함께 남겨야 같은 설정이 다른 작업에서 왜 달랐는지 설명할 수 있습니다.

비교 결과는 모델 변경 뒤 다시 확인하세요.

자주 묻는 질문

항상 high를 쓰면 가장 좋은가요?

아닙니다. 작업이 단순하면 지연과 사용량만 늘 수 있고, 입력이 부정확하면 오답을 더 그럴듯하게 만들 수 있습니다. 낮은 수준을 기준선으로 두고 실패 사례에만 높은 값을 비교하는 편이 안전합니다.

level을 바꾸면 사실 확인도 자동으로 되나요?

되지 않습니다. 모델의 추론량과 자료의 최신성·신뢰성은 다른 문제입니다. 최신 정보는 원문 출처와 날짜를 확인하고, 중요한 계산은 독립된 도구로 다시 검산하세요.

출처

1. Google AI for Developers, Thinking
2. Google AI for Developers, Text generation
3. Haechi, 추론 모델의 사용 기준
4. Haechi, 토큰과 컨텍스트 창