YouTubeClearmud·2026년 10월 29일·0

Another Google Model?! Let''s test Argon and talk Carbon.

Quick Summary

Google의 Argon은 웹사이트·조립 앱 제작에서 가능성을 보였지만 과제와 추론 노력 수준에 따라 결과가 달랐으며, 직접 시험하지 못한 Carbon의 실사용 우위는 판단을 유보해야 한다.

영상 보기

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

원본 열기

🖼️ 인포그래픽

Another Google Model?! Let''s test Argon and talk Carbon. 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

Another Google Model?! Let''s test Argon and talk Carbon.의 핵심 내용을 4단계로 요약한 인포그래픽
Another Google Model?! Let''s test Argon and talk Carbon. 핵심 내용을 4단계로 압축한 4컷 인포그래픽

💡 한 줄 결론

Google의 Argon은 웹사이트·조립 앱 제작에서 가능성을 보였지만 과제와 추론 노력 수준에 따라 결과가 달랐으며, 직접 시험하지 못한 Carbon의 실사용 우위는 판단을 유보해야 한다.

📌 핵심 요점

  1. Carbon은 발표됐지만 일반 사용자 접근이 제한돼 이번 실험은 Argon으로 진행했다. Carbon의 보안·정렬 개선은 공개 설명에 담긴 주장이며, 이번 방송에서 검증된 결과는 아니다.
  2. 운영체제형 웹사이트에서는 high만 창을 끌고 위치에 맞춰 붙이는 기능을 구현했다. 다만 콘텐츠가 새 탭으로 열려 내부 실행이라는 목표를 충족하지 못했고, 진행자도 해당 요구를 프롬프트에 명시하지 않았다는 한계를 인정했다.
  3. IKEA 조립 앱은 low에서도 부품 선택과 X-ray 기능을 구현했지만 medium은 개별 부품 조작이 부족했다. high가 가장 좋은 평가를 받았어도 부품·단계 누락이 의심됐으며, 소닉 게임 실험에서는 시점과 화면 표시의 안정성 문제가 남았다.
  4. Clearbench는 기억·스킬·플러그인 등을 제외한 독립 환경에서 같은 요청을 실행하고 시간과 토큰을 측정한다. 실제 실행은 구독을 사용하며 표시 비용은 공개 API 가격으로 환산한다. 월 20달러 요금제에서는 총 아홉 번의 테스트 뒤 한도에 도달했다.
  5. 이번 결과는 빌드 결과에 대한 평가다. 여러 모델의 보안 감사 비교와 에이전트 하네스 벤치마크는 별도 구상이며, 기억 없는 초기화 환경과 실제 사용 환경 중 무엇을 기준으로 삼을지도 확정하지 않았다.

🧩 배경과 문제 정의

  • Gemini 4 Carbon이 발표됐지만 일반 사용자의 접근은 아직 제한돼 있다. 공개된 벤치마크와 보안 개선 주장이 실제 작업 성능으로 이어지는지는 직접 검증해야 한다.
  • Argon의 실사용 능력을 확인하기 위해 운영체제 형태의 회사 웹사이트와 IKEA 조립 안내 도구를 제작한다. 기존에 Opus가 잘 수행했던 과제가 비교 기준이다.
  • 모델의 가치는 화면 구현뿐 아니라 보안 감사, 다른 모델의 작업 검토, 정해진 워크플로를 수행하는 에이전트 역할까지 포함해 평가할 필요가 있다.
  • 현재 벤치마크는 구독으로 실행하며 API 비용은 공개 문서를 바탕으로 환산한다. 에이전트 환경에서 모델과 추론 노력 수준을 비교하는 별도 평가 방식도 구상 중이다.

🕒 시간순 섹션별 상세정리

1. Carbon 발표와 단계적 접근 제한

  • Gemini 4 Carbon이 새로 발표됐지만 일반 사용자는 아직 접근할 수 없어, 이번 실험은 Argon으로 진행한다 [00:23]
  • 발표 뒤 접근 권한을 천천히 확대하는 Google의 방식은 사용자가 모델을 즉시 검증하기 어렵게 만든다는 불만으로 계속된다 [00:37]

2. ClearMud 웹사이트를 클라우드 운영체제로 구현하는 과제

  • 새 웹사이트는 clearmud.ai를 기준 자료로 삼아 회사의 브랜드, 색상, 서체와 포지셔닝을 반영해야 한다 [02:33]
  • 핵심 요구는 웹사이트 안에서 클라우드의 Mac OS X를 조작하는 듯한 경험이다. 운영체제처럼 보이고 작동해야 하며, 참고 사례로 PostHog를 지정한다 [03:11]

3. Carbon의 보안 개선 주장과 실사용 검증의 필요성

  • Carbon의 공개 설명은 높은 압박이 걸리는 작업에서 정렬, 투명성, 작업 완수를 강화했다고 주장한다. 사이버 방어, 불명확한 상황에서의 협업, 권한을 넘지 않는 후속 작업과 프롬프트 주입 저항성도 개선 항목에 포함된다 [05:09]
  • Google 모델이 벤치마크에서는 좋아 보여도 실제 작업에서는 기대에 못 미쳤다는 경험 때문에 Carbon의 우위는 판단을 유보한다. Argon 역시 이날 처음 본격적으로 시험하는 단계여서 충분한 평가가 쌓이지 않았다 [06:11]

4. HQ 전용 서버 이전과 테스트 계정 인증

  • HQ를 OpenClaw 서버에서 분리해 자체 서버와 자원을 배정할 계획이다. 환경을 제대로 맞추는 데 몇 시간, 경우에 따라 하루가 걸릴 수 있다고 예상한다 [09:53]
  • 임시 Gmail 계정으로 만든 테스트 계정은 추가 정보 확인을 요구한다. QR 인증과 본인 확인을 거친 뒤 접근이 정상적으로 열린다 [10:49]

5. 동일 저장소를 이용한 모델별 보안 감사 비교

  • 출시를 준비 중인 다른 산업용 무료 도구의 저장소를 별도 프로젝트들에 받아, 같은 코드를 대상으로 보안 감사를 실행하는 방안을 구상한다 [11:25]
  • Astra, Fable, Argon의 감사 결과를 비교하면 모델마다 무엇을 발견하고 어떤 차이를 보이는지 살펴볼 수 있다. 아직 실행 결과가 나온 실험은 아니다 [11:39]

6. IKEA 설명서를 단계별 시각 학습으로 바꾸는 과제

  • 두 벤치마크를 나란히 실행해 대기 시간을 줄이고, Opus가 잘 수행했던 IKEA 제품 조립 도구를 Argon에도 맡긴다 [13:08]
  • 페이지를 넘기며 읽는 조립 설명서를 단계별 시각 학습으로 바꿔, 사용자가 조립 과정을 직접 보고 이해하도록 만드는 것이 목표다 [13:26]

7. AI 정보 채널의 신뢰성과 콘텐츠 반복성

  • Theo Brown, Ray Fernando, Rasmike, Riley Brown, Bejon을 신뢰하는 주요 채널로 꼽는다. 잘못된 주장에 책임지는 태도와 직접 시험하는 접근을 높게 평가한다 [14:47]
  • Riley Brown의 일부 썸네일은 클릭을 유도한다고 볼 여지가 있지만, 영상 본문에는 여전히 실질적인 내용이 있다는 평가다 [15:12]

8. 구독으로 실행하고 API 비용으로 환산하는 벤치마크

  • 벤치마크 요청은 보유한 구독을 통해 처리한다. 화면에 제시하는 API 비용은 공개 문서의 가격을 기준으로 계산한 값이다 [15:43]

9. 채널 성장 방식과 대상 시청자의 차이

  • Ray Fernando는 엔지니어링 배경을 바탕으로 접근하며, Rasmike와 비교하면 성장 속도가 완만하다는 관찰이다. 특정 유형의 콘텐츠를 만들지 않으면 채널이 더 빠르게 성장하기 어렵다는 판단도 따른다 [16:54]
  • Greg Eisenberg의 영상을 예전처럼 매번 찾아보지는 않지만, 아이디어와 내용을 포장하는 방식에서는 여전히 참고할 점을 얻는다 [17:35]

10. Kimmy K3.1 구독 경험에서 나온 에이전트 평가 아이디어

  • Kimmy K3.1 시험용 구독에서는 아직 사용량 제한을 체감하지 못했다. 다만 OpenClaw 같은 환경에서의 활용은 충분히 시험하지 않은 상태다 [19:31]
  • 각 에이전트 실행 환경에 데모용 에이전트를 두고, 같은 요청을 여러 모델과 추론 노력 수준으로 처리하게 하는 평가 방식을 구상한다 [20:20]

11. 시청자 참여가 도구 발견과 채널 방향에 미치는 영향

  • Hermes Agent를 비롯한 여러 도구를 시청자 채팅에서 먼저 알게 된 경험이 있다. 커뮤니티의 질문과 정보 공유가 새로운 도구를 발견하는 통로로 작용한다 [22:08]
  • 급격한 구독자 증가보다 현재 속도로 커뮤니티를 형성하는 쪽을 선호한다. 환경에 적응하더라도 채널의 접근 방식과 목적은 유지하려는 입장이다 [22:49]

12. Terra 6.1의 강점은 시각 구현보다 정해진 에이전트 작업에 있다는 평가

  • Terra 6.1은 에이전트 관점에서는 견고하다는 초기 평가를 받지만, 앞서 진행한 일반적인 시각·3D 과제에서는 좋은 결과를 내지 못했다. 추론 노력 수준별 추가 시험을 계획한다 [23:54]
  • 다른 모델과 같은 제작 과제를 수행한 결과에는 아쉬움이 있었으나, 속도·효율·가격은 강점으로 평가한다. 잘 정의된 워크플로나 스킬 파일에 따라 반복 작업을 수행하는 에이전트에 적합할 수 있다는 판단이다 [24:45]

13. 서로 다른 제공자의 모델이 작업을 교차 검토하는 방식

  • 시청자는 여러 제공자의 상위 모델이 서로의 작업을 검토하는 에이전트 팀에서 더 나은 결과를 얻고 있다고 공유한다. 예시로 Kimmy K3.1이 Opus의 프런트엔드·백엔드 작업을 검토하는 구성을 제시한다 [25:20]
  • 이 아이디어를 받아 출시 전 보안 감사 비교에 Kimmy도 추가하는 방안을 고려한다. Fable, Astra, Argon과 함께 각 모델의 감사 접근을 관찰하려는 계획이다 [25:46]

14. 에이전트 실행 환경을 비교하는 새 벤치마크 설계

  • Opus 5.5의 extra high 설정에 즉시 구현 대신 계획 검토를 요청한다. 하나의 에이전트 요청을 서로 다른 모델로 처리하는 평가가 목표이며, 기본 선호는 medium이지만 모든 노력 수준을 시험하는 방안도 열어 둔다 [26:50]
  • HQ를 전용 VM으로 옮기는 작업과 연결해, 먼저 HQ 에이전트 계층을 만들고 Clearbench를 연결할지 검토한다. 새 서버에 테스트용 OpenClaw나 Hermes Agent를 따로 배치하는 대안도 있다 [27:22]

15. Argon 웹사이트 결과의 외형과 운영체제 기능 사이의 차이

  • Low 결과는 약 15분 뒤 완료됐고 API 환산 비용은 79센트로 표시된다. 다만 표시된 사용량과 비용이 정확한지 의문을 제기한다 [27:40]
  • 결과물은 부트캠프 등 기존 사이트의 내용을 가져오고 전체 구조도 갖췄지만, 콘텐츠가 운영체제 내부에서 열리지 않고 창을 좌우로 배치하는 기능도 없다. 기대했던 운영체제 기능은 부족하다는 평가다 [29:23]

16. 최대 노력 수준의 응답 지연과 비교 기준

  • 연구에는 Fable 5.1의 심층 연구와 Opus 55의 extra high 설정을 사용한다고 한다. 6.1 terra의 max 속도는 아직 시험하지 않았으며, 기존 테스트에서는 max가 대체로 가장 오래 걸렸다. [31:02]
  • Luna의 max 설정은 체감상 매우 느렸고, 이를 추론 노력 수준이 실제로 작동한 결과로 추정한다. [31:19]

17. low 설정에서도 구현된 세밀한 조립 상호작용

  • 조립 안내는 부품 목록과 12단계 학습 기능을 제공하며, 부품을 직접 눌러 열 수 있다. 다만 화면이 계속 확대되는 방식은 수정이 필요하다. [32:51]
  • low 설정에서 내부 구조를 보여주는 X-ray 기능까지 구현된 점을 높게 평가한다. [33:03]

18. HQ에 기억을 갖춘 에이전트 계층을 추가하려는 계획

  • HQ를 별도 VM으로 옮긴 뒤, 음성이 현재 시점의 요청에만 반응하는 수준을 넘어 기억과 추가 기능을 사용하도록 만들 계획이다. [34:07]
  • 새 계층의 목적은 HQ 안에서 같은 설명을 반복하지 않아도 작업이 이어지게 하는 것이다. OpenClaw 등을 대체하려는 구상은 아니다. [34:23]

19. medium의 상호작용 저하와 max의 대기 비용

  • medium에서는 개별 부품을 선택해 여는 기능이 없고 전체가 열리고 닫히기만 한다. 표면적인 시각화와 조작 방식은 low가 더 낫다고 평가한다. [35:16]
  • medium의 하단 내비게이션과 그래픽 인터페이스도 불편해, 노력 수준을 높인 결과가 오히려 낮은 평가를 받는다. [35:57]

20. Clearbench의 격리 조건과 측정 방식

  • 각 실행은 하나의 프롬프트로 새로 시작하며, 기억·저장된 세션·스킬·플러그인·MCP 서버·훅·지침용 Markdown 파일을 제외한다. 파일 읽기와 쓰기, 인터넷이 가능한 셸, 웹 검색과 웹 가져오기는 동일하게 제공한다. [38:37]
  • 모든 노력 수준을 동시에 시작하고 서로 참조할 수 없는 개별 폴더를 제공한다. 첫 파일 작성 시점을 표시하며, 에이전트의 마지막 응답까지 걸린 시간과 토큰 사용량을 측정한다. [39:03]

21. high 웹사이트의 개선된 조작과 내부 실행의 한계

  • high 결과는 아이콘·여백·애니메이션이 좋은 평가를 받으며, 비교한 설정 중 유일하게 창을 끌고 위치에 맞춰 붙이는 기능을 구현한다. [40:10]
  • 리소스 안내를 여는 과정에서 원본 사이트의 로딩 이상이 의심된다. 에이전트의 사이트 접근과 관련이 있는지는 확정하지 않고 로그 확인이 필요하다고 판단한다. [40:55]

22. 웹앱 밖으로 나가지 않도록 벤치마크 요구 수정

  • 게시물도 새 탭으로 열리는 동작은 웹앱을 실제 운영체제처럼 사용하려는 목표와 맞지 않는다. 프롬프트가 충분히 명확하지 않았을 가능성을 제기한다. [41:40]
  • 사용자가 다른 탭이나 창을 열도록 강요받아서는 안 된다는 조건을 프롬프트에 추가한다. [42:06]

23. 독립 작업공간인 HQ의 VM 분리

  • GPT 음성은 HQ에 연결돼 있지만, HQ는 특정 하네스에 의존하지 않는 독립 작업공간이다. 여기에 자체 하네스를 구축하려 한다. [43:19]
  • 현재 HQ와 OpenClaw는 같은 서버에서 서로 다른 Linux 사용자로 실행된다. 문제가 생겼을 때 영향 범위를 줄이기 위해 HQ를 별도 VM으로 옮길 예정이며, 이전은 아직 시작하지 않았다. [43:37]

24. 코드 정리에서는 수정 전에 목록과 제안을 확보

  • 에이전트에 파일시스템의 오래되거나 사용하지 않는 코드·테스트·코드베이스를 조사하게 하되, 즉시 수정하지 말고 목록과 정리 제안을 먼저 제출하도록 요청하는 방법을 권한다. [45:27]
  • 직접 사용하는 개발 환경에서 빌드와 테스트를 진행한 뒤 저장소를 만들고 변경을 병합한다. 에이전트에 책임이나 코드베이스를 맡길 때는 해당 저장소를 가져오게 하는 방식을 사용한다. [46:28]

25. 미리보기 장애도 원인 진단을 우선

  • 최근 두 번의 실행에서 앱 미리보기 썸네일이 작동하지 않았다. 문제의 크기를 단정하지 않고, 곧바로 수정하기보다 원인과 필요한 조치를 먼저 확인하도록 요청한다. [47:54]

26. 하네스 비교에서 초기화와 현실성 사이의 긴장

  • Opus는 HQ 에이전트 계층을 먼저 만들기보다 새 VM에 OpenClaw와 Hermes를 벤치마크용으로 설치하자고 제안한다. 각 세션은 빈 홈 디렉터리와 기억·스킬·MCP가 없는 일회용 복사본으로 시작하는 구상이다. [48:56]
  • Clearbench의 도구 어댑터·bubblewrap 기반 Linux 샌드박스·세션 실행기가 HQ 에이전트 계층의 기반이 될 수 있다는 제안도 나온다. 운영 조건으로는 구독 사용, 도구용 API 키 배제, 샌드박스 내부의 폭넓은 권한을 선호한다. [49:29]

27. Google의 접근 권한 혼선과 경쟁력에 대한 잠정 평가

  • 업무용 Workspace 관리 화면의 AI expanded access를 통해서는 Argon 접근 권한을 얻지 못해 별도 Gmail 계정을 사용했다. 구독과 권한 설정 과정이 혼란스럽고 불편했다는 경험이다. [51:26]
  • Gemini의 모바일 경험은 좋으며 Google이 Pixel과 모바일 최적화에 집중해 왔다고 추정한다. 다만 Anthropic과 GPT에 견주면 뒤처져 왔다는 평가를 제시한다. [53:10]

28. high 조립 앱의 우세와 남아 있는 누락

  • high 결과에서도 연결 부품이 보이지 않거나 일부 단계가 빠진 듯한 문제가 의심된다. 세부 표현은 인상적이지만 조립 과정의 완전성은 확신하지 못한다. [54:58]
  • 계속 확대되는 화면은 불편하지만, UI는 가장 깔끔하고 현재까지 가장 선호하는 결과라고 평가한다. [55:36]

29. 벤치마크 자원 정리와 ADHD 대응 스킬의 응답 규칙

  • 완료한 벤치마크를 보관 처리해 디스크 공간과 실행에 예약된 자원을 확보하고, 결과가 계속 쌓이지 않도록 관리한다. [57:02]
  • 공유된 ADHD 대응 스킬은 다음 행동을 먼저 제시하고, 여러 단계의 작업에는 번호를 붙이며, 마지막에 구체적인 다음 행동 하나를 두도록 한다. 곁가지를 줄이고 매 응답에서 현재 상태를 다시 명시하는 규칙도 포함한다. [57:43]

30. Argon의 잠정 평가와 소닉 게임 생성 실험

  • Argon은 한 테스트에서 예상보다 좋은 결과를 냈지만, 테스트가 끝나지 않아 최종 평가는 유보한다. [59:12]
  • 이번 실험의 범위는 에이전트 하네스 성능이 아니라 빌드 결과다. 다음 과제로 소닉 더 헤지혹 게임을 선택하고 간단한 프롬프트로 벤치마크를 실행한다. [59:22]

31. Puddle은 GitHub를 기준으로 여러 환경의 스킬을 통합한다

  • 개인용 도구 Puddle은 여러 에이전트 실행 환경과 기기에서 같은 스킬을 사용할 수 있도록 스킬을 모은다. 변경 사항을 Git에 커밋하고 GitHub를 기준 저장소로 삼는다. [1:00:14]
  • 오래된 스킬을 정리하면서 새로 만든 스킬도 모든 환경에 공유하는 것이 목표다. 현재 주로 쓰는 컴퓨터의 스킬이 들어 있으며, OpenClaw 서버의 스킬은 추가로 가져와야 한다. [1:00:42]

32. 스킬 URL을 직접 가져오는 기능이 필요하다

  • Puddle의 내장 어시스턴트는 기존 스킬의 분석·병합·비교·편집에 맞춰져 있어 외부 스킬을 가져올 도구 권한이 없다. 이 권한 범위 자체는 유지해도 괜찮다. [1:03:05]
  • 대신 ‘새 스킬’ 버튼에서 이름과 설명을 입력하는 방식 외에 SKILL.md 링크를 붙여 넣는 선택지를 추가한다. 링크의 내용을 가져와 Puddle에 등록할 수 있으면 매번 별도 프롬프트로 요청할 필요가 줄어든다. [1:03:26]

33. 새 노트북 기능보다 실제 화면 사용 비중과 세대 안정성이 중요하다

  • 새 주력 노트북이 배송된 날 다른 신제품이 발표됐지만, 사용 시간의 90%는 외부 모니터에 연결한다. 나머지 10%의 노트북 화면 작업에서도 차이를 크게 신경 쓰지 않을 것으로 본다. [1:07:42]
  • 새로운 하드웨어의 첫 세대에는 신중한 입장이다. M1은 좋은 예외였지만, 일반적으로는 첫 세대의 문제가 해결될 가능성이 있는 두 번째 세대를 기다리는 쪽을 선호한다. [1:08:14]

34. Argon의 low와 medium은 구현 성과와 기능 보존에서 차이를 보인다

  • low 결과는 전반적으로 준수하며 기존 ‘클래식’ 요소도 유지했다. 다만 화면에서는 물속으로 들어가는 듯한 동작과 이상한 버그도 나타났다. [1:10:14]
  • 이번 low 결과는 다른 모델의 high보다 나은 편이라는 인상을 준다. 짧은 테스트만 보면 Argon은 3D 구현에 강점이 있어 보이지만, 실패 사례도 있어 판단 범위는 제한적이다. [1:10:27]

35. 이동이 잦은 작업 환경에서는 MacBook의 배터리가 선택 기준이 된다

  • 주력 기기로 MacBook을 사용하는 핵심 이유는 잦은 이동이다. 한곳에서 집중할 때는 외부 장비에 연결하지만, 여행 중에는 배터리 지속 시간이 큰 장점으로 작용한다. [1:13:25]

36. 듀엣은 메인 채팅에서 요청을 분류하고 긴 작업을 스레드로 넘긴다

  • 듀엣은 지난 24시간 동안 사용하기 시작한 단계다. 사용법은 쉽지만 원하는 활용 방식에서 일부 제약을 발견했으며, 아직 종합적인 판단을 내릴 만큼 테스트하지는 않았다. [1:15:00]
  • 메인 채팅은 메시지마다 필요한 최소 대응을 고른다. 간단한 질문은 즉시 답하고, 감사나 참고 전달에는 짧은 반응을 남기며, 실제 작업이 필요한 요청은 스레드로 전환한다. [1:16:01]

37. 듀엣의 메모리는 세 층으로 나뉘며 사용자 발언이 규칙의 근거가 된다

  • 메모리는 현재 대화, 채널 노트, 클로드 메모리의 세 층으로 구성된다. 아래층으로 갈수록 더 오래 유지되고 더 넓은 범위에 적용된다. [1:17:57]
  • 규칙을 정하거나 목표를 확정할 수 있는 근거는 사용자 자신의 말이다. 이메일이나 웹페이지에서 읽은 내용이 사용자에 관한 규칙을 바꿀 수 없으며, 잊어 달라고 요청하면 해당 항목을 삭제한다. [1:18:05]

38. 읽기·초안 작성과 외부 실행에는 서로 다른 권한 경계가 적용된다

  • 이메일·캘린더·파일 읽기, 웹 검색, 답장과 문서 초안 작성, 조사와 선택지 비교, 작업 페이지 갱신은 별도 승인을 기다리지 않는 작업에 포함된다. [1:18:37]
  • 전송, 결제, 삭제, 취소, 로그인 사용은 사용자의 승인을 기다려야 한다. [1:18:44]

39. 서버형 서비스와 자체 호스팅 에이전트는 실행 위치와 작업 분리 방식이 다르다

  • 듀엣과 ChatGPT Work는 메인 채팅과 여러 작업 스레드가 서비스 제공자의 서버에서 실행되는 구조다. OpenClaw 같은 자체 호스팅 방식은 여러 채널과 앱을 게이트웨이에 연결하고, 사용자 기기의 에이전트가 작업하며 운영자가 제약을 설정한다. [1:19:20]
  • Grockbot 비교 자료의 ‘봇마다 컴퓨터가 있다’는 표현에는 보정이 필요하다. 실제로는 여러 봇이 컴퓨터 하나를 공유하고 서로 다른 프로필 화면을 사용한다. [1:19:51]

40. 추가 벤치마크는 여러 요구를 묶은 웹앱 구현을 시험한다

  • 장편 영상에서 사용할 벤치마크를 미리 살펴보는 차원에서 마케팅 키트 과제를 하나 더 실행한다. [1:27:58]
  • 이번 과제는 단순한 랜딩 페이지보다 웹앱에 가깝고, 여러 요청이 하나에 묶여 있다. 처리 구간 안에서는 실행을 시작하며, 완성 결과에 대한 평가는 나오지 않는다. [1:28:15]

41. Puddle의 링크 가져오기가 작동하고 유사 스킬 비교로 계속된다

  • 추가한 링크 입력 기능으로 ADHD 스킬을 Puddle에 가져오는 데 성공한다. 가져온 스킬은 활성 상태로 시작하며 라이브러리에 추가할 수 있다. [1:28:51]
  • 가져온 내용을 읽기 화면에서 확인한 뒤, 그때까지의 변경 사항을 모두 커밋하고 푸시하도록 요청한다. [1:29:13]

42. 기존 스킬의 제약과 개인용 Squirrel 구상

  • Gstack은 시험해 볼 만했지만, 프롬프트가 스택에 의해 지나치게 좌우된다는 불편 때문에 사용을 보류한 상태다. [1:31:01]
  • ADHD 스킬을 복제해 Squirrel이라는 개인용 포크를 만들고, 원본과 나란히 비교하면서 자신에게 맞게 출력을 조정하려 한다. [1:32:36]

43. 게임 결과물의 시점 구현과 화면 소실 문제

  • 어깨 시점 전환과 마우스로 주변을 둘러보는 기능은 작동하지만, 세 가지 effort 수준 가운데 기존의 클래식 시점을 구현한 결과는 하나뿐이다. 원하는 시점을 얻으려면 프롬프트를 개선필요가 있다. [1:34:03]
  • 세 결과 중 상대적으로 가장 나은 결과에도 결함이 남아 있고, 뒤로 이동하는 키와 스페이스를 함께 누르는 조작 방식도 직관적이지 않다. [1:34:39]

44. 아홉 번의 테스트로 드러난 구독 사용 한도

  • 월 20달러 요금제에서 각 effort 수준을 세 번씩, 총 아홉 번 시험한 뒤 사용 한도에 도달한다. 추가 실행이 되지 않아 테스트를 이어갈 수 없다. [1:35:53]
  • Ultra로 올리기 위해 약 80달러를 추가 지출할 의향은 없으며, 영상용으로 네 차례 테스트를 진행하려 해도 한도에 걸렸을 것이라고 판단한다. [1:36:10]

45. 메모리 가격 하락 시점과 소매 시장의 불리함

  • 메모리 가격은 당분간 더 오른 뒤 내려갈 것으로 예상하지만, 1년 전 수준까지 돌아갈 가능성에는 회의적이다. 비슷한 수준에 접근하더라도 예전만큼 저렴해지지는 않을 수 있다는 전망이다. [1:36:41]
  • 수요가 계속 증가하고 신규 생산시설도 데이터센터의 대량 주문에 우선 대응할 것으로 본다. 이에 따라 데이터센터용 가격이 먼저 안정되고, 소매 소비자는 가격 하락의 혜택을 늦게 받을 것으로 예상한다. [1:37:22]

46. 브라질 GPU 화물 실종과 CEO 영상에 대한 의심

  • 브라질 공항에서 약 50만 달러 상당의 GPU 화물 두 팔레트가 사라졌다는 기사 내용이 드러난다. [1:38:43]
  • 사라진 GPU가 웃돈을 붙여 재판매되고 있을 것이라고 추측하지만, 실제 유통 경로나 판매를 확인한 근거는 제시되지 않는다. [1:39:26]

47. 말레이시아 AI 칩 압수와 추가 실험 중단

  • 말레이시아 세관이 서버 30대 안에 숨겨진 1,200만 달러 상당의 첨단 AI 칩을 압수했다는 기사 내용이 나온다. 세관은 밀수 의심 조직이 말레이시아를 경유지로 이용한 것으로 보고 있다. [101:30] [1:40:27]
  • 구독 한도를 이미 소진했기 때문에 Argon으로 더 진행할 수 있는 테스트가 없다는 제약이 다시 확인된다. [102:32] [1:41:33]

48. 전력을 공급하지 못한 채 쌓이는 아마존의 AI 칩

  • 아마존이 아직 전력을 공급해 가동하지 못하는 수십억 달러 규모의 AI 칩을 창고에 보관하고 있다는 기사 내용이 드러난다. [103:09] [1:42:38]
  • 대규모 칩을 미리 확보하고 보관하는 선택은 아마존의 자본력으로 감당할 수 있는 전략이라는 평가다. [103:42] [1:43:44]

49. 테스트 종료와 커뮤니티·다음 방송 운영

  • Gemini 모델을 더 시험할 수 없어 방송을 마무리한다. Discord는 소수의 채널로 단순화했으며, 이러한 정리가 참여자들의 대화와 교류를 늘리는 데 도움이 되기를 기대한다. [105:40] [1:44:49]
  • 다음 방송은 금요일 정오를 목표로 하지만, 오전 일정이 바빠 기존보다 늦게 시작하는 흐름이 이어질 수 있다. 방송 일정은 대체로 한 시간 전에 등록할 계획이다. [106:45] [1:45:55]

🧾 결론

  • Argon은 일부 제작 과제에서 기대 이상의 결과를 보였지만, 제한된 테스트만으로 전반적인 모델 우위를 확정하기는 어렵다.
  • 추론 노력 수준을 높인다고 모든 기능과 사용성이 함께 좋아지지는 않았다. 외형뿐 아니라 요구 기능의 보존과 작업 완결성을 확인해야 한다.
  • 프롬프트의 명확성, 실행 환경, 구독 한도가 비교 결과에 영향을 준다. 모델 성능과 평가 설계의 한계를 함께 읽어야 한다.

📈 투자·시사 포인트

  • 모델 도입 판단에서는 발표 수치와 함께 실제 업무의 기능 충족률·대기 시간·반복 실행 가능성을 살펴볼 필요가 있다. 이번 사례에서는 구독 한도가 추가 검증 자체를 막았다.
  • API 환산 비용은 구독 사용자의 실제 지출과 구분해야 한다. 화면에 표시된 저렴한 비용만으로 운영 경제성을 판단하기 어렵다.
  • 시각적 제작 능력과 정해진 워크플로를 수행하는 에이전트 능력은 별도로 평가할 필요가 있다. 진행자는 Terra의 경우 후자에서 가능성을 봤지만 추가 시험이 필요한 초기 판단이다.
  • Google의 접근 권한과 계정 설정에 대한 불편은 시험·도입 과정의 마찰로 드러났다. 이 사례만으로 기업 실적이나 투자 매력도를 판단할 근거는 부족하다.

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

  • Carbon은 직접 시험하지 않았다. 보안·프롬프트 주입 저항성 개선이 실제 작업에서 어느 정도 효과를 내는지 확인되지 않았다.
  • Argon의 결과는 제한된 과제와 실행에서 나온 잠정 관찰이다. 같은 조건의 반복 시험 없이 노력 수준별 우열이나 3D 구현 강점을 일반화하기 어렵다.
  • 웹사이트의 내부 실행 요구가 처음부터 명시되지 않았고, 조립 앱의 부품·단계 누락도 확정적으로 검증되지 않았다. 프롬프트 문제와 모델의 구현 실패를 구분해야 한다.
  • 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
  • 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
  • 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

  • OS형 웹사이트 프롬프트에 콘텐츠의 내부 실행, 새 탭 이동 금지, 창 이동·배치 기능을 명시하고 같은 조건으로 다시 비교한다.
  • IKEA 원본 설명서와 결과물을 대조해 부품·연결 요소·조립 단계의 누락을 확인하고, 확대 동작과 개별 부품 조작을 점검한다.
  • 노력 수준별로 같은 과제를 반복 실행해 기능 충족 여부, 오류, 완료 시간, 토큰 사용량을 기록한다.
  • 실제 구독 지출·사용 한도와 API 환산 비용을 분리해 기록하고, 표시 비용의 산출 근거를 확인한다.

❓ 열린 질문

  • Carbon의 접근이 확대되면 공개된 보안 개선과 벤치마크 우위가 실제 제작·감사 작업에서도 재현될까?
  • Argon의 low가 medium보다 나았던 기능 차이는 반복 시험에서도 유지될까, 실행별 편차일까?
  • 기억과 도구를 제거한 비교의 공정성과 실제 사용 환경의 현실성을 어떤 기준으로 함께 확보할 수 있을까?

관련 문서

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