35 KiB

Raw Permalink Blame History

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)

"완전 맥스" 설계 의도와의 정합: B4 v1 §1의 목표 경험은 "완전 맥스(3노드 그레이드6 + 해금순번 N) 밴드"다 — 아웃게임 영구성장 시스템은 "계정을 완전히 밀었을 때 도달하는 최종 상태"를 표현하는 것이 설계 취지이므로, 원작에서도 "히어로가 도달 가능한 최종 등급(6)에서 얻는 값"을 대표로 삼는 것이 이 시스템의 의도에 가장 부합한다.
서사적 지위의 명확성: 등급6은 원작에서 "더 이상 오를 곳 없는 최종 형태"라는 유일무이한 지위를 갖는다. 반면 등급4·5는 원작에서도 "다음 등급으로 가는 경유지"였을 뿐 — 이 경유지 하나를 GodDem의 유일한 대표값으로 고정할 서사적 근거가 약하다.
단수 괴리 최소화: 계열95/75는 5단이라 GodDem 표준 6단(Node1 기준)과 1단 차이로 가장 가깝다. 93/73(3단)을 택하면 6단과의 괴리가 더 커져 "단수 처리"(§2) 결정에서 외삽 압박이 커진다.
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단 축소

원작 정합 100%: 이번 작업의 존재 이유 자체가 "원작 불일치 발견→정정"이다 — 외삽 없이 정확히 원작 그대로 이식하는 (a)만이 이 목적에 완전히 부합한다.
per-node MaxGrade는 회피 대상이 아니라 이 상황을 위한 정확한 도구: 본 세션에서 이미 한 차례 검증된 원칙(가챠 합성 사다리가 슬롯별로 비대칭 진입 등급을 갖고, "값이 있는 곳까지만 사다리를 인정"하는 카탈로그 유도 방식으로 정합하게 처리한 전례, 2026-08-23_P3B3-2_스턴_합성_설계_v3.md §2-4)와 동일 유형의 구조적 필요다 — 신규 발명이 아니라 이미 확립된 설계 원칙의 재적용.
(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:

- 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;

  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;

  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;
  }

  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곳):

- /// <summary>마스터리 노드 최대 그레이드(테이블 캡). 캡 확장은 CSV 행 추가만으로 가능.</summary>
- public static int MasteryMaxGrade => SkillMastery.MaxGrade;
+ /// <summary>마스터리 노드 nodeId 의 최대 그레이드(노드별 콘텐츠 캡). 캡 확장은 CSV 행 추가만으로 가능.</summary>
+ public static int MasteryMaxGradeOf(int nodeId) => SkillMastery.MaxGradeOf(nodeId);

- public static bool CanUpgradeMastery(int nodeId) => MasteryGradeOf(nodeId) < SkillMastery.MaxGrade;
+ public static bool CanUpgradeMastery(int nodeId) => MasteryGradeOf(nodeId) < SkillMastery.MaxGradeOf(nodeId);

  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곳 — 루프 밖 단일 조회를 루프 안 노드별 조회로 이동):

- 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 확인 항목

🔴 계열 선택(본 문서 핵심 결정): 계열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 비교표 전체 참조.
🔴 비용 축 = 원작의 약 1/5.25(19.0%)로 GodDem 재산정된 사실: (A) 형태 이식 원칙(구조·형태는 원작에서, 절대치는 GodDem 재산정) 적용 결과이며, 원작의 재료 재화 dj_16001(GodDem 미보유)이 기계적 이식을 애초에 불가능하게 한다는 것이 근본 이유다(§4-5) — PD가 이 축소 사실을 인지한 채 계열 선택을 택해야 한다(feedback_pd_directive_altered_to_rescale 계열 사안).
🔴 N-1 확정의 전제 이동: PD가 N-1(가챠 raw값 유지)을 확정할 때 근거로 삼았던 "가챠가 기존 예산(승급+마스터리=0.64) 대비 1.7배 초과"라는 사실이, 95/75 채택 시 "기존 예산"이 0.64→0.88로 커지며 그 초과 배율이 1.23배로 완화된다(§6-2). N-1 재론 요구 아님 — PD가 이 연쇄를 인지한 채 계열 선택을 택해야 한다.
🟡 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종 정합)를 지킨다.
(참고, 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 감사 수행	—
2026-08-23	balance-designer	plan-auditor 지적 5건 반영(같은 v1 내 확정)	초안
—	원칙	층간 교차표(§6-1류)를 설계 문서 필수 섹션으로 고정(감사 권고 수용)	Ring v3가 이행하고 본 v1이 최초 누락했던 패턴 — 후속 밸런스 설계 문서는 "결합 최종 수치" 절 작성 시 자신이 속한 층뿐 아니라 인접·상위 층(가챠 승산항 등)까지 결합한 상한표를 기본 포함할 것(차기 계승, B4 v1 §1 계승 문서 공통 적용 권고)

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

PD 확인 1건 상신 필요(§8) — 계열 선택 최종 채택. 확정 전까지 CSV 반영 보류 권고(R-E3).
개발팀 구현: §3 코드 3파일 diff + CSV 갱신(Node2·3 각 6행→5행, 값 재산정). C6-1 백업 필수(R-E2) — SurvivalMetaSkillMastery.csv.bak_{YYYYMMDD_HHMM}.csv.
B4 v1 본문 포인터 정정(designer 부수 처리 권고, 별건): 2026-08-22_P3B4_스킬마스터리_설계_v1.md §6-1·§9-2·§11의 Node2·3 값이 본 문서로 대체됐다는 addendum 노트 필요(Ring v3 선례와 동일 패턴).
ux-designer 협의(R-E1): 노드별 상이한 분모("g/6" vs "g/5") UI 표시 방식.
SurvivalStatCatalog.cs Note 필드 갱신(B4 v1 §9-3 권고 승계): ele_* 2종 Note를 구현 완료 후 실제 값 출처(계열95/75)로 갱신.
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 후속 처리).

35 KiB Raw Permalink Blame History Unescape Escape