게임잼 48시간: AI 툴을 최대 활용하는 타임박싱 전략
48시간 게임잼에서 AI 툴이 작업 시간을 잡아먹지 않도록 기획·에셋·코드·테스트 시간을 분리하는 방법을 정리합니다. 스코프 잠금, 프롬프트 제한, 검증 루프와 시간표까지 바로 적용할 수 있습니다.
핵심 요약
48시간 게임잼에서 AI는 제작 속도를 높일 수 있지만 결과를 고르기·고치기·통합하는 시간이 늘면 오히려 일정이 무너집니다. 해결책은 AI를 상시 사용하는 것이 아니라 결과물이 명확한 짧은 작업 슬롯에 배치하고 각 슬롯의 종료 조건과 대체안을 미리 정하는 것입니다.
운영 원칙은 핵심 루프 우선, AI 출력 검증 시간 예약, 마감 6시간 전 기능 동결입니다. AI가 만든 결과도 프로젝트에 들어온 순간부터는 일반 작업물처럼 빌드와 플레이 테스트를 통과해야 합니다.
왜 게임잼에서 AI 활용 시간이 통제되지 않는가?
AI 툴은 초안 생성에는 빠르지만 게임잼의 병목은 보통 초안 이후에 발생합니다. 이미지 생성 결과를 비교하거나 생성 코드를 기존 구조에 맞추거나 저작권·라이선스 조건과 엔진 호환성을 확인하는 시간이 누적됩니다.
특히 다음 상황은 위험합니다.
| 상황 | 흔한 행동 | 일정에 미치는 영향 | 타임박싱 대응 |
|---|---|---|---|
| 아이디어 탐색 | 프롬프트를 계속 바꾼다 | 결정이 지연된다 | 20분 뒤 후보 3개 중 하나를 선택한다 |
| 이미지 생성 | 마음에 드는 결과를 끝없이 찾는다 | 스타일 불일치와 후처리가 늘어난다 | 30분 안에 채택 또는 단색 도형으로 대체한다 |
| 코드 생성 | 큰 기능을 한 번에 요청한다 | 통합·디버깅 범위가 커진다 | 함수 또는 컴포넌트 단위로 생성한다 |
| 문서·카피 작성 | 문구를 과도하게 다듬는다 | 플레이 가능 버전이 늦어진다 | 제출 2시간 전에만 처리한다 |
게임잼에서 남은 시간을 단순히 T라고 보면 실제 제작 가능 시간은 AI 검토·통합·재작업 시간을 뺀 값입니다.
따라서 AI 사용 시간을 늘리는 것이 목표가 아니라 T_rework를 줄이는 것이 목표여야 합니다.
48시간 게임잼 타임박싱은 어떻게 설계할까?
1. 시작 90분 안에 핵심 루프와 금지 목록을 확정한다
첫 90분에는 완성도를 높이지 않습니다. 플레이어가 반복할 행동 하나와 성공·실패 조건만 정합니다.
예를 들어 Godot 4.x의 2D 게임이라면 다음처럼 작게 고정합니다.
- 입력: 방향키 이동과
Space한 가지 행동 - 목표: 60초 안에 아이템 10개 수집
- 실패: 체력이 0이 되거나 제한 시간이 끝남
- 화면: 시작, 플레이, 결과의 3개 상태
- 금지: 온라인 기능, 절차적 맵 생성, 다수의 캐릭터 클래스, 저장 시스템
AI에는 이 단계에서 아이디어 10개를 요구하지 말고 이미 고른 콘셉트의 빈틈을 찾는 용도로 씁니다. 예를 들어 “60초 수집 게임에서 조작 하나로 긴장감을 만드는 장애물 패턴 3개”처럼 출력 범위를 제한합니다.
2. AI 작업은 ‘입력-출력-검증’ 3단계 슬롯으로 쪼갠다
AI 작업 하나에는 생성 시간만 배정하면 안 됩니다. 출력물을 적용하고 확인하는 시간이 반드시 필요합니다.
| 단계 | 권장 시간 | 종료 조건 |
|---|---|---|
| 입력 준비 | 5~10분 | 목표, 형식, 제약을 프롬프트에 적었다 |
| 생성·선택 | 15~25분 | 최대 3회 생성 후 하나를 채택했다 |
| 통합·검증 | 15~30분 | 엔진에서 실행되고 핵심 흐름을 방해하지 않는다 |
예를 들어 AI에게 GDScript 코드를 요청할 때는 “적 이동 시스템 전체”가 아니라 “CharacterBody2D가 목표 위치까지 이동하고 충돌 시 멈추는 _physics_process(delta) 함수”처럼 요청합니다. 생성된 코드는 프로젝트의 입력 맵, 노드 경로, Godot 4 API와 맞는지 즉시 확인합니다.
func _physics_process(delta: float) -> void:
var direction := global_position.direction_to(target.global_position)
velocity = direction * speed
move_and_slide()이 코드도 target이 항상 존재하는지 적이 목표에 도달했을 때 행동이 바뀌는지 충돌 레이어가 의도대로 설정됐는지 검증해야 합니다. 코드가 짧아도 검증을 생략하지 않는 이유입니다.
3. 마감 6시간 전에는 기능을 동결하고 제출물을 만든다
남은 6시간은 새 기능을 넣는 시간이 아닙니다. 치명적인 버그 수정, 난이도 조정, 사운드·UI 최소 보강, 빌드와 제출 페이지 작성에 씁니다.
flowchart LR
A[0~1.5시간\n핵심 루프 확정] --> B[1.5~18시간\n플레이 가능 버전]
B --> C[18~36시간\n콘텐츠·AI 보조 제작]
C --> D[36~42시간\n통합 테스트]
D --> E[42~48시간\n기능 동결·빌드·제출]기능 동결 뒤에 발견한 아이디어는 버리지 말고 post-jam.md 또는 이슈 목록에 적어 둡니다. 지금 추가하지 않는 결정이 다음 게임의 소재를 잃는다는 뜻은 아닙니다.
역할별 AI 타임박싱 예시는 무엇인가?
기획 담당: 결정 지원에만 사용한다
- 20분: 테마 해석과 핵심 동사 후보 정리
- 15분: 선택한 루프의 실패 조건과 점수 규칙 점검
- 10분: 팀 공유용 원페이지 문서 초안
AI가 낸 기획안은 선택지가 아니라 판단 재료입니다. 팀이 결정하지 못하는 상태를 더 오래 유지시키면 안 됩니다.
프로그래머: 작은 단위 생성 뒤 즉시 실행한다
- 25분: UI 상태 전환, 타이머, 스폰 규칙 중 한 기능 생성·구현
- 20분: 로컬 실행과 오류 수정
- 10분: 실제 플레이로 회귀 확인
생성 코드에는 프로젝트 전체를 읽지 못한 전제가 섞일 수 있습니다. 따라서 한 슬롯에서 다루는 파일 수를 제한하고 컴파일 오류를 다음 슬롯으로 넘기지 않습니다.
아트·사운드 담당: 최종 품질보다 일관성을 우선한다
- 30분: 스타일 기준이 담긴 기준 이미지 또는 색상 팔레트 확정
- 45분: 필수 에셋 묶음 생성·선택
- 30분: 투명 배경, 해상도, 스프라이트 시트, 볼륨 정리
에셋은 개별 완성도보다 한 화면에서 함께 보일 때의 일관성이 중요합니다. 첫 30분 안에 팔레트, 외곽선 유무, 시점, 기본 해상도를 정하고 이후에는 그 기준을 프롬프트에 반복해서 넣습니다.
AI 프롬프트에는 어떤 제약을 넣어야 할까?
좋은 게임잼 프롬프트는 창의적인 지시보다 검증 가능한 제약을 포함합니다.
| 항목 | 나쁜 요청 | 더 나은 요청 |
|---|---|---|
| 코드 | “플레이어 시스템 만들어 줘” | “Godot 4 GDScript, CharacterBody2D, 좌우 이동과 점프만 포함한 함수 작성” |
| 이미지 | “귀여운 몬스터” | “32×32 픽셀 아트, 정면 3/4 시점, 4색 팔레트, 투명 배경, 공격 모션 제외” |
| 밸런스 | “재밌는 난이도” | “60초 세션, 초보자가 첫 판에서 목표의 60%에 도달하도록 스폰 간격 3안 제시” |
| 카피 | “게임 설명 써 줘” | “itch.io 소개문 80자, 조작법 한 문장, 한국어, 과장 표현 제외” |
프롬프트 끝에는 채택 기준을 넣는 편이 좋습니다. 예를 들어 “외부 패키지 추가 금지”, “한 파일에서 동작”, “반환값과 실패 조건 명시” 같은 제약은 통합 시간을 줄입니다.
협업 중 AI 산출물은 어떻게 기록할까?
별도 문서 체계를 크게 만들 필요는 없습니다. 팀이 모두 보는 README 또는 공유 메모에 다음 네 줄만 유지하면 충분합니다.
[결정] 적은 3종이 아니라 1종으로 유지한다.
[AI 출력] UI 아이콘 6개 생성, icon_03.webp 채택.
[검증] Godot 4.3 에디터와 Windows 빌드에서 표시 확인.
[보류] 튜토리얼 화면은 제출 후 개선 후보로 이동.이 기록은 누가 무엇을 만들었는지보다 왜 범위를 줄였는지와 어떤 결과가 검증됐는지를 남깁니다. 피로가 쌓이는 후반부에 같은 논의를 반복하지 않게 해 줍니다.
자주 묻는 질문 (FAQ)
AI로 만든 코드는 게임잼에서 바로 사용해도 될까?
대회 규정을 먼저 확인해야 합니다. 허용되는 경우에도 의존성, 라이선스, 엔진 버전 호환성, 실행 여부를 팀이 검증한 뒤 사용해야 합니다.
AI 이미지 생성에 몇 시간을 써도 될까?
핵심 루프가 플레이 가능한 뒤에 시작하고 필수 에셋 묶음당 30~60분 상한을 두는 것이 안전합니다. 시간 내에 채택하지 못하면 도형·기본 에셋으로 대체합니다.
팀원 모두가 AI를 동시에 쓰면 더 빠른가?
항상 그렇지는 않습니다. 결과물을 통합할 담당자와 스타일·코드 기준이 없으면 충돌 비용이 커집니다. 병렬 생성보다 공유 기준과 검증 순서를 먼저 정하세요.
정리: AI는 속도 기능이 아니라 일정 제약 아래의 생산 도구다
48시간 게임잼의 우선순위는 멋진 초안이 아니라 제출 가능한 플레이 경험입니다. AI 작업마다 생성 횟수와 종료 시간을 제한하고 통합·검증 시간을 별도로 잡으면 도구를 적극적으로 쓰면서도 스코프를 지킬 수 있습니다.
가장 단순한 운영 규칙은 세 가지입니다. 첫째, 90분 안에 핵심 루프를 잠급니다. 둘째, AI 출력은 3회 생성 또는 30분 중 먼저 도달한 시점에 선택합니다. 셋째, 마감 6시간 전 기능을 동결하고 빌드와 제출에 집중합니다.
