No Fable 5.5: But we Get Kimi 3.1 Pro!

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Fable 5.5가 나오지 않아 Kimi 3.1 Pro를 바로 시험했지만, 초기 구현은 기대에 못 미쳤고 업무용 성능 판단에는 추론 노력 수준별 추가 비교가 필요하다.

📌 핵심 요점

1. Fable 5.5를 기다리던 중 공개된 Kimi 3.1 Pro를 즉석에서 시험했다. 이번 방송은 정식 평가가 아니라 출시 직후의 탐색적 테스트다.
2. 핵심 과제는 IKEA 조립 설명서를 단계별 3D 도구로 바꾸는 것이다. 제품 세 개와 문서를 직접 찾도록 해 검색·자료 확보·구현 능력을 함께 살피려 했다. Kimi 결과에서는 서랍이 패널처럼 구현됐고, Claude 결과에서는 실제 서랍과 더 세밀한 구현을 확인했다.
3. 비교의 목적은 최고 설정을 고르는 것이 아니라 필요한 품질을 얻는 비용을 찾는 데 있다. 무료 접속 혼잡으로 Kimi Max를 선택했지만, 구독 사용량과 웹·코드 환경의 집계 방식은 명확히 확인하지 못했다.
4. T3 Code에서는 인증 문제와 반복 승인이 작업을 방해했다. 이전 버전 복귀로도 승인이 계속됐고 GPT에서는 재현되지 않았다. 후반에는 Claude Code 설정 변경과 새 스레드 사용 이후 개선됐으며, 종료 시점에는 해결된 것으로 보았다.
5. 후속 평가에서는 여러 개발 과제를 모든 추론 노력 수준으로 반복할 계획이다. 시각적 홍보나 공개 벤치마크에 대한 기대보다 고객 서버·개발 업무에 필요한 구현 품질을 직접 확인하는 데 무게를 둔다.

🧩 배경과 문제 정의

• 이번 주에는 기대했던 Fable 5.5가 나오지 않았고, 새로 공개된 Kimi 3.1을 테스트 대상으로 삼는다.
• 모델마다 여러 추론 노력 수준을 같은 과제로 비교해, 이용자가 구독료와 토큰 소비를 고려하면서 자신에게 맞는 모델과 설정을 고를 수 있도록 하려 한다.
• 비교 과제는 시각적 결과물뿐 아니라 문서 탐색, 실제 서비스 구현, 사업에 필요한 산출물까지 평가하도록 구상한다.
• 실제 테스트에는 무료 계정의 접속 혼잡과 T3 Code의 인증 문제가 걸림돌이 된다. 여러 구독과 장비를 활용할 실행 환경도 정비필요가 있다.

🕒 시간순 섹션별 상세정리

1. 새 모델의 모든 추론 노력 수준을 비교하는 고정 과제

• 새 모델이 나올 때마다 각 추론 노력 수준에서 여러 결과물을 만드는 시리즈를 구상한다. 시각 중심 과제, 다른 회사를 위한 아이디어, 창업자와 중소기업에 유용한 과제를 포함한다. [01:14]
• 사업용 과제는 랜딩 페이지, 리드 유입 경로, 정보 수집용 백엔드, 시장 진출 전략, 성공한 광고 분석과 광고 제작용 산출물을 하나의 프롬프트로 만드는 방식이다. [01:40]

2. 무료 계정에서 확인한 설정과 구독 선택을 위한 비교 기준

• Kimi 무료 계정으로 테스트를 시작하며, 웹 빌드 화면에서 선택 가능한 노력 수준은 Standard·High·Max로 확인한다. [02:57]
• 모든 모델과 설정을 직접 시험할 예산이 없는 이용자에게 성능 차이와 비용을 함께 제공하려 한다. 더 저렴한 구독으로도 필요한 결과를 얻을 수 있는지 판단하는 것이 비교의 목적이다. [03:41]

3. IKEA 조립 설명서를 단계별 3D 학습 도구로 전환

• IKEA의 PDF 조립 설명서를 읽는 대신, 부품 회전과 연결 방법, 나사 위치를 3D로 확인하는 웹 앱을 제안한다. 이런 웹사이트가 없다는 판단은 자신의 지식 범위에 한정한다. [05:10]
• 앞서 Opus 5.5로 제품 하나를 한 번의 요청으로 구현한 예시는 설명서풍·사실적 완성 이미지와 단계별 조립 화면을 제공한다. 필요한 도구와 부품, 뒤집거나 나란히 놓는 동작도 안내한다. [06:09]

4. 제품 문서의 검색과 확보까지 포함하는 벤치마크

• 기존 예시는 만들고 싶은 도구를 설명하고 시작할 제품 하나를 직접 제공했다. 새 비교용 프롬프트는 모델이 제품 세 개를 직접 찾도록 구성한다. [06:55]
• 결과물 구현과 함께 조립 문서를 검색하고 출처를 찾아 확보하는 능력도 평가하려 한다. 설명서를 읽기 싫어하는 사용자도 따라갈 수 있도록 자동 재생 기능을 더하는 아이디어가 나온다. [07:26]

5. 무료 접속 혼잡으로 Max 구독을 선택

• Opus 5.5의 Extra High 설정으로도 시험하려는 가운데, Kimi에서는 이용자가 너무 많아 접속할 수 없고 구독자에게 우선 접속을 제공한다는 메시지가 나타난다. [09:13]
• 월 39달러와 99달러 선택지를 살피며 테스트 중 사용량을 빨리 소진할 가능성을 고려한다. Kimi Code를 CLI에 설치해 T3 Code에서 활용하는 방법도 확인한다. [09:49]

6. CLI 연동 시도와 공개 벤치마크에 대한 초기 기대

• Kimi를 T3 Code의 제공자로 추가하려면 CLI 설정이 필요하다고 판단하고 로그인 절차를 진행하지만, 기대한 인증 팝업이 나타나지 않는다. [11:35]
• 화면의 벤치마크 이미지상으로는 Kimi가 Opus 5.5와 Astra 6 수준으로 보인다는 잠정적인 평가를 내린다. [12:51]

7. ClearMud HQ를 OpenClaw 서버에서 분리하는 구상

• ClearBench의 자원 사용량이 크고 HQ가 확장되고 있어, OpenClaw 서버에 함께 있는 ClearMud HQ를 별도 서버로 옮기려 한다. 고려하는 자원은 16코어, 메모리 약 32GB, 저장 공간 약 0.5TB다. [13:53]
• HQ는 GitHub 저장소에서 가져온 Canvas·Motion·Radar·Bench를 호스팅한다. 주말 작업을 거쳐 다음 주까지 HQ를 별도 VM으로 옮기고, ClearMud OS는 현재 OpenClaw 서버에 두려는 계획이다. [14:16]

8. 직접 호스팅하기 어려운 모델을 클라우드에서 시험

• 관심을 끄는 모델을 더 폭넓게 시험하기 위해 Ollama 클라우드나 OpenRouter, 또는 둘 다 이용하는 방안을 고려한다. 자체 하드웨어로 실행하기 어려운 오픈 웨이트 모델을 활용하려는 목적이다. [14:42]
• OpenRouter의 종량제 이용을 검토하면서 API 비용이 일반 가격의 약 3분의 1일 수 있다고 추측하지만, 가격 구조는 추가 조사가 필요하다고 인정한다. [15:19]

9. 높은 노력 수준의 효용과 반복 가능한 비교 형식

• 시청자는 Opus가 Ultra 설정에서 많은 하위 에이전트를 만들며 일부 경우 성능이 떨어져 Medium을 선호한다고 경험을 공유한다. 다른 모델은 Max를 사용한다는 의견도 있어, 높은 설정이 항상 유리한지는 비교필요가 있다. [17:57]
• 여러 과제에서 Medium이나 High가 충분한지 확인할 수 있다면 토큰 낭비와 만족스럽지 못한 구독 선택을 줄일 수 있다. 창업자와 중소기업 이용자에게 이런 판단 근거를 제공하려 한다. [18:15]

10. CLI와 T3 Code의 모델 선택·인증 문제

• CLI 준비를 마친 뒤 T3 Code에서 모델 선택지가 보이지 않는 문제를 만난다. CLI에서는 여러 모델을 선택할 수 있어 T3 Code를 업데이트하고 재시작해 보기로 한다. [21:26]
• 웹의 테스트는 계속 실행 중이며, CLI 모델은 3.1 Pro로 바꾼다. CLI의 노력 수준은 Low·Higher·Max로 확인하고, 재시작 뒤에도 기존 작업이 계속된다는 점을 확인한다. [22:49]

11. 여러 구독을 쓰기 위한 장비별 인증 우회책

• T3 Code에 보조 구독을 별도 제공자로 추가하는 방법을 아직 해결하지 못했다. 현재 찾은 우회책은 다른 장비나 실행 환경에서 보조 구독을 인증하고 환경을 전환하는 방식이다. [24:57]
• 오래된 Xeon 기반 ProArt 장비와 M1 Max를 재활용하고 서버에 T3용 VM도 만들어, 항상 켜져 있는 여러 실행 환경을 구성하려 한다. [25:12]

12. 소닉 게임을 반복 비교용 과제로 활용

• 좋아하는 게임인 소닉을 만드는 과제를 새 모델의 노력 수준별 테스트에 포함하려 한다. 모델마다 비교할 수 있는 반복 과제로 쓰되 일부 조건은 조정할 계획이다. [26:25]

13. 보건 검사 보고서와 법규를 대조하는 도구

• 시청자가 만든 도구는 보건 검사 보고서에서 정보를 추출하고 시·주·연방 규정을 검토해, 검사관 판단의 불일치와 감점 항목을 찾고 해당 기준에 따른 수정 방법을 제시한다는 설명이다. [26:55]
• 이 도구를 음식점의 보건 검사 준비에 활용할 가능성을 떠올린다. 다만 검사가 무작위인지 예약 방식인지는 알지 못하며, 음식점 POS와 네트워크 경험이 검사 절차에 대한 지식으로 이어지지는 않는다고 드러낸다. [27:25]

14. Railway 보안 공지에 따른 앱 중단과 교체 요구

• Railway의 보안 공개 후속 응답을 확인하고, 이틀 전에도 관련 공지가 게시됐음을 발견한다. 이메일을 받았는지는 기억하지 못한다. [28:16]
• 관련 앱을 우선 오프라인으로 전환하기로 한다. 공지에서 모든 항목을 교체하라고 요구한다고 말하지만, 구체적인 대상은 자막에 나타나지 않는다. [28:43]

15. 인증 문제를 Opus에 맡기고 웹 테스트는 계속 대기

• Opus 5.5에 Kimi를 T3 Code 제공자로 인증하는 문제를 해결하도록 요청한다. 로그인 버튼을 눌러도 팝업이나 안내가 나오지 않는 현상을 전달하고 해결 방법을 찾도록 한다. [29:08]
• 처리 구간 끝에서도 웹의 Kimi는 계속 생각 중이다. 프롬프트가 컸을 가능성을 언급하며, 이 시점에는 생성 결과를 확인하지 못한다. [29:54]

16. 기존 Opus 작업의 실행 시간 확인

• 기존 작업은 Opus 5.5의 extra high 설정으로 32분이 걸렸다. 예상보다 오래 걸렸다는 점을 실제 기록으로 확인한다 [30:08]

17. 반복 승인으로 약해진 T3 Code의 사용 이점

• T3 Code의 주요 장점은 CLI에서 선택지를 입력하며 승인하는 번거로움을 줄이는 것이었다. 매번 버튼을 눌러야 한다면 도구를 사용하는 이점이 줄어든다고 평가한다 [30:47]
• 새 승인 요청이 최신 업데이트와 관련됐을 가능성을 의심한다. 화면에는 T3 Code가 해당 요청을 끌 수 없으므로 내용을 확인하고 승인해야 한다는 안내가 나온다 [31:07]

18. 식당 점검 대비를 일상 운영 기준으로 확장

• 무작위 점검에 대비하는 서비스는 보건당국의 검사 준비를 돕는 방식으로 제시할 수 있다. 다만 식당은 매일 점검을 예상하며 기준을 지키는 편이 맞다는 의견을 덧붙인다 [31:33]
• 미쉐린 식당도 매일이 점검일인 것처럼 운영할 것이라고 추측하며, 일회성 준비보다 상시 관리의 필요성을 강조한다 [31:47]

19. 가족 이동 경로에 경고를 보내는 앱과 명단 해석의 주의점

• 시청자는 로웰시가 페이스북에 게시한 핼러윈 방문 주의 주택 정보를 바탕으로, 가족이 걸어갈 때 해당 위치를 알려주는 인터랙티브 앱을 만들었다고 한다. 지역 공개정보를 활용한 유용한 사례로 평가한다 [31:58]
• 한편 공공장소에서의 배뇨가 노출 행위로 처리돼 등록 명단에 오를 수도 있다는 기억을 언급한다. 이는 개인적 회상과 추정이며, 명단에 포함된 사유가 다양할 가능성을 제기하는 수준이다 [33:52]

20. 승인 대기가 병행 작업과 자동 실행을 방해

• CLI에서 다른 작업을 하다가 돌아오면, 자동 모드를 켰는데도 승인을 기다리며 멈춰 있던 경험이 있다. 이런 중단을 줄이는 점이 GUI와 함께 T3 Code를 선호한 이유였다 [35:49]
• 이전에는 승인이 드물었지만 업데이트 이후 두 스레드에서 연이어 발생한다고 호소하며, 변경 원인과 비활성화 방법을 확인하려 한다 [36:25]

21. 이전 버전 복귀 검토와 프로젝트 문맥의 영향

• 승인 요청이 계속되자 T3 Code를 이전 릴리스로 되돌리는 방안을 선택한다 [38:59]
• 업데이트 직후 문제가 시작됐다는 점을 원인으로 보는 근거로 들지만, 평소에는 프로젝트에 속하지 않은 스레드를 거의 사용하지 않았다는 차이도 인정하고 관찰을 더 해보기로 한다 [39:55]

22. 외부 경로 읽기 관련 설정 변경 시도

• 외부 경로 읽기를 차단하는 것으로 보이는 설정을 찾아, 해당 줄을 삭제할지 값을 false로 바꿀지 검토한다 [41:14]
• 이 설정이 Claude에만 해당하는 것으로 보인다는 점 때문에, 현재 승인 문제 전체를 설명할 수 있는지는 불확실하다 [42:01]

23. Kimi 3.1 Pro의 노력 수준 선택과 웹 작업 지연

• 새 스레드에서 Kimi 3.1 Pro를 선택할 수 있지만, 별도 토글로 노력 수준을 바꾸는 대신 선택 항목 안에서 원하는 수준을 골라야 하는 것으로 파악한다 [45:17]
• 웹에서 실행한 Kimi 작업은 여전히 진행 중이다. 경과 시간은 약 30분으로 추정하며, 완료 시간은 확인되지 않는다 [45:40]

24. 등록 관련 법적 불확실성과 교통 단속에 대한 경험

• 앞서 언급한 등록 문제에 대해 주별 규칙을 모두 알지는 못한다고 드러낸다. 캘리포니아에서 그런 일이 있었다고 주장하면서도, 경찰관의 판단에 영향을 받을 수 있다는 개인적 견해를 덧붙인다 [48:27]
• 자신이 경험한 캘리포니아에서는 고속도로 순찰대가 몸을 숨기고 속도 단속을 하는 반면, 포르투갈에서는 기계식 단속을 접했다며 두 지역의 경험을 비교한다. 이를 미국 전체로 일반화할 수 있는지는 확신하지 않는다 [49:00]

25. 긴 실행 시간과 기대에 못 미치는 초기 결과

• 작업이 오래 걸리는 가운데 승인 요청도 다시 발생해, 설정 변경 후에도 중단 문제가 남아 있음을 보여준다 [50:11]
• 확인 중인 결과물이 좋아 보이지 않는다고 평가하며, 프롬프트를 더 단순하게 유지했어야 했을 가능성을 제기한다. 구체적인 품질 결함이나 원인은 확정하지 않는다 [50:43]

26. 노력 수준별 평가 계획과 설정 원복

• 앞으로 새 모델이 출시될 때마다 모든 노력 수준을 시험하는 영상을 만들 계획이다. 현재 진행 중인 작업은 정식 평가보다는 탐색적인 시험에 해당한다 [52:09]
• Claude Code 관련 설정을 false로 바꿔도 달라진 점이 없다고 판단해, T3 Code를 이전 버전으로 되돌리려 한다 [52:37]

27. Kimi 홍보 영상의 시각 요소 편중

• Kimi 홍보 영상은 시각 요소에 매우 집중돼 있다. 광고 자체는 잘 만들었다고 평가하면서도, 내용이 시각적 표현에 치우쳐 있다는 인상을 강조한다 [55:18]

28. 웹과 코드 환경의 사용량 집계 차이

• 사용량 화면에는 구독 사용량이 0으로 표시된다. 이를 근거로 Kimi 웹과 Kimi Code의 집계가 다를 가능성을 제기하지만, 사용량이 초기화됐을 가능성도 남겨둔다 [56:20]
• 유료 사용량이 프롬프트 하나로 소진된다는 다른 이용자들의 불만을 봤다고 한다. 다만 이들이 어떤 설정을 썼는지 알지 못하며, max나 ultra fast 모드 사용 여부를 가능한 설명으로 추측한다 [56:36]

29. 시각 중심 제품 접근에 대한 유보

• 시각적 결과를 우선하는 접근에는 동의하기 어렵다는 입장을 명확히 한다. 홍보 영상의 완성도에 대한 긍정적 평가와 별개로, 그 방향 자체에는 비판적이다 [56:53]

30. 승인 문제의 지속과 재시작 요구

• 추가 승인 요청이 다시 발생해, 앞선 설정 시험 이후에도 문제가 계속되고 있음을 확인한다 [58:14]
• 반복되는 중단 때문에 재시작을 요구한다. 이 시점까지 이전 버전 복귀나 재시작으로 문제가 해결됐다는 결과는 제시되지 않는다 [58:26]

31. Google 유료 가입 이후에도 풀리지 않는 모델 접근 제한

• 업무용 Workspace 계정에서는 Ultra로 쉽게 업그레이드할 수 없고 AI 확장 접근만 선택할 수 있다. 24달러를 지불했지만 원하는 모델에 접근하지 못해, 여러 추론 수준을 비교하려던 테스트가 막힌다. [1:00:53]
• 개인 계정도 Pro 요금제인데 해당 모델이 비활성화되어 있다. Ultra와 유료 Pro 가입자에게 제공된다는 안내와 실제 접근 상태가 일치하지 않는다. [1:01:43]

32. T3 Code를 원인으로 단정하기 어려워진 승인 문제

• 반복되던 문제가 계속 나타나면서 T3 자체의 문제라는 초기 추정이 흔들린다. Claude Code 업데이트 가능성이 제기되지만 원인은 확정되지 않는다. [1:05:42]
• 문제를 확인하는 과정에서 자동 업데이트가 비활성화된 상태를 발견한다. 자동 업데이트를 끄는 방식은 적절하지 않다고 보고 설정 복원을 요구한다. [1:06:44]

33. IKEA 조립 설명서를 3D로 바꾸는 동일 과제 비교

• Kimi K3의 과제는 상자에 들어 있는 조립 안내 책자나 PDF를 바탕으로 IKEA 가구의 3D 시각화 도구를 만드는 것이다. Opus 5.5에도 같은 프롬프트를 적용해 나란히 비교한다. [1:07:14]

34. Google AI 확장 접근 취소와 환불

• 원하는 접근 권한을 얻지 못한 Google AI 확장 접근을 취소한다. 일할 계산에 따른 환불이 제공되는 것으로 확인된다. [1:11:03]

35. Kimi의 업무용 적합성은 추가 검증이 필요한 상태

• Kimi를 충분히 테스트하지 않아 우위를 판단하기 어렵다. 홍보는 3D에 집중되어 있지만, 평소 Opus 5.5를 사용하는 고객 서버와 개발 작업은 3D 중심이어서가 아니므로 Kimi를 곧바로 신뢰하기는 어렵다는 입장이다. [1:11:40]
• 주말부터 다음 주까지 여러 종류의 개발 과제를 모든 추론 수준에서 시험할 계획이다. Kimi 3.1 Pro의 추론 수준별 비교 영상은 다음 주 목요일 무렵 공개를 목표로 한다. [1:11:58]

36. 긴 생성 시간과 반복 승인이 제한하는 초기 비교

• IKEA 시각화 작업의 정확한 시작 시각은 확인되지 않는다. 방송 시작 약 12분 뒤에 실행했다는 기억을 기준으로, 이미 약 한 시간 동안 생성 중이라고 추정한다. 같은 프롬프트는 Opus 5.5의 extra high 설정에도 적용했다. [1:12:43]
• T3 Code가 작업마다 승인을 요구하면서 진행 시간이 낭비되고 있다. 반복 승인의 원인은 아직 확인되지 않았다. [1:12:57]

37. 생성 완료 뒤에도 확인되지 않는 브라우저 미리보기

• Kimi 작업은 완료되었지만 소요 시간을 보여주는 정보가 없어 정확한 실행 시간은 확인할 수 없다. [1:16:23]
• 결과를 확인하려고 게시를 시도했으나 미리보기에는 빈 흰 화면이 나타난다. 전체 화면으로 바꿔도 결과를 확인하지 못한다. [1:17:21]

38. 자동 모드에서도 계속되는 승인과 업데이트 원인 추적

• 승인 문제는 당일 아침 업데이트 이후 시작되었다. nightly도 설치되어 있지만 주로 사용하는 버전은 beta이므로, 관련 변경 내역을 확인필요가 있다. [1:21:04]
• 전체 접근 권한이나 자동 모드를 켜도 매번 승인이 필요해, 승인 부담을 줄이려고 선택했던 T3 Code의 장점이 약해졌다. [1:21:28]

39. GPT 비교 실행과 프로젝트 유무에 대한 가설 점검

• 모델을 GPT로 바꾸고 extra high 설정으로 새 작업을 실행해, 같은 환경에서 승인 요청이 반복되는지 비교한다. 방송 중 작업 전체를 끝까지 확인하기는 어렵지만 승인 발생 여부는 빠르게 관찰할 수 있다. [1:22:33]
• Claude Code 업데이트가 원인일 수 있다는 추정은 이어지지만, 변경 기록을 충분히 검토해 원인을 확인한 상태는 아니다. [1:23:29]

40. 여러 장치에서 T3를 사용하는 환경 구성 계획

• 서버의 루트 환경에 직접 설치하는 대신 T3용 VM을 만들어 호스팅할 계획이다. 데모용으로 두었던 Xeon 프로세서와 메모리 48GB의 Windows 노트북에도 T3를 설치하려 한다. [1:24:59]
• 기존 M1 장치는 새 주력 컴퓨터에 필요한 환경이 모두 갖춰졌다는 확신이 들 때까지 초기화하지 않는다. 서버 VM과 두 노트북, 새 주력 장치를 합쳐 네 장치에서 T3를 사용하고 모바일도 활용할 구상이다. [1:25:19]

41. GPT에서는 아직 승인 문제가 재현되지 않음

• GPT 작업은 현재까지 원활하게 진행된다. 이 관찰을 바탕으로 문제 범위를 Claude Code 쪽으로 좁혔다고 보지만, 원인을 확정한 것은 아니다. [1:26:12]

42. 연결이 끊기는 장치에서 상시 가동 장치로 작업 넘기기

• 주력 컴퓨터나 모바일에서 시작한 작업을 항상 켜져 있는 다른 장치로 넘기는 방식이 유용할 수 있다. 다만 넘겨받는 장치에서 컴퓨터 조작 기능이 필요 없는 작업을 전제로 한다. [1:26:48]
• 직접 조작하며 개발할 때는 현재 사용하는 장치의 T3 Code에서 작업할 생각이다. 비행기 탑승이나 노트북 종료로 인터넷 연결이 끊기기 전에는 다른 장치로 작업을 넘겨 계속 실행하는 활용을 기대한다. [1:27:17]

43. 전날과 달라진 Claude 승인 동작과 미해결 설정

• GPT에서는 여전히 승인 요청이 나타나지 않는다. 반면 전날 Claude로 개발할 때는 승인 요청이 한 번도 없었다는 경험과 현재 동작이 대비된다. [1:27:48]
• 특정 설정 줄을 이미 false로 바꿨는데도 효과가 없었던 것으로 기억한다. 다시 시도할 수는 있지만, 해당 설정의 정체나 수정 효과는 이 구간에서 확인되지 않는다. [1:28:55]

44. 개발 진입 장벽의 변화와 T3 Code 선호

• 과거 VS Code와 Swift로 작은 개인 프로젝트를 만들 때는 제대로 작동하지 않는 초기 시제품을 구현하는 데도 몇 달이 걸렸다. 현재는 개발을 시작하고 결과를 만드는 일이 훨씬 쉬워졌다고 평가한다. [1:29:38]
• 터미널과 IDE 모두 사용할 수 있지만, 최근에는 T3 Code의 사용 경험을 선호한다. 처음 출시되었을 때는 잘 맞지 않았으나, 4~5개월이 지난 뒤에는 큰 차이를 느껴 본격적으로 사용하기 시작했다. [1:30:04]

45. 반복 승인 요청은 설정 변경과 새 스레드에서 개선됐다

• 자동 모드와 전체 접근 권한에서도 거의 매번 승인 선택이 필요했다. T3에서는 이 문제가 사라졌지만, 최근 Claude Code 릴리스 이후 다시 발생한 것으로 의심됐다. [1:30:15]
• 기존 세션을 멈추고 같은 폴더에 새 스레드를 만들어 이전 작업을 이어갔다. T3 Code도 업데이트했으며, nightly 대신 beta를 사용할 때의 차이는 확실하지 않았다. [1:31:15]

46. 잦은 모델 출시와 비슷한 에이전트가 피로를 키웠다

• Fable 5.5의 당일 출시는 늦었다고 봤지만, 금요일이나 주말에 Claude 모델이 출시된 전례가 있는지는 확신하지 못했다. 현재 Opus 5.5에는 만족하고 있었다. [1:35:05]
• 매주 나오는 모델은 콘텐츠 제작에는 유리하지만, 사용자가 계속 따라가기에는 부담스러웠다. Claude Duet의 조기 접근을 신청했으나 응답을 받지 못했고, 새로운 에이전트를 시험하려는 관심도 줄어들었다. [1:35:22]

47. 에이전트의 가치는 사용자와 업무에 따라 달라졌다

• Grok Bot은 유용하게 쓰고 있지만 OpenClaw를 대체하지는 못했다. Muse 역시 대상 사용자에 따라 가치가 달라질 수 있었다. [1:37:18]
• Duet은 바쁜 전문직과 비즈니스 업무에 더 적합한 도구로 보였다. 이런 방향 때문에 직접 시험하고 싶었지만, 아직 접근 권한이 없었다. [1:38:25]

48. 더 빠른 Opus보다 Fable을 선호했다

• 극단적인 처리 속도가 필요한 업무를 하지는 않았다. 영상 녹화 중 Opus 5.5를 기다리는 시간은 편집으로 잘라내거나 빠르게 처리해야 했지만, 사용을 포기할 정도의 문제는 아니었다. [1:38:51]
• Anthropic 모델은 2026년 들어 대체로 느렸다는 체감이 있었다. 따라서 Opus 5.5의 속도 개선판보다 Fable 5.5를 더 원했다. [1:39:21]

49. Muse는 광고 분석과 제작 프롬프트 생성에 활용됐다

• 새 에이전트는 해당 개발사의 제품·서비스와 연결해 시험하는 방식을 선호했다. Muse에서는 Meta 광고 라이브러리를 조사하고, 장기간 집행되는 광고를 분석해 촬영 목록과 프롬프트를 만드는 자동화를 구축했다. [1:39:50]
• Muse가 처음 만든 라이브러리의 외형은 만족스럽지 않았다. Opus 5.5로 자신의 스타일에 맞게 수정한 뒤, Muse에서 Git pull로 다시 가져와 아티팩트로 사용했다. [100:34] [1:43:45]

50. T3의 같은 스레드 내 모델 전환은 인계 작업을 줄였다

• Kimi CLI가 응답하지 않아 인증 문제일 가능성을 의심했고, 로컬 미리보기 설정은 Claude Code로 이어갔다. 원인은 확정되지 않았다. [102:00] [1:51:55]
• T3 Code는 같은 스레드에서 모델을 바꿀 때 맥락을 넘겨주는 점이 편리했다. 이전에는 모델에 handoff.md를 작성시킨 뒤 다른 모델에게 먼저 읽도록 지시했지만, 이 수동 단계를 줄일 수 있었다. [102:15] [1:52:10]

51. Fable 출시와 OpenAI의 대응 시점은 추측에 머물렀다

• OpenAI가 Astra를 준비해 두었다가 Fable 출시 시점에 맞춰 공개할 수 있다고 예상했다. 이는 확인된 출시 정보가 아니라 개인적인 추측이었다. [103:26] [1:52:25]

52. Kimi와 Claude의 차이는 구현 세부에서 드러났다

• Kimi 결과물에는 세 가지 제품이 있었고, 그중 더 복잡해 보이는 항목을 실행했다. 무언가를 구현하기는 했지만, 서랍이어야 할 부분이 실제 서랍처럼 작동하지 않는 패널에 가까웠다. [104:44] [1:52:40]
• 이번 Kimi 테스트는 기대에 미치지 못했다. 특히 단순한 대상을 골라 구현한 점에 불만이 있었지만, 이 한 번의 테스트를 바탕으로 한 반응이었다. [105:50] [1:52:55]

53. 역공학은 필요한 기능을 자기 앱에 도입하는 데 유용했다

• 애플리케이션 전체를 그대로 복제하기보다 마음에 드는 기능을 골라 자기 앱에 가져오는 방식이 유용하다고 봤다. 다만 관련 저장소를 충분히 시험할 시간은 아직 없었고, 유행에 대한 관심도 섞여 있다고 판단했다. [107:42] [1:53:25]
• 개인용 HQ의 에이전트 계층을 만들면서 여러 도구의 아이디어를 조금씩 도입할 계획이었다. 참고 대상은 대부분 오픈소스였지만, 비공개 소스인 Grok Bot에서도 가져오고 싶은 요소가 있어 추후 시험하려 했다. [108:14] [1:53:40]

54. 스포츠 전망에서는 팀 전력보다 감독의 큰 경기 운영을 우려했다

• 응원팀은 부상에도 전력이 탄탄해 슈퍼볼 진출 가능성이 있다고 봤다. 다만 Kyle Shanahan 감독이 중요한 경기에서 실패해 왔다고 평가하며 우승에는 회의적이었고, 결정적인 단계에서는 다른 사람에게 플레이콜을 맡기는 편이 낫다는 의견이었다. [109:10] [1:53:55]

55. 스크린샷 재현과 애플리케이션 디컴파일은 구분됐다

• 개인용 HQ를 참고하더라도 각자 자기 버전으로 만들기를 바랐다. 자신의 작업 역시 다른 사람에게서 영감을 얻어 독자적인 형태로 구축한 것이었다. [110:19] [1:54:10]
• REA 저장소의 강점은 애플리케이션 디컴파일에 있다고 봤다. HQ는 공개 애플리케이션이 없어 디컴파일할 대상이 없었으며, 스크린샷을 보고 화면을 재현하는 작업은 다른 코딩 에이전트나 모델로도 가능하므로 반드시 REA가 필요하지는 않다고 판단했다. [110:41] [1:54:25]

56. Kimi 추가 검증은 다음 주로 미뤘다

• Kimi의 첫 결과는 아쉬웠지만, 다음 주에 모든 effort 수준을 시험할 계획이었다. 이번 주에는 급하게 새 평가 영상을 만들기보다 이미 녹화한 영상을 공개하려 했다. [111:27] [1:54:40]
• 준비된 영상은 AI와 모션 그래픽 중심으로, Opus 5.5를 주로 사용하면서 몇 가지 모델을 함께 시험한 내용이었다. 여행과 개인 일정 때문에 방송을 마무리하고 당일 편집을 끝내야 했다. [111:44] [1:54:55]

57. 개인용 HQ는 공개보다 자신의 필요를 우선했다

• HQ는 자신을 위해 만드는 개인용 도구였다. 향후 화이트라벨 제공 가능성을 완전히 닫지는 않았지만, 지금 공개해 다른 사용자를 위한 유지보수까지 맡고 싶지는 않았다. [112:26] [1:55:10]
• 매일 사용하고 있지만 원하는 모습과는 아직 거리가 있었다. 조금씩 개선하고 있으며, 1월쯤에는 개선에 쏟는 비중이 줄어들 수 있다고 예상했지만 시간 부족으로 한 번에 하나씩 진행하고 있었다. [113:08] [1:55:25]

58. 자기 문제를 해결하는 과정이 제품의 출발점이 될 수 있었다

• HQ 공개 자체에 반대하는 것은 아니지만, 너무 이른 공개에는 반대했다. 먼저 자신을 위해 만들고 충분히 발전시키는 일이 우선이었다. [114:17] [1:55:55]
• 가장 열정을 쏟을 수 있는 제품은 자신의 불편을 해결하려고 만든 것일 수 있었다. 그렇게 만든 결과물에서 수익 가능성이나 다른 사람에게 줄 효용을 발견하면 제품으로 발전시킬 수 있다고 봤다. [114:30] [1:56:10]

59. 종료 직전에도 승인 요청이 사라졌는지 확인했다

• 다음 방송은 월요일 같은 시간에 재개할 예정이었다. 주말에는 밖에서 쉬거나 원하는 작업에 집중하며 보내기를 권했다. [116:33] [1:56:40]
• 종료 직전까지 GPT에서는 승인 요청이 한 번도 없었고, Claude 쪽 문제도 해결된 것으로 보였다. 최신 변경에 맞춰 설정을 수정한 것이 효과가 있었다고 판단했다. [117:07] [1:56:55]

🧾 결론

• 이번 IKEA 과제의 관찰은 Kimi의 초기 결과가 아쉬웠다는 판단을 뒷받침하지만, 모델 전체의 우열을 확정할 근거는 부족하다.
• 높은 추론 노력 수준이 항상 더 좋은 결과를 보장하는지는 검증이 필요하다. 동일 과제에서 품질·소요 시간·사용량을 함께 비교해야 한다.
• 실제 개발 생산성에는 모델 성능과 함께 인증, 미리보기, 승인 대기, 모델 간 맥락 인계가 영향을 준다.

📈 투자·시사 포인트

• AI 구독의 효용은 표시 가격뿐 아니라 실제 모델 접근 권한과 사용 한도에 좌우된다. 방송에서는 Google 유료 가입 후에도 원하는 모델에 접근하지 못해 취소와 환불로 이어졌다.
• 업무용 도구를 선택할 때는 결과물의 외형과 기능의 정확성을 따로 확인필요가 있다. 이번 비교에서는 서랍의 실제 동작 같은 구현 세부가 차이를 드러냈다.
• 창업자와 중소기업에는 필요한 수준의 결과를 더 적은 비용으로 얻는 설정이 중요하다. Medium·High로 충분한 과제를 찾는 것이 비교 시리즈의 실용적 목표다.
• 제품 아이디어는 자신의 반복적인 불편을 해결하는 과정에서 출발할 수 있다. 개인용 HQ 사례에서는 공개와 유지보수 확대에 앞서 직접 사용하며 개선하는 접근을 강조했다.

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

• Kimi의 평가는 출시 직후 한 번의 탐색적 시험에 크게 의존한다. 공개 벤치마크 이미지에 대한 기대나 게임·3D 분야 중심의 개선 가능성은 검증된 종합 평가가 아니다.
• Kimi 작업의 정확한 실행 시간은 확인되지 않았다. 방송 중 장시간 대기했다는 관찰과 약 한 시간이라는 추정치를 확정된 측정값으로 취급하면 안 된다.
• 반복 승인 문제는 종료 무렵 개선된 것으로 보였지만, 원인이 된 업데이트와 효과를 낸 정확한 설정은 확정되지 않았다. 여러 변경을 거쳤으므로 단일 원인으로 단정하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 동일한 프롬프트와 과제 조건으로 모델별·추론 노력 수준별 비교표를 만들고, 결과 품질·실행 시간·사용량을 함께 기록한다.
• IKEA 과제에서는 제품과 설명서 출처 확보, 조립 단계의 정확성, 서랍 등 가동 부품의 동작, 브라우저 미리보기 실행 여부를 확인한다.
• 구독 전 원하는 모델의 실제 접근 가능 여부와 사용 한도를 확인하고, 웹·CLI·코드 환경의 사용량이 어떻게 집계되는지 구분한다.
• 반복 승인 문제를 다시 확인할 때는 T3 Code와 Claude Code 버전, 프로젝트 조건, 설정 변경 내용을 기록하고 같은 조건의 GPT 작업과 비교한다.

❓ 열린 질문

• Kimi 3.1 Pro는 추론 노력 수준을 바꾸면 IKEA 과제의 구현 정확성과 업무용 개발 품질이 얼마나 달라질까?
• Medium이나 High로 충분한 과제는 무엇이며, Max를 선택했을 때 추가 비용과 대기 시간을 정당화할 개선이 있을까?
• 반복 승인을 줄인 정확한 설정은 무엇이며, 같은 조건에서 문제가 다시 발생하지 않을까?