출시 가능성 감사 스킬 (프로토타입을 완성이라 부르지 않기)

---
name: release-readiness-audit
description: Use when asked to make, finish, assess, or declare complete a product (game or app) meant to be sold or monetized. Classify its status with strict names, demand evidence per gate, and refuse to call a prototype or vertical slice a release candidate. 출시 가능성 판정, 완성 선언 전 점검에 사용.
---

# 출시 가능성 감사

핵심 원칙: **동작하는 핵심 기능은 "다음 단계로 갈 근거"일 뿐, 완성품이 아니다.** 이 스킬은 프로토타입을 완성이라 부르는 일을 막는다.

## 절차
1. 프로젝트의 기획·설계·검수 문서와 현재 상태를 읽는다.
2. 만들어진 것을 **정확히 하나의 상태**로 분류한다.
   IDEA(아이디어) → MARKET_VALIDATED(수요 확인) → CONCEPT_LOCKED(컨셉 확정) → VERTICAL_SLICE(핵심 한 판이 됨) → SCOPE_LOCKED(출시 범위 확정) → ALPHA(처음~결과 전체 흐름 있음, 콘텐츠 미완) → CONTENT_COMPLETE(약속한 콘텐츠 전부 구현) → BETA(다듬기·실입력 시험·저장·성능 통과) → RELEASE_CANDIDATE(전 기준 통과)
3. 아래 기준표로 각 관문을 증거와 함께 점검한다.
4. 새 컨셉이면 제작 전에 **장르 수요를 증명**한다: 공개 출처, 날짜, 지표, 수익 모델, 증거 강도를 적는다. 다운로드 수를 지어내지 않는다(평점·리뷰 수는 대용품일 뿐 다운로드가 아님).
5. 성공한 같은 장르 작품과 비교해 **제작 범위를 잠근다**: 시스템 수, 콘텐츠 단위, 화면, 에셋, 소리, 진행 구조, 목표 플레이 시간.
6. 약속한 모든 플레이어 기능을 **실제 사용자 입력**으로 검증한다. 내부 상태를 직접 바꿔서 통과시킨 것은 증거가 아니다.
7. 짧은 반복 / 전체 흐름 / 장시간 플레이 / 저장 후 재시작 / 성능 / 화면을 점검하고, 실패는 열어 둔 채 고쳐 나간다.
8. 모든 관문의 증거가 있을 때만 RELEASE_CANDIDATE 라 부른다. 아니면 **정확히 더 낮은 상태 이름**을 말한다.

## 기준표 (최소 증거. 프로젝트 자체 기준이 더 엄격하면 그것을 따른다)

**1. 시장·가치**
- 비슷한 출시작 2개 이상, 그중 하나는 수요 증거가 강함(공식 다운로드 구간, 의미 있는 유료 리뷰 수, 꾸준한 순위, 퍼블리셔가 확인한 판매 주장).
- 출처 주소·관찰 날짜·지표·플랫폼·가격/광고 모델·신뢰도를 기록한다.
- 가치 트랙 하나를 고른다(광고 기반 반복 플레이 / 유료 모바일 / 유료 PC). 왜 플레이어가 기존 작품 대신 이걸 선택하는지 적는다.

**2. 제작 계약**
- 플레이어 판타지, 차별화 포인트, 설계 기둥, 첫 세션의 약속.
- 전체 화면 흐름: 실행·온보딩·플레이·일시정지·승패·재도전/다음·설정·이어하기·진행/종료.
- 시스템·콘텐츠·에셋/애니메이션/소리 목록, 저장 구조, 대상 플랫폼, 성능 예산, 목표 플레이 시간.
- 콘텐츠 단위마다 "플레이어의 어떤 결정을 바꾸는가"를 적는다. 숫자만 바뀐 변주는 절반 미만, 의미 있는 결정 전환은 3개 이상(성공한 작품이 더 작은 완결형을 증명하지 않는 한).

**3. 실행 증거**
- 실제 입력으로 모든 주요 흐름을 시작하고 끝까지 간다.
- 단위 시험은 내부를 볼 수 있지만, 종단 시험은 "증명하려는 동작"을 건너뛰려고 숨은 상태를 바꾸면 안 된다.
- 성공·실패·아슬아슬한 실패·전략을 바꾼 재도전·저장 후 다시 열기·경계 조건·대상 화면비/입력 방식을 다룬다.
- 5/15/30/60분 세션(또는 장르에 맞는 동등한 것). 새로움·반복·빈 시간·오류·"계속할 이유가 남는가"를 기록한다.

**4. 연출·손맛**
- 최종 화면이 컨셉 목표(위계·정보·행동·결과·밀도·감정)를 유지한다.
- 시제품 표시, 디버그 표시, 임시 이미지, 안 눌리는 버튼, 소리 없는 핵심 동작, 끊기는 전환, 화면마다 달라 보이는 디자인이 없다.
- 핵심 동작에 예고 → 즉각 반응 → 성공/실패/아쉬운 실패가 읽히는 시각·청각 피드백이 있다.

**5. 안정·완료**
- 출시 경로에 파서·런타임·콘솔 오류가 없다.
- 장시간 구동에서 선언한 프레임 시간·메모리·로딩·크래시 예산을 만족한다.
- 저장이 재시작 후에도 살아 있고, 저장 형식 버전 처리가 문서화돼 있다.
- 범위 목록과 구현이 항목 단위로 일치한다. 빠진 항목은 "시간이 없어서"가 아니라 증거 있는 의도적 예외여야 한다.
- 내보낸 빌드를 처음 실행부터 결과·재시작까지 다시 해 본다.

## 상태 상한 규칙
| 최대로 부를 수 있는 상태 | 필요한 증거 |
|---|---|
| VERTICAL_SLICE | 핵심 루프가 동작하고 짧은 재미 가설이 증거로 있음 |
| SCOPE_LOCKED | 출시 범위와 가치 트랙이 명시됨 |
| ALPHA | 시작→결과 전체 흐름이 있음(콘텐츠는 미완 가능) |
| CONTENT_COMPLETE | 계약한 시스템·콘텐츠·에셋이 모두 구현됨 |
| BETA | 콘텐츠 완료 + 다듬기·종단 시험·저장·성능·장시간 수정 |
| RELEASE_CANDIDATE | 모든 기준 통과, 내보낸 빌드 검증, 열린 차단 문제 없음 |
**라벨만 바꿔서 단계를 건너뛰지 않는다.**

## 넘지 말아야 선
- 시장 통과는 "기회"를 승인한 것이지 만든 게임을 승인한 게 아니다.
- 10초짜리 핵심 증명은 VERTICAL_SLICE 까지만 된다.
- 빌드 파일이 생겼다고 출시 준비가 된 게 아니다.
- 내부 상태를 직접 바꿔서는 플레이어 흐름을 증명할 수 없다.
- 소리·저장/이어하기·결과/재도전 경로·대상 플랫폼 입력이 없으면 BETA 미만이다(장르 기준상 정말 해당 없다는 문서가 있을 때만 예외).
- 같은 세션에서 만든 쪽이 스스로 하는 평가만으로는 주관적 증거가 되지 않는다.
- 쓴 시간은 품질 기준이 아니다. 기준은 납품된 범위와 증거다.

## 보고 형식
- 현재 상태(위 9개 중 하나)
- 통과한 관문과 증거 파일 경로
- 실패했거나 확인할 수 없는 관문
- 바로 할 다음 조치(어느 단계로 돌아가 무엇을 할지)
- RELEASE_CANDIDATE 라고 불러도 되는지(예/아니오)