프로젝트 드롭(Drop) 회고: 왜 내 지난 프로젝트는 실패했는가

먼저, 실패의 이름을 정확히 붙이기

여기서 말하는 ‘프로젝트 드롭’은 특정 실존 프로젝트의 내부 기록이 아니라 인디 게임 개발에서 자주 반복되는 문제를 묶어 만든 가상의 회고 사례다. 실패 원인을 ‘의지가 부족했다’로 정리하면 다음 프로젝트에서도 같은 결정을 반복하기 쉽다.

드롭은 2D 액션 게임으로 시작했다. 플레이어가 낙하하며 적을 피하고 획득한 자원으로 장비를 바꾸는 짧은 반복 구조가 핵심이었다. 문제는 핵심 재미를 검증하기 전에 장비, 스테이지, 적 패턴, 성장 시스템을 동시에 만들기 시작한 데 있었다.

실패는 한 번에 오지 않았다

초기에는 작업량이 늘어나는 것이 진척처럼 보인다. 하지만 플레이 가능한 한 판이 재미있는지 플레이어가 무엇을 이해하지 못하는지 확인하지 않으면 제작물은 자산이 아니라 유지 비용이 된다.

flowchart TD
  A[아이디어 확정] --> B[핵심 조작 프로토타입]
  B --> C{짧은 플레이에서 재미가 확인됐는가?}
  C -- 아니오 --> D[조작·규칙 한 가지 수정]
  D --> B
  C -- 예 --> E[최소 콘텐츠 1세트 제작]
  E --> F{테스트에서 목표가 이해되는가?}
  F -- 아니오 --> G[튜토리얼 또는 규칙 축소]
  G --> E
  F -- 예 --> H[콘텐츠 확장]

드롭은 이 흐름에서 B와 C를 충분히 거치지 못하고 곧바로 H로 이동한 셈이다. 프로토타입의 문제를 콘텐츠 양으로 덮으려 했고 그 결과 수정 범위가 매주 커졌다.

원인 1: 기능 목록이 게임의 목표를 대신했다

기능 목록에는 대시, 무기 여섯 종, 보스, 업그레이드, 업적이 있었다. 그러나 목록만으로는 어떤 기능이 플레이 경험을 바꾸는지 알 수 없다. 기능마다 다음 질문에 답할 수 있어야 한다.

이 기능이 없으면 핵심 재미가 사라지는가?
다음 테스트에서 이 기능을 관찰해야 하는가?
이 기능은 기존 시스템을 몇 곳이나 바꾸는가?

답이 불분명한 기능은 ‘나중에 만들 항목’이지 현재 스프린트의 작업이 아니다. 특히 콘텐츠를 늘리기 전에 한 판의 시작부터 종료까지 플레이어가 무엇을 하고 왜 다시 시작하는지를 확인해야 한다.

원인 2: 측정 기준 없이 테스트했다

친구에게 플레이를 부탁하고 “재밌었어?”라고 묻는 것만으로는 우선순위를 정하기 어렵다. 짧은 테스트라도 관찰 항목을 미리 정하면 피드백이 훨씬 선명해진다.

예를 들어 첫 10분 테스트에서는 다음만 기록할 수 있다.

관찰 항목	확인할 질문	해석
첫 실패 시점	왜 죽었는지 설명하는가	규칙 전달 상태
재시작 여부	바로 한 판 더 하는가	반복 동기
선택 시간	업그레이드 화면에서 멈추는가	선택지의 명확성
목표 설명	게임의 목표를 자기 말로 말하는가	핵심 루프 이해도

이 기록은 통계적으로 일반화하기 위한 데이터가 아니다. 다음 주에 무엇을 고칠지 결정하기 위한 근거다. 같은 문제를 두 명 이상이 겪었다면 플레이어가 틀린 것이 아니라 설계가 설명을 요구하고 있다는 신호로 보는 편이 좋다.

원인 3: 기술 선택이 검증 속도를 늦췄다

새 프레임워크나 복잡한 아키텍처는 장기적으로 도움이 될 수 있다. 다만 프로토타입 단계에서 중요한 것은 확장성이 아니라 수정 속도다. 드롭처럼 규칙이 아직 흔들리는 프로젝트에서는 데이터 구조도 자주 바뀐다.

다음은 업그레이드 효과를 작게 정의하는 예시다. 처음부터 범용 이벤트 시스템을 만들기보다 테스트에 필요한 효과를 명시적으로 구현해도 충분하다.

type PlayerStats = {
  maxHealth: number;
  moveSpeed: number;
  dashCooldown: number;
};

type Upgrade = {
  id: string;
  apply: (stats: PlayerStats) => PlayerStats;
};

const swiftBoots: Upgrade = {
  id: 'swift-boots',
  apply: (stats) => ({
    ...stats,
    moveSpeed: stats.moveSpeed + 0.8,
  }),
};

이 방식의 장점은 효과와 결과가 가까이 있다는 점이다. 규칙이 굳은 뒤에만 데이터 주도 구조나 범용 시스템으로 옮겨도 늦지 않다.

원인 4: 중단 기준이 없었다

계속 개발하는 결정도 비용을 쓴다. 드롭에는 ‘이번 달 안에 재미를 찾지 못하면 방향을 바꾼다’ 같은 기준이 없었다. 그래서 이미 의심스러운 시스템에도 더 많은 콘텐츠와 시간을 투입했다.

중단 기준은 포기가 아니라 실험의 경계다. 예를 들면 다음처럼 정할 수 있다.

3회의 외부 플레이 테스트 뒤에도 핵심 목표를 설명하는 사람이 없다면 규칙을 줄인다.
2주 안에 10분짜리 완결 플레이를 만들지 못하면 기능을 삭제한다.
핵심 조작을 바꿔도 재시작률이 오르지 않으면 장르 가정을 다시 검토한다.

중요한 것은 숫자 자체가 아니라 결과가 나왔을 때 무엇을 할지 미리 합의하는 일이다.

다음 프로젝트에서 지킬 최소 규칙

드롭의 실패를 한 문장으로 정리하면 ‘검증되지 않은 가설 위에 너무 많은 것을 쌓았다’가 된다. 다음 프로젝트에서는 다음 순서를 지키는 편이 안전하다.

한 문장으로 핵심 행동과 보상을 설명한다.
그 행동만 가능한 5분짜리 프로토타입을 만든다.
외부 플레이 테스트를 관찰하고 한 번에 한 가설만 수정한다.
처음부터 끝까지 가능한 최소 콘텐츠를 만든 뒤 확장한다.
매주 계속할 조건과 줄일 조건을 다시 확인한다.

완성하지 못한 프로젝트도 낭비로 끝날 필요는 없다. 무엇을 만들었는지보다 어떤 가정을 검증하지 않았는지를 기록해 두면 다음 프로젝트의 시작점은 훨씬 단단해진다.