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

--- 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 라고 불러도 되는지(예/아니오)