143 lines
5.8 KiB
Markdown
143 lines
5.8 KiB
Markdown
---
|
|
요청번호: REQ-XXX (일련번호 부여)
|
|
요청일: YYYY-MM-DD
|
|
요청부서: 기획팀
|
|
수신부서: 개발팀
|
|
담당에이전트: (예: /게임플레이, /클라이언트)
|
|
우선순위: HIGH | MID | LOW
|
|
상태: 대기 | 진행중 | 응답완료 | 보류
|
|
유형: 밸런스수치_요구서
|
|
관련PD지시: #N (해당 시)
|
|
---
|
|
|
|
# 밸런스 수치 요구서 표준 템플릿
|
|
|
|
> **용도**: 기획팀이 개발팀에 밸런스 수치 변경·신규 테이블 반영을 요청할 때 사용하는 표준 포맷.
|
|
> **원칙**: C7(재미 근거 필수) · C11(개발 관점 존중) · C6(백업 의무) · P16(변경 이력) · P24(기각안 기록).
|
|
> **사용법**: 본 파일을 복사하여 `YYYY-MM-DD_REQ-XXX_요약제목.md`로 저장 후 채워 넣는다.
|
|
|
|
---
|
|
|
|
## 1. 요구서 식별
|
|
|
|
| 필드 | 값 |
|
|
|------|-----|
|
|
| **요구서 ID** | REQ-XXX |
|
|
| **기준 버전** | (예: PCAwakening.json `v1.3.2`, 수상한잡화점_밸런싱전략_v1.md) |
|
|
| **기준 커밋** | (git SHA 또는 "main@YYYY-MM-DD HH:MM") |
|
|
| **작성자** | (기획팀장 / balance-designer 등) |
|
|
|
|
---
|
|
|
|
## 2. 변경 필드 목록
|
|
|
|
대상 파일·테이블과 변경 대상 필드를 명시.
|
|
|
|
| # | 파일·테이블 | 필드 경로 | 변경 유형 |
|
|
|---|------------|---------|---------|
|
|
| 1 | (예: `table_PCAwakening.json` > PC6001) | `s_Value` | 수정 |
|
|
| 2 | (예: `카드시너지_v2.xlsm` > Sheet1!B5:B20) | `effect_coefficient` | 신규 |
|
|
|
|
**변경 유형**: `수정` / `신규` / `삭제` / `구조변경`
|
|
|
|
---
|
|
|
|
## 3. 변경 전후 수치
|
|
|
|
실제 수치를 전후 대비로 명시. 다건이면 표로, 단건이면 단락으로.
|
|
|
|
| # | 대상 | 현재값 | 제안값 | 비고 |
|
|
|---|------|--------|--------|------|
|
|
| 1 | PC6001 MaxHP Node 100394 `s_Value` | `'500%'` | `'50%'` | 데이터 입력 오류 정정 |
|
|
| 2 | 스테이지 5 몬스터 HP | 1200 | 1400 | 난이도 곡선 조정 |
|
|
|
|
성장 곡선·구간 변경 시 구간별 전후 값 전수 명시.
|
|
|
|
---
|
|
|
|
## 4. 재미 근거 (C7 필수)
|
|
|
|
> **"어떤 재미를 강화하는가"를 먼저 정의**해야 수치 변경이 허용된다 (C7). 재미 정의 없는 수치 조정은 금지.
|
|
|
|
- **강화하려는 재미 축**: (예: "보스전 긴장감", "빌드 다양성", "만렙 성취감")
|
|
- **변경 전 재미 문제점**: (예: "현재 만렙 DPS +1067%로 보스가 3초 내 클리어되어 긴장감 소실")
|
|
- **변경 후 기대 경험**: (예: "만렙 DPS +50% 수준으로 보스 TTK 10~15초 구간 유지, 긴장감 보존")
|
|
- **측정 지표**: (예: "Unity MCP 시뮬 100회 평균 TTK", "만렙 클리어율 70~85% 구간")
|
|
|
|
---
|
|
|
|
## 5. 개발 관점 우려 예상 (C11 존중)
|
|
|
|
> 기획팀이 개발팀 관점(C11 — 자원 효율성·코드 직관성·범용성)에서 예상되는 우려를 **사전 명시**하여 논의 효율을 높인다. 개발팀이 추가 우려를 발견 시 C3(은폐 금지)에 따라 즉시 제기.
|
|
|
|
| 관점 | 예상 우려 | 기획팀 입장 |
|
|
|------|----------|-------------|
|
|
| **자원 효율성** | (예: 매 프레임 재계산으로 CPU 부담) | (예: 변경 빈도 낮음 — 초기화 시 1회 계산 가능) |
|
|
| **코드 직관성** | (예: `500%` vs `5.0` 혼재로 파싱 복잡) | (예: 신규 `s_Value_type` 컬럼 도입 제안) |
|
|
| **범용성** | (예: 차기 프로젝트 재활용 어려움) | (예: 프로젝트 특수 로직으로 한정, 범용 모듈 분리) |
|
|
|
|
우려 없을 시 "없음 (기획팀 분석 범위 내 우려 없음)" 명시.
|
|
|
|
---
|
|
|
|
## 6. 검증 방법
|
|
|
|
변경이 의도대로 동작하는지 확인할 수 있는 검증 시나리오.
|
|
|
|
- **검증 채널**: Unity MCP 시뮬 / 로컬 빌드 / QA 수동 / 수치 단위 테스트
|
|
- **검증 케이스**:
|
|
1. (예: "만렙 PC 5종에 각성 트리 풀 해방 상태로 Stage 10 보스 진입 → 10회 반복 → TTK 평균 10~15초 확인")
|
|
2. (예: "중간 단계 3레벨 상태 전투 시뮬 → DPS 증가율 +20~30% 구간 확인")
|
|
- **통과 기준**: (검증 케이스별 수치 기준 명시)
|
|
- **회귀 검증**: 변경 대상 외 기존 밸런스 경로(P14 QA 게이트) 영향 없음 확인
|
|
|
|
---
|
|
|
|
## 7. 백업·이력 (C6·P16)
|
|
|
|
- **백업 파일**: `{원본명}.bak_YYYYMMDD_HHMM.{확장자}` — 개발팀이 변경 착수 전 생성
|
|
- **변경 이력 기록 위치**: 대상 md 문서 하단 "변경 이력 테이블"에 append
|
|
- **관련 대화로그**: `공유/대화로그/수상한잡화점/YYYY-MM-DD.md` 엔트리 링크
|
|
|
|
---
|
|
|
|
## 8. 기각안 (P24 — 결정성 요청이면 권장)
|
|
|
|
검토했으나 채택하지 않은 대안과 기각 사유. 조직 자산 축적의 핵심 (헌법 제1원칙 목표 2 원칙 B).
|
|
|
|
| # | 기각 대안 | 기각 사유 |
|
|
|---|----------|----------|
|
|
| 1 | (예: 현재값 유지 + 별도 난이도 옵션 도입) | (예: 신규 시스템 비용 대비 재미 개선 불확실) |
|
|
| 2 | (예: `500%` 일괄 → `100%`) | (예: 과도한 하향으로 각성 성취감 소실 우려) |
|
|
|
|
기각 대안 미검토 시 "없음 (단일안 — 사유: ...)" 명시. 공란 금지.
|
|
|
|
---
|
|
|
|
## 9. 응답 섹션 (개발팀 작성)
|
|
|
|
> 개발팀이 본 요구서에 응답할 때 아래 섹션을 append. 별도 응답 파일 분리 불필요 (본 파일 단일 SOT).
|
|
|
|
### 9-1. 개발 관점 검토 결과
|
|
- 수용 가능 여부: 수용 / 조건부 수용 / 반려
|
|
- 추가 우려: (기획팀 예상 외 발견 시)
|
|
- 대안 제시: (반려·조건부 시)
|
|
|
|
### 9-2. 변경 적용 결과
|
|
- 적용 커밋: (SHA)
|
|
- 백업 경로: (`.bak_YYYYMMDD_HHMM.{확장자}`)
|
|
- QA 검증 결과: (통과/실패 + 상세)
|
|
- 회귀 검증: (통과/실패)
|
|
|
|
### 9-3. 후속 필요 작업
|
|
- (예: 밸런스 조정 후 balance-designer 재튜닝 필요)
|
|
- (예: Unity MCP 시뮬 재실행 필요 — 경계값 재산출)
|
|
|
|
---
|
|
|
|
## 변경 이력
|
|
|
|
| 일시 | 변경자 | 변경 내역 |
|
|
|------|--------|----------|
|
|
| 2026-04-17 | 기획팀장 | 표준 템플릿 신설 (PD님 직접 지시, 팀장 재량 진행 승인) |
|