요약: Gemini 4 Hydrogen은 2026년 11월 12일에 공개되었습니다. 필자는 모델 이름만 바꾼 '빠른 Flash'으로 취급해서는 안 된다고 생각합니다. 먼저 기존의 샘플링 파라미터인 thinking_budget, 명시적 캐시(explicit cache)에 대한 의존성을 제거하고, 출력 예산과 긴 출력을 생성하는 방법을 확인해야 합니다. 그 후에 4단계의 thinking level을 평가하여 요구 사항을 충족하는 가장 낮은 레벨을 선택합니다. Carbon에 계획을 맡기고 Hydrogen에 실행 및 검증을 맡기는 구성은 시도해 볼 가치가 있지만, 비용은 단가뿐만 아니라 전체 작업에서 집계되어야 합니다. 출처: 공식 발표, 마이그레이션 가이드.
그림 설명: 공식 마이그레이션 가이드와 thinking level 설명을 바탕으로 정리한 개념도입니다. 제품의 스크린샷은 아닙니다.
1. 속도 이전에 요청의 의미를 확인해야 한다
공식 발표에 따르면, Hydrogen은 기본 설정(default)에서 Gemini 3.8 Flash보다 2.5배 빠른 속도를 구현하며, 여러 파일 읽기나 검색을 병렬로 실행할 수 있습니다. 또한, 도구가 실패하거나 검색 결과가 비어 있을 경우 행동을 조정할 수 있습니다. 필자는 이러한 능력이 도구를 반복적으로 호출하는 처리에서 유용하다고 생각합니다. 하지만 모델이 빨라진다고 해도 클라이언트가 오래된 파라미터를 계속 전송하는 문제는 해결되지 않습니다. 업그레이드 검증은 순위(ranking)가 아니라 요청 사양 확인부터 시작해야 합니다. 출처: 공식 발표
마이그레이션 시에는 temperature, top_p, top_k를 삭제합니다. 다만, '설정에서 제거하는 것'과 '전송하면 오류가 나는 것'은 구분할 필요가 있습니다. 업데이트 정보에 따르면, 이러한 사용자 정의 값들은 무시된다고 합니다. 반면, 구 방식의 thinking_budget와 minimal은 HTTP 400 에러를 반환합니다. 필자는 오래된 사고 예산 지정은 현장에서 오류로 처리하고, 호출 측에서 레벨을 명시적으로 선택하도록 하는 것을 권장합니다. 임의로 대응 관계를 추측해서는 안 됩니다. 출처: 업데이트 정보, 모델 가이드
출력 예산(output budget) 역시 기존 설정을 그대로 사용해서는 안 됩니다. 마이그레이션 체크리스트에서는 max_output_tokens가 32,768 미만인 경우, 최소한 이 하한까지 높일 것을 요구하고 있습니다. 업데이트 정보에 따르면, 일반적인 작업의 경우에는 이 필드를 생략하거나 기본값인 65,536을 사용하는 것이 권장됩니다. 이 값은 사용자에게 보이는 답변뿐만 아니라 사고 과정과 최종 출력을 합친 총합을 제한합니다. 동기(synchronous) 요청에서는 스트리밍 및 비스트리밍 모두 한 번의 생성 상한이 65,536이며, 입력/사고/출력은 1,048,576 토큰의 창(window)을 공유합니다. 출처: 마이그레이션 체크리스트, 업데이트 정보
64K를 초과하는 출력에는 백그라운드 실행 또는 클라이언트 측에서의 지속적인 생성이 필요합니다. 네이티브 API의 백그라운드 요청에서는 background=True와 더 큰 출력 예산 둘 다 설정해야 합니다. 백그라운드 실행만 활성화한다고 해도 기본 예산에서 멈춥니다. in_progress, queued 상태를 폴링한 후에는 모든 model_output 단계의 텍스트를 연결해야 합니다. 명시적 캐시인 cachedContents, caches.create는 지원되지 않으며, 기존 요청의 cached_content에도 대처가 필요합니다. 모델 이름만 바꾼다고 마이그레이션할 수 없습니다. 출처: 업데이트 정보
다음은 필자가 작성한 네이티브 API의 generation_config용 체크 함수입니다. 단독으로 실행할 수는 있지만, OpenAI 형식의 파라미터 변환이나 호출 측을 대신하여 캐시 내용을 마이그레이션하는 처리는 포함되어 있지 않습니다.
def clean_config(config):
c = dict(config)
if "thinking_budget" in c:
...
필자는 이 검사를 공통 설정 구성 이후, 실제 전송 직전에 배치할 것을 권장합니다. 업무 코드로 작성된 딕셔너리만 확인하는 것은 불충분합니다. 프레임워크의 기본값(default value), 재시도용 래퍼(wrapper), 환경 설정에 따라 오래된 필드가 다시 추가될 가능성이 있습니다. 정리된 설정 역시 검토할 수 있도록 해야 합니다. 특히, 기존에는 작은 값으로 고정되어 있던 출력 예산(output budget)을 보수 담당자에게 통지 없이 크게 늘려서는 안 됩니다. 마이그레이션 완료 조건에는 요청의 의미와 예산 상한선을 확인하는 것도 포함해야 합니다.
필자가 특별히 주의를 주고 싶은 점은, 명시적 캐시(explicit cache)의 마이그레이션이 단순한 필드 삭제로 오해되기 쉽다는 것입니다. 기존 처리 방식에서 문서를 먼저 업로드하고 요청에는 캐시 참조만 전달했던 경우, 그 참조를 삭제한다고 해서 원문이 자동으로 모델에 전송되는 것은 아닙니다. 먼저 입력 구성 방식을 복원하고, 그 위에 컨텍스트의 중복 여부, 민감 데이터 범위, 작업에 필요한 정보가 모두 갖춰졌는지 확인해야 합니다. 그렇지 않으면, 요청 자체는 성공하더라도 자료가 부족한 상태에서 겉보기에 그럴듯한 답변이 생성될 수 있습니다.
2. 4단계 레벨은 4가지 유형의 품질 보증이 아니다
공식 문서에서 제시하는 사용 구분은 다음과 같습니다. low는 낮은 레이턴시와 높은 스루풋을 요구하는 분류, 라우팅(routing), 요약, medium은 일반적인 코딩, 도구 호출(tool calling), 문서 관련 질의응답에 적합합니다. high는 기본값이며, 복잡한 코딩이나 에이전트에 의한 도구 반복 실행에 적합합니다. xhigh는 high로는 해결하기 어려운 깊은 추론이나 다단계 처리가 필요한 문제용입니다. xhigh는 레이턴시와 토큰 소비를 증가시키며, 단순한 프롬프트에서는 지나치게 생각할 수 있습니다. 출처: 모델 가이드(Model Guide), 업데이트 정보
공식 문서는 충분한 출력 예산을 확보하여 4개 모든 레벨을 평가하고, 요구 사항을 충족하는 가장 낮은 레벨을 선택할 것을 권장합니다. 필자는 '요구 사항을 충족한다'를 검증 가능한 결과로 정의할 것을 권장합니다. 예를 들어, 코드가 테스트에 통과하는지, 도구 실패 후 처리를 수렴시킬 수 있는지, 컨텍스트가 부족할 때 모른다고 인정할 수 있는지를 조건으로 삼는 것입니다. 동시에 소요 시간(time required), 사용량(usage), 오류, 출력 중단 여부도 기록해야 합니다. low의 짧은 답변과 예산 부족으로 인해 중단된 high의 답변을 비교하여 품질을 판단해서는 안 됩니다. 출처: 업데이트 정보
아래 템플릿은 네이티브 SDK를 사용합니다.
google-genai>=3.2.0
을 설치하고 GEMINI_API_KEY
을 설정하면 실행할 수 있습니다. 준비된 eval.jsonl
을 읽어들이며, 각 행에는 prompt
과 사람이 직접 부여한 정답인 expected
이 저장됩니다. 완전 일치(exact match)는 채점 인터페이스를 보여주기 위한 예시에 불과합니다. 개발 작업에서는 격리 환경에서의 테스트나 수동 검토로 대체할 것을 권장합니다. SDK 버전 근거: 마이그레이션 체크리스트
import json
import time
from pathlib import Path
...
필자는 평가 세트에 일반적인 케이스와 실패 케이스를 모두 남기고, 입력, 도구 권한, 수용 기준을 고정할 것을 권장합니다. 특정 레벨에서 우연히 성공했다고 해서 바로 운영 환경으로 전환해서는 안 됩니다. 또한, 모델 자체의 설명을 작업 달성의 증거로 삼아서도 안 됩니다. 위의 템플릿은 원본 답변과 예외를 기록하지만, 중단 판별(cutoff judgment), 결과 파일 저장, 업무에 따른 채점은 호출 측에서 추가해야 합니다. 이는 출발점일 뿐, 완성된 평가 기반이 아닙니다.
필자는 제품 전체에 공통 스위치를 두는 것보다 작업 유형별로 레벨을 설정하는 것이 더 적절하다고 생각합니다. 요약, 대화형 코딩, 여러 파일에 걸친 장애 조사 등에서는 허용 가능한 오류 범위가 다릅니다. 이를 하나의 평균 점수로 묶으면 중요한 처리에서의 실패를 놓칠 수 있습니다. 작업 유형별로 합격 조건을 정하고, 그 조건을 충족하는 후보들을 비교할 때 비로소 도입 판단에 사용할 수 있는 결과가 나옵니다.
3. 호환 API 호출과 네이티브 API 평가는 각각 확인해야 한다
필자는 먼저 일반적인 요청으로 게이트웨이에 대한 연결을 확인하고, 그 후에 사고 파라미터(thinking parameter)의 대응 관계를 검증할 것을 권장합니다. 아래는 openai
을 설치하면 실행할 수 있습니다. Twinkle Model의 base URL을 예로 사용하며, 모델명은 환경 변수에서 읽어옵니다. OpenAI 호환 게이트웨이에서의 모델명과 사용 가능한 파라미터는 게이트웨이의 모델 목록에서 확인해 주십시오. thinking_level
등의 공식 네이티브 파라미터가 호환 레이어에서 어떻게 매핑되는지는 별도로 확인이 필요합니다. 이 예시는 해당 게이트웨이가 Hydrogen나 특정 사고 깊이(thinking level)를 지원한다는 것을 의미하지 않습니다.
import os
from openai import OpenAI
client = OpenAI(
...
필자는 호환 레이어와의 결합 확인 시, 기밀 정보를 제외한 요청 필드와 반환된 usage 값을 저장하고, 요청이 성공했을 뿐만 아니라 파라미터가 실제로 수용되었고 반영되었는지 확인할 것을 권장합니다. 특히 네이티브 API 전용 체크 함수의 출력값을 그대로 채팅 API에 전달해서는 안 됩니다. 필드 이름, 중첩 위치(nesting position), 출력 예산(output budget), 연속 생성 메커니즘을 각각 확인해야 합니다. 네이티브 API에서의 평가 결과도 검증 없이 게이트웨이를 통한 호출에 적용할 수 없습니다.
4. Carbon이 계획하고, Hydrogen이 실행한다. 비용은 작업 완료까지 집계된다.
공식에서 제시하는 조합은 Carbon이 시스템의 인터페이스를 설계하여 난제를 해결하고, Hydrogen이 코드 수정, 병렬 서브태스크(sub-task), 테스트를 담당하는 구성입니다. 릴리스 정보에서는 격리된 워크스페이스에서 작동하는 worker와 verifier에 대해서도 설명되어 있습니다. 필자는 조정 역할(coordinator)이 먼저 수용 조건을 확정하고, 실행 역할에는 변경 사항을, 검증 역할에는 증거를 제출하도록 하는 것을 권장합니다. 실패할 경우 조정 역할로 돌아가 다음 행동을 결정하며, 서로 무한히 일을 주고받는 상태를 피해야 합니다. 출처: 업데이트 정보, 공식 발표
그림 설명: 공식 발표와 업데이트 정보를 기반으로 합니다. 피드백 루프(feedback loop)와 수용 판정은 필자의 제안입니다. 제품 스크린샷이 아닌 개념도입니다.
Hydrogen의 공식 표준 요금은 100만 토큰당 입력 $1.50, 출력 $7.50이며, 사고 과정(thinking)은 출력에 포함됩니다. 암묵적 캐시(implicit cache)에 히트된 입력은 $0.075입니다. 도구의 시스템 지침이나 함수 선언 등의 처리도 과금 대상이 되며, Google Search grounding은 별도로 쿼리 단위로 과금됩니다. 따라서 작업 비용은 마지막 답변의 usage 값만 볼 것이 아니라 모든 호출을 합산해야 합니다. 출처: 업데이트 정보
필자의 계산 예시에서는 특정 작업을 위해 Hydrogen에 의한 실행과 검증의 총합이 입력 100,000 토큰, 사고 과정을 포함한 출력 20,000 토큰이었다고 가정합니다. 캐시와 검색을 제외하면 $0.30입니다 (계산: 0.1×1.50 + 0.02×7.50). 이 토큰 수는 예시를 위한 가정이므로 실제 측정값은 아닙니다. 계산 결과 역시 게이트웨이 요금이 아닙니다. 작업 전체 청구액에는 Carbon에 의한 계획, 실패 시 재시도(retry), 외부 도구의 비용도 합산해야 합니다. 참고 자료에 Carbon의 가격이 없으므로, 본 기사에서는 그 단가를 기재하지 않습니다.
필자가 최종적으로 비교해야 한다고 생각하는 것은 '수용 기준을 충족할 때까지 걸린 작업 전체 비용'입니다. 먼저 마이그레이션으로 인한 오류를 해소하고, 다음으로 레벨별 품질 기준을 확립하며, 마지막으로 여러 모델에 걸친 역할 분담을 시도합니다. 실패와 검증의 비용까지 집계해야만 고속화가 팀의 이익으로 이어졌는지 판단할 수 있습니다.
참고 자료
- 공식 발표: Introducing Gemini 4 Hydrogen
- 개발자 블로그: Build with Gemini 4 Hydrogen
- API 업데이트 정보 및 마이그레이션 가이드
- 마이그레이션 체크리스트
- 모델 가이드
이해관계 공개: 필자는 API 중계 서비스 Twinkle Model(https://big-model.smart-agi.com)을 운영하고 있습니다. GPT・중국산 국산 모델을 약 10% 가격, 최고 성능의 Claude를 제공하며, 공급처로부터의 중계를 통한 저가로 안정적인 서비스를 내세우고 있습니다. 가격은 모델 목록 https://big-model.smart-agi.com/model-plaza에서 확인해 주십시오.
토론
