BurningTimesAi/공유/기획/GodDem/2026-08-21_S3_밸런스_조정안_v1.md

# GodDem SurvivalBattle S3 밸런스 정밀 조정안 v1

> **작성**: balance-designer(기획팀) 2026-08-21 · **근거**: PD 승인 "전부 진행해"(2026-08-21) · 스킬이식 설계 §4 S3 단계("밸런스 튜닝(데미지/쿨타임 GodDem 스케일)... balance-designer") 집행
> **범위**: 스킬 10종 확정(A02·A04·A05·A06·A08·A10·A11·A12·A13·A_Laser) 시점 SurvivalBattle 전면 밸런스. **A15(추적화염구)는 .asset 미생성 확인 — 본 문서 범위 밖, 추가 이식 시 별도 조정 필요.**
> **절대 제약**: 본 문서가 유일 산출물. GodDem 레포(`E:\NerdNavis\GodDem`)는 Read만 수행, 수정 0건. 반영은 개발팀장 검증 후 별도 집행.
> **실측 소스** (전부 Read 완료, 추정 0):
> - `Assets/Resources/Skills/Active/*.asset` 10종 전수
> - `Assets/Resources/CSV/SurvivalUpgrade.csv` (12트랙×6단계, 72행)
> - `Assets/Script/Survival/SurvivalBattleManager.cs`·`SurvivalUnit.cs`·`SurvivalUpgrade.cs`·`SurvivalSkill.cs`
> - `Assets/Script/Survival/Skills/SurvivalActiveSkillRunner.cs`·`SurvivalClone.cs`·`SurvivalProjectile.cs`·`SurvivalPoisonSwamp.cs`·`SurvivalSpiritFire.cs`·`SurvivalDebuffStack.cs`
> - `공유/기획/GodDem/2026-08-20_원작밸런스_해독_매핑_v1.md`(§4 수식 SOT) · `2026-08-20_스킬이식_설계_v1.md`(§4 단계 정의)
> - 개발팀장 실측 관측 2026-08-21 (웨이브2 무스킬 사망 케이스)

---

## 0. 유저 세그먼트 고지 (P30/밸런싱 출력 포맷 필수 항목)

실측 범위(SurvivalBattleManager·SurvivalUnit·SurvivalUpgradeTable·SurvivalSkill 전 코드) 내 **IAP·메타 재화 연동 지점 0건 확인**. Gold는 런 종료 시 영속 저장 로직이 없는 **매판 로그라이크 전용 재화**이며, 시작 스탯(PlayerHp 400·PlayerAttack 22 등)에 과금 등급별 분기가 없다. 따라서 표준 "무과금/소과금/고과금" 3단 비교는 **본 모드에 해당사항 없음**으로 표기한다(추정 아님 — 코드 부재를 실측 확인). 계정 레벨 영구 재화가 이 모드 시작치에 영향을 주는지는 별도 시스템(상점·계정재화) 실측이 추가로 필요하나 본 문서 범위 밖이다. 아래 마스터 표의 "세그먼트 영향" 열은 이 고지에 따라 전부 "전 세그먼트 동일(과금 미연동)"로 통일 표기한다.

---

## 1. 설계 전제

| 항목 | 값 |
|------|-----|
| 기준 플레이어 | 레벨1, 강화 0단계, 스킬 0종 (런 시작 직후) |
| 목표 경험 1 (최우선) | "첫 판에 스킬 한 번 못 쓰고 죽는 경험" 제거 — 웨이브1 100% 가까운 생존, 웨이브2 종료 시점 HP 15~35%(위협 구간 진입, 사망 아님) |
| 목표 경험 2 | 웨이브3부터는 자연 레벨업(1~2 스킬 보유) 전제하에 재미 있는 위협 유지 — 전멸이 아니라 "타이트한 전투" |
| 목표 경험 3 | 스킬 10종이 서로 다른 카테고리(투사체/범위/장판/소환/특수)로 "고른 존재감" — 압도적 1강 없이 상황별 강점 |
| 시행 편차 기준 | 동일 조건 반복 시행에서 웨이브1~2 생존율 편차를 축소(현재: 동사망~웨이브4 도달 편차 확인됨) |

---

## 2. 핵심 공식 (실측 원본, 변경 없음 — 조정은 파라미터만)

```
적 스탯:  EnemyHP(stage s, wave w) = EnemyBaseHp × StageStep^(s-1) × WaveStep^((w-1) mod 10)
          EnemyATK = EnemyHP / HpToAtkRatio(=4, 원작 A80ChampMatchConfig 4:1 규율 — 미변경)
          Boss: HP×BossHpMultiplier(=8) — 미변경
적 수:    count = boss ? 1 : BaseEnemyCount + (Wave-1) × EnemyCountPerWave   ← Wave는 스테이지 리셋 없는 전역 카운터(§8 리스크 R-A)
적 공격:  cooldown=1.2초·range=1.3 (SpawnWave 내부 하드코딩 리터럴, Inspector 노출 필드 아님)
플레이어 DPS: PlayerAttack(22) / PlayerAttackCooldown(0.7) = 31.43 (강화 0단계 기준, 크리티컬 0%)
스킬 유효딜: EffectiveDamage(Lv) = BaseDamage × StackFactor(Lv) × (Player.Attack/22) × DamageScale(1)
            EffectiveCooldown(Lv) = max(BaseCooldown / StackFactor(Lv), 0.5)
            StackFactor = {Lv1:1.0, Lv2:1.2, Lv3:1.4, Lv4:1.6, Lv5:2.0}
강화 누적: Total(key) = Σ(1~현재단계 Grades[].Applied)  — BasisPoint는 /10000 환산
```

**웨이브 내 총 피해량 모델(신규 도출식, 최우선 항목의 근거)** — "전원 즉시 근접·지속 공격"을 가정한 **비관적 하한선**(실제 스폰 지연·물리 충돌로 실전 생존율은 이보다 높음):

```
TotalDamageTaken(wave) = (적ATK/1.2) × (적HP/플레이어DPS) × N(N+1)/2
   ※ N=해당 웨이브 적 수. N마리를 순차 처치하는 동안 전원이 매 순간 공격한다고 가정한 근사식.
```

---

## 3. 초반 생존 곡선 재설계 (최우선)

### 3-1. 문제 진단 (실측 검증)

개발팀장 관측치를 위 공식으로 역산하면 **정확히 일치**한다: 웨이브2(stage1) = HP 62.4·ATK 15.6("atk≈16")·적 6기(count=4+1×2) → 6×15.6/1.2=78 DPS("≈80 DPS"). 위 도출식 대입:

| 웨이브 | 적HP | 적ATK | 적수 N | 소요 피해량(하한 모델) | 잔여 HP(누적, 400 기준) |
|---|---|---|---|---|---|
| 1 | 60.0 | 15.0 | 4 | 238.6 | 161.4 (40.3%) |
| 2 | 62.4 | 15.6 | 6 | 541.9 | **-380.5 (사망)** |

→ 웨이브1을 40% HP로 겨우 넘긴 뒤, 웨이브2의 6마리 동시 압박(누적 피해 542)이 잔여 HP를 초과해 **사망이 수식으로도 재현된다**. 반면 "웨이브4·레벨3 도달" 시행은 스폰 각도 지터(`Random.Range(-0.25,0.25)`)와 Rigidbody2D 충돌로 적이 실제로는 동시에 근접하지 못해 이 비관적 하한선보다 훨씬 적은 피해를 받은 경우로 추정된다 — **동일 코드에서 결과가 극단적으로 갈리는 것 자체가 설계 결함**이다(§7 편차 항목과 연결).

경험치 교차검증: BaseExpReward 12 × 웨이브1 4킬 = 48 < RequiredExp(50). **웨이브1을 전부 잡아도 레벨업 불가** — 최초 스킬은 반드시 웨이브2에서(1킬째 60exp 도달) 나온다. 즉 "무강화·무스킬" 구간은 설계상 **웨이브1 전체 + 웨이브2 극초반**이며, 이 구간 생존 보장이 유일하게 필요한 조정 지점이다(웨이브3은 자연 레벨업 전제로 별도 판정, 아래 3-4).

### 3-2. 조정안

| 항목 | 현재 값 | 제안 값 | 근거 |
|---|---|---|---|
| `EnemyBaseHp` | 60 | **42** (-30%) | HP:ATK=4:1 비율(원작 규율) 유지한 채 기저값만 축소 → 피해량은 HP²에 근사 비례해 축소(0.7²≈0.49, 약 51%↓). 원작 "구조는 그대로/강도는 재조정" 원칙(SOT §6-3) 그대로 적용, 4:1 비율 자체는 불변 |
| `EnemyCountPerWave` | 2 | **1** (증가율 절반) | N(N+1)/2 항이 지배적 — 웨이브당 +2마리는 2차 함수로 피해량을 폭증시킴. 웨이브2 N을 6→5로 낮추는 것만으로 합산항이 21→15(29%↓) |
| SpawnWave 적 수 산식 | `BaseEnemyCount+(Wave-1)*EnemyCountPerWave` (Wave=전역 누적) | **`BaseEnemyCount+waveInStage*EnemyCountPerWave`**(스테이지별 리셋, 코드 변경 필요) | HP/ATK는 이미 `waveInStage` 기준인데 적 수만 전역 `Wave` 기준 — 스테이지 2부터 웨이브1이 count=24(=4+10×2)로 시작하는 구조적 폭발(§8 R-A). 조정값(EnemyCountPerWave=1)과 별개로 반드시 동반 수정 권고 |
| `PlayerHp` | 400 | (보류) 440~480 | 1차 조정(EnemyBaseHp·EnemyCountPerWave)만으로 웨이브2 종료 잔여 23%가 확보됨 — **선제 적용 보류**, 플레이테스트에서 목표 미달 시에만 2차 버퍼로 투입(과잉조정 방지, C2) |

### 3-3. 조정 후 재계산

| 웨이브 | 적HP | 적ATK | 적수 N | 소요 피해량 | 잔여 HP(400 기준) |
|---|---|---|---|---|---|
| 1 | 42.0 | 10.5 | 4 | 116.9 | **283.1 (70.8%)** |
| 2 | 43.7 | 10.9 | 5 | 189.7 | **93.4 (23.4%)** |

웨이브2 종료 시점 23.4% = 기획 목표("HP 20% 이하 위협 구간") 바로 위 경계 — **"위협 구간 진입하되 생존"**이 정확히 재현된다. 추가로 이 모델은 "전원 상시 근접" 가정의 **하한선**이며, 실제로는 (a) 스폰 지연 수 초, (b) 레벨업 시 `Time.timeScale=0` 강제 정지로 전투 자체가 멈추는 무피해 구간이 웨이브2 중간(1킬째)에 반드시 발생 — 두 요인 모두 실전 생존율을 이 계산치보다 높인다.

### 3-4. 웨이브3 처리 방침 (자연 레벨업 전제)

무강화·무스킬 가정을 웨이브3까지 유지하면 산식상 -194(사망)이 나오지만, **3-1의 경험치 역산상 웨이브3 진입 시점에 이미 레벨2(스킬1개), 웨이브3 중반에 레벨3(스킬2개)**이 자연 발생한다(BaseExpReward12×누적킬수 기준). 따라서 웨이브3은 "무강화 생존"이 아니라 **"보유 스킬 1~2개 전제 생존"**이 맞는 목표이며, 본 문서는 웨이브3을 무스킬 기준으로 추가 너프하지 않는다 — 스킬 로스터의 7/9종이 AOE(§4)라는 사실이 정확히 이 국면(다수 적 포위)을 카운터하도록 설계돼 있어, 스킬 하나만 있어도 상황이 크게 달라진다.

**검토했으나 기각한 대안**: `BaseEnemyCount` 4→3 축소(시작 인원 자체를 줄이는 안). 재계산 결과 웨이브1 잔여 82%(과도하게 안전 — 긴장감 저하)·웨이브3 필요피해 382.8(현재안 287.1보다 악화)로, 목표(웨이브2 위협구간 진입)에 더 안 맞음 — **"시작치 감소"보다 "성장률 감소"가 목표에 더 정합**하다는 판단으로 기각.

---

## 4. 스킬 10종 실효 DPS 정규화

### 4-1. 방법론

"목표 1체가 스킬 전체 효과 시간 내내 그 자리에 머문다"고 가정한 **정적 최대 처리량**(실전 상한, 보장치 아님)을 기준으로 통일. AOE 스킬은 실제 총딜이 적중 적 수만큼 배가되므로 별도 열로 구분.

| CardId | 스킬 | 유형 | Lv1 총딜/1회 | Lv1 DPS | Lv3 DPS | Lv5 DPS | 대상범위 |
|---|---|---|---|---|---|---|---|
| A02 | 파이어볼 | 직격+DoT(6틱×3) | 12+18=30 | **20.0** | 39.2 | 80.0 | 단일 |
| A08 | 저주의화살 | 5연사 평균(스택폭발 포함) | 30/5사이클 | **7.5** | 14.7 | 24.0* | 단일(스택은 동일 개체 지속 피격 전제) |
| A06 | 독늪 | 존 6초+마커 5초(10틱) | 100 | **10.0** | 19.6 | 40.0 | 광역(존 10×1.5, 사실상 화면폭) |
| A_Laser | 용염레이저 | 7틱×0.167초 간격 | 35 | **11.7** | 22.9 | 46.7 | 광역(라인 10×1.2) |
| A05 | 학익진 | 단발 광역 | 10 | **6.7** | 13.1 | 26.7 | 광역(4.8×1.2, 좌우 동시) |
| A04 | 번개충격 | 단발(랜덤 위치) | 15 | **6.0** | 11.8 | 24.0 | 소범위(1.2×0.8) |
| A12 | 정화의빛 | 단발 2박스 동시 | 15 | **3.0** | 5.9 | 12.0 | 광역(4×2 + 1.2×6 이중) |
| A11 | 정령불 | 8틱×1초(지속8/15) | 40 | **2.7** | 5.2 | 10.7 | 광역(3.4×1.4, 플레이어 중심) |
| A13 | 천둥발(구체) | 관통 재타격 | 이론상 240** | **96**(이론상)** | — | — | 광역(반경4 — 실측 필요) |
| A10 | 분신 | 미러링(고정딜 없음) | — | 0.5×가동률×타 스킬합 | 〃 | 〃 | 배율형(§5) |

\* A08 Lv5는 EffectiveCooldown이 0.5초 하한(floor)에 걸림(0.8/2.0=0.4<0.5) — 하한이 없었다면 30 DPS, 실제는 24 DPS로 **약 20% 손실**. Lv4→Lv5 체감 상승폭이 다른 스킬보다 완만한 이유.
\*\* A13은 §8 R-E 결함(코드가 자산의 `MaxRange:6`을 무시하고 `speed×6=12`로 강제 — 모든 관통형 스킬에 적용되는 잠재 결함)과 `_hitRadius=4`(스폰반경과 동급)가 겹쳐 이론상 상한이 극단적으로 큼. **실측(플레이테스트) 최우선 후보**로 표기 — 신뢰 가능한 "실전 DPS" 없이 이 수치를 근거로 삼지 않는다(추정 아님을 강조하기 위해 의도적으로 단일 확정값을 제시하지 않음, C44).

### 4-2. 스킬별 판정

| 판정 | 대상 | 근거 |
|---|---|---|
| **변경 불요** | A02 | 단일 대상 한정 스킬 중 최고 DPS(20)지만, AOE 배율이 전혀 없어 광역 스킬과 상쇄됨(광역군은 다수 적중 시 사실상 2~4배) — 장르 관행상 합리적 트레이드오프 |
| **변경 불요(명목수치로 저평가됨)** | A11 | 로스터 내 명목 DPS 최저(2.7)지만, 정확히 "다수 약체에 포위당하는" 본 문서 최우선 문제(3장)를 카운터하는 지속 광역 오라 — 명목딜이 아니라 대응 상황이 핵심 가치 |
| **관찰만(변경 보류)** | A_Laser 설명 텍스트 | .asset `Description`은 "0.5초 간격"이라 적혀 있으나 코드 실측(`RepeatFrameInterval:10프레임`=0.167초)과 불일치 — 밸런스 수치 자체는 코드값이 맞으므로 변경 불요, **설명 텍스트만 컨텐츠팀 확인 권고**(별건) |
| **정밀 실측 필요(수치 변경 아님)** | A13 | §8 R-E — 코드 결함 수정 후 재계산 필요. 결함 수정 전 이 수치 기준 다른 스킬과 비교하지 말 것 |
| **등급 체계 관찰** | 전체 | 패시브 카탈로그(공격력강화 등 10종)는 5514/2944/888 가중추첨(확률 59.0%/31.5%/9.5%, 등급별 배율×1.0/1.5/2.2)이 적용되나, **액티브 스킬(본 10종)은 항상 고정 Grade3**로 등급 추첨을 우회함. 대신 레벨1→5는 재픽 추첨(1/10 균등, 미보유 스킬 수만큼 분모 감소)에 의존 — 패시브보다 "완성까지" 운 의존도가 오히려 높음(1회 추첨으로 끝나는 패시브 vs 여러 번 재당첨 필요한 액티브). 변경 제안 아님, 팀 인지 목적 기록 |

---

## 5. A10 분신(Clone) 검증

### 5-1. 전제 검증 결과 — 코드 실측, 둘 다 정상 구현 확인

| 전제 | 검증 결과 |
|---|---|
| 미러링 피해 50% | `SurvivalClone.DamageMultiplier=0.5f` 상수, `EnqueueMirror`에서 `Damage=damage*DamageMultiplier` 정확 적용 |
| 무한 재귀 차단 | **이중 방어** 확인 — ① `EnqueueMirror`: `if (data.CardId=="A10") return;`(A10 자신을 아예 큐에 안 넣음) ② `FireClone`: `if (_cloneFire) return;`(분신 발동 컨텍스트 중 재소환 차단). 버그 없음 |

### 5-2. 기대 기여 공식 및 레벨별 가동률

```
A10 기여 DPS = 0.5(고정 미러 배율) × Uptime(Lv) × Σ(보유 중인 다른 OnTime 스킬의 DPS)
Uptime(Lv) = MinionLifetime(12, 레벨 무관 고정) / EffectiveCooldown(Lv)
```

| 레벨 | EffectiveCooldown | Uptime | 배율(0.5×Uptime) |
|---|---|---|---|
| 1 | 25.0초 | 48.0% | 0.24× |
| 2 | 20.8초 | 57.6% | 0.29× |
| 3 | 17.9초 | 67.2% | 0.34× |
| 4 | 15.6초 | 76.8% | 0.38× |
| 5 | 12.5초 | **96.0%** | **0.48×** |

**핵심 발견**: A10을 레벨업해도 미러 배율(0.5)·발동 지연(0.25초)은 불변 — `SurvivalClone.cs`의 `DamageMultiplier`·`FireDelay`가 `ActiveSkillData` 필드가 아니라 **하드코딩 상수**이기 때문(레벨 시스템은 쿨다운만 단축). 즉 A10의 레벨업 가치는 순수하게 "가동률 상승"이며, Lv5에서는 사실상 상시 가동(96%)으로 **다른 액티브 스킬 보유 총딜의 절반을 거의 무료로 복제**하는 강력한 후반 스노우볼 카드가 된다.

**리스크**: A10 자체는 데미지 0(BaseDamage:0) — **다른 액티브 스킬을 하나도 보유하지 않은 상태에서 뽑으면 완전 무가치**. 로그라이크 드로우가 "보유/강화 가능한 액티브 1종을 슬롯 보장"하는 구조상, A10이 **최초의 액티브 슬롯으로 등장·선택되면 그 즉시는 순수 폐카드**다. 수치 변경 제안은 아니며(구조상 당연한 트레이드오프), UX 문구로 "다른 발동 스킬 보유 시 위력 발휘"를 명시할 것을 ux-designer 영역으로 별도 제안.

---

## 6. 강화 12종 비용 대비 효율

### 6-1. 실측 — 12트랙 전부 동일 비용 곡선(10/42/99/184/301/454, 트랙당 합계 1090골드)

| 트랙 | 6단계 누적 값 | RecalcPlayer 연동 여부 | 실효 버킷 |
|---|---|---|---|
| attack_add | +87%(비율) | `atkRatio`에 합산 | 공격력 버킷 A |
| hurt_add | +87%(비율) | `atkRatio`에 **동일** 합산 | 공격력 버킷 A (attack_add와 완전 동일 효과) |
| hp_add | +210%(비율) | `hpRatio` | HP 버킷 |
| hp(Flat) | +6600 | `hpFlat` | HP 버킷(hp_add와 합산, 상한 없음) |
| attack_speed_add | +87% | `spd`(쿨다운 나눗셈) | 공속 버킷 |
| lucky_rate | +21%p | `CriticalRate` | 크리티컬 확률 |
| lucky_multiple | +87% | `CriticalMultiplier`(기본2.0에 가산) | 크리티컬 배율 |
| suck_ratio | +31.5% | `LifeSteal` | 흡혈 |
| hurt_reduce | +45% | `reduce` 합산 후 **0.8 클램프** | 방어 버킷 B |
| defense_add | +42% | `reduce` 합산 후 **0.8 클램프** | 방어 버킷 B (hurt_reduce와 동일 버킷) |
| dodge_rate | +31.5% | `reduce` 합산 후 **0.8 클램프** | 방어 버킷 B (동일) |
| **penetrate_ratio** | +21% | **RecalcPlayer 어디에도 미참조** | **완전 무효(사장)** |

### 6-2. 조정안

| 항목 | 현재 값 | 제안 값 | 근거 |
|---|---|---|---|
| `penetrate_ratio` 트랙 | 상점 노출, 골드 소모, 효과 0 | **배선 연결(개발팀 협의) 또는 상점 임시 비노출** | RecalcPlayer 전수 실측 결과 참조 0건 — 골드를 써도 아무 효과가 없는 **순수 손실 함정 옵션**. 원작 SOT의 "HeroAttackMultiplier 사장" 결함과 동일 패턴의 3번째 사례(§8 R-E와 함께 반복 유형). 경제 무결성상 최우선 수정 후보 — **balance-designer 단독 반영 불가(C6·레포 수정 금지), 개발팀 REQ 필요** |
| 방어 3종(hurt_reduce/defense_add/dodge_rate) 조합 상한 | 3종 합산 후 0.8 클램프, UI 경고 없음 | (제안) UI에 "현재 방어 합산 X%(cap 80%)" 표기 또는 3종을 1개 트랙으로 통합 | hurt_reduce 단독 풀강(45%)+defense_add 단독 풀강(42%)만으로 이미 87%>80% cap 도달 — dodge_rate에 투자하는 골드는 **최대 100% 낭비** 가능. 트랙 자체는 살아있으나 투자 순서에 따라 부분적으로 헛돈 나가는 구조 |
| attack_add/hurt_add 라벨 분리 | 완전 동일 효과(같은 버킷) | (제안) 차별화(예: hurt_add를 크리티컬 대상 피해나 방어 관통으로 재설계) | 플레이어에게 손해는 없으나(가산은 그대로 유효) "왜 2개 트랙인가"에 대한 재미 근거 부재 — P30 원칙상 라벨과 실제 효과가 어긋나는 항목은 개선 여지 |

**세그먼트 영향**: 전 세그먼트 동일(과금 미연동, §0). 12트랙 전부 인게임 재화(Gold)만 소모.

---

## 7. EXP 곡선 vs 웨이브당 처치 수 (레벨업 페이싱)

### 7-1. 실측

```
ExpTable(heroskilltree 20단계, 이식 그대로): 50,100,150,200,250,310,370,430,490,550,620,690,760,830,900,980,1060,1140,1220,1300
BaseExpReward=12 (Stage1 고정, 웨이브 무관 — Stage에만 ×1.2^(s-1) 배율)
Stage1 웨이브별 처치수(현재 count식): 4,6,8,10,12,14,16,18,20,(보스1×8배exp)
```

### 7-2. 스테이지1 전체 클리어 시 자연 도달 레벨 (현재 vs 제안, 무사망 가정)

| 항목 | 현재(EnemyCountPerWave=2) | 제안(EnemyCountPerWave=1) |
|---|---|---|
| 웨이브1~9 총 처치수 | 108 | 72 |
| 총 획득 EXP(보스 포함) | 1,392 | 960 |
| 자연 도달 레벨 | 레벨7 중반(~레벨8 문턱) | 레벨6~7 (약간 완만) |

제안값 적용 시 스테이지1 완주 시 레벨 도달치가 소폭 완만해지나(레벨7±1), 최초 스킬 획득 시점(레벨2, 웨이브2 1킬째)은 **불변**이다 — 조정은 적 수 성장률만 건드렸고 킬당 EXP(BaseExpReward)·ExpTable은 그대로이기 때문. 3장의 최우선 목표(웨이브1~2 생존)에는 페이싱 변경이 없고, 스테이지1 후반(웨이브6~9)이 다소 완만해지는 부수효과는 §8 R-A(스테이지별 리셋 구조 변경) 적용 시 스테이지2부터 HP·ATK 지수 성장(×2.1)으로 자연 상쇄된다.

### 7-3. 검증

- 레벨업 시 `Time.timeScale=0`로 전투가 완전히 멈춘다 — 웨이브 중간에 강제 "무피해 휴식 구간"이 매 레벨업마다 삽입되는 구조. 3장의 비관적 모델이 이 휴식을 반영하지 않으므로, 실전 생존율은 모델보다 **항상** 우호적이다.
- 레벨업 페이싱 자체는 스테이지1 기준 재설계 불필요 — **변경 불요** 판정.

---

## 8. 시행 편차 완화 제안 (코드 변경 필요 — 제안만, 반영은 개발팀 판단)

| 원인 | 실측 근거 | 제안(코드 변경 필요) |
|---|---|---|
| 스폰 타이밍 지터 | `Random.Range(-0.25,0.25)` 각도 지터 + 타원 스폰(`x*0.55`)으로 적별 도달 시각이 시행마다 달라짐 | 초기 그레이스(예: 웨이브1 한정 스폰 지연 +0.5~1초 균일 적용)로 편차 축소 — 지터 자체는 유지(완전 결정적이면 재미 저하) |
| 물리 충돌 병목 | 다수 적이 Rigidbody2D로 서로 밀치며 근접 도달이 시행마다 크게 갈림(비관적 모델과 실전 결과 괴리의 주원인으로 추정) | 코드 실측 범위 밖(런타임 물리 시뮬레이션) — **추정**. 실측하려면 Play 모드 계측 필요, 개발팀 협의 대상 |
| 방어 옵션 부재 | 레벨업 패시브 카탈로그 10종(`SurvivalSkill.Catalog`) 중 직접적 "피해 감소" 항목이 **0개**(체력강화·응급처치만 간접 완충) — 방어 3종은 골드 상점 전용 | 패시브 카탈로그에 "피해 감소" 옵션 신설(예: hurt_reduce 소량 부여) — 골드 없이도 방어 축 접근 가능하게 하여 초반 불운 시행의 하한을 높임 |
| 액티브 스킬 간 명목 DPS 편차 | §4 표 — Lv1 기준 A02(20) vs A11(2.7)로 최대 7.4배 편차, 어떤 스킬이 먼저 뽑히는지가 초반 체감 난이도를 크게 좌우 | 최초 액티브 슬롯 한정으로 "생존 관련 스킬"(A05·A06·A11·A12처럼 광역인 것)에 소폭 가중치를 주는 안전망 편향 — 로그라이크 랜덤성은 유지하되 최악의 케이스만 완화 |

---

## 9. 마스터 변경 요약 (현재값 → 제안값 + 근거, 전 항목)

> ⚠️ **본 표는 v2 §5 최종 채택안으로 대체됨** (plan-auditor 재검증 통과·GodDem `d5dea4d` 반영 완료). 특히 PlayerHp 보류 행은 **철회 확정**, A13 DPS 96은 **48로 갱신**, 코드 변경 3항목(SpawnWave 산식·penetrate_ratio·A13 override)은 `7728a41`에서 **집행 완료** — 본 표 기준 재의뢰 금지. → `2026-08-21_S3_밸런스_조정안_v2.md`

| 항목 | 현재 값 | 제안 값 | 근거 | 세그먼트 영향 |
|---|---|---|---|---|
| `EnemyBaseHp` | 60 | **42** | 4:1 비율 유지한 채 웨이브1~2 누적 피해 51%↓ (§3) | 전 세그먼트 동일(과금 미연동) |
| `EnemyCountPerWave` | 2 | **1** | N(N+1)/2 항 완화, 웨이브2 N 6→5 (§3) | 전 세그먼트 동일 |
| SpawnWave 적 수 산식(코드) | 전역 `Wave` 기준 | `waveInStage` 기준(스테이지 리셋) | 스테이지2+ 무한 증가 방지(§8 R-A, 코드 변경 필요) | 전 세그먼트 동일 |
| `PlayerHp` | 400 | (보류) 440~480 | 1차 조정으로 목표 달성 — 미달 시에만 2차 투입 | 전 세그먼트 동일 |
| `penetrate_ratio` 배선 | 미배선(무효) | 배선 또는 임시 비노출 | 골드 순손실 함정 옵션 실측 확인(§6, 코드 변경 필요) | 전 세그먼트 동일 |
| A13 관통 사거리 override | `max(MaxRange, speed×6)`가 자산값(6) 무시하고 12 강제 | 자산 `MaxRange` 존중하도록 수정 또는 의도적 배율로 명문화 | 데이터-코드 불일치 결함(§8 R-E, 코드 변경 필요) | 전 세그먼트 동일 |
| 레벨업 패시브 카탈로그 | 방어 옵션 0종 | "피해 감소" 옵션 신설 | 시행 편차 하한 개선(§8, 코드 변경 필요) | 전 세그먼트 동일 |
| A02·A04·A05·A06·A08·A10·A11·A12·A_Laser 수치 | 현행 유지 | **변경 없음** | §4 판정표 — 명목 편차는 AOE 특성으로 설명 가능, 임의 조정 시 근거 부재(C2 과잉조정 방지) | 전 세그먼트 동일 |

---

## 10. 검증 시나리오

| # | 시나리오 | 통과 기준 | 방법 |
|---|---|---|---|
| 1 | 웨이브1 무강화 생존 | 종료 시 HP ≥ 62.5%(250/400) | 계산 재검증(70.8% 산출) + Play 실측 |
| 2 | 웨이브2 종료 위협구간 진입 | HP>0 && 잔여 15~35% | 계산 재검증(23.4%) + Play 실측 |
| 3 | 자연 진행 웨이브3 클리어율 | N≥20 시행 중 ≥80% 클리어 | **플레이테스트 전용** — 수식만으로 확정 불가(레벨업 스킬 랜덤성) |
| 4 | A10 고립 검증 | A10 단독 보유 시 순수 DPS 기여 0 확인, 재귀 발동 0건 | 코드 검증 완료(§5-1) — 런타임 회귀 테스트 권고 |
| 5 | penetrate_ratio 무효 확인 | 해당 트랙만 만렙 시 Player 전 스탯 변화 0 | QA 실측(개발팀/QA 영역) |
| 6 | 방어 3종 클램프 확인 | hurt_reduce+defense_add 만렙 시 DamageReduction=0.8 정확히 고정(0.87 아님) | QA 실측 |

---

## 11. 리스크

| ID | 리스크 | 심각도 | 내용 |
|---|---|---|---|
| R-A | 적 수 전역 누적 | 높음 | `count`가 스테이지 리셋 없는 전역 `Wave` 기준 — 스테이지2 웨이브1부터 count=24, 스테이지3+ 40~60대까지 무한 증가(성능·밸런스 동시 붕괴 가능성). 본 문서 조정과 별개로 **최우선 구조 수정 후보** |
| R-B | penetrate_ratio 사장 | 높음(경제 무결성) | RecalcPlayer 전수 실측 결과 참조 0건. 원작 SOT의 "HeroAttackMultiplier 사장" 결함과 동일 유형 3번째 사례 — 반복 패턴 |
| R-C | 방어 3종 상한 낭비 | 중간 | hurt_reduce+defense_add만으로 87%>80% cap 초과, dodge_rate 투자분 부분/전체 낭비 가능 |
| R-D | attack_add/hurt_add 완전 동일 | 낮음(손해 없음) | 플레이어 손해는 없으나 라벨 차별화 부재 — P30 재미 관점 개선 여지 |
| R-E | A13 관통 사거리 override 결함 | 중간~높음 | `SurvivalProjectile`이 모든 `Trajectory=Arc`(관통) 스킬에 대해 `speed≥1`이면 자산의 `MaxRange`를 항상 무시(`speed×6`이 항상 더 크거나 같음) — 현재 A13 1종 영향, 향후 관통형 스킬 추가 시 동일 결함 반복 가능 |
| R-F | A08 스택 누적 실전 신뢰도 | 중간 | 매 발사 "최근접 적" 자동 조준으로 대상이 시행마다 바뀔 수 있고, 스택은 시간 감쇠 없이 개체별로 무기한 유지 — 목표가 자주 바뀌면 5스택 폭발이 명목 계산보다 드물게 발생할 가능성(추정, 실측 필요). 부수 — 스택 5 미만에서 사망한 개체의 딕셔너리 참조가 정리되지 않는 경미한 누수 가능성(개발팀 확인 사항) |
| R-G | 방어 옵션 카탈로그 부재 | 중간 | 레벨업 무료 패시브 10종 중 직접 방어 옵션 0종 — 골드 상점만 방어 접근 가능, 초반 불운 시행의 편차를 키움 |
| R-H | 3장 모델은 비관적 하한선 | 낮음(안전 방향) | "전원 상시 근접" 가정 — 실제 생존율은 모델보다 높을 것으로 예상되나 정확한 폭은 플레이테스트 없이는 정량화 불가 |
| R-I | 세그먼트 분석 해당사항 없음 | 정보성 | §0 — 현재 코드에 IAP/메타 재화 연동 0건. 향후 연동 시 본 문서 전면 재분석 필요 |

---

## 12. 변경 이력 (P16)

| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 |
|---|---|---|---|---|---|
| 2026-08-21 | balance-designer | 문서 최초 작성 | (없음) | v1 전체(§1~11) | PD 승인 "전부 진행해" · 스킬이식 설계 §4 S3 단계 집행. 반영 여부·시점은 개발팀장 검증 후 별도 결정 |

---

**후속 조치 (본 문서 범위 밖, 팀장급 확인 필요)**:
1. §9 마스터 표의 "코드 변경 필요" 4항목(SpawnWave 산식·penetrate_ratio 배선·A13 override·패시브 카탈로그 방어옵션)은 `공유/소통/기획팀→개발팀/REQ-템플릿_밸런스수치.md` 표준 양식으로 개발팀 협의 필요.
2. §10 시나리오3(자연 진행 웨이브3 클리어율)은 수식이 아닌 실측 플레이테스트가 필요 — 개발팀장 Unity 세션 여유 시점에 별도 요청.
3. 본 문서는 PD 지시 로그(`공유/PD_지시_트래킹/기획팀_PD_지시_로그.md`) 등재·대화로그 엔트리 기록이 **미수행 상태**다(산출물 단일화 제약으로 본 세션에서 제외) — 팀장/PM 레벨에서 C13·P19·C32 동기화 처리 필요.