# GodDem ele 2종(Node2·3) 원작 정합 재설계 v1

> ⚠️ **역사 보존 — 최신 SOT 아님(2026-08-23)**: PD 직접 지시(대화로그 §98, "영웅 등급별로 맞춰")로 본 문서의 핵심 전제("히어로 1명이라 대표 계열 1개 고정")가 폐기됐다. **`2026-08-23_B4ele_원작정합_재설계_v2.md`가 최신 SOT** — 원작 실측치(계열93/94/95·73/74/75)·D(grade) 비용 방법론·per-node MaxGrade 인프라(`102e662`)는 v2가 그대로 승계했으나, "대표 계열 택1" 구조 자체는 "영웅 등급 차원 보유 + 현재 히어로 HeroGrade=4 고정 배정"으로 대체됐다.

> **작성**: balance-designer(기획팀) 2026-08-23 · **P3-B4 후속 보정 산출물**(B4 v1 병존 — `2026-08-22_P3B4_스킬마스터리_설계_v1.md`는 무변경 유지, 본 문서가 Node2·3 값·per-node MaxGrade 스펙의 최신 SOT)
> **위임 경로**: PD §85 ④ "백로그도 자율적으로 판단해 우선 네가 먼저 진행해" → 개발팀장 재추출(대화로그 §87·§88) → PM 위임(본 문서 착수 근거)
> **PD 원문 인용 불가(C42-2 A 예외 고지)**: 본 건은 PD가 ele 수치 자체를 직접 지시한 적 없다 — PD는 "백로그 자율 위임"만 승인했고, 개발팀장이 자체 재추출로 원작 불일치를 **발견**했다. 따라서 본 문서의 결정 사항(계열 선택 등)은 PD 확인 목록(§8)에 정식 상신하며, 지금 이 설계 자체는 designer 재량(P23 "핵심 밸런싱 방향 전환" 영역이므로 안 자체는 완성하되 최종 채택은 PD 확인) 범위에서 완결한다.
> **실측 소스(C39·C44)**: 개발팀장 재추출 실측치는 대화로그 §87(원문)·§88(요약) 인용 — 본 세션이 원작 암호화 파일을 직접 재복호화하지는 않았다(그 절차는 개발팀장 영역, 조직 분업상 정당). 코드 실측(`SurvivalSkillMasteryTable.cs`·`SurvivalMeta.cs`·`SurvivalLobbyController.SkillMastery.cs`)은 본 세션이 직접 Read.
> **표기 규칙(C5·C44)**: 🟢확정(원작 실측 또는 코드 직접 확인) · 🟡추정 · 🔴PD 확인 필요

---

## 0. 결론 요약

| 결정 항목 | 채택 | 핵심 근거 |
|---|---|---|
| **계열 선택** | **계열95(ele_hurt_add)·계열75(ele_penetrate_ratio)** — 원작 영웅 등급6(최고 등급) 계열 | "완전 맥스"라는 아웃게임 영구성장 설계 의도(B4 §1)에 부합하는 유일한 후보 — 등급6이 원작에서 "히어로가 도달 가능한 최종 형태"라는 명확한 서사적 지위를 가짐(§1) |
| **단수 처리** | **(a) 5단 축소 + per-node MaxGrade 신설** | 계열95/75가 원작에서 실제로 5단이므로 외삽 없이 100% 원작 정합. per-node MaxGrade는 원작 정합의 **필수 선행 조건**(6단 유지 시 구조적으로 불가능, §2) |
| **per-node MaxGrade** | 개발팀장이 그대로 구현 가능한 완전 스펙 확정 | 코드 3파일 변경 지점 전부 실측 확인 — 신규 클래스 없이 기존 3파일 내 수정으로 해결(§3) |
| **비용 재산정** | D(grade) 방법론(B4 §5-1) 그대로 재사용 — Node2 244,860G·Node3 174,900G | 기존 감사통과 방법론 재적용이라 재감사 부담 최소(§4) |
| **3노드 합계(권장안)** | 479,710G(구 526,680G 대비 -8.9%) | B1(1,056,056G)·B2(510,496G)와 동일 자릿수 유지(§6) |
| **승산항(FinalAttack 배율)** | 1.42→**1.66**(+16.9%) | 3종 마스터리 만렙 합 0.42→0.66(§6) |

**PD 확인 필요 1건(§8)**: 계열 선택(95/75 권장 vs 93/73 vs 6단 외삽 등 4안 비교표 제시) — **승산항 밸런싱 방향 전환이라 최종 채택은 PD 확인 영역**(P23).

**소비처 트랙과의 독립성 명시(PM 요청 반영)**: 본 문서는 penetrate_ratio·ele_hurt_add·ele_penetrate_ratio의 **값**만 원작 정합으로 재설계한다. 이 3종이 "관통/속성" 고유 의미 없이 `FinalAttack()` 공격 비율 항에 잠정 배선되는 소비처 형태(B4 §2-2·§8·R-F1, 적 방어 시스템 부재로 인한 잠정 조치)는 **본 문서가 재론하지 않는다** — 두 트랙은 완전히 독립이다: 소비처 형태는 "언제 진짜 관통/속성 시스템을 신설할 것인가"의 문제이고, 본 문서는 "그 배선이 무엇을 얼마나 배선하는가"의 값만 정정한다.

---

## 1. 계열 선택 — 원작 hero_skill_learn 구조를 GodDem에 대응시키기

### 1-1. 원작 구조 재확인(C39, 개발팀장 §87 인용)

`heroskillattr`는 (계열×quality) 2차원이고, `hero_skill_learn` 교차 확인 결과 **계열=영웅 등급·quality=스킬 학습 레벨**이다. ele 2종은 영웅 등급 4/5/6 전용이며, 등급별로 **별도 계열·별도 최대 학습레벨**을 갖는다 — 즉 원작에는 "하나의 6단 계열"이 아니라 **3개의 독립된 짧은 계열**(등급4=3단·등급5=4단·등급6=5단)이 존재하고, 실제 플레이는 히어로 등급이 오를 때마다 새 계열이 열리는 방식이었다.

| 원작 계열 | 대응 영웅 등급 | 단수 | ele_hurt_add(계열93·94·95) | ele_penetrate_ratio(계열73·74·75) |
|---|---|---|---|---|
| 최하 | 등급4 | 3단 | 0.05 / 0.10 / 0.15 | 0.03 / 0.06 / 0.09 |
| 중간 | 등급5 | 4단 | 0.06 / 0.12 / 0.18 / 0.24 | 0.04 / 0.08 / 0.12 / 0.16 |
| **최고** | **등급6** | **5단** | **0.07 / 0.14 / 0.21 / 0.28 / 0.35** | **0.05 / 0.10 / 0.15 / 0.20 / 0.25** |

**공통 구조 확인**: 3개 계열 전부 **엄격 선형**(base×level, 등급이 오를수록 base만 0.05→0.06→0.07(hurt)·0.03→0.04→0.05(penetrate)로 커짐) — 현행 GodDem이 잘못 차용한 `hurt_add`의 "C패턴"(가속형)은 이 3개 계열 어디에도 없다. 이는 B4 v1 §5-1이 "형제 스탯 값형태 대입"으로 세웠던 가정 자체가 틀렸다는 뜻이다(단순 배율 오류가 아니라 **값의 형태 자체가 다른 원작 계열이었다**).

### 1-2. GodDem 대응 문제 — "히어로 1명·등급 개념 부재"

GodDem은 원작과 달리 히어로가 1명뿐이고 "영웅 등급"이라는 상태 축이 없다 — 원작처럼 "등급이 오르면 새 계열이 열린다"는 게이팅을 그대로 이식할 대상 자체가 없다. 따라서 **3개 계열 중 정확히 하나를 GodDem의 유일한 마스터리 값곡선으로 채택**해야 한다.

### 1-3. 후보 비교 — 4안(PM 대비 2안 + 자체 발굴 2안)

| 안 | 단수 | ele_hurt_add 만렙 | ele_penetrate_ratio 만렙 | 3종 합(MasteryAttackRatio) | 승산 배율(1+x) | 구 대비 |
|---|---|---|---|---|---|---|
| 계열93/73(등급4) | 3단 | 0.15 | 0.09 | 0.30 | 1.30 | **-8.5%** |
| 계열94/74(등급5) | 4단 | 0.24 | 0.16 | 0.46 | 1.46 | +2.8% |
| **계열95/75(등급6) — 채택** | **5단** | **0.35** | **0.25** | **0.66** | **1.66** | **+16.9%** |
| (참고) 95/75+6단외삽 | 6단(외삽) | 0.42(외삽) | 0.30(외삽) | 0.78 | 1.78 | +25.4% |

### 1-4. 채택 근거 — 계열95/75(등급6)

1. **"완전 맥스" 설계 의도와의 정합**: B4 v1 §1의 목표 경험은 "완전 맥스(3노드 그레이드6 + 해금순번 N) 밴드"다 — 아웃게임 영구성장 시스템은 "계정을 완전히 밀었을 때 도달하는 최종 상태"를 표현하는 것이 설계 취지이므로, 원작에서도 "히어로가 도달 가능한 최종 등급(6)에서 얻는 값"을 대표로 삼는 것이 이 시스템의 의도에 가장 부합한다.
2. **서사적 지위의 명확성**: 등급6은 원작에서 "더 이상 오를 곳 없는 최종 형태"라는 유일무이한 지위를 갖는다. 반면 등급4·5는 원작에서도 "다음 등급으로 가는 경유지"였을 뿐 — 이 경유지 하나를 GodDem의 유일한 대표값으로 고정할 서사적 근거가 약하다.
3. **단수 괴리 최소화**: 계열95/75는 5단이라 GodDem 표준 6단(Node1 기준)과 **1단 차이**로 가장 가깝다. 93/73(3단)을 택하면 6단과의 괴리가 더 커져 "단수 처리"(§2) 결정에서 외삽 압박이 커진다.
4. **Node1과의 정합**: Node1(penetrate_ratio, 이미 확정)은 원작 "6단 계열(10~16) 중 최저 계열(10)"을 택한 전례가 있다(개발팀장 §87 "부수 확인" — 미고지 자유도였을 뿐 오류는 아님). 이 전례는 "여러 등가 계열 중 하나를 고른다"는 재량 자체를 정당화하지만, 계열 10이 최저였던 이유는 "6단 계열들 사이의 절대값 크기 차이"였을 뿐 단수 차이는 아니었다 — ele 2종처럼 **단수 자체가 계열마다 다른 경우**에는 이 전례가 "최저를 고르라"는 규칙까지 함의하지 않는다.

### 1-5. 기각안(C32)

| # | 검토안 | 기각 사유 |
|---|---|---|
| 1 | 계열93/73(등급4, 3단) | 승산항 위축(-8.5%, 구조 개선 작업인데 파워가 줄어드는 역설) + 3단은 GodDem 6단 표준과 괴리가 가장 커서 §2 단수 처리 부담이 오히려 늘어남 |
| 2 | 계열94/74(등급5, 4단) | 두 극단의 중간이라는 점 외에 채택 근거가 없음 — 원작에서 등급5는 "경유지"일 뿐 "완전 맥스"라는 설계 의도(B4 §1)와 대응할 서사적 근거가 약함 |
| 3 | 3계열 순차 연결(93→94→95, 12단) | 원작의 진짜 구조(히어로 등급이 오를 때 새 계열이 열리는 게이팅)를 재현하려는 시도이나, GodDem은 히어로 등급 개념이 없어 그 게이팅 자체를 이식할 수 없다. 인위적으로 이어붙이면 원작에 없는 12단이라는 **새 구조를 창작**하는 셈이라 "원작 정합"이라는 본 작업의 목적과 정면 모순 |

---

## 2. 단수 처리 — (a) 5단 축소 채택

### 2-1. 두 옵션 정식 비교

| 옵션 | 내용 | 원작 정합 | 구현 부담 |
|---|---|---|---|
| **(a) 5단 축소 — 채택** | Node2·3을 계열95/75 그대로 5단만 등록. per-node MaxGrade 신설 필수(§3) | **100%(외삽 0건)** | 코드 3파일 수정(§3), 신규 클래스 없음 |
| (b) 6단 유지 + 외삽 | Node2·3에 원작에 없는 6번째 스텝을 등차 패턴 그대로 연장해 추가(§1-3 참고행: 0.42/0.30) | 부분(마지막 1단은 원작에 실재하지 않는 창작값) | per-node MaxGrade 불요 — 단 CSV에 "외삽 행"을 채워 넣는 데이터 작업은 (a)와 동량, 이점은 표면적(§2-2) |

### 2-2. 채택 근거 — (a) 5단 축소

1. **원작 정합 100%**: 이번 작업의 존재 이유 자체가 "원작 불일치 발견→정정"이다 — 외삽 없이 정확히 원작 그대로 이식하는 (a)만이 이 목적에 완전히 부합한다.
2. **per-node MaxGrade는 회피 대상이 아니라 이 상황을 위한 정확한 도구**: 본 세션에서 이미 한 차례 검증된 원칙(가챠 합성 사다리가 슬롯별로 비대칭 진입 등급을 갖고, "값이 있는 곳까지만 사다리를 인정"하는 카탈로그 유도 방식으로 정합하게 처리한 전례, `2026-08-23_P3B3-2_스턴_합성_설계_v3.md` §2-4)와 **동일 유형의 구조적 필요**다 — 신규 발명이 아니라 이미 확립된 설계 원칙의 재적용.
3. **(b)의 이점은 표면적**: "6단 유지로 UI 균일성 확보·per-node MaxGrade 구현 회피"가 (b)의 장점처럼 보이나, 실제로는 (b)를 택해도 Node2·3의 CSV에 "외삽 6번째 행"을 새로 채워 넣어야 하므로 **데이터 작업량 자체는 (a)와 동일**하다 — 유일한 차이는 그 6번째 값이 원작 실측치(0건)인가 창작치(1건)인가일 뿐이다. 즉 (b)는 구현을 단순화하는 대가로 "원작에 없는 수치"라는 새로운 PD 확인 부담을 추가로 만든다 — 순전한 손해 교환이다.

### 2-3. 정직 고지 — UI 이질감(리스크로 등재, §9)

(a) 채택 시 마스터리 패널이 Node1은 "Grade 3/6", Node2·3은 "Grade 3/5"로 **서로 다른 분모**를 표시하게 된다. 이는 결함이 아니라 **원작 자체가 이미 그렇게 설계돼 있었다는 사실을 정직하게 노출**하는 것이다(각 스탯이 실제로 도달 가능한 최대치가 다름) — 감추는 쪽(예: 전부 6단으로 통일)이 오히려 허구를 만드는 것이다. 다만 사용자 경험상 이질감이 있을 수 있어 ux-designer 협의를 후속조치(§11)로 남긴다.

---

## 3. per-node MaxGrade 요건 명세 — 개발팀장 구현 스펙

### 3-1. 현재 구조의 결함(C39 실측 재확인)

`SurvivalSkillMasteryTable.cs`의 `MaxGrade`는 **테이블 전체에 걸친 단일 전역 스칼라**다(L36 `public int MaxGrade { get; private set; }`, 로더 L67 `if (row.Grade > table.MaxGrade) table.MaxGrade = row.Grade;` — NodeId 구분 없이 전체 행 중 최댓값 1개). `ValueAt`(L76)·`CumulativeCostAt`(L85) 둘 다 이 전역값으로 `grade`를 클램프한다.

**실측 확인된 파급 범위(3개 파일)**:
- `SurvivalMeta.cs:500` `MasteryMaxGrade => SkillMastery.MaxGrade`(전역 그대로 노출)
- `SurvivalMeta.cs:503` `CanUpgradeMastery(nodeId) => MasteryGradeOf(nodeId) < SkillMastery.MaxGrade`(전역 비교 — 게이팅 오판정 지점)
- `SurvivalMeta.cs:509` `MasteryUpgradeCost(nodeId)`의 `if (cur >= SkillMastery.MaxGrade) return -1;`(전역 비교 — 동일 결함)
- `SurvivalLobbyController.SkillMastery.cs:149` `int max = SurvivalMeta.MasteryMaxGrade;`(루프 밖에서 1회 계산 — 3노드 전부에 동일 분모를 표시, L156 `"Grade {g}\{max}"`)

**결함 시나리오(Node2를 5단으로 축소했다고 가정)**: 전역 `MaxGrade`는 Node1(6단)이 있어 여전히 6 — `CanUpgradeMastery(2)`가 `MasteryGradeOf(2)(=5) < 6`으로 `true`를 반환해 "Grade5→6 강화" 버튼이 활성화된다. 구매 실행 시 `MasteryUpgradeCost(2)`는 `CumulativeCostAt(2,6)-CumulativeCostAt(2,5)`인데 `CumulativeCostAt(2,6)`이 존재하지 않는 grade6 행을 더하지 못해 `CumulativeCostAt(2,5)`와 같은 값이 되므로 **비용 자체는 0으로 반환되고 골드는 차감되지 않는다**(개발팀장 §87 "골드 증발" 표현은 정확한 동작 서술은 아니었음, C44 정정). **실제 피해는 그보다 크다**: `Data.SkillMasteryLevel[2]=6`으로 저장된 순간 `ValueAt(2,6)`이 `_rows`에 없는 행이라 `0f`를 반환하므로, **그 직전까지 244,860G를 누적 투자해 얻은 Grade5의 실제값(0.35)이 통째로 0으로 소실**된다 — 골드를 내고 아무것도 못 받는 손해가 아니라, **이미 지불 완료한 244,860G어치 가치 전체가 공짜 "강화" 버튼 클릭 한 번에 증발**하는 더 심각한 결함이다.

### 3-2. 수정 스펙 — 3파일 정확한 diff

**`SurvivalSkillMasteryTable.cs`**:
```diff
- public int MaxGrade { get; private set; }
+ readonly Dictionary<int, int> _maxGradeByNode = new();
+ /// <summary>노드 nodeId 의 CSV 상 최고 그레이드(노드별 콘텐츠 캡). 미등록 노드는 0.</summary>
+ public int MaxGradeOf(int nodeId) => _maxGradeByNode.TryGetValue(nodeId, out int g) ? g : 0;
```
```diff
  table._rows[(row.NodeId, row.Grade)] = row;
- if (row.Grade > table.MaxGrade) table.MaxGrade = row.Grade;
+ if (!table._maxGradeByNode.TryGetValue(row.NodeId, out int cur) || row.Grade > cur)
+     table._maxGradeByNode[row.NodeId] = row.Grade;
```
```diff
  public float ValueAt(int nodeId, int grade)
  {
      if (grade <= 0) return 0f;
-     if (grade > MaxGrade) grade = MaxGrade;
+     if (grade > MaxGradeOf(nodeId)) grade = MaxGradeOf(nodeId);
      return _rows.TryGetValue((nodeId, grade), out var r) ? r.Value : 0f;
  }
```
```diff
  public long CumulativeCostAt(int nodeId, int grade)
  {
      if (grade < 0) grade = 0;
-     if (grade > MaxGrade) grade = MaxGrade;
+     if (grade > MaxGradeOf(nodeId)) grade = MaxGradeOf(nodeId);
      long sum = 0L;
      ...
```

**`SurvivalMeta.cs`**(3곳):
```diff
- /// <summary>마스터리 노드 최대 그레이드(테이블 캡). 캡 확장은 CSV 행 추가만으로 가능.</summary>
- public static int MasteryMaxGrade => SkillMastery.MaxGrade;
+ /// <summary>마스터리 노드 nodeId 의 최대 그레이드(노드별 콘텐츠 캡). 캡 확장은 CSV 행 추가만으로 가능.</summary>
+ public static int MasteryMaxGradeOf(int nodeId) => SkillMastery.MaxGradeOf(nodeId);
```
```diff
- public static bool CanUpgradeMastery(int nodeId) => MasteryGradeOf(nodeId) < SkillMastery.MaxGrade;
+ public static bool CanUpgradeMastery(int nodeId) => MasteryGradeOf(nodeId) < SkillMastery.MaxGradeOf(nodeId);
```
```diff
  public static long MasteryUpgradeCost(int nodeId)
  {
      int cur = MasteryGradeOf(nodeId);
-     if (cur >= SkillMastery.MaxGrade) return -1;
+     if (cur >= SkillMastery.MaxGradeOf(nodeId)) return -1;
      return SkillMastery.CumulativeCostAt(nodeId, cur + 1) - SkillMastery.CumulativeCostAt(nodeId, cur);
  }
```

**`SurvivalLobbyController.SkillMastery.cs`**(1곳 — 루프 밖 단일 조회를 루프 안 노드별 조회로 이동):
```diff
- int max = SurvivalMeta.MasteryMaxGrade;
  for (int i = 0; i < 3; i++)
  {
      int nodeId = MasteryNodeMeta[i].nodeId;
+     int max = SurvivalMeta.MasteryMaxGradeOf(nodeId);
      int g = SurvivalMeta.MasteryGradeOf(nodeId);
      ...
      "{...}\nGrade {g}\{max}   현재 +{val * 100f:0.#}%..."
```

### 3-3. 기존 3노드 구조 보존 확인

Node1(penetrate_ratio)은 CSV·값 전부 무변경 — `MaxGradeOf(1)`은 자동으로 6이 된다(6개 행이 그대로 존재하므로). **딕셔너리 키 기반 노드 독립성**(`SkillMasteryLevel: Dictionary<int,int>`, B4 v1 §9-1)·**3중 SOT 방지 원칙**(그레이드 직접값 비누적)도 완전히 무변경 — 이번 수정은 "전역 스칼라 1개"를 "노드별 스칼라 딕셔너리 1개"로 바꾸는 것뿐이며 그 외 어떤 아키텍처도 건드리지 않는다.

### 3-4. 신규 기각안(C32)

| # | 검토안 | 기각 사유 |
|---|---|---|
| 1 | Node2·3의 CSV에 grade6 행을 `f_Value=0`으로 채워 전역 MaxGrade 유지(코드 무변경) | `ValueAt`이 "값이 0인 행"과 "행 자체가 없음"을 구분하지 못해 `CanUpgradeMastery`가 여전히 `true`를 반환 — "0%p를 위해 골드를 내는" 함정이 형태만 바꿔 재발한다(proxy, C2 위반). 근본 해결이 아니다 |

---

## 4. 비용 재산정 — (A) 형태 이식, D(grade) 방법론 재사용

### 4-1. 방법론 — B4 v1 §5-1 그대로(재감사 불요)

B4 v1이 이미 plan-auditor 감사를 통과한 "그레이드 단(段)별 한계단가 균일화" 방법론을 그대로 재사용한다 — Node1의 기존 6그레이드 비용열(ingame 12트랙 비용×55)을 **%p당 단가 D(grade)**로 고정하고, 각 노드의 실제 스텝 비용은 `D(grade) × 그 스텝의 %p 증분`으로 역산한다.

```
D(grade) = 550 / 2,310 / 5,445 / 10,120 / 16,555 / 24,970   (grade 1~6, Node1·ingame 비용열×55, 무변경)
```

**원작 계열95/75의 구조적 이점**: 재추출된 두 계열 모두 **매 그레이드 Δ가 일정**(hurt: Δ=0.07·penetrate: Δ=0.05, "엄격 선형")이다 — B4 v1이 Node2(구 C패턴, Δ가 5/2/3/5/5/10%p로 불균등)에서 겪었던 "그레이드별 스텝 비용 재계산" 복잡도가 사라지고, `StepCost(grade) = D(grade) × 고정Δ`로 단순화된다.

### 4-2. Node2(mastery_ele_hurt_add) 재산정 — Δ=7%p 고정

| Grade | f_Value | StepCost = D(g)×7 | 누적 |
|---|---|---|---|
| 1 | 0.07 | 550×7=3,850 | 3,850 |
| 2 | 0.14 | 2,310×7=16,170 | 20,020 |
| 3 | 0.21 | 5,445×7=38,115 | 58,135 |
| 4 | 0.28 | 10,120×7=70,840 | 128,975 |
| 5 | 0.35 | 16,555×7=115,885 | **244,860** |

### 4-3. Node3(mastery_ele_penetrate_ratio) 재산정 — Δ=5%p 고정

| Grade | f_Value | StepCost = D(g)×5 | 누적 |
|---|---|---|---|
| 1 | 0.05 | 550×5=2,750 | 2,750 |
| 2 | 0.10 | 2,310×5=11,550 | 14,300 |
| 3 | 0.15 | 5,445×5=27,225 | 41,525 |
| 4 | 0.20 | 10,120×5=50,600 | 92,125 |
| 5 | 0.25 | 16,555×5=82,775 | **174,900** |

### 4-4. 한계단가 균일성 검증(C-1 재발 방지, B4 v1 §14 기각안1-B 교훈 계승)

임의 그레이드에서 StepCost÷Δ를 재계산하면 3개 노드 전부 정확히 D(grade)와 일치한다(예: 그레이드5 = Node1 16,555÷1%p=16,555 / Node2 115,885÷7%p=16,555 / Node3 82,775÷5%p=16,555 — 완전 동일). B4 v1이 겪었던 "완주 평균만 맞고 도중 한계단가가 어긋나는" 결함(기각안1-B)이 재발하지 않는다 — 오히려 이번 재산정은 원작 계열의 Δ가 고정값이라 그 결함 자체가 구조적으로 발생할 수 없다.

### 4-5. 원작 실제 비용 대조 — (A) 형태 이식 명시(plan-auditor M-1 반영)

원작 계열95/75의 실제 학습 비용은 GodDem과 전혀 다른 재화 구조를 쓴다 — 골드 360,000/540,000/720,000/900,000G(등급6 5레벨째는 골드 비용 없이 별도 게이트) 누적 **2,520,000G** + 재료 `dj_16001` 26/28/30/32개(**GodDem에 대응 재화 자체가 없음**). 재료 재화가 GodDem에 없어 원작 비용 구조를 그대로 이식하는 것은 애초에 불가능하다 — 본 문서는 **(A) 형태 이식**(구조·형태는 원작에서, 절대치는 GodDem 재화·경제 체계로 재산정) 원칙에 따라 §4-1~4-4의 D(grade) 방법론으로 골드 단일 재화 기준 독자 재계수화했다.

**GodDem/원작 배율(C44 — PM 전달치 "약 1/6"을 독립 재검증)**: 원작 누적(2,520,000G) ÷ GodDem 채택안 3노드 합계(479,710G) = **5.253배** → GodDem 값은 원작의 **약 1/5.25(19.0%)**다. PM 전달치 "약 1/6"과 자릿수 근사는 같으나 정밀치는 재계산 결과 1/5.25 쪽이 맞아 본 문서는 이 값을 채택한다(§8 PD확인 반영).

---

## 5. 수치 테이블 (밸런싱 제안 표준 포맷)

| 항목 | 현재 값 | 제안 값 | 근거 |
|---|---|---|---|
| `mastery_ele_hurt_add`(Node2) f_Value(Grade1~5, Grade6 삭제) | 0.05/0.07/0.10/0.15/0.20/0.30(6단, 원작 형제 hurt_add 계열10 오적용) | **0.07/0.14/0.21/0.28/0.35**(5단, 원작 계열95 실측) | §1 — 원작 hero_skill_learn 계열95(영웅등급6)가 GodDem "완전 맥스" 설계 의도에 가장 부합, 개발팀장 재추출 실측(대화로그 §87) |
| `mastery_ele_hurt_add`(Node2) **l_Cost(단계별 — CSV `l_Cost` 열 원값, 누적 아님. `SurvivalSkillMasteryTable.cs` 주석 실측: "l_Cost 컬럼은 단계별… 누적 비용은 CumulativeCostAt이 파생")** | 2,750/4,620/16,335/50,600/82,775/249,700(6단, 누적 406,780G) | **3,850/16,170/38,115/70,840/115,885**(5단, 누적 **244,860G**) | §4-2 — D(grade)×고정Δ(7%p) 재산정, B4 v1 감사통과 방법론 재사용. ⚠ 위 5개 값을 그대로 CSV `l_Cost` 열에 입력할 것 — **누적치(3,850/20,020/58,135/128,975/244,860)를 입력하면 안 됨**(입력 시 `CumulativeCostAt`이 이중 누적해 Node2 총액이 495,840G까지 폭증하는 오입력 위험, plan-auditor M-2) |
| `mastery_ele_penetrate_ratio`(Node3) f_Value(Grade1~5, Grade6 삭제) | 0.01/0.02/0.03/0.04/0.05/0.06(6단, 원작 형제 penetrate_ratio 계열10 오적용) | **0.05/0.10/0.15/0.20/0.25**(5단, 원작 계열75 실측) | §1 — 원작 계열75(영웅등급6) 실측, 정확 5.00× 과소 정정(개발팀장 재추출) |
| `mastery_ele_penetrate_ratio`(Node3) **l_Cost(단계별, 위와 동일 규약)** | 550/2,310/5,445/10,120/16,555/24,970(6단, 누적 59,950G) | **2,750/11,550/27,225/50,600/82,775**(5단, 누적 **174,900G**) | §4-3 — D(grade)×고정Δ(5%p) 재산정. 위 값 그대로 `l_Cost` 열에 입력(누적치 아님, 동일 오입력 위험 M-2) |
| `mastery_penetrate_ratio`(Node1) | 0.01~0.06 / 550~24,970(6단, 59,950G) | **무변경** | 이미 원작 계열10 확정값(B4 v1 §5-1), 본 재설계 범위 밖 |
| (참고) 원작 실제 학습비용 vs GodDem 재산정 | 원작 계열95/75 누적 **2,520,000G + 재료 `dj_16001` 26~32개**(GodDem 미보유 재화) | GodDem 3노드 합계 **479,710G**(재료 불요, 골드 단일) | §4-5 — (A) 형태 이식(재료 재화 부재로 기계 이식 불가), GodDem 값은 원작의 **약 1/5.25(19.0%)**(PM 전달 "약 1/6"을 C44 독립 재검증해 정밀치로 대체) |
| `SurvivalSkillMasteryTable.MaxGrade`(전역 스칼라) | 6(테이블 전체 공통) | **노드별 `MaxGradeOf(nodeId)`**(Node1=6·Node2=5·Node3=5) | §3 — 5단 축소의 구조적 선행 조건, 코드 3파일 수정 스펙 확정 |

**세그먼트별 영향(무과금/소과금/고과금)**: B4 v1 §11과 동일 판정 — **전 세그먼트 동일**. `GOLD_ID`가 상점 골드팩과 공유되나 Survival IAP 미연동 현재 상태(B1 §10 F2P 표준 구조 판정 승계)라 본 재산정이 세그먼트 간 차등 영향을 만들지 않는다.

---

## 6. 결합 최종 수치 — 승산항 배율 4안 비교(PD 확인 자료)

**RecalcPlayer 완전 전개는 범위 밖 — B4 v1 R-F3 유보 그대로 계승**(원시 %p 표현까지만, `atkFlat` 희석 반영한 정밀 전개는 B4 v1이 이미 범위 밖으로 유보한 영역이라 본 문서도 동일하게 유보한다 — 재론 불필요).

**순수 승산항 배율 예시(BaseAttack=22 단독 기준, 장비·승급·B1·B2 전부 0인 최소 앵커)**:

| 계열 선택 | 3종 합(MasteryAttackRatio 만렙) | FinalAttack 승산 배율 | 최소 앵커 예시(22×배율) | 구(0.42) 대비 |
|---|---|---|---|---|
| 계열93/73(3단) | 0.30 | 1.30 | 28.60 | -8.5% |
| 계열94/74(4단, 참고) | 0.46 | 1.46 | 32.12 | +2.8% |
| **계열95/75(5단) — 채택** | **0.66** | **1.66** | **36.52** | **+16.9%** |
| 95/75+6단외삽(참고, §1-3) | 0.78 | 1.78 | 39.16 | +25.4% |

**일반 법칙(C44 — 임의 로드아웃에 적용 가능)**: 마스터리 배율은 `FinalAttack()`의 승산항에 **순수 가산 텀**으로 들어가므로(B4 v1 §8 결합식, 무변경), B1·B2 투자량과 무관하게 어떤 로드아웃에서든 **"배율 비(1.66/1.42=1.169)"만큼 FinalAttack이 일정 비율로 커진다** — 위 표의 "-8.5%~+25.4%"는 3노드 마스터리 조합 자체의 상대적 크기이며, 장비·승급 투자 수준과 독립적으로 항상 동일 비율로 적용된다.

**3노드 합계 경제 비교**:

| 계열 | 3노드 합계 총액 | B1(1,056,056G) 대비 | B2(510,496G) 대비 | 구B4(526,680G) 대비 |
|---|---|---|---|---|
| **95/75(채택)** | **479,710G** | 45.4% | 94.0% | **-8.9%** |
| 93/73(참고) | 126,390G | 12.0% | 24.8% | -76.0% |
| 94/74(참고) | 244,200G | 23.1% | 47.8% | -53.6% |

채택안(479,710G)은 구B4(526,680G)보다 소폭 낮아지지만 여전히 B2(510,496G)와 동일 자릿수(94.0%)를 유지한다 — 층간 대조(I-3 교훈) 통과.

### 6-1. 층간 결합 승산항 상한 — 가챠 v3 §8-4까지 포함한 전체 4안 비교(plan-auditor M-3 반영, 신규)

B3 본체 v3 §8-4가 PD 확정(N-1)한 전체 승산항 구조는 `(1 + 승급 0~0.22 + 마스터리 0~X + 가챠옵션 0~1.08)`이다 — 위 §6 표는 "마스터리 단독"만 다뤘으나, 이 X를 실제 확정 구조에 대입하면 **3개 아웃게임 층 결합 상한**이 계열 선택에 따라 다음과 같이 바뀐다(C44 독립 재검증 — B3 §8-4의 현행 상한 1.72와 정확히 일치 확인):

| 계열 선택 | 마스터리(X) | 결합 상한(1+0.22+X+1.08) | 현행(1.72) 대비 |
|---|---|---|---|
| 93/73(3단) | 0.30 | 1.60 | -7.0% |
| 94/74(4단, 참고) | 0.46 | 1.76 | +2.3% |
| **95/75(5단) — 채택** | **0.66** | **1.96** | **+14.0%** |
| 95/75+6단외삽(참고) | 0.78 | 2.08 | +20.9% |

**B3 §8-4 "0.64 대비 2.69배" 기재도 계열 선택에 연동해 갱신 필요**(현행 1.72÷0.64=2.69배, 95/75 채택 시 1.96÷0.64=**3.06배**) — §11 후속조치에 명시.

### 6-2. ★ N-1 확정의 전제 이동(plan-auditor M-3 반영, PD 인지 필요)

PD는 N-1(가챠 raw값 유지, 대화로그 §67) 결정 당시 "가챠 옵션 기여(+1.08)가 **기존 예산(승급+마스터리=0.64) 대비 1.7배** 초과"라는 사실을 고지받고 그 초과를 감수한 채 원작 raw값을 확정했다(B3 v3 §8-4·§13-8). **본 재설계(95/75 채택)로 마스터리가 0.42→0.66이 되면 "기존 예산"도 0.64→0.88로 커져, 가챠의 상대적 초과 배율은 1.08÷0.88=**1.23배**로 낮아진다** — PD가 N-1을 확정할 때 전제로 삼았던 "1.7배 압도"라는 상황 자체가 이번 결정으로 완화된다는 뜻이다. N-1 재론을 요구하는 것은 아니나(이미 확정·구현 완료 사양, C36), **PD가 이 연쇄를 인지한 채 계열 선택을 택해야 한다** — §8 PD확인에 명시 반영.

---

## 7. 검증 시나리오

| # | 시나리오 | 기대 결과 |
|---|---|---|
| 1 | 신규유저 기준선 무결성(SkillMasteryLevel 전부 미투자) | `MasteryAttackRatio()=0`, `FinalAttack()` 불변(B4 v1 §10 시나리오1 승계, 22/400 앵커 무영향 — 본 재설계는 f_Value/l_Cost/MaxGrade 셋만 변경, `BaseAttack`/`BaseHp` 상수 무접촉) |
| 2 | Node2를 Grade5(만렙)까지 구매 후 추가 구매 시도 | `CanUpgradeMastery(2)`가 `MaxGradeOf(2)=5`와 비교해 `false` — "MAX" 표시, 골드 차감·`ValueAt` 소실 없음(§3-1 결함 시나리오 재발 안 함) |
| 3 | Node1을 Grade6(만렙)까지 구매 | `MaxGradeOf(1)=6` 그대로라 정상 진행(§3-3, 무변경 확인) |
| 4 | UI 패널 동시 노출 | Node1 "Grade g/6", Node2·3 "Grade g/5" — 노드별 분모 정상 표시(§3-2 diff 3번째 반영) |
| 5 | 한계단가 균일성 | 임의 그레이드 G(1~5)에서 Node1·2·3 전부 `StepCost÷Δ = D(G)`로 완전 일치(§4-4) |
| 6 | 3노드 완전 맥스 결합 | `MasteryAttackRatio()=0.06+0.35+0.25=0.66`, 승산 배율 1.66(§6) |

---

## 8. PD 확인 항목

1. **🔴 계열 선택(본 문서 핵심 결정)**: **계열95/75(등급6, 5단) 채택 권고** — 승산항 +16.9%(0.42→0.66), 3노드 총액 479,710G(-8.9%, 원작 2,520,000G의 약 1/5.25). 대안: 계열93/73(3단, -8.5%)·계열94/74(4단, +2.8%)·6단외삽(+25.4%, 원작 실측 아닌 창작치 포함). §1·§6 비교표 전체 참조.
2. **🔴 비용 축 = 원작의 약 1/5.25(19.0%)로 GodDem 재산정된 사실**: (A) 형태 이식 원칙(구조·형태는 원작에서, 절대치는 GodDem 재산정) 적용 결과이며, 원작의 재료 재화 `dj_16001`(GodDem 미보유)이 기계적 이식을 애초에 불가능하게 한다는 것이 근본 이유다(§4-5) — PD가 이 축소 사실을 인지한 채 계열 선택을 택해야 한다(`feedback_pd_directive_altered_to_rescale` 계열 사안).
3. **🔴 N-1 확정의 전제 이동**: PD가 N-1(가챠 raw값 유지)을 확정할 때 근거로 삼았던 "가챠가 기존 예산(승급+마스터리=0.64) 대비 1.7배 초과"라는 사실이, 95/75 채택 시 "기존 예산"이 0.64→0.88로 커지며 그 초과 배율이 **1.23배로 완화**된다(§6-2). N-1 재론 요구 아님 — PD가 이 연쇄를 인지한 채 계열 선택을 택해야 한다.
4. **🟡 Node1 비대칭(designer 의견 포함, 재량)**: Node1(penetrate_ratio)은 원작 **최저 계열(10)**을 유지하는데 Node2·3만 **최고 계열(95/75)**을 채택하면 3노드 간 "어느 계열을 대표로 삼는가" 기준이 서로 달라진다 — **"Node1도 상위 계열로 올릴 것인가?"**를 확인 필요 항목으로 명시한다. designer 의견: 현 단계는 Node1 유지를 권고한다 — Node1은 이미 PD 확정·구현 완료된 값(B4 v1 §5-1)이라 재론은 변경 최소화 원칙(C36 유사 소지)에 부딪히고, 필요성이 확인되면 별도 후속 작업(penetrate_ratio 7개 계열 재추출·재검토)으로 분리 처리하는 편이 본 문서 스코프(ele 2종 정합)를 지킨다.
5. (참고, PD확인 아님) **소비처 형태(관통/속성 잠정 FinalAttack 배선)는 본 건과 독립 트랙** — B4 v1 R-F1이 이미 유보한 별개 안건(적 방어 시스템 신설 시점 결정), 본 문서가 재상신하지 않는다.

---

## 9. 리스크

| ID | 리스크 | 심각도 | 내용 |
|---|---|---|---|
| R-E1(신규) | UI 노드별 상이한 분모("g/6" vs "g/5") 이질감 | 낮음(정보성) | §2-3 — 원작 실제 구조를 정직하게 반영한 결과. ux-designer 협의 권고(§11) |
| R-E2(신규) | `SurvivalMetaSkillMastery.csv` 기존 파일 덮어쓰기 — C6-1 백업 필수 | 높음(구현 전 필수) | B4 v1 R-F6·후속조치#2가 이미 지적한 동일 대상 파일. 개발팀 구현 착수 시 `SurvivalMetaSkillMastery.csv.bak_{YYYYMMDD_HHMM}.csv` 백업 필수(침묵 채택 금지) |
| R-E3(신규) | 계열 선택 미확정 상태에서 개발팀장이 선행 구현 착수 시 재작업 리스크 | 중 | §8 PD확인 1번 확정 전까지는 §3(per-node MaxGrade)만 선구현 가능·§5(f_Value/l_Cost 구체 수치)는 PD 확정 후 CSV 반영 권고 |

---

## 10. 변경 이력 (P16)

| 일시 | 작성 | 변경 | 근거 |
|---|---|---|---|
| 2026-08-23 | balance-designer | 문서 신규 작성(v1) — Node2·3(ele_hurt_add·ele_penetrate_ratio) 원작 정합 재설계. 계열95/75(등급6·5단) 채택 권고(§1)·5단축소+per-node MaxGrade 채택(§2)·코드 3파일 수정 스펙 확정(§3)·D(grade) 방법론 재적용 비용 재산정(§4, Node2 244,860G·Node3 174,900G)·승산항 배율 4안 비교(§6, 0.30/0.46/0.66/0.78) | PM 위임 — 개발팀장 재추출 발견(대화로그 §87·§88), PD §85④ 백로그 자율 위임 근거 |
| 2026-08-23 | plan-auditor | 모드A 감사 수행 | — | 조건부통과("Ring v3보다 개선" 평가 — 코드 인용 8곳·산술 전항 일치) — Major 3건(층간 교차 기재 누락 계열)·Minor 2건 |
| 2026-08-23 | balance-designer | plan-auditor 지적 5건 반영(같은 v1 내 확정) | 초안 | **M-2**(§5 `l_Cost` 라벨 "누적"→"단계별" 정정, 오입력 시 495,840G 폭증 위험 고지)·**M-1**(§4-5 신설 — 원작 실비용 2,520,000G+`dj_16001` 재료 기재, 정밀배율 1/5.25로 재계산해 PM 전달 "1/6"을 대체)·**M-3**(§6-1·6-2 신설 — 층간 결합 승산항 상한 4안 표+N-1 전제 이동 고지 "1.7배→1.23배")·**m-3**(§8 PD확인에 Node1 비대칭 질문 추가)·**m-1·m-2**(절번호 §9→8·§10→9·§13→11·§4-5→5 정정, "골드 증발"을 실동작(비용 0·기투자 244,860G 가치 소실)으로 정정, 대화로그 §87 전파분 정정 주석) | plan-auditor 조건부통과 회송 — PD 상신 전 보강 |
| — | 원칙 | **층간 교차표(§6-1류)를 설계 문서 필수 섹션으로 고정**(감사 권고 수용) | Ring v3가 이행하고 본 v1이 최초 누락했던 패턴 — 후속 밸런스 설계 문서는 "결합 최종 수치" 절 작성 시 자신이 속한 층뿐 아니라 **인접·상위 층(가챠 승산항 등)까지 결합한 상한표**를 기본 포함할 것(차기 계승, B4 v1 §1 계승 문서 공통 적용 권고) |

---

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

1. **PD 확인 1건 상신 필요**(§8) — 계열 선택 최종 채택. 확정 전까지 CSV 반영 보류 권고(R-E3).
2. **개발팀 구현**: §3 코드 3파일 diff + CSV 갱신(Node2·3 각 6행→5행, 값 재산정). **C6-1 백업 필수**(R-E2) — `SurvivalMetaSkillMastery.csv.bak_{YYYYMMDD_HHMM}.csv`.
3. **B4 v1 본문 포인터 정정**(designer 부수 처리 권고, 별건): `2026-08-22_P3B4_스킬마스터리_설계_v1.md` §6-1·§9-2·§11의 Node2·3 값이 본 문서로 대체됐다는 addendum 노트 필요(Ring v3 선례와 동일 패턴).
4. **ux-designer 협의**(R-E1): 노드별 상이한 분모("g/6" vs "g/5") UI 표시 방식.
5. **SurvivalStatCatalog.cs Note 필드 갱신**(B4 v1 §9-3 권고 승계): ele_* 2종 Note를 구현 완료 후 실제 값 출처(계열95/75)로 갱신.
6. **B3 본체 v3 §8-4 PD 확정 기재 갱신 필요**(§6-1·§6-2, plan-auditor M-3): 95/75 채택이 PD 확정되면 §8-4의 "결합 상한 1.72·기존예산 대비 2.69배" 기재를 "1.96·3.06배"로, N-1 관련 "가챠 1.7배 초과" 서술을 "1.23배"로 갱신해야 한다 — `2026-08-22_P3B3_가챠_설계_v3.md` 해당 절 addendum 대상(designer 후속 처리).