Riposte 제작기 - AI와 함께 게임을 만든다는 것
최근 자주 가는 개발자 디스코드 서버에서 작은 AI 게임 만들기 이벤트가 열렸습니다. 조건은 단순했습니다. AI를 사용해 게임을 만들면 된다는 것. 그래서 저는 한 가지 규칙을 정했습니다. 코드는 직접 한 줄도 작성하지 않고, AI만 사용해서 게임을 만들어보기로요.
이름은 Riposte


장르는 짧게 설명하면 뱀서류에 패링 액션을 섞은 게임입니다. 기본적으로는 몰려오는 몬스터를 반격으로 처리하여 성장하는 방식인데, 핵심은 몬스터가 공격하기 직전 타이밍에 맞춰 응수 버튼을 누르는 것입니다.
타이밍이 맞으면 캐릭터가 앞으로 돌진하면서 몬스터를 받아치고, 잘 맞추면 퍼펙트 패리로 더 큰 보상을 받습니다.
만들고 나서 돌아보니, 이 작업은 단순히 “AI가 코드를 대신 써줬다”는 이야기라기보다 아이디어를 실험하는 비용이 얼마나 낮아졌는지에 대한 경험에 가까웠습니다.
이 게임은 https://hexpy.games/games/riposte 에서 플레이해보실 수 있습니다. 콘셉트가 잡힌 뒤 실제로 플레이 가능한 형태가 되기까지는 이틀 정도 걸렸습니다.
1. 한 문장이 PoC가 되는 세상
이번에는 특별한 방법론이나 개발 이론을 앞세우지 않았습니다. 일단 아이디어를 하나 떠올리고, Claude.ai를 켜서 그대로 프롬프트에 입력했습니다.
쿼터뷰 복셀로 뱀파이어 서바이버와 같은 장르의 웹 게임을 만들어줘. 같은 아이템을 먹으면 무기 레벨 업, 다른 아이템을 먹으면 새 무기 획득. 무기가 레벨업되면 쓸어내는 재미가 있도록 해줘. 구현을 위해 더 필요한 정보가 있으면 요청해.
일단 어떻게 나오는지 보고 싶었고, 아이디어가 실제로 움직이는지도 확인해보고 싶었습니다.
클로드는 저에게 세 가지 정도 질문을 한 후, 실제로 작동하는 단일 HTML 파일 하나를 주었습니다.

이리저리 움직여보며 꽤 괜찮은데? 라는 생각이 들자 저는 계속해서 아이디어를 구체화하는 요청을 던져가며 게임에 살을 붙였습니다.
2. 게임을 직접 경험하며 완성시켜 나가다
Riposte를 만드는 동안 저는 코드를 만드는 개발자라기보다는 플레이어이자 감독이자 테스터에 더 가까웠습니다.
작업 방식은 대략 이랬습니다.
- 아이디어를 제시한다.
- AI가 큰 구조를 만든다.
- 내가 직접 플레이해본다.
- 이상한 점을 바로 말한다.
- AI가 수정한다.
- 다시 플레이한다.
- 더 구체적인 피드백을 준다.
이런 피드백은 완성된 스펙 문서라기보다는 플레이 감각 리포트에 가까웠습니다. 하지만 게임에서는 이게 꽤 중요했습니다. 기능상 맞아도 손맛이 없으면 실패고, 숫자가 맞아도 화면에서 읽히지 않으면 실패이기 때문이었죠.
결국 제가 한 일은 “정답 코드 작성”보다 실패 판정 기준을 계속 제시하는 것에 가까웠습니다.
3. 프롬프트는 짧지만 기준은 명확하게
이번 작업에서 사용한 프롬프트들은 대부분 길고 정교한 명세 대신 짧은 피드백과 방향성을 제시하는 형태였습니다.
게임이 재미없다고 느껴진다면 “이 부분이 재미없다”라는 피드백을 주기보다, 왜 재미없게 느껴지는지를 먼저 생각했습니다.
그래서 “게임을 더 재미있게 해줘”라고 하지 않고,
지금 긴장감이 부족하다. 고레벨 몬스터는 마력탄을 발사하게 해라.
플레이어 마력탄이랑 헷갈리지 않게 다른 색이어야 한다.
이처럼 플레이어 경험 기준으로 무엇이 문제이고 어떻게 해결할 것인지를 항상 같이 제시했습니다.
이 방식이 이렇게 작은 게임 제작에는 잘 맞았습니다. 게임은 문서로만 맞출 수 없는 부분이 많습니다. 화면에서 읽히는지, 누르는 맛이 있는지, 너무 사기인지, 너무 밋밋한지 같은 건 결국 직접 해봐야 아는 부분이니까요.
4. 게임의 방향을 바꾸다
뱀서라이크였던 만큼, 처음에는 자동 공격 무기들이 중심이었습니다. 마력탄, 폭탄, 회전 칼날, 광선 같은 무기들이 레벨업하면서 적을 쓸어버리는 구조였죠.
하지만 만들수록 애매해졌습니다.
자동 공격 중심의 구조는 안정적이었지만, 살을 붙일수록 “3D 쿼터뷰 뱀서 복제 게임”에 가까워졌습니다.
또 제 취향도 작용했습니다. 피하면서 몬스터를 많이 쓰러뜨리는 게임보다, 적진 한가운데로 뛰어들어 타이밍을 맞추고 받아치는 능동적인 게임이 더 재미있겠다고 느꼈습니다.
그래서 중간에 구조를 크게 바꿨습니다.
몬스터들의 공격 타이밍에 맞춰 패링을 해나가면서 몬스터를 쓰러뜨리고 성장해나가는 게임으로 말이죠.
기존 시스템을 모두 버리기보다는 응수라는 시스템에 맞는 요소들로 탈바꿈시켜서 큰 이슈 없이 거의 바로 게임의 시스템을 전환할 수 있었습니다.
이것도 전부 AI 덕분에 빠르게 아이디어를 선회해볼 수 있었던 것이죠.
5. 모델 성능이 우선이라는 생각
이번에는 특별한 방법론을 썼다고 하긴 어렵습니다. 컨텍스트 엔지니어링, 프롬프트 엔지니어링 기법을 새로 연구해서 사용하지도 않았습니다. 물론 기존에 사용하던 프롬프트와 컨텍스트 관리 기법은 그대로 사용했지만, 이번에는 그냥 계속 만들고, 보고, 고치고, 다시 보는 식이었습니다.
그런데도 꽤 그럴듯한 결과가 나왔습니다.
결국 이 반복 속도와 안정감은 상당 부분 모델 성능에 기대고 있었습니다.
지금은 사람에게 지시하듯 정확한 원인과 방향을 지정하면, 어느 정도 기대에 부응하는 코드를 만들어냅니다.
덕분에 자연어에 가까운 대화를 통해 꽤 빠르게 피드백을 진행할 수 있었습니다.
그래서 솔직히 말하면, 이번 경험에서 가장 크게 느낀 건 모델 성능이 우선이다라는 점입니다.
6. 리소스 제작의 한계
반대로 한계도 있었습니다.
음악의 경우는 Suno를 통해 비교적 수월하게 해결했지만, UI와 캐릭터 모델링의 경우는 상황이 좀 달랐습니다.
캐릭터 모델링은 몬스터와 캐릭터 모두 큐브를 조합한 형태를 사용하고 있었는데, 몬스터의 형태는 비교적 잘 잡는 반면에 캐릭터의 각 부위는 의외로 생김새와 연결 짓지 못하고 수정에 빈번히 실패했습니다. 더 작은 단위로 나눠서 시도해도 실패했고, 아직까지 3D는 LLM들에게 먼 영역인 것처럼 느껴졌습니다.
결국 캐릭터 모델은 직접 모델링할 수밖에 없었죠.
7. 버그를 찾아내는 방법
UI나 인터랙션, 게임플레이의 외적인 부분은 눈으로 보면서 고칠 수 있었고, 게임의 내적인 부분이나 퍼포먼스 문제는 로깅으로 잡아낼 수 있었습니다.
후반에 적이 많아서 느려지다가 게임 프레임이 프리징되는 부분이 있었는데, 이 경우에는 단순히 “이 부분에서 문제가 발생했으니까 검사해봐라”라는 프롬프트로는 해결할 수 없었습니다.
대신 프레임과 오브젝트 숫자, 종류 등을 로그로 남기고 의심되는 오브젝트와 효과들을 하나하나 제외해가며 소거법으로 접근해서 의심되는 부분을 찾아냈을 때, 비로소 문제를 찾아낼 수 있었습니다.
여기 이런 행동이 일어날 때 프리징이 걸렸어. 재현 조건은 이렇고 이런 타이밍에 발생해. 혹시 할당해놓고 제때 수거하지 않아서 성능에 영향을 주고 있지는 않은지 확인해봐.
그리고 마침내 문제를 해결했습니다.
모델은 게임을 직접 플레이할 수 없습니다. 결국 게임 안에서 여러 오브젝트가 얽히며 생기는 문제는, 직접 플레이한 사람이 재현 조건과 로그를 모아 전달해야 했습니다.
“렉이 걸린다”는 말보다, 언제 어떤 오브젝트가 얼마나 있었고 어떤 이벤트 직후 프레임이 떨어졌는지가 훨씬 강한 프롬프트였습니다.
결론: AI가 PoC의 비용을 무너뜨렸다
이번 작업을 하면서 “그래서 결국 AI가 다 한 것이 아닌가” 한다면 반은 맞고 반은 틀린 것 같습니다.
저는 이번에 한 줄의 코드도 직접 작성하지 않았습니다. 제가 생산했어야 했던 코드들은 전부 AI가 생산해냈습니다.
대신에 저는 어떤 행동들이 재미있었는지 테스트하고, 어떤 이펙트가 좋은지 안 좋은지, 경제 밸런스는 적당한지 등 게임을 경험하면서 게임의 방향을 수정해나가는 데 좀 더 집중할 수 있었습니다.
그래서 제 감상은 이렇습니다.
AI가 제품 감각을 대신해준 것은 아니다.
하지만 제품 감각을 실험해볼 수 있는 비용을 엄청나게 낮췄다.
예전에는 아이디어를 제품처럼 만져보기까지 시간이 많이 들었습니다.
지금은 한 문장으로 시작해서, 플레이 가능한 상태를 만들고, 여러 아이디어를 테스트해가면서 제품화 쪽으로 가능성을 점쳐볼 수 있습니다.
Riposte는 그런 방식으로 만들어진 게임입니다. 처음부터 완벽한 계획이 있었던 게 아니라, 일단 던지고, 만져보고, 재미없는 부분을 버리고, 살아남은 감각을 중심으로 다시 만든 결과물입니다.
물론 Riposte가 지금 당장 완성도 높은 게임이냐고 묻는다면, 아직은 아니라고 생각합니다. 다만 제가 머릿속으로 생각했던 게임플레이의 기반을 실제로 만져볼 수 있는 시험대로는 충분했습니다.
여러 사람의 피드백을 받아서 고칠 부분이 많이 남아있고, 정말 재미있는 하나의 완성된 게임이 되기까지는 많은 단계가 남아있지만, 그 가능성을 검토하고 시험하는 주기가 지금까지의 게임 개발 방법과는 많이 다른 경험이었습니다.
아마 앞으로는 “이거 될까?”라고 오래 고민하기보다,
“일단 던져보고 만져본 다음 판단하자”는 쪽이 더 자연스러워질 것 같다는 생각이 드는 작업이었습니다.