게임잼 48시간 빌드 제출을 위한 타임박싱 전략: 완주하는 일정표와 스코프 관리
48시간 게임잼에서 아이디어 확장과 마감 직전 통합 실패를 줄이는 타임박싱 전략을 정리합니다. 제출 역산 일정표, MVP 우선순위, 협업 규칙, 빌드 검증과 버퍼 확보 방법을 단계별로 설명합니다.
게임잼 48시간의 핵심은 기능을 많이 만드는 일이 아니라 제출 가능한 최소 게임(MVP)을 일찍 고정하고 짧은 시간 상자 안에서 검증 가능한 결과물을 반복 생산하는 일이다. 시작 12시간 안에 플레이 가능한 루프를 만들고 종료 6시간 전에는 기능 개발을 멈춘 뒤 빌드·배포·제출 정보만 다루도록 일정의 경계를 분리하자.
게임잼 48시간에서 타임박싱이 왜 필요한가?
게임잼 일정에서는 남은 시간을 기능 추가에 모두 쓰지 않도록 통합과 테스트 시간을 먼저 확보하자. 테마 해석, 아트 완성도, 사운드, 튜토리얼을 동시에 개선하려 하면 이 시간을 확보하기 어려울 수 있다.
타임박싱은 작업이나 의사결정에 사용할 시간의 상한을 정하는 방법이다. 예를 들어 적 AI를 “더 똑똑하게” 만드는 대신 “90분 동안 추적·피격·사망만 구현”이라고 정하면 시간과 범위의 기준이 생긴다. 이 글에서는 시간이 끝났을 때 결과가 부족하면 작업을 연장하기보다 범위를 줄이는 운영 규칙을 권장한다.
게임잼의 실제 가용 개발 시간은 48시간보다 작다. 수면, 식사, 회의, 빌드 대기, 업로드, 오류 대응 시간을 제외해야 한다.
예를 들어 팀원 1인당 수면 10시간, 식사·휴식 4시간, 조율 3시간, 제출 버퍼 6시간을 잡으면 핵심 제작 시간은 약 25시간이다. 일정은 48시간 기준이 아니라 이 25시간을 기준으로 설계해야 한다.
48시간 게임잼 일정표는 어떻게 짜야 할까?
이 일정 예시는 제출 시각에서 거꾸로 계산한다. 마지막 6시간을 보호 구역으로 예약하고 각 구간의 산출물을 명확히 정의한다. 아래 시간 배분은 대회 규칙이나 검증된 성공률이 아니라 팀이 조정할 계획의 시작점이다.
| 구간 | 시간 | 반드시 남길 산출물 | 금지할 일 |
|---|---|---|---|
| 방향 결정 | 0~2시간 | 한 문장 콘셉트, 핵심 루프, 역할 분담 | 여러 장르를 병렬 검토하기 |
| 프로토타입 | 2~12시간 | 시작부터 종료까지 플레이 가능한 빌드 | 아트 폴리싱, 콘텐츠 대량 제작 |
| 수직 슬라이스 | 12~24시간 | 대표 스테이지 1개, 승패 조건, 기본 피드백 | 추가 시스템 설계 |
| 콘텐츠·완성도 | 24~36시간 | 필요한 콘텐츠, UI, 사운드 최소 세트 | 핵심 규칙 변경 |
| 안정화 | 36~42시간 | 버그 목록 정리, 릴리스 후보 빌드 | 새 기능 병합 |
| 제출 보호 구역 | 42~48시간 | 최종 빌드, 업로드, 설명문, 스크린샷 | 코드·에셋 변경 |
flowchart LR
A[0~2h 콘셉트 고정] --> B[2~12h 플레이 가능 프로토타입]
B --> C[12~24h 수직 슬라이스]
C --> D[24~36h 콘텐츠와 피드백]
D --> E[36~42h 안정화]
E --> F[42~48h 빌드·업로드·제출]이 흐름에서 가장 중요한 마일스톤은 12시간 지점이다. 이때 게임이 시작되고 플레이어가 행동하며 성공 또는 실패로 끝나야 한다. 그래픽이 임시 도형이어도 괜찮지만 입력, 규칙, 결과 화면은 연결되어 있어야 한다.
Step 1. MVP를 한 문장으로 정의한다
MVP(Minimum Viable Product)는 최소한의 노력으로 검증할 가설에 관한 학습을 얻기 위한 제품 버전이라는 개념이다(Agile Alliance 설명). 이 글에서는 게임잼용 MVP를 “최소 요소로 테마를 전달하고 핵심 플레이 가설을 시험하는 버전”으로 한정한다. 기능 목록보다 플레이어 경험으로 작성한다.
좋은 예시는 다음과 같다.
- 플레이어는 제한 시간 동안 빛을 옮겨 어두운 길을 밝히고 출구에 도달한다.
- 플레이어는 한 가지 공격으로 몰려오는 적을 밀어내며 3개의 방을 통과한다.
- 플레이어는 두 개의 버튼을 번갈아 조작해 불안정한 비행체를 착륙시킨다.
“로그라이크 액션 게임을 만든다”는 장르 설명만으로는 검증할 가설과 최소 범위를 알 수 없다. 반복 구조, 보상, 콘텐츠 수의 상한을 구체화한다.
MVP를 정한 뒤에는 기능을 세 등급으로 분류한다.
| 등급 | 기준 | 예시 |
|---|---|---|
| Must | 없으면 게임 루프가 성립하지 않음 | 이동, 핵심 행동, 승패 조건, 재시작 |
| Should | 재미와 이해를 크게 높임 | 피격 효과, 간단한 튜토리얼, 1종의 사운드 |
| Could | 있으면 좋지만 제출에는 불필요 | 업적, 설정 메뉴, 추가 캐릭터, 온라인 랭킹 |
각 기능에 시간 상한을 붙인다. 예를 들어 “튜토리얼 30분”, “배경음 적용 20분”, “보스 패턴 90분”처럼 정한다. 상한을 넘긴 Must 기능은 단순화하고 Should와 Could 기능은 즉시 삭제 후보로 이동한다.
Step 2. 기능이 아니라 플레이 가능한 빌드를 매 시간 상자마다 만든다
작업 단위는 “적 스프라이트 그리기”보다 “적이 등장해 플레이어를 위협하고 처치 가능하게 만들기”가 좋다. 전자는 파일만 남기지만 후자는 플레이 테스트 가능한 변화를 남긴다.
90~120분 단위의 타임박스는 다음 순서로 운영할 수 있다.
- 시작 전에 완료 조건을 한 줄로 적는다. 예: “WASD 이동, 충돌 시 체력 감소, 0이면 게임 오버 화면 표시”.
- 시간 상자 동안에는 다른 작업 요청을 받지 않는다. 긴급 버그가 아니라면 다음 블록의 백로그로 보낸다.
- 종료 시점에 실행 가능한 빌드를 만든다. 미완성이라면 다음 블록으로 넘기기 전에 기능을 더 작게 자른다.
- 5~10분 동안 팀이 직접 플레이하고 발견한 문제를
Must / Should / Could로 다시 분류한다.
Unity 6, Godot 4, Unreal Engine 5처럼 어떤 엔진을 쓰더라도 원칙은 같다. 자동 저장이나 엔진 기능에 의존하지 말고 타임박스 종료 때마다 실행 파일 또는 웹 빌드를 실제로 실행해 본다. 엔진 에디터에서만 동작하는 상태는 제출물 검증이 아니다.
Step 3. 역할 분담과 통합 규칙을 먼저 문서화한다
48시간 게임잼에서는 코드 충돌뿐 아니라 작업 경계의 혼선도 줄여야 한다. 시작 후 30분 안에 아래 항목을 공유 문서나 README.md에 적어 두는 일정을 제안한다.
| 항목 | 결정할 내용 |
|---|---|
| 빌드 담당 | 최종 빌드와 제출 페이지를 책임질 1명 |
| 브랜치 규칙 | main은 실행 가능 상태 유지, 기능은 짧은 브랜치에서 작업 |
| 에셋 규칙 | 폴더 구조, 파일명, 해상도, 투명 PNG 또는 WAV 여부 |
| 변경 동결 | 종료 6시간 전 기능 추가 중단, 종료 2시간 전 코드 병합 중단 |
| 의사결정 | 의견이 갈릴 때 최종 결정권자와 결정 기한 |
예를 들어 Git을 쓴다면 feature/dash-feedback 브랜치에서 변경을 먼저 커밋하고 최신 main을 통합한다. 아래는 브랜치 이름과 원격 이름을 이렇게 정한 경우의 예시다. 관련 변경만 스테이징하고, 병합 충돌이 있으면 해결한 뒤 실행 검증을 완료해야 한다.
git status
git add <변경한-파일-경로>
git commit -m "Add player dash feedback"
git fetch origin
git merge origin/main
git push origin feature/dash-feedback명령 자체보다 중요한 것은 작은 단위로 병합하고 병합 직후 전체 게임을 실행하는 습관이다. 대형 기능 세 개를 종료 직전에 한꺼번에 합치는 방식은 48시간 일정에 맞지 않는다.
스코프를 줄여야 하는 신호는 무엇인가?
다음 중 하나라도 발생하면 일정이 아니라 범위를 수정해야 한다.
- 12시간이 지났는데 시작부터 종료까지 이어지는 플레이가 없다.
- 같은 시스템을 두 번째 타임박스까지 연장하고 있다.
- 콘텐츠가 없어서가 아니라 규칙이 계속 바뀌어서 레벨을 만들 수 없다.
- 팀원이 다른 사람의 결과물을 기다리느라 30분 이상 멈춰 있다.
- 마지막 6시간에 구현해야 할 핵심 기능이 남아 있다.
스코프 축소는 실패가 아니다. 한 종류의 적만 남기고 스테이지를 3개에서 1개로 줄이고 절차적 생성 대신 고정 맵을 쓰는 결정은 게임의 제출 가능성을 높인다. 테마 전달에 직접 기여하지 않는 시스템부터 제거하면 된다.
마감 직전 6시간은 어떻게 보호할까?
제출 보호 구역에서는 게임을 “만드는” 대신 “제출 가능한 상태인지 증명”한다. 이 시간에 발견한 문제는 치명도 기준으로만 처리한다.
| 우선순위 | 처리 기준 | 예시 |
|---|---|---|
| P0 | 실행·제출을 막음 | 빌드 실패, 시작 불가, 진행 불가, 크래시 |
| P1 | 핵심 루프를 훼손함 | 승리 조건 불가, 입력 불가, 저장 파일 때문에 실행 불가 |
| P2 | 경험을 저하시킴 | 오탈자, 일부 UI 정렬, 효과음 크기 |
| P3 | 취향 또는 추가 개선 | 새 이펙트, 추가 맵, 난이도 재설계 |
P0와 P1만 수정하고 수정할 때마다 새 빌드를 만든다. 마지막 2시간에는 코드와 에셋 병합을 중단하는 편이 안전하다. 제출 페이지의 게임명, 조작법, 플랫폼, 크레딧, 라이선스, 스크린샷, 게임 파일 압축 해제 여부도 이 구간의 체크리스트에 포함한다.
자주 묻는 질문 (FAQ)
48시간 게임잼에서 몇 시간 전부터 기능 추가를 멈춰야 하나?
최소 6시간 전부터 기능 추가를 멈추는 것이 좋다. 팀 규모가 크거나 배포 대상이 여러 플랫폼이면 8~10시간 전으로 앞당긴다.
프로토타입이 재미없으면 처음부터 다시 만들어야 하나?
아니다. 먼저 핵심 행동 하나, 목표 하나, 실패 조건 하나만 남긴 뒤 30~60분 안에 수정 가능한 가설을 시험한다. 그 시간 안에 개선되지 않으면 테마 해석이나 콘텐츠 범위를 바꾸는 편이 낫다.
아트와 사운드는 언제 넣어야 하나?
핵심 루프가 작동한 뒤에 넣는다. 다만 조작 피드백에 필요한 최소 이펙트와 효과음은 수직 슬라이스 단계에서 넣어 플레이 감각을 확인한다.
정리: 완주를 위한 시간의 우선순위
이 일정안은 불확실성을 일찍 확인하도록 설계했다. 12시간 내 플레이 가능한 MVP, 6시간의 제출 보호 구역, 짧은 타임박스마다 실행하는 빌드를 시작점으로 삼고 팀의 작업 속도와 제출 조건에 맞춰 조정하자. 이 시간 배분의 성공률이나 위험 감소 폭을 측정한 결과는 아니다.
남는 시간이 생겼을 때만 콘텐츠와 연출을 더하자. 제출 가능한 작은 게임은 제출하지 못한 큰 게임보다 항상 낫다.
