게임잼 48시간 타임어택 개발 일정 구성과 이슈 우선순위 관리법
48시간 게임잼에서 아이디어 과확장과 막판 통합 실패를 줄이는 일정 설계법을 정리합니다. MVP 범위 설정, 시간대별 마일스톤, P0~P3 이슈 우선순위, 팀 문서화와 빌드 점검 절차를 실전용으로 설명합니다.
48시간 게임잼의 성패는 기능 수가 아니라 첫날 안에 완주 가능한 MVP를 고정하고 둘째 날에는 결함을 우선 제거하는 운영에 달려 있다. 일정은 구현 시간만 합산하지 말고 통합·빌드·플레이테스트·제출 여유를 별도 버퍼로 확보해야 한다. 이슈는 플레이 불가 상태를 만드는 P0부터 처리하고 재미를 높이는 개선 사항은 제출 가능한 빌드가 나온 뒤에만 선택한다.
48시간 게임잼 일정은 왜 쉽게 무너지는가?
게임잼의 실제 작업 시간은 48시간보다 짧다. 식사, 휴식, 의사소통, 에셋 탐색, 빌드 실패, 배포 준비에 시간이 쓰이기 때문이다. 특히 Unity, Godot, Unreal Engine처럼 에디터 기반 개발에서는 코드 작성 시간 외에도 씬 병합, 임포트, 플랫폼별 빌드 검증이 필요하다.
유효 개발 시간을 다음처럼 잡으면 낙관적인 계획을 줄일 수 있다.
예를 들어 2인 팀이 각자 6시간씩 휴식하고 식사·정리·회의에 총 5시간, 제출 버퍼 4시간을 쓰면 한 사람의 순수 작업 가능 시간은 대략 33시간이다. 이 시간에 모든 기능을 넣는 것이 아니라 게임의 핵심 반복 구조를 먼저 완성해야 한다.
| 일정이 무너지는 원인 | 흔한 증상 | 운영 원칙 |
|---|---|---|
| 테마 해석이 길어짐 | 첫 4시간 동안 아이디어만 논의 | 60~90분 안에 한 문장 피치 확정 |
| 스코프 과확장 | 적·스테이지·업그레이드가 계속 추가됨 | MVP 밖 기능은 Icebox 목록으로 분리 |
| 통합 지연 | 각자 작업은 끝났지만 실행 흐름이 끊김 | 첫날 중간에 통합 빌드 생성 |
| 테스트 부재 | 마지막에 조작감·난이도 문제가 발견됨 | 4~6시간마다 외부 플레이테스트 |
| 제출 작업을 무시 | 압축, 업로드, 설명 작성에서 지연 | 종료 4시간 전 콘텐츠 동결 |
48시간 게임잼 개발 일정은 어떻게 구성할까?
1. 시작 후 0~2시간: 핵심 루프와 MVP를 고정한다
먼저 다음 빈칸을 한 문장으로 채운다.
플레이어는 [행동]으로 [즉시 보이는 결과]를 만들고 [목표]를 달성한다.
예를 들어 “플레이어는 제한된 탄환을 반사시켜 적을 처치하고 3분 동안 기지를 방어한다”처럼 작성한다. 이 문장에 없는 시스템은 기본적으로 MVP 밖이다.
MVP는 다음 네 가지가 연결된 최소 상태여야 한다.
- 입력: 이동, 조준, 선택 등 플레이어 행동이 있다.
- 규칙: 행동에 따라 성공·실패·점수 변화가 발생한다.
- 목표: 승리 조건 또는 명확한 종료 조건이 있다.
- 피드백: 사운드, 화면 변화, 애니메이션 중 최소 하나로 결과를 전달한다.
2. 2~18시간: 세로 슬라이스를 먼저 완성한다
세로 슬라이스는 시작부터 종료까지 한 판이 가능한 가장 얇은 버전이다. 캐릭터 이동만 만들고 다음 기능으로 넘어가기보다 임시 도형과 임시 사운드를 사용해도 게임 시작·진행·종료를 연결한다.
권장 순서는 다음과 같다.
- 프로젝트 저장소, 브랜치 규칙, 엔진 버전을 문서에 적는다.
- 입력과 플레이어 상태를 구현한다.
- 적 또는 장애물 하나와 충돌·판정 규칙을 연결한다.
- 점수, 체력, 타이머 중 게임 목표에 필요한 값 하나를 표시한다.
- 승리·패배 화면과 재시작 버튼을 만든다.
- 팀 전원이 같은 실행 파일 또는 웹 빌드를 플레이한다.
이 단계에서는 멋진 아트보다 완결성이 우선이다. Godot 4라면 project.godot의 입력 맵, Unity라면 Input System 설정을 먼저 공유하고 각자 로컬 설정에 의존하지 않도록 한다.
3. 18~32시간: 재미를 검증하고 제한적으로 확장한다
세로 슬라이스가 확인된 후에만 콘텐츠를 추가한다. 추가 요청은 아래 질문 세 개를 통과해야 한다.
- 이 기능이 핵심 루프를 더 자주 또는 더 분명하게 만들까?
- 기존 시스템을 재사용해서 2시간 이내에 넣을 수 있을까?
- 없어도 제출 가능한가?
세 질문 중 하나라도 아니오라면 Icebox에 기록하고 보류한다. Icebox는 포기 목록이 아니라 팀이 같은 아이디어를 반복 논의하지 않게 하는 장치다.
4. 32~44시간: 콘텐츠를 동결하고 안정화한다
이 시점부터 새 기능은 원칙적으로 금지한다. 난이도 값, 스폰 간격, 피해량처럼 데이터만 조정 가능한 변경과 P0·P1 버그 수정만 허용한다.
예를 들어 적 스폰 간격 spawnInterval을 코드에 고정하지 말고 엔진의 Inspector 또는 설정 리소스로 분리한다. 그러면 새 시스템을 넣지 않고도 플레이 감각을 조정할 수 있다.
5. 44~48시간: 제출 가능한 빌드를 보호한다
종료 4시간 전에는 아래를 끝낸다.
- 배포 대상에서 클린 빌드를 만든다.
- 다른 팀원이 시작부터 종료까지 한 판을 플레이한다.
- 게임 설명, 조작법, 크레딧, 사용한 외부 에셋 라이선스를 작성한다.
- 업로드 후 실제 배포 페이지에서 다운로드 또는 실행을 확인한다.
- 마지막 수정본과 제출본의 버전 또는 커밋 해시를 기록한다.
flowchart TD
A[새 이슈 발견] --> B{플레이 또는 제출이 불가능한가?}
B -->|예| P0[P0: 즉시 수정]
B -->|아니오| C{핵심 루프를 크게 해치는가?}
C -->|예| P1[P1: 다음 작업으로 수정]
C -->|아니오| D{짧은 시간에 재미를 높이는가?}
D -->|예| P2[P2: 여유가 있을 때 처리]
D -->|아니오| P3[P3: 기록 후 보류]게임잼 이슈 우선순위는 P0~P3로 어떻게 정할까?
중요도와 긴급도를 막연히 논의하면 감정이 큰 목소리를 이기기 쉽다. 게임잼에서는 영향 범위와 제출 위험을 기준으로 단순한 P0~P3 체계를 쓰는 편이 빠르다.
| 우선순위 | 판단 기준 | 예시 | 처리 원칙 |
|---|---|---|---|
| P0 | 플레이·빌드·제출이 불가능 | 게임 시작 시 크래시, 입력 불가, 업로드 실패 | 현재 작업을 멈추고 즉시 해결 |
| P1 | 핵심 루프가 불공정하거나 이해되지 않음 | 피격 판정 오류, 목표가 표시되지 않음 | P0 다음으로 해결 |
| P2 | 완성도나 재미를 높이는 개선 | 카메라 흔들림, 사운드 볼륨 조정, 쉬운 밸런스 개선 | 여유 시간이 있을 때 처리 |
| P3 | 있으면 좋지만 없어도 되는 항목 | 새 스킨, 추가 스테이지, 설정 메뉴 | Icebox에 기록하고 보류 |
우선순위가 애매하면 다음 점수로 정렬할 수 있다.
각 항목은 0 또는 1로 두고 Effort는 예상 작업 단위로 기록한다. 점수가 높을수록 먼저 처리한다. 단, P0는 점수 계산보다 항상 우선한다.
협업 중 이슈를 빠르게 합의하려면 무엇을 기록해야 할까?
문서는 길 필요가 없다. 팀이 같은 사실을 보는 한 장의 보드면 충분하다. GitHub Issues, Notion, Google Sheets, 종이 화이트보드 중 팀이 가장 빨리 갱신할 수 있는 도구를 선택한다.
각 이슈에는 다음 다섯 칸만 유지한다.
| 필드 | 기록 예시 |
|---|---|
| 제목 | P1: 보스 처치 후 승리 화면 미표시 |
| 재현 조건 | 보스 체력이 0이 된 프레임에 피격 시 |
| 담당자 | 클라이언트 A |
| 상태 | Todo / Doing / Verify / Done |
| 완료 기준 | 3회 연속 처치 시 승리 화면과 재시작 버튼 표시 |
특히 완료 기준을 “수정한다”가 아니라 관찰 가능한 결과로 적는다. 그래야 구현자와 검증자가 같은 조건에서 완료를 판단할 수 있다.
30분~1시간 간격의 짧은 동기화에서 확인할 질문
게임잼에서는 긴 회의 대신 5분 이내의 짧은 동기화가 효과적이다. 30분 또는 1시간 단위로 다음만 확인한다.
- 지금 제출본에서 가장 위험한 문제는 무엇인가?
- 다음 점검 시점까지 반드시 끝낼 작업은 무엇인가?
- 막힌 작업이 있는가? 있다면 담당을 바꾸거나 범위를 줄일 수 있는가?
작업 진행률을 “80% 완료”로 표현하지 않는 것도 중요하다. “재시작 버튼이 작동한다”, “웹 빌드가 업로드됐다”처럼 검증 가능한 산출물로 말한다.
자주 묻는 질문 (FAQ)
게임잼에서 기능을 더 넣어도 되는 시점은 언제인가?
시작부터 종료까지 한 판이 가능하고 다른 사람이 플레이해 핵심 규칙을 이해했으며 제출용 빌드를 이미 확보한 뒤다. 그 전의 기능 추가는 대부분 P3로 보류하는 편이 안전하다.
버그와 재미 개선 중 무엇을 먼저 해야 하나?
게임 시작, 입력, 승패 판정처럼 핵심 루프를 막는 버그가 먼저다. 그다음 규칙을 이해하기 어렵게 만드는 문제를 해결하고 연출·추가 콘텐츠 같은 개선은 마지막에 처리한다.
2인 팀은 역할을 어떻게 나누면 좋은가?
한 명은 게임 진행 규칙과 빌드 안정성을 책임지고 다른 한 명은 아트·사운드·UI·콘텐츠를 맡되 매 4~6시간마다 통합 빌드를 함께 확인하는 방식이 실용적이다. 다만 한 사람이 빠졌을 때를 대비해 프로젝트 실행 방법과 핵심 파일 위치는 공유 문서에 남긴다.
정리: 48시간 게임잼의 목표는 더 많은 기능이 아니다
48시간 게임잼에서는 초반 2시간에 MVP를 고정하고 18시간 안에 세로 슬라이스를 만들며 종료 4시간 전에는 콘텐츠를 동결하는 일정이 안정적이다. 이슈는 P0부터 P3까지 단순하게 분류하고 모든 작업을 제출 가능성에 연결해 판단하자. 완벽한 게임보다 처음부터 끝까지 플레이할 수 있고 의도가 전달되는 게임이 더 강한 제출작이 된다.
