1인 개발 프로젝트의 스콥 크립을 막는 의사결정 프로세스
아이디어를 버티는 힘이 아니라 추가 요청을 분류하고 보류하며 검증하는 절차가 1인 개발의 완주율을 높인다. 작은 프로젝트에 바로 적용할 수 있는 스콥 크립 방지 프로세스를 정리한다.
스콥 크립은 의욕 부족 문제가 아니다
스콥 크립은 게임의 범위가 명시적인 재계획 없이 조금씩 커지는 현상이다. 전투 시스템에 콤보를 하나 더 넣고 UI를 손보다가 장비 제작을 추가하고 출시 전에는 온라인 순위표까지 붙이는 식이다. 각 항목은 그럴듯하지만 합쳐지면 일정과 품질을 동시에 무너뜨린다.
1인 개발에서는 개발자 본인이 기획자, 프로그래머, 아티스트, QA 역할을 오가므로 새 아이디어가 곧바로 작업으로 이어지기 쉽다. 따라서 중요한 것은 참는 의지가 아니라 아이디어가 작업 목록에 들어오기 전에 거치는 문을 만드는 일이다.
먼저 출시 가능한 게임을 한 문장으로 고정한다
프로젝트 시작 시 다음 세 가지를 문서 첫머리에 적는다.
- 플레이어가 반복해서 하는 핵심 행동
- 한 판 또는 한 세션이 끝나는 조건
- 출시 버전에 반드시 들어갈 최소 기능
예를 들어 “플레이어가 제한된 탄약으로 방을 돌파하고 보스를 처치하면 한 판이 끝나는 탑다운 액션 게임”처럼 쓴다. 이 문장은 홍보 문구가 아니라 기능을 판정하는 기준이다.
새 기능을 검토할 때는 먼저 묻는다. 이 기능이 없으면 위 문장에 적힌 경험이 성립하지 않는가? 답이 아니오라면 기본적으로 출시 후 후보로 보낸다.
기능 요청을 네 단계로 처리한다
아이디어가 떠오르는 순간 구현하지 말고 아래 흐름으로 처리한다. 이 과정은 개인 아이디어뿐 아니라 플레이테스트 피드백과 커뮤니티 요청에도 동일하게 적용할 수 있다.
flowchart TD
A[새 기능 또는 피드백] --> B{핵심 플레이에 필수인가?}
B -- 예 --> C{현재 마일스톤 안에 검증 가능한가?}
B -- 아니오 --> F[아이디어 백로그로 이동]
C -- 예 --> D[작업 분해와 예상 시간 기록]
C -- 아니오 --> F
D --> E{동일한 가치를 더 작은 변경으로 만들 수 있는가?}
E -- 예 --> G[작은 변경안 채택]
E -- 아니오 --> H[기존 범위를 하나 제거한 뒤 승인]여기서 핵심은 “백로그로 이동”이 거절과 같지 않다는 점이다. 좋은 아이디어라도 지금 만들 이유가 없을 수 있다. 보류 목록에 남기면 아이디어를 잃지 않으면서 현재 마일스톤을 지킬 수 있다.
백로그는 할 일 목록이 아니라 판단 기록으로 만든다
백로그 항목마다 제목만 적으면 시간이 지난 뒤 다시 같은 논쟁을 하게 된다. 최소한 다음 정보를 남긴다.
| 항목 | 기록할 내용 |
|---|---|
| 문제 | 어떤 플레이 경험의 불편이나 부족을 해결하는가 |
| 가설 | 추가했을 때 무엇이 좋아질 것인가 |
| 비용 | 구현, 아트, 테스트, 문서화에 드는 대략적인 시간 |
| 증거 | 플레이테스트, 판매 데이터, 유사 게임 분석 등 근거 |
| 결정 | 이번 버전, 다음 버전, 보류, 폐기 중 하나 |
간단한 텍스트 파일이나 이슈 트래커로도 충분하다.
## 벽 점프 추가
- 문제: 초반 이동 구간이 단조롭다는 의견이 있다.
- 가설: 수직 이동 선택지가 생기면 탐색이 더 재미있어진다.
- 비용: 이동 판정 6시간, 레벨 수정 8시간, 애니메이션 4시간, 테스트 4시간.
- 증거: 테스트 5명 중 1명만 이동의 단조로움을 언급했다.
- 결정: 보류. 다음 플레이테스트에서 점프 패드 배치안을 먼저 검증한다.추가에는 반드시 교환 비용을 붙인다
새 기능을 넣을 때 “시간이 나면”이라는 표현은 위험하다. 기능 하나는 구현 시간 외에도 디버깅, 밸런싱, 튜토리얼, 접근성, 저장 데이터 호환성, QA 비용을 만든다.
기능의 순수 가치보다 완료 비용을 함께 보려면 간단한 우선순위 점수를 사용할 수 있다.
수치의 정확성보다 비교 기준을 일정하게 유지하는 편이 중요하다. 예를 들어 플레이어 영향도와 근거를 각각 1~5점으로 두고 예상 시간을 시간 단위로 기록할 수 있다. 점수가 낮은 기능은 삭제 후보가 아니라 보류 후보로 다룬다.
그리고 새 기능이 현재 출시 범위를 늘린다면 같은 규모의 기능 하나를 제거하는 규칙을 둔다. 이를 “하나 추가하면 하나 뺀다”고 명문화하면 기능을 제안할 때 전체 비용을 자연스럽게 고려하게 된다.
마일스톤마다 범위를 잠근다
마일스톤은 기간보다 검증할 질문으로 정의하는 편이 좋다. 예를 들어 “2주 안에 전투가 재미있는지 확인한다”처럼 정한다. 이 단계에서 필요한 것은 적의 종류를 늘리는 일이 아니라 핵심 전투를 시험할 수 있는 최소 콘텐츠다.
마일스톤 시작 시에는 포함 기능과 제외 기능을 함께 적는다. 특히 제외 목록은 새 아이디어가 들어올 때 빠르게 판단하는 데 도움이 된다.
# 전투 프로토타입 마일스톤
포함
- 플레이어 이동과 기본 공격
- 원거리 적 1종
- 방 3개
- 체력과 재시작
제외
- 장비 제작
- 스킬 트리
- 업적
- 온라인 기능
- 스토리 컷신
검증 질문
- 10분 플레이 후에도 적을 피하고 공격하는 선택이 재미있는가?마일스톤 중간에는 버그 수정과 이미 승인한 작업만 한다. 새 기능은 백로그에 적고 마일스톤 종료 시에만 다시 평가한다. 긴급한 기술 문제처럼 예외가 필요한 경우에도 무엇을 대체하거나 일정을 얼마나 조정하는지 기록한다.
플레이테스트 피드백을 기능 요청으로 바로 번역하지 않는다
플레이어가 “미니맵이 필요하다”고 말해도 실제 문제는 길을 잃는다는 것일 수 있다. 해결책을 그대로 받으면 시스템만 커진다. 먼저 관찰 가능한 문제로 다시 쓴다.
- 요청: “더 다양한 무기가 필요하다”
- 관찰할 문제: 현재 무기 사이에 선택 차이가 충분히 느껴지지 않는가
- 작은 실험: 무기 수를 늘리는 대신 기존 두 무기의 사거리와 반동을 크게 다르게 조정한다
이 방식은 피드백을 무시하는 것이 아니다. 문제를 확인한 뒤 가장 작은 해결책을 찾는 방법이다. 플레이테스트 기록에는 발언뿐 아니라 막힌 구간, 재시도 횟수, 설명 없이 이해한 규칙도 함께 남긴다.
매주 30분만 범위 점검 시간을 확보한다
짧은 정기 점검으로도 스콥 크립은 상당 부분 막을 수 있다. 다음 질문에 답해 보자.
- 이번 주에 추가한 작업은 출시 문장과 직접 연결되는가?
- 진행 중인 기능 중 지금 중단해도 되는 것은 무엇인가?
- 백로그에서 근거가 새로 생긴 항목은 있는가?
- 다음 주에 플레이어가 확인할 수 있는 결과물은 무엇인가?
완벽한 계획보다 변경 이력을 남기는 습관이 중요하다. 범위를 줄이는 결정은 실패가 아니라 게임의 핵심을 끝까지 전달하기 위한 제작 결정이다.
출시 후에 확장할 여지를 남긴다
출시 버전은 모든 아이디어를 담는 상자가 아니라 게임의 약속을 검증하는 첫 번째 완성본이다. 출시 후에는 실제 플레이 시간, 이탈 구간, 리뷰와 문의를 바탕으로 백로그를 다시 정렬할 수 있다.
처음부터 확장 기능을 억지로 넣기보다 핵심 루프를 선명하게 완성하면 업데이트와 다음 프로젝트에서 더 근거 있는 선택을 할 수 있다. 1인 개발의 범위 관리는 창의성을 줄이는 일이 아니라 가장 중요한 아이디어가 완성될 때까지 보호하는 일이다.
