GPT-6 Astra가 게임 개발에 최적의 모델인 이유 — 4가지 실제 사례

URL: https://www.youtube.com/watch?v=iDrEXFOvFUc 날짜: 2026-09-07 채널: Peter Yang

메타데이터

• 원문 제목: GPT 6 Astra is the Best Model for Building Games (4 Real Examples)
• 영상 ID: iDrEXFOvFUc
• 콘텐츠 유형: YouTube 심층 다이제스트
• 언어: 영어 자막 기반 한국어 번역·분석
• 주요 도구: ChatGPT Desktop, GPT Astra, Blender, Godot, Godot MCP, Blender MCP
• 주제 분류: AI/LLM, 게임 개발, 바이브 코딩(vibe coding), 멀티모달 창작 워크플로
• 태그: GPT-6 Astra, Blender, Godot, Star Fox, Dustline, Ashfall, No Moat, roguelike deck builder

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==GPT Astra는 게임 코드를 완벽하게 한 번에 작성하는 모델이라기보다, 아이디어 발상·콘셉트 아트·3D 자산·플레이테스트·반복 개선을 연결해 한 사람이 여러 장르의 플레이 가능한 프로토타입을 매우 짧은 시간에 만드는 모델이다.==

• Peter Yang은 금요일 밤 Astra의 medium 설정으로 네 게임을 동시에 만들었고, 20달러 ChatGPT Plus 요금제에서도 충분히 멀리 갈 수 있다고 말한다.
• Blender와 Godot는 무료 오픈소스 도구이고, Godot MCP와 Blender MCP를 설치하면 Blender나 Godot를 직접 다룰 줄 몰라도 Astra가 앱을 운전할 수 있다.
• Star Fox형 우주 슈터, 이동하는 열차 위 1인칭 슈터, StarCraft형 실시간 전략 게임, AI 창업가 로그라이크 덱 빌더가 각각 다른 장르의 가능성과 한계를 보여준다.
• 결과물의 수준은 처음 생성된 코드보다 레퍼런스 이미지, 짧은 마일스톤, 반복 플레이테스트, 밸런스 피드백, 조명과 아트 개선을 얼마나 빠르게 주고받는지에 좌우된다.

Astra의 가치가 가장 잘 드러나는 지점은 전문 게임 개발자를 대체한다는 선언이 아니라, 어린 시절의 게임 기억이나 막연한 상상을 혼자서 즉시 시험 가능한 형태로 바꾸는 창작 비용을 낮춘다는 데 있다. 다만 결과물은 처음부터 완성품이 되지 않으며, 세 개의 사례는 기술 데모에 가깝고 No Moat만 약 두 시간의 반복 작업을 거쳐 실제로 플레이할 만한 게임에 접근했다.

1. Astra 게임 개발 실험의 출발점

1.1. 과장된 출시 담론 대신 어린 시절의 게임을 되살리기

1. Astra 출시를 맞은 첫 반응

   1. 벤치마크와 인플루언서식 과장: GPT Astra가 막 출시되었을 때 벤치마크가 얼마나 뛰어난지 말하거나 다른 인플루언서처럼 모델을 과장할 수도 있었지만, Peter Yang은 Astra가 자신의 어린 시절 일부를 되살렸다는 경험을 먼저 꺼낸다.
   2. 게임 제작 모델로서의 개인적 평가: Astra는 Peter Yang이 지금까지 게임을 만들 때 사용한 모델 가운데 단연 가장 뛰어난 모델이다.

2. 네 가지 게임의 범위

   1. Star Fox형 우주 슈터: Super Nintendo 시절의 우주 슈팅 게임 감각을 3D 게임으로 재구성한다.
   2. Dustline: 움직이는 열차의 화물칸에서 적을 상대하는 1인칭 슈터(first-person shooter)다.
   3. Ashfall: StarCraft를 연상시키는 실시간 전략(real-time strategy) 레벨이며 Terran과 Zerg의 전투를 중심으로 한다.
   4. No Moat: 세대적 기업(generational company)을 만들려는 AI 창업가를 주인공으로 삼은 로그라이크 덱 빌더(roguelike deck builder)다.

3. 실험의 조건

   1. 동시 제작: 네 게임은 금요일 밤에 Astra의 medium 설정으로 동시에 작업했다.
   2. 요금제의 현실성: 20달러 ChatGPT Plus 플랜으로도 상당히 멀리 갈 수 있으며, Astra의 higher나 ultra 설정까지 사용할 필요는 없다고 평가한다.
   3. 마무리 논점: 게임 사례를 모두 보여준 뒤 Astra 출시가 왜 반발을 샀는지, 그리고 그 책임이 전부 OpenAI에 있었던 것은 아닐 수 있는지를 이야기한다.

1.2. 비개발자도 접근할 수 있는 도구 조합

1. 필요한 기본 환경

   1. ChatGPT Desktop: 모델을 선택하고 아이디어를 주고받는 중심 작업 공간이다.
   2. Astra: 모델 선택기에서 Astra를 활성화해 게임 제작과 개선을 맡긴다.
   3. Blender: 3D 모델과 애니메이션을 만드는 무료 오픈소스 도구다.
   4. Godot: 3D 모델을 실제로 플레이할 수 있는 게임으로 바꾸는 무료 오픈소스 게임 엔진이다.

2. 전문 지식 없이 앱을 연결하기

   1. 낯선 UI의 장벽: Peter Yang은 Blender나 Godot를 실제로 사용할 줄 모르며, Blender의 UI만 봐도 매우 복잡해 보인다고 말한다.
   2. MCP 설치: ChatGPT에 “Godot MCP와 Blender MCP를 설치하자”고 말하는 것만으로 두 도구를 설치하게 했고, AI가 앱을 직접 조작하도록 만들었다.
   3. 핵심 전환: 사용자는 엔진의 모든 메뉴를 배우는 대신 원하는 플레이 경험과 개선 피드백을 말하고, AI는 도구를 통해 모델·애니메이션·게임 로직을 조립한다.

2. Star Fox형 우주 슈터 — 아트 자산과 반복 플레이테스트의 효과

2.1. 어린 시절의 게임 기억을 모델 비교 실험으로 바꾸기

1. Star Fox를 첫 사례로 고른 이유

   1. 개인적 기억: Star Fox는 Super Nintendo 시절의 우주 슈터로, Peter Yang이 어린 시절 매우 좋아했던 게임이다.
   2. 지속적인 모델 테스트: GPT-5.5가 나온 뒤부터 여러 모델을 비교하는 테스트 게임으로 Star Fox를 사용해 왔다.

2. 기존 모델과 Astra의 차이

   1. GPT-5.5 버전: 다각형 그래픽, 다가오는 적, 기본적인 재미를 갖추어 꽤 좋아 보인다.
   2. 다른 비교 버전: GPT-5.5 계열 및 Fable 5와 비교한 초기 버전은 그래픽이 조금 더 좋고 다듬어졌으며, 윙맨(wingman)의 반응도 들어간다.
   3. Three.js의 한계와 장점: 초기 데모는 브라우저 3D용 JavaScript 라이브러리인 Three.js만 사용했으며, Three.js만으로도 상당히 멀리 갈 수 있다.
   4. Astra의 확장된 작업 공간: Astra에는 Blender와 Godot까지 연결했기 때문에 작업할 수 있는 도구가 훨씬 많고, 결과적으로 그래픽의 질을 크게 끌어올릴 수 있다.

2.2. Astra 버전의 실제 플레이 요소

1. 게임의 기본 구조

   1. 윙맨과 프로필: ChatGPT 이미지 생성 기능으로 윙맨 프로필 이미지를 만들고 게임에 넣었다.
   2. 전투와 레벨: 화면으로 들어오는 우주선을 공격하며, 초기 버전보다 더 흥미로운 레벨과 더 많은 적을 배치했다.
   3. 다단계 진행: 한 구역을 지나면 다음 스테이지가 이어지는 구조를 만들었다.

2. 장애물과 보스전

   1. 낙하 블록: 무너지는 구조물에서 떨어지는 블록을 피해야 하므로 단순히 적만 쏘는 게임이 아니다.
   2. 최종 보스: 거대한 Starship Destroyer 같은 보스를 마지막에 추가했다.
   3. 부위 파괴: 보스에게 사격하면 선체의 서로 다른 부분이 떨어져 나가며, 시연 중 양쪽 날개를 차례로 부수는 장면을 보여줬다.
   4. 승리 조건: 계속 사격해 보스 전체를 파괴하면 게임이 끝난다.

2.3. Star Fox를 만드는 대화 흐름

1. 모델에게 참고 자료와 제작 원칙을 제공하기

   1. 도구 설치: ChatGPT와 Astra에게 Godot와 Blender를 설치하게 했다.
   2. OpenAI 직원의 블로그 글: Astra로 게임을 만드는 방법을 정리한 OpenAI 직원의 글을 읽게 했다.
   3. 네 가지 베스트 프랙티스: 플레이어 경험을 먼저 설명하고, 콘셉트 이미지로 외관을 확립하며, 반복 가능한 플레이테스트를 일찍 만들고, Blender로 구별되는 자산(distinctive assets)을 제작하라는 원칙을 적용했다.

2. 아이디어를 좁히는 과정

   1. 상위 다섯 아이디어 요청: “시각적으로 인상적이고 매우 재미있는 게임은 무엇인가? 상위 다섯 개를 달라”고 물었다.
   2. Star Fox 선택: 여러 아이디어 중 Star Fox를 만들라고 지시했다.
   3. 결정된 콘셉트: “Star Fox와 무너지는 거대 구조물(collapsing mega structure)의 만남”이라는 아이디어가 최종 게임의 방향이 되었다.

3. 첫 결과물의 문제와 시각적 기준 세우기

   1. 재미 부족: 처음 만들어진 게임은 작동했지만 실제로 재미있지는 않았다.
   2. 별도 이미지 생성: 다른 ChatGPT 스레드에서 게임의 이상적인 모습을 보여주는 이미지를 만들었다. 무너지는 우주 구조물과 진행 중 장애물이 포함된 이미지였다.
   3. 구체적인 개선: 팀원과 아군을 추가하고 그래픽을 개선하라고 요청하자, Astra는 목표 게임의 대표적인 모습을 다시 생성하고 윙맨 프로필 이미지도 만들었다.

4. 피드백을 통한 게임성 강화

   1. 반복 피드백: “더 좋아졌지만 여전히 지루하다. 파워업을 추가하고, 적을 더 어렵게 만들며, 우주 정거장이 무너지는 것처럼 보이게 하라”고 요청했다.
   2. 보스 개선: 보스전을 더 흥미롭게 만들라고 했고, Astra에게 스스로 어떻게 계속 개선할지 아이디어를 내게 한 뒤 그 아이디어를 전부 구현하게 했다.
   3. 자가 플레이테스트: Astra는 browser use와 computer use를 활용해 자신의 게임을 플레이테스트하고 재미가 있는지 점검할 수 있다.
   4. 소요 시간: 기본적인 대화와 개선을 약 3분 진행한 뒤 시연한 버전이 나왔다.

3. Dustline — 움직이는 열차 위 1인칭 슈터

3.1. 플레이 가능한 전투 장면

1. 이동하는 무대

   1. 열차 화물칸: 플레이어는 달리는 열차의 화물칸 위에 있고, 적들이 사방에서 사격한다.
   2. 기본 총기 조작: 총을 쏘고 재장전하며 조준할 수 있다.

2. 무기와 적의 변화

   1. 화염방사기: 화염방사기를 주워 적에게 불을 쏠 수 있다.
   2. 로켓 런처: 로켓을 발사하면 거품처럼 보이는 폭발이 발생하며, 시연자는 결국 기본 총이 가장 좋다고 판단해 다시 총으로 전환했다.
   3. 제트팩 적: 일부 적은 날아다니며 제트팩으로 공중에서 사격한다.
   4. 최종 함선: 커다란 함선 형태의 보스가 등장한다.

3. 보스전과 한계

   1. 무기 선택: 보스에게는 화염방사기보다 로켓 런처가 더 적합하다고 판단했다.
   2. 탄약 문제: 로켓 탄약이 떨어지는 상황이 발생했으며, 보스가 실제로 충분히 사격하지 않아 난도를 더 높여야겠다는 평가가 나왔다.
   3. 종료 장면: 보스를 처리한 뒤 열차를 장악하는 장면으로 데모가 끝난다.
   4. 자기 평가: Dustline은 완성된 상용 게임이라기보다 기술 데모(tech demo)에 가깝다.

3.2. “Titanfall meets moving train”으로 구체화하기

1. 첫 아이디어 탐색

   1. 동일한 시작 질문: Godot와 Blender로 1인칭 슈터를 만들자고 한 뒤 상위 다섯 아이디어를 요청했다.
   2. 검토한 대안: Left 4 Dead식 좀비 슈터를 만들어볼까 고민했다.
   3. 최종 영감: “Last Train Home”이라는 아이디어가 움직이는 열차 슈터를 만드는 계기가 됐다.

2. 레퍼런스 이미지와 단계별 제작

   1. 목표 이미지: ChatGPT에게 게임의 모습을 그려달라고 했고, 생성된 이미지는 실제로 만든 게임보다 훨씬 인상적이었다.
   2. 이미지의 역할: 다음 세대 모델이 한 번에 이 이미지를 구현할 수도 있겠지만, 레퍼런스 이미지를 주면 AI가 목표 방향을 더 정확히 파악할 수 있다.
   3. 한 줄 콘셉트: “Titanfall과 움직이는 열차의 만남”이라는 표현으로 게임의 판타지를 정리했다.
   4. 세 마일스톤: 한 번에 전부 만들게 할 수도 있지만, 두세 개의 마일스톤으로 쪼개고 중간마다 테스트하는 편이 좋다고 판단했다.

3. 그래픽과 적을 개선하기

   1. 초기 버전: Astra가 만든 첫 결과물은 기본적이었고 Peter Yang이 원하는 모습과 달랐다.
   2. 추가 레퍼런스: 다시 참고 이미지를 제공하고 그래픽을 더 좋게 만들며 총을 더 세밀하게 표현하라고 요청했다.
   3. 적의 변경: 로봇 대신 실제 인간을 적으로 만들고, 제대로 된 사망 애니메이션을 추가하라고 했다.

4. 이동 중 음성 피드백

   1. 생활 속 작업: 가족과 함께 외출해야 해서 작업을 떠났고, 휴대전화의 ChatGPT를 이용해 음성으로 피드백을 보냈다.
   2. 즉흥적 요구: 적의 종류를 더 늘리고, 현재 AI가 너무 멍청하니 개선하며, 로켓 런처를 더 좋게 만들고 탄약을 더 추가하라는 식의 즉흥적인 지시였다.
   3. 품질보다 속도: 고도로 정리된 게임 디자인 문서가 아니라 이동 중 말한 자연스러운 피드백만으로도 시연 가능한 결과물에 도달했다.

4. Ashfall — StarCraft형 실시간 전략 레벨

4.1. StarCraft에 대한 개인적 기억과 게임 데모

1. 어린 시절의 열정

   1. 가장 좋아하는 게임: StarCraft는 Peter Yang이 가장 좋아하는 게임이며 고등학교 때 쉬지 않고 플레이했다.
   2. 수업을 빼먹은 일화: StarCraft를 하려고 수업을 빼먹기도 했다.
   3. 핵 공격 일화: 한국인 친구와 컴퓨터를 상대로 3대1로 압도하던 중 친구의 기지에 핵폭탄을 떨어뜨려 친구의 완벽한 전적을 망친 일이 가장 좋아하는 추억으로 남아 있다.
   4. 새 작품에 대한 소문: Blizzard가 그해 가을 새 StarCraft 게임을 내놓을 것이라는 소문이 있었고, Astra가 StarCraft 레벨을 만들 수 있는지 확인하고 싶어졌다.

2. Ashfall의 기본 플레이

   1. Terran 군대: 플레이어가 조종하는 해병(Marine)과 공성 전차(Siege Tank)가 있다.
   2. 공성 모드: 전차를 StarCraft의 핵심 기능인 Siege Mode로 전환할 수 있다.
   3. 생산과 방어: 해병·의무병(Medic)·전차를 생산하고 포탑도 건설한다.
   4. 방어 목표: Zerg가 몰려오는 기지 방어 게임이며, 릴레이(relay)를 점령하면서 Zerg의 공격을 막아야 한다.

3. 전투 시스템의 세부 요소

   1. 의무병의 역할: 의무병은 해병을 치료한다.
   2. 오버드라이브: E 키를 눌러 해병에게 Stim을 적용하고 overdrive 상태로 만들면 적을 더 빠르게 처치한다.
   3. 궤도 공격: orbital 옵션은 궤도 공격(orbital strike)으로 작동한다.
   4. 난이도 체감: Ultralisks가 등장하자 Zerg가 너무 많아졌고 기지가 무너지기 시작했으며, 궤도 공격을 다시 사용해 겨우 한 레벨을 버텼다. 다음 레벨까지 살아남기는 어려워 보였다.

4.2. 콘셉트 아트에서 전투 루프와 밸런스로 이동하기

1. 시각적 목표 설정

   1. 현대적 StarCraft 요청: StarCraft와 같은 실시간 전략 게임이지만 현대적인 그래픽을 가진 장면을 만들어 달라고 요청했다.
   2. 콘셉트 아트와 실제 게임의 차이: 생성된 콘셉트 아트는 실제 게임보다 훨씬 좋았지만, AI가 원하는 방향을 파악하도록 기준을 잡아주는 데 유용했다.

2. 세력과 전투 조건 지정

   1. 플레이어 진영: 인간 Terran 진영을 플레이어가 조종하게 했다.
   2. 적 진영: 적은 Zerg로 설정했다.
   3. 핵심 기능 요구: Terran이 Zerg로부터 기지를 방어하는 레벨을 만들고, Siege Tank가 반드시 Siege Mode에 들어가게 했다. 이는 StarCraft의 기본 중 기본(StarCraft 101)이다.
   4. 프롬프트의 단순화: 모델이 좋아질수록 Peter Yang은 장황한 프롬프트를 덜 쓰고, 원하는 핵심만 짧게 말하게 되었다.

3. 그래픽보다 중요한 게임성

   1. 게임의 구성 요소: 재미있는 게임은 그래픽만으로 만들어지지 않으며, 밸런스(balance), 핵심 루프(core loop), 진행 시스템(progression system)이 함께 필요하다.
   2. 쉬운 난도 개선: 게임이 너무 쉬워서 의무병 같은 캐릭터를 추가하고, 세 가지 종류의 Zerg 적을 넣고, 적을 더 공격적으로 만들라고 했다.
   3. 조명 팁: 3D 게임을 좋아 보이게 만드는 가장 손쉬운 방법 중 하나는 더 나은 lighting effects를 요청하는 것이며, 조명만 바꿔도 큰 차이가 난다.
   4. 플레이테스트 조정: 직접 플레이한 뒤 5번째 웨이브부터 너무 어렵다고 알려 난도를 낮추는 식으로 조정했다.

4. 결과의 한계와 의미

   1. 프롬프트 수: 대략 열두 개 정도의 프롬프트로 제작했다.
   2. 완성도 평가: Ashfall은 실제 StarCraft는 아니지만, AI로 만든 실시간 전략 게임이 어떤 모습이 될 수 있는지 보여주는 꽤 좋은 기술 데모다.

5. No Moat — 실제 게임에 가장 가까운 로그라이크 덱 빌더

5.1. AI 창업가의 런(run)과 카드 전투

1. 게임의 세계관과 선택

   1. 주제: AI 창업가가 세대적 기업을 만들고 그 과정에서 여러 장애물을 극복한다.
   2. 초기 캐릭터: Dropout, Professor, ex-Fan employee 가운데 하나를 고르며, 시연에서는 Dropout을 선택했다.
   3. 맵 구조: 이겨야 하는 레벨이 맵으로 표시되고, 전체는 세 개의 스테이지로 구성된다.
   4. 동료 선택: Designer, Principal Engineer, Research Scientist 중 첫 동료로 Designer를 선택했다.

2. 초기 전투의 카드와 유닛

   1. 게임 장르: 여러 카드 덱을 이용해 적을 상대하는 로그라이크 덱 빌더다.
   2. Ship It 카드: 래퍼 스타트업(rapper startups)을 제거하는 데 Ship It을 사용했다.
   3. Scope Creeper: Scope Creeper를 rate limit해 공격하지 못하게 한 뒤 Ship It으로 처리했다.
   4. 카드 갱신: 전투 중 버튼을 눌러 카드를 새로고침(refresh)할 수 있다.
   5. GPU Rack: 적의 공격을 막기 위해 GPU Rack을 배치했다.

3. 첫 미니 보스와 보상

   1. Acquire: 첫 미니 보스는 창업이 시작되기도 전에 회사를 인수하려는 Acquire다.
   2. 전술 조작: 보드 위에서 캐릭터를 이동시키고, Hype Tweet으로 공격력을 높였다.
   3. 처치: Acquire의 체력이 세 칸 남았을 때 Ship It으로 직접 마무리해 승리했다.
   4. 성장 선택: 승리 후 동료를 더 영입할지 카드를 더 받을지 선택하고, 시연에서는 동료를 골라 Research Scientist를 추가했다.

4. 버그와 후속 스테이지

   1. Bug Investigation: 다음 전투는 버그 조사이며, 보드 위에 유닛을 배치해 적을 제거한다.
   2. Memory Leak: Memory Leak 적이 나타나자 Hype Tweet으로 처치했다.
   3. 단계별 보스: 각 레벨에는 작은 보스전이 있고, 이후에는 더 큰 Major Bug를 상대해야 한다.
   4. 게임성의 기준: 앞선 세 기술 데모와 달리 이 게임은 그래픽뿐 아니라 로그라이크 덱 빌더 특유의 밸런스까지 맞추기 위해 훨씬 더 많은 시간을 투입했다.

5.2. Claude에서 ChatGPT와 Astra로 옮겨간 제작 과정

1. Astra를 쓰기 전의 출발

   1. 첫날의 제약: Astra를 아직 사용할 수 없었던 첫날에는 Claude에서 Fable을 사용해 개발을 시작했다.
   2. 도구의 대체 가능성: 같은 제작 흐름은 Astra와 ChatGPT만으로도 구현할 수 있다.
   3. 장르 레퍼런스: Slay the Spire와 Wildfrost처럼 매우 재미있는 게임을 만들고, AI 경쟁에 관한 밈도 넣고 싶다고 요청했다.

2. No Moat의 최초 아이디어

   1. 첫 번째 제안: AI 연구소를 Seed 라운드에서 AGI까지 경사로를 오르듯 성장시키는 게임이 첫 번째 아이디어로 나왔다.
   2. 게임 자원: 유닛은 연구자와 GPU 클러스터이며, 다양한 카드가 성장과 전투를 구성한다.
   3. 복잡도 질문: 제작이 복잡한지 묻자 AI는 꽤 쉽다고 답하고 대략적인 제작 계획을 제시했다.

3. HTML 명세로 제품을 먼저 정의하기

   1. 스펙 작성: 이번에는 AI에게 게임의 HTML 명세를 작성하게 했다.
   2. 제품과 기술 분리: 스펙을 product design과 tech stack으로 나누었다.
   3. 제품 파트: 해결책(solution), 핵심 루프(core loop), 요구사항(requirements)을 정리했다.
   4. 디자인 파트: 실제 화면 구성과 플레이 경험을 정의했다.

4. 이모지 프로토타입에서 2D 아트로 이동하기

   1. Claude의 이미지 한계: Claude에는 이미지 모델이 없어서 HTML과 이모지를 이용해 캐릭터와 카드를 표현했다.
   2. 초기 플레이 가능 버전: 첫 버전은 이모지와 카드로 게임 루프를 먼저 확인하는 형태였다.
   3. 전환의 이유: 이모지만으로는 더 나은 이미지를 만들 수 없다고 판단했고, Astra를 사용할 수 있게 되자 ChatGPT로 옮겼다.
   4. 코드베이스 이전: ChatGPT에서 Claude가 만든 코드베이스를 먼저 export하고, 실제로 플레이 가능한 버전으로 만들게 했다.

5. Blender 대신 이미지 생성 선택

   1. 도구 질문: Blender MCP를 써야 하는지, 개발자가 아니라 무엇을 해야 할지 모르겠다고 물었다.
   2. Astra의 판단: Astra는 Blender를 권하지 않고, 이미지 생성으로 아트를 만드는 편이 낫다고 제안했다.
   3. 첫 전투의 집중: 전체 게임을 한 번에 키우기보다 설득력 있는 전투 하나를 먼저 만들고 그래픽을 좋게 하며, 시연에서 본 디오라마(diorama) 느낌을 유지하라고 했다.

6. 2D 자산의 품질과 캐릭터 확장

   1. 생성한 자산: ChatGPT 이미지 모델로 적, 영웅 캐릭터, 전투 스테이지, 버그, 아이템을 만들었다.
   2. 3D 시도와 포기: 캐릭터를 애니메이션처럼 보이게 하려고 Blender로 3D 캐릭터를 만들었지만 2D 이미지보다 디테일이 훨씬 떨어져 2D 방식을 유지했다.
   3. 고정관념을 활용한 유머: PM 캐릭터는 New Balance 신발을 신고 포스트잇을 붙이는 모습으로, 디자이너 캐릭터는 전형적인 디자이너 이미지로 그려졌다. AI가 꽤 고정관념적으로 표현한다는 농담이 붙었다.
   4. 추가 영웅: Vibe Coder와 Principal Engineer를 추가했고, 지쳐 보이는 ex-Fan employee도 영웅 캐릭터로 넣었다.

7. 밸런스와 적 디자인 개선

   1. 검증된 장르의 관습: 직접 게임을 플레이하면서 밸런스를 점검하고, 이 장르의 검증된 게임을 참고해 베스트 프랙티스를 반영하라고 요청했다.
   2. 적의 다양성: 더 많은 캐릭터와 적을 만들고, 각 적이 서로 다른 특성을 갖게 했다.
   3. 코드 미확인: 제작 과정 전체에서 코드를 단 한 번도 직접 들여다보지 않았다.
   4. 현실적인 적의 방향: 처음에는 라이벌 창업가가 많았지만 AI 창업가들은 서로 도우려 할 수도 있다고 판단해 적을 더 현실적인 장애물로 바꾸었다.
   5. 최종 적 목록: Skull Creeper, Procurement Manager, Reply Guy 등이 등장했고, 포식적 VC(predatory VC)는 Joker처럼 보여 특히 우스꽝스럽게 표현됐다.
   6. 적별 이미지: AI는 각 적 유형에 맞는 이미지를 별도로 생성했다.

8. 배포와 모바일 대응

   1. ChatGPT Sites 배포: No Moat은 2D 게임이라 Godot 기반 3D 게임보다 배포가 쉽고, ChatGPT Sites에 올릴 수 있었다.
   2. 공개 설정: 생성된 웹 페이지는 기본적으로 공유 대상에게만 열리므로, Share 메뉴에서 권한을 public으로 바꿔 웹의 누구나 플레이하게 해야 한다.
   3. 마지막 품질 작업: 추가 수정, polish pass, balance pass를 거쳐 ship-ready 상태를 요청했다.
   4. 모바일 문제: 모바일에서 테스트하자 화면이 매우 나쁘게 보였고, 모바일에서도 보기 좋도록 레이아웃을 개선하게 했다.
   5. 소요 시간: 반복적인 대화와 플레이를 약 두 시간 진행해 기술 데모가 아니라 실제로 플레이 가능한 게임에 가깝게 만들었다.
   6. 후속 계획: 로그라이크 덱 빌더 장르를 특히 좋아하기 때문에 개인적으로도 계속 개선할 계획이다.

6. 공통 제작 루프와 Astra의 실제 한계

6.1. 복잡한 프롬프트보다 아이디어·이미지·피드백

1. 과거의 실패 방식

   1. 몇 달 전의 접근: 불과 몇 달 전만 해도 plan mode와 긴 elaborate prompt를 사용해 AI에게 게임을 만들게 했지만 제대로 성공하지 못했다.
   2. 현재의 변화: 이제는 대부분의 게임을 아이디어를 AI와 함께 탐색하고, 레퍼런스 이미지를 만들고, Astra에 중간 피드백을 주는 방식으로 만들 수 있다.

2. 실제 작업의 간결함

   1. 음성 입력: 시연한 프롬프트의 절반은 가족과 외출한 상태에서 휴대전화로 대충 말한 음성 받아쓰기였다.
   2. 역할 변화: 모델이 유능한 게임 디자이너나 개발자처럼 대화 내용을 이해하고 일을 끝낼 정도로 좋아졌다.
   3. 세 단계 루프: 아이디어를 브레인스토밍하고, ChatGPT 이미지로 콘셉트 아트를 만들고, AI에게 구현과 피드백을 반복하는 세 단계가 핵심이다.

3. 시간과 품질의 관계

   1. Dustline과 세 데모: 세 게임은 짧은 반복 작업으로 기술 데모를 만들었다.
   2. No Moat의 차이: 실제 게임에 가까운 완성도를 얻으려면 약 두 시간 동안 밸런스·아트·모바일 대응을 반복해야 했다.
   3. 개발자의 역할: 코드를 직접 작성하지 않아도 플레이어 경험, 난이도, 적의 행동, 그래픽 방향을 판단하고 구체적인 피드백을 주는 일은 여전히 필요하다.

6.2. Astra 출시를 둘러싼 반발과 공정한 평가

1. 출시 방식의 문제

   1. 선공개 홍보: OpenAI가 블로그 글과 보도자료를 내고, 일주일 동안 모델을 써본 인플루언서들이 얼마나 멋진지 말하게 했다.
   2. 일반 사용자의 접근 불가: 홍보가 진행될 때 정작 일반 사용자는 모델을 사용할 수 없었다.
   3. 책임의 불확실성: 모델을 언제 출시할 수 있는지 결정하는 데 제3자가 관여할 가능성이 있어 OpenAI의 전적인 잘못이 아닐 수도 있다.

2. 창작자로서의 비판

   1. 과도한 사전 과장: 모델이 모든 사람에게 실제로 제공되기 전부터 과열된 기대를 만드는 것은 불필요하다.
   2. 바람직한 출시 시점: 모든 사람이 사용할 수 있는 순간에 출시하고, 그때 실제로 무엇을 할 수 있는지 보여주는 편이 낫다.
   3. 정직한 검증: 거의 매주 새 모델이 나오는 현실에서 모든 모델이 삶을 바꾸는 것은 아니므로, 무조건적인 과장보다 직접 만든 결과와 솔직한 의견을 공유해야 한다.

주요 발언 모음

“Astra는 내가 지금까지 게임을 만들 때 사용한 모델 중 단연 최고다.”

“20달러 ChatGPT Plus 플랜만으로도 꽤 멀리 갈 수 있다. Higher나 Ultra가 꼭 필요한 것은 아니다.”

“플레이어 경험을 먼저 설명하고, 콘셉트 이미지로 외관을 정하고, 반복 가능한 플레이테스트를 일찍 만들며, Blender로 독특한 자산을 만들어라.”

“게임이 더 좋아졌지만 여전히 지루하다. 파워업을 추가하고, 적을 더 어렵게 만들고, 우주 정거장이 무너지는 것처럼 보이게 하라.”

“재미있는 게임은 그래픽만으로 만들어지지 않는다. 밸런스, 핵심 루프, 진행 시스템이 필요하다.”

“이 모델들은 유능한 게임 디자이너나 개발자와 대화하듯 말하면 일을 끝낼 정도로 좋아졌다.”

“어린 시절의 게임과 상상 속의 게임을 만들어라. 아이들과 함께 만들면 놀라운 가족 활동이 된다.”

핵심 데이터 & 수치

• 4개 게임: Star Fox형 우주 슈터, Dustline 이동 열차 FPS, Ashfall StarCraft형 RTS, No Moat 로그라이크 덱 빌더를 동시에 제작했다.
• 작업 시점: 네 게임을 금요일 밤에 동시에 만들었다.
• 모델 설정: Astra medium 설정을 사용했으며 higher·ultra가 필수는 아니라고 평가했다.
• 요금제: 20달러 ChatGPT Plus 플랜으로도 충분히 시도할 수 있다고 말했다.
• 도구 비용: Blender와 Godot는 무료 오픈소스 도구이며 Godot MCP·Blender MCP를 연결했다.
• Star Fox 개선 시간: 약 3분의 대화 뒤 무너지는 우주 구조물·장애물·윙맨·보스가 포함된 버전에 도달했다.
• Dustline 제작 흐름: 아이디어 탐색과 피드백 전체가 약 30분에서 1시간 정도 걸렸으며, 그동안 다른 세 게임도 동시에 작업했다.
• Ashfall 프롬프트 수: 대략 열두 개 정도의 프롬프트로 제작했다.
• No Moat 구성: 세 개의 스테이지, 여러 동료와 카드, 각 레벨의 미니 보스, 후반의 Major Bug 전투를 포함한다.
• No Moat 제작 시간: 실제 플레이 가능한 수준으로 만들기 위해 약 두 시간 동안 반복 대화·테스트·밸런스 작업을 했다.
• No Moat 초기 명세: product design과 tech stack으로 나눈 HTML 스펙을 먼저 만들었다.
• 아이디어 생성 단위: 각 장르에서 상위 다섯 개 아이디어를 요청해 최종 콘셉트를 골랐다.
• Dustline 계획 단위: 한 번에 만들기보다 세 마일스톤으로 나눠 중간 테스트를 진행했다.
• No Moat의 공개 방식: ChatGPT Sites는 기본적으로 공유 대상만 접근할 수 있으므로 public 권한으로 바꿔야 한다.

결론 및 시사점

1. 모델보다 작업 루프가 중요하다: Astra의 핵심 장점은 한 번에 완성된 게임을 내놓는 능력이 아니라, 아이디어·레퍼런스 이미지·도구 조작·플레이테스트·피드백을 짧은 루프로 연결하는 능력이다.
2. 비개발자도 진입할 수 있다: Blender와 Godot를 직접 익히지 않아도 무료 MCP 연결과 자연어 지시로 3D 자산과 게임 엔진을 사용할 수 있다.
3. 레퍼런스 이미지가 요구사항 문서 역할을 한다: “더 예쁘게”라는 추상적 말보다 목표 장면을 이미지로 보여주는 편이 AI가 원하는 그래픽·무대·적 디자인을 이해하는 데 효과적이다.
4. 초기 산출물은 기술 데모로 취급해야 한다: Star Fox, Dustline, Ashfall은 작동하는 장면을 보여주지만, 실제 게임이 되려면 재미·난이도·보스 행동·진행 시스템을 계속 조정해야 한다.
5. 게임성은 그래픽과 별개다: No Moat 사례처럼 핵심 루프와 밸런스, 적의 개성, 보상 선택, 모바일 레이아웃을 반복해서 다듬어야 플레이 가능한 게임이 된다.
6. 자연어와 음성 입력이 창작 속도를 높인다: 절반의 프롬프트가 가족과 외출하며 한 음성 받아쓰기였다는 점은 정제된 개발 문서보다 빠른 관찰과 피드백이 더 중요해졌음을 보여준다.
7. 인간의 역할은 판단과 방향 설정으로 이동한다: 코드 한 줄을 보지 않아도 플레이어가 무엇을 느껴야 하는지, 적이 얼마나 공격적이어야 하는지, 어느 웨이브가 너무 어려운지 판단해야 한다.
8. Astra의 출시 평가는 실제 접근성까지 포함해야 한다: 누구나 사용할 수 없는 상태에서 인플루언서와 보도자료로 기대를 높이는 방식은 반발을 부를 수 있으며, 일반 접근이 가능해진 뒤 실제 결과로 평가받는 편이 투명하다.
9. 창작의 가장 좋은 출발점은 개인적 기억이다: Star Fox와 StarCraft처럼 어린 시절 좋아했던 게임을 출발점으로 삼으면 장르·기능·분위기에 대한 피드백이 구체적으로 나온다.
10. 가족 단위 창작 활동으로 확장된다: Astra와 무료 게임 도구를 사용하면 어린 시절 게임뿐 아니라 상상 속 게임을 아이들과 함께 만들 수 있고, 게임 개발 경험의 진입장벽이 가족 활동 수준까지 낮아진다.