Gemini 4를 직접 시험한 결과와 평가

URL: https://www.youtube.com/watch?v=NE006pkiAnk 날짜: 2026-10-15 채널: t3dotgg (Theo - t3․gg) 원제목: So I've been testing Gemini 4... 재생 시간: 38분 30초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Gemini 4 Argan은 낮은 가격과 일부 뛰어난 벤치마크에도 불구하고 실제 코드 작업에 투입할 수 있는 프런티어 모델인가?==

• Gemini 3.1 Pro 이후 정상급 대형 Gemini 모델이 나오기까지 8개월이 걸렸고, 그동안 Google은 Flash 계열만 내놓았다.
• Gemini 4 Argan은 스케이트보드 트릭을 맞히는 Skatebench에서 100%를 기록하고 프런트엔드·3D·멀티모달 능력도 보였지만, API 불안정성과 캐시 적중률 문제를 안고 있다.
• 실제 코드베이스 감사에서 36개 주장 중 24개가 틀렸고, 다른 감사에서도 78개 발견 중 56개가 틀려 낮은 환각률을 내세운 공개 벤치마크와 실무 경험 사이에 큰 간극이 드러났다.
• 최종적으로 Gemini 4 Argan은 마케팅 페이지의 초안, YouTube 데이터 수집, 일부 비전 작업에는 쓸 수 있지만 T3 Code 같은 실제 코드베이스에 코드를 기여하게 해서는 안 되는 모델로 평가된다.

Theo는 가격, 공개 벤치마크, 프런트엔드, Google 고유 기능, 3D 게임 생성, 환각과 코드 감사, ACP 통합 안정성을 차례로 점검한다. 결론은 모델의 속도나 토큰 가격보다 실제로 맞는 코드를 내놓고 자신의 가설을 검증하는지가 중요하며, Gemini 4 Argan은 그 핵심 기준에서 Opus 5.5, GPT-6.1 Soul, Fable 5.1, Muse Wonderful Full보다 크게 뒤처진다는 것이다.

1. 8개월 만의 대형 Gemini 출시와 평가의 전제 (00:00~02:36)

정상급 모델의 출시 간격이 짧던 시기와 비교하면 Gemini 4 Argan은 너무 늦게 도착했다.

1.1. 출시 간격이 보여주는 지연

1. 대형 모델 공백

   1. 과거 Gemini 2.5.6 Soul과 3.6 Astra 사이의 출시 간격은 1~2개월이었다.
   2. Gemini 3.1 Pro와 Gemini 4 Argan 사이의 간격은 8개월이며, 마지막 대형 모델 출시는 2월이었다.
   3. Google은 그 8개월 동안 Flash 모델 외에는 내놓지 않았고, Gemini 4 Argan을 일주일 넘게 예고한 뒤에야 전면 공개했다.

2. 검토해야 할 범위

   1. 가격과 토큰 효율, 프런트엔드 생성 능력, 3D 능력, Gemini 특유의 이상한 동작과 고유 기능을 모두 확인해야 한다.
   2. 최근 출시된 Opus 5.5, GPT-6.1 Soul, Muse Wonderful Full과 비교해 실제 경쟁력이 있는지 판단해야 한다.
   3. Theo는 Google 내부 지인 몇 명이 조기 접근권을 얻도록 힘써준 데 감사하면서도, 좋은 점과 나쁜 점을 모두 말하겠다고 했다.

1.2. 이해관계 공개와 자기검열에 대한 농담

1. Google과의 관계

   1. Google은 Theo가 YouTuber이기 때문에 상당한 금액을 지급하지만, Gemini·Antigravity 보도 자체에 대가를 지급한 것은 아니다.
   2. 과거 Gemini 관련 영상은 YouTube에서 수익 창출 중단에 가까운 조치를 받을 뻔했으므로, Gemini를 비판하는 데 오히려 비용이 들었다고 설명한다.
   3. “나는 유료 홍보자가 아니다”라는 평소 농담을 이번에는 완전히 할 수 없지만, 적어도 이 리뷰의 내용에 돈을 받은 것은 아니라는 선을 긋는다.

2. WorkOS 광고 구간과 에이전트 가입 문제

   1. 오늘날 Theo는 직접 버튼을 누르는 대신 에이전트(agent)로 대부분의 일을 하므로, 에이전트가 선택한 서비스는 에이전트가 실제로 가입하고 사용할 수 있어야 한다.
   2. WorkOS는 사람과 기업이 애플리케이션에 로그인하는 플랫폼이며, OpenAI, Anthropic, FA, Cursor, Bolt, Vanta, Carta 등이 사용한다고 소개된다.
   3. WorkOS가 Firecrawl·Cloudflare와 함께 설계한 OMD 표준은 에이전트가 사용자를 대신해 애플리케이션에 가입하는 절차를 쉽게 만든다.
   4. Neon, Monday, Parallel 등도 이 표준을 채택하고 있으며, 에이전트가 기업 고객을 대신해 가입해야 하는 제품은 OMD를 출발점으로 삼을 수 있다.
   5. 광고 링크는 soy.link/workos이며, Theo는 이 구간을 마친 뒤 Gemini 4 Argan 평가로 돌아간다.

2. 공개 범위, 공식 주장과 가격의 함정 (02:36~10:57)

Gemini 4 Argan은 폭넓게 공개됐지만, Google의 제품 구성과 가격 정책은 사용자가 실제 비용을 파악하기 어렵게 만든다.

2.1. 접근 경로와 Google의 공식 포지셔닝

1. 접근 가능한 제품군

   1. 개발자와 기업은 API, AI Studio, Gemini 플랫폼에서 사용할 수 있다.
   2. Google AI Ultra 구독자는 Antigravity에서 사용할 수 있고, Gemini 앱과 검색의 AI Mode에서는 Google AI Ultra·Pro 구독자가 사용할 수 있다.
   3. Theo는 이를 나열하다가 Google의 제품 라인이 얼마나 복잡해졌는지 새삼 깨달았다며 “엉망이다”라고 평한다.

2. Google이 내세운 능력

   1. 코딩, 금융, 법률, 사이버 보안, 과학 등 복잡한 현실 업무의 심층 작업(deep work)을 잘한다고 홍보한다.
   2. 여러 단계 작업에서 깊이와 정밀도가 높아 여러 도메인의 프런티어 모델을 벤치마크에서 앞선다고 주장한다.
   3. 금융·코딩·법률·세무 같은 핵심 경제 부문의 모델 성능을 측정하는 VL Index에서 1위를 차지했다고 한다.
   4. Chrome 브라우저 기능 코드를 풀어내 여러 개의 깔끔한 변경을 한 번에 만들었고, 수백 개 파일을 가로지르는 아키텍처 리팩터링을 수개월에서 수주로 줄였다고 한다.
   5. 운영 중인 Python 코드베이스 최적화도 몇 시간 만에 끝냈다고 홍보한다.
   6. Antigravity를 사용한 팀에서 에이전트 코드 제출이 35% 이상 늘고 코드 롤백이 거의 3분의 1 줄었다고 주장하지만, Theo는 기존 도구도 좋지 않았다는 점을 감안하면 대단한 수치가 아니라고 본다.
   7. Google 직원이 Argan을 “혁명적이다”라고 설명하지 않고 “Opus 5를 찾는 일이 줄었다”고 표현했다. 이는 최신 Opus 5.5가 아니라 Theo가 처음에는 혹평했다가 자신이 틀렸음을 인정한 구형 Opus 5를 뜻한다.

3. 공식 데모와 소프트웨어의 역설

   1. Google은 멋진 3D 모델과 애니메이션을 보여주지만, 이는 완성된 생성 영상이 아니라 생성된 3D 모델을 별도 소프트웨어의 로토스코프 비슷한 처리로 영상처럼 보여준 것이다.
   2. 애니메이션은 여전히 어색하고, 데모 페이지의 YouTube 플레이어는 오버레이가 사라지지 않는 버그를 보인다.
   3. Theo는 “Google이 좋은 모델을 가졌는지는 소프트웨어가 마침내 작동하기 시작할 때 알 수 있다”는 식으로 Google의 제품 완성도를 비꼰다.
   4. Deote 관계자는 장시간 작업에서 컨텍스트를 유지하고 여러 도구를 사용하며 평가에서 100% 성공했다고 말했지만, Theo는 무엇을 평가했는지가 빠진 100% 주장은 의미가 약하다고 본다.

2.2. 제3자 지표와 잘못된 가격 비교

1. Artificial Analysis Intelligence Index

   1. Gemini 4 Argan의 점수는 Astra와 GPT-6.1 Soul보다 높지만, Opus 5.5의 High보다 의미 있게 낮고 X High·Max에는 더 크게 뒤처진다.
   2. 점수가 낮은데도 Opus 5.5 High보다 비싸며, Artificial Analysis 지표는 코드 능력을 완벽하게 측정하지 않지만 일반적인 지능 위치를 가늠하는 참고자료가 된다.
   3. Theo는 모델 가격을 먼저 보여주면 사람들이 토큰 가격만 보고 판단한다고 우려한다. 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러만 보면 Opus 5.5의 약 5.25달러대 입력 가격과 비교해 매우 싸 보이기 때문이다.

2. 저렴해 보이는 가격을 무너뜨리는 토큰 사용량

   1. Argan은 토큰을 많이 먹는(token-hungry) 모델이며 특별히 효율적이지 않으므로, 실제 Intelligence Index 비용 구간에서는 싸지 않다.
   2. Antigravity에서 캐시 읽기(cache read) 적중률도 최근 사용한 모델 중 최악이었다. Argan은 70~80% 정도인 반면 다른 모델은 99% 이상이었다.
   3. 캐시 읽기에 적용되는 95% 할인은 적중할 때만 의미가 있으므로, 낮은 적중률은 입력 비용을 크게 높인다.
   4. 이 문제가 Antigravity의 요청 전송·사용량 보고 방식 때문인지, T3 Code가 사용하는 MCP 구현 버그인지 확정할 수는 있다.
   5. Theo는 Google이 확인해야 할 문제를 자신이 더 파고들 생각은 없으며, Google의 끔찍한 CLI는 절대 쓰지 않겠다고 말한다.

3. 잘못된 Muse Wonderful 가격 표기

   1. 비교 표에는 Muse Wonderful의 입력 4달러·출력 20달러 가격이 적혀 있었지만, Theo는 자신이 토큰 가격을 받은 적이 없고 그 표기가 틀렸다고 지적한다.
   2. Wonderful은 표준 Wonder와 같은 가격일 수 없으므로, 이 오류가 비교 자료 전반에 대한 신뢰를 낮춘다고 말한다.

2.3. 가격 인상과 실제 비용

1. 도입 가격

   1. 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러는 영구 가격이 아니라 도입 가격이다.
   2. 12월 1일부터 입력은 4달러, 출력은 20달러로 두 배가 된다.
   3. Google이 모델을 실제로 서비스할 수 있는 가격을 처음부터 제시하지 않고 한동안 낮춘 뒤 올리는 정책을 반복한다고 비판한다.

2. 개발자에게 주는 신호

   1. 사용자가 모델 위에 제품을 깊게 구축하기 시작할 즈음 비용이 오를 수 있으므로 장기 의존을 망설이게 만든다.
   2. 가격을 나중에 낮추는 것은 이해할 수 있지만, 정기적으로 가격을 올리는 연구소는 Google뿐이라고 Theo는 비꼰다.
   3. Meta가 Wonderful 가격을 아예 공개하지 않고 구독에만 넣은 것보다는 낫지만, 실제 제공 원가에 맞는 가격을 처음부터 공개하라는 것이 결론이다.

3. Skatebench, 멀티모달 능력과 프런트엔드 작업 (07:30~16:55)

특정 벤치마크와 디자인 작업에서 Gemini 4 Argan은 분명한 강점을 보이지만, 빠른 토큰 생성과 빠른 문제 해결은 다르다.

3.1. Skatebench 만점과 평가의 한계

1. 스케이트보드 트릭 명명 테스트

   1. Theo의 비공개 Skatebench에서 Gemini 4 Argan은 처음으로 100% 만점을 받았다.
   2. 비교 대상인 Opus 5.5 Max는 79%였고, Google의 Gemini 2.8 Flash도 과거 96%로 이 영역에서 특이하게 강했다.
   3. 대부분의 모델은 80%대, 70%대, 심지어 50~60%대에 머물렀고, Gemini와 Muse Wonderful만 90%를 넘겼다.
   4. 스위치(switch)·페이키(fakie)처럼 보드 위에 선 자세까지 포함하는 스케이트보드의 문법이 모델에 어렵기 때문에 이 벤치마크는 예상보다 난도가 높다.

2. 만점의 조건

   1. 초기 테스트에서 Gemini API는 매우 불안정해 오류가 자주 발생했고, Theo는 엔드포인트 오류를 피하려고 벤치마크 자체를 크게 손봐야 했다.
   2. 답을 빠르게 내고 과하게 생각하지 않았다는 점은 Gemini 계열에서 보기 드문 토큰 효율의 개선이었다.
   3. 스케이트보드 트릭 이름처럼 좁고 특수한 작업이라면 속도·토큰 효율·정확성 모두에서 좋은 경험을 할 가능성이 있다.
   4. 그러나 대부분의 사람이 생업으로 스케이트보드 트릭 이름을 붙이는 것은 아니며, Theo는 그런 직업을 갖고 싶지만 현실에는 없다고 농담한다.
   5. “평가에서 100% 성공했다”는 문장은 평가 과제가 실제 업무와 얼마나 가까운지 함께 봐야 한다.

3.2. 멀티모달·비전과 가격의 재확인

1. 멀티모달 주장

   1. Google은 고급 추론과 멀티모달 능력, 엄격한 근거성(grounding)을 강조하며 문서·PDF·영상·오디오를 잘 다룬다고 주장한다.
   2. Gemini 계열은 마더보드 사진을 보고 부품에 라벨을 붙인 뒤 Python으로 이미지 위에 그리는 작업처럼 시각 처리에서 역사적으로 강했다.
   3. Theo는 이번 평가를 코드 중심으로 진행해 비전 벤치마크를 실행하지 않았지만, 복잡한 비전 업무라면 Gemini 4와 다른 모델을 직접 비교할 가치가 있다고 한다.
   4. 국제화·현지화·다국어 작업에서 강하다는 사용자 의견도 들었으나, Theo의 테스트에서는 그 고유 능력을 뚜렷하게 확인하지 못했다.

2. 모델 고유성의 변화

   1. 과거에는 Google이 가진 데이터와 제품 접근권 때문에 Gemini에만 있던 능력이 많았지만, 최근에는 외부 모델도 그 기능을 따라잡았다.
   2. 그래도 Skatebench 만점처럼 설명하기 어려운 비밀 소스(secret sauce)는 남아 있을 가능성이 있다.
   3. 모델들이 사전학습 데이터와 코드 강화학습을 비슷하게 공유하면서 고유 능력이 줄어드는 흐름 속에서도 Google은 아직 일부 고유성을 보유한다.

3.3. 프런트엔드 생성 능력과 디자인 스킬

1. 과거 활용 경험

   1. Gemini 3 Pro와 3.1 Pro가 새로 나왔을 때 Theo는 프런트엔드에 자주 사용했다.
   2. Frame.io의 대안인 Lawn은 영상 관리 플랫폼이며, 회사의 모든 YouTube 영상이 이 서비스에 올라가 팀이 관리한다.
   3. Lawn의 UI·UX 상당 부분은 Gemini 3.1 Pro로 만들었고, 당시 Opus 계열과 번갈아 사용하면서 독특한 홈페이지를 만들 수 있었다.

2. Argan의 결과

   1. Argan이 만든 홈페이지는 텍스트가 지나치게 많다는 단점이 있지만 매우 보기 좋고, 웹을 돌아다니다가 AI 생성물이라는 사실을 모를 정도였다.
   2. 상호작용 섹션도 실제로 작동했고 억지스럽지 않았다. Theo는 흠을 잡을 수 있다면 많이 잡겠지만 이 결과는 괜찮다고 인정한다.
   3. Witch AI라는 도구에서 모델별 결과를 비교했으며, 이 도구는 Theo의 지인 Dra가 만들었고 whichi.dev에서 확인할 수 있다.

3. 스킬의 영향

   1. Anthropic의 공식 디자인 스킬을 켠 결과는 괜찮고 독특한 레이아웃을 만들었다.
   2. 스킬을 끄면 불필요한 텍스트, 거친 폰트, 모든 결과에 반복되는 못생긴 상단 내비게이션, 지나치게 진부한 레트로 디자인이 나타났다.
   3. Anthropic의 taste 스킬은 오히려 어색한 상단 내비게이션과 일관되게 나쁜 레이아웃을 되돌려 놓으므로 추천하지 않는다.
   4. 디자인 스킬은 모델에게 보기 좋고 서로 다른 결과를 만들도록 압박하는 균형점으로 평가된다.

4. 최고 수준인지에 대한 판단

   1. 프런트엔드 능력은 꽤 좋지만 최첨단은 아니다.
   2. Fable 5.1이 홈페이지·마케팅 사이트에서 가장 멋지고 독특한 결과를 만들며, Opus는 순간적으로 좋을 때가 있다고 평가된다.
   3. 어떤 모델도 첫 시도에 올바른 결과를 완성하지 못하므로, 원하는 결과를 설명하고 여러 버전을 오가며 빠르게 다듬을 수 있어야 한다.
   4. Slopolytics 사이트는 OpenAI 모델과 Astra의 Ultraast를 사용해 만들었으며, Ultraast가 마법처럼 디자인을 잘해서가 아니라 빠른 왕복 수정이 가능해서 선택했다.
   5. 마케팅 페이지보다 실제 사용자가 누르는 버튼과 상호작용하는 UX를 만들 때는 토큰 생성 속도보다 반복 수정의 총 시간이 중요하다.
   6. Google 모델은 토큰을 빠르게 생성할 수 있지만 문제를 빠르게 해결하지는 못한다. Theo의 경험에서 Argan은 빠른 모델이 아니다.

4. Google 모델의 고유 기능과 YouTube 활용성 (15:00~17:19)

모델의 지능과 별개로 독점적인 데이터·API 접근권은 Gemini를 실무 파이프라인에 남겨두는 강력한 이유가 된다.

4.1. 각 연구소가 제공하는 고유 기능

1. 모델과 도구의 결합

   1. OpenAI 모델은 자체 이미지 생성 API와 이미지 모델을 직접 호출할 수 있다.
   2. Claude 계열은 자체 이미지 생성기가 없으므로 외부 서비스를 호출해야 한다.
   3. Grok은 X/Twitter API 접근이 강점이다. X API를 직접 쓰면 너무 비싸므로 Theo는 Codex나 Claude에게 Grok을 호출하게 해 XAI의 API를 이용한다.
   4. 특정 모델이 독점 데이터에 접근할 수 있다면 그 모델을 통해서만 얻을 수 있는 결과가 생긴다.

2. Gemini가 가진 접근권

   1. YouTuber인 Theo는 YouTube에서 일해야 할 일이 많으며, Google은 Gemini에 YouTube API와 관련 기능을 매우 관대하게 제공한다.
   2. YouTube 자막을 얻는 목적에는 Gemini API가 현재 가장 좋은 방법 중 하나다.
   3. Theo의 여러 사업은 이런 Google 모델 기능을 이미 많이 사용하므로 Gemini 4를 계속 사용할 예정이다.
   4. 이는 특별히 지능이 뛰어나거나 가성비가 좋아서가 아니라 Google이 가진 API, 데이터센터, 독점 데이터 접근권 때문이다.

4.2. Google 서비스 자체에서의 실망

1. 서비스 통합의 낮은 신뢰도
   1. 이메일 받은편지함을 다루는 작업은 Gemini보다 Grokbot이나 ChatGPT에서 더 나은 경험을 얻었다.
   2. 애플리케이션에 Gemini 버튼이 나타나면 기능이 작동하지 않거나 결과가 민망한 경우가 많아 오히려 불안하다고 한다.
   3. YouTuber 또는 YouTuber 관련 업무를 한다면 Gemini는 파이프라인에서 유용할 가능성이 높다.
   4. 독특한 비전 작업도 과거 강점이 남아 있으므로 직접 벤치마크할 가치가 있지만, 과거만큼 독점적인 영역은 아니다.

5. Fishlop 3D 게임 테스트와 ‘큰 모델 냄새’의 부재 (17:19~21:24)

Fishlop은 같은 프롬프트·환경·도구로 모델의 3D 생성 능력을 비교하는 Theo의 게임이며, Argan은 외형을 개선했지만 시스템을 이해하는 판단력이 부족했다.

5.1. 첫 번째 Fishlop 결과

1. 시각적 결함

   1. 화면 위쪽 물의 표면이 심하게 깨졌으며, 인코딩 문제가 아니라 모델이 실제로 그렇게 만들었다.
   2. UI는 전형적인 Gemini식 결과였고, 5개의 수조를 차례로 통과하는 전체 게임 루프는 제대로 만들었다.
   3. 잠수함 모델은 Muse나 Grok만큼 나쁘지는 않았지만, 사람들이 올린 화려한 3D 데모에 기대한 수준에는 미치지 못했다.

2. 부분적으로 좋은 3D 구현

   1. 물고기의 움직임은 합리적이었고 애니메이션은 어느 정도 작동했다.
   2. 물고기의 눈이 올바른 방향을 향했다. 몇 달 전만 해도 이것은 드문 능력이었다.
   3. Theo는 다른 모델에 사용한 것과 정확히 같은 프롬프트·설정·도구를 제공했으므로 환경 차이로 결과를 설명하기 어렵다고 봤다.

5.2. 먹이 시스템의 치명적인 설계 결함

1. 물고기가 먹이를 먹지 못하는 상태

   1. 먹이가 수조 바닥으로 떨어질 수 있지만 만료되지 않는다.
   2. 물고기는 배고파서 바닥으로 와 먹으려 하지만 바닥의 먹이를 먹는 방법을 구현하지 못한다.
   3. 물고기는 먹이를 바라보며 계속 먹으려 시도하다가 죽는다.
   4. 수조에 넣을 수 있는 먹이 양도 제한돼 있어 새 먹이를 무한히 추가해 우회할 수 없다.
   5. 만료 처리도 빠져 먹이가 영원히 남으므로 게임 루프가 막힌다.
   6. 초반에는 사운드 라우팅도 작동하지 않았다. Theo는 사운드를 고쳤지만 게임 자체가 특별히 좋은 소리를 내는 것은 아니며 처음부터 소리가 없었던 것은 큰 손실이 아니라고 농담한다.

2. 두 번째 시도

   1. Theo는 수조 천장의 반짝임, 만료되지 않는 먹이, 바닥 먹이에 접근하지 못하는 문제, 실망스러운 그래픽을 구체적으로 지적하고 개선을 요구했다.
   2. Argan은 한동안 실행한 뒤 외관을 크게 개선했고 먹이 관련 문제도 많이 고쳤다.
   3. 잠수함 모델은 그대로였지만 Theo는 개선된 버전을 실제로 잠시 플레이할 수 있었다.

5.3. Geminiism과 시스템 수준의 사고 부족

1. ‘큰 모델 냄새’의 의미

   1. Theo가 말하는 big model smell은 더 큰 모델이 세계를 더 잘 이해할 때 드러나는 사려 깊음과 일반화 능력을 뜻한다.
   2. 3D 능력은 모델의 지능 전체를 반영하지 않는다. 3D는 별도로 학습된 기능을 추가하는 영역이기 때문이다.
   3. Argan은 3D 훈련을 더 받은 흔적이 있지만, 다른 모델에서는 잘 보지 못한 단순하고 멍청한 실수를 만들었다.

2. 무용한 공격력 파워업

   1. 괴물은 1분마다 생성되고, 웨이브를 끝내면 파워업을 떨어뜨리며, 파워업은 30초 동안 지속된다.
   2. 공격력을 높이는 파워업을 얻었을 때는 쏠 수 있는 괴물이 수조에 없고, 괴물이 다시 나타날 때는 파워업이 이미 사라진다.
   3. 따라서 파워업 하나는 실제로 아무 기능도 하지 않는다.
   4. 이는 환각이라기보다 시스템의 시간 관계를 생각하지 않고 그럴듯한 코드를 만든 결과다.
   5. 사람이나 충분히 똑똑한 모델이라면 괴물이 파워업 지속 시간 안에 나타나는지 확인했을 것이지만, Argan은 공격력 파워업 아이디어를 만들고 바로 구현했다.

6. 환각 벤치마크와 현실 코드 감사의 충돌 (21:24~29:53)

공개 환각 지표는 낮은 오류율을 보여주지만, 실제 코드베이스에서의 주장 검증은 정반대의 결과를 낸다.

6.1. AI Omniscience 벤치마크의 해석

1. 공개 수치

   1. Artificial Analysis의 AI Omniscience 벤치마크에서 Gemini 4 Argan의 환각률은 15%였다.
   2. 지능 지수 45점 이상인 모델 중 가장 낮은 환각률이라고 소개된다.
   3. 공식 차트만 보면 Argan은 환각을 매우 적게 하는 모델처럼 보인다.

2. 점수 구성의 함정

   1. 이 벤치마크는 환각만 측정하지 않고, 오답·부분 답변·거부를 함께 계산한다.
   2. 정답이면 점수를 얻고, 틀리면 점수를 잃으며, “답할 수 없다”고 하면 중립으로 처리된다.
   3. Argan은 틀린 답을 피하기 위해 거부하는 비율이 높아 전체 점수에서는 1위가 아니라 4위로 내려간다.
   4. 즉, “도와줄 수 없다”고 말해서 오답을 피하는 것이 실제 유용성과 같지는 않다.
   5. Theo는 Google이 환각을 줄인 점 자체는 인정하지만, 자신의 일상적인 코드 작업에서 Argan이 자주 틀렸기 때문에 이 벤치마크가 현실적이지 않다고 판단한다.

6.2. TS Rust 코드베이스 감사

1. 실험 설계

   1. TS Rust는 Theo가 TypeScript 컴파일러 전체를 Rust로 다시 작성한 프로젝트이며, 이 작업에는 Opus 5.5를 사용했다.
   2. 여러 모델에게 코드베이스를 감사하고 개선점을 설명하게 했다.
   3. 모델이 한 모든 주장을 사실인지 검증한 뒤, 평가자 패널이 정보성·정확성·유용성을 점수화했다.

2. 비교 모델 결과

   1. GPT-6.1 Soul은 38개 주장을 모두 참으로 판정받고 8.84점을 기록했다.
   2. Opus 5.5는 8.78점으로 약간 낮았고 한 주장이 틀렸다. 49분이 걸렸으며 24달러가 들었고, Soul의 28분·4달러보다 느리고 비쌌다.
   3. 6 Astra는 틀린 주장이 없었고 20분으로 빨랐지만 여전히 비용이 높았다.
   4. Soul의 X High에서는 결과가 더 좋아졌고, Astra Max가 Astra X High보다 낮은 점수를 받아 최고 추론 단계가 항상 좋은 것은 아니라는 기존 관찰을 재확인했다.

3. Gemini 4 Argan 결과

   1. Argan은 4.38점으로 Opus와 Soul의 절반에도 못 미쳤다.
   2. 43분이 걸려 Soul의 28분보다 거의 두 배였고, X High에서 걸린 시간보다도 두 배 이상 길었다.
   3. 비용은 3달러로 낮았지만, 36개 주장 중 24개가 거짓이었다.
   4. 코드베이스에 대해 말한 내용의 다수가 틀렸으므로, 실제 코드 작업에서 맞을 가능성과 틀릴 가능성이 비슷하거나 틀릴 가능성이 더 높다는 뜻이다.
   5. Muse Wonderful은 33개 중 8개가 틀렸고, Fable 5.1은 33개 중 11개가 틀렸다. 두 모델은 오류 수가 비교 가능하지만 24/36은 전혀 다른 수준이다.
   6. Theo는 Argan을 Opus 5.5, Fable 5.1, 6 Astra, GPT-6.1 Soul, 심지어 Muse Wonderful과 같은 프런티어 수준으로 보는 사람이 실제 코드를 다루고 있는지 의문을 제기하며, 틀렸다면 데모를 보여 달라고 요청한다.

6.3. T3 Code의 원격 일괄 업데이트 버그 감사

1. 모델별 결과

   1. Opus 5.5는 8.22점을 받았고 46개 주장 중 5개가 틀렸으며, 26달러·20분이 들었다.
   2. GPT-6.1 Soul은 Opus가 찾은 고위험 문제 일부를 놓쳤지만 틀린 말은 하지 않았다. 10분에 1달러가 들어 리뷰 모델로서 매우 인상적이었다.
   3. Muse Wonderful은 점수가 더 낮았고 Opus와 비슷한 오류율이었지만 6분 만에 끝났으며, 결과가 매우 읽기 쉬웠다.

2. 모델 성격에 대한 비교

   1. GLM 5.3 Flash, Kimi K3 같은 오픈 웨이트 모델은 서로 말투와 행동이 비슷한 증류 모델처럼 보인다.
   2. Argan과 Muse Wonderful은 서로 완전히 다른 방식으로 행동하므로 단순한 복제품은 아니다.
   3. 그러나 Argan은 그 차이를 정당화할 만큼 똑똑하지 않고, Muse Wonderful Full은 가격을 모르는 상태에서 그 차이를 정당화할 만큼 저렴한지 판단하기 어렵다.
   4. 표준 Muse Wonderful은 40개 중 14개를 틀렸지만, 적어도 Argan처럼 36개 중 24개를 틀리는 수준은 아니며 Theo가 Muse에 더 관대했던 이유가 여기에 있다.

6.4. Lakebed 61 코드 제품 감사

1. 정확도 비교

   1. GPT-6.1 Soul은 10점 만점에 9점을 받았다.
   2. Sonnet 5.5는 8.5점을 받았고, Max 추론이 문제를 찾을 때까지 토큰을 계속 태우는 성향 때문에라도 많은 것을 찾아냈다.
   3. Muse Wonderful은 Opus 5.5의 8.25 수준에서 5.75로 하락했다.
   4. Gemini 4 Argan은 2.25점에 그쳤다.

2. 거짓 발견의 규모

   1. Argan의 발견 78개 중 56개가 틀렸으며, 실패율은 70%다.
   2. 이 정도면 에이전트에게 유용한 리뷰를 제공하기보다 가스라이팅할 가능성이 더 높다.
   3. 부득이하게 사용한다면 Soul·Opus처럼 오류율이 낮은 모델을 후속 검증기로 붙여야 한다.
   4. Theo는 일상적인 실제 코드 작업에서 Argan이 환각하지 않는 모습을 거의 본 적이 없는데, 어떤 벤치마크가 이를 낮은 환각률로 측정했는지 이해할 수 없다고 말한다.

6.5. T3 Code 아키텍처 감사

1. 판정 수치

   1. Argan은 10점 만점에 3.95점을 받았다.
   2. 참인 발견은 31개, 부분적으로 참인 발견은 14개, 거짓 발견은 47개였다.
   3. Muse Wonderful은 참 29개, 부분 참 8개, 거짓 4개였다.
   4. Argan의 거짓 발견 수가 Muse Wonderful의 참인 발견 수보다 많았다.

2. 가독성과 최종 평가

   1. Argan은 필요한 것보다 훨씬 많은 텍스트를 쏟아내고 중요도가 낮은 내용을 벽처럼 늘어놓아 읽기 불편했다.
   2. 표준 Muse Wonderful과 Argan은 이 벤치마크에서 유일하게 나쁜 모델이며, Theo는 표준 Muse를 버리고 건드리지 말라고 한다.
   3. Muse Wonderful Full은 괜찮지만 표준 Muse Wonderful과 Gemini 3·4 계열은 T3 Code에 유용한 코드를 기여하지 못한다고 선을 긋는다.

7. SQLite PR 사례와 검증하지 않는 에이전트 (29:53~33:54)

Argan은 문제의 핵심 메커니즘을 일부 발견했지만, 자신의 진단을 검증하지 않은 채 1,200줄짜리 잘못된 PR을 만들었다.

7.1. 문제 진단과 잘못된 우선순위

1. SQLite 연결 계층 문제

   1. T3 Code는 Windows 같은 플랫폼의 무거운 사용 환경에서 연결 불안정성이 있어 SQLite 연결 계층을 손보려 했다.
   2. Theo는 이미 많은 수정 방향을 알고 있었고, Argan이 스스로 문제를 찾는지 확인하려고 했다.
   3. 사용자 보고에는 연결 불안정성이 많았고 SQLite 관련 문제가 상당수로 보였으며, Theo는 async SQLite라는 힌트도 제공했다.
   4. 올바른 해법은 읽기 풀(read pool)과 단일 쓰기 연결(single write)을 사용하는 연결 풀링이다.

2. Argan의 조사 방식

   1. Argan은 파일을 하나씩 동기적으로 전부 읽는 전형적인 Geminiism을 보이며 길게 돌아다녔다.
   2. 읽기 풀과 단일 쓰기 연결을 분리해야 한다는 핵심 조각은 찾아냈지만, 전체 시스템에서 그 변경이 실제로 문제를 해결하는지 확인하지 않았다.
   3. Theo가 첫 번째 우선순위 항목을 PR로 만들라고 하자 Argan은 그 항목이 옳은지 검증하지 않고 문자 그대로 최대 규모로 구현했다.

7.2. 30분 만에 만든 1,200줄짜리 실패 PR

1. 크기와 시간

   1. Argan은 PR을 만드는 데 30분이 걸렸고, 30줄이면 될 변경을 1,200줄로 만들었다.
   2. T3 Code가 Google의 서버에서 제공하는 ACP 바인딩을 사용하므로 느린 것이 T3 Code의 잘못이라고 볼 수 없다.
   3. PR은 결국 닫혔으며, Theo는 변경 자체가 과도하게 커진 순간 이미 포기할 준비가 됐다고 말한다.

2. 저장소 규칙과 품질 실패

   1. 저장소에는 PR을 작성하는 스킬이 있고, 사용자가 겪은 문제와 고칠 내용을 2~3문장으로 간단히 설명해야 한다.
   2. Argan은 이를 지키지 않고 “오케스트레이션 프로젝션 및 쿼리 서비스의 특정 파일에서 SQLite 읽기와 쓰기를 분리했다”는 식의 긴 요약을 썼다.
   3. 문장은 읽기 어려운 run-on sentence였고 저장소 규칙을 따르지 않은 슬롭이었다.
   4. CI의 check와 lint가 모두 실패했지만 Argan은 이를 고치지 않았고 리뷰 봇의 고·중요도 댓글도 처리하지 않았다.

7.3. Opus 5.5가 찾아낸 진짜 문제

1. PR 폐기 과정

   1. Theo는 PR 스레드 ID를 Opus 5.5에 붙여 넣고, Argan이 만든 PR이 형편없고 문제도 제대로 설명하지 않았으니 T3 Code 스레드를 검토해 잘못된 부분을 찾아 닫으라고 했다.
   2. Opus는 슬롭이라는 데 동의하고 잘못된 이유를 댓글로 남긴 뒤 PR을 닫았다.

2. 진단의 절반만 맞춘 수정

   1. Argan의 첫 번째 진단은 대부분 맞았지만 증거가 없었다. 동기식 데이터베이스 동기화가 메인 스레드에서 실행된다는 실제 메커니즘은 찾아냈다.
   2. 두 번째 단계에서는 자신의 진단 중 잘못된 절반을 고쳤다.
   3. 읽기 풀도 여전히 메인 스레드에서 데이터베이스 동기화를 열었고, 읽기 연결에서 느린 읽기가 발생하면 쓰기 연결과 똑같이 하트비트를 막았다.
   4. 바뀐 효과는 특정 세마포어 호출에서 기다리는 시간이 줄어드는 것뿐이며, 트랜잭션 안에서 fiber가 양보할 때에만 의미가 있었다.

3. 선행 사례를 찾지 않은 문제

   1. 이미 같은 문제를 해결한 PR이 두 개 있었지만 Argan은 GitHub의 PR 탭에서 선행 사례를 확인하지 않았다.
   2. Muse Wonderful은 “코드를 작성하지 않겠다. 대신 고치는 PR이 있으니 그것을 병합하라”고 말했지만, Argan은 기존 정답을 찾는 대신 틀린 해결책을 발명했다.
   3. Argan은 요청을 라우팅하는 데 React를 사용하기까지 했으며, Theo는 이 사실이 농담이 아니라고 강조한다.
   4. Opus의 판단에 따르면 Argan은 코드를 읽고 설명할 수는 있지만 자신의 이론을 테스트하지 않는다.
   5. 읽기 풀을 메인 스레드에 둬도 이벤트 루프가 막히지 않는지 묻지 않았고, 느슨한 질문에 자신감 있는 로드맵과 근거 없는 비율을 붙였다.

4. 사람이 마무리한 수정

   1. Theo가 Opus의 판단을 따른 뒤 실제 수정은 21줄로 끝났고 병합됐다.
   2. 수정은 다음 nightly 릴리스에 들어가 SQLite 사용자의 경험을 개선할 예정이다.

8. Google 계정 위험과 Antigravity·ACP 통합 불안정성 (33:54~36:07)

Gemini 생태계는 모델 품질뿐 아니라 계정 정지와 통합 실패의 비용도 다른 모델보다 크다.

8.1. 계정 정지의 비대칭 위험

1. Anthropic·OpenAI 계정

   1. Anthropic 계정이 정지되면 새 이메일로 다시 열 수 있어 손실이 제한적이다.
   2. OpenAI 계정 정지도 조금 더 번거롭지만 새 계정을 만들면 된다.
   3. Google 계정으로 두 서비스에 로그인했더라도 정지되는 것은 Anthropic 또는 OpenAI 로그인 자체다.

2. Gemini 계정이 곧 Google 계정인 문제

   1. Gemini 계정이 정지되면 YouTube 채널을 잃을 수 있다.
   2. 이메일, 신용카드 청구 시스템, Chrome에 저장한 비밀번호, YouTube 채널 접근권, Google 로그인으로 연결된 모든 서비스 접근권을 함께 잃을 수 있다.
   3. Google은 Gemini와 Antigravity만 정지하고 Google 전체 계정은 정지하지 않겠다고 약속했지만, 실제로 Google 계정까지 정지됐다는 사례를 봤다는 것이 Theo의 경고다.
   4. 따라서 공식 ACP를 T3 Code에 통합하는 일 자체가 위험한 선택이었다.

8.2. ACP 게이트웨이와 제품 통합의 실패

1. 실행 중 연결 끊김

   1. Argan은 수많은 파일을 1시간 2분 동안 읽은 뒤 게이트웨이에 연결하지 못하고 중단됐다.
   2. 작업을 이어가지도, 기존 스레드 기록을 보존하지도 않아 전체 스레드를 처음부터 다시 시작해야 했다.
   3. 이런 실패는 단순히 모델이 조금 느린 문제가 아니라 에이전트 작업의 신뢰성을 무너뜨린다.

2. Google식 ACP 구현

   1. ACP에서 모델을 보고 effort를 선택하는 대신, Google은 모델 slug와 effort 수준을 묶어 Argan High, Argan Medium, Argan Low를 각각 모델처럼 선택하게 한다.
   2. 다른 연구소는 이런 기본적인 표준 통합을 제대로 처리하지만 Google은 단순한 ACP 구현도 어긋나게 만들었다.
   3. T3 Code의 버그 중 Antigravity 전용 버그 비율이 높고, 통합 이후 계속 골칫거리였다.
   4. Gemini 4로 처음으로 비교적 쓸 만한 Gemini UI를 얻은 것은 안도감이었지만, Muse·Opus·Sonnet 같은 제대로 작동하는 모델 옆에 놓으니 오히려 격차가 더 아프게 드러났다.

9. 최종 판정: YouTube 데이터에는 사용하지만 코드에는 사용하지 않는다 (36:07~38:30)

실제 업무에서 검증할 수 없는 모델은 가격과 공개 벤치마크가 좋아도 T3 Code에 투입할 수 없다.

9.1. 구독 한도보다 중요한 실사용 신뢰

1. 200달러 플랜에 대한 무관심

   1. Theo는 200달러 플랜의 사용량이 얼마나 되는지 묻지 말라고 한다.
   2. 사용량이 사실상 무제한이어도 모델이 답답해서 사용자가 곧 포기할 것이므로 의미가 없다고 본다.

2. 자동 차단 구상

   1. Gemini 4 Argan 또는 표준 Muse Wonderful이 작성한 T3 Code PR을 자동으로 닫는 방법을 찾겠다고 했다.
   2. 이는 과장이 아니라, 잘못된 코드를 검증하는 데 쓴 시간과 토큰이 더 똑똑한 모델로 처음부터 작성했을 때보다 많았기 때문이다.
   3. Muse Wonderful Full은 괜찮지만 표준 Muse Wonderful과 Gemini 3·4 등은 T3 Code에 유용한 코드를 기여하지 못한다는 구분을 다시 강조한다.

9.2. 남겨둘 수 있는 사용처

1. 제한적으로 쓸 작업

   1. Gemini는 코드 세계에서 보기 좋은 마케팅 페이지의 첫 번째 또는 두 번째 초안을 만드는 정도에는 쓸 수 있다.
   2. YouTube 자막·데이터 수집은 Google의 독점적인 API 접근권 덕분에 계속 맡길 수 있다.
   3. 복잡한 비전·다국어 작업은 직접 벤치마크해 이점이 확인될 때만 사용해야 한다.

2. 코드 모델로서의 판정

   1. Theo는 Gemini 4 Argan을 올해 최악의 출시 중 하나로 평가한다.
   2. 벤치마크가 뭐라고 하든 실제 업무에서 계속 테스트했지만 Argan이 만든 것을 단 하나도 병합하지 않았다.
   3. 코드 환각 수준이 2024년으로 돌아간 듯하며, Google 직원들이 피드백에 잘 반응해 왔기 때문에 지금까지 예의를 지켰다고 설명한다.
   4. Carbon이라는 더 나은 스냅샷이 곧 나온다는 소문을 들었지만, Argan보다 훨씬 좋아야 의미가 있다.
   5. 마지막 선택지는 Muse가 아니라 진지하게는 Opus 5.5로 돌아가는 것이다.

9.3. 결론과 실용적 시사점

1. 가격표는 토큰 단가가 아니라 실제 토큰 사용량·캐시 적중률·오류 검증 비용까지 합산해 평가해야 한다.
2. 좁은 벤치마크의 만점은 실제 코드베이스에서의 사실성·선행 사례 탐색·자기 검증 능력을 보장하지 않는다.
3. 3D 결과물이 보기 좋아도 게임 규칙과 시간 관계를 이해하지 못하면 실무에서 신뢰할 수 없다.
4. 환각률 벤치마크는 거부율과 부분 답변의 처리 방식을 확인하지 않으면 현실 업무의 오류율을 과소평가할 수 있다.
5. 실제 코드 감사에서는 주장마다 근거를 확인하고, PR은 저장소 규칙·CI·lint·리뷰 댓글·기존 PR을 모두 통과한 뒤 병합해야 한다.
6. Google 계정과 YouTube 채널이 연결된 사용자는 Gemini·Antigravity의 정지 정책과 ACP 연결 실패를 별도의 운영 리스크로 고려해야 한다.
7. Theo의 최종 선택은 특수한 YouTube 데이터 수집에는 Gemini를 쓰되, T3 Code의 실질적인 코딩에는 Opus 5.5를 사용하는 것이다.

주요 발언 모음

“Gemini 4 Argan은 스케이트보드 트릭 명명 벤치마크에서 100%를 받았지만, 많은 사람이 스케이트보드 트릭 이름을 붙이는 일로 생계를 유지하지는 않는다.”

“이 모델은 토큰을 많이 먹고, 캐시 적중에도 형편없다.”

“모델이 토큰을 빠르게 생성한다고 해서 문제를 빠르게 해결하는 것은 아니다.”

“큰 모델 냄새는 세계를 더 잘 이해하는 모델의 사려 깊음과 일반화 능력이다.”

“Argan은 코드를 읽고 설명할 수 있지만 자신의 이론을 시험하지 않는다.”

“Gemini 4 Argan의 거짓 발견 수는 Muse Wonderful의 참인 발견 수보다 많다.”

“이 모델은 에이전트에게 유용한 피드백을 주기보다 가스라이팅할 가능성이 더 높다.”

“Google이 좋은 모델을 가졌는지는 소프트웨어가 마침내 작동하기 시작할 때 알 수 있다.”

“Gemini는 YouTube에서 데이터를 가져오는 일 외에는 코드 세계에서 유용한 모델이 아니다.”

“이것은 올해 최악의 출시 중 하나다. 벤치마크가 뭐라고 하든 상관없다.”

“다음에는 Muse를 쓰겠다. 진지하게 말하면 아마 Opus 5.5를 쓰겠다.”

핵심 데이터 & 수치

• 출시 공백: Gemini 3.1 Pro에서 Gemini 4 Argan까지 8개월, 과거 대형 모델 간격은 1~2개월이었다.
• 공개 가격: 2026년 11월 30일까지 입력 100만 토큰당 2달러·출력 100만 토큰당 10달러, 12월 1일부터 각각 4달러·20달러로 인상된다.
• 캐시 적중률: Argan 70~80% 대 다른 모델 99% 이상, 캐시 읽기 할인은 95%다.
• 공식 업무 주장: Antigravity 팀의 에이전트 코드 제출 35% 이상 증가, 코드 롤백 거의 3분의 1 감소, Chrome 수백 개 파일 리팩터링을 수개월에서 수주로 단축했다.
• Skatebench: Gemini 4 Argan 100%, Opus 5.5 Max 79%, Gemini 2.8 Flash 96%였다.
• AI Omniscience: Argan 환각률 15%로 지능 지수 45점 이상 모델 중 최저였으나, 거부·부분 답변까지 포함한 종합 순위는 4위였다.
• TS Rust 감사: GPT-6.1 Soul 38개 주장 전부 참·8.84점·28분·4달러, Opus 5.5 8.78점·49분·24달러·오류 1개, Argan 4.38점·43분·3달러·36개 중 24개 거짓이었다.
• 원격 업데이트 감사: Opus 5.5 8.22점·46개 중 오류 5개·20분·26달러, GPT-6.1 Soul 10분·1달러·오류 없음이었다.
• Lakebed 61 감사: GPT-6.1 Soul 9/10, Sonnet 5.5 8.5/10, Muse Wonderful 5.75/10, Argan 2.25/10이며 Argan 발견 78개 중 56개가 거짓이었다.
• T3 Code 아키텍처 감사: Argan 3.95/10, 참 31개·부분 참 14개·거짓 47개; Muse Wonderful 참 29개·부분 참 8개·거짓 4개였다.
• SQLite 수정: Argan의 1,200줄 PR은 폐기됐고, 실제 병합된 수정은 21줄이었다.
• 중단 사건: Antigravity가 파일을 1시간 2분 읽은 뒤 게이트웨이에 연결하지 못하고 작업 기록을 잃었다.

결론 및 시사점

1. Gemini 4 Argan은 3D 외형, 일부 프런트엔드 결과, Skatebench, 비전·YouTube API 접근권에서 쓸모를 보인다.
2. 그러나 실제 코드베이스 감사에서 거짓 주장이 압도적으로 많고, 자신의 진단을 검증하지 않으며, 기존 PR을 탐색하지 않고, 실패한 CI와 lint도 고치지 않았다.
3. 공개 환각률과 실무 오류율이 크게 다르므로 좁은 벤치마크나 공식 홍보문만으로 에이전트 코딩 모델을 선택해서는 안 된다.
4. 낮은 표면 가격은 토큰 과소비, 낮은 캐시 적중률, 두 배 가격 인상, 오류 검증 비용 때문에 실제 가성비로 이어지지 않는다.
5. Gemini 4 Argan은 YouTube 데이터 취득과 제한적인 마케팅 페이지 초안에 한정하고, 신뢰성이 필요한 코드 작성·감사에는 Opus 5.5나 GPT-6.1 Soul을 사용해야 한다.
6. Google 계정 정지 위험과 Antigravity ACP 통합 불안정성까지 고려하면 Gemini를 핵심 개발 인프라에 단독으로 의존해서는 안 된다.