docs(BT13-GodDem): 원작 아키텍처 이식 청사진 v1 (P1 완료)

- 3축 조망: 능력치 24종(PvE 18)·아웃게임 5층·스테이지(원작=teamwavepassreward 54단계)
- 정정: StageBalance는 원작 아닌 GodDem 자산 / 재사용 3·확장 3
- 단계: P2 메타재설계→P3-A 능력치→P3-B 아웃게임→P3-C 스테이지. 재추출 3건·가챠 PD결정

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

공유/기획/GodDem/2026-08-22_원작아키텍처_이식청사진_v1.md

@@ -0,0 +1,206 @@
+# GodDem 원작 데이터 아키텍처 전면 이식 청사진 v1
+
+> **작성**: balance-designer(기획팀) 2026-08-22 · **1단계 산출물** (P32 맥락 분할 · C50 대규모 승인분)
+> **PD 지시 원문 (C42-2 A, 2026-08-22)**: "원작 데이터 아키텍처 전면 이식이 맞아" / "그냥 이대로 진행해"(세션 유지)
+> **PD 지적 원문 2건**: ①"총 스테이지 구성 등을 원작 게임과 동일하게 맞춰" ②"원작은 능력치가 아웃게임을 통해 점차 확장·종류 훨씬 많은데 현재 게임은 원작보다 데이터가 훨씬 적어"
+> **근거**: [`2026-08-20_원작밸런스_해독_매핑_v1.md`](./2026-08-20_원작밸런스_해독_매핑_v1.md)(매핑v1) · [`2026-08-22_원작배율_재추출_원본_v1.md`](./2026-08-22_원작배율_재추출_원본_v1.md)(재추출v1) · GodDem 코드 실측(C39, 아래 §3 파일 목록)
+> **절대 제약**: GodDem 레포(`E:\NerdNavis\GodDem`) Read만 수행, 수정 0건. Unity MCP 미사용. 본 문서가 유일 산출물.
+> **범위**: 조망(청사진) 수준. 세부 수치·CSV 설계는 축별 후속 단계(C50). 밸런싱 수치 변경 제안이 아니므로 "제안값" 표는 포함하지 않는다.
+> **표기 규칙(C5·C44)**: 🟢확정(코드/재추출 데이터 직접 실측) · 🟡추정(근거 있으나 미확정) · 🔴재추출 필요/미확보
+
+---
+
+## 0. 결론 요약
+
+PD 지적 2건은 하나의 근본원인으로 수렴한다 — **초기 「황야의 생존자」형 MVP 전환 시 원작의 다층(多層) 아웃게임 성장 아키텍처를 단일층으로 압착**했다. 이는 최근 종료된 공격력 2층 복원 사이클(`2026-08-22_공격력_원작2층_재설계_v2.md`)이 발견한 "정액 층 누락"과 **같은 패턴의 반복**이며, 이번엔 스탯 값 한 개가 아니라 **아키텍처 전체 스케일**에서 재발했다.
+
+- **지적②(능력치)의 실체**: 원작은 능력치를 5개 서로 다른 성장층(레벨·승급·장비·가챠·스킬)에 나눠 배치해 "점차 확장"되는 것처럼 느끼게 하는데, 우리는 이 5층을 인게임 매판강화 13종 트랙 **하나**로 뭉쳤다. 데이터 절대량 문제가 아니라 **층위가 눌린(flatten) 구조 문제**다.
+- **지적①(스테이지)의 실체**: 원작 웨이브 보상표(`teamwavepassreward`, 54단계·6주기)는 데이터 테이블 기반인데, 우리는 `EnemyBaseHp`·`StageStep`·`WaveStep`·`BossHpMultiplier` **4개 코드 상수**로 무한 반복시키고 있다(§3-3에서 실측 확인). "GodDem 자체의 기존 `StageBalance.csv`"(6구간)와 "원작 `teamwavepassreward`"(54단계)는 **서로 다른 두 테이블**인데 이번 과제 지시문에서 이름이 병치돼 있어, 본 문서 §1-3에서 이 둘을 명확히 분리한다.
+
+본 문서는 **무엇을 이식할지의 전체 지도**만 제시한다. "판마다 리셋되는 것"과 "영구히 남는 것"의 경계를 어디에 그을지가 2단계(system-designer 메타 재설계) 착수 전 핵심 결정 사항이며, §2-2에서 5층 각각에 대한 이식 옵션을 제시하되 **최종 채택은 확정하지 않는다**(C36 — 방향 수준 결정은 PD/system-designer 영역).
+
+---
+
+## 1. 원작 3축 아키텍처 조망
+
+### 1-1. 능력치 24종 — 분류·저항 대응·획득 층
+
+`heroskillattr.csv`(1011행, 매핑v1 §2-4) 기준 **24종 확정**(🟢). 재추출v1은 여기에 `hurt_add`의 별도 템플릿 변형 3개(`302/402/502`)를 더해 **effect code 기준 27종**으로 세분화했다(🟢, 재추출v1 §2-1) — "24종"은 attr(스탯 의미) 기준, "27종"은 effect code(값 템플릿) 기준으로 **집계 기준이 다를 뿐 모순은 아니다**.
+
+| 분류 | 능력치 | 저항(_res) 쌍 |
+|---|---|---|
+| **치명계** | `lucky_rate`(치명확률) · `lucky_multiple`(치명피해) | ✅ 각각 `_res` 존재 |
+| **특수효과계** | `stun_rate`(기절) · `suck_ratio`(흡혈) · `retaliate_rate`(반격) · `combo_rate`(연타) | ✅ 4종 전부 `_res` 존재 |
+| **공격계** | `attack_add` · `attack_speed_add` · `hurt_add` · `ele_hurt_add` · `penetrate_ratio` · `ele_penetrate_ratio` | 없음 |
+| **방어/체력계** | `hp` · `hp_add` · `defense_add` · `hurt_reduce` | 없음 |
+| **명중/회피계** | `hit_rate` · `dodge_rate` | 없음 |
+
+**24종 = 저항쌍 6종×2(12종) + 저항 없는 12종.** 저항(`_res`) 계열은 PvP(대인전) 전용이며, GodDem은 PvE 단일모드라 **비적용이 기존부터 타당**하다는 판단이 이미 있다(🟢, 재추출v1 §3 "lucky_multiple_res GodDem 미적용" 확정 근거를 6종 전체에 동일 적용). 즉 **PvE 이식 실질 대상은 18종**(24종 − 저항 6종)이다.
+
+**어느 층에서 획득되는가** — 5개 층에 다음처럼 분산된다(상세는 §1-2):
+
+| 층 | 관여 능력치 | 확정도 |
+|---|---|---|
+| 1층(레벨) | 진영별 재분배되는 기초 5스탯(구체 항목명은 원작 컬럼에 없음) | 🔴 미확보 |
+| 2층(승급) | 공/방/HP 3스탯 % 보너스 | 🟢 |
+| 3층(장비) | `attack`/`hp` 기본 + 슬롯별 파생(`attack_speed_add` 또는 `defense_add`) | 🟢 |
+| 4층(가챠) | `heroskillattr` 21종(prefix10~16 밴드, 장비 옵션 드로우풀) | 🟢 |
+| 5층(스킬) | `hp_add`·`attack_add`·`penetrate_ratio`·`ele_penetrate_ratio`·`hurt_add`·`ele_hurt_add` 6종(별도 scope 추정) | 🟡 |
+
+### 1-2. 아웃게임 성장 5층 — 역할·공식·상호작용·기여 경로
+
+| 층 | 역할 | 핵심 공식 | 상호작용 | 확정도 |
+|---|---|---|---|---|
+| **① 캐릭터 레벨**(`hero_level`, 1800행=12진영×150레벨) | 기초 스탯 총량 결정 | `stat(L)=0.22L²+0.26L` / EXP비용 `0.5L³+4.5L²` / 스탯예산 `450+50L`(선형) | 진영 12종은 계수합 **1.1001**(편차 0.05%)로 동일 예산 재분배 — 강약이 아니라 배분 차이 | 🟢(총량) / 🔴(5스탯 개별 분해식) |
+| **② 승급**(`hero_star`, 186행) | **레벨 상한 게이팅**(진짜 기능) + 소폭 % 보너스(부가) | 비용 `gold=quality×(star+1)³×(star+50)` / 보너스 `0.002×quality×star`(공/방/HP 동일) / 레벨캡 `5×(star+1)`, 150 클램프 | 레벨(①)이 진행되려면 승급으로 상한을 먼저 열어야 함 — **승급이 레벨의 문지기** | 🟢(비용·보너스) / 🟡(레벨캡 성29·30 2개 등급 불일치, 재검증 권고) |
+| **③ 장비**(`heroequipment`+`upgrade`+`forging`+`reforging`) | 슬롯별(2슬롯) 레벨업 강화 + 등급업(승급도박) + 재련(리롤 잠금) | 레벨배수 M(계단식 2차 16단계) × 등급배수(1/5/10/20/40/80) / 비용=`Base(quality)+V(level)` 가산분해 / 도박 rate `0.4/0.3/0.2/0.1`·비용×2등비 / 재련 잠금 `2^N` | subtype1(공격형)=`attack_speed_add` 파생, subtype2(방어형)=`defense_add` 파생(192행 전수) — **슬롯이 2차 스탯 종류를 결정** | 🟢 |
+| **④ 가챠/확률**(`heroequipmentskill`+`drawlib`+`drawtype`) | 장비 "옵션 슬롯"을 채우는 확률 추첨 | weight 등급별 `55.14/29.44/8.88/4.05/2.34/0.16%` / basis point 전풀 합10000 / 천장 `drawtype` 4단 중 2종만 실사용(`libid2need=9`·`libid3need=29`) | 장비 등급(quality)이 높을수록 확정 티어 지급 — **"등급"이 확률을 대체** | 🟢(가중치·천장 스케줄) |
+| **⑤ 스킬**(`heroskill`+`heroskilltree`) | 학습형 스킬 슬롯 — 학습 소모재화 곡선 + 스킬 자체 수치 | `heroskilltree` 소비수열 `50,100,…,1300`(20단계, 계단선형) | `heroskillattr` "87엔트리/6종"(히어로 기본 kit 추정 scope)은 §4층의 "882/21종"(장비옵션 scope)과 **다른 참조 경로** — 두 scope 혼동 금지(재추출v1 §1-2 명시 인계) | 🟢(소비곡선, 이미 우리 EXP커브로 이식 완료) / 🟡(87/6종 scope 추정) |
+
+**5층 간 인과 관계 요약**: ①이 스탯 총량의 "바닥"을 깔고, ②가 ①의 "상한"을 게이팅하며, ③은 ①·②와 독립적으로 슬롯 장비 자체를 강화하고, ④는 ③의 옵션 슬롯 내용물을 확률로 결정하며, ⑤는 ①~④ 전부와 독립적인 별도 학습 슬롯이다. **다섯 층 모두 "영구 누적, 수확체감 없음"이 전제**다(매핑v1 §6-3) — 이 점이 매판 리셋 설계와 정면으로 부딪히는 지점이며 §2에서 다룬다.
+
+### 1-3. 스테이지 구조 — 두 개의 다른 테이블 구분 (중요 사실관계 정정)
+
+이번 과제 지시문의 "원작 StageBalance 6구간·teamwavepassreward 54단계"는 **서로 다른 두 테이블을 병치**한 표현이다. 실측 결과:
+
+| 테이블 | 소속 | 구간 | 용도 | 확정도 |
+|---|---|---|---|---|
+| `StageBalance.csv`(6구간, HP 300→870→2610→7830→23490→70470) | **GodDem 자체 기존 자산**(매핑v1 §3-2) — Stage/Defense/Invasion/RandomBattle 등 **카드배틀 모드 전용**, Survival과 무관 | 6구간 | Survival이 아닌 다른 게임모드의 스테이지 밸런스 | 🟢(GodDem 코드, 원작 아님) |
+| `teamwavepassreward.csv`(216행) | **원작(Wild Survival) 데이터** | `dif` 54단계 = 6주기, 기본 `[2,50,100,200,350,500]`×등급배율 `[1.0,1.2,1.6,2.0]` | 웨이브 보상 티어 | 🟢(매핑v1 §2-8) |
+
+즉 "6구간"은 GodDem 자체 카드배틀 자산이고, "54단계"만 원작 Wild Survival 데이터다. PD 지적①("총 스테이지 구성을 원작과 동일하게")이 가리키는 실제 참고 대상은 **`teamwavepassreward`**로 좁혀 읽는 것이 정확하다. 다만 이 구분 자체가 이번 청사진의 발견 사항이라 PD 원 지적의 진의(GodDem 카드배틀 스테이지 구성을 참고하라는 의도였을 가능성 포함)를 배제하지 않으며, 후속 단계에서 확인이 필요하면 질의한다.
+
+**원작 스테이지·몬스터의 근본 한계 2건(창작 불가피 확정, 재추출로도 미해소)**:
+1. **원작에 "보스" 개념이 없다** — 현재 우리 게임의 "10웨이브 보스"는 순수 창작이며, 그 수치는 원작의 다른 규율("공격 유닛 HP 상한 13.33배", `A80ChampMatchConfig` §2-7)을 준용해 만든 것이다(매핑v1 §4(b)).
+2. **원작 몬스터 절대 스탯 원본이 없다** — `monsterteam[10001~10052]`가 추출본에 부재하며, 재추출v1도 2938개 번들·257개 TextAsset 전수 확인 결과 **동일하게 부재를 재확인**했다(🟢 부재 확정). 참고 가능한 것은 `monsterteamattr`(10행, 감쇠계수)와 `A80ChampMatchConfig`(34행, 4:1 비율)뿐이다.
+
+→ **몬스터·보스 축은 원작 이식이 원천적으로 불가능하며, 우리 창작 + 원작 규율(4:1 비율 등) 준용이 유일한 경로다.** 이 전제는 이미 태스크 지시에도 명시돼 있으며 본 청사진도 그대로 승계한다.
+
+**미확보 추가 발견**: `teamwavepassreward`의 `dif` 54단계 이후 게임이 종료되는지, 54단계를 상한으로 값이 반복되는지는 매핑v1·재추출v1 어디에도 명시가 없다(🔴 재추출 필요, §5에 등재). "총 스테이지 구성"을 원작과 맞추려면 이 반복 여부가 "유한 엔딩형"과 "유한 구간+무한 반복형" 중 어느 쪽을 이식할지의 전제가 되므로 우선순위가 낮지 않다.
+
+---
+
+## 2. 우리 게임 이식 매핑
+
+### 2-1. 장르 구조 차이 (매핑v1 §0 승계)
+
+| | 원작(Wild Survival) | 우리(GodDem Survival) |
+|---|---|---|
+| 장르 | 방치형 수집 RPG | 중앙 고정 웨이브 디펜스 로그라이크 |
+| 캐릭터 | 12진영×6등급×31성 다양성 | 1명 고정 |
+| 세션 | 수개월 누적, 방치 진행 | 1회 플레이(판) 단위 |
+| 성장 전제 | 영구 누적, 수확체감 없음(만렙 없음 전제) | 매판 리셋 + 그 위 영구 자산 |
+
+### 2-2. 경계 재정의 — 매판 리셋 ↔ 영구 성장, 5층 대응 옵션
+
+현재 구조(§3에서 코드로 재확인)는 다음과 같이 **압착**돼 있다:
+
+```
+[아웃게임(영구)] 장비 6부위, 스탯 2종(Attack/Hp)만
+        ↓ (시작 스탯에 가산)
+[인게임(매판 리셋)] 강화 13종 + 레벨/EXP(런스코프) + 레벨업 3택1 스킬드래프트
+```
+
+원작 5층을 이 압착 구조에 되돌리려면, 5층 각각이 "인게임 매판강화"와 "아웃게임 영구자산" 중 어느 쪽에 대응하는지 결정해야 한다. **층별로 자연스러운 대응 후보를 제시**한다(방향 확정은 PD/system-designer, C36):
+
+| 원작 층 | 이식 대응 후보 | 근거·특이사항 |
+|---|---|---|
+| **①레벨** | 아웃게임 신규 — "런 레벨 상한"의 **영구 확장 자원** 도입 검토 | 현재 `ExpTable`(20단계)은 레벨 20 이후도 코드가 막지 않고 마지막 값(1300)으로 무한 진행된다(🟢 실측, §3-3). 즉 "20레벨"은 설계 의도일 뿐 코드상 캡이 아니다 — ②(승급)의 게이팅 개념을 얹을 빈 자리가 이미 있다. |
+| **②승급** | 아웃게임 신규 — **레벨 상한 게이팅 토큰** | 원작 승급의 진짜 기능(레벨캡 게이팅, §1-2)을 그대로 이식하면 ①과 자연 결합 — "판마다 초기화되는 성장의 한계를, 영구 자산으로 늘려준다"는 메타 프로그레션 문법이 로그라이크 장르와 친화적. |
+| **③장비강화** | 아웃게임 확장 — 현 `SurvivalItemCatalog`(정적 값)에 **레벨업 강화축** 신설 | 현재 장비는 "장착"만 있고 "강화"가 없다(§3에서 확인). 원작의 Base+V 가산분해 문법을 그대로 재사용 가능(이미 인게임 §3층에서 검증된 패턴). |
+| **④가챠/확률** | 아웃게임 신규 — **장비 뽑기** 도입 여부는 별도 결정 | 현재 상점은 직접구매만(확률 없음). 원작 weight 모델은 이미 `SurvivalSkill.cs`가 인게임 스킬드래프트에 재사용 중이다(§3 확인) — 데이터 자체는 검증됐으나, 확률형 아이템 도입은 **과금·정책 이슈와 직결**되어 P23 기준 **PD님 확인 필요 영역**이다. |
+| **⑤스킬** | 아웃게임 신규 — 인게임 3택1 드래프트 스킬의 **영구 해금**(메타 프로그레션) | 원작 스킬트리(학습형)와 로그라이크의 "영구 업그레이드" 관용 패턴은 결이 다르므로 "구조는 참고, 수치는 재설계" 범주. `SurvivalActiveSkillRunner`(EerieVillage 이식 액티브 스킬 러너)가 이미 존재해 연동 지점 후보가 있다(🟡 상세 미조사, 범위 외). |
+
+**구현 시 유의사항(선반영 메모, 세부 설계 아님)**: 아웃게임에 `attack_add` 등과 같은 키를 쓰는 영구 강화축이 생기면, 현 `SurvivalUpgradeTable.Total(key)` 조회 방식과 **키 충돌** 위험이 있다(인게임 매판강화와 아웃게임 영구강화가 같은 `"attack_add"` 키를 참조하게 됨). 네임스페이스 분리(예: 아웃게임은 별도 프리픽스 또는 별도 클래스)가 후속 단계에서 필요하다.
+
+### 2-3. 능력치 18종(PvE 실질 대상) 배치 방향
+
+§1-1의 18종을 인게임(현 13종 보유)과 아웃게임(현 2종 보유)에 어떻게 나눌지는 2단계(system-designer)에서 결정할 사항이나, 참고로 현재 인게임 13종 vs 원작 18종의 차집합은 `hit_rate`·`ele_hurt_add`·`ele_penetrate_ratio`·`retaliate_rate`·`combo_rate`(5종, 인게임 미보유)이다(🟢 CSV 실측 대조, §3). 이 5종을 인게임에 추가할지, 아웃게임 전용으로 신설할지도 층 배치 결정에 연동된다.
+
+---
+
+## 3. 현재 대비 gap·재사용 가능분 (C39 코드 실측)
+
+실측 파일: `SurvivalMeta.cs` · `SurvivalItemCatalog.cs` · `SurvivalShopCatalog.cs` · `SurvivalUpgrade.cs`(+`SurvivalUpgrade.csv`) · `SurvivalSkill.cs` · `SurvivalBattleManager.cs` · `SurvivalLobbyController.Hero.cs`
+
+| 파일/시스템 | 현재 상태(실측) | 판정 | 근거 |
+|---|---|---|---|
+| **`SurvivalMeta.cs`** | 정적 클래스, JSON 별도 저장(`survival_meta.json`), `BaseAttack=22f`/`BaseHp=400f` 상수 + 장비 6슬롯 Owned/Equipped + 일일구매이력 + **`Version` 필드(마이그레이션 대비 이미 존재)** | ✅ **확장 기반으로 재사용** | 스키마 버전 필드가 이미 있어 신규 영구 레이어(레벨상한·승급토큰 등) 추가 시 필드만 늘리면 됨. 구조 자체는 원작 5층 중 어떤 것을 얹어도 수용 가능한 설계(대전형 `UserDataDTO`와 의도적으로 완전 분리된 이유가 문서화돼 있음). |
+| **`SurvivalItemCatalog.cs`** | 정적 9종, 부위 6종, **등급 1~2뿐**, 스탯 **Attack/Hp 2종뿐**, 합성(3개→1개, **100% 확정** 승급) | ⚠️ **확장 필요, 폐기 아님** | 원작 장비(6등급×레벨업 16단계) 대비 등급·스탯 다양성 극히 협소. 합성이 원작 승급도박(forging, 실패율 0.6~0.9)과 달리 무조건 성공 — 실패 요소 도입 여부는 재미(P30) 판단 필요. |
+| **`SurvivalShopCatalog.cs`** | 데일리딜5·젬팩6·골드팩3·오퍼2, **재화·장비 직접판매만(확률 요소 0)** | ⚠️ **재사용 + 확률형 레이어는 신규 판단 필요** | 원작 4층(가챠) 대응 요소가 전무. §2-2④ 참조 — 도입 여부는 PD 결정 영역. |
+| **`SurvivalUpgrade.cs`/`.csv`** | CSV기반 **13개 트랙**(`attack_add·attack·hp_add·hp·attack_speed_add·hurt_add·hurt_reduce·defense_add·lucky_rate·lucky_multiple·suck_ratio·dodge_rate·penetrate_ratio`) × 6단계, **매판 리셋** | ✅ **그대로 재사용 — "인게임" 정체성이 정확함** | 원작 heroequipmentskill 드로우풀(21종) scope를 근거로 이미 검증된 레이어(공격력 2층 사이클 완료). 코드 주석은 "12종"이라 쓰여 있으나 CSV 실측 결과 **13종**이 정확하다(🟡 주석 stale, 기능 결함 아님, 별건). |
+| **`SurvivalSkill.cs`** | 레벨업 3택1, 패시브 10종+액티브 1슬롯(EerieVillage 이식), 가중치 `5514/2944/888`(원작 weight 상위 3티어 그대로), **매판 리셋** | ✅ **그대로 재사용** | 원작 4층의 확률 모델을 이미 정확히 재사용 중인 유일한 레이어. 다만 "영구 계승"이 없다는 점이 원작 5층(스킬트리)과의 차이 — §2-2⑤ 참조. |
+| **`SurvivalBattleManager.cs`(Stage/Wave)** | `EnemyBaseHp`(42)·`StageStep`(2.1)·`WaveStep`(1.04)·`BossHpMultiplier`(8) **4개 코드 상수**로 계단형 지수 계산, `WavesPerStage=10`마다 보스, **Stage 무한 증가(상한 코드 없음)** | ⚠️ **구조 확장 필요(데이터화)** | 원작처럼 유한 구간·데이터 테이블 기반으로 바꾸려면 CSV화(`EnemyWaveBalance.csv`, 매핑v1 §5 이미 제안) 필요. 수식의 "형태"(계단형 지수)는 재사용 가능하나 "무한 반복"이라는 성격 자체를 바꿀지가 §1-3 미확보분(54단계 이후 반복 여부)에 달려 있다. |
+| **`SurvivalLobbyController.Hero.cs`** | 장비 6슬롯 UI + 능력치(Attack/Hp) 표시만 — **레벨·승급·스킬트리 UI 자체가 없음** | 신규 UI 필요 | 아웃게임에 신규 층 추가 시 이 화면(또는 별도 화면) 확장 필수. UX 영역(ux-designer) 후속 협의 대상. |
+| `SurvivalActiveSkillRunner` 등 Skills 폴더 | EerieVillage 이식 액티브 스킬, 원작에 대응 수치 없음(매핑v1 §6-4 "틀은 있고 데이터는 비었다") | 범위 외, 현행 유지 | 본 청사진 범위 밖(과제 지시 3축에 미포함). §2-2⑤에서 연동 후보로만 언급. |
+
+---
+
+## 4. 단계 분할 제안
+
+PD 지시 로그(§21)의 3단계 구획을 아래처럼 세분화한다. 각 Phase는 C49(팀장 설계→팀원 작업→팀장 검증)를 따르며, Phase 간 착수는 이전 Phase 완료·PD 확인을 전제로 한다(일정 아님, C9).
+
+| Phase | 산출물 | 규모 추정(근거) | 선행 조건 |
+|---|---|---|---|
+| **P1(본 문서)** | 이식 청사진(조망) | 완료 | — |
+| **P2** | system-designer 메타 아키텍처 재설계 — §2-2의 5층 대응 옵션 중 실제 채택안 확정, 신규 영구 레이어의 데이터 스키마(클래스·CSV 컬럼) 설계 | 중(옵션 비교·PD 확인 지점 다수 — §2-2④ 가챠 도입 여부가 최대 분기점) | 본 문서 PD 확인 |
+| **P3-A** | 능력치 축 확장 — §2-3의 인게임 5종 격차 해소 + 아웃게임 스탯 종류 확장 (balance-designer 수치) | 소(기존 13종 트랙 패턴 재사용, 신규 5종 추가 수준) | P2 확정 |
+| **P3-B** | 아웃게임 성장 층 구현 — 채택된 층(레벨상한/장비강화/가챠/스킬영구화 중 확정분)의 실제 수치·CSV | 중~대(층 개수에 비례, §2-2 결정에 따라 가변) | P2 확정 |
+| **P3-C** | 스테이지 구조 데이터화 — 4상수 하드코딩 → CSV 테이블 전환, §1-3 미확보분(54단계 반복 여부) 해소 후 유한/무한 형태 확정 | 중(기존 계단형 지수 형태 재사용, 데이터 이관 작업) | P2 확정 + §5 재추출 |
+
+**세부 수치는 각 Phase 착수 시점에 별도 C50 승인을 받는다.** 본 문서는 P1 완료 시점의 조망까지만 다룬다.
+
+---
+
+## 5. 재추출 필요 데이터 표시
+
+| 항목 | 현재 확보 상태 | 우선순위 | 사유 |
+|---|---|---|---|
+| `teamwavepassreward` dif 54단계 **이후 반복 여부** | 🔴 미확보(매핑v1·재추출v1 모두 미언급) | **높음** | P3-C(스테이지 유한/무한 형태 결정)의 직접 전제 조건 |
+| `hero_star.csv`(186행) 레벨캡 성29·30 **2개 등급 불일치** 재검증 | 🟡 추정(불일치 확인됐으나 원인 미규명) | 중(P2에서 승급 게이팅 채택 시 선행) | 매핑v1 §2-2 자체가 "12행 불일치, 재실측 확인" 필요라 표기 |
+| `heroequipment`/`heroequipmentupgrade` 계단식 M수열(16단계) 원본 CSV 재대조 | 🟡 추정(패턴 확인됐으나 ⚠️ 절 표기) | 중(P3-B 장비강화 채택 시 선행) | 매핑v1 §6-5 "실제 PM 감사 적발 오류 4건 전부 ⚠️ 절에서 발생" 경고 이력 — 공격력 트랙도 동일 경로로 재추출 필요했던 전례 |
+| `heroequipmentforging`(승급도박) rate 원본 재대조 | 🟡 추정 | 중(P3-B에서 도박 요소 채택 시에만) | 상동 |
+| `hero_level` 진영별 **5스탯 개별 분해 공식** | 🔴 미확보(계수합 1.1001만 확인, 개별 배분비는 어느 문서에도 없음) | **낮음** | 이미 4:1 유도 방식을 채택한 선례(공격력 2층 사이클 §5-3)가 있어 이 분해식 없이도 진행 가능 — 참고용으로만 재추출 가치 있음 |
+| 원작 `monsterteam[10001~10052]` | 🔴 부재 확정(2회 재확인, 재추출 무의미) | **해당 없음** | 재추출로 해소되지 않는 항목 — 창작 전제 확정(§1-3) |
+
+---
+
+## 6. 리스크
+
+| ID | 리스크 | 심각도 | 내용 |
+|---|---|---|---|
+| R-A1 | 스테이지 유한/무한 결정 지연 | 중 | §5 "54단계 이후 반복 여부" 미확보 상태로 P3-C를 서두르면 다시 "임의 결정 후 재작업"이 반복될 소지(공격력 2층 사이클의 재추출 필요성과 동일 패턴) |
+| R-A2 | 네임스페이스 충돌 | 중 | §2-2 유의사항 — 아웃게임 영구축과 인게임 매판축이 같은 키(`attack_add` 등)를 쓰면 `SurvivalUpgradeTable.Total()` 조회가 오염됨. P2 설계 시 최우선 반영 필요 |
+| R-A3 | 가챠 도입 시 정책 리스크 | 중~높음(미확정) | §2-2④ — 확률형 아이템은 국내 게임법상 확률 표시 의무 등 정책 이슈 동반. P23 기준 PD 확인 없이 balance-designer 단독 진행 불가 |
+| R-A4 | 5층 전체 동시 착수 시 검증 부하 | 중 | P3-A~C를 병렬로 몰면 플레이테스트·plan-auditor 검증 큐가 동시에 밀림 — P32 원칙대로 축별 순차 진행 권고 |
+| R-A5 | ⚠️ 절 재발 패턴 | 낮음(주의) | 매핑v1 §6-5 스스로 경고했듯 미검증(⚠️) 절에서 실제 오류가 반복 발생했다(공격력 트랙 사례). §5의 🟡 표기 3건은 세부 설계 착수 전 반드시 원본 재대조 권고 |
+
+---
+
+## 7. 기각안 (C32)
+
+| # | 검토안 | 기각 사유 |
+|---|---|---|
+| 1 | 5층 전체를 이번 1단계 문서에서 세부 수치까지 확정 | PD 지시·PM 접근 방침이 이미 "1단계 조망 → 2단계 메타 재설계 → 3단계 축별 구현"으로 분할했다(C50, PD 지시 로그 §21). 조망 단계에서 세부 수치를 결정하면 이후 재설계 시 재작업 위험이 커진다. |
+| 2 | §2-2 5층 대응안을 balance-designer가 이 문서에서 즉시 확정 | C36(PM/디자이너 자율판단 범위 상한) — 특히 ④가챠 도입 여부는 기존 확정 방향의 외연을 넘어서는 결정(과금·정책 연동)이라 PD 확인 없이 확정 금지. 옵션 제시까지만 수행. |
+| 3 | "StageBalance 6구간"을 원작 데이터로 그대로 받아들여 청사진에 원작 자산으로 기재 | §1-3 실측 결과 GodDem 자체 카드배틀 자산으로 확인됨(원작 아님). 사실과 다르게 기재하면 후속 단계가 잘못된 전제 위에 서게 되어(C44 팩트 우선) 정정해 명시했다. |
+| 4 | 본 문서 산출 직후 즉시 plan-auditor 호출 | bt-planning-fun "밸런스 수치 변경·중요 결정 응답 전 권장"에 해당하나, 본 문서는 구체 수치 변경 제안이 없는 조망 문서다. 즉시 호출 대신 **2단계(system-designer 메타 재설계) 착수 전 교차검증을 권고**하는 것으로 완화(§9). |
+| 5 | 원작 24종 능력치를 18종(PvE)이 아닌 24종 전체 이식 전제로 설계 | §1-1 — 저항(`_res`) 6종은 PvP 전용이며 GodDem은 PvE 단일모드. 기존에 이미 동일 판단(재추출v1 §3, `lucky_multiple_res` 미적용)이 있어 일관성 유지 차원에서 18종을 실질 대상으로 삼았다. 추후 PvP 모드가 생기면 재검토 대상. |
+
+---
+
+## 8. 변경 이력 (P16)
+
+| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 |
+|---|---|---|---|---|---|
+| 2026-08-22 | balance-designer | 문서 신규 작성(v1) | — | 본 문서 전체 | PD 지시 "원작 데이터 아키텍처 전면 이식이 맞아" 1단계 집행 |
+
+---
+
+## 9. 후속 조치 (본 문서 범위 밖)
+
+1. **PD 확인**: 본 청사진의 3축 조망·§2-2 5층 대응 방향(특히 ④가챠 도입 여부)이 P2 착수 전제로 타당한지.
+2. **plan-auditor 교차검증 권고**(기각안4): 즉시 호출 대신 P2(system-designer 메타 재설계) 착수 전 1회 권고.
+3. **개발팀장 재추출**(§5 우선순위 순): ①`teamwavepassreward` 반복 여부 ②`hero_star` 레벨캡 불일치 ③`heroequipment`/`forging` 원본 재대조 — P3-B·C 착수 전 선행.
+4. **system-designer 위임**(P2): §2-2 옵션 비교표를 입력으로 메타 아키텍처 실제 스키마 설계.
+5. **PM 공유**: 본 문서 산출 완료를 `개발팀_PD_지시_로그.md`(GodDem/BT13 단일 관리 확정, 기획팀 로그 중복 등록 없음) 및 대화로그에 반영.

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

@@ -84,3 +84,16 @@
 - **PD 결정 2건**: ①"원작 데이터 아키텍처 전면 이식이 맞아" (특정 축 아닌 전면) ②"그냥 이대로 진행해" (세션 전환 안 함·현 세션 유지 — PM 세션 정리 권고 기각)
 - **접근 (P32 맥락 분할·C50 대규모)**: 1단계 원작 아키텍처 이식 청사진(조망) → 2단계 system-designer 메타 재설계 → 3단계 축별 단계 구현(능력치→아웃게임 층→스테이지). 세부 수치는 축별 후속, 각 단계 C50 승인
 - **착수**: balance-designer 이식 청사진 1단계 (원작 3축 조망·이식 매핑·gap·단계 분할·재추출 필요분, 진행중). 산출 예정 `2026-08-22_원작아키텍처_이식청사진_v1.md`
+
+## 22. 원작 데이터 아키텍처 이식 청사진 1단계 — 완료 (balance-designer, GodDem 수정 0건)
+
+- **작업**: 매핑v1·재추출v1 Read + GodDem 코드 실측(`SurvivalMeta.cs`·`SurvivalItemCatalog.cs`·`SurvivalShopCatalog.cs`·`SurvivalUpgrade.cs`+csv·`SurvivalSkill.cs`·`SurvivalBattleManager.cs`·`SurvivalLobbyController.Hero.cs`, C39)로 원작 3축(능력치 24종·아웃게임 5층·스테이지) 조망 + 이식 매핑 + gap 판정 + 단계 분할 + 재추출 필요분을 정리.
+- **핵심 발견 1(근본 재확인)**: PD 지적 2건은 "초기 MVP 전환 시 원작 다층 아웃게임 성장 아키텍처를 단일층으로 압착"한 동일 근본의 재발 — 공격력 2층 사이클(§15~20)의 "정액층 누락"과 같은 축소 패턴이 아키텍처 스케일에서 반복. 원작 5층(레벨·승급·장비·가챠·스킬)이 현재 아웃게임 1층(장비 6부위, Attack/Hp 2스탯만, `SurvivalItemCatalog` 실측 확인)으로 눌려 있음.
+- **핵심 발견 2(사실관계 정정)**: 과제 지시문의 "StageBalance 6구간·teamwavepassreward 54단계"는 **서로 다른 두 테이블**. `StageBalance.csv`(6구간)는 GodDem 자체 기존 카드배틀 자산(원작 아님, 매핑v1 §3-2), `teamwavepassreward`(54단계)만 원작 데이터. 스테이지 축은 실제로 `SurvivalBattleManager.cs`의 4개 코드 상수(`EnemyBaseHp`·`StageStep`·`WaveStep`·`BossHpMultiplier`)로 무한반복 구현되어 있음을 실측 확인(§27:35-39 코드).
+- **핵심 발견 3**: `SurvivalBattleManager.cs` `ExpTable`(20단계, 원작 heroskilltree 소비수열 정확 이식 재확인)이 레벨 20 이후 코드상 캡 없이 마지막 값(1300)으로 무한 진행 — 원작 승급(레벨상한 게이팅)을 얹을 빈 자리가 이미 있음을 확인, §2-2 이식 옵션(레벨상한 게이팅)의 근거로 채택.
+- **이식 매핑(옵션 제시, 미확정 — C36)**: 원작 5층을 ①레벨→아웃게임 런레벨상한 확장 후보 ②승급→상한 게이팅 토큰 ③장비강화→`SurvivalItemCatalog` 레벨업축 신설 ④가챠→장비뽑기(**PD 결정 영역**, 과금정책 연동) ⑤스킬→인게임 3택1의 영구해금(메타프로그레션)으로 대응 후보 제시. 최종 채택은 2단계(system-designer 메타 재설계)에서 결정.
+- **gap·재사용 판정**: `SurvivalMeta.cs`(Version 필드 이미 존재 — 확장 기반 재사용 우수) · `SurvivalUpgrade.cs`+csv(13종 확정, 코드주석 "12종"은 stale·기능결함 아님) · `SurvivalSkill.cs`(원작 weight 모델 이미 정확 재사용 중) 전부 **재사용 판정**. `SurvivalItemCatalog.cs`(등급1~2·스탯2종뿐)·`SurvivalShopCatalog.cs`(확률요소 0)·Stage/Wave(코드상수 4개) = **확장 필요** 판정.
+- **기각안 5건**(C32): ①본 1단계에서 세부수치까지 확정 — 기각(C50 단계분할 기지시, 재작업 위험) ②§2-2 5층 대응안 즉시 확정 — 기각(C36, 특히 가챠는 PD 확인 영역) ③"StageBalance 6구간"을 원작 자산으로 그대로 기재 — 기각(실측 결과 GodDem 자체 자산, C44 정정) ④문서 산출 직후 즉시 plan-auditor 호출 — 기각(구체 수치변경 없는 조망 문서라 2단계 착수 전 권고로 완화) ⑤24종 전체를 PvE 이식 대상으로 전제 — 기각(저항 `_res` 6종 PvP전용, 기존 판단과 일관성 유지해 18종을 실질 대상으로 함).
+- **재추출 필요 표시(우선순위순)**: 높음=`teamwavepassreward` 54단계 이후 반복 여부(미확보, 스테이지 유한/무한 결정 전제) / 중=`hero_star` 레벨캡 성29·30 불일치·`heroequipment`/`forging` 원본 재대조(⚠️ 절 이력상 재발 패턴 경고) / 낮음=`hero_level` 5스탯 개별분해식(4:1 유도 선례로 우회 가능) / 해당없음=`monsterteam`(부재 확정, 재추출 무의미).
+- **산출물**: `공유/기획/GodDem/2026-08-22_원작아키텍처_이식청사진_v1.md` (GodDem 레포 Read만, 수정 0건, Unity MCP 미사용).
+- **후속 조치**: PD 확인(3축 조망·§2-2 대응방향·가챠 도입 여부) · plan-auditor 교차검증 권고(2단계 착수 전) · 개발팀장 재추출(우선순위순 3건) · system-designer 위임(2단계 메타 아키텍처 설계) · PM 공유(`개발팀_PD_지시_로그.md` 단일관리 기존 방침 유지, 기획팀 로그 중복등록 없음).