개발 일정 지연 시 기능 Cut 판단 기준과 마일스톤 재설정 방법

게임 개발 일정이 지연되면 먼저 종료일을 고정한 채 기능을 줄이는 것이 아니라 출시 가능한 핵심 경험(Minimum Lovable Product) 을 다시 정의해야 한다. 기능 Cut은 플레이어 가치, 출시 필수성, 기술·콘텐츠 의존성, 검증 비용을 같은 기준으로 비교해 결정하고 남은 범위에 맞춰 마일스톤의 완료 조건과 위험 완화 작업을 함께 다시 설정한다.

개발 일정 지연은 왜 발생하는가?

일정 지연은 단순히 작업 속도가 느려서만 생기지 않는다. 게임 프로젝트에서는 기능 구현 이후에도 밸런싱, UI 연결, 저장 데이터 호환, 플랫폼 인증, 현지화, QA 회귀 테스트가 뒤따른다. 초기 견적에 이 통합 비용이 빠져 있으면 기능 하나가 끝난 것처럼 보여도 마일스톤은 완료되지 않는다.

특히 다음 신호가 겹치면 범위 조정이 필요하다.

• 핵심 기능의 완료율은 높지만 통합 빌드에서 막히는 이슈가 계속 늘어난다.
• 다음 마일스톤의 선행 조건이 아직 검증되지 않았다.
• 남은 작업의 상당수가 “구현”이 아닌 튜닝, 예외 처리, 콘텐츠 제작, 회귀 테스트다.
• 같은 인력이 여러 기능의 병목이 되어 병렬 진행이 불가능하다.

일정 예측에는 완료한 티켓 수보다 남은 작업량과 불확실성을 반영해야 한다. 예를 들어 기능별 예상 작업량을 $E_i$, 위험 계수를 $R_i$, 실제로 투입 가능한 인력을 $C$라고 할 때 남은 기간의 단순 추정은 다음처럼 둘 수 있다.

$$T_{remaining}=\frac{\sum_{i=1}^{n}(E_i\times R_i)}{C}$$

여기서 $R_i$는 이미 검증된 반복 작업이면 1에 가깝고 새 엔진 기능·온라인 연동·플랫폼 인증처럼 불확실성이 큰 작업이면 1보다 커진다. 이 수식은 정답을 내는 도구가 아니라 낙관적인 견적이 어디에 숨어 있는지 드러내는 장치다.

기능 Cut은 어떤 기준으로 판단해야 할까?

기능을 빼는 기준은 “만들기 어려운 기능”이 아니라 “출시 핵심 경험을 해치지 않고 제거할 수 있는 기능”이어야 한다. 각 기능을 아래 표로 평가하면 회의에서 취향 싸움을 줄일 수 있다.

평가 항목	확인 질문	높은 점수의 의미
플레이어 가치	이 기능이 없으면 첫 30분의 재미가 약해지는가?	없으면 게임의 매력이 크게 훼손됨
출시 필수성	스토어 설명, 장르 기대, 핵심 루프에 반드시 필요한가?	출시 범위에 반드시 포함해야 함
의존성	다른 기능, 콘텐츠, UI가 이 기능을 전제로 하는가?	지금 제거하면 연쇄 수정 비용이 큼
검증 비용	구현 뒤 밸런싱·QA·플랫폼 검증이 얼마나 필요한가?	완료 선언까지 시간이 오래 걸림
대체 가능성	더 단순한 규칙이나 콘텐츠로 같은 가치를 낼 수 있는가?	Cut 또는 축소 후보가 됨

Cut 우선순위를 점수로 정하는 방법

기능별로 1점에서 5점까지 점수를 매긴 뒤 다음과 같이 Cut 우선순위를 계산할 수 있다.

$$CutScore=(검증비용+대체가능성+불확실성)-(플레이어가치+출시필수성+의존성)$$

CutScore가 높을수록 먼저 제거하거나 축소를 검토한다. 점수 자체보다 모든 직군이 같은 질문에 답했다는 점이 중요하다. 기획은 플레이어 가치와 장르 약속을 프로그래밍은 불확실성과 의존성을 아트·QA는 제작 및 검증 비용을 함께 판단해야 한다.

기능 예시	권장 판단	이유
전투의 기본 회피와 피격 반응	유지	핵심 루프와 조작 감각에 직접 연결됨
무기별 고유 애니메이션 12종	축소	공통 애니메이션과 수치 차이로 초기 가치를 유지할 수 있음
출시 후에도 가능한 사진 모드	Cut	핵심 플레이와 분리되어 있고 대체로 출시 필수성이 낮음
온라인 랭킹	보류 또는 Cut	서버, 계정, 운영, 예외 처리의 통합 비용이 큼
튜토리얼의 첫 전투 안내	유지하되 단순화	이탈 방지에 중요하지만 연출은 축소 가능함

일정이 늦었을 때 기능을 Cut하는 3단계

1. 출시 핵심 경험을 한 문장으로 다시 합의한다

먼저 “이 게임을 왜 플레이하는가”를 한 문장으로 적는다. 예를 들어 액션 로그라이크라면 “짧은 전투에서 빌드 선택의 차이를 느끼고 실패 후 다시 도전하고 싶게 만드는 경험”처럼 쓴다.

이 문장에 연결되지 않는 기능은 기본적으로 Cut 또는 출시 후 업데이트 후보가 된다. 단, 접근성, 저장 안정성, 크래시 방지, 필수 플랫폼 요건처럼 플레이어에게 보이지 않아도 출시 품질을 지키는 작업은 별도로 보호해야 한다.

2. 기능을 유지·축소·연기·제거로 나눈다

단순한 포함/제외 이분법 대신 네 가지 상태를 사용한다.

상태	의미	예시
유지	출시 핵심 경험과 필수 품질에 직접 필요	기본 전투, 저장·불러오기
축소	동일한 가치를 더 작은 범위로 제공	8개 보스를 4개 보스로 축소
연기	출시 후 업데이트로 옮겨도 구조상 안전	사진 모드, 추가 난이도
제거	출시 이후에도 가치 대비 비용이 낮음	사용 빈도가 낮은 보조 시스템

축소는 기능을 반쯤 구현한 채 남겨 두는 일이 아니다. 완료 조건도 함께 줄여야 한다. 예를 들어 “절차적 던전 생성”을 축소한다면 단순히 방 개수를 줄이는 대신 “고정된 3개 레이아웃에서 전투와 보상 흐름이 정상 동작한다”처럼 새 완료 조건을 정의한다.

3. Cut 결정의 파급 효과를 확인하고 문서화한다

기능을 빼면 코드만 사라지는 것이 아니다. 퀘스트, UI 문구, 아이템 데이터, 튜토리얼, 트레일러, 스토어 설명, 테스트 케이스도 함께 바뀔 수 있다. Cut 항목마다 영향 범위를 확인한다.

• 선행 또는 후행 기능이 있는가?
• 저장 데이터와 세이브 버전 정책에 영향이 있는가?
• 이미 제작 중인 아트·사운드·현지화 자산이 있는가?
• 문서, QA 테스트 케이스, 마케팅 문구를 누가 언제 수정하는가?
• 출시 후 다시 도입할 때 데이터 구조나 API 호환성이 필요한가?

결정 로그에는 다음 필드를 최소한으로 남긴다.

## 범위 변경 결정
- 기능: 온라인 랭킹
- 결정: 출시 범위에서 제외
- 결정일: 2026-08-09
- 근거: 서버 운영 및 계정 연동 검증 비용이 현재 일정에 비해 큼
- 대체안: 로컬 최고 기록과 주간 챌린지 UI만 출시
- 영향 범위: 메인 메뉴, 결과 화면, 스토어 설명, QA 회귀 항목
- 담당자와 기한: UI 문구 수정 - 기획, 다음 콘텐츠 동결 전
- 재검토 조건: 출시 후 30일 유지율 및 운영 인력 확보 여부 확인

마일스톤은 어떻게 다시 설정해야 할까?

마일스톤 재설정은 날짜만 뒤로 미루는 일이 아니다. 남은 출시 범위에 맞춰 완료 정의(Definition of Done), 통합 시점, 위험 검증 시점을 다시 설계하는 일이다.

기존 계획을 버리고 현재 기준선으로 다시 추정한다

이미 끝난 작업을 제외하고 현재 빌드에서 실제로 남은 일만 새로 목록화한다. 이때 “기능 구현 완료”와 “출시 가능”을 구분한다.

구분	구현 완료	출시 가능
전투 기능	공격과 피격이 동작함	입력, 사운드, 애니메이션, 밸런스, 난이도, 회귀 테스트까지 통과
저장 기능	파일을 저장하고 읽음	실패 복구, 버전 호환, 플랫폼별 경로, 장시간 플레이 테스트 완료
UI 화면	화면이 표시됨	해상도·언어·패드 입력·접근성·연결 상태를 검증

새 마일스톤에는 기능 목록이 아니라 검증 가능한 결과를 적는다. “인벤토리 구현”보다 “획득·장착·저장·불러오기·패드 조작이 통합 빌드에서 통과”가 더 정확한 완료 조건이다.

재설정된 마일스톤의 권장 구조

마일스톤	목적	종료 조건
범위 동결	출시 범위와 Cut 목록 확정	변경 로그 승인, 백로그 우선순위 갱신
핵심 루프 통합	플레이 가능한 최소 경험 확인	처음부터 실패·재시작까지 한 흐름이 빌드에서 동작
콘텐츠 동결	추가 제작을 멈추고 품질 확보 시작	필수 스테이지, 적, 텍스트가 모두 연결됨
품질 동결	회귀 버그와 성능 문제 집중	신규 기능 금지, 우선순위 높은 결함 해결
릴리스 후보	배포 가능한 후보 빌드 검증	플랫폼 요구사항과 릴리스 체크리스트 충족

콘텐츠 동결과 품질 동결 사이에는 버퍼를 둔다. 버퍼는 남는 시간이 아니라 통합 실패, 재작업, 인증 반려처럼 예측이 어려운 일을 처리하는 기간이다. 버퍼를 확보하지 못했다면 기능을 한 번 더 축소하는 편이 대체로 안전하다.

마일스톤 변경을 팀에 어떻게 공유할까?

일정 변경 공지는 “일정이 늦어졌습니다”로 끝나면 안 된다. 팀이 다음 행동을 결정할 수 있도록 변경 전후와 이유를 명확히 전달해야 한다.

1. 현재 상태를 사실로 정리한다. 완료한 범위, 남은 범위, 발견된 위험, 출시일 제약을 분리해 적는다.
2. 선택지를 제시한다. 출시일 유지와 범위 축소, 출시일 조정과 범위 유지처럼 현실적인 대안을 비교한다.
3. 결정과 후속 행동을 확정한다. Cut 목록, 새 마일스톤, 담당자, 다음 검토일을 같은 문서와 보드에 반영한다.

회의 후에는 백로그 상태와 문서를 반드시 일치시킨다. 문서에는 제외됐는데 작업 보드에는 진행 중인 티켓이 남아 있으면 팀은 이미 합의한 범위를 다시 만들게 된다.

자주 묻는 질문 (FAQ)

기능 Cut은 개발 리더만 결정해야 하나요?

최종 우선순위의 책임자는 필요하지만 판단 근거는 기획·프로그래밍·아트·QA가 함께 제공해야 한다. 한 직군만 결정하면 플레이어 가치나 통합 비용 중 하나를 놓치기 쉽다.

이미 구현한 기능도 Cut해야 하나요?

그럴 수 있다. 구현 완료 여부보다 출시 품질까지 가는 검증 비용과 핵심 경험 기여도를 비교해야 한다. 다만 이미 다른 시스템이 강하게 의존한다면 제거보다 비활성화 또는 축소가 안전할 수 있다.

마일스톤을 다시 잡은 뒤에도 일정이 흔들리면 어떻게 하나요?

변경의 원인을 기록하고 다음 마일스톤에서 가장 큰 불확실성을 먼저 검증한다. 반복적으로 흔들리는 범위는 작업자에게 압박을 주기보다 완료 조건이 모호하거나 통합 비용이 누락됐는지 점검해야 한다.

정리

일정 지연 상황에서 좋은 기능 Cut은 적게 만드는 결정이 아니라 제한된 시간 안에 게임의 핵심 재미와 출시 품질을 지키는 결정이다. 플레이어 가치와 출시 필수성을 보호하고 대체 가능성과 검증 비용이 높은 항목부터 축소·연기·제거하자. 그다음 새 범위에 맞는 완료 조건과 동결 시점을 마일스톤에 반영하면 팀은 불확실한 계획 대신 실행 가능한 계획을 갖게 된다.