플레이 가능한 결과물 만들기 (Part 1): AI 생성 게임의 문제는 AI 자체가 아니다

여러분도 아실 겁니다. 누군가 채팅창에 세 줄 정도를 입력하면, 화면에 '생각 중...' 메시지가 나타나고 작은 사각형이 튕기는 캔버스가 팝업됩니다. 그러더니 같은 사람들이 게임 디자인이나 글쓰기, 예술 등이 죽었다고 떠들기 시작합니다.

저는 그런 것을 보면서 짜증을 느낍니다. 그리고 그것은 단순히 무작위 소셜 미디어 게시물에 국한되지 않습니다. 주변 사람들도 똑같은 일을 하면서 자신들이 게임을 '만들었다'며 스스로를 칭찬하는 모습을 봅니다.

프롬프트를 입력하고 지저분한 HTML 파일 하나를 받는 것은 게임을 만드는 것이 아닙니다. 그것은 간단한 기술 데모일 뿐입니다. 이러한 종류의 'AI 게임' 과장된 프로토타입들은 원시적인 단일 프롬프트 코드 덤프이거나, 휴대폰에 맞게 확장되지 않는 UI이거나, 혹은 아무도 두 번 방문하지 않을 기본 로바블 링크(lovable link)에 호스팅된 무언가입니다. 기술적으로는 물론 게임이라고 할 수 있습니다. 하지만 이 도구들이 실제로 무엇을 할 수 있는지 측면에서 보면, 현재 AI 도구들의 'Hello World' 프로그램만큼이나 인상적이지 않습니다. 그 결과물을 슬롭(slop)이라고 부르기 쉬운데, 왜냐하면 그것이 바로 그런 것이기 때문입니다.

이러한 좌절감 때문에 저는 게임 디자이너로서 제가 하는 방식에 대한 이 모음집을 만들 시간을 썼습니다. 저는 이러한 도구들을 사용해 왔고, 실제로 공유하고 개선할 수 있는 게임을 만드는 방법을 찾아냈습니다. 그것들은 어떤 의미에서도 크고 상세한 게임은 아니지만, 제가 자랑스러워할 수 있고, 친구들과 공유할 수 있으며, 실제로 개선할 수 있는 실험적인 게임들입니다.

여기서 복잡한 소프트웨어 공학에 대해 설교하려는 것은 아닙니다. 제가 하는 일은 여전히 매우 간단하지만, 실제 구조를 가지고 있습니다. 원하신다면 제가 만드는 게임들을 여전히 슬롭이라고 부를 수도 있겠지만, 적어도 그것은 의도적으로 만들어진 슬롭이며, 제 생각에는 게임을 만들기 위한 유효한 출발점으로 간주될 수 있는 기반을 갖추고 있기 때문입니다.

이 모든 과대광고를 보고, 기술적 배경 지식이 전혀 있을 때 실제로 무엇이 가능한지 궁금해하고, 자신의 아이디어를 실제 플레이어가 시도할 수 있는 무언가로 실용적으로 만들 방법을 원하는 분들에게 이 가이드가 적합합니다.

우선, 중요한 주의사항을 말씀드리자면: 저는 코딩 경험이 없습니다. 저는 단지 16년 넘게 전문적으로 게임을 디자인해 온 게임 디자일 뿐입니다 (너무 자랑하는 것 같지만).

코딩 실력에 있어서 저를 '초보자'라고 부르지도 않을 겁니다. 저는 코드를 어떻게 짜는지 잘 모릅니다. 파일이 어디에 존재하는지는 이해할 수 있고, 아니면 눈을 가늘게 뜨고 보면 무슨 일이 일어나고 있는지 정도는 이해할 수 있지만 그게 전부입니다. 이러한 이해가 제가 직접 고치거나 발전시킬 수 있는 무언가로 이어지지는 않습니다. 바로 이 지점에서 AI 도구들이 저에게 도움이 되었습니다.

그렇긴 하지만, 제가 해낼 수 있었던 것은 실제로 작동하는 몇 가지 짧고 간소한 워크플로우를 만드는 것이었습니다. 이것들은 분명 완벽하지는 않습니다. 저는 새로운 것이나 급진적인 것을 제안하는 것이 아니며, 여러분이 대박을 터뜨려 백만장자가 될 거라고 가장할 생각도 없습니다.

저의 워크플로우 덕분에 실제로 작동하는 결과물을 만들어낼 수 있었습니다. 이는 제가 머릿속에 있는 아이디어를 꺼내고, 그것을 구축하고, 실제 플레이어들 앞에 내놓아 아이디어 구상 능력을 향상시키는 데 도움을 주었습니다. AI를 사용하여 이러한 워크플로우를 알아가는 여정에서 제가 만든 게임 몇 가지 예시는 playable-things.itch.io에서 확인하실 수 있습니다.

다음 몇 개의 게시물에 걸쳐, 지난 몇 달 동안 실제로 플레이 가능한 결과물을 빠르게 만들게 해준 저의 과정을 공유하려고 합니다. 따라오고 싶으시다면, 함께 자신만의 작은 AI 게임 프로젝트를 만들어 보세요 :

Part 1 (이번 글): 단일 프롬프트 게임 만들기 중단하기.

AI를 슬롯머신처럼 다루기보다 협업자로 취급하고, WHY(이유), WHAT(무엇을), HOW(어떻게)를 종이에 먼저 구상하는 것입니다.

Part 2: 프로젝트 설정하기.

사용할 AI 도구를 선택하고, 로컬 폴더를 설정하며, 코드를 건드리기 전에 메모를 명확한 사양으로 바꾸는 것입니다.

Part 3: 구축 및 수정하기.

계획을 비판적으로 읽고, 환각(hallucination)을 초기에 포착하며, 시각적 에셋을 준비하고, 첫 번째 localhost 빌드를 실행하는 것.

Part 4: 컴퓨터에서 꺼내기.

루프를 테스트하고, 목표 지향적인 버그 수정(bug fixing), 채팅 위생(chat hygiene)을 관리하며, 사람들이 실제로 플레이할 수 있도록 itch.io용으로 패키징합니다.

가장 먼저 빠지기 쉬운 함정부터 시작하겠습니다.

단일 프롬프트의 착각 (The Delusion Of The Single Prompt)

AI를 사용하는 가장 간단한 방법은 채팅 창을 열고 원하는 것을 입력하는 것입니다. 하지만 이는 스스로를 구석에 몰아넣는 가장 빠른 방법이기도 합니다.

단지 LinkedIn 피드에 올릴 무언가를 빠르게 생성하여 게임을 플레이하지 않는 사람들에게 박수를 받고 싶다면 괜찮습니다. 채팅 창의 단일 프롬프트로 충분합니다.

하지만 실제로 유지보수하고, 수정하며, 친구들과 공유할 수 있는 게임을 만들고 싶다면, 하나의 채팅 스레드에 의존하는 것은 재앙이 될 준비를 하고 있는 것과 같습니다.

첫 번째 프롬프트 이후에 무슨 일이 일어날지 생각해 보세요:

• 변경 사항을 요청하기 시작하면 그 채팅 스레드는 얼마나 오래 유지될까요?
• 채팅 내용이 방대해졌을 때 AI가 미친 듯이 환각(hallucination)을 일으키고 작동하던 메커니즘을 망가뜨리는 것을 어떻게 막을 수 있을까요?
• 점수 시스템을 삭제하고 전체 파일을 다시 작성하기로 결정하는 모델 때문에 단순히 점프 높이나 타이머만 수정하고 싶을 때는 어떻게 될까요?
• 3일 후에 초기 디자인 결정을 변경하고 싶다면 어떨까요? 단일 채팅 스레드에서는 모든 것이 스파게티처럼 무너집니다.

AI는 그저 텍스트 생성기입니다. AI는 사용자의 비전(vision)을 '이해'하는 것이 아니라, 단순히 다음에 올 개연성 있는 텍스트 조각을 예측할 뿐입니다. 모호한 프롬프트를 주면, 자신이 동원할 수 있는 가장 일반적인 내용으로 빈칸을 채웁니다.

그리고 같은 끝없는 채팅 스레드 안에서 이를 수정하려고 하면, 실제로 플레이 가능한 것을 디자인하는 것보다 환각된 버그와 토큰 과부하(token bloat)를 싸우는 데 더 많은 시간을 쓰게 됩니다.

한 줄 프롬프트 테스트 (The One-Line Prompt Test)

AI는 예언가처럼 당신의 생각을 읽어주는 존재가 아니라 도구입니다. 마치 당신이 생각하기도 전에 원하는 것을 아는 마법 상자처럼 대할 것이 아니라, 매우 문자 그대로의 협력자로 다루어야 합니다.

제 말을 믿지 않아도 됩니다. 지금 바로 가장 좋아하는 AI 채팅창을 열고 이 모호한 프롬프트를 입력해 보세요:

스페이스 인베이더스 같은 게임을 만들어 주세요. 다만 농장 테마로 하고, 제가 허수아비가 되어 제 농장에 착륙하는 새들을 쫓는 내용으로 해주세요. 아늑한 아트 스타일을 사용하고, 난이도가 다른 10개의 레벨을 만들어 주세요.

진행해 보세요. 실행해 보세요.

게임 하나를 받게 될 겁니다. 하지만 그것은 AI가 즉석에서 상상하는 것이 될 것입니다. Gemini, ChatGPT, Claude에 이 프롬프트를 넣어본 결과 스크린샷이 여기 있습니다.

Ishan Manjrekar's image-9ddfa

단 한 줄의 테마만으로는 게임 디자이너가 될 수 없습니다. 아무리 영리한 프롬프트를 작성하는 것이 자신을 창작자로 만든다고 스스로를 설득하더라도, 그렇지 않습니다. 만약 당신이 진심으로 그렇게 믿는다면, 그저 'delulu slop-ster'일 뿐입니다.

AI는 코드를 모르는 사람도 게임을 만드는 데 확실히 도움을 줄 수 있지만, 오직 당신 자신이 실제 디자인 결정을 내릴 때만 가능합니다. 규칙, 조작(controls), 상호 작용(interaction)을 프롬프트 창에 맡기는 순간, 당신은 게임을 디자인하는 것이 아닙니다. 단지 기계가 대신 주사위를 굴리도록 허락하는 것일 뿐입니다.

디자인 방향: WHY, WHAT, HOW

진짜 게임 디자인이 필요한 곳이 바로 여기입니다.

기계를 작동시키라고 요청하기 전에 무엇을 원하는지 알아야 합니다. 이 분야에서 전문적으로 상당한 시간을 보내면서 저는 이것이 게임에 대해 한 번도 작업해 본 적이 없는 사람에게는 위협적으로 들릴 수 있다는 것을 압니다. 작은 게임의 경우, 50페이지짜리 디자인 바이블(design bible)이 필요하지 않습니다. 단지 왜(WHY), 무엇을(WHAT), 그리고 **어떻게(HOW)**라는 세 가지 기본적인 질문에 대한 명확한 답변만 있으면 됩니다.

그 허수아비 게임을 다시 예로 들어봅시다. AI가 규칙을 추측하게 하는 대신, 실제 플레이 경험 과정을 단계별로 설명해 보세요:

• 플레이어가 화면에서 실제로 무엇을 하나요? 무언가를 쏘나요, 아니면 물리적으로 걸어 다니며 새들을 겁주는 건가요?
• 캐릭터는 어떻게 조종하나요? 화살표 키인가요, 가상 조이스틱인가요, 아니면 터치하여 이동하는 방식인가요?
• 승리 및 패배 조건은 무엇인가요? 새들이 작물을 먹을 때 농장에 체력 바(health bar)가 줄어들거나, 생존해야 하는 타이머가 있나요?
• 난이도는 어느 정도인가요? 레벨 2는 단순히 새를 더 많이 던지기만 하나요, 아니면 새들이 더 빨리 움직이나요?
• 왜 누군가가 이 게임을 한 번 이상 플레이할까요? 플레이 1과 플레이 10은 무엇이 다른가요?
• 플레이어는 처음 5초 동안 무엇을 해야 할지 어떻게 알게 되나요?

이러한 질문들에 복잡한 업계 답변이 필요하지 않습니다. 단지 본인에게 말이 되는 답변만 있으면 됩니다.

자신의 게임으로 연결되는 링크를 클릭한다고 상상해 보세요. 가장 먼저 보이는 것은 무엇인가요? 플레이어는 무엇을 클릭하나요? 모든 터치나 스와이프마다 무슨 일이 일어나나요? 그 전체 흐름을 머릿속으로 되짚어보세요.

저는 WHY, WHAT, HOW에 대한 이해가 게임 디자인의 기초라고 생각합니다. 이 내용은 제가 작성한 가장 초기의 글 중 하나에서 다루었습니다:

UX/UI 및 피드백 (Feedback)

단순히 머릿속으로 메커니즘을 갖는 것만으로는 충분하지 않습니다. 화면에서 어떻게 느껴질지까지 생각해야 합니다.

플레이어가 터치할 때 게임이 즉각적인 피드백을 주나요? 새를 겁주면 애니메이션과 함께 날아가나요, 아니면 단순히 화면에서 사라지기만 하나요?

종이 한 장을 가져와서 스케치해 보세요. 점수는 어디에 위치하나요? 일시 정지 버튼은 어디인가요? 패배 화면은 어떤 모습인가요? 만약 종이에 간단한 상자조차 스케치할 수 없다면, AI가 깨끗한 UI를 배치해주기를 어떻게 기대할 수 있겠어요?

규칙 균형 맞추기 (Balancing The Rules)

게임에는 긴장감이 필요하며, 이 긴장감은 숫자로 옵니다.

새 한 마리가 작물 위에 앉아 있다가 농장이 피해를 입는 데 걸리는 시간은 얼마나 되나요? 3초요? 5초요? 웨이브(wave)는 얼마나 지속되나요? 여러 새들을 동시에 겁줄 수 있나요, 아니면 하나씩만 할 수 있나요?

이러한 숫자들은 당신의 게임이 편안하게 느껴질지 아니면 완전히 혼란스럽게 느껴질지를 결정합니다. 지금 결정하세요. 나중에 언제든지 바꿀 수는 있지만, 기준점은 필요합니다.

“당신의 이해(understanding)가 아니라 생각하는 과정(thinking)을 아웃소싱할 수 있다.” - Andrej Karpathy (출처)

AI는 상용구 코드(boilerplate code) 작성, 파일 구조화, 그리고 당신이 이해하지 못하는 구문 처리에는 매우 능합니다. 하지만 AI는 당신의 게임에 영혼을 불어넣을 수는 없습니다. 만약 당신이 AI에게 무엇을 만들라고 요청하는 것 뒤에 의도(intent)가 없다면, AI는 그저 추측만 할 것입니다. 그리고 그 추측은 항상 고통스러울 정도로 평범합니다.

실제로 게임을 만드는 것은 어떨까요?

이 시점에서 당신은 아마 이렇게 생각할지 모릅니다: “좋아, 그런데 언제 실제로 도구를 만져보는 거죠? 이건 튜토리얼이어야 하는 거 아닌가요?”

네, 맞습니다. 하지만 앞으로 나아가기 위한 가장 좋은 방법은 이 단계를 먼저 스스로 명확히 하는 것입니다.

지금 당신은 코드를 작성하는 것이 아니라, 무엇을 만들지 계획만 하고 있습니다. 지금 종이에 더 많은 질문에 답할수록, 우리가 프롬프팅(prompting)을 시작했을 때 마주칠 장애물이나 지저분한 재작업이 줄어들 것입니다.

그러니 어떤 도구를 만지기 전에, 이 모든 생각을 머릿속에서 꺼내서 대략적인 메모로 정리하세요. 화려한 형식은 필요 없습니다. 그냥 노트 앱을 열고 다음 내용을 적으세요:

• 게임의 핵심 목표(core goal).
• 플레이어가 어떻게 움직이고 상호작용하는지.
• 승리 및 패배 규칙(win and lose rules).
• 기본적인 수치들 (타이머, 속도, 체력 등).
• 화면이 어떤 모습일지에 대한 간단한 스케치.

그 메모들을 모두 작성했다면, 준비된 것입니다.

Part 2에서는 조금 더 깊이 들어가 보겠습니다. 우리가 AI 도구를 선택하고, 진행 상황을 절대 잃지 않도록 Git을 안전망으로 설정하며, 프로젝트의 기본 골격(scaffold)을 잡고, 그 대략적인 메모들을 명확한 사양(specs)으로 변환하여 AI가 마침내 당신의 게임을 만드는 작업을 시작할 수 있도록 할 것입니다.

요약 (TL;DR)

단일 프롬프트 함정에서 벗어나기: 기발한 프롬프트를 작성하는 것은 당신을 프롬프터로 만들 뿐, 디자이너가 아닙니다. 플레이 가능한 게임은 기계의 추측이 아니라 의도적인 규칙과 결정을 필요로 합니다.코드 대신 디자인 의도를 가져오기: 코딩 경험이 전무하다는 것이 장애물은 아니지만, 자신의 사고 과정을 외주화하는 것은 문제입니다. AI는 구문을 처리할 수 있지만, 플레이어 경험은 당신이 주도해야 합니다.WHY(이유), WHAT(무엇), HOW(방법)를 매핑하기: 좋은 디자인은 플레이어가 순간순간 겪게 될 여정을 이해하는 것에서 시작됩니다. 만약 머릿속으로 그 흐름을 따라 걸어볼 수 없다면, AI가 그것을 구축해 줄 수 없습니다.화면과 숫자를 스케치하기: 시각적 피드백과 메커니즘 조정(mechanical tuning)은 게임에 긴장감과 느낌을 부여합니다. 간단한 레이아웃과 기본 값을 초기에 결정하는 것은 반복 작업을 위한 견고한 기반을 만듭니다.Part 2를 위해 노트 준비하기: 명확하고 구조화된 노트는 모호한 아이디어와 구축할 수 있는 실행 가능한 프로젝트 사이의 간극을 메워줍니다.

노트 앱에 두고 빌리기를 기다리는 게임 아이디어가 있나요? 채팅에서 전체 게임을 프롬프트로 요청했다가 메시지 세 개 만에 망가지는 것을 본 적이 있나요? 댓글을 남겨주세요. 어떤 것에 재미를 붙이고 있는지 듣고 싶습니다.