게임 프로토타이핑에서 버려야 할 것들: 리소스를 아끼는 스코프 관리법
게임 프로토타입 단계에서 완성도와 기능을 과감히 덜어내는 기준을 정리한다. 핵심 가설 검증에만 집중하도록 아트, UI, 콘텐츠, 기술 부채의 우선순위를 관리하는 실무 방법을 소개한다.
핵심 요약
프로토타입에서 버려야 할 것은 ‘나중에 필요할 수 있는 기능’이 아니라 현재 검증하려는 가설의 결과를 바꾸지 않는 모든 작업이다. 플레이어가 핵심 행동을 이해하고 반복할 이유가 있는지만 확인한 뒤 그 결과를 바꾸는 요소만 다음 단계로 가져간다.
프로토타입은 작은 완제품이 아니다. 예를 들어 액션 게임이라면 ‘조작 30초 안에 재미를 느끼는가’를 검증하는 실험이며 정식 UI·콘텐츠 볼륨·확장 가능한 아키텍처를 만드는 단계가 아니다.
프로토타입의 목표는 무엇인가?
프로토타입의 산출물은 빌드 자체가 아니라 의사결정에 쓸 수 있는 증거다. 따라서 시작 전에 한 문장으로 검증 가설을 작성한다.
가설: 플레이어는 적의 공격 예고를 본 뒤 회피하고 반격하는 5초 루프를 반복해서 즐길 것이다.
이 가설이라면 필요한 것은 플레이어 이동, 적 1종, 공격 예고, 피격과 회피, 짧은 피드백뿐이다. 캐릭터 커스터마이징, 저장 시스템, 튜토리얼, 10개 스테이지는 검증 대상을 흐린다.
검증 비용은 다음처럼 생각할 수 있다.
같은 정보를 얻을 수 있다면 더 싼 구현이 좋은 프로토타입이다.
프로토타입 단계에서 무엇을 버려야 하는가?
| 버릴 대상 | 왜 버리는가 | 최소 대체안 | 다시 도입할 시점 |
|---|---|---|---|
| 최종 아트 에셋 | 제작 시간이 길고 게임성 판단을 왜곡할 수 있다 | Primitive, 단색 스프라이트, 임시 SFX | 핵심 루프 통과 후 |
| 완성형 UI/UX | 화면 설계가 반복해서 바뀐다 | 디버그 텍스트, 단축키, 한 화면 메뉴 | 플레이테스트 흐름이 안정된 후 |
| 콘텐츠 볼륨 | 맵과 적 수를 늘려도 핵심 재미가 증명되지는 않는다 | 맵 1개, 적 1~2종, 무기 1개 | 리텐션 또는 반복 플레이 검증 후 |
| 범용 시스템 | 미래 요구를 추측한 추상화는 수정 비용을 키운다 | 현재 사례 하나를 직접 구현 | 반복 패턴이 실제로 2~3회 나온 후 |
| 온라인·저장 기능 | 개발과 테스트 경로가 급격히 복잡해진다 | 로컬 고정 데이터, 세션 내 테스트 | 멀티플레이나 장기 진행이 핵심 가설일 때 |
| 모든 플랫폼 대응 | 입력·성능·인증 이슈가 검증 속도를 늦춘다 | 목표 플랫폼 1개 | 제품 방향 확정 후 |
최종 아트를 먼저 버려야 하는 이유
최종 아트는 프로토타입을 그럴듯하게 만들지만 팀이 ‘재미’보다 ‘보기 좋은 상태’를 평가하게 만들기 쉽다. 특히 3D 프로젝트에서 리깅, 셰이더, VFX, 애니메이션 블렌드 트리는 루프 검증보다 훨씬 큰 비용을 만든다.
Unity 6 또는 Unreal Engine 5에서라면 충돌체, 기본 머티리얼, 간단한 파티클만으로도 조작감과 전투 판정은 확인할 수 있다. 단, 피격 여부와 공격 범위처럼 재미를 좌우하는 피드백은 임시 상태라도 명확해야 한다. 빨간 플래시, 짧은 화면 흔들림, 숫자 텍스트면 충분하다.
범용 아키텍처를 버려야 하는 이유
프로토타입에 상태 머신 프레임워크, 범용 퀘스트 시스템, 데이터 주도형 콘텐츠 파이프라인을 먼저 만들면 코드가 늘어나는 만큼 실험 속도는 느려진다. 추상화는 이미 반복되는 문제를 줄일 때 가치가 있다.
예를 들어 무기 하나만 시험한다면 무기 데이터베이스보다 상수 몇 개가 낫다.
public sealed class PrototypeWeapon
{
public float damage = 10f;
public float cooldownSeconds = 0.35f;
public float range = 2.2f;
}두 번째 무기와 세 번째 무기를 추가하면서 피해량 계산, 발사 방식, 장착 규칙이 실제로 달라질 때 구조를 분리한다. 이 순서는 재작업을 무조건 피하려는 것이 아니라 증거 없이 재작업 비용을 선불로 내지 않는 방법이다.
프로토타입 스코프는 어떻게 정할까?
1. 검증 질문을 하나로 제한한다
한 빌드가 답해야 할 질문은 하나가 가장 좋다. 다음처럼 질문과 측정 기준을 함께 적는다.
| 항목 | 예시 |
|---|---|
| 검증 질문 | 적의 패턴을 읽고 회피하는 것이 재미있는가? |
| 대상 | 액션 게임 경험이 있는 플레이어 5명 |
| 관찰 지표 | 자발적 재시작 횟수, 사망 원인 설명 가능 여부, 5점 재미 점수 |
| 종료 조건 | 평균 재미 점수 3점 미만이면 패턴 또는 조작을 수정한다 |
‘게임이 재미있는가?’는 너무 넓다. 조작, 전투, 성장, 협동, 탐험 중 한 가지 행동으로 질문을 좁혀야 결과를 해석할 수 있다.
2. 기능을 가설 기여도로 분류한다
백로그의 모든 항목에 아래 세 가지 중 하나를 붙인다.
- 필수: 없으면 가설을 시험할 수 없다.
- 보조: 테스트를 원활하게 하지만 없어도 결론은 낼 수 있다.
- 보류: 현재 가설의 결과를 바꾸지 않는다.
보류 항목은 삭제가 아니라 별도 목록으로 이동한다. 이렇게 하면 팀원이 아이디어를 잃는 불안을 줄이면서 현재 스프린트를 보호할 수 있다.
3. 시간 상한을 먼저 정하고 기능을 맞춘다
프로토타입은 ‘기능을 다 만들 때까지’ 진행하면 끝나지 않는다. 예를 들어 5인 팀이 5일 동안 작업한다면 최대 투입량은 다음과 같다.
하지만 회의, 빌드 오류, 플레이테스트, 수정 시간을 빼야 한다. 처음부터 총량의 50~60%만 기능 제작에 배정하고 나머지는 통합과 수정에 남겨 둔다.
기능을 자를 때 사용할 수 있는 의사결정 흐름
flowchart TD
A[기능 후보] --> B{현재 가설의 결과를 바꾸는가?}
B -- 아니오 --> C[보류 목록으로 이동]
B -- 예 --> D{수동 테스트나 임시 구현으로 대체 가능한가?}
D -- 예 --> E[가장 싼 대체안 선택]
D -- 아니오 --> F{정해 둔 시간 상한 안에 가능한가?}
F -- 예 --> G[이번 프로토타입에 포함]
F -- 아니오 --> H[가설을 더 작은 단위로 분할]이 흐름에서 중요한 질문은 ‘좋은 기능인가?’가 아니다. 이번 테스트에서 필요한가?다. 좋은 기능도 현재 가설과 무관하면 보류 대상이다.
협업에서 리소스 낭비를 막는 문서화 방법
문서는 길게 쓰기보다 판단 근거를 남기는 데 써야 한다. 프로토타입 킥오프 문서는 한 페이지면 충분하다.
# Prototype P-03: 회피-반격 루프
- 가설: 공격 예고 0.6초가 있을 때 회피 후 반격이 만족스럽다.
- 포함: 이동, 회피, 근접 공격, 적 1종, 체력, 재시작 버튼
- 제외: 스토리, 저장, 상점, 최종 UI, 다국어, 최종 아트
- 기간: 2026-08-10 ~ 2026-08-14
- 성공 기준: 테스트 5명 중 3명 이상이 자발적으로 3회 이상 재시작
- 결정권자: 게임 디렉터 1명매일 10분 정도로 다음 세 가지만 확인한다.
- 어제 만든 항목이 가설 검증에 직접 기여했는가?
- 오늘 새로 생긴 요청은 필수·보조·보류 중 어디인가?
- 성공 기준을 판단할 수 있는 빌드가 언제 나오는가?
‘조금만 더 다듬자’는 요청은 가장 흔한 범위 확장 신호다. 그 요청이 성공 기준을 바꾸는지 묻고 바꾸지 않는다면 보류 목록으로 옮긴다.
프로토타입에서 기술 부채는 어디까지 허용해야 할까?
기술 부채 자체가 문제는 아니다. 문제는 팀이 임시 구현을 정식 코드로 오해하는 상황이다. 그래서 임시 코드는 명시적으로 표시한다.
// PROTOTYPE ONLY: P-03 테스트 종료 후 제거 또는 재설계한다.
[SerializeField] private float enemyTelegraphSeconds = 0.6f;다만 다음 항목은 프로토타입이어도 함부로 버리지 않는 편이 좋다.
- 빌드가 반복해서 실패하는 문제
- 테스트 결과를 왜곡하는 입력 지연과 판정 오류
- 팀원이 데이터를 잃을 수 있는 버전 관리 규칙
- 플레이테스터의 안전과 개인정보 처리
즉, 제품 품질은 낮춰도 되지만 실험의 신뢰도와 협업의 안전성은 낮추면 안 된다.
자주 묻는 질문 (FAQ)
프로토타입에도 사운드가 필요한가?
핵심 행동의 타이밍과 결과를 이해시키는 사운드는 필요하다. 다만 최종 BGM, 전문 성우 녹음, 완성형 믹싱은 검증 질문에 직접 필요하지 않다면 미룬다.
플레이테스트 전에 버그를 모두 고쳐야 하나?
아니다. 플레이어가 핵심 루프를 경험할 수 없는 버그와 측정 결과를 왜곡하는 버그만 우선 수정한다. 나머지는 알려진 이슈로 기록한 뒤 테스트를 진행할 수 있다.
프로토타입을 언제 정식 개발로 전환해야 하나?
검증 가설이 통과했고 다음 위험 요소가 무엇인지 명확해졌을 때다. 이때도 프로토타입 코드를 그대로 확장하기보다 유지할 부분과 폐기할 부분을 별도로 결정한다.
마무리
리소스를 아끼는 프로토타이핑은 적게 만드는 기술이 아니라 답을 얻기 위해 필요한 것만 만드는 운영 방식이다. 가설 하나, 시간 상한 하나, 성공 기준 하나를 먼저 정하고 그 결과를 바꾸지 않는 기능은 과감히 보류하자. 빠른 폐기는 실패가 아니라 더 빠른 판단을 위한 생산성이다.
