아이디어를 희망 목록이 아닌 테스트로 바꾸기
AI로 게임을 만들려면 먼저 플레이 가능한 핵심 루프 하나를 정의하고, 작은 구현을 요청한 뒤, 기능을 더하기 전에 결과를 확인하세요. 프롬프트는 입력일 뿐 요청한 기능이 작동한다는 증거는 아닙니다. 생성 후에는 “게임처럼 보이는가?”보다 “플레이어가 행동하고, 목표에 도달하고, 실패 이유를 이해하고, 다시 시작할 수 있는가?”를 물어야 합니다.
이 가이드는 기록이 남아 있는 기존 SEELE 사례와 별도의 교육용 기획안을 함께 다룹니다. 사례에는 기존 플레이 링크와 녹화 영상이 있지만, 교육용 기획안은 이 글을 위해 생성하거나 테스트하지 않았습니다. 둘을 구분해야 그럴듯한 작업 과정이 검증된 성공 사례로 오해되지 않습니다.
기록된 좀비 생존 게임 사례에서 확인할 수 있는 것
원문은 Three.js로 1인칭 좀비 생존 게임을 요청한 2026년 10월의 SEELE 생성 기록을 설명합니다. 요청 기능에는 포인터 잠금을 이용한 이동, 총기, 재장전, 조준경을 통한 조준, 앉기, 달리기, 아이템 획득, 미니맵이 포함됐습니다.
원문에서 결과 녹화를 설명하며 확인한 요소는 1인칭 무기 화면, 체력과 탄약 HUD, 미니맵, 웨이브 카운터, 적, 아이템 획득 안내입니다. 21.5초짜리 플레이 영상은 첫 번째 웨이브의 일부만 보여 줍니다. 이 화면만으로 재장전과 앉기가 실제로 작동하는지, 모든 아이템 상호작용이 가능한지, 다섯 웨이브를 끝까지 진행할 수 있는지 또는 다른 브라우저와 호환되는지는 입증할 수 없습니다. 이는 공개된 사례의 근거가 미치는 범위이며, 새로 직접 플레이해 완료했다는 보고가 아닙니다.
이 이미지는 해당 프로젝트의 프롬프트 기반 제작 과정을 기록합니다.
첫 빌드를 위한 더 작은 기획안 복사하기
슈팅 게임에 서로 영향을 주는 시스템이 너무 많아 첫 시도가 부담스럽다면 다음 교육용 예시를 사용하세요.
교육용 예시이며 테스트된 빌드가 아닙니다. Signal Run이라는 단일 화면의 탑다운 브라우저 게임을 만드세요. 플레이어는 WASD 또는 방향키로 움직이며 배터리 세 개를 모아 눈에 보이는 출구에 도달합니다. 배터리 개수와 조작법을 표시하세요. 장애물 하나가 고정된 두 지점 사이를 수평으로 움직입니다. 장애물에 닿으면 패배 화면이 나타나고, 배터리를 모두 모으지 않은 채 출구에 도달하면 필요한 조건을 안내합니다. 세 개를 모두 모아 출구에 도달하면 승리 화면을 표시합니다. 어느 결과에서든 R 키로 다시 시작할 수 있으며 플레이어, 배터리, 카운터, 장애물은 초기 상태로 돌아갑니다. 알아보기 쉬운 임시 도형을 사용하세요. 적, 무기, 저장, 네트워크, 추가 레벨, 결제 기능은 넣지 마세요. 변경한 프로젝트 구성 요소를 설명하고 이동, 수집, 승리, 패배, 재시작을 확인하는 방법을 제시하세요.
SEELE의 프롬프트 기반 게임 제작은 기획안을 프로토타입으로 옮기는 단계에 활용할 수 있습니다. 요청한 조작과 초기화 동작은 실제 생성 결과에서 반드시 검증해야 하며, 프롬프트의 문구만으로 보장되지는 않습니다.
1단계: 첫 번째 플레이 루프 점검하기
화면을 다듬기 전에 목표 환경에서 빌드를 실행하고 게임 안에 표시된 조작법을 따르세요. 모든 방향의 이동을 확인하고 플레이 영역 밖으로 나갈 수 없는지 확인합니다. 배터리 하나를 수집한 다음 원래 있던 자리를 다시 지나가세요. 카운터가 두 번 올라가면 안 됩니다.
배터리를 다 모으기 전에 출구에 가서 메시지를 기록합니다. 수집 경로를 완수해 승리를 확인하고, 의도적으로 장애물에 닿아 패배도 확인합니다. 두 결과가 나온 뒤 각각 다시 시작하세요. 장애물은 초기화되지만 배터리는 돌아오지 않는다면 AI에 막연히 “게임을 고쳐 줘”라고 하기보다 그 차이를 정확히 전달합니다.
2단계: 사례를 이용해 검증 기록표 만들기
각 기능마다 요청한 동작, 이용 가능한 증거, 관찰된 동작, 상태라는 네 항목을 기록하세요. 좀비 사례에서 미니맵이 보인다는 사실은 증거 항목에 넣을 수 있지만, 위치를 정확히 추적하는지는 테스트하기 전까지 미검증 상태입니다. 재장전 요청은 탄약 변화와 재장전 동작을 기록할 수 있을 때까지 명세 항목에 둡니다.
Signal Run에도 같은 원칙을 적용하세요. “배터리 세 개를 요청했다”는 말은 “서로 다른 세 아이템이 정확히 집계됐다”는 뜻이 아닙니다. 확실하지 않은 항목은 단정적인 설명으로 빈칸을 채우지 말고 미검증으로 표시합니다. 이 기록표를 이용하면 다음 프롬프트의 범위를 줄이고 협업자에게 빌드 상태를 신뢰성 있게 설명할 수 있습니다.
3단계: 규칙 하나를 수정하고 루프 다시 실행하기
작동하는 버전을 저장한 뒤 변경 하나만 요청하세요. 장애물의 경로와 모든 수집 규칙은 유지하면서 이동 속도를 20% 줄입니다. 같은 출발점에서 같은 경로를 다시 지나가 시간을 비교하고, 두 가지 종료 상태를 다시 테스트합니다.
관련 없는 시각적 변경 후 이동이 고장 났다면 정상 작동이 확인된 버전으로 되돌리고 요청 범위를 좁히세요. 정확한 오류, 대상 환경, 기대 동작, 가장 짧은 재현 순서를 제공해야 합니다. 원인을 모르는 실패 위에 광범위한 재작성을 계속 덧붙이지 마세요.
4단계: 개발 산출물 인계를 별도로 확인하기
플레이 가능한 링크가 소스 프로젝트의 인계를 뜻하지는 않습니다. 도구를 이용해 계속 개발하기 전에 현재 요금제에서 프로젝트에 접근하고 내보낼 수 있는지 확인하세요. 필요한 형식을 제공한다면 버전이 표시된 복사본을 저장하고 진입점, 소스 파일, 에셋, 의존성 명세 파일, 잠금 파일, 실행 지침을 목록으로 정리합니다. 무엇이 생성된 것인지, 무엇이 의존성인지, 무엇이 별도 서비스를 필요로 하는지 확인하세요. 프로젝트와 함께 자격 증명, 비공개 엔드포인트, 계정 토큰을 공개하지 마세요.
별도의 깨끗한 폴더에서 해당 엔진이나 프레임워크의 문서화된 설치 및 실행 명령을 따르세요. 런타임 버전과 누락된 의존성을 기록합니다. 호스팅된 작업 공간에 의존하지 않고 이동, 수집, 승리, 패배, 재시작을 다시 확인합니다. 로컬 빌드가 실패하거나 내보내기를 이용할 수 없다면 그 제약을 기록하세요. 호스팅된 미리보기로 부족한 증거를 대신할 수는 없습니다. 기존 좀비 사례에서는 소스 내보내기나 로컬 실행이 확인되지 않았습니다.
5단계: 확인된 범위를 정직하게 공유할 준비하기
공유하기 전에 깨끗한 환경에서의 로딩, 읽기 쉬운 조작법, 오디오가 있다면 오디오, 키보드 포커스, 재시작을 확인하세요. 의도한 용도에 맞게 도구와 에셋의 최신 이용 조건을 살펴봅니다. 다른 브라우저나 기기를 지원한다고 말하기 전에 실제로 테스트하세요. 성능에 관한 설명은 삽입된 영상이 부드러워 보인다는 인상이 아니라, 명시된 하드웨어와 기록된 측정 방법에 근거해야 합니다.
위 기획안을 사용해 SEELE에서 작은 프로토타입을 시작해 보세요. 더 많은 변경을 요청하기 전에 작동하는 빌드, 정확한 프롬프트, 테스트 메모를 보존합니다. 목표는 긴 기능 목록이 아니라 검증된 루프 하나입니다. 처음 접하는 플레이어가 이동하고 목표를 이해하며 승리와 패배에 도달하고 다시 시작할 수 있어야 합니다. 제작자의 설명 없이 이 루프를 시연할 수 있게 된 뒤에 레벨과 더 풍부한 에셋을 추가하세요. 작업 공간 밖에서 개발을 계속하는 것이 중요하다면 소스 인계와 깨끗한 로컬 실행을 미리보기에서 추정하지 말고 별도의 인수 기준으로 삼으세요.
증거 및 인수 기준 표
이 표는 글에서 제안한 확인 항목을 정리한 것이며, 완료된 테스트에 대한 보고가 아닙니다.
| 주장 또는 작업 | 원문 또는 기획안에서 확인되는 내용 | 추가로 확인해야 할 내용 |
|---|---|---|
| 녹화된 생존 게임 사례 | 글은 짧은 플레이 영상을 설명하고 보이는 HUD와 적 요소를 식별합니다. | 짧은 영상만으로 전체 플레이 동작이나 브라우저 호환성을 추정하지 않습니다. |
| 플레이 루프 | 교육용 기획안은 행동, 목표, 패배 상태, 재시작을 제안합니다. | 실제 빌드에서 각 동작을 실행하고 결과를 기록합니다. |
| 수정 | 작업 과정은 범위가 정해진 변경 하나를 요청합니다. | 변경을 적용한 뒤 기준 테스트를 반복합니다. |
| 개발 산출물 인계 | 인계는 작업 과정의 별도 단계입니다. | 실제 파일, 설정 지침, 허용된 이용 범위를 확인합니다. |
자주 묻는 질문
짧은 플레이 영상으로 게임 전체가 작동한다고 증명할 수 있나요?
아니요. 녹화된 시간 동안 보이는 내용만 뒷받침합니다. HUD가 보이더라도 그 아래의 모든 규칙이 정확한 것은 아닐 수 있습니다. 기능 체크리스트, 재현 가능한 입력, 특정 동작을 다루는 더 긴 영상을 사용해 동작을 확인하세요. 제작 과정 영상, 외형 미리보기, 완료된 플레이 테스트는 구분해야 합니다.
생성된 파일을 전부 이해해야 하나요?
게임을 테스트하고 작동하는 버전을 보호하며 관련 변경 사항을 찾을 수 있을 만큼은 이해해야 합니다. 구성 요소와 전제를 쉬운 말로 설명해 달라고 어시스턴트에 요청하세요. 익숙하지 않은 엔진 고유 동작은 해당 엔진의 최신 문서를 확인합니다. 설명이 기술적으로 그럴듯하다는 이유만으로 광범위한 코드 재작성을 받아들이지 마세요.
임시 아트는 언제 교체해야 하나요?
루프를 쉽게 이해하고 반복할 수 있게 된 후입니다. 에셋을 조금씩 교체하고 충돌 판정, 크기, 대비, 로딩, 이용 권리를 다시 확인하세요. 매력적인 이미지는 전달력을 높일 수 있지만 테스트하지 않은 게임 동작을 검증할 수는 없습니다. 콘셉트 이미지는 정직하게 표시하고, 작동하는 생성 결과의 스크린샷처럼 제시하지 마세요.
다음 플레이 가능한 마일스톤에 대한 워크플로를 선택하세요
브라우저에서 재생 가능한 하나의 루프에서 다음 결정을 테스트할 수 있는 경우 게임 제작자를 사용하세요. 프로젝트에 이미 엔진, 자산 또는 코드베이스가 있는 경우 해당 환경 내에서 하나의 제한된 변경에 대해 어시스턴트를 테스트하세요. 플레이 테스트 노트와 함께 내보내기 및 자산 체크리스트를 보관하여 플레이 가능한 결과와 휴대용 프로젝트를 별도로 평가할 수 있습니다.
