In times like this, just build.

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

In times like this, just build.를 중심으로, 시장 불안 속에서도 만들기를 이어간다. 시간과 주의력을 통제 가능한 작업에 쓰자는 태도이며, 실제 투자 손실이 주는 두려움까지 부를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 시장 불안 속에서도 만들기를 이어간다. 시간과 주의력을 통제 가능한 작업에 쓰자는 태도이며, 실제 투자 손실이 주는 두려움까지 부정하지는 않는다.
2. 서버 격리로 개발의 부담을 줄이려 한다. Clear Mud HQ를 별도 VM으로 옮겨 OpenClaw와의 자원 경합을 줄일 계획이며, T3 Code도 잘못된 작업의 영향 범위를 고려해 설치 위치를 검토한다.
3. Opus 55의 effort별 게임 제작에서는 화면 생성보다 실제 조작과 완성도가 중요했다. 낮은 effort 결과도 긍정적으로 평가했지만, 미디엄 빌드는 31분이 걸렸고 비교 대상보다 비용이 약 세 배였으며 조작·물리 문제도 남았다. 전체 effort의 우열이 확정된 것은 아니다.
4. 도구 개선은 구체적인 불편에서 출발한다. HQ로 흩어진 도구에 접근하고, Build Bench의 버튼 넘침과 Clearbench의 점수 선택 문제를 고치며, 좋은 테스트 결과를 Git 커밋과 저장소 생성으로 이어가려 한다.
5. 모델 평가와 구독 선택은 확인 가능한 조건에 맞춰 진행한다. Ultra 명칭은 계정 화면에서 확인했지만 한도 배수는 해석이 섞여 있다. Agent Bench는 작업 이력이 있는 환경에서 에이전트를 비교하는 별도 도구로 구상하며, Ollama 클라우드는 결제 전 연동 방식을 확인하려 한다.

🧩 배경과 문제 정의

• 시장의 불확실성과 부정적인 분위기 속에서도 자신이 통제할 수 있는 시간과 주의력을 실제 개발에 집중하자는 관점이 출발점이다.
• 여러 개발 도구와 OpenClaw가 서버 자원을 공유하면서 장애의 영향 범위와 자원 경합을 줄일 필요가 생겼다.
• AI 구독의 명칭과 사용 한도 변화가 관심사지만, 비공식 게시물에 대한 해석과 실제 계정 화면에서 확인한 내용을 구분해야 한다.
• 구체적인 구현 방법을 지정하지 않은 게임 제작 요청으로 Opus 55의 effort 수준별 결과를 비교하고, 생성 도중 드러나는 화면 배치와 조작 문제도 살펴본다.

🕒 시간순 섹션별 상세정리

1. 시장의 불확실성 속에서도 개발을 계속한다

• 외부 상황을 지나치게 걱정하기보다 고개를 숙이고 무언가를 만드는 데 집중하자는 것이 핵심이다. 불안한 시기를 창작과 개발을 이어 갈 시간으로 받아들인다 [00:26]

2. Claude 요금제 명칭과 실제 사용 한도를 구분한다

• 초반에는 Max 20x가 Ultra로, Max 5x가 Max로 바뀐다는 게시물을 공유하면서 실제 사용량은 Pro의 10배였다는 해석을 덧붙인다. 이 게시물의 공식성은 뒤에서 다시 제한한다 [01:01]
• Opus 55 출시 이후 5시간 사용 한도에 도달한 경우는 주로 여러 effort 수준을 나란히 실행하는 벤치마크 작업이었다. 다만 구독 두 개를 고객 작업용과 내부 작업·시연용으로 나눠 사용하므로, 하나의 구독만 사용하는 조건과는 차이가 있다 [01:44]

3. 서버와 VM을 분리해 장애의 영향 범위를 줄인다

• Clear Mud HQ는 현재 Clear Mode OS 및 OpenClaw 서버와 같은 환경에 있다. HQ와 Clear Bench의 기능을 확장하면서 OpenClaw용 자원을 소모하지 않도록 주말에 별도 VM으로 이전할 계획이다 [02:24]
• T3 Code를 여러 VM을 호스팅하는 루트 서버에 설치할지, 별도 VM에 설치할지는 아직 결정하지 않았다. 모델이 잘못된 작업을 수행할 때의 영향 범위를 줄인다는 점에서는 별도 VM 쪽으로 기운다 [03:03]

4. DFS 도구는 한 시즌 검증한 뒤 판매한다

• 개발 중인 DFS 도구는 서둘러 판매하지 않고 남은 시즌 동안 직접 사용하면서 수익 기록을 쌓을 계획이다. 판매 시점은 2026~2027 NFL 시즌을 앞둔 때로 생각하고 있다 [05:27]
• 현재까지는 수익이 플러스라고 드러낸다. 이번 주 개선으로 수익과 승률이 더 높아질 것으로 기대하지만, 이는 아직 검증된 결과가 아닌 전망이다 [06:04]

5. 비공식 게시물과 시장 전체에 대한 판단을 구분한다

• 초반에 공유한 요금제 관련 게시물은 공식 발표가 아니라 재미있어서 가져온 게시물이라고 보여준다 [06:25]
• 현재 상황을 AI만의 거품 문제로 보지는 않으며, 시장 전반에 더 큰 일이 벌어지고 있다고 생각한다. 이는 개인적인 판단이고, 구체적인 원인을 확정하지는 않는다 [06:38]

6. 사용 한도 확대와 모델 경쟁을 긍정적으로 평가한다

• Pro 100·200·500 및 Business Premium의 사용 한도를 두 배로 늘린다는 안내를 확인한다. 다만 이전 한도 축소 이후의 기준이므로, 기존 20배가 그대로 40배가 된다는 뜻으로 해석하지 않는다 [08:17]
• 자신의 이해로는 500 요금제가 50배, 200 요금제가 20배, 100 요금제가 기존 5배에서 10배가 된다. 이 수치는 확정적인 검증 결과가 아니라 안내에 대한 해석이다 [08:32]

7. Clear Mud HQ는 흩어진 도구를 한곳에서 사용하려는 필요에서 나왔다

• Clear Mud HQ는 정해진 템플릿보다 여러 OS를 만든 경험과 고객 프로젝트에서 얻은 아이디어를 바탕으로 발전했다. 도구마다 다른 탭을 오가는 불편과 시간 낭비가 직접적인 문제였다 [11:01]
• 각 도구를 기존 개발 서버에 그대로 둔 채 HQ에서 접근하는 구조를 지향한다. GitHub 저장소나 별도 서버·포트의 도구를 연결하며, 현재 환경은 외부에 공개하지 않은 로컬 구성이다 [11:54]

8. 통제 가능한 일에 집중하되 실제 손실의 부담도 인정한다

• 이미 가진 것, 통제할 수 있는 것, 현재 순간에 주의를 기울이는 태도를 권한다. 다만 실제로 많은 돈을 투자해 큰 손실을 보는 사람에게는 두려움을 피하기 어려울 수 있다는 점도 인정한다 [14:53]
• 계정 화면에서는 기존 Max 대신 Ultra라는 명칭이 실제로 나타난다. 구독 인증 방법을 둘러싼 추측과 별개로, 명칭 변경은 화면에서 확인한 내용이다 [15:42]

9. 닌자 거북이 테마의 대전 게임을 모호한 요구사항으로 제작한다

• Opus 55의 모든 effort 수준을 시험하기 위해, Mortal Kombat 방식의 닌자 거북이 게임을 처음부터 끝까지 만들도록 요청한다. 시작 캐릭터는 거북이 네 명과 스플린터를 포함한 다섯 명이다 [16:17]
• 캐릭터 외형과 3D 모델 제작에 필요한 조사를 모델에 맡기고, 원작과 매우 유사한 모습을 요구한다. 개인용이며 판매·공개하지 않을 예정이라는 조건도 붙이지만, 저작권에 문제가 없다는 판단은 요청자의 주장이다 [16:59]

10. 데이터 생성 시작과 게임 완성을 구분한다

• 한 실행에서 약 2MB가 기록된 것을 보고 완성이 임박했다고 생각하지만, 실제로는 데이터 작성을 시작했다는 의미였다. 다른 실행들은 여전히 조사와 추론을 진행하고 있어, 생성 속도만으로 완성도를 판단할 수 없는 상태다 [18:25]
• 기존 월 200 구독은 별도 업그레이드보다는 Ultra로 이어지는 것으로 이해한다. 새 상품을 추가 구매했다는 의미로 보지는 않는다 [18:58]

11. Imagination Studio는 추후 시험할 도구 후보로 남는다

• 피드에서 우연히 발견한 Imagination Studio 저장소에 관심을 갖고 직접 사용해 보려 한다. 이 시점에는 실제 사용 결과보다 저장소와 요구 사항을 살펴보는 단계다 [20:31]
• Apple Silicon 관련 항목과 Fish Audio를 확인하고, 자세한 시험은 방송 밖에서 이어 갈 계획이다 [21:02]

12. 게임 미리보기는 표시되지만 아직 실행이 끝나지 않았다

• ‘Shell Combat’, ‘Sewer Showdown’이라는 이름의 화면이 나타나지만 처음에는 조작이 되지 않는다. 작업이 계속 실행 중이어서, 완성된 게임이 아니라 먼저 표시된 미리보기로 이해한다 [21:34]
• 짧은 시간 안에 화면이 나왔다는 사실만으로 좋은 결과라고 보지는 않는다. 너무 빨리 끝났다면 원하는 품질에 못 미쳤을 것이라는 판단이다 [22:08]

13. Build Bench의 창 너비 축소 시 버튼이 벗어나는 문제를 수정한다

• Build Bench의 화면 배치를 조정하는 과정에서 창 크기에 따른 표시 문제가 드러난다. 이를 작은 수정 작업으로 바로 처리하려 한다 [22:18]
• 구체적인 문제는 Build Bench의 너비를 줄일 때 오른쪽 아래 프롬프트 채팅창의 버튼이 이동하면서 창 밖으로 겹쳐 나오는 현상이다. 수정 요청에 해당 위치와 발생 조건을 함께 넣는다 [23:32]

14. 플레이어별 단축키 차이가 게임 조작을 어렵게 만든다

• 게임을 시험하면서 자신과 컴퓨터 캐릭터를 구분하기 어렵고, 이동·공격·방어 키도 즉시 파악하기 어렵다. 숫자키와 S키 등을 확인하지만 조작 체계가 명확하게 이해되지 않는다 [25:15]
• 처음에는 단축키가 작동하지 않는다고 생각했으나, 플레이어마다 키 배치가 다르다는 점을 발견한다. J·K·L·U 조합을 따로 익혀야 하는 상태다 [26:27]

15. 낮은 effort 결과도 가능성을 보이지만 조작 개선이 필요하다

• 낮은 effort 결과를 시험하며 더 높은 effort가 더 나은 결과를 낼 것으로 예상한다. 이 구간에서는 아직 비교 결과가 아니라 기대에 해당한다 [28:18]
• 일부 공격 키는 실제로 작동하며 상대를 공격할 수 있다. 다만 이동과 공격을 더 자연스럽게 배치할 필요가 있어, J·K·L 등을 활용하는 단축키 구성을 고민한다 [28:48]

16. 점수판의 텍스트 선택과 결과 열기를 분리한다

• Clearbench 점수판에서 숫자를 드래그해 선택하려 해도 해당 세션이 열린다. 행 전체 클릭 대신 점수판 오른쪽 위의 명시적인 진입 지점으로 결과를 열도록 바꿀 필요가 있다 [30:10]
• 수정은 작은 UI 변경으로 한정하고, 현재 진행 중인 테스트 실행은 중단하지 않는 조건이다 [30:49]

17. 우수한 테스트 결과를 GitHub 저장소로 이어간다

• 지금까지 테스트 결과는 매번 보관 처리했고 다시 활용하지 않았다. 만족스러운 결과가 나오면 개발을 이어갈 수 있도록 Git 커밋과 저장소 생성 옵션이 필요하다 [31:37]
• GitHub 계정에 저장소를 만드는 기능을 Clearbench에 추가하려 한다 [32:01]

18. 신규 모델을 모든 effort 수준에서 반복 평가한다

• 모델 출시마다 모든 effort 수준을 시험하고, 한 영상에서 여러 빌드를 비교하는 형식을 지속할 계획이다 [33:35]
• 이상적으로는 출시 후 24시간 안에 테스트하고 싶지만, 현재는 고객 업무와 계약상 의무가 채널보다 우선하므로 항상 그 속도를 맞출 수는 없다 [33:52]

19. Kimi는 보조 관점에 활용하고 에이전트 평가는 별도로 설계한다

• 에이전트와 하네스 관점에서 모델을 시험하는 별도 앱을 구상한다. Clearbench의 범위를 넓히기보다 별도 작업공간을 만들고, HQ를 독립 VM으로 옮긴 뒤 개발을 이어갈 생각이다 [34:58]
• 사용할 하네스는 아직 정하지 않았다. OpenClaw, Hermes Agent, Buzz 등이 후보이며 추가 검토가 필요하다 [35:42]

20. 라이브 음질은 녹화 영상과 처리 방식이 다르다

• 긴 녹화 영상은 DaVinci Resolve에서 음성을 보정하지만, 라이브에는 마이크 배경 소음을 제거하는 필터 하나만 적용한다 [40:04]
• 포르투갈에서 사용했던 넓은 차고 공간은 울림이 심했다. 미국으로 돌아온 뒤 OBS 오디오 입력에 필터를 추가하면서 배경 소음을 줄였다 [40:25]

21. 새 장비 도입과 기존 장비 재활용으로 인프라를 정비한다

• 주말에는 가족 일정과 함께 블라인드 교체, 미니 PC 이동 등 작업 환경과 서버 인프라 정비를 진행할 계획이다 [41:11]
• 새 노트북은 월요일에 도착할 예정이며, 기존 노트북도 여전히 쓸 수 있으므로 서버 랙에 넣어 활용하려 한다 [41:46]

22. 다음 effort 비교 영상은 Terra를 우선한다

• 이미 녹화한 두 번째 영상을 폐기하고, 모든 effort 수준을 비교하는 영상으로 대체하는 방안을 고려한다. 후보는 Gemini 4 Argon과 6.1 Terra다 [42:04]
• Carbon은 자신의 모델 목록에 아직 나타나지 않아 접근할 수 없는 상태다 [42:30]

23. 제한된 게임 시간으로 휴식과 아이디어를 확보한다

• 과거 World of Warcraft의 누적 플레이 시간은 365일을 넘었으며, 대학 시절 더 활발한 사회생활을 위해 게임을 그만뒀다 [42:57]
• 지금은 고객 업무와 YouTube·Clear Mud 콘텐츠 제작에 집중하면서 가볍게 즐길 생각이다. 일에서 잠시 벗어나 재미와 창의성에 집중하는 시간이 새로운 아이디어를 얻는 데 도움이 된다 [43:40]

24. Mistral 등 추가 모델의 시험 경로를 찾는다

• 대화에 등장한 Mistral 모델이 이미 한동안 공개돼 있었다는 점을 확인하고, 테스트에 사용할 수 있는 요금제를 알아볼 계획이다 [45:49]
• 일부 모델을 시험하기 위해 OpenRouter 이용 방식을 검토하는 일도 할 일 목록에 포함돼 있다 [46:19]

25. 오픈웨이트 모델 평가에 클라우드 예산을 배정한다

• OpenRouter는 사용량에 따라 지불하는 방식이며, 다른 후보인 Ollama에서는 이전에 막혀 있던 Max 구독을 현재 신청할 수 있다 [47:43]
• Pro부터 시험할 생각이지만, 모든 effort 수준을 평가하는 작업량이라면 빌드를 한두 개 만드는 데 그칠 수도 있다고 예상한다. 이에 Ollama 클라우드에 월 100달러를 배정하는 방안을 고려한다 [48:04]

26. 미디엄 effort 게임은 완성도와 함께 조작·물리 문제를 드러낸다

• 미디엄 effort 빌드는 31분 만에 완료됐고 외형은 더 정돈돼 보인다. 다만 두 플레이어가 같은 키보드를 나눠 쓰는 조작 방식은 불편하다 [49:44]
• 실제 대전에는 캐릭터별로 다른 특수기가 있지만, 일부 물리 동작이 제대로 구현되지 않았다. 회전 동작도 신체의 한 지점을 축으로 삼아 어색하게 움직인다 [51:37]

27. Ollama 결제 전에 Clearbench 연동 방식을 확인한다

• 우선 20달러 구독으로 시작하는 방안도 고려한다. 자체 하드웨어가 없는 상태에서 오픈웨이트 모델을 시험하기 위해 Ollama 클라우드와 Clearbench를 연결하려 한다 [52:44]
• 결제 전에 연동에 필요한 작업을 확인하며, 구독 인증 방식으로 연결할 수 있을 것으로 예상하지만 아직 확정하지는 않는다 [53:06]

28. 실행 종료를 기다리며 보관과 후속 개발을 구분한다

• 남은 테스트는 5분 더 기다릴 계획이다. 실행 결과는 대체로 보관하되, 마음에 드는 결과가 있으면 Git에 커밋해 개발을 이어가려 한다 [54:22]
• 프리뷰 브랜치에는 배포해야 할 변경 사항이 14개 있다. 프리뷰에서는 점수판 행을 클릭해도 세션이 열리지 않아 앞서 지적한 동작이 수정된 것을 확인한다 [54:43]

29. Brave의 자원 사용량 때문에 Helium을 시험한다

• 고객별 계정, Clear Mud, 개인 용도로 브라우저 프로필을 나누고 여러 탭을 열어 두다 보니, Brave 프로필 서너 개를 동시에 사용할 때 자원 부담이 커진다 [55:43]
• 자원을 덜 사용하는 Chromium 기반 대안으로 Helium을 시험하고 있다. Brave도 계속 사용하면서 일부 프로필을 Helium으로 옮기는 방안을 고려한다 [56:09]

30. 작업 맥락이 축적된 환경에서 Agent Bench를 만든다

• Agent Bench는 테스트용 작업 환경에 기본 정체성과 기존 작업 이력을 갖추고, 그 안에서 모델별 에이전트 수행 능력을 비교하는 형태를 지향한다. 하네스 후보는 OpenClaw, Hermes, Pi다 [56:40]
• 개발을 이번 주말에 시작할지는 불확실하지만, 라이브 방송에서 구축을 시작할 가능성이 크다 [59:34]

31. 개발 일정의 불확실성과 게임 테스트의 개선 과제

• Agent Pench와 관련 영상은 크리스마스까지 작동하게 하는 것이 희망 일정이다. 작업이 진행되면 Pi를 직접 사용해 볼 시간도 생길 것으로 기대한다. [1:00:09]
• 가격 체계가 2026년 8월에 토큰당 과금으로 바뀌었다는 정보는 비용 보고 방식에 영향을 줄 수 있지만, 공식 문서 확인이 필요한 상태다. [1:00:44]

32. 원샷 벤치마크에 한 차례 수정을 허용하는 구상

• 기존 벤치마크는 원샷 프롬프트를 전제로 한다. 한 차례 수정까지 허용하면 어떨지 검토하며, 이를 Clearbench의 새 기능으로 추가할 가능성을 열어 둔다. [1:03:09]

33. 통제할 수 있는 제작 활동에 집중하는 태도

• 외부 상황에 대한 불안을 키우기보다, 지금을 고개를 숙이고 재미있는 것을 만들기에 좋은 시기로 본다. [1:03:44]
• 통제할 수 없는 일에 지나치게 신경 쓰기보다 자신이 가진 것과 바꿀 수 있는 일에 집중하는 편이 더 행복한 생활로 이어진다고 믿는다. 제작을 즐기면서 야외 활동과 주말의 여유도 챙기자는 권고로 계속된다. [1:04:01]

34. 일상용 도구와 아이디어 협업 도구의 구분

• Hermes는 매일 사용하지만 자동화를 맡기는 용도로 의존하지는 않는다. OpenClaw와 Grockbot을 주력으로 사용하고, Duet도 시험 중이며 나머지 도구는 간헐적으로 사용한다. [1:04:41]
• Buzz에는 릴레이를 만들고, 일론 머스크·샘 올트먼·잭 도시의 이력과 강점·약점에 관한 맥락을 넣어 서로 다른 관점으로 깊이 대화하고 아이디어를 함께 검토한다. 주된 용도는 대화와 협업이며, 일상적인 중심 도구는 OpenClaw다. [1:05:07]

🧾 결론

• 만들기를 계속한다는 메시지는 작은 UI 수정, 서버 분리, 테스트 결과 재활용 같은 구체적인 작업으로 이어진다.
• 미리보기 표시나 데이터 생성 시작은 완성의 증거가 아니다. 직접 조작하고 결함을 확인해야 결과의 가치를 판단할 수 있다.
• 모델 평가는 동일한 요청 아래 품질·시간·비용을 함께 살펴야 한다. 높은 effort가 더 좋은 결과를 낼 것이라는 기대와 실제 비교 결과를 구분해야 한다.
• 초기 결과를 반복해서 다듬고, 만족스러운 결과를 후속 개발로 연결하는 과정이 중요하다.

📈 투자·시사 포인트

• 시장 전반에 문제가 있다는 발언은 개인적인 판단이다. 이 자료만으로 시장 원인이나 자산 가격의 방향을 판단할 근거는 부족하다.
• AI 개발 비용은 구독 가격이나 생성 속도만으로 평가하기 어렵다. 미디엄 게임 사례처럼 추가 시간과 비용이 들면서도 사용성 문제가 남을 수 있다.
• DFS 도구는 남은 시즌의 직접 사용 기록을 쌓은 뒤 판매하려는 계획이다. 현재 수익이 플러스라는 설명과 향후 수익·승률 개선 기대는 구분해서 봐야 한다.
• 클라우드 평가 예산과 자체 호스팅 계획은 연동 가능성, 실제 작업량, 하드웨어 가격에 좌우된다. 언급된 예산은 확정 지출이나 보편적인 적정 비용이 아니다.

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

• 요금제 명칭 변경과 사용 한도 변경은 별개다. Ultra 표시는 계정에서 확인했지만, 초반 게시물은 공식 발표가 아니며 한도 배수도 발표자의 해석이 포함돼 있다. 구독 두 개를 나눠 쓰는 사용 경험을 단일 구독에 그대로 적용하기도 어렵다.
• 모든 effort 수준의 최종 비교가 제시된 것은 아니다. 낮은 effort에 대한 호평과 미디엄 빌드 관찰만으로 전체 성능 순위를 확정할 수 없다.
• 마지막 API 비용은 자막상 ‘A$165’로 제시된다. 정확한 통화와 집계 범위는 확인이 필요하며, 토큰당 과금 전환 정보도 공식 문서 검증이 남아 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 요금제를 비교할 때 공식 안내와 실제 계정 화면을 대조하고, 명칭·한도 기준·적용 조건을 따로 기록한다.
• effort별로 같은 게임 요청을 실행하고 완료 시간, 비용, 조작 가능 여부, 물리 오류를 함께 기록한다.
• 버튼 넘침은 창 너비와 발생 위치를 명시해 재현하고, 점수 선택과 결과 열기가 구분되는지 실제 화면에서 확인한다.
• HQ와 개발 도구의 VM 분리 전에 공유 자원과 영향 범위를 확인하고, 이전 뒤 OpenClaw 자원 경합이 줄었는지 점검한다.

❓ 열린 질문

• 모든 effort 수준이 완료되면 추가 비용과 시간이 실제 게임 품질 향상으로 얼마나 이어질까?
• 원샷 이후 한 차례 수정을 허용하면 조작·물리 문제는 얼마나 줄어들며 모델 간 평가 결과는 어떻게 달라질까?
• 작업 이력과 기본 정체성이 축적된 Agent Bench에서는 모델과 하네스의 영향을 어떻게 구분할 수 있을까?