개발 일정 지연 시 기능 컷 판단 기준: 스코프를 지키고 리스크를 관리하는 방법

핵심 요약

개발 일정이 지연됐을 때 기능 컷은 단순히 덜 중요한 기능을 삭제하는 일이 아니다. 출시 가능한 핵심 경험을 보호하기 위해 기능의 플레이어 가치, 의존성, 완성도 위험, 검증 비용을 비교해 스코프를 재설계하는 의사결정이다.

가장 안전한 순서는 출시 기준을 다시 고정하고 → 기능을 점수화해 컷 후보를 정하고 → 대체안·영향 범위·복구 조건을 문서화하는 것이다. 일정이 부족할수록 팀의 직감보다 같은 기준으로 남긴 기록이 중요하다.

개발 일정 지연은 왜 기능 컷으로 이어지는가?

일정 지연은 작업 시간이 부족해서만 발생하지 않는다. 기능 간 의존성, 반복 테스트, 콘텐츠 제작, 플랫폼 인증, 버그 수정처럼 계획 초기에 작게 잡히기 쉬운 비용이 후반에 한꺼번에 드러나기 때문이다.

특히 게임은 기능 하나가 여러 분야의 작업을 연쇄적으로 만든다. 예를 들어 신규 보스는 AI 로직만 추가하는 일이 아니다. 애니메이션, 사운드, 이펙트, 전투 밸런스, UI 안내, 난이도 테스트, 저장 데이터, 업적, 로컬라이징까지 영향을 줄 수 있다.

출시일을 고정해야 하는 프로젝트에서 선택지는 보통 세 가지다.

선택지	장점	주요 위험	적합한 상황
일정 연기	품질과 스코프를 유지할 여지가 생긴다	마케팅, 계약, 플랫폼 일정 비용이 커질 수 있다	출시일 변경 비용이 낮고 핵심 품질 문제가 남았을 때
인력 투입	병렬 가능한 작업을 빠르게 끝낼 수 있다	온보딩과 조율 비용으로 오히려 지연될 수 있다	작업 경계가 분명하고 즉시 투입 가능한 인력이 있을 때
기능 컷	핵심 경험에 집중하고 완료 가능성을 높인다	잘못 자르면 게임의 정체성과 완성도가 무너진다	출시일이 고정됐고 비핵심 범위를 분리할 수 있을 때

기능 컷은 마지막 순간의 공황 대응이 아니라 일정과 품질의 불확실성을 통제하는 정상적인 프로젝트 관리 수단으로 다뤄야 한다.

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

기능을 좋아 보이는 기능과 필요한 기능으로 나누는 것만으로는 부족하다. 아래 네 가지 축을 같은 단위로 평가하면 논의를 훨씬 빠르게 정리할 수 있다.

1. 핵심 게임 루프를 보호하는가?

핵심 게임 루프는 플레이어가 반복하며 재미를 느끼는 행동의 연결이다. 액션 로그라이크라면 보통 전투 → 보상 선택 → 빌드 변화 → 더 어려운 전투가 핵심 루프다.

다음 질문에 하나라도 “아니오”라고 답한다면 컷 후보가 될 가능성이 높다.

• 이 기능이 없어도 첫 10~30분의 핵심 재미가 유지되는가?
• 이 기능이 없어도 플레이어가 목표와 다음 행동을 이해하는가?
• 이 기능이 없어도 게임을 끝까지 진행하고 결말을 볼 수 있는가?
• 이 기능은 기존 기능의 재미를 증폭하는가, 아니면 별도의 재미를 추가하는가?

예를 들어 전투 게임의 피격 판정, 카메라, 적 행동 가독성은 대개 컷 대상이 아니다. 반면 사진 모드, 장식용 코스메틱, 출시 후에도 확장 가능한 도전 과제는 핵심 루프를 훼손하지 않는 범위에서 연기하기 쉽다.

2. 기능의 의존성과 제거 비용은 얼마인가?

기능을 빼는 일에도 비용이 든다. 이미 다른 시스템이 그 기능의 데이터나 상태를 참조한다면 제거 작업은 새 기능을 만드는 것만큼 위험할 수 있다.

의존성을 확인할 때는 다음을 함께 본다.

• 코드 의존성: API, 이벤트, 세이브 데이터, 상태 머신 전이
• 콘텐츠 의존성: 맵, 퀘스트, 대사, 튜토리얼, 아이템 테이블
• 운영 의존성: 업적, 상점 상품, 분석 이벤트, 고객 지원 문서
• 외부 의존성: 플랫폼 인증, 연령 등급, 퍼블리셔 납품 항목

나중에 빼면 된다는 판단은 위험하다. 기능을 제거했을 때 세이브 호환성이나 진행 불가 버그가 발생하면 컷으로 확보한 시간이 회귀 테스트에 다시 소모된다.

3. 완료율이 아니라 남은 불확실성을 봤는가?

“80% 완료”라는 표현은 의사결정 근거로 약하다. UI가 붙은 프로토타입은 80%처럼 보여도 예외 처리, 성능, 밸런스, 저장·불러오기, QA가 남아 있다면 실제 출시 준비도는 낮다.

기능별 잔여 비용은 작업 시간과 위험 비용을 분리해 추정한다.

$$E_{remain}=E_{implementation}+E_{integration}+E_{qa}+E_{content}+E_{certification}$$

여기서 E_qa는 단순 테스트 시간이 아니라 회귀 테스트와 수정 반복까지 포함한다. 플랫폼 제출이 필요한 게임이라면 E_certification도 별도 항목으로 둔다.

4. 기능을 축소한 대체안이 있는가?

컷은 이분법일 필요가 없다. 완전 삭제 대신 축소 출시, 수동 운영, 단일 시나리오 제공처럼 최소 기능 제품(MVP) 형태로 바꿀 수 있다.

원래 계획	축소안	출시 후 복구 가능성
절차 생성 던전 12종	검증된 던전 4종을 고정 배치	높음
온라인 랭킹	로컬 최고 기록만 제공	높음
캐릭터 6명	역할이 겹치는 3명만 출시	중간
복잡한 제작 시스템	상점 업그레이드 5단계로 대체	중간
협동 멀티플레이	싱글플레이 밸런스 완성에 집중	낮음, 별도 프로젝트 수준의 재검토 필요

대체안은 기능의 이름이 아니라 플레이어가 얻는 가치를 기준으로 설계한다. 예를 들어 “랜덤 던전”이 주는 가치가 매회 다른 선택과 긴장감이라면 모든 절차 생성 규칙을 완성하지 못해도 소수의 검증된 변형 맵으로 일부 가치를 제공할 수 있다.

기능 컷 우선순위는 어떻게 점수화할까?

점수는 결정을 자동화하는 장치가 아니라 서로 다른 직군이 같은 언어로 논의하게 만드는 장치다. 각 기능을 1점부터 5점까지 평가하고 높은 점수일수록 먼저 컷하거나 축소 검토하도록 운영할 수 있다.

$$CutScore=2R+2D+U-V$$

• R(Risk): 기술·일정·품질 위험. 높을수록 컷 우선순위가 높다.
• D(Dependency): 다른 작업을 막거나 복잡하게 만드는 정도. 높을수록 컷 우선순위가 높다.
• U(Uncertainty): 남은 작업량의 추정 오차. 높을수록 컷 우선순위가 높다.
• V(Player Value): 핵심 게임 루프와 구매 이유에 주는 가치. 높을수록 유지해야 하므로 점수에서 뺀다.

가중치 2R, 2D는 예시다. 네트워크 게임이라면 기술 위험의 비중을 더 높일 수 있고 서사 중심 게임이라면 플레이어 가치 평가에 내러티브 완결성을 명시적으로 포함할 수 있다.

기능	R	D	U	V	CutScore	권장 결정
사진 모드	1	1	1	1	5	출시 후 업데이트로 연기
신규 보스 2종	4	4	3	3	19	1종만 유지하거나 컷
튜토리얼 가이드	2	3	2	5	4	유지, 범위만 단순화
온라인 랭킹	5	4	4	2	24	컷 또는 별도 출시 계획

점수화 후에는 반드시 정성 검토를 한 번 더 한다. V가 높은 기능을 컷해야 한다면 출시 버전의 핵심 약속이 바뀌는 것이므로 일정 문제를 해결하는 수준을 넘어 제품 전략을 다시 승인받아야 한다.

일정 지연 시 기능 컷을 실행하는 3단계

1. 출시 기준과 남은 시간을 다시 고정한다

먼저 “무엇을 완료로 볼 것인가”를 문장으로 확정한다. 예시는 다음과 같다.

PC 출시 빌드는 처음부터 엔딩까지 진행 가능해야 하며 핵심 전투 루프가 60 FPS 목표 성능에서 안정적으로 동작하고 진행 불가 결함과 저장 데이터 손상 결함은 없어야 한다.

그다음 남은 기간에서 필수 검증 버퍼를 먼저 뺀다. 마지막 주까지 기능 개발을 채우면 테스트 일정은 계획이 아니라 희망이 된다.

• 콘텐츠 잠금(Content Lock): 신규 콘텐츠 추가를 멈추는 날짜
• 기능 잠금(Feature Lock): 신규 기능 추가를 멈추는 날짜
• 코드 잠금(Code Freeze): 승인된 결함만 수정하는 날짜
• 제출 버퍼: 빌드 생성, 플랫폼 제출, 인증 재제출에 필요한 기간

2. 기능을 유지·축소·연기·삭제로 분류한다

기능 목록을 한 번에 모두 논의하지 말고 각 항목에 결정 상태를 부여한다.

flowchart TD
    A[기능 목록과 남은 작업 정리] --> B{핵심 게임 루프에 필요한가?}
    B -- 예 --> C{출시 전 완료 위험이 허용 범위인가?}
    B -- 아니오 --> D{축소안으로 가치를 제공할 수 있는가?}
    C -- 예 --> E[유지]
    C -- 아니오 --> F[범위 축소 또는 일정 재협상]
    D -- 예 --> G[축소 출시]
    D -- 아니오 --> H[출시 후 연기 또는 삭제]

분류 결과에는 반드시 담당자와 확인 날짜를 붙인다. “연기”는 담당자가 없는 보류가 아니라 다음 검토 시점과 복구 조건이 있는 제품 백로그 항목이어야 한다.

3. 영향 범위와 복구 계획을 문서화한다

기능 컷 결정 문서는 길 필요가 없다. 대신 질문에 바로 답할 수 있어야 한다.

항목	기록할 내용
결정	유지, 축소, 출시 후 연기, 삭제 중 하나
근거	일정 위험, 의존성, 플레이어 가치, 외부 제약
영향 범위	코드, 콘텐츠, 세이브, UI, QA, 마케팅, 인증
대체안	플레이어 가치 손실을 줄일 방법
담당자	제거·수정·검증을 책임질 사람
완료 조건	빌드와 테스트에서 확인할 항목
복구 조건	출시 후 다시 착수할 수 있는 기준과 우선순위

이 문서는 기획서의 부록이 아니라 변경 관리(Change Control) 기록이다. 변경 이력을 남기면 마케팅 문구, 스토어 페이지, QA 테스트 케이스가 이전 스코프를 계속 참조하는 문제를 줄일 수 있다.

기능 컷 이후 리스크는 어떻게 관리할까?

기능을 잘랐다고 리스크가 사라지지는 않는다. 리스크의 형태가 바뀐다. 따라서 컷 직후에는 리스크 등록부(Risk Register)를 갱신하고 각 항목에 감시 신호와 대응 책임자를 지정한다.

리스크	조기 경보 신호	대응	담당
컷한 기능의 참조가 남음	컴파일 오류, 누락 UI, 세이브 로드 오류	참조 검색, 마이그레이션 테스트, 회귀 테스트	클라이언트·QA
핵심 경험의 빈 공간	플레이테스트에서 목표 상실, 반복 피로	대체 보상, 난이도 곡선, 안내 문구 조정	게임 디자인
외부 커뮤니케이션 불일치	스토어 설명과 실제 빌드의 차이	스토어 자산·트레일러·FAQ 동시 갱신	마케팅·PM
일정이 다시 밀림	컷 후에도 주간 완료량이 계획 미달	추가 컷 후보 사전 승인, 범위 재협상	PM·리드

리스크 관리는 주간 회의의 장황한 보고가 아니라 관측 가능한 신호를 확인하는 일이어야 한다. 예를 들어 “QA가 불안하다” 대신 “핵심 경로 20개 중 7개가 아직 회귀 테스트를 통과하지 못했다”처럼 측정 가능한 상태로 기록한다.

기능 컷 회의에서 피해야 할 실수

이미 만든 것이 아까워서 유지한다

투입한 시간은 되돌릴 수 없는 매몰비용이다. 지금 판단해야 할 것은 그 기능을 마무리하고 유지하는 데 앞으로 얼마나 드는지와 그 시간이 핵심 품질을 높이는 데 더 가치 있게 쓰일 수 있는지다.

모두가 조금씩 더 하면 된다고 생각한다

마감 직전의 추가 노동은 피로와 결함률을 높인다. 특히 통합과 QA가 필요한 기능은 개인의 노력만으로 병렬화되지 않는다. 초과근무를 일정 계획의 전제로 두면 품질 리스크가 다음 주로 이월된다.

컷 결정을 구두로만 공유한다

구두 합의는 빠르지만 지속되지 않는다. 결정 직후 티켓, 릴리스 범위 문서, 테스트 계획, 외부 공개 자료를 함께 갱신해야 팀이 같은 제품을 만들게 된다.

자주 묻는 질문 (FAQ)

기능 컷은 언제 결정해야 하나?

기능 잠금 날짜 이전에 결정하는 것이 가장 안전하다. 다만 핵심 경로의 결함률이나 잔여 작업량이 계획을 초과했다면 다음 마일스톤까지 기다리지 말고 즉시 컷 후보를 재평가해야 한다.

완성도가 80%인 기능도 컷해야 하나?

그럴 수 있다. 남은 20%가 통합, 성능, QA, 인증처럼 예측하기 어려운 작업이라면 실제 위험은 높다. 이미 쓴 시간보다 출시 기준을 충족하는 데 필요한 미래 비용을 기준으로 판단한다.

컷한 기능은 반드시 출시 후 업데이트해야 하나?

아니다. 출시 후 플레이 데이터, 사용자 피드백, 운영 비용을 다시 평가해야 한다. 컷 당시의 우선순위를 그대로 복구하기보다 출시 버전에서 확인된 문제와 기회를 기준으로 재정렬하는 편이 낫다.

마무리

좋은 기능 컷은 게임을 작게 만드는 결정이 아니라 약속한 핵심 경험을 끝까지 완성하기 위한 선택이다. 핵심 게임 루프와 출시 기준을 먼저 고정하고 기능의 가치와 위험을 같은 기준으로 비교하며 영향 범위와 복구 조건을 문서화하자.

일정이 흔들릴수록 팀에는 더 많은 기능보다 더 명확한 기준이 필요하다.