Stress-Testing Gemini 4 Argon: Building a 3D Flutter Kart Game in 15 Prompts with Zero Assets
Gemini 4 Argon 스트레스 테스트: 외부 에셋 없이 프롬프트 15개로 3D Flutter 카트 게임 만들기
Gemini 4 Argon으로 외부 3D·이미지 에셋 없이 Flutter 카트 게임을 만들고 WebAssembly로 배포한 과정을 공개했습니다. 15개 프롬프트와 3시간 26분이 걸렸으며, 화면을 확인하고 사용자 피드백을 반영하는 과정에서 시각 요소와 오디오, 배포 문제를 고쳤습니다.
- 주제
에디터 노트
이 사례에서 설득력 있는 대목은 코드 생성량보다 피드백과 실행 결과를 연결한 과정입니다. 작성자는 캐릭터를 뒤에서 본 화면, 음악 루프의 잔향, 배포 브라우저의 네트워크 로그를 근거로 문제를 좁혔고 모델이 이를 수정했습니다. 특히 .gitignore 문제는 생성 코드의 품질만으로는 배포 성공을 판단하기 어렵다는 점을 구체적으로 보여줍니다. 다만 96.7%의 코드 공유율과 7분 미만의 웹 전환은 작성자가 만든 이 게임과 개발 환경의 결과입니다. Flutter 3D 프로젝트 전반에 그대로 적용되는 수치로 제시되지는 않았습니다. 댓글은 화면 캡처 없이도 모델이 카메라 시점 문제를 알아챌 수 있었는지 물었지만 답은 없습니다. 따라서 이 사례가 보여주는 범위는 자율적인 문제 발견보다 실행 화면과 사람의 피드백을 포함한 반복 작업에 있습니다.
AI 요약
작성자는 일반적인 웹 앱 대신 60FPS를 목표로 하는 Mario Kart 스타일의 3D 카트 게임을 Gemini 4 Argon과 Antigravity로 만들었습니다. Blender 모델, 이미지 텍스처, 외부 음원 없이 게임의 3D 형상과 텍스처, 소리를 코드로 생성했습니다. 빈 폴더에서 GitHub Pages 배포까지 프롬프트 15개를 사용했고, 실제 작업 시간은 3시간 26분이었습니다. 플레이 테스트를 포함한 전체 시간은 4시간 35분입니다.
게임 구성과 시각적 수정
초기 프롬프트로 트랙과 플레이 가능한 캐릭터 4종, 3단계 드리프트 부스트, 점프대, 코인, 아이템 7종을 만들었습니다. 캐릭터와 카트는 flutter_scene과 Flutter GPU를 사용해 구, 원뿔, 캡슐, 고리, 상자 같은 기본 도형을 조합했습니다. 아스팔트 질감과 타이어 자국, 표면 범프 맵도 앱 실행 시 메모리에서 생성합니다.
처음 만든 Flutter Dash는 캐릭터 선택 화면에서는 알아보기 쉬웠지만, 실제 경주에서는 뒤통수만 보여 파란 공처럼 보였습니다. Gemini 4 Argon이 실행 중인 게임 화면을 캡처한 뒤 문제를 파악했고, 고글 끈과 펄럭이는 빨간 스카프, 꼬리 깃털, 기울어진 날개를 추가했습니다. 작성자는 카메라 시점에 따른 외형 문제를 모델이 스크린샷을 확인한 뒤 수정한 사례로 설명합니다.
오디오 생성과 피드백
처음에는 Dart로 사인파와 사각파를 합성해 음악과 효과음을 만들었습니다. 작성자가 음악이 저렴한 8비트 장난감 소리처럼 들린다고 피드백하자, 모델은 macOS에 포함된 Roland MIDI 악기 라이브러리를 사용했습니다. Swift 스크립트로 여러 트랙의 브라스, 슬랩 베이스, 재즈 오르간, 드럼을 재생하고 스튜디오 리버브를 적용해 스테레오 WAV 파일로 내보냈습니다.
새 음악은 14초마다 루프가 다시 시작될 때 짧게 끊겼습니다. 시작 지점에는 리버브 잔향이 없고 끝 지점에는 앞선 음의 잔향이 남아 생긴 문제였습니다. 모델은 8마디 루프를 세 번 연속 렌더링한 뒤 가운데 구간을 잘라냈습니다. 앞 구간의 잔향이 이어지는 두 번째 테이크를 사용해 루프 경계의 클릭음을 없앴습니다. 작성자는 모델이 처음부터 최선의 결과를 냈다기보다 사람의 피드백을 받은 뒤 다른 접근을 찾았다고 강조합니다.
Flutter와 WebAssembly 배포
게임은 Flutter의 60Hz Ticker로 물리 처리를 하고, 3D 렌더링에는 flutter_scene을, 속도계와 미니맵, 아이템 표시 같은 2D HUD에는 CustomPainter를 사용합니다. 처음 12개 프롬프트 동안 macOS 앱에서 개발한 뒤 웹 실행을 요청했습니다. Dart 코드 12,082줄 가운데 96.7%는 수정 없이 WebAssembly로 빌드됐습니다. 오디오 플레이어만 macOS 명령줄 오디오와 브라우저 HTML5 오디오를 구분하도록 조건부 import 세 줄을 추가했습니다. macOS 게임을 Chrome에서 실행하기까지 7분도 걸리지 않았다고 합니다.
GitHub Pages에 배포한 뒤에는 로딩 화면에서 멈췄습니다. 모델이 headless Chrome으로 배포된 페이지와 네트워크 로그를 확인해 3D 셰이더 번들이 404를 반환하는 문제를 찾았습니다. flutter_scene이 생성한 폴더에 빌드 산출물을 Git에서 제외하려고 넣은 .gitignore 파일이 웹 빌드 결과에도 복사됐고, GitHub Pages 배포 과정에서 셰이더 파일까지 무시된 것이 원인이었습니다. 배포 전에 build/web 안의 .gitignore 파일을 삭제해 문제를 해결했습니다.
작성자는 개발 과정에서 드러난 한계로 캐릭터를 앞에서만 설계한 점, 첫 오디오 결과에 만족한 점, AI 운전자를 기준으로 게임 속도를 높게 잡은 점을 꼽습니다. 속도가 약 22% 빨라 사람이 코너를 돌기 어려웠고, 작성자가 속도를 낮춰 달라고 요청했습니다.
dev.to 반응
- @pengeszikra — 고맙습니다. 정말 통찰력 있는 작업 과정이네요. 이제 누구나 조금씩 자기만의 게임을 만들 수 있겠어요.
- @alexcodebytes — 셰이더를 전부 먹어버린 교묘한 .gitignore 버그가 이 글에서 가장 솔직한 대목입니다. AI 코딩 데모는 모델이 기술적으로는 맞는 일을 했지만 누구도 예상하지 못한 방식으로 배포를 망가뜨리는 부분을 빼곤 합니다. 오디오 사례도 에이전트가 피드백을 받고 회복하는 모습을 잘 보여줍니다. 8비트 삑 소리에서 macOS MIDI 사운드뱅크로 옮겨간 건 단순히 더 나은 답을 내놓은 게 아니라 처음에는 쓰지 않았던 지식을 모델이 떠올린 사례입니다. 올바른 코드를 생성하는 능력과는 다른 역량입니다. 카메라 시점 문제는 궁금합니다. 스크린샷 없이도 스스로 고쳤나요, 아니면 항상 스크린샷이 필요했나요? 에이전트가 자기 결과물을 직접 확인하는 방식이 실제 개발 작업에 가장 가까워 보이는데, 대부분의 프레임워크는 아직 이를 지원하지 못하는 것 같습니다.
- @sebastian_sterhaug_f1661 — Eurot Eouyteeyiejfelgreogeeoteoterohr😪
원문: dev.to / 번역·요약: Trawling