게임 프로토타입 3개를 폐기하고 본 프로젝트를 수립한 리소스 회고

핵심 요약

프로토타입을 폐기했다는 사실만으로 리소스가 낭비된 것은 아니다. 폐기 원인을 검증 가설·투입 시간·재사용 가능 자산으로 기록하면 다음 본 프로젝트의 스코프와 일정 추정 정확도를 높이는 학습 비용이 된다.

핵심은 세 프로토타입을 성공·실패로 평가하지 않고 어떤 가설을 검증했고 무엇을 남겼는지 분리하는 것이다. 이후 본 프로젝트는 검증된 재미의 핵심 루프만 MVP 범위에 넣고 불확실한 기능은 마일스톤 뒤로 미룬다.

왜 프로토타입 3개를 파기해도 리소스 회고가 필요한가?

게임 프로토타입은 완성도보다 의사결정 속도를 위해 만든다. 문제는 중단된 빌드를 단순히 실패작으로 분류할 때 발생한다. 팀은 같은 논쟁을 반복하고 이미 만든 UI·입력 처리·에셋 파이프라인을 다시 만들며 본 프로젝트 일정은 희망적인 추정에 기대게 된다.

프로토타입 회고의 목적은 세 가지다.

1. 중단 결정의 근거를 남긴다. 재미 부족, 제작 비용 과다, 기술 위험 중 무엇이 결정적이었는지 구분한다.
2. 재사용 가능한 리소스를 목록화한다. 코드, 아트 소스, 툴, 문서, 외부 협업 계약을 분리해 관리한다.
3. 본 프로젝트의 MVP를 줄인다. 검증되지 않은 가설을 출시 필수 항목에서 제외한다.

프로토타입 비용은 다음처럼 계산할 수 있다.

$$프로토타입\ 회수율 = \frac{재사용\ 가능\ 리소스의\ 추정\ 절감\ 시간}{프로토타입에\ 투입한\ 총\ 시간} \times 100$$

이 수치는 자산의 금전적 가치를 정밀하게 산정하려는 도구가 아니다. 다음 프로젝트에서 실제로 절약할 개발 시간을 팀이 함께 보수적으로 추정하기 위한 기준이다.

프로토타입 폐기 원인은 어떻게 분류할까?

세 개의 프로토타입을 같은 기준으로 비교해야 감정적 평가를 줄일 수 있다. 예를 들어 Unity 6 또는 Godot 4 같은 엔진 버전, 목표 플랫폼, 테스트 인원, 플레이 세션 길이를 회고 문서에 명시한다. 기술적 문제가 재미의 문제로 혹은 일정 문제로 잘못 기록되는 일을 막을 수 있다.

구분	확인할 질문	기록 예시	본 프로젝트 반영 방식
핵심 재미	플레이어가 반복 행동을 자발적으로 이어 갔는가?	10분 테스트에서 재시도 동기가 약함	핵심 루프 재설계 또는 제외
제작 비용	콘텐츠 1개를 만드는 데 얼마나 걸렸는가?	적 캐릭터 1종 제작에 3인일 소요	자동화, 스타일 변경, 콘텐츠 축소
기술 위험	목표 플랫폼에서 안정적으로 동작하는가?	저사양 기기에서 프레임 타임 급증	기술 스파이크를 선행 마일스톤으로 분리
협업 마찰	결정과 전달이 지연된 지점은 어디인가?	기획 변경이 아트 작업 후 전달됨	결정 로그와 변경 요청 절차 도입
시장 적합성	한 문장으로 차별점을 설명할 수 있는가?	유사 게임과의 구분이 모호함	포지셔닝 재정의 또는 방향 전환

프로토타입 A·B·C 회고에서 남길 최소 기록

각 프로토타입마다 한 페이지 분량의 카드로 정리하면 충분하다.

• 시작 가설: “2분 내 한 판이 끝나는 협동 전투가 반복 플레이를 유도한다”처럼 검증 가능한 문장
• 검증 방법: 빌드 버전, 플레이테스트 대상, 세션 수, 관찰 지표
• 결과: 가설 채택·보류·기각 중 하나와 근거
• 투입 리소스: 직군별 인일, 외주비, 라이선스, 장비·서비스 비용
• 남은 자산: 저장소 경로, 원본 파일 경로, 라이선스 상태, 담당자
• 중단 이유: 한 문장 결론과 상세 근거

폐기한 리소스와 재사용할 리소스는 어떻게 구분할까?

“나중에 쓸 수 있다”는 판단은 저장 비용과 탐색 비용을 숨긴다. 본 프로젝트에 실제로 연결할 자산만 유지하고 보관만 할 자산은 별도 아카이브로 이동한다. 단, 외주 에셋과 플러그인은 라이선스 범위를 먼저 확인해야 한다.

리소스 유형	재사용 조건	처리 방식
게임플레이 코드	핵심 루프와 결합도가 낮고 테스트가 있음	공용 패키지 또는 모듈로 추출
UI 프리팹·위젯	정보 구조와 해상도 정책이 유지됨	디자인 시스템 후보로 등록
3D 모델·사운드	계약상 재사용 가능하고 아트 방향과 맞음	원본 포함 에셋 라이브러리 보관
빌드·배포 스크립트	CI 환경과 플랫폼 요구사항이 동일함	본 프로젝트 저장소로 이관 후 검증
실험용 코드	임시 의존성이나 하드코딩이 많음	아카이브만 하고 이관하지 않음
회의 메모	결정 근거가 포함됨	ADR 또는 결정 로그로 요약

특히 코드 재사용은 “복사”보다 “검증”이 우선이다. 입력 처리나 세이브 시스템처럼 여러 기능이 얽힌 코드는 재사용 후보라 해도 새 프로젝트의 요구사항으로 테스트를 통과한 뒤에만 일정 절감분으로 계산한다.

본 프로젝트 MVP는 어떤 순서로 수립해야 할까?

프로토타입 이후에는 기능 목록부터 늘어놓지 않는다. 먼저 검증된 핵심 루프를 확정하고 플레이 가능한 최소 단위를 만든 뒤 제작량을 산정한다.

1. 검증된 가설을 한 문장으로 고정한다

본 프로젝트의 출발점은 “무엇을 만들 것인가”가 아니라 “무엇이 이미 작동한다고 확인했는가”다.

예시는 다음과 같다.

플레이어는 제한된 시간 안에 이동 경로를 선택하고 위험을 감수하는 결정을 반복할 때 가장 높은 몰입을 보였다.

이 문장이 정해지면 이동, 선택, 보상, 실패 피드백은 MVP 후보가 된다. 반면 코스메틱, 랭킹, 여러 난이도, 장기 메타 시스템은 출시 필수가 아닐 수 있다.

2. 코어 루프를 세로 슬라이스로 만든다

세로 슬라이스는 최종 품질의 축소판이 아니라 한 번의 완결된 플레이 경험이다. 다음 항목이 한 빌드에서 이어져야 한다.

1. 게임 시작과 목표 안내
2. 핵심 행동과 즉시 피드백
3. 성공 또는 실패 판정
4. 보상·결과 화면
5. 재시작 또는 다음 선택

이 흐름을 먼저 구현하면 콘텐츠 양이 부족한 상태에서도 재미와 제작 파이프라인을 함께 검증할 수 있다.

flowchart LR
    A[프로토타입 회고] --> B[검증된 핵심 가설]
    B --> C[세로 슬라이스]
    C --> D{플레이테스트 통과?}
    D -- 예 --> E[MVP 기능 고정]
    D -- 아니오 --> B
    E --> F[콘텐츠 생산량 산정]
    F --> G[마일스톤과 출시 범위]

3. 기능을 우선순위와 불확실성으로 나눈다

우선순위는 중요도만으로 정하면 범위가 계속 커진다. 사용자 가치와 구현 불확실성을 함께 본다.

우선순위	기준	예시 대응
P0	핵심 루프가 성립하는 데 필수	입력, 전투 판정, 실패·재시작
P1	첫 플레이 경험을 완성하지만 우회 가능	튜토리얼 개선, 기본 설정 화면
P2	출시 후에도 추가 가능한 가치	업적, 코스메틱, 추가 모드
스파이크	구현 방법이 불명확한 고위험 항목	멀티플레이 동기화, 절차적 생성

스파이크는 기능 개발과 분리한다. 예를 들어 네트워크 동기화가 필요하다면 “멀티플레이 전체 구현”을 일정에 넣는 대신, 목표 동시 접속 수와 허용 지연 시간을 정한 3~5일짜리 기술 검증 태스크를 먼저 둔다.

일정 추정은 왜 인일 합계만으로 부족한가?

인일 합계는 작업량이며 달력상의 기간은 의존성·검토·대기·병렬 가능 인원에 영향을 받는다. 콘텐츠 제작이 병목인 게임에서는 프로그래밍 완료일보다 아트와 QA의 처리량이 출시일을 좌우하는 경우가 많다.

마일스톤별로 다음 네 값을 관리하면 과도한 낙관을 줄일 수 있다.

지표	의미	운영 방법
완료 조건	끝났다고 판단할 수 있는 기준	“구현 완료” 대신 테스트 시나리오로 작성
의존성	선행 작업 또는 외부 결정	담당자와 필요 시점을 명시
버퍼	불확실성 대응 시간	고위험 작업에만 별도 배정
컷 라인	지연 시 제외할 범위	P2부터 제거 순서를 사전 합의

일정은 주간 단위로 재예측한다. 단, 매주 모든 기능의 기간을 다시 협상하면 팀이 계획에 지친다. 완료 조건, 의존성, 컷 라인이 달라진 작업만 갱신하는 방식이 효율적이다.

협업 문서는 무엇만 남겨야 하는가?

문서가 많아질수록 정보가 늘어나는 것은 아니다. 본 프로젝트 초기에 아래 네 문서를 단일 기준 문서로 정하면 대부분의 운영 문제를 줄일 수 있다.

1. 프로젝트 원페이지: 목표 플레이어, 핵심 경험, 플랫폼, MVP, 비목표를 한 페이지에 기록한다.
2. 결정 로그: 언제 누가 어떤 대안을 검토해 왜 결정했는지 남긴다. ADR 형식처럼 배경·결정·영향만 써도 된다.
3. 마일스톤 보드: 태스크 상태보다 완료 조건과 막힌 이유를 우선 표시한다.
4. 에셋 레지스트리: 파일 경로, 소유자, 원본 여부, 라이선스, 재사용 상태를 기록한다.

변경 요청에는 반드시 영향 범위를 붙인다. “보스 패턴을 추가한다”는 요청만으로는 우선순위를 판단할 수 없다. 기획·아트·클라이언트·QA에 미치는 영향, 필요한 인일, 기존 범위에서 무엇을 뺄지를 함께 적어야 한다.

자주 묻는 질문 (FAQ)

프로토타입을 몇 개까지 만들어야 하나요?

개수보다 가설의 수가 기준이다. 하나의 프로토타입으로 핵심 재미와 제작 비용을 모두 검증하지 못했다면 다음 실험이 필요할 수 있다. 반대로 같은 가설을 반복 확인하고 있다면 추가 프로토타입보다 본 프로젝트의 세로 슬라이스가 낫다.

폐기한 프로토타입 코드를 본 프로젝트에 그대로 가져와도 되나요?

그대로 이관하지 않는 편이 안전하다. 새 요구사항에서 테스트하고 외부 의존성과 하드코딩을 정리한 뒤 모듈 단위로 가져온다. 재사용 판단은 작성 당시 품질보다 현재 프로젝트와의 결합도로 한다.

MVP 범위가 계속 커질 때 가장 먼저 해야 할 일은 무엇인가요?

새 기능의 가치만 묻지 말고 기존 범위에서 무엇을 제거할지 함께 결정한다. 컷 라인이 없는 추가는 일정 연장이 아니라 출시 위험 증가로 이어진다.

정리: 폐기는 끝이 아니라 다음 범위를 줄이는 일이다

프로토타입 세 개를 파기한 뒤 남겨야 할 것은 빌드 파일이 아니라 결정의 근거다. 가설별 결과, 투입 시간, 재사용 자산, 중단 이유를 구조적으로 남기면 팀은 실패를 설명하는 데 시간을 쓰지 않고 다음 MVP를 더 작게 정의할 수 있다.

본 프로젝트의 첫 계획은 확정 약속이 아니라 검증된 사실을 반영한 운영 문서여야 한다. 핵심 루프를 세로 슬라이스로 확인하고 불확실한 기능은 스파이크로 분리하며 컷 라인을 합의해 두면 일정과 스코프를 함께 관리할 수 있다.