docs(BT13-GodDem): 인게임·메타·밸런스 5차 일괄 집행 기록 — A10 완결·상점/Hero 결선·결함 4종 해소·S3 v2 확정 반영 (C49 이중 검증 사이클) + BT14-Org 완료 이관

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

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

@@ -0,0 +1,289 @@
+# 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 동기화 처리 필요.

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

@@ -0,0 +1,238 @@
+# GodDem SurvivalBattle S3 밸런스 정밀 조정안 v2 (재산출)
+
+> **작성**: balance-designer(기획팀) 2026-08-21 · **근거**: plan-auditor 반려 3건 해소(C49 재상정) · PD 원승인 "전부 진행해"(2026-08-21) 유효
+> **성격**: v1 **대체 아님 — 증보**. v1 전체 본문은 그대로 유효하며, 본 문서는 반려 3건에 해당하는 **변경분만** 다룬다. v1 미변경 섹션(§4 스킬 정규화 전반·§5 A10·§7 EXP 페이싱)은 본 문서에서 재인용하지 않으므로 반드시 v1과 함께 볼 것.
+> **v1**: [`2026-08-21_S3_밸런스_조정안_v1.md`](./2026-08-21_S3_밸런스_조정안_v1.md)
+> **절대 제약**: 본 문서가 유일 산출물. GodDem 레포(`E:\NerdNavis\GodDem`)는 Read만 수행, 수정 0건 (v1과 동일).
+> **중요 고지 — 세션 중 동시편집 확인**: 본 작업 도중 `git status`로 GodDem 레포에 **5개 파일 미커밋 변경**(개발팀장 4차 반영, 동시 진행 세션)을 확인했다 — `SurvivalBattleManager.cs`·`SurvivalMeta.cs`·`SurvivalProjectile.cs`·`SurvivalUIController.cs`·`SurvivalBattle.unity`. 아래 실측은 **이 변경이 이미 반영된 현재 워킹트리 상태**를 기준으로 하며, git diff로 변경분을 직접 대조 확인했다(v1의 Critical 원인이 된 "Read 시점 경합"의 재발 방지). **단, 미커밋 상태이므로 해당 세션이 커밋하지 않고 되돌리면 아래 "확인 완료" 항목이 무효화될 수 있음 — 개발팀장 커밋 후 재확인 권고.**
+
+---
+
+## 0. 반려 3건 요약 (재상정 사유)
+
+| # | 반려 항목 | 심각도 | v1의 결함 |
+|---|---|---|---|
+| 1 | 메타 장비 가산 전제 누락 | Critical | `ApplyMetaEquipment()`(커밋 `57a8fcf`)가 시작 스탯에 장비 능력치를 가산하는데, v1은 "IAP·메타 재화 연동 0건"으로 오판(§0) — 3차 미커밋 작업분과 Read 시점이 겹친 경합 |
+| 2 | 골드 경제 미검토 | Major | `EnemyCountPerWave` 2→1은 적 처치 수를 줄여 골드 획득도 줄이는데, 설계 앵커("20웨이브 약 460마리≈4,600G→12종 중 4종 만렙")와의 정합을 검토하지 않음 |
+| 3 | 도달 시차 미반영 | Major | 3장 생존모델이 "전원 t=0 즉시 근접·지속공격"을 가정 — 스폰~사거리 도달 시간(무피해 구간)을 반영하지 않아 잔여 HP 과소계상 |
+
+---
+
+## 1. Critical 해소 — 메타 장비 2케이스 밴드
+
+### 1-1. 실측 (코드 인용)
+
+`SurvivalBattleManager.cs` (현재 워킹트리, 이중 SOT 해소 반영 후):
+```csharp
+void ApplyMetaEquipment()
+{
+    PlayerAttack = SurvivalMeta.BaseAttack + SurvivalMeta.TotalAttack();   // Base 22
+    PlayerHp     = SurvivalMeta.BaseHp     + SurvivalMeta.TotalHp();       // Base 400
+}
+```
+`Start()`에서 `ApplyMetaEquipment()` → `SpawnPlayer()` → `RecalcPlayer()` 순서로 호출되며, 레벨1·강화0단계 시점엔 `RecalcPlayer`의 배율(`atkRatio`·`hpRatio` 등)이 전부 0이므로 **웨이브1~2 실효 스탯 = ApplyMetaEquipment 결과값 그대로**다(추가 배율 없음, 직접 확인).
+
+`SurvivalItemCatalog.cs` 9종(6부위) 실측 — **개발 임시값 명시 상태**("신규 장비·수치 밸런싱은 기획팀 후속 영역이다", 코드 주석):
+
+| 부위 | 하위 등급 | 상위 등급(합성 결과) | 슬롯 최댓값 채택 |
+|---|---|---|---|
+| 무기 | 낡은 검 6atk | 강철 검 14atk | 14atk (상위가 양축 모두 우위) |
+| 모자 | 마법사 모자 3atk/55hp(유일) | — | 3atk/55hp |
+| 반지 | 힘의 반지 8atk | 보석 반지 20atk | 20atk |
+| 신발 | 신속의 부츠 0atk/40hp(유일) | — | 0atk/40hp |
+| 갑옷 | 사슬 갑옷 0atk/90hp(유일) | — | 0atk/90hp |
+| 부적 | 번개 부적 5atk/25hp | 용의 보물함 10atk/120hp | 10atk/120hp(양축 모두 우위) |
+| **합계** | | | **+47atk / +305hp** |
+
+### 1-2. 밴드 확정 — 대화로그 기재치와의 차이 명시
+
+| 케이스 | Attack | HP | 근거 |
+|---|---|---|---|
+| **하한 (미장착)** | 22 | 400 | `TotalAttack()/TotalHp()=0` — Equipped 전 슬롯 0 |
+| **개발팀장 실측 예시** (대화로그 §8, 2026-08-21) | 52 | 610 | 특정 장착 조합(무기만 상위 등급, 반지·부적은 하위 등급) — **카탈로그 최댓값이 아닌 진행 도중 스냅샷** |
+| **상한 (풀장착 최댓값, 본 문서 채택)** | **69** | **705** | 슬롯별 상위 등급 완전 합성(1-1표) — 현재 카탈로그가 허용하는 이론적 최댓값 |
+
+**기각안**: 대화로그의 "52/610"을 그대로 밴드 상한으로 채택 — 기각. 사유: 반지·부적을 상위 등급으로 합성한 조합이 두 스탯 모두 엄격히 더 크므로(20>8, 120>25 등) 도달 가능한 실제 최댓값이 아니다. 밴드 상한은 "안전마진을 과소평가하지 않는" 방향으로 실제 도달 가능한 최댓값을 써야 하므로 69/705를 채택하고, 52/610은 "중간 진행 예시"로 별도 병기한다.
+
+### 1-3. 밴드별 웨이브1~2 재계산 (제안값 EnemyBaseHp 42·EnemyCountPerWave 1 적용, 시차 미반영 기존 비관적 모델 기준)
+
+| 케이스 | PlayerDPS | 웨이브1 잔여 | 웨이브2 잔여(누적) |
+|---|---|---|---|
+| 하한(22/400) | 31.4 | 283.1 (**70.8%**) | 93.6 (**23.4%**) — v1과 동일 |
+| 상한(69/705) | 98.6 | 667.7 (**94.7%**) | 607.3 (**86.1%**) |
+
+**세그먼트 영향**: 현재는 전 세그먼트 동일(IAP 미연동, v1 §0 유지). 단 상점 실화폐 슬롯(젬 팩)이 결선되면 고과금 유저가 풀장착 상한(69/705)에 더 빨리 도달해 웨이브1~2 무위협 구간에 더 일찍 진입하는 파급이 예상된다(**추정, IAP 결선 후 재분석 필요**).
+
+→ 상한 케이스는 비관적 모델에서조차 86.1% 잔여로 **위협이 사실상 소멸**한다. 이는 §4(도달 시차)에서 더 심화되므로 종합 판정은 §4-3에서 다룬다.
+
+---
+
+## 2. Major 해소 — 골드 경제 재설계
+
+### 2-1. 설계 앵커의 실체 검증
+
+`SurvivalBattleManager.cs:41~44` 주석(불변): *"20웨이브 약 460마리 ≈ 4,600골드 → 12종 중 4종 정도 만렙"*.
+
+이 "460마리"를 역산하면 **Σ(w=1→20) [4+(w-1)×2] = 460** — 즉 **보스 웨이브 희석(10·20웨이브는 count=1)과 스테이지 리셋을 반영하지 않은 산술급수 근사**임이 확인된다(실측). 보스 희석·스테이지 리셋을 반영한 **정밀 재계산**(waveInStage 산식 확인 반영 — §2-2)은 다음과 같다.
+
+| 항목 | 근사(주석의 방식) | 정밀(실측, boss 희석+waveInStage 반영) |
+|---|---|---|
+| 20웨이브 총 처치 수(EnemyCountPerWave=2) | 460 | **218** |
+| 20웨이브 총 골드(BaseGoldReward10+GoldPerStage2 그대로) | 4,600 | **2,596** (≈2.38/12 트랙) |
+
+→ **개발자 주석의 "4,600G/4트랙" 자체가 실제 코드 동작보다 약 1.77배 부풀려진 근사치**다 — 이는 EnemyCountPerWave 변경과 무관하게 이미 존재하던 갭이며, 본 조정안이 만든 문제가 아니다. 따라서 앵커를 "4,600G 정확히 복원"이 아니라 **"현재 실제 동작 중인 2,596G 페이스 유지"**로 재정의한다(과잉조정 방지, C2).
+
+### 2-2. EnemyCountPerWave 1 적용 시 격차
+
+waveInStage 기준 적 수 산식은 **현재 워킹트리에 이미 반영 확인됨**(`SurvivalBattleManager.cs:252`, `int count = boss ? 1 : BaseEnemyCount + waveInStage * EnemyCountPerWave;`).
+
+| 항목 | 현재(2) | 제안(1) | 증감 |
+|---|---|---|---|
+| 스테이지1 처치(웨이브1~9) | 108 | 72 | -33% |
+| 20웨이브(2스테이지) 총 처치 | 218 | 146 | -33% |
+| 20웨이브 총 골드(현행 요율 10/+2) | 2,596G | **1,804G** | **-30.5%** |
+
+### 2-3. 보상안 — 골드 요율 조정 (앵커 유지)
+
+| 항목 | 현재 값 | 제안 값 | 근거 |
+|---|---|---|---|
+| `BaseGoldReward` | 10 | **14** | 목표: 1,804G(제안 적수) → 2,596G(현재 실동작 페이스) 복원. 배율 2596/1804=1.439 → 10×1.439≈14 |
+| `GoldPerStage` | 2 | **3** | 동일 배율 적용(2×1.439≈2.9→3) |
+| → 재계산 결과 | — | **2,542G**(≈2.33/12 트랙) | 목표(2,596G) 대비 -2.1% — 오차범위 내 |
+
+> 유의 (plan-auditor 재검증 Minor): 총액 앵커는 유지되나 **분포가 초반으로 이동** — 웨이브1 골드 40→56(+40%)·웨이브2 +16.7%, 웨이브4 부근 교차 역전. 초반 강화 속도 가속은 R-J(풀장착 무위협)와 같은 방향의 가산 요인 — 플레이테스트 시 관찰 항목.
+
+**세그먼트 영향**: 전 세그먼트 동일(IAP 미연동, §1-2 동일 고지).
+
+**기각안 1**: 강화 비용 곡선(10/42/99/184/301/454)을 인하해 앵커를 맞추는 방안 — 기각. 사유: 이 곡선은 "원작 hero_level 골드 곡선 실측값 그대로" 이식된 것(`SurvivalUpgrade.cs` 주석)으로, 원작 정합성이라는 별도 설계 가치가 있다. 골드 획득 쪽(플레이어 손에 들어오는 수치)을 조정하는 편이 원작 이식 자산을 건드리지 않아 리스크가 낮다.
+
+**기각안 2**: 개발자 주석의 "4,600G/4트랙"을 문자 그대로 복원(배율 2.42배, BaseGoldReward→24 수준) — 기각. 사유: §2-1에서 확인했듯 그 수치 자체가 부풀려진 근사치였다. 실제로 필요한 보정은 "내 제안이 깎은 -30.5%"만이며, "주석과 실제 구현의 기존 괴리(-44%)"까지 이번 조정에서 함께 메우는 것은 범위를 벗어난 과잉조정(C2)이다. 후자는 별도 항목(§6 Minor 4)으로 분리해 주석 정정만 권고한다.
+
+---
+
+## 3. Major 해소 — 도달 시차 반영
+
+### 3-1. 상수 재확인
+
+| 상수 | 값 | 출처 |
+|---|---|---|
+| SpawnRadius | 4 (가로축 ×0.55) | `SurvivalBattleManager.cs:29`, `SpawnWave()` 스폰 좌표식 |
+| EnemyMoveSpeed | 1.1 | 동 파일:40, 씬 직렬화 동일값 재확인 |
+| 적 공격 사거리 | 1.3 (하드코딩) | `unit.Init(hp, atk, 1.2f, 1.3f, EnemyMoveSpeed)` |
+| 적 공격 쿨다운 | 1.2 (하드코딩) | 동일 라인 |
+| 플레이어 공격 사거리 | 3.2 | `PlayerAttackRange` |
+| 플레이어 공격 쿨다운 | 0.7 | `PlayerAttackCooldown` |
+
+스폰 지점~원점(플레이어) 거리는 타원 파라미터상 **2.2(근거리 축)~4.0(원거리 축)** 범위.
+
+### 3-2. 정밀 도달 시각 — 쿨다운 게이트 보정 (신규 발견)
+
+`SurvivalUnit.cs` `FixedUpdate()` 확인 결과, 공격 타이머(`_timer`)는 **유닛 스폰 시점부터 무조건 누적**되며(사거리 진입 여부와 무관), 최초 공격은 `_timer >= AttackCooldown`이 될 때만 발생한다. 즉 최초 공격 시각 = **max(사거리 도달 시간, 자신의 공격 쿨다운)**이다 — 이동 시간만으로 근거리를 계산한 과제 지시치(0.8초)보다 실제로는 다소 늦다.
+
+| 구분 | 이동 시간만 | **쿨다운 게이트 보정(채택)** |
+|---|---|---|
+| 적 근거리 최초 피격 | (4.0−1.3)/1.1=2.45초* → 정정: 근거리 스폰은 2.2−1.3=0.9,0.9/1.1=0.82초 | max(0.82, 쿨다운1.2) = **1.2초** (쿨다운이 이동보다 늦게 걸림) |
+| 적 원거리 최초 피격 | (4.0−1.3)/1.1=2.45초 | max(2.45, 1.2) = **2.45초 ≈ 2.5초** (이동이 쿨다운보다 늦음, 과제 지시치와 일치) |
+| 플레이어 최초 공격(웨이브1, 타이머 리셋 직후) | 근거리 스폰은 즉시 사거리 내(2.2<3.2) | max(0, 쿨다운0.7) = **0.7초** |
+| 플레이어 최초 공격(웨이브2+) | 전멸 대기 + WaveInterval(1.5초) 동안 `_timer`가 쿨다운을 이미 초과 상태로 유지 | **≈0초**(사실상 즉시, 도달한 순간 공격) |
+
+→ 근거리 지시치는 "0.8초"가 아니라 **쿨다운에 걸려 1.2초**가 정확한 값이다(이동만으로는 0.82초에 사거리 진입하지만 아직 쿨다운이 안 돌아 공격 못 함). 원거리는 지시치(2.5초)와 일치.
+
+### 3-3. 밴드별 재계산 — 2×2 매트릭스 (장비 × 시차)
+
+방법: N마리를 "근거리 일괄 도착(1.2초)" / "원거리 일괄 도착(2.45초)"의 두 경계로 근사(과제 지시 방식과 동일 구조) + 위 쿨다운 보정 적용. 순차처치 사망시각 `t_k = t_p + k·T_kill`(T_kill=적HP/플레이어DPS)에서 각 적의 공격구간 = `max(0, t_k − t_e)`.
+
+| 장비 케이스 | 시차 가정 | 웨이브1 잔여 | 웨이브2 잔여(누적) |
+|---|---|---|---|
+| 하한(22/400) | **없음(v1 비관 모델, 하한 참고용)** | 70.8% | **23.4%** |
+| 하한(22/400) | 근거리(1.2초) | 75.2% | **41.4%** |
+| 하한(22/400) | 원거리(2.45초) | 85.2% | **63.3%** |
+| 상한(69/705) | 없음(비관 모델) | 94.7% | 86.1% |
+| 상한(69/705) | 근거리(1.2초) | 97.1% | 94.9% |
+| 상한(69/705) | 원거리(2.45초) | 100% | 100% |
+
+### 3-4. 목표 밴드(15~35%) 재판정
+
+**판정: 조건부 유지 — "최악 하한 보장"으로는 성립, "평균 체감"으로는 불성립.**
+
+- 목표1의 핵심("죽는 경험 제거")은 **모든 케이스에서 사망 0건**으로 강하게 충족된다.
+- 15~35% 밴드는 **비관적 하한선(스폰 클러스터링 등 최악의 불운)에서만** 성립(23.4%). 시차를 반영한 현실적 모델은 하한장비 기준으로도 **41.4~63.3%**로 밴드 상단(35%)을 상회하고, 장비 상한 기준으로는 86~100%로 위협이 사실상 없다.
+- 즉 15~35%는 "항상 이 범위에 들어온다"가 아니라 **"최악의 경우에도 이 범위 아래로 안 떨어진다(=죽지 않는다)"는 안전 하한 지표**로 재해석해야 한다. "평균적으로 위협을 느끼는" 체감은 스폰 클러스터링 등 **불운 시행에서만** 발생하는 구조이며, 이는 v1 §8이 이미 지적한 **"동일 코드에서 결과가 극단적으로 갈리는" 편차 문제**와 같은 뿌리다.
+
+**권고**: `EnemyBaseHp 42 / EnemyCountPerWave 1`은 **그대로 유지**한다(추가 너프 반대). 이유:
+1. 이미 모든 밴드에서 사망 위험이 0이므로 목표1(최우선)을 견고하게 만족.
+2. "평균 체감을 15~35%에 맞추려는" 추가 너프는 최악 하한(현재 23.4%)을 더 낮춰 목표1(사망 방지)을 다시 위협한다 — 죽는 경험 재발이 "가끔 안전한 느낌"보다 더 나쁜 실패 모드다.
+3. 체감 편차 문제의 올바른 해법은 **수치 재조정이 아니라 v1 §8의 편차 완화안**(웨이브1 스폰 그레이스, 방어 패시브 카탈로그 신설)이다 — 이미 제안되어 있고 반려 대상도 아니었다.
+
+**신규 리스크**(장비 상한 관련, §1과 연결): 풀장착 유저는 시차를 반영하지 않아도 86.1%, 반영하면 94.9~100% — 웨이브1~2가 사실상 완전 무위협이다. 이는 파라미터 미세조정으로 해결 불가능한 **구조적 질문**(초반 웨이브를 장비 수준에 따라 스케일할지 여부)이며, 본 조정 범위 밖의 별도 설계 결정이 필요하다(§7 리스크 R-J).
+
+**기각안**: 시차를 몬테카를로 수준으로 정밀 시뮬레이션(적별 개별 스폰각·이동 스태거링 전부 반영) — 기각. 사유: 과제 지시 자체가 근거리/원거리 2-경계 밴드를 요청했고, 이는 v1의 장비 2케이스 구조와 동형이라 문서 일관성이 높다. 완전 시뮬레이션은 §10 검증 시나리오3처럼 "플레이테스트 전용" 영역으로 남긴다(과잉정밀 방지, C14).
+
+---
+
+## 4. Minor 정정 3건 + 부수 확인 1건
+
+| # | 항목 | 정정 내용 |
+|---|---|---|
+| 1 | R-E 조건 표현 | v1 "speed≥1이면 항상 무시"는 부정확 — `Mathf.Max(MaxRange, speed×6)`은 **speed>1일 때만**(등호에서는 동률이라 실질적 override 없음) 자산값을 이긴다. **+추가 확인: 코드 자체가 이미 수정 완료**(`SurvivalProjectile.cs`, 워킹트리 확인) — override 로직 삭제, 자산 `MaxRange` 직접 사용. R-E는 더 이상 활성 결함이 아니다. |
+| 2 | A13 명칭 | 자산 `DisplayName`="저주 구체"(유니코드 실측 확인), `EnglishName`="Cursed Orb". 파일명 `A13_cheondoongbal.asset`은 내부 리소스명으로 유지, 문서 표기는 "A13 저주 구체(Cursed Orb)"로 통일 |
+| 3 | A13 DebuffStackLimit | 자산값 `DebuffStackLimit: 3` 보유 확인. 관통 재타격마다 `SurvivalDebuffStack.AddStack` 호출 — v1·본 문서의 DPS 수치는 이 스택 폭발분을 포함하지 않은 **순수 관통타 데미지만**의 값이다 |
+| 4(부수) | A13 이론상 DPS 갱신 | 정정 1의 R-E 수정 결과, MaxRange가 12(버그)→6(자산값)로 되며 관통 생존시간이 6초→**3초**로 반감. 재계산: 240 dmg/96 DPS(v1, 30틱 기준) → **120 dmg/48 DPS**(15틱 기준)로 갱신. 여전히 단일 표적 정적 최대치이며 스택 폭발 미포함(정정3과 동일 유보) — "실측 필요" 판정은 유지 |
+
+**부수 확인(과제 범위 외지만 직접 실측)**: `penetrate_ratio`는 **배선도 비노출 양자택일이 아니라 이미 "비노출"로 확정 반영됨**을 워킹트리에서 확인. `SurvivalBattleManager.cs`에 `ConsumedUpgradeKeys`(RecalcPlayer가 실제 소비하는 11개 키 집합, penetrate_ratio 제외) 신설 + `SurvivalUIController.cs`가 이 집합에 없는 키를 상점에서 자동 제외하도록 수정 — "골드 소모·효과 0" 함정이 구조적으로 차단됐다. 추후 배선 시 `RecalcPlayer` + `ConsumedUpgradeKeys` 양쪽에 키를 추가하면 자동 복귀하도록 self-documenting 되어 있음(코드 주석 확인).
+
+---
+
+## 5. 마스터 변경 요약 (v1 §9 갱신판 — 본 문서 신규/변경분만)
+
+| 항목 | 현재 값 | 제안 값 | 근거 | 세그먼트 영향 |
+|---|---|---|---|---|
+| `EnemyBaseHp` | 60 | **42** | v1 §3 유지 — §3-4 재판정 통과(밴드는 안전하한 지표로 재해석) | 전 세그먼트 동일 |
+| `EnemyCountPerWave` | 2 | **1** | v1 §3 유지 — 상동 | 전 세그먼트 동일 |
+| `BaseGoldReward` | 10 | **14** | §2-3 — EnemyCountPerWave 변경분(-30.5%)만 정확히 보상, 개발자 주석의 기존 과대추정(§2-1)은 별도 이슈로 분리 | 전 세그먼트 동일(IAP 미연동) |
+| `GoldPerStage` | 2 | **3** | 상동 | 전 세그먼트 동일 |
+| `PlayerHp` 2차 버퍼(440~480) | 400 | **보류 철회 권고** | v1은 "미달 시 투입"으로 보류했으나, 재계산 결과 최저 케이스도 23.4%(사망 아님)·시차 반영 시 41%+ — 버퍼 필요성 근거가 오히려 약해짐 | 전 세그먼트 동일 |
+| SpawnWave 적 수 산식 | — | (조정 아님, 확인만) | **이미 waveInStage 기준으로 반영 확인**(§2-2) | — |
+| A13 관통 사거리 override | — | (조정 아님, 확인만) | **이미 자산 MaxRange 직접 사용으로 수정 확인**(§4) | — |
+| `penetrate_ratio` | — | (조정 아님, 확인만) | **이미 상점 비노출로 확정 반영 확인**(§4 부수) | — |
+
+---
+
+## 6. 검증 시나리오 갱신 (v1 §10 대체분만)
+
+| # | 시나리오 | 통과 기준 | 결과 |
+|---|---|---|---|
+| 2 | 웨이브2 종료 위협구간(하한 장비, 시차無) | HP>0 && 15~35% | **23.4% — 통과(안전하한 지표로 재정의, §3-4)** |
+| 2b(신규) | 웨이브2 종료(하한 장비, 시차 반영) | 참고치(밴드 강제 아님) | 41.4~63.3% — 밴드 상회, §3-4 판정대로 허용 |
+| 2c(신규) | 웨이브2 종료(상한 장비, 전 조건) | 사망 0 | 86.1~100% — 통과(위협 소멸은 별도 리스크 R-J로 관리) |
+| 7(신규) | 골드 앵커 유지 | 20웨이브 시점 골드가 현재 실동작치(2,596G) 대비 ±10% 이내 | 2,542G(−2.1%) — **통과** |
+| 8(신규) | penetrate_ratio 상점 비노출 | 강화 탭(공격)에 관통 항목 미표시 | 코드 실측 통과 — **QA 최종 확인 권고**(런타임 미검증) |
+
+---
+
+## 7. 리스크 갱신 (v1 §11 추가분)
+
+| ID | 리스크 | 심각도 | 내용 |
+|---|---|---|---|
+| **R-I(갱신)** | 세그먼트 분석 — 향후 리스크로 격상 | 낮음→**정보성 갱신** | 현재는 여전히 무관하나(§1-2), 상점 실화폐 슬롯 결선 시 고과금 유저의 장비 상한 조기 도달이 예상됨(추정) |
+| **R-J(신규)** | 장비 상한 유저 웨이브1~2 무위협 | 중간 | §3-4 — 파라미터 조정으로 해결 불가. 초반 웨이브를 장비 수준에 연동할지는 별도 설계 결정(시스템 기획 영역 상의 필요) |
+| **R-K(신규)** | 골드 앵커 자체의 기존 과대추정 | 낮음(정보성) | §2-1 — 개발자 주석("4,600G")이 boss 희석·스테이지 리셋 미반영 근사치였음. **코드 변경 아님, 주석 정정만 권고**(개발팀 REQ 불요, 팀장 재량) |
+| **R-L(신규)** | 미커밋 동시편집 의존성 | 낮음(일시적) | 본 문서의 "이미 반영 확인" 3건(waveInStage·A13 MaxRange·penetrate_ratio)은 개발팀장 세션의 **미커밋 워킹트리** 기준 — 커밋 전 되돌려지면 무효화. 커밋 완료 후 재확인 권고 |
+
+---
+
+## 8. 변경 이력 (P16)
+
+| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 |
+|---|---|---|---|---|---|
+| 2026-08-21 | balance-designer | 문서 최초 작성(v2) | (v1 §9 마스터 표) | 본 문서 §0~7 | plan-auditor 반려 3건(Critical 1·Major 2) 해소 + Minor 3건 정정 (C49 재상정) |
+| 2026-08-21 | balance-designer | 메타 장비 밴드 확정 | 미검토(v1 "해당없음" 오판) | 22/400(하한)~69/705(상한), 대화로그 52/610은 중간 예시로 별도 병기 | `ApplyMetaEquipment()`·`SurvivalItemCatalog.cs` 실측(§1) |
+| 2026-08-21 | balance-designer | 골드 요율 조정 제안 | BaseGoldReward10/GoldPerStage2 | 14/3 | EnemyCountPerWave 1 적용분(-30.5%) 보상, 앵커는 실동작 페이스(2,596G) 기준 재정의(§2) |
+| 2026-08-21 | balance-designer | PlayerHp 2차 버퍼 | 보류(v1) | 철회 권고 | 재계산 결과 안전마진 충분(§3-4·§5) |
+
+---
+
+**후속 조치 (본 문서 범위 밖, 팀장급 확인 필요)**:
+1. §7 R-K(골드 주석 정정)·R-L(미커밋 확인) — 개발팀장 재량, REQ 불요.
+2. §3-4 R-J(장비 상한 무위협)는 시스템 기획 영역과 협의가 필요한 설계 질문 — plan-team-lead 상정 권고.
+3. PD 지시 로그·대화로그 동기화는 balance-designer가 별도 엔트리로 직접 기록(C13·C32, 팀장 경유 아님).

공유/대화로그/GodDem/2026-08-21.md

@@ -0,0 +1,99 @@
+# GodDem 대화로그 — 2026-08-21
+
+> 세션: BT13-GodDem 재개 (총괄PM). 신규 세션 체계 첫 적용 (session_health 자동 실측 + C14-7 스크린샷 최소화)
+
+## 1. PD 결정 — GodDem 단독 PC 운영
+
+- **PD 원문**: "BurningTimes 조직의 GodDem 프로젝트는 이 로컬 PC에서만 진행할게."
+- 두 PC 병행 종료 — 세션 끊김 요인 중 인증 충돌 축 제거 (BT14-Org 진단 연계)
+
+## 2. 작업 현황 보고 → PD 전체 승인
+
+- PM 현황 보고: 완료 누적 6건 압축 + 중단 지점(A10 분신 미커밋 10건) + 잔여 7건 + PD 결정 대기 2건
+- **PD 원문**: "좋아 전부 진행해." → 잔여 7건 승인. 결정 대기 2건(ModalDocument 정리·XOR 키 보존)은 명시 결정 전 대기 유지 (C19)
+
+## 3. 집행 구조 (P32 맥락 분할)
+
+| 맥락 | 담당 | 상태 |
+|------|------|------|
+| 1차: 인게임 완결 묶음 — A10 분신 완료·A13 피격FX·일시정지·적 HP바·Phase A 미세 이슈 | 개발팀장 (Opus 직접 — Unity 단일 인스턴스 관례) | **진행중** (백그라운드) |
+| 2차: S3 밸런스 조정안 | balance-designer | 대기 — A10 포함 10종 확정 후 착수 (병렬 시 산출물 무효화 의존성) |
+| 3차: 상점·Hero 메타 결선 (영구 메타 설계 포함) | 개발팀장 | 대기 — 1차 완료 후 |
+
+- 사전 실측: Unity 실행·MCP 연결·콘솔 에러 0·dirty 10건 변동 없음
+- 위임서에 C14-7(텍스트 실측 우선·스크린샷 최종 1회)·C39 Read 의무·churn 제외 전례 명시
+
+## 4. 1차 인게임 완결 묶음 — 완료 (GodDem `77bd835`·`ee9ec11` push 완료)
+
+- **PD 중단 의심 제기 → PM 실측**: 중단 아님 — 대형 작업(79분·도구 147회) 마무리 단계였고 보고 정상 도착. 다만 output 파일이 76분간 0바이트로 보여 구분 불가했던 관측 한계는 사실
+- **5건 전부 완료**: ①A10 분신 완결 (SurvivalClone.cs 209줄·미러링 큐·피해 반감 50%·무한 재귀 차단·Minion 디스패치 CardId 분기 — **카드 풀 10종 정합 실측**) ②A13 피격FX `FX_PinkMagicArrow_Hit` + 관통 재타격 FX 폭증 방지(최초 접촉만 스폰) ③일시정지 (Popup_Close 전용·timeScale 이중 제어 가드·버튼 y=800 이동) ④적 개별 HP바 (월드 스프라이트+정적 풀링 재량 — 42기 동시 성능·FaceTo 반전 회피 근거) ⑤보상 코인 겹침(셀 360×190 가로 배치)·SurvivalHUD.cs 삭제(참조 0 실측)
+- **개발팀장 선제 교정**: 중간 코드의 Rigidbody2D Destroy → SkeletonAnimationHandler 매 프레임 MissingReferenceException 잠재 크래시 발견·교정 (Kinematic+simulated=false)
+- **검증**: C14-7 첫 적용 — 텍스트 실측 표 8항목(미러링 큐·피해 반감·앵커 치환·HP바 정합 4==4==4·timeScale·보상 좌표) + 스크린샷 2장 (1장 초과 자진 고지 — 적 전멸로 재촬영, 텍스트 선행 확인 후)
+- **개발팀장 자진 고지**: 커밋 메시지 오기(`77bd835` "push 인증 실패" — 실제는 성공) → force push 대신 정정 커밋 `ee9ec11`. **git 원격 간헐 Authentication failed 재관측** (PM도 어제 1회 — burning.i234.me 서버 간헐 이슈 정황, 재시도 통과)
+- **한계 인계**: ①분신 미러링 A11 정령불이 플레이어에 부착 (위치 정합 원작과 다름 — 미수정) ②밸런스 편차 관측 (무개입 웨이브 2 사망 vs 웨이브 4 도달 — S3 인풋 전달) ③TMP 폰트 churn 반복 — .gitattributes 정책화 별건 권고
+
+## 5. 2차·3차 병렬 가동 (진행중)
+
+- **2차 balance-designer**: S3 조정안 문서 (자산 수정 금지·Read만). 개발팀장 편차 관측 반영 지시. 산출 예정: `공유/기획/GodDem/2026-08-21_S3_밸런스_조정안_v1.md` → 개발팀장 검증 후 반영 (C49)
+- **3차 개발팀장**: 상점·Hero 메타 결선 (영구 메타 설계 선행·기존 대전형 무오염 제1 제약) + 로비 크롬·전체 부팅 검증
+
+## 6. 2차 S3 조정안 — 완료 (balance-designer) + plan-auditor 검증 가동
+
+- **산출**: `공유/기획/GodDem/2026-08-21_S3_밸런스_조정안_v1.md` — 조정 8건 (즉시반영 2·코드변경 제안 4·보류 1·스킬 9종 현행유지 판정 1) + 리스크 9건. GodDem 수정 0건 (Read만 — 제약 준수)
+- **최우선 3건**: EnemyBaseHp 60→42 · EnemyCountPerWave 2→1 · 적수 산식 전역 Wave→스테이지 리셋(waveInStage) 기준 (코드 변경 제안). 재계산상 웨이브1 잔여 70.8%·웨이브2 잔여 23.4% — 무개입 사망 케이스 수식상 해소
+- **코드 결함 2건 실측 발견 (조정안 부산물)**: ①`penetrate_ratio` 강화가 `RecalcPlayer` 완전 미참조 — 구매 시 골드 순손실 함정 ②A13 관통이 자산 `MaxRange:6` 무시·사거리 12 강제 (`SurvivalProjectile.cs`)
+- **balance-designer 정직 고지**: 3장 생존모델 = "전원 상시 근접" 비관적 하한선 (안전마진 미정량화) · A13 DPS는 결함 수정 전 "실측 필요" 표기 유지
+- **C49 검증 단계**: plan-auditor 교차검증 가동 (수식 재계산·결함 2건 코드 라인 확정·원작 정합·P30 과보정 리스크) — 통과분만 4차 반영
+
+## 7. plan-auditor 검증 — 조건부 통과 (S3 조정안)
+
+- **통과**: 수식 재계산 전량 일치 (산술 오류 0)·코드 상수 12종 일치·결함 2건 코드 라인 확정 — ①`penetrate_ratio`는 `RecalcPlayer` 참조 0건인데 `SurvivalUIController:35`가 공격 탭에 등재 → **상점 판매 중인 무효 옵션** (1,090G 순손실, 문서 판단보다 심각) ②A13 `SurvivalProjectile.cs:55` `Max(_maxRange, _speed*6)` 관통 한정 강제 확정
+- **반려 3건 (수치 조정 보류 사유)**: [Critical] "메타 재화 연동 0건" 오판 — `ApplyMetaEquipment()`가 시작 스탯 가산 (PlayerHp 400 = 장비 미장착 하한, 3차 미커밋 작업분과 겹친 Read 시점 경합) / [Major] EnemyCountPerWave 반감 시 골드 경제 붕괴 미검토 (설계 앵커 "20웨이브 ≈4,600G" 파괴) / [Major] 도달 시차 무피해 선제딜 구간 미반영 — 잔여 HP 과소계상 → P30 긴장감 소실 리스크
+- **4차 즉시 반영 승인 3건** (수치 독립): penetrate_ratio 배선/비노출 · A13 MaxRange override 수정 · SpawnWave waveInStage 산식 교정. **반영 지점 경고**: 실 SOT = 씬 직렬화 (`SurvivalBattle.unity:532~533`) — .cs만 고치면 무효
+- **PM 판정**: EnemyBaseHp·CountPerWave 조정은 3차 완료 후 메타 확정 수치 기반 balance-designer 재산출 → 재상정. Minor 3건(R-E 조건 부정확·A13 명칭 "저주 구체" 불일치·DebuffStackLimit 미기재)은 재산출 시 동반 정정
+
+## 8. 3차 상점·Hero 메타 결선 — 완료 (GodDem `57a8fcf` push 완료)
+
+- **영구 메타 설계 판단**: `UserDataDTO` 재사용 기각 (3근거 실측 — 전체 직렬화 트랜잭션 결합 = C6 오염 리스크·18인자 생성자 NRE 표면·씬 결합) → **`SurvivalMeta` 분리 신설** (`survival_meta.json` 물리 분리·대전형 오염 경로 0·씬 수정 0). 재화만 `CurrencyManager` SOT 공유 (Phase B 성립 관계)
+- **상점**: 16칸 전부 결선 — 실동작 9칸 (데일리 딜 5·골드 팩 3·무료 젬 1, 일일 한도·잔액 반려 토스트·자정 타이머 실계산) + IAP 미연동 7칸 "준비중" 정직 표기. 실측: 한도 차단·차감·환전·실화폐 무변동
+- **Hero**: 6부위 장착·합성("동일 3→상위 1" 단순 규칙)·전체해제·부위 필터 + **인게임 반영 완결** — `ApplyMetaEquipment()` 12줄 (풀장착 공격 52/체력 610 가산·재진입 유지 실측)
+- **결함 2건 발견·수정**: ①`RefreshDaily()` lazy-load 전 참조 — 부팅 후 상점 첫 진입 100% NRE (런타임 프로브 재현·근본 수정) ②카탈로그-아이콘 의미 불일치 (스프라이트명 실측 후 부위 체계 재정의·추가 아트 0)
+- **로비 크롬**: 미구현 기능 버튼(Friends/Ranking/Clan/Quest/Gift)·더미 표시 6종 **숨김** (한글화 기각 근거 — 무반응 버튼이 구현된 것처럼 보이는 오해 방지). 활성 영문 텍스트 0 실측
+- **부팅 검증**: BaseLoading→Lobby→상점→영웅→SurvivalBattle 전 구간 — 신규 에러 0. 잔존 1건은 StreamingAssets 미동봉 baseline 404 (본 작업 이전부터 — "에러 0" 아님 정직 보고)
+- **한계 정직 보고 8건**: 이중 SOT (BaseAttack/BaseHp 사본 — 4차 해소 대상)·IAP 7칸·합성 단순 규칙·장비 강화 레벨 없음·**상품 가격·장비 수치 = 개발 임시값 (P14 미통과 — 밸런스 후속)**·자동화 테스트 없음·백업 생략 (git 이력 보존 근거)·스크린샷 3회 (1회 무효 캡처 + 결함 발견-수정-재확인, 텍스트 선행 준수)
+
+## 9. 4차 승인분 반영 + 재산출 v2 병렬 가동 (진행중)
+
+- **4차 개발팀장**: penetrate_ratio 해소 (배선 권장/비노출 대안)·A13 MaxRange 자산 SOT화·waveInStage 산식 교정 + 이중 SOT 해소 (수치 값 변경 금지 명시)
+- **재산출 balance-designer**: v2 — 메타 밴드 2케이스 (22/400~52/610)·골드 앵커 유지 연립 재설계·도달 시차 항 반영 + Minor 3건 정정
+
+## 10. 재산출 v2 — 완료 (balance-designer, plan-auditor 반려 3건 해소)
+
+- **산출**: `공유/기획/GodDem/2026-08-21_S3_밸런스_조정안_v2.md` (v1 대체 아닌 증보). GodDem 수정 0건 (Read만 — 제약 준수)
+- **세션 중 동시편집 확인 (C39 실측)**: 작업 도중 `git status`로 GodDem 5개 파일 미커밋 변경 확인(개발팀장 4차 세션과 동시 진행) — `git diff`로 직접 대조해 아래 3건이 **워킹트리에 이미 반영 완료**임을 확인: ① `SpawnWave()` 적 수 산식 waveInStage 기준 교정 완료 ② `SurvivalProjectile.cs` R-E override(`Mathf.Max(MaxRange,speed×6)`) 라인 삭제 완료(자산 MaxRange 직접 사용) ③ `penetrate_ratio` `ConsumedUpgradeKeys` 신설로 상점 자동 비노출 완료. v1 Critical 원인이던 "Read 시점 경합" 재발 방지 목적으로 명시적으로 재확인함
+- **Critical 해소 (메타 장비 밴드)**: `SurvivalItemCatalog.cs`(9종 6부위) 직접 재계산 결과, 슬롯별 최댓값 완전합성 시 **69/705**(공격+47/체력+305) — 대화로그 §8의 "실측 52/610"보다 높음. **기각안**: §8 수치를 그대로 밴드 상한 채택 — 기각(반지·부적 상위등급이 하위등급을 양축 모두 엄격 우위, 즉 §8은 카탈로그 최댓값이 아닌 특정 중간 진행 스냅샷). 밴드 상한은 69/705 채택, 52/610은 별도 병기
+- **Major 해소 (골드 경제)**: 개발자 주석 "20웨이브 약460마리≈4,600G"를 역산한 결과 boss 웨이브 희석·스테이지 리셋 미반영 산술급수 근사(정밀 재계산 시 실제 현재 동작치는 2,596G)임을 확인 — **기각안**: 주석의 4,600G를 문자 그대로 복원(BaseGoldReward→24 수준, 배율 2.42배) — 기각(과잉조정, 기존부터 있던 주석-실제 괴리까지 이번 조정 책임으로 떠안기지 않음). 채택안: EnemyCountPerWave 변경분(-30.5%)만 정확히 보상하는 BaseGoldReward 10→14·GoldPerStage 2→3 (결과 2,542G, 목표 대비 -2.1%). **기각안 2**: 강화비용 곡선 인하로 앵커 유지 — 기각(곡선은 원작 이식 자산, 골드 획득 쪽 조정이 리스크 낮음)
+- **Major 해소 (도달 시차)**: `SurvivalUnit.cs` 실측으로 신규 발견 — 공격 타이머가 스폰 시점부터 무조건 누적되어 최초 공격시각=max(사거리도달시간, 자신의 쿨다운). 근거리 지시치 0.8초는 쿨다운(1.2초)에 걸려 실제로는 1.2초로 정정. 장비×시차 2×2 매트릭스 재계산 결과 하한장비 웨이브2 잔여 41.4~63.3%(시차 미반영 시 23.4%), 상한장비는 86.1~100%. **판정: 조건부 유지** — 15~35% 밴드는 "최악 하한 보장" 지표로만 성립, "평균 체감" 지표로는 불성립. **기각안**: 평균 체감을 밴드에 맞추려 추가 너프 — 기각(최악 하한을 더 낮춰 목표1 사망방지 재위협, C2). 몬테카를로 수준 정밀 시뮬레이션 — 기각(과제 지시가 요청한 2-경계 밴드 구조로 충분, 완전 시뮬은 플레이테스트 영역)
+- **최종 채택**: EnemyBaseHp 60→42·EnemyCountPerWave 2→1 유지(반려 이전 제안 그대로 확정) + BaseGoldReward 10→14·GoldPerStage 2→3(신규) + PlayerHp 2차 버퍼(440~480) 보류 철회 권고(안전마진 이미 충분)
+- **Minor 3건 정정 + 부수 확인**: R-E 조건 "speed>1"로 정정(+코드 자체 이미 수정 완료 확인) · A13 명칭 "저주 구체(Cursed Orb)" 통일 · DebuffStackLimit:3 명기(DPS 수치에 스택폭발 미포함 사실도 병기) · 부수로 A13 이론상 DPS 240/96→120/48 갱신(R-E 수정에 따른 관통 생존시간 6→3초 반감 결과)
+- **신규 리스크**: R-J(장비 상한 유저 웨이브1~2 무위협 — 파라미터 조정 불가, 시스템 기획 협의 필요) · R-K(골드 앵커 주석 자체 과대추정, 정정만 필요) · R-L(본 확인 3건이 미커밋 워킹트리 기준 — 개발팀장 커밋 전 되돌리면 무효화 가능)
+- **C49 후속**: plan-auditor 재검증 대상 — 팀장급(plan-team-lead 또는 PM) 상정 권고. R-J는 시스템 기획 협의 별도 상정 필요
+
+## 11. 4차 승인분 반영 — 완료 (GodDem `7728a41` push 완료, dev-auditor 조건부 승인·전건 반영)
+
+- **#1 penetrate_ratio — (b) 비노출 채택 (지시 권장 (a) 배선의 실측 반증)**: 적은 `Init()`에서 `DamageReduction`을 설정받지 않아 **전 판 내내 0** — 관통 배선 시 `0×(1-pen)=0`으로 현행과 완전 동일 (no-op proxy). **근본 원인 = 상점 탭 키·RecalcPlayer 소비 목록의 손관리 2중 구조** → `ConsumedUpgradeKeys` 단일 선언 신설·상점 노출 파생화 (배선되는 날 집합 추가만으로 자동 복귀). **기각안 3건**: ①매니저 참조 (아웃게임 읽기 불가) ②상수를 직렬화 초기값으로 (씬이 덮어 3중 SOT 잔존) ③ScriptableObject/CSV 공통 참조 (유일 완전안이나 범위 초과 — 보류·승격 조건부)
+- **#2 A13 클램프 완전 제거**: `git log -L` 실측 — `0e06942` 도입 의도 "관통 충분 전진"은 6초 수명의 거리 오표현. 전 자산 speed≥1이라 자산값 영구 사장 구조. 스폰 반경 4 < 자산 사거리 6이라 원 의도도 자산값으로 충족. 사거리 12→6
+- **#3 waveInStage 산식 통일**: W11 24→4·W19 40→20·W21 44→4 / W1·W5·W9 무변화 실측
+- **#4 이중 SOT 소멸**: `PlayerHp/PlayerAttack` 비직렬화 프로퍼티 전환 + 씬 고아 2줄 제거. `const` 아닌 `static readonly` (참조 어셈블리 인라인 복사 재발 경로 차단 — dev-auditor Minor 수용)
+- **실측 검증**: 컴파일 error 0/warning 0·사장 키 penetrate_ratio 단독·정상 키 손실 0·기본 스탯 22/400 무변경·씬 재임포트 오류 0
+- **한계**: Play 모드 미실행·`ConsumedUpgradeKeys` 역방향 미검출 (EditMode 테스트 후속)·`ValidateUpgradeCoverage` 상시 경고 (의도된 표면화)
+- **기획팀 통지 필요 (dev-auditor Major 조건)**: `BaseHp/BaseAttack` Inspector 편집성 소멸 — 이 2종 튜닝은 **기획팀 단독 반영 불가·개발팀 REQ 경유**로 전환. 기획팀이 직접 튜닝 요구 시 기각안 ③(SO/CSV) 승격 조건 명시
+- **git 인증 간헐 실패 3회째** (PM 1·개발팀장 1차 1·4차 1 — 전부 재시도 통과): GCM 자격증명 갱신 이슈 정황. 재발 시 별도 진단 안건
+
+## 12. v2 재검증 통과 + 5차 수치 반영 — 완료 (GodDem `d5dea4d` push 완료) · 본 흐름 마감
+
+- **plan-auditor 재검증**: **통과** (Critical 0·Major 0·Minor 4). 메타 밴드 69/705 정확·골드 역산 오차 0 (2,596/1,804/2,542 검산 일치)·도달 시차 2×2 전수 재계산 일치·A13 DPS 120/48 정합·R-L 해소 (`7728a41` 커밋 확인)
+- **5차 PM 직접 집행** (C48 — 기계적 수치 치환): EnemyBaseHp 60→42·EnemyCountPerWave 2→1·BaseGoldReward 10→14·GoldPerStage 2→3 — **씬 직렬화+코드 기본값 동시 반영** + 구주석 앵커(460마리≈4,600G 과대추정) 정정. 활성 씬이 BaseLoading임을 확인 후 파일 직접 수정 → Unity refresh·Additive 임시 로드로 SerializedObject 실효값 실측 (4종 전부 채택값·PlayerHp 비직렬화 유지·컴파일 에러 0·콘솔 에러 0)
+- **문서 Minor 정정**: v1 §9에 v2 대체 포인터 (완료된 코드 수정 재의뢰 방지 — C14-5) + v2에 골드 분포 초반 이동(+40% W1) 유의 명기
+- **잔여 관찰·별건 안건**: R-J 풀장착 초반 무위협 (시스템 기획 협의 — 별건 상정) · A11 분신 미러링 위치 정합 · ValidateUpgradeCoverage 상시 경고 · TMP churn .gitattributes 정책화 · git GCM 간헐 인증 실패 · 플레이테스트 기반 실측 검증 (모델은 2-경계 밴드까지)
+- **오늘 GodDem 커밋 5건**: `77bd835`(1차 인게임 완결) `ee9ec11`(정정) `57a8fcf`(3차 메타 결선) `7728a41`(4차 승인분 반영) `d5dea4d`(5차 S3 v2 수치)

공유/대화로그/조직운영/2026-08-21.md

@@ -35,5 +35,5 @@
 
 ### 결정·방침
 - 세션 수명 기준: 10MB / 이미지 30장 / API 끊김 / 압축 발생 (권고 기준 — 운영 조정 가능)
-- 이 PC(E:\BurningTimes) 단독 운영 권장. 두 PC 병행 시 동시 세션 금지
+- **PD 확정 (2026-08-21)**: "BurningTimes 조직의 GodDem 프로젝트는 이 로컬 PC에서만 진행" — 두 PC 병행 종료, 인증 충돌 축 제거. 조직 레포 경로 = `E:\BurningTimes` · GodDem 레포 = `E:\NerdNavis\GodDem`
 - C40 하위 번호 미사용 (무번호 소절) — C40-1~4 부재 상태에서 C40-5 신설 시 번호 기형 (감사 Major 1)

공유/소통/개발팀→기획팀/2026-08-21_기본스탯_튜닝경로_변경_통지.md

@@ -0,0 +1,16 @@
+# [통지] 플레이어 기본 스탯 튜닝 경로 변경 (GodDem SurvivalBattle)
+
+> 발신: 개발팀장 (총괄PM 대행 기록) · 2026-08-21 · 근거 커밋: GodDem `7728a41` · dev-auditor Major 조건 이행
+
+## 내용
+
+이중 SOT 결함 해소(4차)로 `SurvivalBattleManager.PlayerHp/PlayerAttack`(현행 400/22)이 **씬 직렬화 필드 → 코드 상수(`static readonly`) 기반 비직렬화 프로퍼티**로 전환되었습니다.
+
+**기획팀 영향**: 이 2종은 Inspector 편집이 불가해져 **기획팀 단독 반영 경로가 소멸** — 튜닝 필요 시 개발팀 REQ 경유로 전환됩니다. (S3 조정안의 "코드 변경 필요" 목록 +1)
+
+**승격 조건**: 기획팀이 기본 스탯 직접 튜닝 권한을 요구할 경우, 개발팀이 ScriptableObject/CSV 공통 참조 구조(4차 기각안 ③ — 편집성+단일 SOT 동시 충족 유일안)로 승격 집행합니다. 필요 시 본 채널로 회신 바랍니다.
+
+## 참고
+
+- 그 외 밸런스 값(EnemyBaseHp·EnemyCountPerWave·골드 계수 등)은 종전대로 씬·CSV 직접 편집 가능
+- `penetrate_ratio` 강화 트랙은 상점 비노출 처리됨 (배선 시 자동 복귀 구조) — 강화 카탈로그 기획 시 참고