Gemini 4 Carbon API 개방: thinking 예산과 12월 요금 전환 점검
11월 10일 열린 Gemini 4 Carbon API의 전환 조건을 정리한다. thinking·출력 합산 한도, 캐시·샘플링 설정, 미완료 응답과 12월 1일 요금 변경을 점검하고 Python으로 토큰 비용을 계산한다.
추론에 쓰이는 자원을 계측하고 조절하는 과정을 표현한 생성형 개념 이미지. 실제 Gemini 제품 화면이나 내부 구조가 아니다.
Gemini 4 Carbon을 API에서 사용할 수 있는지가 달라졌다. Google은 November 10, 2026 일반 유료 개발자에게 제공을 시작했고, 공식 모델 문서에도 gemini-4-carbon이 등록됐다. 10월의 제한적 공개를 다룬 Gemini 4 Carbon 공개: API 접근·가격·벤치마크에서 확인할 것 이후의 변화다. 이번에는 순위보다 기존 호출 설정과 비용 계산에서 달라지는 부분을 살펴본다. 개발자 대상 공식 발표 · 모델 문서
확인 기준: November 11, 2026. 유료 API를 실제 호출하거나 모델 성능을 측정하지 않았다. 아래 Python 예제는 네트워크 없이 계산만 검증했다.
1. 먼저 어떤 경로로 사용할지 정한다
Gemini API의 유료 등급과 Google AI Ultra의 제품 내 이용 경로를 구분해야 한다. 공식 발표는 유료 API 이용과 Ultra 가입자의 AI Studio·Antigravity 접근을 각각 설명한다. 한쪽에서 모델이 보인다는 이유로 다른 프로젝트의 API 권한·할당량·결제 조건까지 확인됐다고 판단하지 말자. 개발자 제공 경로
Carbon은 텍스트·이미지·영상·오디오·PDF를 입력으로 받고, 출력은 텍스트다. 이미지 생성, 음성 생성, Live API는 지원 항목이 아니다. 기존 음성 서비스의 모델 ID를 Carbon으로 바꾼다고 TTS나 실시간 음성 모델이 되는 것은 아니다. 공식 지원 기능
도입 작업에는 API 프로젝트, 모델 ID, 호출 목적, 사용량 한도를 함께 적는다. 처음부터 전체 트래픽을 옮기기보다 검증된 복구 경로를 남긴 작은 평가군으로 시작하는 편이 좋다.
2. Argon에서 옮길 때와 구형 Gemini에서 옮길 때가 다르다
공식 전환 문서는 Argon에서 Carbon으로 옮길 때 요청 스키마 변경이 필요 없다고 설명한다. 다만 Carbon은 복잡한 문제에서 더 많은 thinking 토큰과 시간을 쓸 수 있다. 같은 입력을 보냈을 때 끝까지 답하는지, 첫 응답이 얼마나 늦는지, 재시도가 늘어나는지를 다시 봐야 한다. Carbon 전환 안내
Gemini 3 또는 이전 모델에서 옮긴다면 다음 설정을 별도로 확인한다.
thinking_level은low,medium,high를 지원하며 기본값은medium이다.
temperature,top_p,top_k는 전달해도 무시된다. 예전 샘플링 설정으로 동작을 제어한다고 가정하지 않는다.
- 명시적 캐시인
cachedContents·caches.create와cached_content참조를 그대로 사용할 수 없다.
- 오래 걸리는 요청을 처리할 클라이언트·중간 프록시의 시간 제한도 점검한다.
출처: 이전 모델에서의 전환 체크리스트.
명시적 캐시를 빼고 같은 내용을 매번 보내는 변경은 기능상 통과하더라도 비용을 바꿀 수 있다. Carbon은 암묵적 캐시를 지원하지만 캐시 적중을 전제로 예산을 짜기보다는 응답의 사용량을 확인하는 편이 안전하다. 캐시 지원 범위
3. 출력 한도를 낮추는 것과 추론량을 줄이는 것은 다르다
이 절의 응답 상태와 실행 방식은 Interactions API 기준이다. max_output_tokens는 thinking과 최종 출력의 합산 한도다. 답변을 짧게 받으려고 한도를 지나치게 줄이면 추론 도중 예산을 소진해 최종 텍스트가 비어 있는 incomplete 응답이 나올 수 있다. 추론량은 thinking_level로 조절하고, 출력 한도는 답변까지 마칠 여유와 지출 상한을 함께 고려한다. 한도와 미완료 상태
긴 출력을 처리한다면 한 번의 HTTP 응답만 가정한 파서도 확인해야 한다. 공식 문서는 백그라운드 실행과 클라이언트 측 continuation을 구분한다. 백그라운드 방식은 store: true가 필요하고, 여러 model_output 단계가 생길 수 있다. 저장을 원하지 않는 서비스라면 그 제약부터 검토해야 한다. Long decode 실행 방식
운영에서는 HTTP 성공 여부와 업무 완료 여부를 분리한다. 응답 상태, 최종 텍스트 존재 여부, JSON 스키마 검증, 실제 도구 실행 결과를 각각 확인하자. 미완료 결과를 성공으로 저장했다가 다음 단계가 잘못된 입력을 받는 일을 줄일 수 있다.
4. 12월 예산은 두 배 단가로 다시 계산한다
공식 Standard 요금은 토큰 100만 개당 다음과 같다.
- November 30, 2026까지: 일반 입력 US$2, 캐시 입력 US$0.10, thinking을 포함한 출력 US$10.
- December 1, 2026부터: 일반 입력 US$4, 캐시 입력 US$0.20, thinking을 포함한 출력 US$20.
Free tier는 제공되지 않는다. 위 숫자는 Standard 토큰 단가이며, 검색 등 도구 과금·세금·다른 처리 등급의 조건은 별도다. 공식 요금표
다음 코드는 전체 입력에 캐시 입력이 포함되고, 최종 출력과 thinking을 별도 집계했다는 가정으로 토큰 비용만 계산한다. 실제 응답을 붙일 때는 사용하는 API의 사용량 필드 정의를 확인해 thinking을 누락하거나 중복으로 더하지 않아야 한다.
가상 사용량에서 thinking 30,000개를 빠뜨리면 도입 기간의 계산이 US$0.368 대신 US$0.068이 된다. 최종 답변 길이만 보고 비용을 추정하기 어려운 이유다. 예제의 정상값·0개·전체 캐시·thinking만 있는 경우와 잘못된 입력을 포함해 로컬 검사 9개를 통과했다. 실제 청구나 API 호환성을 검증한 결과는 아니다.
긴 실행은 처음 입력한 프롬프트 크기만으로 계산해서도 안 된다. continuation의 다음 단계에서 앞선 내용이 다시 입력으로 처리될 수 있고, 문서는 취소·실패 전에 처리한 작업도 과금된다고 설명한다. 실행별 최종 사용량을 보존하자. Long decode의 토큰 집계와 과금
5. 전환 승인은 같은 작업의 완료 비용으로 판단한다
다음은 이 글의 운영 제안이다.
- 현재 모델로 처리한 대표 작업과 실패 사례를 평가셋으로 고정한다.
- Carbon의 세 thinking 수준을 비교하되, 각 실행의 시간·토큰·재시도 횟수를 남긴다.
- 빈 답변, 출력 잘림, 잘못된 JSON, 도구 호출 중단을 의도적으로 검사한다.
- 캐시가 적중하지 않은 경우와 12월 단가를 넣어 예산을 다시 계산한다.
- 테스트 통과율과 사람의 수정 시간을 포함해 완료된 작업 한 건당 비용을 비교한다.
복잡한 원인 분석에는 Carbon을 시험하고 빠른 응답이 필요한 경로는 기존 모델을 유지하는 식으로 나눌 수 있다. 모델 교체 자체를 목표로 삼기보다 어떤 작업에서 더 나은 결과를 얼마의 시간과 비용으로 얻는지를 확인하는 것이 이번 API 개방을 활용하는 출발점이다.