스코프 크립 관리: 버릴 기능(Kill List)을 일찍 결정하는 노하우
인디 게임 개발에서 일정과 완성도를 지키려면 무엇을 만들지뿐 아니라 무엇을 버릴지도 초기에 정해야 한다. Kill List를 실제 일정 관리 도구로 바꾸는 기준과 운영 방식을 정리한다.
Kill List가 필요한 이유
스코프 크립은 기능이 한꺼번에 폭증해서만 생기지 않는다. 전투 손맛을 조금 더 다듬고 싶다는 요청, 메뉴 전환을 더 멋지게 만들자는 의견, 플레이어가 좋아할지 모를 수집 요소 하나가 누적되면서 발생한다. 각각은 합리적으로 보이지만 전체 일정에서는 출시를 늦추는 비용이 된다.
특히 소규모 팀은 기능 하나가 여러 영역을 건드린다. 새 적 하나를 추가하면 아트, 애니메이션, AI, 밸런싱, 사운드, 튜토리얼, 테스트까지 함께 늘어날 수 있다. 따라서 기능의 개수보다 기능이 만드는 연결 비용을 봐야 한다.
Kill List는 실패한 아이디어의 묘지가 아니다. 현재 버전에서는 만들지 않기로 합의한 항목을 기록하는 목록이다. 아이디어를 완전히 잊지 않고도 개발 범위에서는 분리할 수 있게 해 준다.
시작 전에 정할 세 가지
1. 출시 가능한 최소 경험을 문장으로 쓴다
먼저 게임의 핵심 경험을 한두 문장으로 고정한다. 예를 들어 로그라이크 액션 게임이라면 다음처럼 쓸 수 있다.
플레이어가 제한된 이동 기술을 조합해 짧은 전투 구역을 돌파하고 매 판 다른 빌드 선택으로 생존 전략을 바꾼다.
이 문장에 직접 기여하지 않는 기능은 우선 보류 후보가 된다. 핵심 경험은 장르 이름이나 기능 목록보다 구체적이어야 한다. 로그라이크 요소 추가처럼 쓰면 판단 기준이 되기 어렵다.
2. 출시 기준을 측정 가능한 형태로 바꾼다
“재미있으면 출시”는 좋은 목표지만 일정 기준은 아니다. 팀이 확인할 수 있는 조건으로 바꾼다.
- 첫 플레이에서 핵심 조작을 익힐 수 있다.
- 한 판의 시작부터 종료까지 진행이 막히지 않는다.
- 목표 플랫폼에서 성능과 저장·불러오기 문제가 허용 범위에 있다.
- 필요한 콘텐츠 수와 로컬라이징 범위가 확정되어 있다.
이 기준을 만족하는 데 꼭 필요하지 않은 항목은 Kill List에 넣을 수 있다.
3. 기능의 전체 비용을 적는다
기능 카드에는 구현 시간만 적지 않는다. 의존성, 테스트, 유지보수, 콘텐츠 생산 비용을 함께 적는다. 예를 들어 “무기 개조 시스템”은 UI 한 화면을 만드는 일로 끝나지 않을 수 있다. 아이템 데이터 구조, 저장 데이터 이전, 밸런스 조정, 튜토리얼 문구, 예외 처리까지 필요할 수 있다.
간단한 우선순위 점수는 논의를 시작하는 데 도움이 된다.
점수 자체가 결정권을 대신하지는 않는다. 다만 기대 효과만 크게 말하고 숨은 비용을 빼먹는 일을 줄여 준다.
Kill List를 만드는 절차
flowchart TD
A[새 기능 제안] --> B{핵심 경험에 직접 기여하는가?}
B -- 아니오 --> K[Kill List에 기록]
B -- 예 --> C{출시 기준을 충족하는 데 필요한가?}
C -- 아니오 --> D[후속 업데이트 후보로 분리]
C -- 예 --> E{의존성과 검증 비용을 감당할 수 있는가?}
E -- 아니오 --> K
E -- 예 --> F[현재 스프린트 후보로 우선순위 평가]이 과정에서 중요한 점은 “나중에 생각하자”를 상태값으로 두지 않는 것이다. 기능은 현재 개발, 출시 후 후보, Kill List 중 하나에 속해야 한다. 애매한 상태가 길어질수록 이미 설계와 코드에 영향을 주기 시작한다.
Kill List 항목은 이유까지 남긴다
목록에 기능 이름만 적으면 다음 회의에서 같은 토론을 반복하게 된다. 다음 필드를 최소 단위로 사용하면 충분하다.
| 항목 | 기록 예시 |
|---|---|
| 기능 | 실시간 4인 협동 모드 |
| 결정 | 출시 버전 제외 |
| 이유 | 네트워크 동기화와 매치메이킹이 핵심 싱글플레이 루프의 완성도를 압박함 |
| 재검토 조건 | 출시 후 플레이 데이터와 운영 여력이 확보될 때 |
| 결정일 | 2026-07-30 |
이 형식은 아이디어를 폐기했다는 감정을 줄인다. “영원히 하지 않는다”가 아니라 “지금의 출시 목표에는 맞지 않는다”는 명확한 결정이기 때문이다. 단, 재검토 조건이 없는 항목까지 모두 미래 가능성으로 남기면 목록이 백로그로 되돌아간다. 근거 없이 보관만 하는 기능은 과감히 종료해도 된다.
자주 실패하는 패턴
프로토타입이 있으니 포함한다
이미 만들어 본 기능은 아깝다. 그러나 프로토타입이 있다는 사실은 출시 기능으로서 완성됐다는 뜻이 아니다. 예외 상황, 접근성, 성능, 튜토리얼, 플랫폼별 입력, QA 비용을 따로 확인해야 한다.
프로토타입은 다음 질문을 통과했을 때만 승격한다.
- 핵심 경험을 더 선명하게 만드는가?
- 다른 기능을 삭제하거나 단순화할 수 있는가?
- 출시 전 검증 범위를 팀이 감당할 수 있는가?
세 질문 중 하나라도 답이 불분명하면 Kill List 또는 출시 후 후보로 옮기는 편이 안전하다.
영향력이 큰 사람의 요청을 예외로 둔다
누가 제안했는지와 기능의 필요도는 분리해야 한다. 리드, 퍼블리셔, 커뮤니티의 요청도 같은 기준표에 올린다. 예외가 필요하다면 예외라는 사실과 그로 인해 밀려나는 작업을 기록한다. 추가 기능은 공짜가 아니므로 무엇을 포기하는지 함께 보여야 한다.
Kill List를 한 번 만들고 닫아 둔다
목록은 프로젝트 초기에만 쓰는 문서가 아니다. 마일스톤마다 다시 본다. 다만 매주 모든 항목을 재논의하면 결정이 무력해진다. 재검토는 다음 같은 사건이 있을 때만 한다.
- 플레이테스트가 핵심 가설을 반박했을 때
- 목표 플랫폼이나 출시 조건이 바뀌었을 때
- 다른 기능을 삭제해 개발 여력이 생겼을 때
- 플레이 데이터가 명확한 기회를 보여 줄 때
작은 팀에서 바로 쓸 운영 규칙
매주 짧은 범위 검토 시간을 잡고 새 기능 제안은 반드시 기존 항목 하나와 비교한다. 좋은 질문은 “이 기능이 필요할까?”보다 “이 기능을 넣으면 무엇을 빼야 할까?”다.
또한 기능의 상태를 코드 저장소의 이슈, 기획 문서, 작업 보드 가운데 한 곳에서만 최종 관리한다. 여러 문서에 서로 다른 우선순위가 남으면 Kill List는 신뢰를 잃는다.
출시가 가까워질수록 기준은 더 엄격해져야 한다. 마지막 단계의 새 기능은 단순히 만드는 시간을 요구하지 않는다. 기존 시스템과 충돌하지 않는지 확인하는 시간을 추가로 요구한다. 이때 Kill List는 팀이 “아니오”라고 말할 수 있게 하는 합의 문서가 된다.
마무리
좋은 Kill List는 야심을 줄이는 문서가 아니라 완성할 야심을 고르는 도구다. 플레이어가 실제로 만나는 핵심 루프를 먼저 완성하고 그 경험을 흐리거나 검증 비용을 급격히 높이는 기능은 이유와 함께 일찍 분리하자. 출시 후에 다시 꺼낼 수 있는 아이디어를 기록해 두면 지금 버리는 결정도 더 빠르고 차분하게 내릴 수 있다.
