26 KiB
GodDem 원작 데이터 아키텍처 전면 이식 청사진 v1
작성: balance-designer(기획팀) 2026-08-22 · 1단계 산출물 (P32 맥락 분할 · C50 대규모 승인분) PD 지시 원문 (C42-2 A, 2026-08-22): "원작 데이터 아키텍처 전면 이식이 맞아" / "그냥 이대로 진행해"(세션 유지) PD 지적 원문 2건: ①"총 스테이지 구성 등을 원작 게임과 동일하게 맞춰" ②"원작은 능력치가 아웃게임을 통해 점차 확장·종류 훨씬 많은데 현재 게임은 원작보다 데이터가 훨씬 적어" 근거:
2026-08-20_원작밸런스_해독_매핑_v1.md(매핑v1) ·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·BossHpMultiplier4개 코드 상수로 무한 반복시키고 있다(§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건(창작 불가피 확정, 재추출로도 미해소):
- 원작에 "보스" 개념이 없다 — 현재 우리 게임의 "10웨이브 보스"는 순수 창작이며, 그 수치는 원작의 다른 규율("공격 유닛 HP 상한 13.33배",
A80ChampMatchConfig§2-7)을 준용해 만든 것이다(매핑v1 §4(b)). - 원작 몬스터 절대 스탯 원본이 없다 —
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. 후속 조치 (본 문서 범위 밖)
- PD 확인: 본 청사진의 3축 조망·§2-2 5층 대응 방향(특히 ④가챠 도입 여부)이 P2 착수 전제로 타당한지.
- plan-auditor 교차검증 권고(기각안4): 즉시 호출 대신 P2(system-designer 메타 재설계) 착수 전 1회 권고.
- 개발팀장 재추출(§5 우선순위 순): ①
teamwavepassreward반복 여부 ②hero_star레벨캡 불일치 ③heroequipment/forging원본 재대조 — P3-B·C 착수 전 선행. - system-designer 위임(P2): §2-2 옵션 비교표를 입력으로 메타 아키텍처 실제 스키마 설계.
- PM 공유: 본 문서 산출 완료를
개발팀_PD_지시_로그.md(GodDem/BT13 단일 관리 확정, 기획팀 로그 중복 등록 없음) 및 대화로그에 반영.