첫 게임 범위 정하기: 1인 개발자가 끝까지 만드는 크기와 일정 짜기
혼자 만드는 첫 게임을 끝까지 가져가려면 범위를 얼마나 작게 잡아야 하는지, 계획서 한 장에 무엇을 적고 일정을 어떻게 나누는지 정리합니다. Godot로 작은 게임 세 개를 만들어 본 기록에서 실제로 걸린 시간과 막힌 곳, 범위가 바뀐 과정을 함께 보여 줍니다.
한국어English
기준: Godot 4.7.2(표준판, Windows), Claude Code, Godot 4.7 공식 문서. 2026년 11월에 확인했습니다. 그림은 모두 직접 만든 시험 게임의 실제 실행 화면입니다. 게임 속 글자는 한국어입니다.
혼자 만든 게임이 끝나지 않는 가장 흔한 까닭은 실력이 아니라 크기입니다. 처음 떠올린 게임은 보통 혼자 몇 달을 들여도 끝나지 않을 만큼 큽니다. 그래서 첫 게임에서 가장 먼저 할 일은 코드를 쓰는 것이 아니라, 끝까지 갈 수 있는 크기로 범위를 자르는 것입니다. 범위는 "이번에 만들 것"과 "이번에 만들지 않을 것"을 가르는 선입니다. 이사할 때 짐을 다 싸기 전에 "이번 차에 실을 것"부터 정하는 것과 같습니다.
이 글은 1인 개발 연재 3편입니다. 첫 게임의 알맞은 크기, 계획서 한 장에 적을 것, 일정을 단계로 나누는 법을 정리하고, Godot로 작은 게임을 만들어 본 기록에서 실제로 걸린 시간과 막힌 곳을 보여 줍니다. 이 글에서는 첫 게임의 범위를 정하고 일정을 짜는 방법을 설명합니다. 연재 전체 지도는 1인 게임 개발 지도에 있습니다.
1. 결론 먼저: 첫 게임의 크기
| 항목 | 첫 게임에 알맞은 크기 |
|---|---|
| 화면 | 하나. 메뉴·설정 화면 없이 바로 시작 |
| 규칙 | 한 줄로 설명되는 것 하나 |
| 한 판 | 1분 안팎. 시작 → 진행 → 끝 → 다시 시작이 됨 |
| 조작 | 키 두세 개, 또는 마우스 하나 |
| 모델 | 이미 있거나 간단히 만들 수 있는 것 |
| 소리 | 효과음 몇 개면 충분 |
| 내보내기 | 첫 판이 끝난 뒤 따로 |
이 표는 작아 보이지만, 이만큼을 끝까지 만들면 게임 한 편에 필요한 일을 한 바퀴 모두 해 보게 됩니다. 모델을 넣고, 입력을 받고, 승패를 가르고, 다시 시작하게 만드는 일입니다. 두 번째 게임은 이 바퀴를 조금 더 크게 굴리는 것입니다.
2. 계획서 한 장에 적을 것
범위는 머릿속에 두면 자꾸 늘어납니다. 그래서 글로 적은 계획서 한 장을 먼저 만듭니다. 이런 문서를 흔히 PRD(제품 요구 문서)라고 부릅니다. 집을 짓기 전의 평면도처럼, 무엇을 어디까지 만들지 정해 두는 문서입니다.
범위를 정하는 데 쓰인 것은 제 방공 게임 계획서의 두 칸이었습니다. 계획서의 나머지 칸(한 줄 설명, 질문, 규칙 표)은 Claude Code로 Godot 게임 장면 만들기 4절에 있습니다.
| 칸 | 적은 내용 |
|---|---|
| 범위 밖 | 배포·설치 파일, 메뉴·설정 화면, 여러 스테이지, 온라인, 모바일 |
| 합격 기준 | 모델의 크기·방향·색이 맞음, 한 판이 시작 → 진행 → 끝 → 다시 시작까지 됨, 걸린 시간과 용량을 잼 |
가장 중요한 칸은 범위 밖입니다. 만들지 않을 것을 미리 적어 두면, 중간에 "메뉴 화면도 있으면 좋겠다"는 생각이 들어도 "이번에는 범위 밖"이라고 바로 정리할 수 있습니다. 합격 기준에는 확인하는 방법까지 함께 적습니다. "잘 돌아간다"가 아니라 "한 판이 다시 시작까지 된다"처럼 눈으로 확인할 수 있는 문장이어야 합니다.
따라 하기: AI에게 코드를 시키기 전에 계획서부터 쓰게 합니다. 이렇게 적으면 됩니다(예).
작은 게임 한 장면을 만들려고 해. 코드를 쓰기 전에 PRD.md를 먼저 써 줘.
- 한 줄 설명, 합격 기준(확인 방법 포함), 범위 밖 목록
- 규칙 표(시점, 조작, 승패 조건)
- 단계 목록: 단계마다 끝났는지 확인하는 방법을 붙여 줘
내가 읽고 "진행"이라고 하기 전에는 코드를 쓰지 마.
3. 단계로 나누기
계획서가 정해지면 일을 단계로 나눕니다. 단계마다 "끝났다"를 확인하는 방법이 있어야 합니다. 등산로의 쉼터처럼, 한 구간이 끝나면 쉼터에서 지도를 다시 보는 것입니다.
제 방공 게임은 여섯 단계로 나눴습니다.
| 단계 | 한 일 | 확인 |
|---|---|---|
| M0 준비 | Godot 4.7.2 표준판 받기 | 받은 파일의 검증 값이 공식 값과 같음 |
| M1 모델 | Blender 모델 8개를 glTF로 내보내기 | 모델 8개 모두 치수 차이 0 |
| M2 배경 | 사막·하늘·산을 코드로 만들기 | 그림 1을 보고 "진행" |
| M3~M5 게임 | 조준·발사·무인기·승패·화면 글자 | 자동 확인 14/14, 직접 해 보기 |
그림 1. M2 단계가 끝난 화면. 배경과 발사대만 있고 게임 규칙은 아직 없습니다 (Godot 실행 화면)
그림 1처럼 게임 규칙을 넣기 전에 배경과 모델만 먼저 확인했습니다. 이 단계에서 화면의 느낌이 틀어졌다면 규칙을 넣기 전에 고쳤을 것입니다. 뒤에서 고칠수록 손댈 곳이 늘어나기 때문에, 단계마다 멈춰서 보는 것이 결과적으로 빠릅니다.
4. 실제로 걸린 시간
2026년 10월 10일 밤 한 세션에서 한 일과 걸린 시간입니다. 코드는 모두 Claude Code가 썼고, 저는 계획서를 읽고 정하고 직접 해 봤습니다.
| 한 일 | 걸린 시간 |
|---|---|
| 방공 게임 첫 판(한 판이 돌아갈 때까지) | 약 1시간 |
| 방공 게임 다듬기 | 제가 다섯 번 해 보고 고칠 점을 말함 |
| 리깅 캐릭터 옮기기 시험 | 약 20분 |
| 페널티킥 승부차기 | 약 30분 |
| 세션 전체 | 약 3시간(기다린 시간 포함) |
시작 전에는 5~7시간이 걸리리라 어림했는데, 실제로는 절반쯤이었습니다. 다만 이 숫자는 그대로 따라 쓰지 마세요. 모델과 동작이 이미 있었고, 게임이 화면 하나짜리였기 때문에 나온 시간입니다. 모델을 새로 만들어야 한다면 그 시간이 따로 더해집니다. 단계별로 몇 분씩 걸렸는지는 기록하지 않아서 여기에 적지 않습니다.
그림 2. 약 1시간 만에 나온 첫 판. 점수, 기지 체력, 남은 시간이 있고 재장전이 됩니다 (Godot 실행 화면)
그림 2는 첫 판입니다. 합격 기준인 "시작 → 진행 → 끝 → 다시 시작"은 이미 됐습니다. 범위를 작게 잡은 덕분에 첫 판이 빨리 나왔고, 그다음부터는 직접 해 보며 고치는 시간이 대부분이었습니다.
5. 범위가 바뀐 과정
첫 판을 해 본 뒤 다섯 번 해 보며 규칙이 바뀌었습니다. 회차마다 제가 한 말은 Claude Code로 Godot 게임 장면 만들기 6절에 있고, 여기서는 범위가 커졌는지만 봅니다.
| 회차 | 바뀐 규칙 | 범위가 커졌나 |
|---|---|---|
| 1 | 재장전 없앰, 무인기 32대가 이어서 옴 | 아니오. 값과 승패 조건만 바뀜 |
| 2 | 호를 그리는 궤도, 2~4대 동시 등장, 세 겹 조준 원 | 조금. 화면 표현이 늘었지만 화면은 하나 |
| 3 | 등장 간격 2.5초 → 1.7초, 기지 체력을 없애고 발사대가 한 번에 파괴 | 줄어듦. 기지 체력이 빠짐 |
| 4 | 표적 바꾸기, 거리에 따라 크기 줄이기, 등장 거리 1,500 m | 조금. 무인기 규칙 하나가 늘어남 |
| 5 | 점수 표시 삭제, 규칙 확정 | 줄어듦. 점수가 빠짐 |
그림 3. 고치는 도중의 방공 게임. 남은 시간 대신 남은 무인기가, 기지 체력 대신 남은 발사대가 보입니다. 그림의 점수 표시는 마지막 회차에서 지웠습니다 (Godot 실행 화면)
그림 2와 그림 3을 견주면 범위가 어떻게 움직였는지 보입니다. "2분 30초 버티기"가 "32대 막기"로, "재장전 있음"이 "없음"으로, "기지 체력"이 "발사대 한 번에 파괴"로 바뀌었고, 마지막에는 점수까지 없앴습니다. 규칙은 많이 바뀌었지만 화면 하나, 한 판 약 40초라는 크기는 그대로였습니다. 범위를 지킨다는 것은 규칙을 바꾸지 않는다는 뜻이 아니라, 크기를 늘리지 않는다는 뜻입니다.
6. 막힌 곳
| 막힌 곳 | 증상 | 처리 |
|---|---|---|
| 모델 내보내기 | 모델과 캐릭터를 옮기며 색이 빠짐, 바닥 판이 딸려 나옴, 빈 파일이 나옴 등 다섯 군데 | AI가 내보내기 스크립트에 처리를 넣음(Blender 모델을 Godot로 옮기기) |
| 첫 실행 | "no main scene" 오류 창 | 프로젝트의 첫 장면을 지정 |
| 난이도 | 자동 플레이로는 쉬운지 어려운지 알 수 없음 | 사람이 직접 다섯 번 해 봄 |
| 화면 글자 | 숫자가 많아 거슬림 | 점수를 빼고 "4대 막는 것만" 보이게 함 |
| 페널티킥 첫 판 | 확률이 화면에 보이고, 두 편 캐릭터가 똑같음 | 확률을 숨기고 편마다 옷 색과 이름표를 나눔(그림 4) |
그림 4. 페널티킥 승부차기의 첫 판(위)과 고친 판(아래). 확률 글자를 지우고, 차례마다 옷 색과 머리 위 이름표로 편을 나눴습니다 (Godot 실행 화면)
따라 하기: 그림 4처럼 고친 판이 나오면 처음 판과 나란히 놓고 봅니다. 고친 점이 실제로 화면에 들어갔는지, 고치다가 다른 것이 깨지지 않았는지 한눈에 보입니다.
막힌 곳 가운데 코드 문제는 AI가 금방 풀었습니다. 오래 걸린 것은 사람이 해 보고 느낌을 말하는 일이었습니다. 일정을 짤 때 이 시간을 꼭 따로 잡아야 하는 까닭입니다.
같은 세션에서 하지 못하고 남긴 것도 있습니다. 소리는 코드로 합성한 효과음 여섯 개뿐이었고, 발사통 뚜껑이 열리는 동작은 넣지 않았으며, 내보내기(실행 파일 만들기)는 하지 않았습니다. 모두 처음부터 범위 밖에 두었거나 첫 판 뒤로 미룬 일입니다.
7. 일정 짜기
위 기록에서 나온 원칙을 일정으로 옮기면 이렇습니다.
- 단계마다 확인 방법을 붙입니다. "모델 넣기"가 아니라 "모델 넣기, 치수 차이 0 확인"처럼 적습니다.
- 첫 판까지를 가장 짧게 잡습니다. 메뉴·소리·내보내기는 첫 판 뒤로 미룹니다.
- 직접 해 보는 시간을 따로 잡습니다. 한 번 해 보고 고칠 점을 말하는 데 드는 시간을 회차마다 넣습니다.
- 내보내기는 별도 단계로 둡니다. 엔진 안에서 돌아가는 것과 실행 파일로 돌아가는 것은 다른 일입니다.
처음 만드는 사람을 위한 일정의 예입니다. 실제로 잰 값이 아니라, 위 원칙을 하루 두세 시간씩 쓰는 사람에게 맞춰 본 권고안입니다.
| 날 | 할 일 | 끝났는지 확인 |
|---|---|---|
| 1일 | 계획서 한 장(한 줄 설명, 합격 기준, 범위 밖) | 계획서를 읽고 "진행"이라고 말할 수 있음 |
| 2일 | 모델 넣기, 배경 | 엔진 화면과 Blender 그림이 맞음 |
| 3일 | 첫 판 | 시작 → 진행 → 끝 → 다시 시작 |
| 4~5일 | 직접 해 보고 고치기(하루 두세 번) | "적당하다"는 말이 나옴 |
| 6일 | 소리, 화면 글자 정리 | 한 판을 끝까지 해도 거슬리는 것이 없음 |
| 7일 | 내보내기 | 엔진 밖에서 켜짐 |
내보내기에는 따로 준비가 필요합니다. Godot는 실행 파일을 만들 때 내보내기 템플릿을 씁니다. 템플릿은 게임을 각 운영체제에서 돌리는 실행 틀로, 공식 사이트에서 따로 받습니다. 제 기록에서는 받은 템플릿 원본이 1.2 GB였고, 내보낸 협곡 비행 게임은 Windows 판 107 MB, 웹 판 40 MB였습니다. 웹 판은 한글 글꼴을 게임 안에 넣어야 글자가 나왔고, 렉이 있었는데 원인은 찾지 못했습니다. 이런 일이 생기므로 내보내기 단계에는 여유를 둡니다.
8. 두 번째 게임: 범위를 넓힐 때
첫 게임을 끝낸 뒤 범위를 넓힐 때도 방법은 같습니다. 사흘 뒤인 10월 13일에 만든 협곡 비행 게임은 처음부터 단계를 A·B·C·D로 나눠 계획했고, 몇 단계는 제가 해 보고 말한 뒤 다음으로 넘어갔습니다. B단계 2회차와 D단계 전체는 기록에 제 판정이 남아 있지 않습니다. 첫 판과 내보내기, 그리고 A~D 네 단계를 하루에 끝냈고, 자동 확인 18개는 내보낸 Windows 실행 파일로도 모두 통과했습니다.
방공 게임과 다른 점은 화면이 늘었다는 것입니다. 처음 화면, 카운트다운, 이어하기, 결과 카드가 들어갔습니다. 첫 게임에서 범위 밖에 두었던 "메뉴 화면"이 두 번째 게임에서 들어온 셈입니다. 이처럼 범위 밖 목록은 버리는 목록이 아니라, 다음 게임의 할 일 목록이 됩니다. 단계별 내용은 Claude Code로 Godot 게임 장면 만들기에 있습니다.
연습 문제
- 만들고 싶은 게임을 한 줄로 적어 보세요. 화면 하나, 규칙 하나로 줄여 씁니다.
- 합격 기준을 세 개 적어 보세요. 모두 눈으로 확인할 수 있는 문장이어야 합니다.
- 범위 밖 목록을 다섯 개 이상 적어 보세요. 하고 싶지만 이번에는 하지 않을 것들입니다.
- 7절의 일정 예를 여러분의 하루 시간에 맞춰 다시 적어 보세요. 직접 해 보는 날이 빠지지 않았는지 확인합니다.
자주 하는 실수와 해결
| 증상 | 까닭 | 해결 |
|---|---|---|
| 몇 주째 만들고 있는데 끝이 안 보인다 | 범위 밖 목록이 없어 기능이 계속 늘어남 | 계획서에 범위 밖을 적고, 새 생각은 다음 게임 목록에 옮기기 |
| 첫 판이 나오기도 전에 지친다 | 메뉴·소리·효과부터 손댐 | 시작 → 끝 → 다시 시작만 되는 첫 판부터 |
| 규칙을 고칠 때마다 다른 데가 깨진다 | 규칙마다 확인 방법이 없음 | 규칙마다 자동 확인 항목을 두고 고칠 때마다 다시 돌리기 |
| 일정이 늘 밀린다 | 직접 해 보는 시간을 일정에 넣지 않음 | 회차마다 해 보는 시간을 따로 잡기 |
| 엔진에서는 되는데 내보낸 파일이 안 켜진다 | 내보내기를 마지막 날 처음 해 봄 | 내보내기를 별도 단계로 두고 여유 잡기 |
한 줄 정리
화면 하나·규칙 하나·한 판 1분, 계획서에 범위 밖부터, 단계마다 확인 방법, 직접 해 보는 시간은 따로, 내보내기는 별도 단계.
참고 자료
- Godot Engine 4.7 문서, Your first 2D game: https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html
- Godot Engine 4.7 문서, Exporting projects: https://docs.godotengine.org/en/stable/tutorials/export/exporting_projects.html
- Godot Engine 다운로드: https://godotengine.org/download/
- 이 연재의 다른 글: 1인 게임 개발 지도, 1인 게임 개발에 미리 알면 좋은 것, AI로 1인 개발 일 나누기, 게임용 에셋 규칙
- 그림: 모두 실제 Godot 실행 화면(직접 만든 시험 게임)
