게임 개발 Scope Creep 대응: Kill List 기능 우선순위 결정 가이드
게임 개발 중 Scope Creep이 발생했을 때 무엇을 버릴지 판단하는 Kill List 작성법을 소개합니다. 출시 영향도·비용·리스크 점수로 기능을 비교하고 팀 합의를 문서화하는 실전 우선순위 가이드입니다.
게임 개발에서 Scope Creep이 발생하면 ‘중요해 보이지 않는 기능’을 감으로 제거하면 안 됩니다. 출시 목표 기여도, 구현·검증 비용, 일정 리스크, 대체 가능성을 같은 기준으로 점수화해 Kill List 후보를 정하고 그 결정과 후속 조치를 문서로 남겨야 합니다.
Kill List는 실패한 기능 목록이 아니라 정해진 출시일과 품질 목표를 지키기 위해 이번 버전에서 의도적으로 제외하는 기능 목록입니다.
Scope Creep은 왜 발생하는가?
Scope Creep은 승인된 범위를 넘어 기능, 콘텐츠, 품질 기준이 조금씩 늘어나는 현상입니다. 게임에서는 다음 상황에서 특히 자주 발생합니다.
- 플레이 테스트 후 개선 의견이 기능 요구사항으로 확장된다.
- 경쟁작의 신기능을 보고 대응 항목을 추가한다.
- 아트, 사운드, UI 폴리시 수준의 요청이 시스템 변경으로 커진다.
- ‘금방 할 수 있다’는 추정이 예외 처리와 QA 비용을 빠뜨린다.
- 출시 목표가 문서화되지 않아 팀마다 필수 기능의 기준이 다르다.
문제는 기능 하나의 개발 시간만이 아닙니다. 기능 추가는 보통 UI, 저장 데이터, 튜토리얼, 현지화, 밸런싱, 접근성, 플랫폼 인증, 회귀 테스트 범위까지 함께 늘립니다.
따라서 Kill List는 ‘개발 시간이 긴 기능’만 고르는 목록이 아니라 출시 대비 순효과가 낮은 변경을 제거하는 도구여야 합니다.
Kill List를 만들기 전에 고정할 기준
먼저 이번 빌드의 출시 목표를 한 문장으로 고정합니다. 예를 들어 다음과 같습니다.
2026년 10월 데모에서 신규 플레이어가 20분 안에 핵심 루프인 탐험·전투·보상 선택을 이해하고 크래시 없이 완주할 수 있게 한다.
이 문장은 후보 기능을 평가하는 기준점입니다. ‘재료 제작 2단계 확장’이 재미있어 보여도 이 목표에 직접 기여하지 않는다면 출시 버전의 필수 기능으로 취급할 이유가 약해집니다.
출시 목표와 기능을 연결하는 질문
각 기능에 아래 질문을 답합니다.
- 이 기능이 없으면 플레이어가 핵심 루프를 이해하거나 완주하지 못하는가?
- 이 기능이 없으면 플랫폼 제출, 수익화, 계약상 약속이 막히는가?
- 기존 기능이나 콘텐츠로 같은 문제를 충분히 해결할 수 있는가?
- 지금 추가하면 다른 필수 기능의 검증 시간을 침식하는가?
1번 또는 2번이 ‘예’인 항목은 보통 유지 후보입니다. 3번과 4번이 ‘예’인 항목은 Kill List 상위 후보가 됩니다.
Kill List 우선순위는 어떻게 점수화할까?
기능마다 1점에서 5점까지 점수를 매기고 해석이 다른 항목은 짧은 근거를 함께 적습니다. 점수 자체보다 같은 기준으로 비교 가능한 상태를 만드는 것이 목적입니다.
| 평가 항목 | 1점 | 5점 | 판단 기준 |
|---|---|---|---|
| 출시 목표 기여도 | 목표와 거의 무관 | 목표 달성에 필수 | 핵심 루프, 계약, 플랫폼 요건에 미치는 영향 |
| 미구현 시 피해 | 거의 없음 | 출시 불가 또는 큰 신뢰 하락 | 제거했을 때 생기는 문제 |
| 구현·통합 비용 | 반나절 이내 | 여러 시스템과 콘텐츠 수정 필요 | 개발, UI, 데이터, 통합 작업 포함 |
| QA·회귀 비용 | 독립 테스트 가능 | 넓은 회귀 테스트 필요 | 저장, 네트워크, 튜토리얼, 플랫폼 영향 포함 |
| 일정 불확실성 | 이미 검증됨 | 기술·외주·의존성이 불명확 | 추정 오차와 외부 의존성 |
| 대체 가능성 | 대체 수단 없음 | 기존 기능으로 충분히 대체 가능 | 간단한 규칙, UI, 콘텐츠로 우회 가능한지 |
Kill List 우선순위 점수는 다음처럼 단순하게 계산할 수 있습니다.
점수가 높을수록 이번 범위에서 제외할 후보입니다. 단, 플랫폼 인증 항목, 법적·계약상 의무, 치명적 버그 대응은 이 수식과 무관하게 제거 대상에서 제외합니다.
예시: 로그라이크 데모의 기능 비교
| 기능 | 목표 기여 | 미구현 피해 | 비용 | QA 비용 | 불확실성 | 대체 가능성 | 제거 우선순위 | 결정 |
|---|---|---|---|---|---|---|---|---|
| 장비 외형 염색 | 1 | 1 | 3 | 3 | 2 | 5 | 11 | 제거 |
| 재료 제작 3단계 | 2 | 2 | 4 | 4 | 3 | 4 | 11 | 제거 |
| 일일 도전 과제 | 2 | 1 | 3 | 3 | 3 | 4 | 10 | 보류 |
| 게임패드 재매핑 | 4 | 4 | 3 | 3 | 2 | 1 | 1 | 유지 |
| 보스전 1종 | 5 | 4 | 4 | 4 | 3 | 1 | 3 | 유지 |
이 표에서 장비 외형 염색은 플레이어 만족에 기여할 수 있지만 데모의 핵심 루프 검증에는 직접적이지 않습니다. 반면 게임패드 재매핑은 대상 플랫폼과 접근성 요구에 따라 미구현 피해가 커질 수 있으므로 단순 편의 기능으로 분류하면 안 됩니다.
기능을 버릴 때 따라야 할 3단계
1. 후보를 기능 단위가 아니라 출시 가능한 묶음으로 분해한다
‘제작 시스템’처럼 큰 이름으로 판단하지 않습니다. 다음처럼 플레이어 경험과 의존성을 기준으로 나눕니다.
- 재료 획득
- 제작 레시피 선택 UI
- 제작 결과 생성
- 장비 강화 수치 계산
- 희귀 재료 드롭 테이블
- 제작 튜토리얼
이렇게 분해하면 ‘제작 시스템 전체를 버릴지’가 아니라 데모에서는 강화 없는 단순 장비 드롭으로 대체할지를 결정할 수 있습니다. 기능을 작게 나누면 제거 대신 축소라는 선택지도 생깁니다.
2. 유지·축소·연기·제거를 구분한다
Kill List의 모든 항목이 영구 삭제를 뜻하지는 않습니다.
| 결정 | 의미 | 예시 |
|---|---|---|
| 유지 | 출시 버전에 필수 | 저장·불러오기, 핵심 전투 피드백 |
| 축소 | 최소 경험만 남김 | 12개 캐릭터 스킨을 기본색 3종으로 축소 |
| 연기 | 이후 마일스톤으로 이동 | 랭크 모드, 시즌 패스 |
| 제거 | 현재 목표와 맞지 않아 종료 | 소셜 허브, 인게임 사진 모드 |
‘연기’에는 다시 검토할 조건과 시점을 붙여야 합니다. 예를 들어 ‘데모 완주율 70% 이상, 저장 데이터 포맷 고정 후 재평가’처럼 기록합니다. 그렇지 않으면 연기한 기능이 다음 스프린트에 근거 없이 되살아납니다.
3. 결정 로그와 변경 영향을 함께 기록한다
Kill List는 백로그에 Won't do 라벨만 붙이는 것으로 끝나지 않습니다. 아래 정보를 남기면 재논의를 줄이고 협업 비용을 낮출 수 있습니다.
## KL-014: 장비 외형 염색
- 결정: 제거
- 결정일: 2026-08-09
- 근거: 데모 핵심 루프 기여도 1/5, UI·저장 데이터·QA 범위가 큼
- 대체안: 장비 등급별 고정 외형 3종
- 영향: 상점 UI의 염색 탭 제거, 튜토리얼 문구 수정
- 재검토 조건: 정식 출시용 꾸미기 상품 전략 확정 후
- 담당: 기획 / UI / 클라이언트이 기록은 누군가 나중에 ‘왜 빠졌는지’를 묻는 상황에서 특히 유용합니다. 중요한 것은 누가 제안했는지가 아니라 어떤 출시 목표와 근거로 결정했는지입니다.
비용이 작아도 Kill List에 넣어야 하는 기능은 무엇인가?
작은 기능도 다음 조건에 해당하면 상위 제거 후보가 될 수 있습니다.
- 핵심 시스템의 데이터 구조를 바꾼다.
- 저장 호환성이나 네트워크 프로토콜에 영향을 준다.
- 현지화 문자열, 플랫폼별 UI, 튜토리얼을 연쇄 수정한다.
- 테스트 시나리오를 크게 늘린다.
- 담당자가 한 명뿐이거나 외주 납품을 기다려야 한다.
예를 들어 ‘친구 초대 버튼 추가’는 UI 작업만으로 보일 수 있습니다. 그러나 실제 친구 초대 플로우가 플랫폼 SDK, 딥링크, 세션 입장, 실패 처리, 개인정보 고지까지 포함한다면 기능 크기보다 일정 불확실성이 훨씬 큽니다.
flowchart TD
A[새 기능 요청] --> B{출시 목표에 직접 기여하는가?}
B -->|예| C{계약·플랫폼·핵심 루프 요건인가?}
C -->|예| D[유지 및 일정 보호]
C -->|아니오| E[비용·QA·불확실성 점수화]
B -->|아니오| E
E --> F{기존 기능으로 대체 가능한가?}
F -->|예| G[축소 또는 제거]
F -->|아니오| H[연기 조건 또는 유지 근거 기록]Kill List 합의 회의에서 지켜야 할 운영 원칙
Kill List 회의는 아이디어를 평가하는 자리가 아니라 출시 약속을 보호하는 의사결정 자리입니다. 회의 전에 기능 목록과 점수 초안을 공유하고 회의에서는 점수의 근거와 의존성만 검토하는 편이 효율적입니다.
- 제품 책임자는 출시 목표와 성공 지표를 확인한다.
- 개발 리드는 구현·통합·기술 리스크를 확인한다.
- QA는 회귀 범위와 테스트 가능성을 확인한다.
- 아트와 사운드는 콘텐츠 제작 및 수정 비용을 확인한다.
- 결정권자는 충돌하는 우선순위를 최종 확정한다.
합의가 어려우면 ‘살릴 이유’를 설명하게 하기보다 제거했을 때 어떤 출시 목표가 깨지는지를 구체적으로 적게 하세요. 답이 모호하다면 해당 기능은 보통 축소 또는 연기 후보입니다.
자주 묻는 질문 (FAQ)
Kill List는 언제 만들어야 하나요?
프로덕션 막바지에만 만들지 말고 마일스톤 시작 시점과 일정·인력·품질 기준이 바뀔 때 갱신하세요. 특히 알파, 콘텐츠 락, 플랫폼 제출 전에는 반드시 다시 검토하는 것이 좋습니다.
기능을 제거하면 팀 사기가 떨어지지 않나요?
근거 없이 취소하면 떨어질 수 있습니다. 반대로 출시 목표, 점수, 재검토 조건을 공개하면 팀은 개인의 아이디어가 아니라 프로젝트의 제약을 기준으로 결정이 이뤄진다는 점을 이해하기 쉽습니다.
점수표만으로 최종 결정을 내려도 되나요?
아닙니다. 점수표는 비교를 돕는 도구입니다. 플랫폼 요구사항, 계약 의무, 브랜드 리스크, 이미 완료된 작업량처럼 수식에 담기 어려운 조건을 별도로 검토해야 합니다.
정리
Scope Creep 상황에서 좋은 Kill List는 기능의 가치를 부정하는 목록이 아닙니다. 출시 목표에 맞지 않는 일을 지금 하지 않기로 합의하는 장치입니다.
기능을 세분화하고 출시 기여도와 총비용을 함께 점수화하고 유지·축소·연기·제거를 구분해 결정 로그를 남기세요. 이렇게 하면 일정이 압박받는 순간에도 감정이나 목소리 크기 대신, 팀이 공유한 기준으로 우선순위를 정할 수 있습니다.
