Let''s Vibe Code with T3, Ultracode & Fable 5.2

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

T3 Code에서 Ultra Code와 Fable 5.2로 게임 제작을 시도했지만, 결과가 완성되지 않아 추가 비용에 걸맞은 성능인지는 판단을 유보해야 한다.

📌 핵심 요점

1. 실험 과제는 의자 경주 게임 Desk Derby다. 세 가지 트랙, 여덟 레이서, 의자의 무게감과 미끄러짐을 구현하고 모든 모델을 코드로 3D 제작하도록 요구했다.
2. Ultra Code는 추론 수준과 별도로 설정할 수 있다. 앱 업데이트 뒤 독립 토글임을 확인했고, 이번 제작은 High와 Ultra Code를 조합해 시작했다. 후속 모델 비교에는 Extra High와 동일 프롬프트를 적용할 계획이다.
3. Fable 5.2의 비용 대비 효용은 아직 설득력이 부족하다는 개인 평가다. 진행자는 일부 작업의 개선과 빠른 처리를 인정하면서도 Opus 5.5를 주력으로 유지한다. 긴 실행 시간과 추가 에이전트 작업도 비용 부담으로 남았다.
4. 공정한 비교에는 실행 환경과 검증 절차가 필요하다. 렌더링의 하드웨어 병목을 줄이고 같은 앱에서 모델을 비교하려 한다. 구현 뒤에는 검증과 단순화를 거쳐 중복 코드와 실패한 시도의 흔적을 제거하는 방식이 강조됐다.
5. 행사 인터뷰는 에이전트의 활용 범위를 보여 준다. 회의·전화 업무, 개발 작업 전달, 웹훅을 통한 조건부 실행, 빠른 멀티모달 판단, 다중 에이전트 협업이 소개됐다. 작업을 맡기는 범위가 넓어질수록 결과 검증과 사용 모델의 투명성도 중요한 과제로 떠오른다.

🧩 배경과 문제 정의

• Ultra Code와 Fable 5.2로 실제 게임을 만들며 코딩 성능과 사용 경험을 확인하는 것이 출발점이다. 제작 대상은 커뮤니티 의견을 반영해 고른다.
• Fable 5.2의 성능 개선이 추가 비용을 정당화하는지, Ultra Code와 추론 수준을 어떻게 조합해야 하는지가 핵심 판단 문제다.
• 모델 비교에는 실행 환경의 하드웨어 제약이 영향을 주며, 생성된 코드의 품질을 확보하려면 검증과 단순화 작업도 필요하다.

🕒 시간순 섹션별 상세정리

1. 커뮤니티 의견으로 게임 제작 과제 선정

• 실제로 사용할 만한 결과물을 선호하되, 시청자 제안을 받아 함께 토큰을 사용하며 제작 과제를 고른다 [02:17]
• 기존 페인트볼 게임 프롬프트를 개선한 뒤 멀티플레이어 게임으로 확장하는 안을 고려한다. 당일 완성 여부는 불확실하지만 개발을 시작할 수는 있다는 구상이다 [02:44]

2. Desk Derby의 핵심 요구사항은 트랙 다양성과 의자 물리

• Desk Derby는 퇴근 후 사무실 건물에서 바퀴 달린 의자로 경주하는 브라우저 게임이다. 사무실 미로, 주차장 나선 구간, 옥상 장애물 구간의 세 트랙을 각각 랩당 약 1분, 총 세 바퀴로 구성한다 [04:09]
• 여덟 레이서에게 서로 다른 의자와 최고 속도·가속·조향·무게 능력치를 부여하고, 아이템·외형·음악도 독창적으로 만든다 [04:28]

3. Fable 5.2의 추가 비용과 일상 작업에서의 효용

• 진행자의 사용 경험에서는 Fable 5.2의 개선 폭이 크지 않은 데 비해 비용은 더 높아, Opus 5.5가 여전히 주력 모델이다 [05:03]
• Fable 5.2로 Clear Mud HQ의 백엔드와 성능을 소폭 개선했으며 작업 속도도 비교적 빨랐다. 다만 해당 개선은 Opus 5.5로도 가능했을 것이라는 판단이다 [05:42]

4. AI 기술기업 CEO를 등장시키는 3D 경주 게임으로 구체화

• 제작 대상으로 Desk Derby를 선택하고 기존 프롬프트를 사용한다 [07:18]
• 여덟 레이서를 AI 기술기업 CEO로 구성하도록 수정하며 Nvidia, OpenAI, Anthropic, SpaceX, Google 등을 예시로 넣는다 [07:38]

5. Clearbench의 로컬 실행으로 시각적 비교 작업의 병목 완화

• Clearbench는 서버 실행을 유지하면서 로컬 버전도 마련한다. 클라우드 에이전트의 모델 작업과 달리 시각적 데모와 비교 결과의 렌더링은 실행 환경의 자원을 많이 사용한다 [09:11]
• Clear Mud HQ의 해당 가상머신은 메모리 32GB와, 진행자의 기억으로는 16코어를 사용한다. 렌더링 작업이 대기열에 들어가 순차 처리되면서 결과가 나오는 시간이 늘어난다 [09:37]

6. Ultra Code를 추론 수준과 독립적으로 조합할 수 있다는 발견

• 초기 이해에서는 Ultra Code가 높은 추론 수준에 여러 하위 에이전트를 결합한 장시간 작업 기능이므로, 별도 추론 수준으로 보기 어렵다고 판단한다 [10:44]
• 시청자의 정정 이후 T3 Code 업데이트를 확인하고, 빌드를 시작하기 전에 앱을 갱신한다 [11:23]

7. T3 Code에서 High 추론 수준으로 빌드 시작

• 앱은 용도에 따라 선택한다. ChatGPT 앱은 특정 작업에 매일 사용하고, 직접 무언가를 만드는 작업에는 대체로 T3 Code를 사용한다 [14:10]
• Medium과 Extra High 사이에서 고민한 뒤 중간인 High를 선택해 Ultra Code 빌드를 시작한다. Max는 이번 실행에서 선택하지 않는다 [15:15]

8. 높은 추론 수준의 사용량과 리셋 잔여분 점검

• 시청자 설명에 따르면 Max는 Ultra Code와 Fast Mode를 제외해도 사용량이 3.5배이며, 추가 크레딧만 사용한다. 높은 설정에서는 크레딧이 빠르게 소진될 수 있다 [16:59]
• 계정에서 추가로 적립된 리셋을 확인한다. 기존 장기 리셋 하나는 주간 한도 대신 Fable 사용 구간을 초기화하려고 이미 사용한 상태다 [17:32]

9. Clearbench에 추론 수준별 Ultra Code 설정 추가 요청

• Clearbench 개선 작업에는 Opus 5.5의 Extra High 설정을 사용한다 [20:00]
• Claude 모델의 모든 추론 수준에서 Ultra Code를 실행할 수 있도록 Clearbench에 해당 조합을 연결하는 작업을 요청한다 [20:08]

10. 숙련 엔지니어의 경험을 플러그인과 스킬로 전달

• 게임 빌드를 기다리며 시청한 행사 방송에서는, Lauren의 Cursor 플러그인을 사용한 경험이 엔지니어링 역량 향상에 도움이 됐다는 평가가 나온다 [22:01]
• 단순히 에이전트에 요청하는 방식에서 더 나아가, 숙련 엔지니어가 시스템을 만들며 얻은 지식을 스킬로 압축하면 개인 바이브 코더도 그 경험을 작업에 적용할 수 있다 [22:24]

11. 에이전트의 코드 작성 권한과 검증 단계 분리

• 에이전트가 메인 스레드에서 직접 코드를 작성하지 못하도록 스레드를 분리하고, 리뷰 과정에 검증 단계를 두는 작업 방식이 핵심 사례다 [23:39]

12. AI 엔지니어를 독립적인 역할로 보는 관점

• 행사 대화에서는 AI 엔지니어를 기존 소프트웨어 개발과 구분되는 역할 범주로 본다. 프런트엔드와 백엔드처럼 전문 역할이 나뉘는 것에 비유한다 [24:12]
• 이 역할에 대한 개념이 세계 여러 곳에서 열리는 AI 엔지니어 콘퍼런스로 확장됐다는 맥락이 계속된다 [24:29]

13. 작업 완료 후 단순화 요청으로 불필요한 코드 제거

• Lucas의 코딩 에이전트 활용법은 결과를 검증하고, 사람이 검증하기 쉬운 상태로 만드는 단순하고 실용적인 기법에 초점을 둔다 [25:24]
• 에이전트가 구현을 마친 뒤 코드를 단순화하고 실패한 시도의 흔적을 제거하도록 요청하면, 방금 작성한 코드에서도 상당한 불필요 요소를 걷어낼 수 있다 [25:57]

14. Opus 5.5 선호에는 성능과 가격이 함께 작용

• Lucas는 그해 OpenAI 모델을 주로 사용했지만 Opus 5.5 출시 이후 선호 모델이 바뀌었다. Fable 5.2의 품질은 아직 판단하지 못한 상태다 [27:07]
• 다른 대화 참여자는 Fable 5.2와의 비교에서 Opus 5.5가 더 저렴하다는 점을 강조한다. 가격 차이는 모델 선택의 실질적인 기준이다 [28:20]

15. 작은 성능 향상보다 속도와 모델 적응 비용이 중요할 수 있음

• Lucas는 매번 작은 작업이 끝날 때마다 단순화를 지시하지 않아도 되는 수준의 개선을 원한다. 모델 성능 향상 자체에는 여전히 효용이 있다 [29:00]
• 다만 대부분의 작업에서 조금 더 좋은 대신 훨씬 느린 모델을 원하는 것은 아니라는 입장이다. 새 Fable은 아직 직접 시험하지 않았다 [29:15]

16. Opus 성능 저하 주장과 Ultra Code 게임 실험

• Opus 5.5의 성능이 낮아졌다는 주장이 있지만, 매일 사용하는 진행자는 최근 이틀 동안에도 그런 변화를 체감하지 못했다고 드러낸다. 성능 저하 여부는 확인된 사실로 단정하지 않는다 [30:43]
• Ultra Code를 높은 추론 수준으로 실행해 게임을 만드는 중이며, 작업이 오래 걸려 기다리는 동안 Ray Fernando의 행사 현장 방송을 함께 시청한다 [30:50]

17. Carbon의 창의성과 업무 신뢰도는 별개다

• Carbon은 비용 측면에서 호평받지만, 게임 생성 비교에서는 Opus나 Fable 같은 모델에 아직 못 미친다는 평가다. PRD와 Blender 등의 도구로 준비한 자산이 있으면 결과가 달라질 가능성은 있으나, 그 조건은 시험하지 않았다 [31:40]
• 세 가지 실제 제작 과제에서는 모션 그래픽과 영상 생성 결과가 인상적이었다. 아이디어 발상과 영상 제작에 활용해 기존 작업에 새로운 관점을 얻으려 한다 [31:58]

18. 추론 수준과 에이전트 실행 환경을 함께 비교한다

• 모든 추론 수준을 비교하는 테스트 형식을 지속하고, 게임뿐 아니라 중소기업의 실용적인 업무 사례로 평가 범위를 넓힐 계획이다 [33:25]
• 개발 중인 ‘agent bench’는 격리된 에이전트 실행 환경에서 새 모델과 각 추론 수준을 시험하는 도구다. 현재 PI로 만들고 있으며, Hermes와 OpenClaw도 서버에 추가하는 방안을 검토한다 [33:52]

19. 영상 게시 일정과 올리브 수확기의 운영 조정

• 화·수·목요일에는 영상을 게시하고 월·금요일에는 라이브 방송을 하는 일정을 유지하고 싶어 한다. 이 일정이면 화·목요일에 시간이 겹치던 Ray의 방송도 시청할 수 있다 [34:26]
• 올리브 수확은 약 5~7일이 걸릴 것으로 예상한다. 노동 강도를 고려해 해당 기간에는 긴 형식의 영상만 게시하고 라이브 방송은 쉬는 방향을 생각한다 [34:59]

20. Desk Derby의 제작 조건과 패러디 캐릭터 구성

• 제작 중인 Desk Derby는 Mario Kart를 재해석한 카트 레이싱 게임이며, Ultra Code의 높은 추론 수준을 사용한다 [35:18]
• 일부 테스트에서 확인한 창의성을 바탕으로 Carbon과 Argon도 아이디어 발상에 활용하려 한다. 한 모델의 제안에만 의존하지 않으려는 목적이다 [35:58]

21. 모델과 추론 수준을 바꾸는 데에도 평가 비용이 든다

• 현장 대화에서는 새 모델을 쓰기 시작하는 일 자체가 상당한 투입을 요구한다는 의견이 나온다. 여러 추론 수준까지 비교해야 하므로 기본값인 Opus 5.5의 medium을 계속 사용한다는 선택이다 [38:12]
• medium이 low보다 좋은지, high보다 나쁜지는 직접 비교하지 않아 알 수 없다고 드러낸다. high를 시험하려면 별도의 평가 과정이 필요하다는 점이 변경의 부담이다 [38:24]

22. 최신 정보를 공유하는 참가자들이 대화의 깊이를 높인다

• 행사 참가자들이 서로 비슷한 수준으로 최신 동향을 알고 있어, 대화가 앞선 논의를 토대로 계속 발전한다는 평가다. 일반적인 만남에서 상대의 이해 수준부터 파악해야 하는 상황과 차이가 있다 [41:47]
• 참가자 구성이 사실상 선별됐다는 점도 높은 대화 수준의 배경으로 거론된다 [41:55]

23. 완료된 스크립트의 응답 대기가 새 작업에 다시 나타난다

• Clear OS에서 새 스크립트를 시작했는데, 이미 파이프라인 처리를 마친 이전 스크립트의 답변을 기다린다는 상태가 표시되는 버그를 발견한다 [42:28]
• 해당 작업은 패키징까지 끝난 상태였으므로, 완료된 작업이 대기 대상으로 다시 나타나는 것이 문제다. 수정은 요청했지만 이 시점에는 원인이나 해결 결과가 확인되지 않는다 [43:01]

24. 게임 제작에서는 개별 메커니즘을 이해하려는 요구가 크다

• 게임 설계는 각 메커니즘을 세밀하게 이해하고 싶다는 점에서 다른 작업과 차이가 있다는 견해다 [43:08]
• 개발 중인 게임은 Avatar, Smash Brothers, Brawl Stars 등에서 영감을 받은 원소 기반 대전 게임이다. 현재는 개인 컴퓨터 안에서 실행되며, 향후 공개를 희망하지만 아직 이름도 정하지 않았다 [43:50]

25. 아이디어부터 실제 배포까지 연결하는 제작 가이드

• 아이디어 발상과 프로토타입 제작 단계에서 현재 어떤 모델을 사용하는지, 이후 실제 서비스로 배포하려면 어떤 절차가 필요한지를 묶은 영상을 구상한다 [44:36]
• 커스텀 도메인과 DNS 설정까지 포함할 예정이며, 가능하면 이달에 촬영해 연휴 전에 공개하려 한다 [44:53]

26. 봇의 회의 참여가 기록에서 업무 실행으로 확장된다

• Matt Palmer는 봇 서비스가 당일 1.0을 출시해 정식으로 베타를 벗어났으며, Google Meet 회의에 참여할 수 있다고 드러낸다 [46:06]
• 회의에 들어온 봇은 채팅에서 지시를 받아 Notion을 확인하거나 백그라운드 작업을 수행하고 필요한 정보를 가져올 수 있다. Zoom 지원 여부는 이 대화에서 명확히 확정하지 않는다 [46:41]

27. 전화 에이전트가 예약 변경과 대기 시간을 대신 처리한다

• 전주에 추가된 전화 기능은 보험사 연결 대기, 병원 전화, 꽃 주문 등에 활용할 수 있다. 전화 안내에 맞춰 버튼을 누르고, 통화 중 실시간 전사도 확인할 수 있다 [47:20]
• 온라인으로 예약은 가능하지만 변경하려면 전화해야 하는 서비스가 구체적인 활용 사례다. 웹에서 끝낼 수 없는 후속 절차를 에이전트가 이어서 처리하는 방식이다 [47:55]

28. 작업별 모델 라우팅의 세부 기준은 공개되지 않는다

• Opus 5.5 사용과 모델 전환 방식에 대한 질문에, 서비스는 여러 모델을 섞어 작업별로 적합한 모델에 요청을 배분한다고 답한다 [48:52]
• 구체적인 라우팅 방식은 공개하지 않는다. 사용자는 여러 모델이 활용된다는 점은 알 수 있지만, 내부 선택 규칙까지 확인할 수 있는 것은 아니다 [49:08]

29. 공유 봇과 선제적 행동으로 AI 동료를 지향한다

• 1.0에 포함된 팀 봇은 Teams와 Enterprise 버전에서 봇을 만들어 다른 사람과 공유하는 기능이다. 여러 사람이 AI와 함께 협업하는 경험을 발전시키려 한다 [49:46]
• 소셜 게시물 작성 절차를 봇에 담고 MCP 서버를 연결한 뒤 팀 전체와 공유하거나 Slack에 넣을 수 있다. 팀원이 같은 봇에 게시물 예약을 요청하는 방식으로 개인의 작업 절차를 공동 도구로 만든다 [50:16]

30. 개인 에이전트를 개발 작업의 오케스트레이터로 쓴다

• 개인 에이전트의 변화가 AI 엔지니어들에게 충분히 주목받지 못한다는 문제의식이 나온다. 엔지니어가 봇으로 클라우드 에이전트를 실행하고 MCP 서버나 API를 연결하는 활용도 가능하다 [51:49]
• 별도 에이전트를 계속 추가하면 직접 관리할 문제도 늘어날 수 있다는 지적이 있다. 관리형 봇에 플러그인과 도구를 연결하고, 필요하면 다른 코딩 실행 환경을 함께 쓰는 방식이 대안이다 [53:21]

31. 사설망 연결로 로컬 도구와 홈 네트워크에 접근한다

• Tailscale 연동은 공개 인터넷에 노출하지 않은 도구를 봇이 사용할 수 있게 한다. 집의 Mac mini 등에서 MCP 서버를 실행하고 봇에 Tailscale 플러그인을 추가하면 해당 서버에 연결할 수 있다 [55:04]
• 로컬 기기를 출구 노드로 사용해 트래픽을 그 기기로 보내는 기능도 다룬다. 웹사이트 접근이 막혔을 때 사용할 수 있는 방법으로 제시되며, 제품에서는 ‘이 기기로 트래픽 라우팅’이라는 표현을 쓴다 [55:55]

32. 웹훅으로 필요한 순간에만 봇을 깨워 비용을 줄인다

• 매분 실행하는 루틴은 매번 봇을 깨워 토큰을 소비한다. 사용량이 높다면 지나치게 잦은 반복 실행이 원인일 수 있으며, 사용량 분석 기능은 아직 개발 중이다 [57:09]
• Linear에서 변화가 생길 때 웹훅으로 봇을 깨우면, 봇이 계속 상태를 확인할 필요가 없다. 실제 사용자도 이 방식으로 비용이 크게 줄었다고 말하며, 각 봇의 웹훅 URL을 Linear나 에이전트, 클라우드 작업에 연결할 수 있다 [57:58]

33. Firecrawl 부스의 게임 체험으로 현장 탐방을 이어간다

• 인터뷰를 마친 뒤 Firecrawl 부스의 작은 아케이드 게임을 체험하러 이동한다 [59:38]
• 게임을 하는 동안 Firecrawl에 대한 설명도 듣기로 한다. 처리 구간 끝까지는 구체적인 제품 기능이나 체험 결과가 나오지 않는다 [59:51]

34. Firecrawl이 에이전트의 데이터 탐색을 대신하는 방식

• 인형 뽑기에서 원하는 AirPods를 얻으려는 시도는 에이전트의 인터넷 탐색에 비유된다. 직접 탐색하면 필요한 정보를 찾을 수도, 놓칠 수도 있지만, Firecrawl은 특정 용도에 필요한 데이터를 공급하는 역할을 맡는다. [1:00:23]

35. PR 검토 자동화의 확대와 모델 투명성 요구

• Grockbot에는 각 턴에서 어떤 모델을 사용하는지 확인할 수 있는 투명성이 필요하다는 요구가 나온다. [1:02:08]
• 일부 팀은 PR 검토 자동화에 더 많은 판단을 맡기기 시작했으며, 위험이 낮은 변경에는 자동 승인을 적용하는 사례도 있다. [1:02:16]

36. OpenAI 부스의 Codex 기념품과 게임 제작 접점

• OpenAI 부스는 토트백과 스티커를 제공하고, 추첨 경품으로 소형 Codex 키보드를 마련했다. [1:03:03]
• Dev Day에서 제공한 ModRetro의 맞춤형 Game Boy는 직접 게임을 만들어 보고 싶은 동기로 계속된다. 다만 진행자는 아직 게임을 제작하지 않았다고 드러낸다. [1:03:25]

37. 대규모 토큰 사용자를 위한 전용 라운지

• Cognition·Devin이 후원하는 Token Billionaires Lounge는 하루 약 10억 토큰을 사용하는 사람에게 골든카드를 제공하는 공간으로 묶인다. 사용량 기준은 확정적인 규정이 아니라 현장에서 설명한 대략적인 조건이다. [1:04:34]

38. 매일 발행하는 행사 신문 Daily Context

• Major League Hacking의 Daily Context는 행사장에서 실물 신문 형태로 제공되며, 매일 새로운 기사가 나온다. 강연 외에도 읽을거리와 행사 정보를 접할 수 있는 접점이다. [1:05:09]
• 신문에는 에이전트의 오류와 시스템 책임, 생성형 앱의 외형 유사성 같은 주제뿐 아니라 기고 신청, 애프터파티, 분실물 정보도 함께 담긴다. [1:05:35]

39. Gemini Decision의 멀티모달 입력과 처리 성능

• Phil Smith는 이날 Gemini Decision 모델과 새로운 Decisions API를 출시했다고 드러낸다. 텍스트·이미지·영상·오디오를 지원하며, 재무 자료나 청구서 PDF를 직접 넣고 질문하는 용도도 가능하다. [1:07:12]
• 가격은 100만 토큰당 약 10센트로 드러난다. 이 대화에서는 입력과 출력에 따른 별도 요금 구분까지 설명하지 않는다. [1:07:55]

40. 생태계 연동과 안전성 판단에 적합한 활용처

• 출시 시점에 생태계 파트너 7곳을 확보했고 OpenRouter에서도 사용할 수 있다. Cloudflare의 관련 모델 제공 여부는 대화 참여자들도 확신하지 못해 확인 과제로 남는다. [1:09:01]
• 주요 활용처는 정해진 입력에 대해 빠르고 보정된 판단이 필요한 분류 작업이다. 내부 사용 사례로 Stitch의 실시간 와이어프레임 기능과 검색 도구 선택이 언급되며, 에이전트의 도구 호출 실행 여부를 판단하는 안전장치도 적합한 예다. [1:10:03]

41. 낮은 지연 시간과 개발 친화적인 API

• 현재 관측한 종단 간 지연 시간은 최대 16,000토큰 입력에서 약 150~250밀리초다. 여러 질문을 같은 순전파에서 처리하므로 질문이 하나일 때와 열 개일 때 지연 시간이 같다는 설명이며, 추가 지연 개선도 계획하고 있다. [1:11:34]
• API는 Interactions API에 기반한 REST 방식이다. 멀티모달 입력 필드와 질문별 선택·점수 등의 구조를 제공해 기존 판단 모델 API에서 옮겨오기 쉽게 구성했다. [1:12:05]

42. Carbon의 성능 호평과 개발자 신뢰 회복 과제

• 일부 사용자는 Carbon이 Fable에 근접하거나 자신에게는 더 낫다고 평가한다. 다만 이는 진행자가 접한 사용자 평가이며, Phil도 개발자를 다시 확보하려면 아직 할 일이 많다고 인정한다. [1:13:14]
• Carbon은 Gemini Decisions API 개발과 출시 자료 제작에 내부적으로 활용됐다. 좋은 모델 하나의 출시만으로 개발자가 돌아오는 것은 아니므로, 활용 사례를 꾸준히 보여 주고 체험과 피드백을 늘려야 한다는 입장이다. [1:14:04]

43. Swarm의 동등한 에이전트 협업 구조

• Antigravity의 새 다중 에이전트 기능은 중앙 조정자가 하위 에이전트에게 작업을 배분하는 구조 대신, 동등한 에이전트들이 전용 메시지 보드에서 서로 태그하고 소통하는 방식을 사용한다. 각 에이전트에는 검증자·테스터 등의 역할이 주어진다. [1:15:48]
• 시연 사례에서는 수백~수천 개 에이전트가 밤사이 런던 사무실을 Blender로 재현하고 렌더링했다. 깊게 탐색해야 하는 연구나 보안 작업도 유망한 활용처로 드러난다. [1:16:35]

44. 라운지의 맞춤 제작·촬영·휴식 서비스

• 라운지는 무료 피부 관리, 마사지, 이발 서비스를 제공한다. 현장에서 이발 가능 시간을 확인하고 예약하는 모습도 나온다. [1:18:02]
• 이동식 자수 장비에서는 준비된 물품을 고르고 요청 사항과 실 색상을 지정하면 약 30분 뒤 완성품을 받을 수 있다. 이어 전문 프로필 사진 촬영도 이용한다. [1:18:43]

45. Cognition의 라운지 운영과 Devin 체험 유도

• 라운지 담당자인 Matt는 마사지·이발·헤어 스타일링과 프로필 촬영을 함께 이용할 수 있다고 보여준다. 음식도 별도로 제공되지만, 미쉐린 수준이라는 진행자의 표현은 Matt가 확인하지 않는다. [1:23:14]
• Cognition에는 흥미로운 변화가 예정돼 있다는 예고가 나오지만, 구체적인 내용은 공개되지 않는다. 공개 시점도 “아마 일주일 뒤” 정도로만 나온다. [1:24:00]

46. 초기 엔지니어에게 비공식 교류가 주는 가치

• Monaco의 초기 엔지니어인 참가자는 동료의 발표를 지원하러 왔으며, 개인적으로도 같은 분야의 사람들을 만나고 업계에서 일어나는 일을 파악하는 데 행사의 가치가 있다고 평가한다. [1:25:11]

47. 개발자 관계의 수요와 생태계를 넘는 아이디어 교류

• 진행자는 AI 기업에 현장 배치 엔지니어뿐 아니라 제품 사용법을 대중에게 전달하는 개발자 관계 역할도 필요하다고 본다. Kent는 관심을 확보하는 일이 중요하다는 말로 호응한다. [1:26:32]
• Kent는 콘퍼런스의 성격이 주최자를 반영한다고 보며, AI Engineer의 분위기를 긍정적으로 평가한다. AI를 매개로 JavaScript, 프런트엔드, 백엔드, iOS, 저수준 라이브러리 개발자들이 한자리에 모이면서 서로의 아이디어를 교환할 기회가 생긴다. [1:26:58]

48. 빠르게 바뀌는 개발 지식과 소프트웨어 팩토리

• 기존 개발 진영의 구분이 중요성을 잃으면서 무엇이 핵심인지 다시 배워야 하며, 지금 중요한 지식도 석 달 뒤에는 중요하지 않을 수 있다 [1:28:07]
• 소프트웨어 팩토리는 입력을 받아 소프트웨어를 생성하는 체계로 정의된다 [1:28:35]

49. SaaS를 넘어 실제 문제를 해결하는 비즈니스 엔진

• 기업은 소프트웨어만으로 구성되지 않으므로, 소프트웨어 팩토리 다음 단계는 사업 전체를 다루는 ‘비즈니스 엔진’이 될 수 있다는 전망이다. 대형 기업의 범용 에이전트가 기존 기능을 흡수하면 SaaS만 제공하는 기업의 안전지대는 줄어든다 [1:29:13]
• 사용자가 원하는 것은 소프트웨어 제작 자체보다 문제 해결이다. 에이전트가 해결 방법을 판단하고 필요한 소프트웨어까지 만들어 주는 방향이 지향점이다 [1:29:36]

50. 에이전트 집단의 결과를 검증하는 문제

• 여러 에이전트가 소프트웨어 팩토리에서 일할 때는 작업 수행 여부뿐 아니라 올바른 일을 수행하는지 검증해야 한다. 형식 검증이 에이전트에 어떤 의미를 갖는지도 아직 탐색 중인 문제다 [1:30:10]

51. 에이전트의 작동 여부에서 활용 방식으로 이동하는 관심

• AIE 같은 모임은 사람들이 아이디어를 교환하고 반년이나 일 년 뒤 달라진 인식을 확인하는 장이다. 2024년의 “에이전트는 작동하지 않는다”는 대화가 2025년에는 “아직 작동하지 않는다”로 바뀌었고, 현재는 작동 자체가 분명해졌다는 평가다 [1:31:25]

52. 완성 지연과 에이전트별 독립 세션

• 예정된 통화 준비 때문에 방송 시간이 제한되어 있지만 완성 결과는 아직 나오지 않았다. 작업을 계속 실행하고 다음 방송에서 결과를 확인하는 방안이 고려된다 [1:33:09]
• 부모 세션이 총 여덟 에이전트를 구성했으며, 당시 네 개는 작업 중이고 네 개는 완료 상태다. 각 에이전트가 별도 세션을 시작하므로 아직 자동 압축이 필요하지 않았다는 설명이다 [1:33:34]

53. 페인트볼 게임으로 두 모델을 비교하는 후속 실험

• 후속 영상은 페인트볼 1인칭 슈팅 게임을 과제로 삼아 Opus와 Fable 5.2를 비교하는 구상이다. Ultra Code와 Extra High 옵션을 활용해 성능을 확인하려 한다 [1:37:30]
• 처음에는 세션을 나란히 배치할 수 없다고 판단해 데스크톱 앱과 T3 Code를 각각 사용할 계획이었다. 녹화에는 세 시간 이상 걸릴 수도 있다고 예상한다 [1:37:56]

54. 기존 콘텐츠의 이모지 선택기 오류

• 새 콘텐츠에서는 이모지 선택 토글이 작동하지만, 이미 생성된 영상의 이모지를 왼쪽 클릭하면 선택 창이 열리지 않는다. 기존 이모지를 지우고 오른쪽 클릭 메뉴를 이용해야 하는 불편이 있다 [1:39:17]
• 기존 콘텐츠에도 같은 드롭다운 선택기를 제공하도록 수정 요청을 작성하고 스크린샷을 첨부하려 한다. 요청은 나중에 전송할 상태로 남겨 둔다 [1:39:27]

55. Code 화면의 분할 기능으로 비교 조건 개선

• 직접 확인한 결과, Code 화면에서는 세션을 시작한 뒤 다른 세션을 끌어와 나란히 배치할 수 있다. 같은 방식은 Chat 화면에서 작동하지 않았다 [101:00] [1:43:09]
• 이 기능을 활용해 두 모델을 Claude Code 데스크톱 앱 안에서 비교하는 방향으로 계획을 바꾼다. 서로 다른 앱에서 실행하면 비교가 공정하지 않다는 지적이 가능하다는 점도 인정한다 [101:27] [1:43:24]

56. 모델별 작업 폴더와 실행 환경 준비

• Opus와 Fable용 작업 폴더를 준비하면서 각 모델이 선택한 디렉터리 안에서만 작업하도록 프롬프트에 명시할지 검토한다. 상위 경로의 다른 디렉터리까지 탐색할 가능성을 염두에 둔 조치다 [103:03] [1:44:02]
• 별도 폴더를 각 세션에 연결하고 모델과 실행 옵션을 설정해 후속 비교용 작업 공간을 준비한다 [105:24] [1:44:59]

57. 게임의 작동 방식을 설명하고 동일한 과제로 비교

• Roblox와 비슷한 것을 만들더라도 단순히 복제를 요구하기보다, 먼저 작동 방식을 살펴보고 이를 설명할 수 있게 된 뒤 자체 버전을 만드는 접근을 택한다 [106:58] [1:45:56]
• 비교 과제는 자신이 좋아하는 페인트볼 게임으로 유지한다. Ultra Code의 Extra High 조건에서 Fable 5.2와 Opus 5.5에 같은 프롬프트를 적용할 계획이다 [107:52] [1:47:43]

58. 핵심 에이전트 완료 뒤에도 이어지는 작업과 비용 부담

• T3에서 핵심 에이전트들은 모두 완료됐지만 추가 에이전트 세 개가 작업 중이다. 이후에도 작업이 얼마나 더 추가될지는 알 수 없는 상태다 [108:48] [1:47:49]
• Opus 5.5와 비교하면 비용이 지나치게 높다는 평가에도 동의하며, 긴 실행 시간과 함께 비용 부담이 쟁점으로 남는다 [109:05] [1:48:46]

59. GitHub 대체가 보여 주는 소프트웨어 사업의 난점

• 소프트웨어가 죽었다는 주장과 GitHub에 대한 불만이 함께 나온다면, 왜 이를 대체하는 서비스가 시장을 차지하지 못했는지가 반론이 된다. 이 간극은 소프트웨어의 가치가 사라졌다는 주장에 의문을 제기한다 [109:34] [1:49:43]
• GitHub 대안들은 존재하지만 시장 점유율과 관심을 압도적으로 가져간 서비스는 아직 없다는 판단이다. GitHub의 문제가 늘어날수록 경쟁자에게 기회가 커질 수 있다는 전망도 따른다 [110:02] [1:49:48]

60. 미완성 결과의 후속 확인과 방송 일정의 불확실성

• 통화 준비 때문에 방송을 종료하고 결과는 다음 방송에서 확인하려 한다. 작업을 계속 실행할지, 사용량을 아끼기 위해 일시 중지하거나 중단할지는 아직 결정되지 않았다 [110:58] [1:51:36]
• 금요일 생방송은 없으며, 화·수·목에 긴 영상을 게시하고 월·금에 생방송을 진행하는 편성을 선호한다. 다음 주에는 수확 작업으로 매일 농장에 있을 예정이라 저녁 체력에 따라 방송 가능 여부가 달라질 수 있다 [112:04] [1:52:14]

🧾 결론

• 이번 방송은 완성된 게임의 품질 비교보다 제작 과정과 설정 선택을 관찰한 기록이다. 종료 시점까지 결과가 나오지 않았으므로 모델의 우열을 확정할 수 없다.
• 모델 선택에는 출력 품질뿐 아니라 가격, 대기 시간, 사용량, 새로운 모델에 익숙해지는 비용이 함께 작용한다.
• 에이전트가 구현을 마쳤다는 보고만으로 품질을 보장할 수는 없다. 검증 가능한 결과와 사람이 이해하기 쉬운 코드가 필요하다.
• 후속 비교는 같은 과제·프롬프트·앱·실행 옵션을 맞추는 방향으로 준비됐다. 실제 결과와 비용을 확인해야 이번 실험의 판단을 보완할 수 있다.

📈 투자·시사 포인트

• 고성능 모델의 가격 프리미엄에는 실용적인 근거가 필요하다. 일상 작업의 작은 품질 차이보다 처리 속도와 총비용이 사용자의 선택에 더 크게 작용할 수 있다는 사례다.
• 에이전트 제품의 가치는 업무 연결에서도 나온다. 회의, 전화, 협업 도구, 로컬 서버와 개발 환경을 이어 실제 작업을 끝내는 능력이 제품 평가 기준으로 제시된다.
• 실행 방식도 운영 비용을 좌우한다. 반복적으로 상태를 확인하는 대신 이벤트가 발생할 때 웹훅으로 실행하는 구조는 비용 절감 사례로 소개됐다. 절감 폭은 실제 사용 조건에서 확인해야 한다.
• SaaS의 경쟁력에 관한 전망은 양면적이다. 범용 에이전트가 기존 기능을 흡수할 수 있다는 우려와 함께, GitHub 대체 서비스가 시장을 장악하지 못했다는 반론도 나온다. 소프트웨어 생성 능력만으로 사업의 경쟁력을 판단하기 어렵다는 시사점이다.

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

• Desk Derby는 방송 종료까지 완성 결과가 공개되지 않았다. 플레이 가능 여부, 물리 구현의 품질, 최종 실행 시간과 총비용은 확인되지 않았다.
• Fable 5.2와 Opus 5.5에 대한 평가는 개인 경험과 행사 대화에 기반한다. 동일 조건의 후속 비교는 계획 단계이며, Opus의 성능 저하 주장도 확인된 사실이 아니다.
• Max의 사용량 3.5배 설명은 시청자 발언이다. 실제 요금과 크레딧 적용 조건은 별도 확인이 필요하며, 이번 High 실행의 비용으로 대입할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Desk Derby의 후속 결과에서 실행 가능 여부, 트랙과 의자 물리의 구현 상태, 실제 플레이 품질을 확인한다.
• Fable과 Opus 비교 시 같은 프롬프트·앱·추론 수준·Ultra Code 설정을 맞추고, 작업 폴더를 분리한다.
• 모델별 완료 시간, 사용량과 비용, 검증 뒤 남은 결함을 함께 기록해 추가 비용의 효용을 판단한다.
• 구현 완료 뒤 작동을 검증하고, 중복 구현과 실패한 시도의 흔적을 제거하도록 단순화를 요청한다.

❓ 열린 질문

• Fable 5.2와 Ultra Code의 조합은 어떤 종류의 작업에서 추가 비용과 대기 시간을 상쇄할 만큼 결과를 개선하는가?
• 추론 수준과 Ultra Code 사용 여부를 각각 바꾸면 품질·시간·비용에 어떤 차이가 생기는가?
• 핵심 에이전트가 완료된 뒤 추가 작업이 이어질 때, 종료 조건과 예산을 어떻게 정해야 하는가?