YouTubeClearmud·2026년 8월 15일·0

Grok 4.6 & Gemini 3.7 Flash (LIVE: Watch Me Work)

Quick Summary

Grok 4.6과 Gemini 3.7 Flash의 라이브 비교는 Gemini의 빠른 초기 구현과 Grok의 낮은 비용 가능성을 보여줬지만, 두 모델 모두 정확성·주소 연동·안정성·도구 사용성 측면에서 실서비스 수준에는 도달하지 못했다.

영상 보기

클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.

원본 열기

🖼️ 인포그래픽

Grok 4.6 & Gemini 3.7 Flash (LIVE: Watch Me Work) 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Grok 4.6 & Gemini 3.7 Flash (LIVE: Watch Me Work)의 핵심 내용을 4단계로 요약한 인포그래픽
Grok 4.6 & Gemini 3.7 Flash (LIVE: Watch Me Work) 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Grok 4.6과 Gemini 3.7 Flash의 라이브 비교는 Gemini의 빠른 초기 구현과 Grok의 낮은 비용 가능성을 보여줬지만, 두 모델 모두 정확성·주소 연동·안정성·도구 사용성 측면에서 실서비스 수준에는 도달하지 못했다.

📌 핵심 요점

  1. 동일한 주거용 태양광 리드 퍼널 프롬프트에서 Gemini 3.7 Flash는 늦게 시작하고도 먼저 실행 가능한 결과를 내놓아 초기 생성 속도에서 앞섰다.
  2. Gemini 결과물은 3D 태양 위치와 그림자 제어를 구현했지만 실제 주소 데이터를 반영하지 못했고, 부정확한 패널 배치·상태 초기화·API 키 노출 가능성까지 드러내 표면적인 데모에 머물렀다.
  3. Grok 4.6은 페이지 로드 오류와 플레이스홀더 문제를 해결하지 못했고, 실제 주소를 추가한 뒤에도 주택 렌더링의 핵심 오류가 남아 동일 기준의 완성도 평가가 어려웠다.
  4. 공정한 모델 비교를 위해 외부 API를 배제하면 주소 기반 지리 정보의 정확성이 떨어지고, Google Earth Engine 같은 API를 추가하면 순수 모델 역량을 비교하려는 벤치마크 목적이 훼손되는 충돌이 발생했다.
  5. 실제 사용 경험은 모델만이 아니라 Grok CLI·Anti-Gravity CLI 같은 기본 하네스, 계정별 할당량, 결제 경로에 좌우됐다. 특히 Google AI 구독과 Workspace·Anti-Gravity 사용량의 분리는 테스트 중단과 구독 해지로 이어졌다.

🧩 배경과 문제 정의

  • Grok 4.6과 Gemini 3.7 Flash가 실제 웹 애플리케이션 제작에서 어떤 속도와 완성도를 보이는지 동일한 프롬프트로 비교필요가 있다.
  • 모델 자체의 성능뿐 아니라 전용 CLI와 작업 도구를 포함한 기본 하네스가 결과물의 품질과 사용 경험을 크게 좌우한다.
  • 주거용 태양광 리드 퍼널을 제작하면서 주소 기반 3D 시각화, Google Maps·Solar API 연동, 잠재 고객 전환이라는 복합 요구를 얼마나 충실하게 구현하는지가 핵심 평가 기준이다.
  • 빠른 프로토타입 생성과 실제 서비스 수준의 정확성·API 연동·사용량 정책 사이에는 상당한 간극이 존재할 수 있다.

🕒 시간순 섹션별 상세정리

1. 동일 프롬프트를 이용한 모델 비교 시작

  • 주택 소유자가 주소를 입력하면 해당 부동산의 태양광 잠재력을 3D로 확인하고 상담 단계로 전환되는 완성형 리드 퍼널을 Grok 4.6에 요청한다. 제품·데이터·디자인·기술 의사결정도 모델이 자체적으로 수행해야 한다. [01:28]
  • Gemini 3.7 Flash에도 같은 프롬프트를 입력해 두 모델의 제작 속도와 결과물을 동일한 조건에서 비교한다. [02:21]

2. 가격·성능 평가와 기본 하네스의 중요성

  • Grok 4.6은 저렴한 가격에 비해 높은 역량을 갖췄지만 Claude나 GPT 계열의 최상위 모델과 완전히 동등한 수준은 아니며, 차기 4.7에서 격차를 줄일 가능성이 있다는 추정이 나온다. [07:35]
  • Google은 Gemini Pro보다 Flash 모델을 더 빈번하게 갱신하고 있으며, Pixel 기기처럼 대규모 제품에 Gemini를 탑재하려는 전략이 이러한 집중에 영향을 줬을 가능성이 있다. [08:25]

3. 라이브 진행 방식 조정과 두 번째 웹사이트 테스트

  • 실시간 댓글을 확인하면서 장문 콘텐츠까지 동시에 녹화하기는 어렵기 때문에 장문 녹화는 다음 날로 미루고, 라이브에서는 준비한 필드 테스트에 집중한다. [11:30]
  • 두 번째 과제는 PostHog의 웹사이트 구조를 역설계한 프롬프트로 유사한 사이트를 재구축하는 작업이며, 반복 가능한 모델 평가를 위해 비교적 상세한 요구사항을 포함한다. [12:37]

4. Gemini 결과물의 시각화와 정확성 문제

  • 계절에 따른 태양 위치와 그림자 방향을 조절하는 기능은 작동하지만, 중심 3D 화면이 작고 제어 옵션이 분산돼 있어 기대했던 몰입형 전체 화면 경험에는 미치지 못한다. [14:10]
  • 태양광 발전량 계산의 정확성은 확인하기 어렵고, 패널이 지붕에 옆으로 배치되거나 화면 상태가 반복적으로 초기화되는 등 시각적 결함도 발생한다. [15:10]

5. 실제 주소 연동 실패와 프롬프트 해석의 한계

  • 샌프란시스코 지역의 주소를 선택하려 했지만 자동 완성이나 사전 입력이 작동하지 않았고, 별도로 요구하지 않은 Google Places API 기능이 빠진 것이 원인으로 추정된다. [16:45]
  • 특정 주택을 선택해도 실제 주소의 건물 데이터를 불러오지 않고 기본 주택 모델을 반복해서 보여줘, 주소별 태양광 잠재력을 체험하게 한다는 핵심 요구를 충족하지 못한다. [17:28]

6. 빠른 제작 속도와 얕은 구현의 상충

  • Gemini 결과물은 매우 빠르게 완성됐지만 특정 주택을 선택해 분석하는 기능이 빠지고 초기 미리보기와 동일한 디지털 모델만 반복해, 실서비스용 리드 퍼널보다는 표면적인 데모에 가깝다. [20:13]
  • Flash의 에이전트 작업 능력도 별도 검증이 필요하지만, 현재 비교 범위는 프롬프트를 받아 웹 애플리케이션을 직접 생성하는 능력에 한정된다. [20:30]

7. Anti-Gravity 할당량 중단과 Google 계정 체계의 분리

  • Anti-Gravity에서 개인 할당량을 모두 사용했다는 오류가 발생하고 다음 사용 가능 시점이 약 149시간 뒤로 표시돼, 사용량이 거의 없었다는 인식과 실제 제한 사이에 큰 차이가 생긴다. [25:22]
  • Google AI 구독과 Workspace 계정이 Anti-Gravity 사용량에 통합되지 않아, 유료 계정을 보유해도 별도의 스타터 할당량이 적용되는 구조가 테스트를 중단시킨다. [27:14]

8. 저렴한 비용과 Terra 비교 기준

  • 현재 모델은 비용이 저렴하다는 장점이 크며, 3.6과 3.7의 세부 차이보다 유사한 작업 환경을 가진 Terra와의 직접 비교가 더 중요하다. [30:17]
  • 기존 실행은 추가 결과 없이 종료돼, 같은 조건에서 비교할 수 있는 후속 작업이 필요해졌다. [31:02]

9. Gemini 한도 확대를 막는 결제 마찰

  • 중단된 Gemini 작업을 마무리하려면 사용량 한도를 늘려야 하지만, 적절한 결제·업그레이드 경로를 바로 찾기 어렵다. [32:43]
  • Google AI 계정, Antigravity 사이트, 폐지된 Ultra 요금제 정보가 서로 얽혀 있어 탐색 비용이 커졌고, 추가 확인을 포기할 정도로 마찰이 심하다. [34:34]

10. Grok 주택 렌더링의 실패

  • Grok의 주택 렌더링은 태양 위치를 선으로 표시하는 등 요구한 결과와 어긋났고, 초기 출력 품질은 Gemini가 더 인상적이었다. [35:37]
  • 실제 주소를 추가해 다시 시도했지만 핵심 오류가 남아 있어, 단순 입력 보완만으로는 결과를 개선하기 어려웠다. [36:27]

11. 프롬프트와 API 의존성의 충돌

  • 추가 미세 조정보다 프롬프트를 처음부터 다시 설계해야 할 정도로 결과가 기대에 못 미쳤고, 지리 정보 처리 방식이 주요 결함으로 남았다. [39:26]
  • Google Earth Engine API를 결합하면 정확도를 높일 가능성이 있지만, 외부 API 없이 모델 자체 역량을 비교하려는 벤치마크 목적과 충돌한다. [39:56]

12. 새 작업 환경과 게임 클론 생성

  • 실패한 벤치마크를 일단 실험으로 마무리하고, 별도의 Grok 작업 디렉터리와 세션을 추가로 실행했다. [41:17]
  • 다음 코딩 과제로 개인적인 향수가 있는 ‘소닉 더 헤지혹’ 클론을 선택해 Grok의 웹 제작 능력을 시험했다. [41:57]

13. 공개 콘텐츠를 활용한 브랜드 OS 생성

  • 생성된 사이트는 Clear Mud의 공개 웹사이트를 분석해 프롬프트에 직접 넣지 않은 ‘Muddy OS’와 방문자 세션 개념까지 구성했다. [45:07]
  • ‘Muddy OS’ 관련 정보는 프롬프트가 아니라 사이트에 게시된 블로그 글에서 수집된 것으로 보이며, 공개 콘텐츠 탐색이 결과물의 구조와 용어에 직접 반영됐다. [46:26]

14. 창 시스템의 동작과 탐색 한계

  • 블로그 글과 여러 메뉴는 실제 링크로 연결됐지만 대부분 새 탭을 열었고, 생성된 운영체제 안에서 콘텐츠를 탐색하는 일관된 경험은 부족했다. [46:44]
  • 외부 링크를 자체 내장 브라우저에서 열도록 만들면 창 기반 인터페이스의 몰입감과 사용 흐름을 유지할 수 있다. [47:00]

15. 브랜드 OS 프롬프트의 핵심 요구사항

  • 초기 결과는 활용할 만하지만 링크 처리와 세부 동작을 개선해야 하며, 이 형식은 앞으로 반복적으로 사용할 제작 패턴이 될 가능성이 크다. [48:04]
  • 프롬프트는 공개 콘텐츠·제품·고객 포지셔닝·시각 정체성을 분석한 뒤, 기존 브랜드를 브라우저 기반의 독창적인 운영체제로 재해석하도록 요구했다. [48:14]

16. Cursor Ultra와 Grokbot 사용 계획

  • Cursor Ultra 구독은 비용 절감, Cursor 실험, 높은 사용량이 포함된 Grokbot 접근 권한을 동시에 확보하기 위한 선택이었다. [49:25]
  • 생성된 브랜드 OS는 좋은 출발점이지만, 재사용 가능한 품질에 도달하려면 프롬프트에 링크 동작과 인터페이스 규칙을 더 추가해야 한다. [49:48]

17. 브랜드 정체성 재현과 오래된 정보

  • “AI 도구는 작동하지만 설명은 작동하지 않는다”는 브랜드 문제의식과 에이전트·누적 메모리·인간 승인 구조가 사이트 문구에 정확히 반영됐다. [50:09]
  • 브랜드의 핵심 문체는 잘 재현됐지만 일부 설명은 이미 오래된 상태여서, 원본 웹사이트 문구를 먼저 갱신해야 생성 결과도 최신 상태를 유지할 수 있다. [50:50]
  • Matt Van Horn의 저장소에서 ‘Agent Cookie’를 찾아 Grokbot 기반 에이전트 사례와 구현 자료를 확인했다. [52:26]
  • Grokbot VM에서는 X 계정 로그인이 차단돼 게시물 초안 작성과 승인 요청 같은 마케팅 자동화 실험을 진행할 수 없다. [53:22]

19. Grokbot VM에 한정된 로그인 차단

  • 약 12시간 동안 로그인을 반복했지만 Grokbot VM에서만 요청 횟수 초과 메시지가 발생했고, 다른 컴퓨터와 신규·시크릿 브라우저에서는 정상 로그인됐다. [53:46]
  • 동일 계정과 일반 브라우저에서는 재현되지 않아 계정 자체보다 Grokbot VM의 네트워크·브라우저 환경 또는 X의 세션 판별 방식이 원인일 가능성이 크다. [54:18]

20. 저가 모델 경쟁이 만드는 가격 압력

  • 중국의 저가 모델과 Grok의 빠른 개선은 OpenAI와 Claude의 가격 인하를 압박하며, 소비자가 더 낮은 비용으로 강한 모델을 선택할 가능성을 넓힌다. [56:25]
  • Gemini가 차지할 것으로 예상했던 세 번째 주요 모델 자리를 Grok이 낮은 가격을 바탕으로 대신 확보하는 흐름이 나타났다. [56:45]

21. Gemini 구독과 CLI 할당량의 분리

  • Gemini 3.7 Flash는 무료 계정의 주간 사용량 한도에 도달해 테스트가 중단됐으며, 월별 Google AI 유료 구독은 Antigravity CLI 할당량에 적용되지 않았다. [57:02]
  • Google 모델의 결제·사용량·대시보드가 하나의 계정 체계로 통합되지 않아, 유료 사용자도 별도 설정과 결제 경로를 다시 찾아야 한다. [57:32]

22. Grok의 가격 대비 사용량과 품질 격차

  • Grok은 테스트 오케스트레이션 같은 복합 업무에는 아직 부족하지만, 낮은 비용으로 빠르게 성능을 높이며 실무 도구로서의 경쟁력을 키우고 있다. [58:31]
  • 월 30달러 Super Grok 구독의 사용량은 월 200달러 Claude 구독에 견줄 만하지만, 결과 품질은 Fable이나 Soul보다 한 단계 낮다. [58:44]

23. 실행 속도 차이와 Google 생태계의 약화

  • Grok은 CLI에서 느리지만 Grok.com에서는 더 빠르며, Gemini Flash는 토큰 효율이 높아 실행 환경과 모델 유형에 따라 체감 성능이 달라진다. [59:23]
  • Gemini Pro의 존재감은 크게 약해졌고, Flash의 효율성만으로는 파편화된 제품 구조와 고객 경험 문제를 상쇄하기 어렵다. [59:41]

24. 불명확한 Google AI 구독과 해지 결정

  • Google 구독은 Flow 애니메이션을 가끔 만드는 용도에만 쓰이는데도 매달 20달러 이상이 들며, AI Ultra 개편 이후 상품 구성과 혜택을 이해하기 어려워졌다. [1:00:33]
  • Workspace 비즈니스 계정에는 ‘AI expanded access’라는 월 24달러 라이선스가 연결돼 있었고, 개인 계정용 AI Ultra·Pro와의 차이도 즉시 파악하기 어려웠다. [1:01:22]

25. Google 도구에 대한 신뢰 하락

  • 구독 해지로 매달 24달러를 절약하게 됐으며, 종료일 전에는 언제든 다시 구매할 수 있지만 당장은 재구독할 이유가 없었다. [1:02:57]
  • 초기 Google AI Studio와 Antigravity는 유용했지만, 제품과 정책의 초점이 지나치게 분산되면서 지속적으로 사용하기 어려운 상태가 됐다. [1:04:04]

26. Grokbot을 활용한 X 운영 자동화 구상

  • 단일 RTX 5090에서 Qwen 3.8 27B가 초당 약 206토큰으로 동작하는 환경을 Grokbot의 주요 로컬 모델로 활용할 계획이다. [1:04:19]
  • X의 알고리즘과 주제별 트렌드를 분석해 매일 아침 브리프를 만들고, 게시물 문구와 함께 올릴 가치 중심 자료까지 생성하는 흐름을 시험한다. [1:05:01]

27. Grok 4.6과 Cursor Ultra의 보완적 활용

  • Grok 4.6은 Codex 구독을 보완할 만한 성능을 보였고, Cursor Ultra의 추가 사용 크레딧을 활용해 Cursor 앱과 에이전트 기능도 폭넓게 시험할 수 있게 됐다. [1:06:02]
  • Cursor는 기존에 고객 작업용 IDE와 로컬 터미널 중심으로 사용했지만, Ultra 구독 이후에는 자체 에이전트와 원격 실행 관점까지 활용 범위가 넓어진다. [1:07:15]

28. Seedance 생성 영상의 품질과 잔존 한계

  • Seedance로 만든 제품 광고는 AI 특유의 느낌이 남아 있지만 전반적인 완성도는 높았고, 어깨와 머리를 돌리는 동작에서는 로봇 같은 움직임이 드러났다. [1:07:20]
  • 일부 움직임은 자연스러웠으며, 높은 완성도의 핵심은 5~8초 길이 장면을 각각 생성한 뒤 효과적으로 이어 붙이는 편집에 있었다. [1:07:42]

29. 장편 영상을 한 번에 생성하기 어려운 현실

  • 현재 품질은 개별 장면을 어떻게 생성하고 연결하느냐에 크게 좌우되며, 4분짜리 결과물도 단일 프롬프트보다 여러 장면을 조립했을 가능성이 크다. [1:08:58]
  • 하나의 이야기만 입력해 완성된 장편 영상을 자동 생성하는 단계에는 아직 도달하지 못한 것으로 보이지만, 직접 검증할 필요는 남아 있다. [1:09:04]

30. Sonic풍 플랫폼 게임의 공간 인식 문제

  • Sonic the Hedgehog에서 영감을 받은 게임 복제 결과는 캐릭터가 맵 중앙을 달리고 일부 자산 처리도 기대와 달라, 프롬프트 요구사항을 충분히 반영하지 못했다. [1:10:28]
  • 캐릭터가 지형 중간에 끼어 진행하지 못한 장면은 게임 세계의 위치와 충돌 관계를 이해하는 공간 인식 문제일 가능성이 있다. [1:11:05]

31. AI 기반 무인 유튜브 채널의 운영 구조

  • Hermes 에이전트가 기획부터 제작까지 처리하고, 사람은 영상 품질과 문구의 정확성을 확인한 뒤 게시만 승인하는 무인 채널 구조가 목표다. [1:13:26]
  • 도시의 모습을 과거부터 현재까지 지도 기반 애니메이션으로 변화시키고, 연도별 사건을 대본과 연결하면 교육성과 시각적 흥미를 함께 확보할 수 있다. [1:14:20]

32. 웹사이트 기반 24시간 상품 출시 벤치마크

  • ‘24시간 상품 출시’ 프롬프트는 기존 웹사이트를 분석해 새로운 상품이나 서비스를 스스로 구상하도록 설계됐다. [1:16:17]
  • 이미 운영 체계를 갖춘 사업자는 만들 제품을 미리 정하지 않아도 되며, 모델이 사업 맥락을 분석해 24시간 안에 판매 준비가 가능한 제안을 만들어야 한다. [1:16:27]

33. 교육적 가치를 우선하는 무인 콘텐츠

  • HeyGen과 ElevenLabs는 무인 영상 제작을 쉽게 만들지만, AI 인간을 만들어 실제 사람을 대체하기보다 교육용 인포그래픽 형식이 더 적합하다. [1:17:49]
  • 제작 과정에서 창작자도 새로운 내용을 배우고 시청자에게 정보·교육·흥미를 제공해야 하며, 가치 없는 자동 생성 콘텐츠를 늘리는 방향은 피해야 한다. [1:18:18]

34. 완전 자동화보다 인간의 개성을 더하는 방식

  • 에이전트가 영상과 대본을 준비하더라도 실제 목소리와 말투로 직접 읽으면, 얼굴을 공개하지 않으면서도 인간적인 개성을 유지할 수 있다. [1:18:59]
  • AI가 기획과 제작을 맡고 사람이 마지막 표현을 더하는 구조가 완전 자동 생성 영상보다 경쟁력이 높을 가능성이 크다. [1:19:11]

35. 음성 복제의 비용과 수익성

  • 채널이 수익을 내고 직접 녹음할 시간을 줄여야 하는 단계라면 음성 복제가 대안이지만, 사용량과 생성 단어 수에 따라 지속적인 비용이 발생한다. [1:20:18]
  • 채널이 월 수천 달러를 벌고 제작 서비스 비용이 월 수백 달러 수준이라면, 음성 합성과 자동화 도구를 포함해도 사업성이 유지된다. [1:20:56]

36. 로컬 음성 복제 도구와 기존 전사 서비스

  • 영상당 5분 기준으로 약 200분을 사용할 수 있는 요금 구성이 검토됐고, 무료 음성 복제 대안으로 Voicebox가 다시 후보에 올랐다. [1:21:52]
  • 이전 OpenClaw 부트캠프 때 접했던 Voicebox는 이제 로컬 하드웨어를 갖춘 만큼 직접 운용할 가능성이 커졌다. [1:22:10]

37. 방송을 유지하기 위한 영상 재생 전환

  • 잠시 자리를 비우는 동안 스트림을 종료하지 않기 위해 화면에 다른 영상을 재생하는 ‘무비 타임’으로 전환했다. [1:25:46]
  • Gemini Flash를 충분히 시험하지 못한 상황에서 최근 공개된 다른 Google 모델 관련 영상을 찾아 약 5~10분 동안 대신 재생하기로 했다. [1:26:06]

38. WorldClaw의 편집 가능한 3D 세계 생성

  • Tencent WorldClaw는 프롬프트로 전체 3D 세계를 만들면서 나무·집·수레·가로등 같은 구성 요소를 각각 편집 가능한 개별 자산으로 생성한다. [1:27:10]
  • 설원 마을과 사막 전투 장면에서는 환경뿐 아니라 깊이 맵·노멀 맵·인스턴스 맵과 분리된 객체 자산까지 함께 만들어진다. [1:27:32]

39. 검색·이미지 분할·3D 변환을 결합한 생성 파이프라인

  • 지형 계획 에이전트는 장면 명세에 외부 지식이 필요하면 웹 검색으로 참고 자료를 수집하고, GPT Image 2로 기본 지형 이미지를 생성한다. [1:28:22]
  • Meta의 SAM 3가 생성 이미지 속 요소를 각각 분할한 뒤, Tencent Hunyuan 기술이 2D 이미지를 3D 자산으로 변환해 세계를 구성한다. [1:28:48]

40. WorldClaw의 잠재력과 현재 접근 제한

  • 생성된 3D 세계는 게임 제작, 개인 애니메이션, 로봇 시뮬레이션처럼 서로 다른 분야에서 재사용 가능한 자산 기반 제작 방식을 제공한다. [1:29:35]
  • 로봇이 현실에서 마주칠 시나리오를 가상 환경에서 먼저 학습하는 기존 훈련 방식에 새로운 세계 생성 경로를 추가할 가능성이 있다. [1:29:45]

41. 비개발자를 겨냥한 Grokbot의 위치

  • Grokbot은 Cursor처럼 코딩에 집중한 도구보다 OpenClaw·Hermes·Claude Cowork에 가까우며, 코드를 보지 않고도 에이전트에게 업무를 맡기려는 사용자를 겨냥한다. [1:30:19]
  • 사용자는 목적이 다른 소형 에이전트를 만들 수 있고, 받은편지함 분류·비서·협상·프로토타이핑·조사·쇼핑·주거 탐색 같은 역할이 기본 예시로 제공된다. [1:30:42]

42. 역할 이름만으로 구성되는 다중 에이전트

  • Research Bot이라는 이름만으로 자료와 출처를 조사해 핵심 판단을 반환하는 역할이 설정되고, 최신 AI 뉴스를 평일 오전 8시 57분마다 전달하는 일정까지 만들어진다. [1:31:02]
  • Email Triage는 Gmail 접근 권한이 없음을 감지해 연결을 요청한 뒤 받은편지함을 불러오며, 메일 초안·홍보 메일 정리·아침 요약 같은 후속 작업을 지원한다. [1:32:08]

43. 플러그인 자동화와 실제 계정 연동의 제약

  • Gmail·Google Drive·Calendar·Notion·Slack 등을 연결할 수 있고, 새 Slack 메시지나 Git 이벤트가 발생하면 지정된 프롬프트를 자동 실행할 수 있다. [1:33:08]
  • 반복 업무를 시연하고 일정을 지정하면 에이전트가 백그라운드에서 실행되므로, 사용자는 내부 추론이나 코드를 직접 확인하지 않고 결과 중심으로 운영할 수 있다. [1:33:31]

44. Codex CLI 중심으로 바뀐 작업 방식

  • Codex CLI를 실제 작업에 활용하는 빈도가 늘었고, 기존에 예상했던 것보다 사용 경험도 긍정적으로 자리 잡았다. [100:30] [1:36:54]
  • Codex 앱보다 CLI를 더 자주 사용하며, 데스크톱 앱은 현재 주로 썸네일 제작처럼 시각 작업에 한정해 활용한다. [100:47] [1:36:59]

45. 에이전트 사용자를 위한 Field Kit 상품 구상

  • 자동 생성된 상품은 무료 부트캠프와 1,500달러 기업 감사 사이를 채우는 중간 가격대의 Field Kit이며, 이미 터미널과 에이전트를 사용하지만 운영 체계가 없는 개인을 대상으로 한다. [101:46] [1:39:01]
  • 기업 감사가 성숙한 조직의 기회 지도를 만드는 서비스라면, Field Kit은 도구를 설치한 뒤에도 안정적인 업무 시스템을 구축하지 못한 사용자의 다음 단계를 지원한다. [102:00] [1:39:06]

46. 정적인 진단 UX와 생성 결과의 한계

  • 초기 화면은 기본적인 선택형 질문으로 구성되고, 질문의 크기와 배치가 제목처럼 보여 실제 진단 흐름과 구분되지 않는다. [103:15] [1:39:16]
  • 여러 창을 열지 않고 에이전트 전체를 확인하는 기능, 반복 작업의 cron 이전, 장애 시 백업 같은 질문은 유용하지만, 스크린샷과 시각 자료를 활용한 상호작용형 온보딩이 부족하다. [104:21] [1:41:19]

47. 모델 선택과 Linux용 Codex 앱

  • 여러 제공자 사이를 자주 오가던 시기에는 Codex CLI를 깊게 사용하지 못했지만, 5.6 계열 모델에 대한 만족과 신뢰가 생기면서 CLI를 본격적으로 시험할 동기가 커졌다. [105:52] [1:41:39]
  • 업무용 노트북에서는 Codex 앱을 일부 사용하지만 Arch Linux 버전 부재가 제약이며, Linux 베타가 Debian·Red Hat·Fedora 중심으로 공개된 정황이 있다. [106:07] [1:43:36]

48. Hermes·OpenClaw의 보안 위험과 지속적인 효용

  • Hermes와 OpenClaw의 하위 에이전트가 사이버 공격에 이용돼 85개 계정과 25개 시스템이 침해됐다는 사례는 에이전트의 높은 실행 권한이 공격 규모를 확대할 위험을 보여준다. [107:09] [1:43:41]
  • 보안 사고와 “OpenClaw는 끝났다”는 반응에도 불구하고, 실제 업무에서는 여러 시스템 가운데 OpenClaw에 가장 크게 의존하며 활용 가치가 유지된다. [107:23] [1:44:47]

49. 콘텐츠 제작과 개인 일정의 충돌

  • 오랜만에 만나는 친구를 위해 당일 업무에서 벗어나지만, 그 결과 장편 영상 두 편의 녹화와 편집을 다음 날 이른 아침부터 처리해야 한다. [107:53] [1:45:53]
  • 첫 영상은 오전 5시에 녹화를 시작해 10시까지 게시하고, 두 번째 영상은 편집 후 일요일 공개로 예약하는 압축 일정이 잡힌다. [108:12] [1:46:38]

50. 과장된 유행 담론과 개인정보 접근 경계

  • 특정 도구가 “죽었다”는 주장은 감정과 관심을 끌기 위한 클릭베이트 성격이 강하며, OpenClaw는 사라진 것이 아니라 에이전트 활용 방식의 확산을 촉발했다. [109:25] [1:48:06]
  • OpenAI가 전체 대화 기록에 접근하는 새 기능은 편리함보다 개인정보 노출과 오작동 위험이 커 보여 당장은 사용하지 않을 계획이다. [109:55] [1:48:50]

51. 방송 종료와 다음 작업 계획

  • 이동 전 이른 점심을 먹어야 하는 일정 때문에 추가 실험을 중단하고, 현재 지점을 당일 라이브의 종료 시점으로 정한다. [110:44] [1:50:18]
  • 주말에는 휴식과 집중 작업을 병행하되 다음 날 Grokbot을 더 깊게 시험하며 콘텐츠 제작을 이어갈 계획이다. [111:42] [1:51:02]

🧾 결론

  • Gemini 3.7 Flash는 빠른 프로토타이핑과 초기 시각적 완성도에서 우위를 보였지만, 실제 주소 기반 분석이라는 핵심 요구를 충족하지 못했다.
  • Grok 4.6은 가격 대비 잠재력은 확인됐으나 복합 작업 오케스트레이션, 공간 인식, 실행 안정성에서는 상위 모델과의 품질 격차가 남아 있었다.
  • 이번 실험은 생성 속도만으로 모델을 평가할 수 없으며, 실제 데이터 연결·보안·상태 유지·오류 복구까지 포함해야 실서비스 적합성을 판단할 수 있음을 보여준다.
  • 모델 비교는 동일 프롬프트뿐 아니라 동일한 API 조건, 실행 환경, 시간·비용 한도, 성공 기준을 사전에 고정하는 방식으로 다시 설계필요가 있다.

📈 투자·시사 포인트

  • Grok과 중국계 저가 모델의 빠른 개선은 OpenAI와 Claude 계열에 가격 인하 또는 사용량 확대 압력을 가할 수 있다.
  • 저렴한 추론 비용만큼 중요한 경쟁 요소는 CLI 안정성, 계정 통합, 명확한 결제 체계와 같은 제품 운영 경험이다.
  • Google은 Flash의 효율성에도 불구하고 구독·Workspace·CLI 할당량의 파편화가 지속되면 유료 사용자의 이탈 위험이 커질 수 있다.
  • AI 코딩 제품의 장기 경쟁력은 인상적인 데모보다 외부 데이터 정확성, 보안 기본값, 재현 가능한 실행과 인간 승인 구조에서 갈릴 가능성이 크다.

⚠️ 불확실하거나 확인이 필요한 부분

  • Gemini의 태양광 발전량 계산 정확성과 주소별 건물 데이터 연동은 검증되지 않았으며, Google Places 또는 Earth 계열 API를 명시했을 때 결과가 얼마나 개선되는지도 확인되지 않았다.
  • Grok 결과물은 정상적으로 로드되지 않아 Gemini와 동일한 기준으로 품질과 제작 시간을 비교할 수 없었다.
  • Anti-Gravity의 약 149시간 제한이 계정 구성, 제품 정책, 일시적 오류 중 무엇에서 비롯됐는지 명확하지 않다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • 동일한 주소·프롬프트·API 허용 범위·시간 제한·비용 한도를 고정해 Grok 4.6과 Gemini 3.7 Flash를 다시 실행한다.
  • 실제 주소 데이터 반영 여부, 발전량 계산, 패널 배치, 상태 유지, 오류 복구를 각각 독립된 합격 기준으로 측정한다.
  • 생성된 애플리케이션에서 API 키의 클라이언트 노출 여부를 확인하고, 노출된 키는 폐기·재발급한다.
  • 외부 API를 금지한 순수 모델 벤치마크와 필요한 API를 허용한 실서비스 벤치마크를 별도 트랙으로 운영한다.

❓ 열린 질문

  • 동일한 프롬프트에서 Gemini의 빠른 결과와 얕은 구현은 Flash 모델 자체의 특성인가, Anti-Gravity 하네스의 실행 전략에서 비롯된 차이인가?
  • 주소와 지리 데이터 연동 조건을 더 명시하면 두 모델이 실제 주택별 태양광 잠재력을 정확하게 구현할 수 있는가?
  • 외부 API 없는 공정성과 실사용 가능한 정확성을 동시에 평가하려면 벤치마크를 어떤 단계로 분리해야 하는가?

관련 문서

공통 태그와 주제 흐름을 기준으로 같이 보면 좋은 문서를 이어서 제안합니다.