BurningTimesAi/공유/기획/GodDem/2026-08-22_공격력_원작2층_재설계_v1.md

# GodDem 공격력 원작 2층 구조(정액+배율) 재설계 v1

> **작성**: balance-designer(기획팀) 2026-08-22 · **근거**: PD 직접 승인 "이 방향으로 재구현해"(2026-08-22)
> **배경**: PD 실측 지적 — "배율도 존재하지만 단순 기본 공격력을 증가하는 것도 존재해." §6-D(원작대로 밸런싱, 증가량·능력치 종류 그대로 이식) 지시 대비 현 구현 이탈 2건 재설계
> **선행 문서**: [`2026-08-20_원작밸런스_해독_매핑_v1.md`](./2026-08-20_원작밸런스_해독_매핑_v1.md)(이하 "매핑 SOT") · [`2026-08-21_S3_밸런스_조정안_v1.md`](./2026-08-21_S3_밸런스_조정안_v1.md) · [`2026-08-21_S3_밸런스_조정안_v2.md`](./2026-08-21_S3_밸런스_조정안_v2.md)(이하 "S3 v2")
> **절대 제약**: GodDem 레포(`E:\NerdNavis\GodDem`)는 Read만 수행, 수정 0건. 본 문서가 유일 산출물. Unity MCP 미사용(개발팀 영역).
> **표기 규칙(C5)**: 🟢확정(코드/CSV 직접 실측) · 🟡추정(근거 있으나 미확정) · 🔴재추출필요(원본 CSV 재대조 없이는 확정 불가)

---

## 0. 결론 요약

PD 지적은 **정확했다**. 원작은 공격력에 **정액(hero_level power)과 배율(heroskillattr attack_add) 2개 트랙**을 모두 가지고 있고, 체력은 GodDem에도 이미 이 2층이 대칭 이식(`hp` Flat + `hp_add` Ratio)돼 있는데 **공격력만 배율(`attack_add`) 단독**이라 비대칭이다. 코드까지 직접 대조한 결과 원인은 더 구체적으로 드러났다 — `RecalcPlayer()`가 HP는 `(Base×(1+비율)+정액)` 식으로 계산하면서 공격력만 `Base×(1+비율)`로 정액 항이 통째로 빠져 있다(§1-2).

추가로 **현재 `attack_add`의 수치 자체(0.05~0.30)도 진짜 attack_add 원본이 아니라 매핑 SOT가 "계열 prefix 10에서만 성립"이라 명시한 별도 스탯의 패턴을 차용한 것**임을 재대조로 확인했다(§2-2). 다만 이 수치는 **실재 원작 데이터**이고 S3 v2 검증 체크포인트가 전부 강화 0단계(미구매) 기준이라 지금 손대도 리스크가 없다.

**재설계 요지**: ① 신규 정액 트랙 `attack`을 `hp`와 동일 구조로 4:1 유도해 신설(30/90/180/300/450/600) ② 배율 `attack_add`는 현 수치 유지 + 출처 라벨만 정정(안A 채택, 안B 기각 — §5) ③ 몬스터 `EnemyBaseHp` 등은 **유지**(0구매 기준선 불변 확인, §4) ④ 신규 발견 리스크(저메타 구간 정액 압도적 우위·후반 몰빵 무위협) 후속 플레이테스트 권고 ⑤ 정확한 attack_add 원본 단위는 🔴 APK 재추출 전까지 미확정.

---

## 1. 문제 재확인 — 코드 대조 실측

### 1-1. 원작 2층 구조 (매핑 SOT 재인용, 🟢확정)

| 트랙 | 원작 근거 | 성격 |
|---|---|---|
| 정액 | `hero_level.csv` stat(L) = 0.22L²+0.26L (camp1 power, L50=563/L100=2226/L150=4989, 오차 0.00) | 레벨 성장 절대치 |
| 배율 | `heroskillattr.csv` attack_add — 계열 자체 값은 순수 선형, 예시 인용 1.0/2.0/3.0/4.0/5.0 | 스킬 뽑기로 얻는 % 버프 |

### 1-2. GodDem 현 구현 — HP는 대칭, 공격력은 비대칭 (🟢확정, 코드 직접 인용)

`SurvivalBattleManager.cs:180-203` `RecalcPlayer()`:
```csharp
float atkRatio = t.Total("attack_add") + t.Total("hurt_add");
Player.Attack = PlayerAttack * (1f + atkRatio) * Player.SkillAttackMul;      // ← 정액 항 없음

float hpRatio = t.Total("hp_add");
float hpFlat = t.Total("hp");
Player.SetMaxHp((PlayerHp * (1f + hpRatio) + hpFlat) * Player.SkillHpMul);  // ← 정액(hpFlat) 항 존재
```
`Assets/Resources/CSV/SurvivalUpgrade.csv` 트랙 목록도 동일하게 비대칭이다: `hp`(Flat, 120~2400)와 `hp_add`(Ratio, 0.1~0.6)는 쌍을 이루지만, 공격력 쪽은 `attack_add`(Ratio, 0.05~0.30) 단독이고 짝이 되는 `attack`(Flat) 트랙 자체가 CSV에 없다. **PD 지적이 코드 레벨에서 정확히 재현된다.**

---

## 2. 원작 데이터 정밀 재실측

### 2-1. attack_add 원본 단위 확정 시도 (🔴재추출필요)

매핑 SOT §2-4가 인용한 attack_add 고유 계열의 예시값은 **1.0/2.0/3.0/4.0/5.0**(선형, 차분 +1.0)이다. 이 값을 그대로 실전 배율로 쓸 경우 배율 1.0이 "+100%"인지, 혹은 퍼센트 포인트 표기라 "÷100 = +1%"인지는 **매핑 SOT 어디에도 명시되어 있지 않다**. 두 해석 모두 정황 증거는 있으나 결정적이지 않다:

- **배율 직접 해석(1.0=+100%) 반증**: 등급 가중 추첨(§2-5, 매핑 SOT) 기준 quality1(가장 흔한 등급, 뽑기 확률 55.14%)이 곧 이 계열의 최저 등급이다. 가장 흔하게 뽑히는 스킬 하나가 공격력을 그 자리에서 2배로 만든다는 것은 12진영×150레벨의 장기 수집형 구조를 감안해도 과도하다.
- **퍼센트 포인트 해석(1.0=+1%) 반증**: 매핑 SOT §4 스킬 카탈로그 표(GodDem이 이미 채택한 레벨업 3종 택1 시스템용)는 attack_add를 "0.05 등차 +0.02"(5%/7%/9%)로 이미 퍼센트 직접 값으로 쓰고 있다 — 이 선례와 "÷100" 해석을 결합하면 두 시스템의 attack_add 스케일이 5배 이상 벌어져 내부 일관성이 낮아진다.

**결론**: 원본 CSV·복호화 키가 PD 결정(2026-08-21)으로 조직 기록에서 영구 삭제되어 재대조가 불가능하다. **100% 확정에는 원작 APK(현재 `Downloads` 잔존) 재추출이 필요하다** — 진행 여부는 PD·개발팀장 판단 영역(재추출은 개발팀 작업, 본 기획 문서 범위 밖).

### 2-2. 현재 GodDem의 0.05~0.30은 어떻게 유도됐는가 (🟢확정 — 신규 발견)

`SurvivalUpgrade.cs` 코드 주석은 "attack_add 0.05/0.07/0.10/0.15/0.20/0.30 = 원작 그대로"라 적어놓았지만, 매핑 SOT §2-4를 재대조하면 **이 정확한 6개 수열(0.05, 0.07, 0.10, 0.15, 0.20, 0.30)은 "C 5시리즈"로 별도 명명되어 있고, 매핑 SOT 원문이 "계열 prefix 10에서만 성립"이라고 명시**한 스탯이다 — attack_add 고유 계열이 아니다. 진짜 attack_add 계열의 예시는 §2-1에 인용한 1.0/2.0/3.0/4.0/5.0이다.

정황상 최초 CSV 작성자가 heroskillattr 원본에서 attack_add로 태그된 행을 정확히 짚지 못하고, 형태가 비슷한(선형·6단·소수 백분율) 다른 계열의 숫자를 차용해 대입한 것으로 보인다. **다만 이 숫자 자체는 허구가 아니라 원작 원본에 실재하는 검증된 데이터**이므로 "가짜 수치"는 아니고 "계열 라벨이 잘못 붙은 실재 수치"다 — §5에서 이 사실을 반영해 처리 방향을 정한다.

같은 논리로 `hurt_add`·`attack_speed_add`도 동일한 0.05~0.30 수열을 그대로 재사용하고 있음을 확인했다(부수 발견, 본 문서 범위 밖 — §9 리스크로만 기록).

### 2-3. hp 정액·4:1 비율 정합성 (🟢확정)

`SurvivalUpgrade.csv`의 `hp` Flat 트랙(120/360/720/1200/1800/2400)과 `A80ChampMatchConfig`의 HP:공격력=4:1(✅매핑 SOT §2-7, dam>0 12행 전부·예외 0건) 비율은 재설계의 유일하게 안정적인 앵커다. GodDem 몬스터 스탯도 이미 이 비율로 구현되어 있다(`SurvivalBattleManager.cs:38,258` `HpToAtkRatio=4f`, `atk = hp / HpToAtkRatio`). **신규 정액 공격력 트랙은 이 검증된 4:1을 그대로 유도 기준으로 쓴다.**

`hero_level` power 곡선(0.22L²+0.26L)은 절대값이 150레벨 스케일이라 우리 20레벨 매판 스케일에 직접 대입 불가(매핑 SOT §0 기존 결론)하며, 곡선 형태(2차 가속)만 참고 가능하다는 점도 재확인했다 — 이번 재설계는 **4:1 유도를 주 경로로, hero_level 곡선은 형태 참고용**으로 쓴다.

---

## 3. 공격력 2층 재설계

### 3-1. 공식

```
Player.Attack = (PlayerAttack × (1 + atkRatio) + atkFlat) × Player.SkillAttackMul

  PlayerAttack = SurvivalMeta.BaseAttack + SurvivalMeta.TotalAttack()   (메타 장비, 기존 그대로)
  atkRatio     = Upgrades.Total("attack_add") + Upgrades.Total("hurt_add")   (기존 그대로)
  atkFlat      = Upgrades.Total("attack")     ← 신규
```
HP 계산식 `(PlayerHp×(1+hpRatio)+hpFlat)×SkillHpMul`과 완전히 동형이다. `RecalcPlayer()`에 `atkFlat` 한 줄, `ConsumedUpgradeKeys`(§1-2 소비 키 집합)에 `"attack"` 한 항목 추가가 코드 변경의 전부다(개발팀 반영 대상, 본 문서는 설계만).

### 3-2. 신규 정액 트랙 `attack` (Flat)

| 항목 | 현재 값 | 제안 값 | 원작 근거 |
|---|---|---|---|
| 트랙 존재 여부 | 없음 | **신설** | PD 지적 자체 — hp와의 구조 대칭 |
| Grade 1 | — | **30** | hp Flat 120 ÷ 4 (🟢확정 4:1) |
| Grade 2 | — | **90** | hp Flat 360 ÷ 4 |
| Grade 3 | — | **180** | hp Flat 720 ÷ 4 |
| Grade 4 | — | **300** | hp Flat 1200 ÷ 4 |
| Grade 5 | — | **450** | hp Flat 1800 ÷ 4 |
| Grade 6 | — | **600** | hp Flat 2400 ÷ 4 |
| 강화 비용 | — | **10/42/99/184/301/454**(재사용) | 원작 hero_level 골드 곡선 실측값 — 기존 트랙 전부와 동일 curve, S3 v2 §2-3 기각안1 결론 존중(곡선은 건드리지 않음) |

CSV 추가분(형식 그대로):
```
attack,공격력(고정),Flat,1,30,10
attack,공격력(고정),Flat,2,90,42
attack,공격력(고정),Flat,3,180,99
attack,공격력(고정),Flat,4,300,184
attack,공격력(고정),Flat,5,450,301
attack,공격력(고정),Flat,6,600,454
```

**세그먼트 영향**: 전 세그먼트 동일 (Survival 모드 IAP는 전투 스탯과 미연동, S3 v2 §1-2·§2-3 재확인 유효). 단 §8에서 향후 리스크로 별도 관리.

### 3-3. 배율 트랙 `attack_add` 재산정

| 항목 | 현재 값 | 제안 값 | 원작 근거 |
|---|---|---|---|
| Grade 1~6 | 0.05/0.07/0.10/0.15/0.20/0.30 | **변경 없음(안A 채택)** | §2-2 — 계열 라벨은 오귀속이나 수치 자체는 실재 원작(heroskillattr "계열10 패턴") 데이터, S3 v2 검증에 이미 노출된 형태 |
| 코드 주석 | "attack_add 원작 그대로" | **"heroskillattr 계열10 패턴 차용 — attack_add 고유 계열 아님"으로 정정** | §2-2 신규 발견 반영 (허위 출처 표기 정정, C5) |

**세그먼트 영향**: 전 세그먼트 동일. 값 자체가 바뀌지 않으므로 과금 세그먼트 간 영향 차등 없음.

---

## 4. 몬스터 재설계 판단

### 4-1. 4:1 비율 — 변경 불필요 (🟢확정)

몬스터 공격력은 이미 `atk = hp / HpToAtkRatio`(4:1)로 정확히 구현돼 있다(§2-3). 본 재설계는 이 메커니즘 자체를 건드리지 않는다.

### 4-2. EnemyBaseHp(42) 등 — 유지 권고

핵심 근거: **S3 v2가 검증한 모든 체크포인트(무개입 하한 22/400, 상한 69/705 — S3 v2 §14 플레이테스트 실측)는 강화 트랙 전부 0단계(미구매) 상태다.** `Total()`은 미구매 트랙에서 항상 0을 반환하므로, 신규 `attack` Flat 트랙을 추가해도 **0구매 기준선의 Player.Attack 값은 정확히 그대로다** (22와 69, 변화 없음 — §7 시나리오1로 산술 검증).

즉 원 지적 해소(무개입 웨이브2 생존 43.6~51.7%)·R-J(풀장착 웨이브2 95.5% 잔여) 등 이미 검증된 수치는 이번 재설계로 **전혀 흔들리지 않는다**. 따라서 `EnemyBaseHp=42`, `StageStep=2.1`, `WaveStep=1.04`, `BossHpMultiplier=8`은 **유지**한다.

### 4-3. 신규 발견 — 후반 "공격 몰빵" 무위협 리스크 (조정 보류, 후속 플레이테스트 이관)

신규 `attack` Flat 트랙에 골드를 몰아 쓰는 빌드는 후반 웨이브도 무력화할 수 있음을 §7 시나리오3에서 확인했다. 그러나:
1. 이 몰빵에 필요한 최소 골드(1,090G, 트랙 풀맥스)는 스테이지1 종료 시점 누적 골드(S3 v2 실측 1,148G)와 맞먹어 **스테이지2 진입 시점에야 가능**한 후반 현상이다.
2. 이미 별도로 식별된 R-J(장비 상한 무위협)·보스 급락 스파이크(S3 v2 §14) 리스크와 **같은 범주("파라미터 조정으로 해결 불가한 구조적 질문")**다 — 지금 EnemyBaseHp만 임의로 올리는 것은 근거 없는 추측성 대응(C2 proxy 위반 소지)이다.

**권고**: 신규 트랙 반영 후 "공격 특화(attack 축 몰빵) 빌드"로 스테이지2~보스 구간 실측하는 후속 플레이테스트를 진행하고, 그 결과로 `EnemyBaseHp`/`StageStep` 조정 여부를 판단한다. 지금 시점에 몬스터 수치를 먼저 바꾸는 것은 데이터 없는 선제 조정이라 채택하지 않는다(C44 팩트 우선).

### 4-4. 골드·강화비용 — 변경 불필요

| 항목 | 현재 값 | 재설계 영향 | 판단 |
|---|---|---|---|
| `BaseGoldReward`/`GoldPerStage` | 14 / 3 | 없음 | **유지** — 골드 "획득"은 처치 수·골드 요율에서만 결정되며 강화 트랙 개수와 무관 |
| 강화 비용 곡선 | 10/42/99/184/301/454 | 신규 트랙에 재사용만, 곡선 자체 변경 없음 | **유지** — 원작 hero_level 골드 곡선 실측값(S3 v2 §2-3 기각안1 결론 재확인, 재론 불필요) |

---

## 5. 기각안 (C32)

| # | 검토안 | 기각 사유 |
|---|---|---|
| 1 | attack_add를 원작 인용값(1.0~5.0)의 배율 직접 해석으로 전면 교체 | §2-1 — quality1(뽑기확률 55%)이 곧바로 공격력 2배가 되어 전체 밸런스 붕괴. 단위 확정도 안 된 상태에서 가장 파괴적인 해석을 채택하는 것은 근거 없는 확대해석 |
| 2(안B) | attack_add를 1.0~5.0의 퍼센트 포인트 해석(÷100 = 0.01~0.06)으로 축소 채택 | §5-3 — 이미 검증된 S3 v2 수치를 근거 약한 추정(🔴재추출필요 단계)으로 대체하는 것은 리스크 대비 이득 불명확. 매핑 SOT §4의 기존 attack_add 5%/7%/9% 선례와도 스케일이 5배 이상 벌어져 내부 일관성이 오히려 낮아짐. 안A(현상유지+라벨정정) 대비 우위 없음 |
| 3 | 신규 `attack` Flat 값을 hero_level power 곡선(0.22L²+0.26L)에서 직접 유도 | §2-3 — 절대값이 150레벨 스케일이라 20레벨 매판 규모에 그대로 대입 불가(매핑 SOT §0 기존 결론). 4:1 유도가 이미 우리 스케일(hp Flat)에 맞춰진 값이라 더 안전 |
| 4 | 신규 트랙 도입에 맞춰 EnemyBaseHp를 선제적으로 상향 조정 | §4-3 — 실제 영향은 후반부 몰빵 빌드에 한정되고 아직 플레이테스트 미실측. 데이터 없는 선제 조정은 C2 proxy·C44 팩트 우선 위반 소지. 후속 플레이테스트로 이관 |
| 5 | hp_add·attack_speed_add·hurt_add 등 나머지 11개 트랙도 이번 기회에 원본 재대조 | 과제 범위는 공격력 2층 복원으로 한정(PD 지시). 동일 유형 의심(§2-2 부수 발견)은 있으나 전면 재감사는 별건 상정이 맞다(C48 불필요한 범위 확장 배제) |

---

## 6. 성장 곡선 — 단계별 합산 Player.Attack

`attack_add`(배율)와 `attack`(정액)을 **동시에 같은 등급까지** 구매했다고 가정한 합산 곡선(참고용, hurt_add 미포함):

| 등급 | Flat 누적 | Ratio 누적 | Attack @ 메타하한(22) | Attack @ 메타상한(69) |
|---|---|---|---|---|
| 0 (미구매) | 0 | 0 | **22** | **69** |
| 1 | 30 | 0.05 | 53.1 | 102.5 |
| 2 | 120 | 0.12 | 144.6 | 197.3 |
| 3 | 300 | 0.22 | 326.8 | 384.2 |
| 4 | 600 | 0.37 | 630.1 | 694.5 |
| 5 | 1,050 | 0.57 | 1,084.5 | 1,158.3 |
| 6 (풀맥스) | 1,650 | 0.87 | 1,691.1 | 1,779.0 |

**곡선 해석**: 등급이 오를수록 정액(Flat) 기여가 배율(Ratio) 기여를 압도한다 — 메타 베이스(22~69)가 작아 배율의 절대 기여분이 미미하기 때문이다. 이는 **기존 hp/hp_add 쌍이 이미 갖고 있던 동일한 패턴**(hp Flat 최대 2,400·6,600누적이 hp_add 배율보다 압도적)을 공격력에 대칭 이식한 결과이며, 본 재설계가 새로 만든 불균형이 아니다. 다만 이 때문에 "배율 트랙이 사실상 트랩 옵션이 되는" 현상은 §9 리스크로 명시한다.

---

## 7. 검증 시나리오

| # | 시나리오 | 통과 기준 | 결과 |
|---|---|---|---|
| 1 | 기준선 무결성 — 메타 하한(22/400), 전 트랙 0단계(신규 `attack` 포함) | Player.Attack = 22, S3 v2 43.6~51.7% 잔여 불변 | **통과** — atkFlat=0이므로 산술적으로 22 그대로 (§4-2) |
| 2 | 저메타 구간 Flat vs Ratio 동일 지출(151G, grade1~3) 효율 비교 | 참고치(강제 기준 없음) | Flat 채택 시 Attack=322, Ratio(attack_add만) 채택 시 Attack=26.84 — 동일 골드 대비 **약 12배 격차**. §9 리스크 반영 |
| 3 | 후반 공격 몰빵 — `attack` Flat 풀맥스(1,090G) 단독, 스테이지2 웨이브1(HP 88.2) 조우 | 참고치 | TTK ≈ 0.037초(사실상 즉사). 몰빵 소요 골드(1,090G)는 스테이지1 종료 누적치(1,148G)로 도달 가능 시점 확인 — §4-3 후속 플레이테스트 대상 |
| 4 | 4:1 정합성 검산 — `attack` Flat과 `hp` Flat 양쪽 풀맥스 | 누적비 정확히 4:1 | **통과** — 6,600(hp) ÷ 1,650(attack) = 4.0 정확 일치. 단 메타 베이스(22:400=1:18.2)·장비합산(47:305=1:6.5)은 4:1과 무관한 기존 설계로 범위 외(§9 별건 기록) |

---

## 8. 세그먼트 영향 총괄

| 세그먼트 | 현재 영향 | 향후 리스크 |
|---|---|---|
| 무과금 | 없음 (구조·수치 모두 세그먼트 무관) | 없음 |
| 소과금 | 없음 | 없음 |
| 고과금 | 없음 (Survival IAP 미연동, S3 v2 §1-2 재확인) | 🟡추정 — 상점 실화폐 슬롯이 결선되고 그 재화가 인게임 골드 획득에 연동되면, 고과금 유저가 신규 `attack` Flat 몰빵(§4-3, §7-3)에 더 빨리 도달해 후반 무위협 구간에 조기 진입할 수 있음. 현재는 연동 자체가 없어 이론상 리스크 |

---

## 9. 리스크

| ID | 리스크 | 심각도 | 내용 |
|---|---|---|---|
| R-M1(신규) | 배율 트랙의 트랩 옵션화 | 중간 | §6 — `attack_add`(신규 `attack`과 동일 예산 경쟁)가 저메타 구간에서 항상 열위. `hp`/`hp_add` 쌍에도 이미 존재하는 기존 패턴이나, 이번에 공격력까지 대칭화되며 12트랙 중 2개(`attack_add`,`hp_add`)가 사실상 유인력을 잃을 소지. 전체 트랙 상대 효율 재점검은 별건(기각안 5) |
| R-M2(신규) | 후반 공격 몰빵 무위협 | 중간 | §4-3·§7-3 — R-J(장비 상한 무위협)와 동일 계열의 신규 사례. 파라미터 단독 조정 불가, 후속 플레이테스트로 실측 후 판단 필요 |
| R-M3(신규) | attack_add 원본 단위 미확정 | 낮음(정보성) | §2-1 — 🔴재추출필요 상태로 남음. 안A 채택으로 당장 리스크는 없으나, PD가 "그대로 이식" 문언의 완전한 충족을 요구할 경우 APK 재추출이 최종적으로 필요 |
| R-M4(신규) | hurt_add·attack_speed_add도 동일 오귀속 의심 | 낮음(정보성) | §2-2 부수 발견 — 같은 0.05~0.30 수열을 재사용 중. 본 문서 범위 밖(기각안 5), 전면 재감사 별건 상정 권고 |
| R-M5(신규) | 메타 레이어 자체가 4:1 비율 미준수 | 낮음(정보성) | §7-4 — `SurvivalMeta.BaseAttack/BaseHp`(22:400)·장비 합산(47:305)은 4:1과 무관. 이미 "개발 임시값"으로 별도 플래그된 영역(2026-08-21 대화로그 §8)이라 본 재설계 범위 밖으로 유지, 밸런스 후속 작업 시 함께 검토 권고 |

---

## 10. 변경 이력 (P16)

| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 |
|---|---|---|---|---|---|
| 2026-08-22 | balance-designer | 문서 최초 작성 | (없음) | 본 문서 전체 | PD 직접 승인 "이 방향으로 재구현해" — 공격력 2층 구조 이탈 재설계 |
| 2026-08-22 | balance-designer | 신규 정액 트랙 `attack` 설계 | 없음(구조 결손) | 30/90/180/300/450/600, 비용 10/42/99/184/301/454 재사용 | hp Flat ÷ 4(4:1 확정 비율) 유도, hp/hp_add 대칭 구조 복원 |
| 2026-08-22 | balance-designer | `attack_add` 배율 값 | 0.05/0.07/0.10/0.15/0.20/0.30 | **변경 없음**(라벨만 정정) | 계열 오귀속 확인(안A 채택, 안B 기각) — S3 v2 검증 리스크 없음 |
| 2026-08-22 | balance-designer | `EnemyBaseHp` 등 몬스터 상수 | 42 등 | **변경 없음** | 0구매 기준선 불변 확인, 후반 리스크는 후속 플레이테스트 이관 |

---

## 11. 후속 조치 (본 문서 범위 밖)

1. **개발팀 코드 반영**(팀장급 검토 후): `SurvivalUpgrade.csv`에 `attack` Flat 6행 추가 + `RecalcPlayer()` 1줄 수정(`atkFlat` 항 추가) + `ConsumedUpgradeKeys`에 `"attack"` 추가 + `SurvivalUIController.cs` 상점 탭에 신규 슬롯 노출(자동 파생 구조이므로 트랙 추가만으로 노출될 가능성 높음, 확인 필요) + 코드 주석 출처 표기 정정(§3-3).
2. **후속 플레이테스트**(개발팀장 위임 권고): 신규 트랙 반영 후 "공격 특화 몰빵" 빌드로 스테이지2~보스(웨이브10) 구간 실측 → `EnemyBaseHp`/`StageStep` 추가 조정 필요 여부 판단(§4-3).
3. **PD 확인 필요**: attack_add 원본 단위(§2-1) 100% 확정을 위한 APK 재추출 진행 여부 — 안A(현상유지)로 당장 기능상 문제는 없으나 "그대로 이식" 문언의 완전한 충족 여부는 PD 판단 영역.
4. **별건 상정 권고**: hurt_add·attack_speed_add 동일 오귀속 의심(R-M4) 및 전체 트랙 상대 효율(R-M1) 재점검 — 본 과제 범위 밖.

---

## 12. plan-auditor 검증 반영 (2026-08-22) — C5 출처 정정 + PD 결정

> **본 v1은 재추출 전 잠정안.** plan-auditor 조건부 통과. 정액 트랙은 확정, 배율은 재추출 후 재산정으로 대체 예정.

**C5 출처 정정 (검증 지적 5건)**:
- 본 문서·요약이 인용한 **"S3 v2 §14"는 오인용** — S3 v2 문서는 §8까지. 실제 출처는 **플레이테스트 대화로그** `2026-08-21.md §14`. 인용치(웨이브2 43.6~51.7%·상한 95.5%·스테이지1 1,148G)는 S3 v2 설계문서가 아니라 플레이테스트 실측치.
- **"라벨 오귀속 🟢확정" → 🟡추정** — 근거인 매핑 SOT가 자기모순(§4가 attack% 스킬을 attack_add에 귀속). 현 %가 원작 attack_add 정합인지 자체가 미확정.
- **S3 v2 불변 결론은 유효** (0단계 트랙 `Total()`=0 논리) — 단 위 인용 출처만 정정.

**PD 결정 (2026-08-22 AskUserQuestion)**: **"재추출로 전체 원작 정합"**.
- 정액 트랙 `attack` = **확정 구현** (본 문서 §3 유지)
- 배율 `attack_add` 및 유사 트랙(공속·피해증가·**치명타피해** — 검증서 최소 3종 동일수열)은 **APK 재추출 원본 기준 전체 재산정**으로 대체 → 후속 `2026-08-22_원작배율_재추출_원본_v1.md`(개발팀장 재추출) + 배율 재산정 v2(balance-designer)
- 몬스터는 재추출 배율 결과에 따라 재조정 폭 결정 (본 문서 §4 "유지"는 잠정)