AI 기반 스코프 크립 관리: 버릴 기능 우선순위를 자동 분류하는 법
게임 개발에서 늘어나는 기능 요청을 AI와 점수 모델로 분류해 일정·핵심 재미·리스크 기준으로 먼저 버릴 항목을 찾는 실전 스코프 크립 관리 방법을 정리합니다.
핵심 요약
스코프 크립은 기존에 합의한 프로젝트 범위가 통제되지 않게 확대되는 현상이다. 이 글에서는 기능 요청을 같은 기준으로 비교하고 일정·비용 영향을 확인해 이를 관리하는 방법을 다룬다. AI는 기능 설명을 구조화하고 누락된 근거를 찾는 보조 도구로 쓰며, 최종 폐기 후보는 CutScore로 비교한다. 점수에는 핵심 루프 연결도, 일정 지연 위험, 요구사항·기술 불확실성, 예상 인일, 재사용성을 반영한다.
게임 개발에서 스코프 크립은 왜 발생하는가?
기능 요청이 추가됐다고 모두 스코프 크립인 것은 아니다. 원래 합의한 범위 밖의 일이 일정·비용·자원 조정이나 명시적 승인 없이 범위에 편입되면 스코프 크립 위험이 커진다. 출시 목표와 교환 비용을 함께 확인하지 않은 채 기능이 백로그에 남고 우선순위가 반복해서 바뀌는 상황을 점검해야 한다.
예를 들어, 다음과 같은 요청은 폐기 판단이 늦어질 위험이 있어 점검할 수 있다.
- 데모에서 반응이 좋을 것 같은 연출 기능
- 경쟁작에 있으니 필요해 보이는 편의 기능
- 이미 만든 시스템을 활용할 수 있다는 이유의 파생 콘텐츠
- “작으니 이번 스프린트에 넣자”고 시작한 UI·저장·QA 작업
기능 하나의 개발 비용은 구현 시간만이 아니다. 기획 확정, UI 연결, 로컬라이제이션, 저장 데이터 마이그레이션, 테스트와 해당하는 경우 콘솔 인증 영향도 고려해야 한다.
AI로 버릴 기능을 어떻게 자동 분류할까?
AI에게 “무엇을 버릴까?”라고만 물으면 일관된 결과를 기대하기 어렵다. 먼저 기능 요청을 고정된 필드로 변환하고 수식으로 정렬한 뒤 사람이 최종 결정을 내리는 흐름이 필요하다.
flowchart LR
A[기능 요청 백로그] --> B[AI 구조화]
B --> C[점수 산정]
C --> D{폐기 후보 기준 충족?}
D -->|예| E[폐기 또는 출시 후 검토]
D -->|아니오| F[출시 범위 또는 실험]
E --> G[결정 로그]
F --> GAI는 판단 권한자가 아니라 분류와 기록을 보조하는 도구다. 이 역할을 분리하면 팀의 취향이나 회의 분위기가 점수 모델을 덮어쓰는 상황을 줄이는 데 도움이 될 수 있다.
1. 기능 요청을 비교 가능한 데이터로 바꾼다
Notion, Linear, Jira, 스프레드시트 등 도구와 무관하게 기능마다 아래 필드를 만든다.
| 필드 | 설명 | 예시 |
|---|---|---|
| feature_id | 변경되지 않는 식별자 | FEAT-042 |
| player_problem | 해결하려는 플레이어 문제 | 보스 패턴을 읽기 어렵다 |
| core_loop_link | 핵심 루프 연결도, 1–5 | 4 (전투 중 회피 판단 지원) |
| effort_days | 구현·통합·QA를 포함한 예상 인일 | 6 |
| delay_risk | 일정 지연 가능성, 1–5 | 4 |
| uncertainty | 요구사항·기술 불확실성, 1–5 | 3 |
| reuse_score | 출시 후 다른 콘텐츠에 재사용할 가능성, 1–5 | 2 |
| evidence | 플레이테스트, 데이터, 요구사항 링크 | PT-12 관찰 기록 |
AI 프롬프트에는 원본 요청과 팀의 용어집을 함께 넣는다. 예를 들어 “핵심 루프”가 전투-보상-빌드 선택인지 탐험-제작-건설인지 먼저 정의하면 모델이 기능을 잘못 연결할 가능성을 줄일 수 있다. 생성된 연결은 사람이 확인해야 한다.
다음 기능 요청을 JSON으로 구조화하라.
- 사실로 확인된 내용과 추정 내용을 분리한다.
- 근거가 없으면 임의로 채우지 말고 null로 둔다.
- core_loop_link, delay_risk, uncertainty는 근거가 있을 때만 1–5 정수로 제안한다. 근거가 부족하면 null로 둔다.
- 판단 근거를 evidence_gap 배열에 기록한다.
핵심 루프: 전투 -> 보상 선택 -> 빌드 강화
기능 요청: 보스전 종료 후 사진 모드와 SNS 공유 화면을 추가한다.여기서 중요한 규칙은 null을 허용하는 것이다. 필수 점수에 null이 있으면 임의로 0점 처리하지 말고 CutScore 산출을 보류해 근거를 보완하거나 사람이 검토해야 한다. 근거가 없는 수치를 AI가 생성하면 자동 분류 결과를 실제 근거보다 신뢰할 위험이 있다.
2. 폐기 우선순위 점수를 계산한다
모든 프로젝트에 맞는 단일 수식은 없다. 다만 출시 직전의 게임이라면 핵심 재미 기여가 낮고 일정 부담과 불확실성이 높은 기능을 먼저 폐기 후보로 올리는 것이 실용적이다.
각 항목을 같은 1–5 척도로 평가한다고 가정하면 다음 점수를 사용할 수 있다. core_loop_link도 1–5점으로 채점하고, 근거가 없는 필수 점수가 있으면 위에서 설명한 대로 계산을 보류한다.
CutScore가 높을수록 출시 범위에서 빼기 좋은 후보다. 가중치는 팀 상황에 맞게 한 번 정하고 같은 마일스톤 동안 자주 바꾸지 않는다.
| CutScore 구간 | 기본 처리 | 사람이 확인할 질문 |
|---|---|---|
| 3.5 이상 | 폐기 후보 | 없어도 출시 목표가 성립하는가? |
| 2.5 이상 3.5 미만 | 출시 후 검토 | 플레이테스트 또는 매출 가설이 있는가? |
| 1.5 이상 2.5 미만 | 범위 축소 | 최소 버전으로 핵심 문제를 해결할 수 있는가? |
| 1.5 미만 | 유지 후보 | 의존 기능과 일정이 명확한가? |
EffortScore는 인일을 그대로 쓰지 말고 팀의 백로그 분포에 맞춰 1–5로 구간화한다. 예를 들어 1–2일은 1점, 3–5일은 2점, 6–10일은 3점으로 시작하고 더 긴 작업은 팀의 백로그에 맞춰 4–5점 구간을 정한다.
3. AI가 만든 결과를 회의용 결정 문서로 바꾼다
정렬된 목록을 그대로 승인하지 말고 AI에게 각 상위 폐기 후보를 짧은 결정 카드로 요약하게 한다.
다음 기능의 폐기 후보 판단을 120자 이내로 요약하라.
반드시 포함할 것:
1) 플레이어 영향
2) 일정 영향
3) 유지가 필요한 전제 또는 폐기 가능한 이유
근거 없는 내용은 '확인 필요'로 표시한다.회의에서는 기능별 토론보다 다음 세 가지를 확인한다.
- 이 기능이 없으면 출시 버전의 핵심 루프가 깨지는가?
- 근거는 실제 플레이테스트·텔레메트리·계약 요구사항 중 어디에 있는가?
- 폐기 대신
출시 후 검토로 옮길 경우 필요한 재검토 조건은 무엇인가?
결정 결과는 반드시 폐기, 출시 후 검토, 범위 축소, 유지 중 하나로 기록한다. “나중에 보자”는 상태는 담당자와 재검토 날짜가 없으면 사실상 스코프에 남는다.
기능 폐기 우선순위 모델에서 AI가 잘하는 일과 못하는 일
| AI가 보조할 수 있는 일 | 사람이 결정해야 할 일 |
|---|---|
| 티켓 문장 요약과 필드 추출 보조 | 출시 목표 변경 |
| 중복 기능과 의존성 후보 표시 | 브랜드·계약·플랫폼 요구사항 판단 |
| 근거 누락, 모호한 요구사항 표시 보조 | 핵심 재미의 최종 정의 |
| 점수표 정렬과 회의록 초안 작성 보조 | 리스크 수용 여부 |
AI를 활용하는 한 가지 방법은 “빠르게 버린다”가 아니라 “왜 남겼는지와 왜 버렸는지를 같은 형식으로 기록하도록 보조한다”는 것이다. 기록이 보존되고 연결되어 있다면 다음 분기에 기능을 재검토할 때 당시의 근거와 가정을 추적하는 데 도움이 된다.
자주 묻는 질문 (FAQ)
AI 점수만으로 기능을 폐기해도 될까?
안 된다. 점수는 비교 순서를 만드는 도구다. 핵심 루프, 계약 의무, 플랫폼 인증, 접근성 요구사항은 점수와 별도로 사람이 검토해야 한다.
작은 기능은 점수가 낮으면 바로 추가해도 될까?
아니다. 작은 기능도 UI, 저장, QA, 번역 같은 연결 비용을 포함해 추정해야 한다. 특히 다른 시스템의 상태를 바꾸면 실제 비용이 커질 수 있다.
플레이테스트 데이터가 없으면 어떻게 시작할까?
AI가 근거 없는 숫자를 만들지 않도록 evidence_gap을 기록하고 기획 가설로 임시 점수를 둔다. 다음 플레이테스트에서 확인할 관찰 항목을 결정 카드에 추가한다.
정리
AI 기반 스코프 크립 관리는 모델에게 기능을 버리게 하는 방식이 아니다. 기능 요청을 같은 데이터 구조로 만들고 CutScore로 폐기 후보를 드러내며 사람이 근거와 출시 목표를 기준으로 결정하는 운영 방식이다.
다음 스프린트에는 백로그 전체를 바꾸기보다 상위 20개 기능만 구조화해 보자. 점수보다 먼저 드러나는 것은 대개 기능의 가치가 아니라 팀이 아직 합의하지 못한 출시 기준이다.
