Gemini 4 Carbon의 Pelican 데모 해부: 두 개의 에이전트, Blender 파이프라인, 그리고 실제로 완결되는 리뷰 루프

Google이 2026년 11월 10일에 내놓은 가장 유용한 것은 벤치마크 표가 아니었다. 그것은 자전거를 탄 펠리컨이었다. Gemini 4 Carbon을 일반 공개한 같은 게시물에서 Google은 Carbon 에이전트가 오픈월드 3D 게임을 만든 한 실행 사례를 설명했다. GBike를 탄 펠리컨이 되어 Google의 Mountain View 캠퍼스를 탐험하는 이 게임은 Blender에서 에셋을 모델링한 뒤 WebGL 셰이더와 함께 Three.js로 브라우저 게임을 만들고, Lyria 음악과 짝을 이루는 절차적 Web Audio 효과를 넣는 방식으로 제작되었다. 함께 유포된 클립은 약 77초 분량이다. 주목할 부분은 펠리컨이 아니다. 핵심은 루프가 닫혔다는 점이다. 그 파이프라인 안의 무언가가 자신이 렌더링한 결과를 보고 충분히 좋은지 판단했다.

그것은 "모델이 똑똑하다"는 주장과는 다른 주장이다. 데모는 선별되며, 이 데모는 벤더가 골랐다. 하지만 리뷰어가 포함된 데모는 벤치마크 점수와는 다른 방식으로 검증할 수 있다 — 구조를 읽고, 역할 수를 세고, 같은 형태가 자신의 업무에서도 버틸 수 있을지 물을 수 있다. 그래서 이것은 출시 기사라기보다 분해 분석이다: 무엇이 만들어졌고, 에이전트가 어떻게 분할되었으며, 이 실행이 무엇을 보여주고 무엇을 보여주지 않는지, 그리고 같은 패턴을 당신이 실제로 중요하게 여기는 것에 적용하는 데 무엇이 드는지.

실제로 무엇이 지어졌는지, 지어진 순서대로

Google의 설명은 툴체인에 관해 이례적으로 구체적이어서, 엔지니어링 노트로 읽을 만한 가치가 있습니다. 해당 실행에는 세 개의 미디어 레그가 있었으며, 이들은 서로 대체할 수 없습니다:

• 에셋 — 서브에이전트는 Omni와 Nano Banana가 생성한 레퍼런스를 바탕으로 Blender에서 3D 오브젝트를 모델링했습니다. 이는 코드 단계가 아니라 모델링 단계입니다. 형상, 재질, 스케일이 여기서 결정되며, 다운스트림의 모든 작업은 이 단계에서 생긴 잘못을 그대로 이어받습니다.

• 이 게임은 Three.js와 WebGL 셰이더로 만들어졌기 때문에, 결과물은 렌더링된 영상이 아니라 브라우저에서 렌더링 가능한 장면입니다. 셰이더가 컴파일된다는 것은 "보기 좋다"는 것과 달리 기계적으로 검증 가능한 확실한 신호입니다.

• 사운드 — Lyria 음악과 짝을 이루는 절차적 Web Audio 효과. 이 부분은 검토 루프와 가장 덜 연결되어 있으며, 사후에 사람이 직접 튜닝할 가능성이 가장 높은 부분입니다.

같은 게시물에는 또 다른 3D 결과물 네 개가 나란히 놓여 있고, 패턴이 반복된다. 역사 사진과 공학 도판을 바탕으로 에펠탑의 1887~1889년 건설 과정을 보여주는 인터랙티브 Three.js 전시, 시의회 계획 PDF 7개로부터 열 번의 밤샘 루프에 걸쳐 제작한 구글 플랫폼 37 사무실의 906,000개 삼각형 Three.js 재구성, 110개 섬유 극좌표 추적 기능을 갖춘 직물 시각화 도구, 그리고 61건반 에스케이프먼트 물리를 구현한 연주 가능한 포르테피아노가 그것이다. 다른 무엇이 사실이든, 이것은 운 좋게 한 번 성공한 프롬프트가 아니다. 같은 형태의 실행 묶음이다.

에이전트 두 명일까, 아니면 세 가지 역할을 맡은 에이전트 한 명일까?

관찰자 계정들과 Google 자체의 글은 같은 실행을 서로 다른 각도에서 설명하는데, 그 차이는 시사하는 바가 큽니다. 11월 10일 @dotey가 올린 가장 널리 공유된 중국어 요약은 이를 빌더 에이전트와 자체 렌더링을 검사하는 리뷰어 에이전트로 나눕니다. 원글 작성자인 Google AI Studio의 Vamsi Batchu는 같은 내용을 캠퍼스 곳곳에서 TPU 칩을 모으는 펠리컨으로 표현하며, 그 공을 Google Antigravity의 /swarm 기능에 돌립니다. Google은 이 기능을 단일 프롬프트를 "실시간으로 추적할 수 있는 협업 에이전트 팀"으로 바꾸는 것이라고 설명합니다.

Google의 게시물은 Carbon에 역할을 미디어가 아니라 "아키텍처 설계, 조정, 감사"로 부여합니다. 관찰자 설명과 나란히 읽으면, 형태는 지오메트리와 코드를 생성하는 빌더와 소스가 아니라 출력물을 보는 감사자입니다. 이 구분은 에이전트 수보다 더 중요합니다. 자신의 diff를 검토하는 에이전트는 약한 신호를 가집니다. 렌더링된 프레임, 컴파일 중인 셰이더, 또는 실행 중인 게임의 스크린샷을 검토하는 에이전트는 강한 신호를 가집니다. 왜냐하면 실패가 산문에서 논쟁 가능한 것이 아니라 아티팩트에서 가시적이기 때문입니다.

출처와 관련해 솔직하게 밝힐 두 가지 유의점이 있습니다. 빌더/리뷰어 분리는 공개된 아키텍처 다이어그램이 아니라 실행 과정을 설명한 사람들의 진술에서 나온 것이므로, 사양서가 아닌 충실한 요약으로 받아들이시기 바랍니다. 그리고 /swarm은 Antigravity에서 프리뷰 상태이므로, 재현하려는 오케스트레이션 계층은 아직 일반적으로 사용할 수 있는 상태가 아닙니다.

또한 아무도 언급하지 않는 실질적인 문제가 하나 있습니다: 링크된 AI Studio 앱은 Google 로그인 뒤에 있습니다. 저는 익명으로 게임을 열 수 없었습니다 — URL은 곧바로 accounts.google.com으로 리디렉션됩니다. 따라서 "브라우저에서 플레이 가능"은 "Google 계정이 있고, 앱 자체의 경우 AI Studio 세션이 있어야 플레이 가능"을 의미합니다. 그것은 그 영상이 수백 번 재게시되는 동안 조용히 넘어간 사소한 부분입니다.

왜 게임이 그것이 대체한 SVG보다 더 어려운 테스트인가

자전거 타는 펠리컨 프롬프트는 Simon Willison의 것으로, 그는 2024년 이후 사실상 모든 프런티어 릴리스에 이 프롬프트를 실행해 왔습니다 — 처음에는 단일 SVG 요청으로, 그다음 모델들이 평면 SVG에서 더 이상 차별화되지 않자 3D 프롬프트로: WebGL 페이지, Blender 렌더, p5.js 스케치. 이 테스트의 가치는 펠리컨이 어렵다는 데 있지 않습니다. 가치는 출력이 시각적이고, 자체 완결적이며, 사람이 1초 안에 즉시 판단할 수 있다는 데 있습니다.

Carbon의 실행이 하는 일은 바로 그 성질을 한 단계 더 어려운 수준으로 끌어올리는 것입니다. SVG는 한 언어로 된 하나의 산출물입니다. 이것은 한 도구에서 나온 기하학, 다른 도구에서 나온 코드, 세 번째 도구에서 나온 런타임, 그리고 이 셋을 모두 조화시켜야 하는 리뷰 단계입니다. 이는 장기 지평의 에이전트 작업이 보통 무너지는 바로 그 종류의 과제입니다. 첫 단계가 아니라 열네 번째 단계에서, 모델이 자신이 어떤 좌표계를 택했는지 잊어버릴 때 말입니다.

Google의 이 기능 요약은 정확하며 그 메커니즘을 명시한다. 웹 앱 개발을 위해 이 모델은 "빌드 및 검증 루프를 실행하고, 오류에서 복구하며, 자체 코드와 렌더링된 UI를 모두 확인한다." 이것이 바로 그 모든 비법을 간명하게 말한 것이다. 흥미로운 변수는 첫 시도가 얼마나 좋은지가 아니다. 에이전트가 개선을 멈추고 헛돌기 시작하기 전까지 루프가 몇 번 돌 수 있는지다.

데모가 알려주지 않는 것

벤더 데모는 선별된 샘플이며, 선별 자체가 이 실습의 핵심입니다. 그것이 답할 수 없는 세 가지는 다음과 같습니다:

• 얼마나 자주 실패하는가. 우리는 완료된 실행만 본다. 멈춰 버린 열한 번의 실행은 아무도 공개하지 않으며, 글 어디에도 분모는 없다.

• 비용은 얼마였나. Platform 37 빌드에서 밤새 열 번의 루프를 돌렸다는 것은 막대한 토큰과 막대한 실제 경과 시간을 의미한다. Carbon의 요율로 따지면 그것은 실제 숫자가 되지만, Google은 이를 밝히지 않는다.

• 더 저렴한 모델로도 충분했을지 여부. 이것이 독자가 실제로 물어야 할 질문이며, 그 데모는 구조적으로 그 질문에 답할 수 없다.

측정 가능한 부분에 대해서는 Artificial Analysis가 균형추 역할을 하며, 그 수치는 영상보다 덜 호의적이다. Gemini 4 Carbon은 고강도 설정에서 Intelligence Index v5.0.1 60점을 기록해 74개 모델 중 4위이며, 65점, 62점, 62점을 받은 Claude Fable 5.2의 세 가지 구성 뒤에 있다. 지수 작업당 비용은 $7.76로 해당 지표에서 73개 중 61위이며, 전체 지수에서 출력 토큰 2억 500만 개를 소비하는데 중앙값은 약 7,300만 개다. 즉 장황한 모델이며, 토큰당 가격은 Carbon 워크로드의 비용을 과소평가한다. 출력 속도는 초당 약 82토큰이고 첫 답변 토큰까지는 약 67.5초가 걸린다. 토큰당으로는 충분히 빠르지만 첫 토큰까지는 충분히 느려서, 채팅창형이라기보다 배치 후 대기형 프로필로 읽힌다. Coding Agent Index에서 같은 평가자는 Antigravity CLI와 함께 Carbon을 59점으로 평가했고, Opus 5.5와 함께한 Claude Code는 62점이었다.

그중 어느 것도 데모와 모순되지 않는다. 모델은 범용 지수에서 4위일 수 있고, 작업당 비용이 비쌀 수 있으며, 그래도 4시간짜리 빌드를 끝까지 유지하는 모델일 수 있다 — 그것들은 서로 다른 측정치이고, 데모는 세 번째에 대한 증거이지 첫 번째에 대한 증거가 아니다. 그것이 증명이라는 뜻은 아니며, 가장 값싸게 메울 수 있는 빠진 조각은 이 계보가 보통 제공하는 바로 그것이다. Willison은 거의 모든 릴리스에서 pelican 프롬프트를 실행하고 결과를 공개한다. 2026년 11월에 그의 pelican 글들은 다섯 가지 추론 수준의 Claude Fable 5.2와 여섯 가지 수준의 Muse Ember를 다루며, 그중 Carbon 세트는 없다. 하나가 나타나기 전까지 pelican 데모는 Google의 산출물이며 다른 누구의 것도 아니다 — 벤더가 고른 빌드에 벤더가 작성한 설명이 붙어 있고, 실패율을 비교할 외부 실행이 없다.

같은 루프를 직접 실행할 때 드는 비용

Carbon은 Google의 유료 티어에서만 사용할 수 있습니다. 무료 경로는 없습니다. AI Studio 앱에는 Google 계정이 필요하고, API에는 결제 설정이 필요하며, 처리되는 모든 토큰은 사고 토큰을 포함해 과금됩니다. 요금표는 도입용이며 기간 한정입니다:

• 2026년 11월 30일까지 — 입력 토큰 100만 개당 $2.00, 출력 토큰 100만 개당 $10.00.

• 2026년 12월 1일부터 — 변경되지 않은 모델 기준 $4.00 및 $20.00.

• 컨텍스트 — 1M 토큰, 길이 기반 가격 구간이 없으므로 900,000토큰 코드베이스도 2,000토큰 프롬프트와 토큰당 비용이 같습니다.

장황함을 절벽 옆에 두면 계산이 불편해진다. 빌드-리뷰 루프는 구조상 출력이 많은 작업이다. 리뷰어가 쓰고, 빌더가 다시 쓰며, 매 턴마다 대화 기록이 늘어난다. 입력 1억 개, 출력 2천만 개 토큰의 워크로드는 이번 달에 400달러(입력 200달러, 출력 200달러)로 청구되고, 동일한 트래픽에 대해 12월 1일부터는 800달러로 청구된다. 11월에 파일럿을 진행한다면 파일럿 가격을 12월 요율로 산정하라. 그렇지 않으면 두 배나 틀린 예산을 승인하게 될 것이다.

우리가 어디에 있는지 분명히 하는 편이 좋겠습니다: Gemini 4 Carbon은 OrcaRouter 카탈로그에 없으며, 여기 어떤 내용도 그것이 있다고 주장하는 것으로 읽혀서는 안 됩니다. 그 자리에 있는 것은 google/gemini-4-argon이며, Google 자체의 입력 $2 / 출력 $10 — Carbon이 이번 달 사용 중인 것과 같은 카드 — 에 DeepSeek V4 Pro가 $0.66/$1.98, Grok 4.7이 $2/$6에 함께 있습니다, 모두 216개 모델에 걸쳐 하나의 OpenAI 호환 키로, 아울러 공급자 정가가 0% 마크업으로 전달되어 공급업체 요율 변경이 재가격 책정 주기를 거친 뒤가 아니라 발생하는 당일에 적용됩니다. 이 특정 패턴에서 그것이 중요한 데에는 지루한 이유가 있습니다: 멀티 에이전트 빌드 루프는 한 공급자에서 요율 제한이나 좋지 않은 오후를 겪을 가능성이 가장 높은 워크로드이며, 두 번째 경로로의 장애 조치는 10회 루프 실행 중간에 한계를 발견하는 것보다 비용이 적게 듭니다.

구조를 복사하려면 검토 단계를 복사하세요.

이 데모에서 전이 가능한 부분은 Blender가 아니며 Three.js도 아닙니다. 바로 검토자가 살펴볼 수 있는 무언가를 받았다는 점입니다. 결과를 얼마나 크게 바꾸는지 순서대로 세 가지 방법:

• 산출물을 리뷰 입력으로 삼아라. 실행 중인 앱을 스크린샷으로 찍고, 프레임을 렌더링하고, 셰이더를 컴파일하고, 테스트를 실행한 다음 — 그것을diff가 아니라 다시 넘겨라. "이 코드가 올바른가?"라고 질문받은 에이전트는 자기 자신에게 동의할 것이다. "이 스크린샷이 브리프와 일치하나?"라고 질문받은 에이전트는 틀릴 여지가 생긴다.

• 루프에 상한을 두고 수렴 여부를 확인하세요. Google이 한 번의 빌드에 대해 제시하는 수치는 밤새 루프 10회입니다. 자신만의 상한을 정하고, 각 턴이 실제로 아티팩트를 개선했는지 기록하세요 — 개선을 멈춘 에이전트는 보통 꾸미기를 시작한 에이전트입니다.

• 툴체인은 지루하고 검증 가능하게 유지하세요. Blender 내보내기, Three.js, WebGL, 브라우저는 모두 결정적이며 검사 가능합니다. 이번 실행은 한 업체만 보유한 기능에 의존하지 않습니다. 첫 실패 후에도 계속 나아갈 모델에 의존합니다.

다음에 지켜볼 것은 좁고 구체적이다. 다음 질문은 /swarm이 프리뷰 단계를 벗어날지 여부다. 왜냐하면 오케스트레이션이야말로 오늘날 재현할 수 없는 부분이기 때문이다. Google 외부의 누군가가 Carbon pelican을 공개할지 — Willison의 버전은 이 계보에서 독립적인 결과에 가장 가까운 것이며, 그것은 아직 등장하지 않았다. 그리고 10월 28일의 제한적 발표와 11월 10일의 일반 출시 사이의 12일 간격이 패턴인지 예외인지로 드러날지. 그 데모는 몇 달 동안 인용될 것이다. 그 이면의 루프가 바로 일반화될지 아닐지의 관건이다.