Gemini 4 Carbon과 Hydrogen은 함께 사용할 때 가장 큰 시너지를 냅니다. Carbon이 계획을 세우고, Hydrogen이 이를 구현합니다. Carbon 기반의 플래너(Planner) Agent에 Task를 부여하고, 인수 검정(acceptance check)이 포함된 하위 태스크를 작성하게 한 뒤, 이를 Hydrogen 기반의 워커(Worker) 및 검증기(Verifier) Agent에 전달하세요. 두 번 연속 실패하는 작업만 다시 플래너로 전달하도록 구성하면 됩니다. 프론티어 모델 수준의 정교한 판단이 필요한 턴에만 프론티어 요금을 지불하면 됩니다.
Gemini 4 Carbon과 Hydrogen을 왜 함께 사용해야 할까요?
Google은 2026년 11월 12일 Gemini 4 Hydrogen을 출시하며 이를 "에이전트 워크플로우를 위한 데일리 드라이버(daily driver)"라고 불렀습니다. 이보다 이틀 전인 11월 10일, Gemini API 변경 내역(changelog)에 Gemini 4 Carbon이 정식 출시(GA)된 것으로 발표되었습니다. 따라서 이번 달부터 처음으로 Google의 가장 강력한 모델과 빠른 실행 모델을 동일한 Task에 결합하여 활용할 수 있게 되었습니다.
Google 역시 Hydrogen을 소개하며 두 모델의 조합을 핵심으로 내세우고 있습니다. 출시 발표 게시글에 따르면 Carbon이 조정자(coordinator) 역할을 맡고, Hydrogen은 "격리된 워크스페이스 전반에서 변경 사항을 동시에 빌드하고 테스트하는 워커 및 검증기 에이전트"를 구동할 수 있습니다. Gemini API 가이드에서는 이를 더욱 명확하게 설명합니다. Carbon이 인터페이스를 설계하거나 까다로운 난제를 해결하도록 하고, 코드 수정, 병렬 하위 에이전트 작업, 테스트 실행은 Hydrogen에 위임하는 방식입니다.
이는 개별 모델의 기능이라기보다는 하나의 오케스트레이션 패턴이며, 오늘 바로 여러분의 대시보드에 구축할 수 있습니다. 노트북 한 대에서 실행되는 스크립트 대신 팀 보드에서 이 패턴을 체계적으로 운영하고 싶다면, Task, Agent, 코드 리뷰가 모두 한곳에 모여 있는 Sharkly를 활용해 보세요.
Google Orchestrator의 역할, 한 문단으로 정리하기
Orchestrator는 Google Antigravity 내의 모델 옵션으로, 단일 대화 안에서 플래너(Carbon 또는 Argon)와 Hydrogen 간의 전환을 처리합니다. Antigravity 문서에 따르면, 플래너는 읽기 전용 탐색 단계로 시작하여 명확한 재계획(re-planning) 트리거가 포함된 계획을 수립한 뒤 Hydrogen에 실행을 넘깁니다. 그리고 Hydrogen은 작업 중 난관에 부딪히면 제어권을 다시 플래너에 넘깁니다.
문서에서는 눈여겨볼 만한 세 가지 장애 신호(friction signals)를 제시합니다:
- 검증 단계가 두 번 연속 실패할 때.
- 인터페이스가 계획에서 예상했던 것과 다르게 동작할 때.
- 계획에서 확정하지 않은 설계상의 선택이 필요할 때.
Google의 보고에 따르면 Terminal-Bench에서 Orchestrator는 쿼터를 24% 적게 사용하고 평균 19% 더 빠르게 완료하면서도 Carbon에 근접한 태스크 성공률을 기록했습니다. Google의 두 게시글에서 벤치마크 버전 표기가 일치하지 않으므로(출시 글에는 4.0, Antigravity 글에는 4.1로 기재됨), Google이 이를 수정할 때까지는 단순히 Terminal-Bench로 인용하는 것이 좋습니다.
Orchestrator는 대화 내에서 단일 에이전트를 유지하고, 사고 수준(thinking-level)을 제어할 수 없는 고정 구성을 사용하며, Carbon 버전은 Google AI Ultra 사용자 전용으로 제공됩니다. 반면 팀 보드를 활용하면 이러한 역할 분담을 여러 Agent에 분산시키고 계획과 인수인계 과정을 모두에게 투명하게 공개할 수 있습니다.
비용 분석: Gemini 4 Hydrogen vs Carbon 가격 비교
2026년 11월 13일 기준 Gemini API 가격 안내 페이지의 토큰 가격입니다:
| 모델 | API 모델 ID | 입력 / 1M | 출력 / 1M | 무료 티어 |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
11월 30일까지 $2.00, 이후 $4.00 | 11월 30일까지 $10.00, 이후 $20.00 | 미지원 |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
$1.50 | $7.50 | 지원 (호출 속도 제한 적용) |
예산을 책정하기 전에 날짜를 먼저 확인해야 합니다. 11월 30일까지는 Hydrogen이 Carbon보다 토큰당 25% 저렴할 뿐이지만, 12월 1일부터는 62.5% 더 저렴해집니다. 두 수치 모두 Google의 정가를 기준으로 자체 계산한 결과입니다.
단일 실행(run)을 기준으로 보면 차이가 더 분명해집니다(마찬가지로 자체 계산 기준). 200k 토큰을 읽고 40k 토큰을 출력(출력에는 사고 토큰 포함)하는 워커 턴을 가정해 보겠습니다. 12월 1일 이후 Carbon의 경우 $0.80 + $0.80 = $1.60입니다. Hydrogen에서는 $0.30 + $0.30 = $0.60입니다. 스프린트 동안 하루에 이 작업을 30회 실행한다면 그 격차는 결코 무시할 수 없는 수준이 됩니다.
단순 토큰당 단가만으로는 실제 비용 차이가 과소평가될 수 있습니다. Google에 따르면 Carbon은 "가설을 검증하고 엣지 케이스를 확인하기 위해 매 턴마다 더 많은 사고 토큰을 사용"하며, 출력 가격에는 사고 토큰이 포함됩니다. 따라서 동일한 코드 수정 작업이라도 Carbon에서는 더 높은 단가뿐만 아니라 더 많은 출력 토큰이 청구될 가능성이 높습니다. Google은 두 모델의 조합에 대한 태스크당 비용 수치를 공개하지 않았으므로, 예상 절감액을 산정하기 전에 자체 리포지토리에서 직접 측정해 보는 것이 좋습니다.
속도 역시 중요한 이점입니다. Google에 따르면 Hydrogen은 기본 high 설정에서 Gemini 3.8 Flash보다 작업을 2.5배 빠르게 완료합니다.
에이전트 팀에 작업 분배하기: 모델에 최적화된 역할 구성
플래너/워커 분담은 명문화된 분업 체계입니다. 한 Agent가 계획과 까다로운 의사결정을 전담하고, 비용 효율적인 Agent들이 실행을 맡으며, 검증기가 사람이 확인하기 전에 결과를 점검합니다. 각 역할에는 해당 업무에 최적화된 비용과 성능 깊이를 가진 모델이 배정됩니다.
| 역할 | 모델 | 사고 수준 | 담당 업무 |
|---|---|---|---|
| 플래너(Planner) | gemini-4-carbon |
기본 medium, 고난도 Task는 high |
코드베이스 분석, 인수 검정이 포함된 하위 태스크 작성, 재계획 수립 |
| 워커(Worker, 1~n) | gemini-4-hydrogen |
high (기본값) |
코드 수정, 패키지 업데이트, 테스트 실행 (각각 하위 태스크 1개 전담) |
| 검증기(Verifier) | gemini-4-hydrogen |
high, 위험도 높은 diff는 xhigh |
플래너의 인수 기준에 따른 검증 실행 |
| 사용자(Person) | 해당 없음 | 해당 없음 | 대규모 Task의 계획 승인, 최종 결과 수락 |
이 표는 Google 공식 문서의 두 가지 세부 정보를 기반으로 구성되었습니다. Carbon과 Argon은 기본값이 medium이고 최대 high까지 지원하는 반면, Hydrogen은 기본값이 high이며 xhigh까지 지원합니다. 또한 Google은 xhigh 설정 시 지연 시간과 토큰 사용량이 증가하며 "단순한 프롬프트에서 지나치게 깊이 생각하는 현상이 발생할 수 있다"고 경고합니다. 따라서 xhigh는 인증, 결제 또는 데이터 마이그레이션과 같이 위험도가 높은 변경 사항(diff)을 점검하는 검증기에만 사용하는 것이 좋습니다.
플래너는 어떤 내용을 작성해야 할까요?
플래너의 산출물은 이후 작업을 수행하는 모든 에이전트를 위한 계약서 역할을 합니다. 훌륭한 계획에는 독립적인 변경 사항당 하나의 하위 태스크, 각각의 대상 파일 범위(file scope), 정상 작동을 입증하는 검증 명령어, 그리고 작업을 플래너로 반환해야 하는 조건이 명시되어 있어야 합니다. 워커가 작업 완료 시점을 명확히 알 수 없다면, 그 계획은 아직 완성된 것이 아닙니다.
작업은 언제 플래너로 다시 반환되어야 할까요?
Google의 트리거 목록을 차용하여 기준을 명확히 설정하세요. 워커는 검증이 두 번 연속 실패할 때, 인터페이스가 계획과 일치하지 않을 때, 또는 설계상 결정이 필요할 때 하위 태스크를 반환합니다. 이때 로그와 지금까지의 diff, 그리고 명확한 질문을 함께 넘깁니다. 더 비싼 상위 모델로 몰래 재시도해서는 안 됩니다. 그렇게 하면 저렴한 티어의 비용 절감 효과가 고가 티어의 청구서 뒤로 가려지기 때문입니다.
Sharkly에서 구성하는 방법
Sharkly에서 Agent는 연결된 Computer의 Runtime을 통해 실행되는 AI 팀원이며, Crew는 한 명의 리더 Agent가 조율하는 Agent와 사람들의 그룹입니다. 별도의 연동 코드 없이도 플래너/워커 분담 구조에 그대로 부합합니다. 플래너가 Crew 리더가 되고, 워커와 검증기는 Crew 멤버가 됩니다.
위 패널(Claude Code를 실행하는 예시)에 나타난 것처럼 각 Agent는 고유한 Runtime과 Default model을 가집니다. 이 구성을 구현하려면 Gemini CLI 등 Gemini API에 접근할 수 있는 Runtime을 각 Agent에 부여하고, Agent별로 모델을 지정합니다. 즉, 플래너에는 Carbon을, 나머지에는 Hydrogen을 설정합니다. 모델 목록에 아직 새 모델 ID가 표시되지 않는다면 Runtime 자체 설정에서 모델을 지정할 수 있습니다. Gemini CLI는 설정 참조 문서에 명시된 대로 GEMINI_MODEL 환경 변수도 읽어 들이며, Agent별로 환경 변수를 지정할 수 있습니다.
그런 다음 Crew 지침(Crew instructions)에 다음과 같이 조율 규칙을 작성합니다:
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
이제 Task를 Crew에 할당합니다. Crews 문서에 설명된 대로 실행은 리더 우선(leader-first) 방식으로 진행됩니다. 리더가 Task와 Crew 지침을 확인한 뒤 특정 작업에 필요한 멤버를 멘션하고, 멤버들의 작업 결과는 동일한 Task로 다시 취합됩니다. 각 워커가 독립된 워크트리(worktree)를 가질 수 있도록 임시 작업 디렉터리를 사용하세요. 하위 태스크들이 이전 작업의 로컬 변경 사항을 순차적으로 이어받아 빌드해야 하는 경우에만 Crew의 공유 Task 디렉터리를 활성화합니다.
진행이 차단된 작업은 언제나 명확하게 파악할 수 있습니다. 실패하거나 블로킹된 실행은 Inbox에 표시되며, 사람의 승인을 기다리는 Agent는 사이드바의 Task Chats에 노출됩니다. 플래너가 자체적으로 계획을 수정하지 못할 때 다이어그램의 점선 화살표가 가리키는 곳이 바로 여기입니다.
고급 기법
단일 장기 Task에 API의 모델 전환 기능 활용하기. Google 공식 문서에 따르면 스키마 변경 없이 previous_interaction_id를 사용하는 단일 멀티턴 세션 내에서 계획 턴은 gemini-4-carbon으로, 실행 턴은 gemini-4-hydrogen으로 라우팅할 수 있습니다. 이는 Orchestrator의 방식을 자체 코드에 적용한 것으로, 단일 Agent 실행 환경에서 매우 유용합니다.
홉 크기(hop size) 유의하기. Hydrogen은 비스트리밍(non-streaming) 홉당 최대 65,536 토큰을 반환하는 반면, Carbon과 Argon은 비스트리밍 REST 홉당 32,768 토큰을 반환합니다. 테스트 스위트나 마이그레이션 명세와 같이 길이가 긴 생성 작업은 워커 쪽에 맡기는 것이 좋습니다.
Hydrogen에서는 명시적 캐싱 생략하기. Hydrogen은 명시적 컨텍스트 캐싱(explicit context caching)을 지원하지 않습니다. 대신 4,096 토큰 이상의 프롬프트에서 암시적 캐싱(implicit caching)이 작동하여 캐시된 입력에 95% 할인이 적용되므로, 공유 리포지토리 컨텍스트를 각 워커 프롬프트의 맨 앞부분에 배치하세요.
플래너/워커 분담 방식의 대안
- Hydrogen 단독 사용: Google 문서에서는 패키지 업그레이드, 코드 중복 제거, 스캐폴딩, 명확하게 정의된 함수의 단위 테스트 및 문서화 작업에 권장합니다. 이 경우 플래너가 필요하지 않습니다.
- Carbon 단독 사용: 분산 시스템 설계, 경쟁 상태(race condition) 해결, 멀티 리포지토리 마이그레이션과 같이 모든 단계에서 깊이 있는 사고가 필요한 작업에 적합합니다.
- Antigravity의 Orchestrator: 해당 기능을 지원하는 요금제에서 단 한 명의 사용자, 단일 대화, 자동 인수인계 방식으로 진행할 때 적합합니다.
- 정적 라우터: 사전에 Task를 분류하여 단일 모델로 라우팅하는 방식입니다. 다만 Google은 작업 진행 중에 난이도가 변하는 장기 실행 태스크에서는 이 방식이 한계를 드러낸다고 지적합니다. 사전 라우팅 방식은 Gemini Decisions API로 에이전트 Task 라우팅하기에서 다룬 바 있습니다.
실제 활용 사례
대규모 이슈 분류(Triage): Google의 Antigravity SDK 공식 데모에서는 이슈 분류 및 코딩을 담당하는 Hydrogen 에이전트들과 리팩터링, 신규 기능 개발, 보안 점검을 담당하는 Carbon 에이전트를 결합하여 사용합니다. 이를 보드에 구현하면, 접수 큐에는 Hydrogen Agent를 배치하고 리팩터링이나 보안 라벨이 붙은 작업에는 Carbon 리더를 배치하는 구조가 됩니다.
기능 개발을 병렬 하위 태스크로 분할: 플래너가 API 변경 작업을 스키마, 핸들러, 클라이언트 업데이트로 나눕니다. 세 명의 워커가 독립된 워크트리에서 각 작업을 병렬로 실행하고, 검증기가 계약 테스트(contract test)를 수행합니다.
마치며
Carbon이 계획하고, Hydrogen이 구축하며, 사람이 최종 승인합니다. 12월 1일부터 적용되는 가격 정책 덕분에 이러한 역할 분담은 충분한 경제성을 갖추게 되었습니다. 또한 장애 트리거를 통해 저렴한 실패가 값비싼 재시도로 이어지는 것을 방지하며, 보드 위에서 모든 인수인계 과정이 Task 단위로 팀원들에게 투명하게 공개됩니다. 더 포괄적인 패턴에 대해 알아보려면 AI 에이전트 오케스트레이션이란 무엇인가 및 Crews를 위한 모델 라우팅 규칙을 확인해 보세요.
이제 직접 시작해 볼 차례입니다. Sharkly에 Computer를 하나 연결하고, Carbon 기반 플래너 Agent 1개와 Hydrogen 기반 워커 Agent 1개를 생성한 뒤, 위의 지침을 사용해 Crew를 구성하세요. 그리고 보통 사람에게 반나절 정도 맡길 만한 Task를 할당해 보시기 바랍니다. Sharkly는 무료 플랜을 제공하므로 테스트에 드는 비용은 Gemini 토큰 비용뿐입니다.
자주 묻는 질문(FAQ)
Gemini 4 Carbon과 Hydrogen의 차이점은 무엇인가요?
Carbon은 긴 호흡의 복합 추론(long-horizon reasoning)과 까다로운 아키텍처 설계, 디버깅, 보안 분석에 특화된 Google의 최상위 프론티어 모델입니다. Hydrogen은 일상적인 코딩과 에이전트 실행에 최적화된 빠르고 효율적인 Gemini 4 모델입니다. Carbon은 사고 수준(thinking)의 기본값이 medium이며 최대 high까지 지원하고, Hydrogen은 기본값이 high이며 xhigh까지 지원합니다.
Gemini 4 Hydrogen이 Carbon보다 더 저렴한가요?
네, 그렇습니다. Hydrogen은 100만 입력 토큰당 $1.50, 출력 토큰당 $7.50입니다. Carbon은 2026년 11월 30일까지 $2 및 $10이며, 12월 1일부터는 $4 및 $20로 인상됩니다. 또한 Hydrogen은 Gemini API에서 속도 제한이 적용되는 무료 티어를 제공하지만, Carbon은 무료 티어를 제공하지 않습니다.
검증기는 Hydrogen 대신 Carbon에서 실행해야 하나요?
기본적으로는 그럴 필요가 없습니다. Google은 병렬 워커 및 검증기 에이전트용으로 Hydrogen을 권장합니다. 위험도가 높은 변경 사항(diff)에는 검증기 사고 수준을 xhigh로 설정하고, 검증이 두 번 연속 실패할 때만 해당 Task를 Carbon 플래너로 상신(escalate)하세요.
Sharkly가 각 Task에 적합한 모델을 자동으로 선택하나요?
아닙니다. 사용자가 각 Agent의 Runtime을 통해 모델을 직접 지정하며, Crew 지침에 따라 Task의 어느 부분을 어떤 Agent가 담당할지 결정됩니다. Sharkly는 Task, 실행 이력, 인수인계 프로세스, 그리고 리뷰 관리를 총괄합니다.
