PetAI 극상세 WBS 마스터
버전: 1.0
기준일: 2026-07-21
목적: 단일 거대 명세를 팀이 실행 가능한 작업분해구조로 나누고, 범위·의존성·담당·완료 증거를 한곳에서 연결한다.
제품 비중: 게임 경험 80~90%, 생활 보조 10~20%
현재 구현 기준: Unity 6000.5.4f1, 로컬 저장 schema 4
1. 문서 사용 순서
- 처음 읽는 사람은 최종 기능 한눈에 보기에서 제품의 모습과 포함·제외 이유를 이해한다.
- 팀은 최종 제품 기능 범위 의사결정서에서
포함 / 조건부 포함 / 논의 필요 / 제외를 합의한다.
- 이 마스터에서 릴리즈 Gate와 분야 간 선행 관계를 확인한다.
- 담당자는 자기 분야 WBS에서 work package와 완료 증거를 가져간다.
- 인터페이스가 바뀌면 자기 문서만 고치지 않고 마스터의 의존성 표와 상대 담당 문서를 함께 갱신한다.
- 리듬게임은 이 문서 묶음에서 정의하지 않는다. 별도 HTMLBook이 생기면 링크만 추가한다.
2. 문서 맵
| WBS |
문서 |
책임 질문 |
링크 |
| 0.0 |
극상세 WBS 마스터 |
전체 순서와 Gate가 무엇인가 |
현재 문서 |
| 0.05 |
최종 기능 한눈에 보기 |
처음 읽는 팀원이 제품 범위를 빠르게 이해하는가 |
열기 |
| 0.1 |
최종 제품 기능 범위 |
완성된 제품에 무엇을 넣고 무엇을 영구히 뺄 것인가 |
열기 |
| 1.0 |
제품·경험 WBS |
어떤 사용자 경험을 언제 검증하는가 |
열기 |
| 2.0 |
Unity·도메인 WBS |
어떤 상태와 화면을 클라이언트가 구현하는가 |
열기 |
| 3.0 |
로컬 AI·기억 WBS |
AI가 무엇을 표현하고 무엇을 결정하지 않는가 |
열기 |
| 4.0 |
백엔드·데이터·보안 WBS |
서버가 꼭 필요한 기능과 전송 금지는 무엇인가 |
열기 |
| 5.0 |
콘텐츠·사건 WBS |
Day 0~7 사건과 한국어를 어떻게 생산하는가 |
열기 |
| 6.0 |
QA·릴리즈 WBS |
무엇을 어떤 증거로 출시 가능하다고 판단하는가 |
열기 |
| 후속 |
리듬게임 명세 |
장르·입력·판정·점수·난이도·오디오 |
별도 HTMLBook 작성 뒤 링크 예정 |
3. WBS 상태 체계
| 상태 |
의미 |
다음 상태로 가는 조건 |
NOT_STARTED |
범위는 있으나 착수하지 않음 |
담당자·선행 조건·산출물 확정 |
READY |
선행 조건이 모두 충족됨 |
실제 작업 시작 |
IN_PROGRESS |
구현·작성·검증 중 |
산출물 제출 |
REVIEW |
담당자 산출물이 나와 교차 검수 중 |
수용 기준과 증거 통과 |
VERIFIED |
자동·수동 증거까지 충족 |
후속 Gate에 입력 |
BLOCKED |
외부 결정 또는 선행 작업이 없음 |
blocker와 해제 조건 명시 |
DEFERRED |
이번 릴리즈에서 의도적으로 제외 |
별도 승인 없이는 착수 금지 |
코드가 있음, 문서가 있음, 이미지가 있음은 VERIFIED가 아니다. 실제 빌드, 상태 저장, 사람 입력, 한국어, 개인정보 경계를 포함한 완료 증거가 필요하다.
4. 최상위 작업분해구조
| WBS |
Work package |
우선순위 |
주 책임 |
핵심 산출물 |
완료 증거 |
| 1.1 |
제품 계약·관계 약속 |
P0 |
Product |
한 문장 정의, 관계 범위, 실패 원칙 |
팀 승인 기록 |
| 1.2 |
첫 5분·7일 경험 |
P0/P1 |
Product·Content |
화면 흐름, Day 0·1·3·7 |
무설명 사용자 테스트 |
| 2.1 |
Boot·저장·복구 |
P0 |
Unity |
inspect, load, migration, recovery UI |
EditMode·PlayMode·Player 증거 |
| 2.2 |
홈·상호작용 |
P0 |
Unity |
이동, 터치, 가구, sorting |
실제 입력 영상 |
| 2.3 |
사건·추억·달력 |
P0/P1 |
Unity·Content |
event runner, memory, calendar |
중단·재실행 일치 |
| 2.4 |
공동 놀이 공통 shell |
P0 |
Unity |
entry, pause, outcome adapter, result |
장르 독립 fixture |
| 3.1 |
Template-first 대사 |
P0 |
Local AI·Content |
intent catalog, fallback templates |
모델 없이 전 구간 완주 |
| 3.2 |
로컬 SLM 표현 |
P1 |
Local AI |
input/output validator, timeout |
오프라인 한국어 평가 |
| 3.3 |
로컬 기억 |
P1 |
Local AI·Unity |
fact/preference/episode store |
삭제·수정·충돌 fixture |
| 4.1 |
콘텐츠 배포 |
P2 |
Backend |
signed manifest, bundle, rollback |
변조·오프라인 테스트 |
| 4.2 |
선택 온라인 기능 |
P2 |
Backend |
weather, push, backup, analytics |
동의·fallback·보존 검증 |
| 5.1 |
캐릭터 바이블 |
P0 |
Content |
욕망·결점·취향·거절·말투 |
30문장 블라인드 검수 |
| 5.2 |
Day 0~7 사건 |
P1 |
Content |
schema-valid event bundle |
날짜 주입 완주 |
| 6.1 |
테스트 자동화 |
P0 |
QA·Unity |
unit, integration, PlayMode |
최신 XML 100% 통과 |
| 6.2 |
물리 입력 검증 |
P0 |
QA |
success/failure/restart/recovery |
끊기지 않은 영상·상태 대조 |
| 6.3 |
CI/CD·배포 |
P2 |
DevOps |
GitHub Actions, build, Fastlane |
재현 가능한 artifact |
5. 통합 의존성
기능 범위 승인
→ 제품 계약과 상태 불변 조건
→ 콘텐츠 schema + Unity domain contract + AI intent contract
→ Template-only Day 0 완주
→ 저장·복구·홈·공동 놀이 shell 안정화
→ Day 1 사건·추억·달력 연결
→ 로컬 SLM을 표현 계층으로 추가
→ Day 0·1·3·7 통합
→ 선택적 backend와 배포 자동화
병렬 가능
- Unity 저장 복구와 캐릭터 바이블
- 사건 schema fixture와 로컬 AI validator
- Backend OpenAPI 초안과 로컬-only 플레이
- QA 시나리오 작성과 기능 구현
병렬 금지
- 관계 수치 계약 전에 Unity·콘텐츠·AI가 각자 보상을 정의
- event schema 전에 Day 0~7 대사를 대량 작성
- template fallback 없이 SLM을 필수 경로에 연결
- 수동 build가 재현되기 전에 CI/CD만 먼저 구축
- 별도 리듬게임 명세 전에 BPM·판정·점수·보상을 공통 문서에 확정
6. 릴리즈 Gate
| Gate |
목표 |
필수 통과 |
진입 금지 조건 |
| G0 범위 |
제품과 최종 범위 합의 |
최종 기능 범위표, 관계 약속, 명시적 제외 |
핵심 기능 상태가 OPEN |
| G1 기반 |
데이터 손실 없는 수직 슬라이스 |
저장·복구·홈·공동 놀이 shell·결과 |
actual Player 증거 없음 |
| G2 하루 |
Day 0~1 완성 루프 |
사건, 선택, 추억, 재실행, 한국어 |
template-only 완주 불가 |
| G3 7일 |
Day 0·1·3·7 연결 |
날짜·날씨 fallback, 회고, 복귀 |
날짜 주입과 중단 복구 불가 |
| G4 팀 배포 |
반복 가능한 팀 build |
repository, CI, artifact, QA 보고 |
로컬 build 재현 불가 |
| G5 선택 온라인 |
서버 기능의 가치 검증 |
consent, fallback, 최소 payload |
로컬 핵심 플레이가 서버 의존 |
7. 현재 가장 중요한 결정
- 최종 제품 기능 범위의
IN, OUT, 조건부 포함 기준을 팀이 승인한다.
- 관계 범위를 우정·동료애 중심으로 유지할지 확정한다.
- Day 0·1·3·7 중 실제 다음 주 데모에 넣을 날을 확정한다.
- 공동 놀이 shell의 장르 독립 contract를 유지한다.
- 리듬게임은 별도 문서가 생길 때까지 기획 확정 항목으로 세지 않는다.
- 로컬 AI 없는 template-only 경로를 먼저 합격시킨다.
- 실제 사람 입력과 save recovery 증거가 없는 항목을 완료 처리하지 않는다.
8. 변경 관리
- 범위 변경은 기능 범위 명세서의 상태와 이유를 먼저 수정한다.
- 담당 구현 문서, API contract, QA case를 같은 변경 묶음으로 갱신한다.
- 삭제한 기능은 데이터 field와 화면 흔적까지 확인한다.
DEFERRED 기능을 몰래 placeholder 뒤에 구현하지 않는다.- 모든 WBS 문서의 버전과 마스터 링크를 릴리즈 Gate마다 대조한다.
9. 2026-07-23 기능 범위 보완 반영
9.1 WBS 연결 변경
| 상위 영역 |
추가·수정해야 하는 하위 WBS |
선행 결정 |
| WBS 1 제품·경험 |
튜토리얼 권한 문맥, 스트레스 UX, 도감, 위젯/푸시, 친구 안전 |
성장·알림·공개 범위 정책 |
| WBS 2 Unity |
상태 schema, 도감/상점, 권한 fallback, widget snapshot, friend UI |
데이터 계약과 platform capability |
| WBS 4 Backend |
OAuth, push, weather proxy, friend snapshot, purchase restore, backup |
consent/allowlist/retention |
| WBS 5 콘텐츠 |
히든·한정·기능 아이템, 이벤트·재등장 정책, 알림 카피 |
경제·운영 정책 |
| WBS 6 QA/릴리즈 |
권한 거절, 푸시 opt-out, 복원/환불, 친구 차단, offline fallback |
각 기능의 failure contract |
9.2 기능 Gate
- Gate P1: 육성 파라미터와 일일 감소식이 수치·표시·회복 UX까지 확정됨.
- Gate P2: 아이템 종류·도감 표시·한정 재등장·상품 복원이 정책과 schema로 일치함.
- Gate P3: 위젯/푸시/날씨가 권한 off·offline·조용한 시간에서 안전하게 fallback함.
- Gate P4: OAuth/친구가 최소 데이터 원칙과 차단·신고·공개 범위로 검증됨.
상세 내용은 최종 기능 정의서를 참조한다.