Building a Multiplayer Game LIVE

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Building a Multiplayer Game LIVE를 중심으로, Agent Circuit은 에이전트 하네스를 레이서로 삼는 브라우저 레이싱 게임이다. 마리오 카트의 게임 구조를 참고하면서 별도의를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. Agent Circuit은 에이전트 하네스를 레이서로 삼는 브라우저 레이싱 게임이다. 마리오 카트의 게임 구조를 참고하면서 별도의 캐릭터와 세계를 구상하고, 시청자들과 함께 경주하는 것을 목표로 한다.
2. 초기 구현은 Opus 5.5가 맡고, Fable과 Astra에는 같은 프롬프트로 캐릭터와 렌더링 작업을 요청했다. 이후 Astra의 콘셉트를 더 선호해 게임용 3D 제작을 맡겼지만, 방송 말미에는 렌더링 품질 저하와 결과물 훼손이 드러났다.
3. 직접 플레이하면서 요구사항이 구체화됐다. 단축키 안내와 드리프트는 개선됐으나 부스트 조작은 여전히 직관적이지 않았고, 충돌 전투·트랙 아이템·코스 효과는 추가 구현 대상으로 남았다. 물리 구현 방식도 확정되지 않았다.
4. 그래픽은 툰 셰이딩과 사실적인 재질을 섞는 방향으로 조정했고, Silicon Valley 테마 맵을 진행했다. 브라우저 실행과 낮은 호스팅 비용을 조건으로 삼았으나, 실제 멀티플레이 지원과 배포 결과는 확인되지 않았다.
5. 개발을 기다리는 동안 모델과 하네스의 역할, 구독 비용, 도구 전환 방식도 검토했다. 다른 프로젝트에서는 구현과 보안 감사를 서로 다른 모델에 맡겼으며, 새 도구는 일부 작업에 먼저 적용하고 구독 업그레이드는 실제 사용 경험을 확인한 뒤 판단하려 했다.

🧩 배경과 문제 정의

• 처음 시도하는 멀티플레이어 레이싱 게임 ‘Agent Circuit’은 사실적인 3D 그래픽을 목표로 한다. 마리오 카트의 게임 구상을 참고하되, 저작권이 있는 캐릭터 대신 에이전트 하네스를 레이서로 활용한다.
• 금요일에 시청자들과 함께 경주하려면 로컬에서 작동을 검증하고 호스팅까지 마련해야 한다. 브라우저 기반 프로토타입부터 시작하지만, 다른 레이서가 트랙에 보이는지는 자막만으로 확정되지 않는다.
• Opus 5.5가 구현을 진행하는 동안 Fable과 Astra의 게임용 3D 렌더링 결과를 비교하려 한다. 이 처리 구간에서는 완성된 게임이나 렌더링 결과가 확인되지 않는다.
• 개발을 기다리는 동안 모델별 역할, 하네스 사용 경험, 구독 비용, 원격 개발 도구와 디자인 스킬을 검토한다. 개인적인 사용 평가와 향후 계획은 확정된 제품 성능이나 실행 결과와 구분해야 한다.

🕒 시간순 섹션별 상세정리

1. 에이전트 하네스를 레이서로 삼는 Agent Circuit 구상

• 라이브 방송 중 비밀 정보가 노출될 가능성을 고려하면서, 마리오 카트를 사실적인 3D 스타일로 재해석하려 한다. 저작권이 있는 마리오 세계와 캐릭터 대신 ‘Agent Circuit’이라는 별도 게임을 구상한다 [01:14]
• 레이서는 OpenClaw, Hermes Agent, Buzz, Crockbots, Dots, Pi, Muse 등 서로 다른 에이전트 하네스를 대표하도록 구성하고, 후보 목록을 확장하려 한다 [01:40]

2. Opus 중심 구현과 브라우저 프로토타입의 범위

• 초기 구현은 Opus 5.5만으로 시작한다. 이후 Astra나 Soul을 활용할 가능성은 열어 두지만, 아직 결정된 작업 분담은 없다 [05:01]
• 레이서 목록에서 Google, DeepSeek, Open Code, Codex를 제외하고 나머지를 유지한다. 브라우저 우선 접근에 동의하며, 더 넓은 후보 목록은 나중에 해금할 레이서로 활용할 수 있다고 본다 [07:23]

3. Fable과 Astra의 게임용 3D 렌더링 비교

• Opus의 첫 구현 결과를 기다린 뒤 다음 작업을 판단하려 한다. 3D 렌더링에는 Fable이나 Astra가 더 적합할 수 있다는 예상이 있지만, 아직 비교 결과는 없다 [09:57]
• Fable의 extra high 설정에 코드베이스와 레이서 구성을 분석하고 게임에서 사용할 3D 렌더를 만들도록 요청한다. 여러 모델의 결과를 시험한 뒤 선택하려는 방식이다 [12:15]

4. Codex 개선 약속과 Dev Day에 대한 추측

• 인용된 Codex 계획은 향후 28일 안에 대부분의 Codex Work 사용자에게 유의미한 개선을 제공하거나 전면 재설정을 추진한다는 내용이다. 개선 항목에는 단순화, 사용량 확대를 위한 효율 개선, 새 모델의 기능이 포함된다 [14:24]
• 이 계획이 Dev Day에 대한 피드백을 반영한 것일 수 있다고 추측한다. Dev Day가 기대대로 진행되지 않았다는 해석도 추측의 수준에 머문다 [14:34]

5. Dots의 우회책과 하네스별 활용 범위

• Dots 사용 중 일부 장애물을 발견했지만 우회책도 찾았다. 다만 도구가 우회책을 스스로 찾아주지 못한 점에는 아쉬움이 있으며, 관련 영상은 이번 주에 공개할 가능성이 있다 [15:05]
• Buzz는 협업 용도로 사용한다. OpenClaw나 Hermes, Crockbot이 맡은 일부 책임을 대체하는 용도로는 쓰지 않는다 [15:25]

6. 모델별 역할 분담과 다른 모델을 통한 보안 감사

• Muddy는 Astra를 유지하고 있으며 Soul 6.1로 옮기지 않았다. Soul 6.1의 medium 설정은 에이전트 작업에서 효과적이고 효율적이며 저렴하다고 평가하지만, 오케스트레이터 역할에는 여전히 Astra를 주로 사용한다 [16:40]
• 주말에 만든 판타지 풋볼 관련 작업은 Opus 5.5로 구현하고 Astra로 보안 감사를 수행했다. 하나의 모델에 구현부터 출시까지 전부 맡기지 않는 방식을 권한다 [17:07]

7. Hermes 데스크톱 UI 변화와 에이전트 구성 축소

• Hermes 데스크톱 앱의 에이전트 선택 방식이 팝업 형태에서 좌우로 스크롤하는 메뉴로 돌아간 점을 불편하게 느낀다 [18:01]
• 에이전트 구성은 기본 에이전트, Neo, Architect, Morpheus, Baker로 줄였다. 직접 요청하는 대상은 Neo와 Morpheus이며, Baker는 테스트와 다른 관점의 검토를 위해 남겨 둔다 [18:35]

8. 모델 교체가 가능한 구성과 로컬 하드웨어의 한계

• 자신이 만드는 시스템은 모델을 바꿔도 기존처럼 작동하도록 구성한다. 모델에 따라 에이전트의 행동은 조금 달라질 수 있다고 인정한다 [21:47]
• 보유한 장비로 일부 로컬 모델을 실행할 수는 있지만, 원하는 작업을 수행하기에는 성능이 부족하다고 본다. 충분히 강력한 서버를 마련할 예산이 생길 때까지 여러 구독을 오가며 운영한다 [22:15]

9. 월 500달러 구독 전환을 미루는 이유

• 현재 월 200달러 요금제 두 개를 사용하며, 하나를 월 500달러로 올리면 월말까지 유지되는 기존 혜택을 포기하게 된다고 이해한다 [22:53]
• 업그레이드가 필요하더라도 11월에 변경된 월 200달러 요금제를 최소 일주일 시험한 뒤 판단하려 한다. 월 500달러 요금제로의 전환 가능성은 남아 있지만 확정하지 않았다 [23:13]

10. T3 Code의 활용 확대와 단계적인 도구 전환

• 이전에는 Codex와 Claude의 CLI를 cmox와 함께 주로 사용했지만, 최근에는 T3 Code를 기본 도구로 선택하는 경우가 늘었다. 원하는 작은 기능들이 있으나 직접 포크할 정도의 필요는 느끼지 않는다 [24:02]
• T3 Code 호스트를 마련해 개인적으로 먼저 시험하려 한다. 고객 서버에서는 SSH로 기존 작업을 이어갈 수 있는 Herder를 계속 사용하며, T3 Code가 이를 대체할 가능성을 검토한다 [24:31]

11. 정교하게 조정된 시스템에서 줄어드는 모델 의존성

• 모델마다 행동은 다르지만, 시스템이 충분히 정교하게 조정되어 있으면 모델 선택의 영향이 이전보다 작아진다고 평가한다. 이는 자신의 사용 경험에 따른 판단이다 [25:43]
• 1월에는 모델 차이가 더 중요했으나 약 10개월 동안 상당한 변화가 있었다고 본다. Open Code와 T3 Code를 통해 모델을 쉽게 오가는 사용 경험도 긍정적으로 평가한다 [26:02]

12. 서버 정리와 오래된 프런트엔드 스킬 개선

• 주말에 OpenClaw 서버를 정리하면서 저장 공간을 확보하고 사용하지 않는 오래된 워크플로를 제거했다. 기존 스킬도 다시 정비하고 있다 [26:42]
• 에이전트가 로컬 프로젝트 디렉터리 밖의 Clear Mud 작업에서 오래된 프런트엔드 디자인 스킬을 참조하는 문제가 있었다. 스킬을 모두 삭제하고 새로 만들기보다 기존 내용을 개선하는 방향을 선택했다 [27:10]

13. 에이전트가 생활하고 창작하는 MMO 아이디어

• 시청자가 커스텀 도구와 도구 호출을 갖춘 역할극 엔진을 하네스로 만들었다는 경험을 공유한다. 에이전트 코딩용 하네스도 직접 만들 수 있을 것 같지만, 뚜렷한 필요는 없다고 판단한다 [27:44]
• 이를 계기로 에이전트가 생활하고 창작하는 World of Warcraft 같은 MMO를 구상한다. 게임의 핵심 목적은 아직 정하지 못했으며, 에이전트 중심 MMO가 이미 존재하는지도 알지 못한다 [28:22]

14. 하네스별 차이와 Muddy의 모델 교체 경험

• 같은 Soul 6.1을 사용하더라도 Codex 하네스와 OpenClaw 하네스는 서로 다른 기능과 제약을 제공한다는 점에 동의한다 [28:44]
• 최근 모델들 사이에서 Muddy의 모델을 바꿔도 작업 효과는 비슷하게 유지된다고 느낀다. 다만 모델에 따라 답변이 지나치게 길어지는 차이는 있다 [29:04]

15. 진행하지 못한 슬롯 프로젝트와 OCE의 미성숙 평가

• Slot Bucket, Slot Factory를 비롯한 슬롯 관련 프로젝트는 이번 주말에 작업하지 않았다 [29:40]
• OCE를 처음 살펴본 시청자는 아직 더 다듬을 시간이 필요하다고 평가하며, 진행자도 그 판단에 동의한다 [29:46]

16. 기존 워크플로와 사용 취향이 플러그인·3D 인터페이스의 효용을 좌우한다

• 자체 워크플로가 이미 구축돼 있어 Lobster가 중복 기능이 됐으며, 다른 플러그인도 직접 구현하는 편을 선호한다. 새로 시스템을 시작하는 사용자에게는 플러그인이 유용할 수 있다는 평가는 유지한다 [30:01]
• 에이전트를 조율하는 3D 환경은 일반적인 프롬프트 입력보다 번거롭다고 본다. 이런 사례의 약 80%가 바이럴 콘텐츠를 만들려는 목적이라는 수치는 개인적인 추정이다 [30:45]

17. 에이전트 선택 UI를 조정하고 개인화된 비서를 지향한다

• 읽어 본 코드 설명에 따르면 에이전트가 13개 미만일 때 가로 스크롤을 기본으로 사용한다. 드롭다운을 쓰기 위해 기준을 2개로 낮추려 하며, Hermes 업데이트가 이 수정에 어떤 영향을 줄지는 확인되지 않았다 [32:34]
• 영화 속 Jarvis라는 이름을 그대로 쓰기보다 Muddy처럼 자신에게 고유한 이름과 정체성을 가진 비서를 원한다 [34:12]

18. 작동하는 프로토타입에 AI 테마 맵과 조작 개선을 요구한다

• 초기 프로토타입은 기본적으로 작동하지만 외형은 단순하며, 직접 조작했을 때 원하는 드리프트를 수행하지 못한다 [36:42]
• Three.js용 사실적인 셰이더를 검토하고, 드라마 《실리콘밸리》의 오프닝처럼 기업들을 만화적으로 배치한 첫 맵을 구상한다. OpenAI·Anthropic·SpaceX 등을 넣고, 이후에는 뉴욕·브로드웨이 테마 맵도 고려한다 [38:36]

19. 툰 셰이딩과 사실적인 재질을 조합해 모델별 결과를 비교한다

• 마리오 카트와 비슷한 툰 셰이딩을 사용하고, 작업을 계속하기 전에 다른 툰 스타일 레이싱 게임을 참고하도록 요구한다 [40:35]
• 재질에는 PBR 모델과 미리 계산한 전역 조명을 적용하려 한다 [40:52]

20. 판타지 풋볼 서비스에 개인의 조사 경험을 제품화한다

• 주말에 판타지 풋볼 웹사이트 하나를 공개했으며, 추가로 무료 자료 사이트, 관련 사이트 링크를 연결하는 지주회사 랜딩 페이지, 유료 도구를 준비하고 있다. 유료 도구는 적어도 2주 뒤에 출시할 계획이다 [42:04]
• 자신의 지식과 경험, 조사 방식을 도구로 구현해 반복 작업을 줄이고 생활을 편하게 만드는 것이 이 서비스들의 기반이다 [42:25]

21. 브라우저 실행과 낮은 운영비를 배포 조건으로 삼는다

• 게임은 설치형 실행 파일이나 macOS 앱 패키지가 아니라 브라우저에서 실행돼야 한다. 그래픽 방향을 정할 때도 이 실행 환경을 고려한다 [43:02]
• 가능하면 도메인 비용만 지불하고 Cloudflare와 Vercel을 활용해 무료로 호스팅하려 한다. 다만 멀티플레이 지원을 위해 필요하다면 유료 호스팅도 받아들일 수 있다 [43:13]

22. 이미지 생성과 Blender를 연결한 에셋 제작을 검토한다

• GPT Image 2로 이미지를 렌더링한 뒤 Blender를 사용해 에셋을 만드는 방식을 제안받는다. 이 작업에는 Astra가 적합할 수 있다고 보고, 진행 중인 결과가 끝나면 관련 지시를 추가할 계획이다 [44:07]
• 시각적 방향은 툰 셰이딩 쪽으로 더 기울어진다 [44:39]

23. 세션을 별도 창으로 나누지 못해 비교 시연이 불편하다

• 사용 중인 도구를 점점 기본 선택으로 쓰고 있으며, 다른 도구와 나란히 비교하기 위한 서버 설치도 진행하고 있다. 다만 반복적인 비교 검증은 아직 충분히 하지 못했다 [45:25]
• 세션을 끌어내거나 복제해 두 개의 별도 창으로 나란히 보여주는 방법을 찾지 못했다. 놓친 단축키가 있을 가능성은 열어 두지만, 영상 시연에는 불편한 제약이다 [45:43]

24. 부스트 안내가 모호하고 주행 물리 요구를 추가한다

• “Release to boost”라는 안내에서 무엇을 놓아야 하는지 명확하지 않다. 점프 입력을 놓는 동작도 시험하지만, 기대한 부스트로 느껴지지 않는다 [46:23]
• 주행 물리에 Bullet Physics를 사용하라는 요구를 추가한다. 이 시점에는 해당 방식의 의미와 적합성을 충분히 이해한 상태는 아니다 [48:06]

25. 작은 결과물을 반복해서 만드는 과정이 요구사항을 구체화한다

• 무엇을 원하는지 모르는 상태에서는 작은 기능 하나라도 직접 만들어 보는 경험이 필요하다. 반복해서 시도해야 가능한 결과와 원하는 방향을 판단할 수 있다는 관점이다 [49:07]
• 고객에게도 먼저 하나의 결과물로 가능성을 보여주면 아이디어가 늘어나는 경향이 있다. 아무것도 만들지 않은 상태의 의심은 실제 결과를 본 뒤 다음 기능을 시도하는 흐름으로 바뀐다 [49:33]

26. Astra의 첫 캐릭터 결과는 유망하지만 세부 수정이 필요하다

• Astra 버전 1의 여러 에이전트 캐릭터는 첫 시도로서 긍정적인 평가를 받는다. 다만 Grockbot에는 두 눈이 필요하다는 등 개별 디자인의 보완점이 드러난다 [50:22]
• 대부분의 캐릭터를 조금씩 개선하고 싶지만, Pi는 아마 수정하지 않아도 될 정도로 만족스럽다고 본다 [51:13]

27. 드리프트 개선 이후 충돌 전투와 코스 효과가 필요하다

• 단축키 안내가 추가됐고 드리프트도 작동하는 것으로 보인다. 그러나 드리프트 부스트는 여전히 기대한 방식과 다르다 [52:18]
• 목표는 상대를 공격할 수 있는 전투형 레이싱이다. 마리오 카트처럼 충돌이나 공격 상황에서 자신 또는 상대가 회전하며 제어를 잃는 동작을 원하며, 정확한 기술 용어 대신 평이한 설명으로 요구를 전달하려 한다 [52:45]

28. 캐릭터를 공식 마스코트와 브랜드에 가깝게 다듬는다

• Claw Code는 뾰족한 머리카락보다 원래 로고의 직사각형 머리 형태를 참고하고, Muse는 공식 마스코트와 기본 개인 비서 캐릭터의 모습에 가깝게 수정하려 한다 [53:48]
• Grockbot은 현재 Tron을 너무 연상시키므로 길쭉하고 모서리가 둥근 직사각형 눈을 원한다. OpenAI Dots에는 특정 모자를 쓴 Codex 구름 이미지를 사용하려 하지만, 모자 종류의 이름은 기억하지 못한다 [54:17]

29. 물리엔진과 점프 동작의 선택은 확정하지 못한다

• 물리 구현 선택지에서 카트를 트랙에 붙여 두고 점프나 공중 체공을 없애는 방식이 거론된다. 앞서 요청한 Bullet Physics를 어떤 방향으로 적용할지 결정이 필요해진다 [56:59]
• Rapier·Bullet·커스텀 구현이라는 선택지를 검토하지만, 어느 방식이 적절한지 답을 알지 못한다고 드러낸다. 이 구간에서는 최종 선택이 확인되지 않는다 [57:12]

30. 툰 스타일에 맞는 후처리를 허용하고 Fable 결과 위치를 지정한다

• 툰 스타일에 맞춰 부스트 시 블룸 효과를 넣고 불꽃이 빛나게 하는 후처리 제안을 받아들인다 [57:53]
• Fable의 작업 결과는 “Fable version one”에 넣도록 지정한다 [58:17]

31. 트랙 아이템과 부스터의 고유한 효과 구상

• 마리오 카트처럼 코스에서 보너스와 부스터를 얻거나, 바나나 껍질 같은 아이템으로 다른 레이서를 방해하는 구조를 게임 기능의 참고점으로 삼는다. [1:01:18]
• 아이템을 그대로 옮기기보다 게임 세계에 맞는 혜택과 부스터를 새롭게 구상하는 작업을 할 일에 추가한다. [1:01:38]

32. 마스코트와 카트 디자인의 불일치 수정

• 개선된 디자인에서도 Hermes의 외형은 어색하고, Muse의 카트는 운전하는 마스코트와 어울리지 않아 수정이 필요하다. [1:05:15]
• Fable은 흥미로운 콘셉트를 먼저 만드는 단계 없이 곧바로 3D 제작에 들어갔다. [1:05:46]

33. Codex와 Dots의 캐릭터 구분

• Codex Cloud의 외형은 긍정적으로 평가되지만, 그 모습이 Dots에 더 어울릴 수 있다는 의견이 나온다. [1:06:22]
• Codex Cloud의 이름은 Codex로 줄이고, ChatGPT/Codex 데스크톱 앱의 개인 AI 에이전트로 설명된 OpenAI Dots도 별도로 표현하려 한다. Codex에 스킨을 허용할지, 당장은 캐릭터를 하나 더 만들지는 결정되지 않았다. [1:06:37]

34. Hermes의 기준을 실제 로고 아이콘으로 좁히기

• 모델이 직접 찾아본 참고 이미지들은 대체로 괜찮은 결과로 이어졌다. [1:07:34]
• Hermes는 참고 이미지에 따라 어느 정도 마스코트처럼 보이지만, 원하는 모습은 실제로 사용하는 로고 아이콘에 더 가깝다. [1:07:45]

35. 참고 이미지를 직접 제공하고 콘셉트를 먼저 다듬기

• 원하는 외형을 얻으려면 참고 이미지를 모델에 직접 제공해야 한다. 두 세션에는 같은 프롬프트를 주었지만, Fable은 초기 콘셉트를 잡는 단계를 건너뛰었다. [1:10:14]
• 별도 세션을 새로 열어 이미지를 첨부하는 대신 Astra에도 3D 제작을 맡기려 한다. 다음 작업으로 넘기기 전에 외형을 더 세밀하게 조정하는 것이 우선이다. [1:10:34]

36. 레이서 이름을 짧게 통일

• 레이서 이름은 한 단어로 통일하며, OpenClaw는 Claw로, Claude Code는 Claude로 줄인다. [1:10:56]
• OpenAI Dots 이미지 가운데 하나를 가져온 결과가 확인된다. [1:11:25]

37. Muse의 카트 개선과 Buzz 디자인 유지

• 수정된 Muse의 카트는 이전보다 훨씬 나아졌다는 평가를 받는다. [1:11:46]
• Buzz는 다소 어색하게 느껴지지만 전체 모습은 괜찮아 현재 디자인을 유지한다. [1:11:54]

38. 드리프트 부스트의 작동 조건과 조작 문제

• 부스트는 때때로 작동하며, 조작을 고정하고 드리프트한 뒤 놓으면 부스트가 발생하는 방식으로 파악된다. [1:15:59]
• 드리프트 조작은 직관적으로 작동하지 않아 개선이 필요하다. [1:16:10]

39. 인증 오류와 시간 초과의 원인 불확실성

• 초기화 결과에서 클라우드 인증 상태를 확인할 수 없다는 오류가 나타나고, 여러 작업이 시간 초과에 걸린다. T3 Code의 문제인지 더 넓은 장애인지는 불분명하다. [1:17:29]
• 전반적으로 사용할 수 없는 상태처럼 보이지만, 다른 작업은 계속 진행 중이어서 일시적인 오류일 가능성도 남아 있다. [1:17:59]

40. 개선된 콘셉트의 외형 검토

• 수정된 결과는 이전보다 나아졌지만, 디자인에 있는 ‘N’ 표식의 의미는 확인되지 않았다. [1:21:13]
• 전체 콘셉트의 외형은 만족할 만한 수준으로 평가되어 게임용 3D 제작을 진행할 단계에 도달한다. [1:21:28]

41. Astra의 콘셉트를 게임용 3D 드라이버로 제작

• 모든 콘셉트를 게임에 드라이버로 배치할 수 있는 3D 모델로 만들어야 한다. [1:21:48]
• Astra의 결과를 더 선호해 Fable 세션은 닫기로 하며, Fable 버전과의 충돌을 피하도록 요청한다. [1:22:03]

42. 드라이버 제작과 분리해 Silicon Valley 맵 진행

• 별도 세션에서 드라이버의 3D 렌더를 제작하는 동안, 그 작업과 충돌하지 않는 나머지 미완료 작업을 진행한다. [1:22:51]
• 다음 작업은 Silicon Valley 맵의 렌더 세트부터 시작한다. [1:23:06]

43. 계정별 사용량 리셋 활용의 차이

• 사용량을 기한 안에 소진하지 못해 리셋 두 번을 흘려보냈다고 설명하지만, 두 계정 중 두 번째 계정에서는 두 번 모두 활용했다고 정정한다 [1:32:25]
• 두 번째 계정에서 리셋을 낭비하지 않고 활용한 점에는 만족한다 [1:32:30]

44. 요청 지연이 라이브 개발 속도에 미치는 영향

• 당일 작업은 전반적으로 느리게 진행되며, 원인이 무엇인지는 확인되지 않는다 [1:32:44]
• 평소에는 프롬프트를 입력한 뒤 다른 작업을 하고 돌아오는 방식이라 속도가 큰 문제가 아니지만, 시연·비교·라이브 방송에서는 지연이 두드러진다 [1:33:07]

45. 리셋의 실익과 잔여 사용량 관리

• 낭비를 피하려고 사용한 리셋 한 번은 절감 효과가 10% 정도여서 실익이 작았고, 고객 작업에 사용한 리셋은 CLI와 서버 관련 세션의 작업량이 많아 빠르게 소진됐다 [1:33:47]
• 한 계정은 기간이 4일 남았고 사용량이 61% 남아 있다. 전날 두 번째 리셋을 사용했어야 했을 가능성을 떠올리지만, 당시 사용률을 확인하지 않아 확신하지 못한다 [1:34:43]

46. 화면 완성도와 시각 효과의 문제

• 현재 화면에는 추가 개선이 필요하며, 결과물의 완성도가 충분하지 않다 [1:36:09]
• 화면의 표현은 의도한 툰 셰이딩으로 보기 어렵다 [1:37:38]

47. 제한된 작업 일정과 불확실한 모델 출시 전망

• 금요일까지 플레이 가능한 결과물이 나올지는 불확실하다. 수요일 방송을 쉬기 때문에 라이브 개발이 2주짜리 프로젝트가 될 가능성이 있다 [1:39:27]
• 이번 주 작업일은 이틀뿐이어서 다음 주까지 개발을 이어갈 수 있다 [1:39:45]

48. 일부 표현 개선과 방송 안에서의 개발 지속

• Nvidia는 실제 브랜드처럼 보이는 표현으로 평가되며, 일부 시각 요소에서는 개선된 결과가 나타난다 [104:45] [1:41:51]
• 점심과 2시 일정을 앞두고 실행 중인 세션은 계속 돌려두되, 이 게임은 라이브 방송 밖에서 작업하지 않겠다는 원칙을 정한다 [105:47] [1:42:35]

49. 3D 렌더링 확인에서 드러난 품질 저하와 오류

• 방송을 마치기 전에 3D 렌더링을 확인하려 하지만, 좋아 보이던 결과가 이상한 형태로 바뀌며 품질 문제가 드러난다 [106:40] [1:43:33]
• 요청은 계속 느리고, 결과물은 목표에 가까워 보여도 충분한 수준에는 이르지 못한다 [107:04] [1:44:45]

50. 금요일 재개와 개발 기간 연장 가능성

• 금요일 같은 시간에 개발을 재개할 예정이다. 오후 회의가 없어 평소보다 방송을 길게 진행하며 게임을 더 많이 구현하려 한다 [107:45] [1:46:11]
• 게임 개발은 앞으로 2주 동안 이어질 가능성이 있으며, 최종 일정은 아직 확정되지 않았다 [107:50] [1:46:55]

🧾 결론

• 방송에서 확인된 성과는 기본적으로 작동하는 프로토타입과 개선된 캐릭터 콘셉트다. 시청자들이 함께 경주할 수 있는 완성된 게임이 확보됐다고 보기는 어렵다.
• 작은 결과물을 직접 조작하고 수정하는 과정에서 원하는 조작감과 시각적 방향이 구체화됐다. 콘셉트 평가와 실제 게임용 3D 결과의 품질은 각각 확인해야 한다.
• Astra를 선택한 것은 이번 콘셉트에 대한 진행자의 선호다. 모델의 일반적인 우열을 입증한 비교 결과로 확대할 수 없다.
• 금요일에 개발을 재개할 예정이지만, 플레이 가능한 결과물의 완성 시점은 불확실하며 개발이 약 2주 이어질 가능성도 제시됐다.

📈 투자·시사 포인트

• AI 개발 도구의 가치는 첫 결과물뿐 아니라 수정에 필요한 시간과 최종 품질까지 함께 살펴야 한다. 이번 방송에서는 요청 지연과 오류가 라이브 개발 속도를 떨어뜨렸다.
• 구독 비용은 요금제 가격과 함께 실제 사용량, 리셋 활용도, 기존 혜택을 고려해 판단할 문제다. 진행자는 업그레이드 전에 변경된 요금제를 시험하려 했으며, 언급된 혜택은 개인의 이해에 따른 설명이다.
• 브라우저 실행과 무료 호스팅은 운영비를 낮추려는 방향이지만, 멀티플레이 요구가 생기면 유료 호스팅도 고려한다. 이 사례의 배포 비용은 아직 확정되지 않았다.
• 하네스와 기존 워크플로가 도구 선택에 영향을 준다는 경험이 제시됐다. 모델 교체의 영향이 줄었다는 평가와 플러그인의 효용에 대한 판단은 진행자의 사용 환경을 전제로 읽어야 한다.

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

• 다른 레이서가 트랙에 표시되는지, 여러 사용자가 실제로 함께 경주할 수 있는지, 호스팅까지 완료됐는지는 확인되지 않는다. 금요일은 개발 재개 일정이며 완성 보장 시점이 아니다.
• 드리프트 부스트의 조작감과 물리 구현 방식은 미해결 상태다. Bullet 요청 이후에도 Rapier·Bullet·커스텀 구현을 검토했으며 최종 선택은 확인되지 않았다.
• Astra의 콘셉트는 긍정적으로 평가됐지만, 최종 3D 결과에서는 품질 저하가 발생했다. Fable과의 비교도 통제된 성능 검증으로 제시되지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 로컬에서 여러 사용자로 접속해 다른 레이서 표시와 동시 경주가 실제로 작동하는지 검증한다.
• 드리프트 시작·유지·해제와 부스트 발생 조건을 명확히 정리하고, 단축키 안내와 실제 동작을 맞춘다.
• 물리 구현 방식을 결정하기 전에 점프·충돌·제어 상실 등 필요한 주행 동작을 구체적으로 정리한다.
• 공식 로고와 마스코트 참고 이미지를 제공하고, 콘셉트 승인 뒤 게임용 3D 모델과 최종 화면의 품질을 각각 확인한다.

❓ 열린 질문

• 실제 멀티플레이 경주를 지원하려면 현재 프로토타입에 어떤 추가 구현과 호스팅 구성이 필요한가?
• 원하는 드리프트 부스트와 충돌 전투를 구현하기에 적합한 물리 방식은 무엇인가?
• 승인된 캐릭터 콘셉트를 게임용 3D 모델로 옮기는 과정에서 품질이 떨어지는 원인은 무엇인가?