50 KiB
GodDem 아웃게임 메타 아키텍처 재설계 v1 (P2 — 골격)
작성: system-designer(기획팀) 2026-08-22 · 2단계 산출물 (P32 맥락 분할 · C50 대규모 승인분) PD 지시 원문 (C42-2 A, 2026-08-22): "원작 데이터 아키텍처 전면 이식이 맞아" / "원작대로 가챠 도입" / "현 세션 P2 계속" 입력 문서:
2026-08-22_원작아키텍처_이식청사진_v1.md(청사진v1, balance-designer P1) ·2026-08-22_원작배율_재추출_원본_v1.md(재추출v1) ·2026-08-20_원작밸런스_해독_매핑_v1.md(매핑v1) 절대 제약: GodDem 레포(E:\NerdNavis\GodDem) Read만 수행, 수정 0건. Unity MCP 미사용. 본 문서가 유일 산출물. 범위: 메타 아키텍처 골격(각 층 역할·상호작용·데이터 스키마 구조). 세부 수치·CSV 실제 값 채움은 P3 축별 단계(C50). 표기 규칙(C5·C44): 🟢확정(코드/문서 직접 실측) · 🟡추정(근거 있으나 미확정) · 🔴재추출 필요/미확보 ·TBD(Px)= 후속 단계 수치 결정 자리 감사 이력(C35): plan-auditor 모드A 1회 수행 — 판정 조건부통과(Critical 2·Major 6·Minor 4). 본 v1은 그 지적을 전부 반영한 최종본이다(§11).
0. 결론 요약
청사진v1이 제시한 5층 대응 후보(§2-2)를 전부 채택하고 실제 스키마를 확정한다. 핵심 설계 원칙 1개로 5층 전체를 관통시켰다:
인게임(매판 리셋)은 "이번 판 빌드 다양성", 아웃게임(영구)은 "계정 장기 성장"을 담당한다. 같은 스탯을 양쪽에 중복 배치하지 않는다 — 인게임에 이미 기능 중인 것은 그대로 두고, 원작에 있지만 우리 게임에 아직 없는 것만 아웃게임 5층에 새로 배치한다.
청사진 §2-3 정정(C44): "인게임 미보유 5종"은 재검증 결과 6종이다 — stun_rate가 누락돼 있었다(§2-1).
결합 구조 정정(plan-auditor C-1 반영): 아웃게임→인게임 결합은 "1곳"이 아니라 Attack/Hp 조회 3개 호출부 + Defense 채널 1개 호출부, 총 4곳이다. 이를 각 스탯별 단일 계산 메서드(SurvivalMeta.FinalAttack()/FinalHp()/TotalDefenseRatio())로 캡슐화해 호출부가 몇 개든 공식은 한 곳에서만 정의되도록 한다(§3-4) — 이 캡슐화 자체가 이 코드베이스가 반복 겪은 "3중 SOT" 결함 패턴(SurvivalMeta.cs 자체 주석이 경고하는 바로 그 패턴)의 재발을 막는 설계 장치다.
| 항목 | 결론 |
|---|---|
| 5층 채택 | ①레벨→"영웅레벨"(신규 영구) ②승급→레벨 게이팅+3스탯 보너스(신규 영구) ③장비강화→per-item 레벨업(SurvivalItemCatalog 확장) ④가챠→장비 확률 획득(전면 신규, PD 확인 완료) ⑤스킬→마스터리 영구 해금(SurvivalActiveSkillRunner 연동, 드래프트 풀 필터링 방식으로 확정) |
| 능력치 18종 배치 | 인게임 기능 11종 유지 + 인게임 사장(死藏) 1종(penetrate_ratio) ⑤로 이관 + 완전 신규 6종을 ④가챠 4종 확정(hit/stun/retaliate/combo) + ⑤스킬마스터리 2종 확정(ele_hurt_add·ele_penetrate_ratio — P3-A 재추출로 ④ 가설 반증·⑤ 확정, 정직 한계: 원작 positive 사용 근거 아님, §2-2 상세) |
| 경계 재정의 | "판 시작 전 확정 vs 판 진행 중 리셋" 시점 기준. 네임스페이스 충돌은 클래스 분리+CSV 키 접두+단일 계산 메서드 캡슐화 3중 방지 |
| 재사용/확장 | SurvivalMeta(확장 기반)·SurvivalUpgrade(불변 재사용)·SurvivalSkill(불변+조건부 확장) / SurvivalItemCatalog·SurvivalShopCatalog(구조 확장 필요 — 확률 지급물 미지원 확인) / 신규 클래스 4·CSV 7종 |
| 미확정 이관 사항(PD/개발팀 영역, §10) | 가챠 소비 재화(골드 vs 젬, 🔴 원작 근거 부재) · defense 클램프 공유 방식. (해소 2026-08-22) ele_* 2종 최종 층 — P3-A 재추출로 ⑤ 확정 완료(§2-2) |
| P3 분할 | P3-A(능력치 정리) → P3-B1(레벨+승급) → P3-B2(장비강화, 원본 재대조 선행) → P3-B4(스킬마스터리) → P3-B3(가챠, PD 정책 확인 후) → P3-C(스테이지, 병렬 가능) |
1. 5층 재설계 확정
1-0. 표기 원칙 — 인게임과 아웃게임의 이름을 분리한다
현재 코드에 이미 "Level"이라는 이름이 인게임에서 쓰이고 있다 (SurvivalBattleManager.Level, EXP 20단계, 매판 리셋, 레벨업마다 스킬 3택1). 이것은 원작 ①레벨(hero_level, 스탯 총량 공식)의 이식이 아니라 원작 ⑤스킬(heroskilltree EXP 소비 곡선)의 이식이다(🟢, ExpTable = {50,100,...,1300} 20단 수열이 매핑v1 §2-8 heroskilltree 수열과 정확히 일치 — 코드 주석도 이를 명시). 따라서 신규 영구 레이어에 "레벨"이라는 이름을 그대로 쓰면 기존 인게임 "Level"과 혼동된다.
본 문서부터 용어를 분리한다:
| 용어 | 소속 | 실체 |
|---|---|---|
| 런레벨(RunLevel) | 인게임, 기존, 불변 | SurvivalBattleManager.Level — 원작 ⑤스킬 EXP곡선의 이식체, 매판 리셋 |
| 영웅레벨(HeroLevel) | 아웃게임, 신규(본 문서 Layer①) | 원작 ①레벨(hero_level) 스탯총량 공식의 이식체, 영구 누적 |
1-1. Layer① 영웅레벨(HeroLevel) — 아웃게임 신규
재미 근거(P30): 판을 거듭할수록 "이번 판 시작점 자체"가 조금씩 높아진다는 감각 — 로그라이크의 매판 완결성(이번 판은 이번 판대로 승부)을 해치지 않으면서, 계정을 오래 키운 유저가 신규 유저보다 항상 유리한 출발선을 갖는 장기 동기(수집·성장 게임의 핵심 재미축)를 제공한다. 청사진이 지적한 "능력치가 점차 확장되는 느낌"의 가장 직접적인 담당 층.
역할: 판 시작 전 이미 확정된 공격력/체력 "바닥"을 영구히 높인다. 원작 stat(L)=0.22L²+0.26L(2차) 구조를 형태만 재이식한다(원작 1800행 절대치는 규모 불일치로 폐기, 매핑v1 §0 원칙 승계).
- 획득 조건: 소비 재화
TBD(P3-B1)(디폴트 권고: 신규 중간재 도입 없이 기존 골드(GOLD_ID=201) 직접 소비 — 원작의 골드→경험서→소비 2단 경제를 스킵. 중간재 도입 필요성은 balance-designer 열린 이슈). - 비용 곡선: 원작 3차식(
0.5L³+4.5L²) 형태만 재사용, 절대값은TBD(P3-B1). - 산출:
AttackBudget(HeroLevel)·HpBudget(HeroLevel)2개 함수 — 기존SurvivalMeta.BaseAttack/BaseHp상수는HeroLevel=0앵커로 유지하고, HeroLevel 상승분은 그 위에 가산되는 증분으로 취급(§3-4). - 상한: 정정(2026-08-22, PD 결정) — 최초 초안은 "없음(원작 '수확체감 없음' 원칙 승계)"이었으나, PD가 P3-B1(balance-designer)의 유한 캡 설계를 "우선 원작처럼 맞춰 전체 밸런싱 동일성 확인 후 추후 변경할 부분을 지시할게"로 확정 승인해(대화로그
공유/대화로그/GodDem/2026-08-22.md§31) 현재 콘텐츠 캡 60/11(HeroLevel 1~60·PromotionStar 0~11, 동일 공식으로 CSV 행 추가 시 확장 가능)로 정정한다. "수확체감 없음"은 레벨당 예산(§3-2 선형,AttackBudget=2×L류)이 줄어들지 않는다는 뜻이지 레벨 수 자체가 무한하다는 뜻이 아니었다 — 최초 서술이 이 둘을 혼동했다(원작도 실제로는 150레벨에서 멈춘 유한 시스템이었다,2026-08-22_P3B1_레벨승급_설계_v1.md§0). Layer②가 열어주지 않으면 다음 구간 진입 불가라는 게이팅 관계 자체는 불변.
1-2. Layer② 승급(Promotion) — 아웃게임 신규
재미 근거(P30): 영웅레벨 하나만 있으면 "돈 모아서 계속 누르는" 단조 곡선이 된다. 승급이라는 별도 게이팅 자원을 끼워 넣으면 "지금 승급을 더 할까, 레벨을 더 올릴까"라는 자원 배분 선택이 아웃게임에도 생긴다 — 원작이 이미 검증한 문지기 문법(매핑v1 §2-2)을 그대로 가져와 로그라이크 장르에도 자연스러운 "메타 프로그레션 우선순위 선택" 재미를 만든다(청사진 §2-2② 근거 승계).
역할: 원작의 진짜 기능(레벨 캡 게이팅)을 그대로 이식한다. Layer①의 "문지기".
- 공식 형태만 재사용(절대 계수는 원작 그대로 쓰지 않는다 — 매핑v1 §0 "그대로 복사하면 자릿수가 터진다" 경고 대상이므로
TBD(P3-B1)로 유보): 비용gold=quality×(star+1)³×(star+50)꼴(4차) / 보너스k×quality×star꼴(선형, 공/방/HP 계수 동일) / 레벨캡k'×(star+1)꼴(선형 게이팅). - 재실측 선행 필수: 매핑v1 §2-2 자체가 "성29·성30 레벨캡 12행 불일치, 재검증 필요"를 🔴로 남겼다 — 본 층 채택 시 재실측이 P3-B1의 직접 선행 조건이다(청사진 §5 우선순위 승계).
- 보너스 3스탯 유지: 원작 실측(매핑v1 §2-2 "공/방/HP 3스탯 항상 동일값, 186행 검증 True")을 존중해 attack/hp뿐 아니라 defense도 포함한다. 단 이는 아웃게임에 처음으로
defense채널을 들여오는 지점이며, 인게임에 이미defense_add가 있어 결합식이 RecalcPlayer 쪽에도 필요하다(§3-3·§3-4·§7 R-B2에서 정면 처리 — "RecalcPlayer 무변경" 같은 과장된 주장을 하지 않는다).
1-3. Layer③ 장비강화(Equipment Upgrade) — SurvivalItemCatalog 확장
재미 근거(P30): 지금은 장비를 "얻으면 끝"이라 수집 자체가 목표의 전부다. 개별 장비에 강화축이 생기면 "어느 장비를 밀어줄까"라는 2차 선택이 생겨 같은 9종 장비라도 유저마다 다른 투자 경로가 나온다 — 수집(④가챠)과 육성(③강화)이 분리된 2단계 동기 구조는 원작뿐 아니라 이 장르(수집형 강화 게임) 전반의 표준 재미 축이다.
역할: 현재 정적인(레벨 개념 없는) 9종 장비 각각에 개별 강화축을 신설한다. 원작 Base(quality)+V(level) 완전 가산 분해(매핑v1 §2-3, SurvivalUpgrade.cs가 이미 검증한 패턴과 동일 구조)를 재사용한다.
- 강화 대상: itemId 단위(슬롯 단위 아님) — 원작이
heroequipment개별 ID에 레벨을 매기는 것과 동일. 슬롯 단위로 하면 "어떤 장비를 껴도 같은 강화치"가 되어 수집 동기가 약화된다(§8 기각안3). - 소비 재화: 골드(기존
GOLD_ID) — 원작 그대로. - 슬롯 종속 2차 스탯(매핑v1 §2-3 "슬롯 종속" 규칙 재사용): 원작 subtype1(공격형)=
attack_speed_add파생, subtype2(방어형)=defense_add파생. 우리 6슬롯에 이 규칙을 적용하면 슬롯마다 주 스탯(Attack 또는 Hp) 외에 부 스탯 1종이 함께 오른다. 슬롯→부스탯 매핑표는TBD(P3-B2). - 재실측 선행 필수(청사진 §5 R-A5 승계):
heroequipment/heroequipmentupgrade계단식 M수열(16단계) 원본 CSV 재대조가 P3-B2의 직접 선행 조건이다 — 매핑v1 §6-5가 "실제 PM 감사 적발 오류 4건 전부 ⚠️ 절에서 발생"이라 경고한 바로 그 절(⚠️ 표기)이며, 공격력 트랙도 동일 경로로 재추출이 필요했던 전례가 있다. - 아이템 융합(TryFuse)과의 상호작용 미정의(엣지 케이스):
EquipLevel[itemId]>0인 장비가 융합 재료로 소모돼Owned=0이 되면 투자한 강화분이 고아(orphan)가 된다. 기본 권고: 강화분>0 아이템은 융합 차단(경고 후 확인) — 최종 결정은 P3-B2(§7 R-B3). - 레벨업 vs 승급도박(forging) 분리 여부: 원작은 레벨업(확정)과 등급업(도박, 실패율 0.6~0.9)이 별도 축이다. 현재
TryFuse()는 무조건 성공(도박 요소 0). 도박 요소 도입 여부는 재미(P30) 판단이 필요한 열린 이슈 — 본 문서는 구조 자리만 마련, 채택은 P3-B2.
1-4. Layer④ 가챠(Gacha) — 전면 신규 (PD 도입 확정)
재미 근거(P30): "이번에 뭐가 나올까"라는 확률 기대감은 확정 구매(현 상점)에 없는 재미축이다. 원작이 이미 등급별 확정 지급(quality↑ = 하위 결과 배제)으로 "실패해도 손해는 아니다"라는 안전판을 설계해뒀다 — 이를 그대로 가져오면 신규 재미축 도입과 동시에 "질렀는데 완전 꽝"이라는 이탈 유발 요소를 피할 수 있다.
역할: 장비를 확률로 획득하는 새 채널을 추가한다(기존 상점 직접구매를 대체하지 않음 — §4).
- 가중치 모델: 원작
heroequipmentskill(매핑v1 §2-5) 구조 재사용 — 전 풀 합 10000 basis point 강제(매핑v1 §2-6 채택 원칙 재사용). 정정(plan-auditor m-3): 이 "합 10000 강제"는 인게임에서 이미 검증된 관행이 아니라 본 층이 이 프로젝트에서 처음 실제로 도입하는 계약이다 —SurvivalSkill.cs의GradeWeight={5514,2944,888}는 합이 9346이며RollGrade()가 그 실제 합으로 정규화하는 방식이라(🟢 실측), "합 10000 고정"을 따르고 있지 않다. 가챠(Layer④)에서 이 규율을 처음 실제로 강제하고, 인게임 드래프트 쪽 정합 여부는 본 문서 범위 밖(별건). - 천장(pity): 원작
drawtype은 4단이나 18행 중 4행만 실사용·스케줄 2종뿐(매핑v1 §2-6). "우리 2단 채택"은 매핑v1 §4(e)가 인게임 스킬드래프트용으로 문서화한 설계이며, 코드 실측 결과(SurvivalSkill.csRollGrade()) 그 설계는 아직 코드로 구현되지 않았다(🟢 실측 — 천장 카운터 없음, 순수 가중치 랜덤). 본 층에서 2단 천장을 처음 실제 구현한다 — 인게임 쪽 천장 미구현은 범위 밖 별건(§10). - 등급의 실질 가치: 원작 "등급이 높을수록 확정 티어 지급"(quality→확정 확률 대체) 원칙 재사용 — 높은 등급 뽑기권은 낮은 등급 결과를 배제.
- 소비 재화 — 🔴 미확보, PD 이관: 원작 문서 3건 어디에도
drawlib/drawtype의 소비 재화(무료 vs 유료) 언급이 없다(매핑v1 §2-6은 weight·천장만 다룸). "원작대로 가챠 도입"이라는 PD 지시가 구조·스키마 설계까지는 덮지만(C1), 무료재화(골드) 가챠와 유료재화(젬) 가챠는 서로 다른 BM이자 R-A3 정책 등급도 달라진다. 본 문서는 재화 종류를 확정하지 않는다 — 결정은 PD 영역(§10). - 드롭 대상 확장: 가챠는 §1-3(장비강화)과 별개로 SurvivalItemCatalog 자체의 폭 확장(신규 등급 3+·신규 아이템) 창구다 — 청사진 §3의 "등급 1~2뿐, 극히 협소" 문제의 실제 해소 지점.
- 신규 스탯 수용(확정 4종):
hit_rate·stun_rate·retaliate_rate·combo_rate(명중/회피계+특수효과계, 원작 B-템플릿 ×2 등비 공유군, 재추출v1 §2-2 — 확정 배치). 정정(P3-A 재추출 완료, 2026-08-22):ele_hurt_add·ele_penetrate_ratio는 최초 초안에서 ④ 잠정 배치였으나,heroequipmentskill(장비옵션 드로우풀, 실사용 21종) 재대조 결과 ele 2종 참조 0건으로 확인돼 ④ 소속 가설이 반증됐다 — ⑤스킬마스터리로 이관 확정(§1-5·§2-2 상세).
1-5. Layer⑤ 스킬 마스터리(Skill Mastery) — SurvivalActiveSkillRunner 연동
재미 근거(P30): 지금은 계정을 아무리 오래 해도 다음 판 스킬 뽑기 폭이 첫 판과 똑같다. 마스터리로 드래프트 후보 자체를 넓혀주면 "이번 판엔 어떤 언락된 카드가 뜰까"라는 장기 기대감이 매판 드래프트 재미 위에 한 겹 더 얹힌다 — 매판 완결성(로그라이크)과 영구 확장(원작 학습형 스킬트리)을 절충하는 지점.
역할: 원작 학습형 스킬트리의 "영구 학습" 기능만 가져오고, 학습 UX는 로그라이크 관용어인 **"영구 언락→드래프트 풀 확장"**으로 재해석한다(청사진 §2-2⑤ 판단 승계).
- 연동 지점 실측(C39-10):
SurvivalActiveSkillRunner는_owned/_byId를 인스턴스 필드로 갖고Awake()에서 빈 상태로 시작한다(🟢, 완전 매판 리셋).LoadActiveSkills()는Resources/Skills/Active/*.asset전체를 조건 없이 로드한다 — 현재는 액티브 스킬 습득에 게이팅이 전혀 없다. - 메커니즘 확정 — 드래프트 풀 필터링(Pre-seed 방식 기각):
SurvivalSkill.Draw()가 액티브 후보를 계산하는 지점(avail리스트)에SurvivalMeta.Data.UnlockedActiveCardIds조회 조건 1줄을 추가해, 언락 안 된 카드는 그 판 드래프트에 아예 등장하지 않게 한다. "판 시작 시 자동 장착(pre-seed)" 방식은 채택하지 않는다 — 로그라이크의 매판 선택 긴장감(레벨업마다 3택1)을 그대로 보존하면서 "풀이 넓어진다"는 감각만 추가하는 쪽이 재미(P30) 관점에서 더 낫고, 구현도 1줄 필터로 더 단순하다. 기본값은 전체 언락 상태로 시작(하위호환 유지 — 아무 투자 안 한 신규 계정은 지금과 동일하게 전체 풀에서 드래프트). - 패시브 마스터리 노드: 드래프트를 거치지 않고 ①②③처럼 항상 적용되는 영구 가산 스탯. 확정 배치 3종:
penetrate_ratio(아래 이관 근거) +ele_hurt_add·ele_penetrate_ratio(P3-A 재추출로 ④ 잠정 해소, §2-2 확정표). 정직 한계 명기(C5·C44): ele 2종의 ⑤ 확정은 "④ 소속 가설 반증(heroequipmentskill실사용 21종에 참조 0건) + 잔여 층 배치 +penetrate_ratio와의 의미론적 근접성(같은 관통/속성계 변형)"에 의한 것이지, "원작이 이 2종을 ⑤ 스킬트리에서 실제로 positive 사용했다"는 원작 근거가 확보된 것은 아니다 — 원작 자체도 이 2종을 정의만 하고 실사용은 안 했을 개연이 있다(매핑v1 §6-4가heroskill.csv에 대해 이미 밝힌 "틀은 있고 데이터는 비었다" 패턴과 동일 계열 가능성). penetrate_ratio이관(확정 권고): 현재 인게임 CSV(13종)에 존재하나ConsumedUpgradeKeys에 없어 **사장(死藏)**돼 있다(🟢 실측,SurvivalBattleManager.csL152-160). 중요 정정(plan-auditor m-2): 이 트랙은 방치된 위험 요소가 아니다 —ValidateUpgradeCoverage()(L167)가 기동 시 미소비 키를 경고하도록 이미 설계돼 있고(주석이 "동일 유형의 재발을 막는다"고 명시), 상점에서도 이미 자동으로 숨겨진다. 실제 문제는ConsumedUpgradeKeys(소비 목록)와RecalcPlayer(실계산)가 손으로 동기화해야 하는 한 쌍이라는 점이며(코드 주석 L148-150이 이미 자인), 이 수동 동기화 부담은 아웃게임에 신규 키를 추가할 때도 똑같이 발생한다(§3-3에 동일 원칙 적용).penetrate_ratio를 인게임에서 배선(1줄 추가)하는 대안 대신 ⑤로 이관하는 이유는 순수하게 §0 원칙("이미 인게임에 있는 건 유지, 신규만 아웃게임 배치") 적용이지, 위험 회피가 아니다(§8 기각안 다).- 속성(elemental) 시스템 전제조건 미확인:
ele_hurt_add/ele_penetrate_ratio가 의미를 가지려면 전투에 "속성" 개념이 필요하다.AttributeTag(Flags enum, 물리/화염 등)가SkillDataAsset.cs에 이미 존재하나(🟢), 이것이SurvivalUnit.TakeDamage()의 실제 데미지 계산에서 상성/저항으로 소비되는지는 미확인(🔴, 범위 외 — P3-B4 착수 시 개발팀 재확인 필수 선행 조건). 이 전제조건은 ele_* 2종의 층 배치가 ④에서 ⑤로 확정된 뒤에도 동일하게 적용된다(§2 참조) — 층이 확정됐다고 소비처 존재가 자동으로 확정되는 것은 아니다.
1-6. 5층 상호작용 요약
[판 시작 전 — 아웃게임, 영구]
①영웅레벨(HeroLevel) ──예산 산출──> AttackBudget·HpBudget
②승급(Promotion) ──게이팅────> ①의 최대 도달 가능 HeroLevel 상한
──보너스────> attack%·hp%·defense% (defense는 §3-4 별도 결합)
③장비강화(EquipLv) ──독립──────> 슬롯별 attack/hp + 부스탯(속도|방어)
④가챠(Gacha) ──확률 공급──> ③이 강화할 "장비 자체"(신규 아이템) + 옵션(hit/stun/retaliate/combo, 4종 확정)
⑤스킬마스터리 ──패시브────> penetrate_ratio·ele_hurt_add·ele_penetrate_ratio 영구 가산(3종 확정, P3-A 재추출)
──풀 확장───> 런레벨업 드래프트의 "액티브 카드" 후보 목록(필터링, 패시브와 별개 트랙)
↓ (①②③④의 스탯 기여 = 아웃게임 최종 flat/ratio 총합, §3-4)
[판 진행 중 — 인게임, 매판 리셋]
런레벨(RunLevel, 기존) ──EXP──────> 3택1 드래프트(⑤가 넓혀준 액티브 풀 + 기존 패시브 10종 카탈로그에서 추첨)
강화(SurvivalUpgrade, 기존 13종) ──골드──> attack_add 등 11종 기능 누적(불변)
원작 §1-2 인과("①이 바닥, ②가 ①의 상한 게이팅, ③은 독립, ④는 ③의 확률원, ⑤는 전부와 독립된 별도 슬롯")가 보존됨을 확인. 단 ⑤는 "패시브 가산"과 "드래프트 풀 확장" 2개 하위 트랙으로 분리된다는 점이 원작에 없던 우리 쪽 재해석이다(위 표에서 명시적으로 분리 표기).
2. 능력치 18종 배치 확정 (청사진 §2-3 정정 포함)
2-1. 정정 — "인게임 미보유"는 5종이 아니라 6종이다
청사진 §2-3은 "차집합 5종(hit_rate·ele_hurt_add·ele_penetrate_ratio·retaliate_rate·combo_rate)"이라 기재했다. SurvivalUpgrade.csv(13행 전수) + SurvivalSkill.cs의 Catalog(10항목 전수) 직접 대조 재실측(plan-auditor 재검증 완료) 결과:
| 18종 원본 목록 | 인게임 상태 |
|---|---|
| lucky_rate, lucky_multiple, hp, hp_add, attack_add, defense_add, attack_speed_add, hurt_add, hurt_reduce, suck_ratio, dodge_rate | ✅ 기능 중(11종) |
| penetrate_ratio | ⚠️ CSV엔 있으나 ConsumedUpgradeKeys 미포함 = 사장(1종) |
| hit_rate, stun_rate, retaliate_rate, combo_rate, ele_penetrate_ratio, ele_hurt_add | ❌ 완전 미보유(6종, stun_rate가 청사진 누락분) |
11 + 1 + 6 = 18, 정합. "미보유 = 6종"이 정확하며, stun_rate 누락은 청사진 자체가 🟡 표기 없이 넘어간 대목이다 — C3에 따라 은폐 없이 표면화한다.
참고(18종 외 트랙): 인게임 attack(정액)은 18종에 속하지 않는다 — 원작 27개 effect code 카탈로그(재추출v1 §2-1)에 대응 항목이 없는 GodDem 자체 발명 트랙이다. 다만 이는 무근거 발명이 아니라 직전 완료된 "공격력 원작 2층 복원" 사이클(26ff655)이 원작 hero_level의 "정액+배율 2층 구조" 개념을 인게임 스케일로 의도적으로 재현한 결과물이다(hp의 정액/배율 쌍 구조를 attack에도 대칭 적용, 4:1 비율 파생). 본 문서의 18종 집계에서는 제외한다.
2-2. 배치 확정표
| 능력치 | 층 | 사유 |
|---|---|---|
| attack_add, hp_add, hp, attack_speed_add, hurt_add, hurt_reduce, defense_add, lucky_rate, lucky_multiple, suck_ratio, dodge_rate | 인게임 유지(불변, 11종) | 이미 SurvivalUpgrade에서 기능 중 — 중복 배치 금지 원칙(§0) |
| hit_rate, stun_rate, retaliate_rate, combo_rate | ④가챠 옵션(확정, 4종) | 원작 분류상 "명중/회피계"+"특수효과계"이며 원작 B-템플릿(×2 등비, 재추출v1 §2-2) 공유군 — 확률 드로우풀 스탯으로서의 원작 성격과 일치 |
| ele_hurt_add, ele_penetrate_ratio | ✅ ⑤스킬마스터리로 확정(2종, P3-A 재추출 완료 2026-08-22) | 최초 초안은 재추출v1 §2-1(27코드−res6=21) 산술이 §3 "장비옵션 드로우풀 실사용 21종"과 일치해 ④ 소속 가능성을 🟡로 열어뒀다(plan-auditor M-1 지적). P3-A 재추출 재대조 결과: heroequipmentskill(장비옵션 드로우풀) 실사용 21종에 ele 2종 참조 0건 확인 — "27−res6=21" 일치는 우연이었고 ④ 소속 가설은 반증됐다. 잔여 층 배치 원칙 + penetrate_ratio(이미 ⑤ 확정)와의 의미론적 근접성(관통/속성계 변형 형제 관계)으로 ⑤ 확정. 정직 한계(C5·C44 — plan-auditor 재확인 통과): 이 확정은 "④ 기각 + 잔여 층 + 의미론"에 의한 것이지 "원작이 ⑤에서 이 2종을 positive 사용했다"는 근거는 아니다 — 원작도 정의만 하고 미사용이었을 개연 존재(§1-5). 속성 시스템 전제조건(§1-5)은 층 확정과 무관하게 별도 미확인 상태 유지 |
| penetrate_ratio | ⑤스킬마스터리로 이관(확정, 1종) | 인게임에서 이미 사장된 트랙을 §0 원칙(신규만 아웃게임 배치)에 따라 이관 — 위험 회피가 아니라 배치 원칙 적용(§1-5) |
3. ★ 매판 리셋 인게임 ↔ 영구 아웃게임 경계 재정의
3-1. 판정 원칙 (일반화 규칙)
"판이 시작되기 전에 이미 값이 정해져 있는가?" — 그렇다면 아웃게임. "이번 판 안에서 무작위로 얻고 이번 판이 끝나면 사라지는가?" — 그렇다면 인게임.
부가 원칙 2개:
- 중복 배치 금지 — 같은 스탯 키를 인게임·아웃게임 양쪽에 동시에 두지 않는다(R-A2 재발 방지 최우선 원칙).
- 총량 vs 증분 분리 — 인게임·아웃게임이 같은 물리량(Attack·Hp·Defense)에 동시에 기여하는 것은 허용하되, 반드시 **서로 다른 시점의 항(項)**으로 분리하고 결합 공식을 한 곳에서만 정의한다(§3-4).
3-2. 현재 SurvivalMeta·SurvivalUpgrade와의 관계
둘 다 이미 정확한 자리에 있다 — 청사진 §3의 판정을 재확인한다:
SurvivalMeta(장비 6부위·공격/체력만) = 원작 5층 중 ③장비만 이식된 아웃게임. 얕지만 위치는 맞다.SurvivalUpgrade(13종, 매판 리셋) = 원작 4층(가챠) 스코프를 인게임 화폐 강화로 이식한 것 — "인게임" 정체성 자체는 정확.
본 설계는 이 둘을 대체하지 않고 확장한다.
3-3. 네임스페이스 충돌(R-A2) 3중 방어
충돌이 실제로 발생하는 지점: Layer②(승급) 보너스가 아웃게임에 defense 채널을 처음 들여오는데, 인게임 SurvivalUpgrade.csv에도 이미 defense_add가 있다.
- 구조적 분리(1차 방어, 이미 존재): 아웃게임 5층은
SurvivalMeta(확장 클래스) 소속, 인게임은SurvivalUpgradeTable소속 — 서로 다른 클래스·CSV·Total()이라 두 딕셔너리가 물리적으로 섞이지 않는다. - CSV 키 접두 가드(2차 방어, 신규 도입): 이 프로젝트는 "동일 문자열 키를 다른 테이블에 복붙하다 조용히 어긋나는" 결함 이력이 반복됐다(사장된
penetrate_ratio, stale "12종" 주석, 사장된HeroAttackMultiplier아이템). 신규 아웃게임 CSV의s_StatKey는 인게임과 절대 같은 문자열을 쓰지 않는다 — 예: 인게임defense_add↔ 아웃게임promo_defense_add(승급)·equip_defense_add(장비강화). - 단일 계산 메서드 캡슐화(3차 방어, 신규 도입 — plan-auditor C-1 반영): 결합 공식 자체를 호출부마다 재작성하지 않고
SurvivalMeta안에 딱 한 번만 정의한다(§3-4). 호출부가 3개든 10개든 전부 이 메서드 하나만 부르므로, "공식이 여러 곳에 흩어져 하나만 안 고쳐 어긋나는" 3중 SOT 결함이 구조적으로 발생하지 않는다. 이 신규 관리 부담(신규 outgame 키 추가 시 접두 가드 준수)은 코드 리뷰 체크리스트 항목으로 명문화 권고(§7 R-A2).
3-4. 결합 지점 확정 (구현 가이드라인 — plan-auditor C-1·C-2 반영 재작성)
실측 결과 결합이 필요한 호출부는 4곳이다(🟢, 최초 초안의 "1곳" 주장은 정정):
| 스탯 | 현재 호출부(수정 없이 그대로 둘 대상) | 정정 방식 |
|---|---|---|
| Attack | SurvivalBattleManager.ApplyMetaEquipment() L121-122 |
아래 신규 메서드 호출로 교체 |
| Attack(표시) | SurvivalLobbyController.Hero.cs L232-233 (RefreshHeroStats) |
동일 신규 메서드 호출로 교체 |
| Attack(상세표시) | SurvivalLobbyController.Hero.cs L338-339 (UpdatePropertyText, Base/+Bonus 2단 표기) |
신규 메서드 호출 + 비율 항 표기 방식은 ux-designer 협의 대상(현재는 flat 가산만 표기하는 구조라 비율 항이 추가되면 "기초/장비/승급%" 3단 분해 표시가 필요할 수 있음) |
| Defense | SurvivalBattleManager.RecalcPlayer() L202 reduce = ... |
항 1개 추가(아래) — "RecalcPlayer 무변경"은 성립하지 않으므로 정정 |
// 신규: SurvivalMeta에 결합 공식을 한 곳에만 정의 (호출부는 전부 이것만 부른다)
SurvivalMeta.FinalAttack() = (BaseAttack + TotalAttack()) × (1 + TotalAttackRatio())
SurvivalMeta.FinalHp() = (BaseHp + TotalHp()) × (1 + TotalHpRatio())
// TotalAttack()/TotalHp() 내부(신규) = ①영웅레벨 예산 + 기존 장비 flat 총합 + ③강화분
// TotalAttackRatio()/TotalHpRatio() 내부(신규) = ②승급 attack%/hp% 보너스
SurvivalMeta.TotalDefenseRatio() = ②승급 promo_defense_add% // 신규, 인게임과 별개 네임스페이스
// 호출부 정정
ApplyMetaEquipment(): PlayerAttack = SurvivalMeta.FinalAttack(); PlayerHp = SurvivalMeta.FinalHp();
Hero.cs RefreshHeroStats(): 같은 SurvivalMeta.FinalAttack()/FinalHp() 호출로 교체(3중 SOT 방지)
RecalcPlayer() L202(수정): reduce = t.Total("hurt_reduce") + t.Total("defense_add") + t.Total("dodge_rate")
+ SurvivalMeta.TotalDefenseRatio(); // ← 1개 항 추가
Player.DamageReduction = Mathf.Clamp(reduce, 0f, 0.8f);
defense 클램프 공유 리스크와 권고안(§7 R-B2): 위 방식대로 promo_defense_add가 인게임 항들과 같은 0~0.8 클램프를 공유하면, 계정을 오래 키운 유저는 판 시작부터 클램프에 근접해 있어 그 판의 인게임 방어 강화 선택 자체가 무의미해지는 함정이 생긴다(P30 직결 — "성장했는데 체감 0"). 권고 기본안: 아웃게임 defense는 클램프 이후 별도 승산항으로 분리한다 — 최종피해감소 = 1 - (1-ingame_reduce_clamped) × (1-outgame_defense_ratio). 이러면 인게임 클램프(0.8 상한)는 그대로 보존되면서 아웃게임 투자도 항상 체감 있게 작동한다. 최종 수식·클램프 정책은 P3-B1에서 balance-designer 확정.
추가 발견 — Player.Attack의 숨은 2번째 소비처(plan-auditor m-1): SurvivalActiveSkillRunner.cs L18,83이 const float BaselineAttack = 22f를 자체 보유하고 (atk/BaselineAttack)로 액티브 스킬 데미지를 스케일링한다. 이는 (a) Layer①로 Player.Attack이 오르면 액티브 스킬 데미지도 선형 증폭된다는 뜻이며, (b) 22f가 SurvivalMeta.BaseAttack의 const 복제본이라는 뜻이다 — SurvivalMeta.cs L57-60 자체 주석이 "SOT로 선언한 값에는 const를 쓰지 않는다"고 명시적으로 금지한 바로 그 패턴이 여기 이미 존재한다. 본 문서 범위(P2 설계) 밖의 기존 결함 발견이므로 여기서 수정하지 않되 은폐하지 않는다(C3) — P3-B1 착수 시 BaselineAttack을 SurvivalMeta.BaseAttack 참조로 교체 권고(§7 R-B4). 영웅레벨이 오른 상태에서 ⑤(액티브 언락)까지 겹치면 이중 증폭 효과가 생기므로 P3-B1/B4 밸런싱 시 인지 필요.
4. 재사용/확장 판정 확정 (청사진 §6-7 구체화)
| 시스템 | 판정 | 확장 방향 |
|---|---|---|
| SurvivalMeta.cs | ✅ 확장 기반 재사용 | Version 1→2 + 신규 필드 6종(§5-1) + FinalAttack()/FinalHp()/TotalDefenseRatio() 신규 메서드(§3-4) |
| SurvivalUpgrade.cs/.csv (13종) | ✅ 완전 불변 재사용 | 손대지 않음. penetrate_ratio 이관은 CSV에서 행 제거(별건 정리, §1-5) |
| SurvivalSkill.cs(가중치) | ✅ 재사용 + 조건부 확장 | Draw()의 액티브 후보 계산에 아웃게임 언락 필터 1줄 추가(§1-5). Catalog(패시브 10종) 불변. 가중치 합 9346(비-10000) 정합 여부는 본 문서 범위 밖 |
| SurvivalItemCatalog.cs | ⚠️ 확장 | 등급 1~2→3+ 확장, 슬롯별 부스탯 필드 추가(§1-3). EquipLevel 저장은 카탈로그가 아니라 SurvivalMetaData가 보유 |
| SurvivalShopCatalog.cs | ⚠️ 구조 확장 필요(plan-auditor M-5 반영 — "무변경 수용 가능" 주장 철회) | SurvivalShopEntry의 지급물은 GoodsId/GoodsAmount(재화) 또는 ItemId/ItemCount(장비) 2종 중 택1 구조뿐이라 확률 지급물을 표현할 수 없다(L28 주석 확인). 또 Path가 Shop.prefab 실측 노드에 1:1 대응해 엔트리 추가 = 프리팹 카드 노드 추가(개발팀·클라이언트팀 협업 필요). 가챠는 (a) 신규 지급 타입(PoolId 참조) 필드 추가, 또는 (b) 기존 상점과 분리된 전용 UI/데이터 경로 신설 중 택1 — 결정은 P3-B3 |
| SurvivalActiveSkillRunner.cs | ⚠️ 연동 지점 추가 + 기존 결함 1건 발견 | SurvivalSkill.Draw() 필터 연동(§1-5). BaselineAttack const 복제 결함 발견(§3-4, 본 문서 범위 밖 별건) |
Stage(EnemyWaveBalance 등) |
범위 외 | P3-C 소속(§6). 병렬 착수 가능 |
신규 클래스 4개: SurvivalHeroLevelTable(①) · SurvivalPromotionTable(②) · SurvivalEquipUpgradeTable(③, SurvivalUpgradeTable과 동일 패턴 복제) · SurvivalGachaTable(④, weight+pity). ⑤는 신규 클래스 없이 SurvivalMetaData 필드 + SurvivalActiveSkillRunner 연동만으로 충분.
5. 데이터 모델 골격
5-1. SurvivalMetaData 확장 (Version 1→2)
public class SurvivalMetaData
{
// ── 기존 필드 (v1, 불변) ──
public Dictionary<int, int> Owned;
public int[] Equipped; // 6
public Dictionary<string, int> DailyPurchase;
public string LastDailyReset;
public int Version = 2; // ← 1에서 상향
// ── 신규 필드 (v2, 본 설계) ──
public int HeroLevel = 0; // Layer① 영구 레벨
public long HeroLevelExp = 0; // Layer① 소비 자원 누적(단위는 §1-1 열린 이슈)
public int PromotionStar = 0; // Layer② 승급 성급(게이팅 토큰)
public Dictionary<int, int> EquipLevel; // Layer③ itemId → 강화단계(신규, Owned와 별개)
public int GachaPityCount; // Layer④ 천장 카운터(2단 중 현재 위치)
public Dictionary<int, int> SkillMasteryLevel; // Layer⑤ 노드ID → 레벨(penetrate_ratio·ele_hurt_add·ele_penetrate_ratio 3종 확정 패시브 전용)
public HashSet<string> UnlockedActiveCardIds; // Layer⑤ 액티브 카드 드래프트 풀 언락 목록
}
마이그레이션: 기존 Load()의 Owned ??= new Dictionary<int,int>() 패턴(L96-98)을 그대로 복제 — 신규 Dictionary/HashSet 필드 전부 동일한 null-coalescing 초기화 필요. Version==1(구버전) 로드 시 UnlockedActiveCardIds는 전체 카드로 채워 시작(§1-5 하위호환 원칙) — 이 분기가 유일한 실제 마이그레이션 로직이다.
5-2. 신규 CSV 스키마 (골격 — 값은 P3, CSV 포맷 계약 §3-4 준수)
CSV 계약: 1행 헤더(컬럼명, 타입 접두 n_/f_/s_/e_/l_) · 2행 한글 설명(로더가 무조건 폐기) · 3행부터 데이터(매핑v1 §3-4, SurvivalUpgrade.csv 실물 확인).
| 파일 | 컬럼 | 원작 근거 | 비고 |
|---|---|---|---|
SurvivalMetaHeroLevel.csv |
n_Level, l_RequireCost, f_AttackBudget, f_HpBudget |
hero_level 2차 스탯식 + 3차 비용식(형태만) | ① |
SurvivalMetaPromotion.csv |
n_Star, n_Quality, l_GoldCost, n_LevelCap, f_AttackBonusRatio, f_HpBonusRatio, f_PromoDefenseAddRatio |
hero_star 4차 비용+선형 보너스+게이팅(형태만) | ②. f_PromoDefenseAddRatio가 §3-3 키 접두 가드 적용 예 |
SurvivalMetaEquipUpgrade.csv |
n_ItemId, n_Level, f_EquipAttackAdd, f_EquipHpAdd, s_SecondaryStatKey, f_SecondaryValue, l_Cost |
heroequipment Base+V 가산분해(형태만) | ③. s_SecondaryStatKey는 equip_attack_speed_add 등 접두 키만 허용 |
SurvivalMetaGachaPool.csv |
n_PoolId, n_ItemId, n_Grade, n_Weight |
heroequipmentskill weight, 합 10000 강제(본 층이 첫 실도입, §1-4) | ④ |
SurvivalMetaGachaOption.csv |
n_OptionId, s_StatKey, n_Grade, f_Value |
heroskillattr B-템플릿(hit/stun/retaliate/combo, 4종 확정 — ele_*는 P3-A 재추출로 ⑤ 이관) | ④. s_StatKey=gacha_hit_rate 등 |
SurvivalMetaGachaPity.csv |
n_Tier, n_PullsNeed, n_GuaranteedGrade |
drawtype 2단(pool2need/pool3need 구조) | ④ |
SurvivalMetaSkillMastery.csv |
n_NodeId, s_StatKey, n_Grade, f_Value, l_Cost |
heroskillattr(penetrate_ratio·ele_hurt_add·ele_penetrate_ratio 3종 확정, P3-A 재추출) |
⑤. s_StatKey=mastery_penetrate_ratio 등 |
예시(헤더+한글설명 행 실물, 값은 TBD):
n_Star,n_Quality,l_GoldCost,n_LevelCap,f_AttackBonusRatio,f_HpBonusRatio,f_PromoDefenseAddRatio
승급 성급,등급,골드비용(4차식 형태),레벨상한(게이팅),공격%보너스,체력%보너스,방어%보너스(접두 promo_ 가드)
0,1,TBD,TBD,TBD,TBD,TBD
5-3. 코드 터치포인트 (구현 가이드라인 — plan-auditor C-1 반영 갱신)
| 파일 | 변경 |
|---|---|
SurvivalMeta.cs |
SurvivalMetaData에 6필드 추가 + Load() 마이그레이션 분기 + FinalAttack()/FinalHp()/TotalDefenseRatio() 신규 메서드(§3-4) + 내부 TotalAttack()/TotalHp()에 ①③ 반영 |
SurvivalBattleManager.cs |
ApplyMetaEquipment()을 FinalAttack()/FinalHp() 호출로 교체 + RecalcPlayer() L202에 TotalDefenseRatio() 항 1개 추가(§3-4) |
SurvivalLobbyController.Hero.cs(누락분 추가, C-1) |
RefreshHeroStats()(L232-233)·UpdatePropertyText()(L338-339) 2곳 모두 동일한 FinalAttack()/FinalHp() 호출로 교체 — 직접 수식을 재작성하지 말 것(3중 SOT 재발 방지가 본 설계의 핵심 목적). L338-339의 Base/+Bonus 2단 표기는 비율 항 추가로 표시 로직 재검토 필요(ux-designer 협의) |
SurvivalSkill.cs |
Draw()의 액티브 후보 필터링에 SurvivalMeta.Data.UnlockedActiveCardIds 조회 조건 1줄 |
SurvivalActiveSkillRunner.cs |
기존 결함(BaselineAttack const 복제, §3-4) 인지만 — 수정은 별건. 신규 로직 추가 없음(pre-seed 방식 기각, §1-5) |
SurvivalItemCatalog.cs |
SurvivalItemDef에 SecondaryStatKey(슬롯별 부스탯 종류) 필드 추가, 등급 3+ 아이템 정의 추가 |
SurvivalShopCatalog.cs |
§4 판정대로 구조 확장(신규 지급 타입 또는 전용 경로) — 세부는 P3-B3, 클라이언트팀 협업 필요 |
| 신규 파일 4개 | SurvivalHeroLevelTable.cs·SurvivalPromotionTable.cs·SurvivalEquipUpgradeTable.cs·SurvivalGachaTable.cs — SurvivalUpgradeTable.Load()의 CSV 파싱 패턴(헤더 2행 스킵) 복제 |
6. P3 단계 분할 정합
청사진 §4의 P3-A/B/C를 세분화한다. C49(팀장 설계→팀원 작업→팀장 검증) 준수, Phase 간 착수는 이전 Phase 완료·PD 확인 전제(C9 — 일정 아님).
| Phase | 범위 | 규모 추정(근거) | 선행 조건 |
|---|---|---|---|
| P3-A | 능력치 정리 — §2-2 배치표 확정 반영, penetrate_ratio 이관(CSV 행 제거+마스터리 CSV 등재), ele_* 2종 최종 층 재추출 확정(④→⑤) — 완료(2026-08-22, 개발팀장 GodDem 8684211, plan-auditor 조건부통과) |
소~중(재추출 1건 포함) | 본 문서 PD 확인 |
| P3-B1 | Layer①+② 구현 — 영웅레벨+승급, SurvivalMetaHeroLevel.csv+SurvivalMetaPromotion.csv + defense 클램프 분리 결합식(§3-4) |
중(신규 클래스 2·결합 로직) | P3-A + hero_star 레벨캡 불일치 재실측(청사진 §5) |
| P3-B2 | Layer③ 구현 — 장비강화, SurvivalMetaEquipUpgrade.csv + SurvivalItemCatalog 확장 |
중(기존 패턴 복제 + 슬롯별 부스탯 매핑) | P3-B1(결합식 전제) + heroequipment/upgrade M수열 원본 재대조(R-A5, §7) |
| P3-B4 | Layer⑤ 구현 — 스킬 마스터리, SurvivalMetaSkillMastery.csv + SurvivalActiveSkillRunner 드래프트 필터 연동 |
중(속성 시스템 실존 확인 선행 필요) | 개발팀 AttributeTag 소비 여부 재확인 |
| P3-B3 | Layer④ 구현 — 가챠, SurvivalMetaGachaPool/Option/Pity.csv + 상점 구조 확장 |
중~대(과금 정책 연동 + 상점 구조 변경, R-A3·M-5) | PD 확인 필수(재화 종류·확률형 아이템 정책, P23 기준) |
| P3-C | 스테이지 구조 데이터화(청사진 소관, 본 문서 범위 외) | 청사진 §4 추정 유지 | §5(teamwavepassreward 반복 여부) 재추출 |
순서 권고: P3-A→B1→B2→B4→B3 순 착수(가챠는 정책 확인이 가장 오래 걸릴 수 있어 마지막 배치 — 나머지 4층이 먼저 플레이 가능한 깊이를 만든다). P3-C는 P3-B와 독립적이므로 병렬 착수 가능(C41).
검증 부하 분산(청사진 R-A4 대응): 5층을 4개 서브페이즈로 쪼갠 것 자체가 "5층 동시 착수 시 검증 부하" 리스크의 직접 해소책이다.
7. 리스크 (청사진 R-A1~5 전체 승계 + 신규 4건)
| ID | 리스크 | 심각도 | 내용 |
|---|---|---|---|
| R-A1(승계) | 스테이지 유한/무한 결정 지연 | 중 | 청사진 §6 원문 그대로 — 본 문서 범위 밖(P3-C) |
| R-A2(승계, §3-3에서 3중 방어 반영) | 네임스페이스 충돌 | 중→구조·키·캡슐화 3중 방어 반영 | §3-3. 접두 가드 준수는 구현자 규율에 의존하므로 P3-B1 code review 체크리스트에 명문화 권고 |
| R-A3(승계) | 가챠 도입 정책 리스크 | 중~높음 | §1-4·P3-B3에서 PD 확인 필수. 재화 종류(골드/젬) 자체도 미확정임을 추가 명시(M-2) |
| R-A4(승계) | 5층 동시 착수 시 검증 부하 | 중 | §6의 4개 서브페이즈 분할로 대응 |
| R-A5(승계 — 최초 초안 누락분) | ⚠️ 절 재발 패턴 | 낮음(주의) | 매핑v1 §6-5 "실제 오류 4건 전부 ⚠️ 절에서 발생". Layer②(hero_star, ⚠️)·Layer③(heroequipment, ⚠️) 둘 다 이 패턴 대상 — P3-B1·B2 선행 재실측으로 대응(§6) |
| R-B1(신규) | penetrate_ratio 이관 지연 |
낮음(하향 조정) | plan-auditor m-2 반영 — ValidateUpgradeCoverage()가 이미 경고하므로 방치 위험은 낮다. 실제 리스크는 "소비목록↔실계산 수동 동기화 부담"이 신규 outgame 테이블에도 반복된다는 점(§1-5) |
| R-B2(신규 — plan-auditor C-2 반영) | defense 클램프 공유 시 아웃게임 투자 무의미화 | 중 | §3-4 — 승급 defense% 보너스가 인게임과 같은 0.8 클램프를 공유하면 계정이 성장할수록 그 판 인게임 방어 강화 선택이 무의미해진다. 권고: 클램프 이후 별도 승산항으로 분리 |
| R-B3(신규) | 아이템 융합(TryFuse) ↔ 장비강화(EquipLevel) 상호작용 미정의 | 중 | §1-3 — 강화분 투자된 아이템이 융합 재료로 소모되면 투자가 고아화. 기본 권고: 강화분>0 아이템 융합 차단 |
| R-B4(신규 — plan-auditor m-1 반영) | SurvivalActiveSkillRunner.BaselineAttack const 복제 기존 결함 + Layer①과의 증폭 상호작용 |
낮음~중 | §3-4 — 기존 결함 발견(본 문서 범위 밖). 영웅레벨 상승이 액티브 스킬 데미지도 선형 증폭시키며, ⑤ 언락과 겹치면 이중 증폭. P3-B1 착수 시 BaselineAttack을 SOT 참조로 교체 권고 |
| R-B5(신규) | 가챠·상점 중복 판매 시 상점 가치 희석 | 낮음~중 | §1-4 — "상점=저확정 티어, 가챠=고티어+옵션" 역할 분리 권고, 최종 경계는 P3-B3 |
8. 기각안 (C32 — plan-auditor 지적 3건 추가 반영)
| # | 검토안 | 기각 사유 |
|---|---|---|
| 1 | 원작 ①레벨 이름을 그대로 "레벨"로 아웃게임에 도입 | 기존 인게임 SurvivalBattleManager.Level과 이름 충돌(§1-0). "영웅레벨"/"런레벨"로 분리 |
| 2 | 승급(Layer②) 보너스에서 defense를 제외하고 attack/hp 2종만 이식 |
원작 실측(매핑v1 §2-2 "186행 검증 True")이 3스탯 동일 보너스임을 명시 — 임의 축소는 이식 충실성 훼손. 대신 §3-4 클램프 분리로 부작용만 해소 |
| 3 | 장비강화(Layer③)를 슬롯 단위 설계 | 원작은 heroequipment 개별 ID 단위(매핑v1 §2-3). 슬롯 단위면 수집 동기 약화 |
| 4 | 가챠(Layer④) 도입 시 기존 상점 직접판매 장비 항목 전부 대체 | 청사진 §3 재사용 판정과 배치. 신규 유저 저티어 접근성 보존을 위해 병존(R-B5) |
| 5 | ele_hurt_add/ele_penetrate_ratio를 속성 시스템 실존 여부 확인 없이 즉시 수치까지 확정 |
C39 위반 소지 — 소비처 없는 스탯 배치는 결함 재발(청사진의 HeroAttackMultiplier 사장 사례와 동일 패턴). 배치(당시 ④ 잠정)만 하고 수치는 유예 — (2026-08-22 후속) P3-A 재추출로 층은 ⑤ 확정됐으나(§2-2) 수치·소비처 확인은 여전히 유예 상태, 이 기각 논리는 그대로 유효 |
| 6 | 청사진 §2-3 "5종" 표기를 재검증 없이 승계 | C44는 상위 문서 수치도 항상 재검증 요구. 실측 결과 6종(stun_rate 누락)이 정확 |
| 7 | 본 문서에서 세부 CSV 수치까지 한 번에 확정 | PD 지시가 "P1 조망→P2 메타재설계→P3 축별 구현"으로 명시 분할(C50) |
| 8(신규) | Layer②를 성29·성30 레벨캡 12행 불일치 미해소 상태로 그대로 채택 강행 | plan-auditor M-3 지적 — 매핑v1 §2-2 자체가 재검증 필요를 명시한 ⚠️ 절이다. 채택 방향은 확정하되 재실측을 P3-B1 선행 조건으로 강제(§6·R-A5)해 강행하지 않는다 |
| 9(신규) | 가챠 소비 재화를 젬(유료)으로 본 문서에서 확정 | plan-auditor M-2 지적 — 원작 문서 3건 어디에도 drawlib/drawtype 소비 재화 근거가 없다(🔴). 무료(골드)·유료(젬) 가챠는 BM 자체가 다른 결정이라 스키마 설계 이상의 확정은 PD 영역 침범(C36) — 재화 컬럼 구조만 만들고 값은 유보(§10) |
| 10(신규) | penetrate_ratio를 인게임에 그대로 두고 ConsumedUpgradeKeys에 1줄만 추가해 배선(이관 대신 배선) |
plan-auditor 질의 유도 — 기술적으로는 더 간단한 수정이지만, 이미 신규 스탯 6종을 아웃게임에 배치하기로 한 §0 원칙과 충돌한다(사장된 스탯이라 해서 "인게임에 있던 것"이 아니게 되는 건 아니지만, 기능적으로 전혀 작동한 적 없던 스탯이므로 §0의 "신규만 아웃게임" 원칙을 적용해도 무리가 없고, 이관 쪽이 청사진이 지적한 "아웃게임 능력치 종류 확장" 목표에 더 직접 기여한다) |
9. 변경 이력 (P16)
| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 |
|---|---|---|---|---|---|
| 2026-08-22 | system-designer | 문서 신규 작성 초안 | — | 5층 골격·18종 배치(5종 기준)·결합 "1곳" 주장 | PD 지시 집행 1차 초안 |
| 2026-08-22 | system-designer | plan-auditor 감사 반영 최종화(같은 v1 내 확정) | 초안 | Critical 2(결합 4곳 정정·defense 채널 처리)·Major 6(ele_* 🟡화·가챠재화 🔴화·상점구조 확장·통계 정합·R-A5 승계·P30 근거 보강) 전부 반영 | C35 감사 게이트 — 조건부통과 정정 완료 후 발신 |
| 2026-08-22 | system-designer | ele_hurt_add·ele_penetrate_ratio 층 배치 정정(§0·§1-4·§1-5·§1-6·§2-2·§5-1·§5-2·§6·§8) | 🟡④가챠 잠정(2종) | ✅⑤스킬마스터리 확정(2종) | P3-A 재추출 실측 완료(개발팀장, GodDem 8684211) — heroequipmentskill 실사용 21종에 ele 참조 0건 확인, ④ 소속 가설("27−res6=21" 일치) 반증. plan-auditor P3-A 검증(§27, 대화로그) 이미 통과분을 본 문서에 정합 반영. 정직 한계(원작 positive 사용 근거 아님) 각 위치에 명기 |
| 2026-08-22 | system-designer | §1-1 Layer① 상한 정정 | "상한: 없음(수확체감 없음 원칙 승계)" | "현재 콘텐츠 캡 60/11(동일 공식 CSV 행 추가로 확장 가능)" | PD 유한캡 승인(대화로그 §31 "우선 원작처럼 맞춰") — P3-B1(balance-designer) 유한 캡 설계(HeroLevel60·PromotionStar11)가 메타v1 최초 방향과 상충하던 것을 PD 결정으로 해소, "수확체감 없음"(레벨당 예산 불변)과 "상한 없음"(레벨 수 무한) 개념 혼동 시정 |
10. 후속 조치 (본 문서 범위 밖)
- 개발팀 재확인 3건: ①
hero_star레벨캡 성29·30 불일치 재실측(P3-B1 선행) ②heroequipment/upgradeM수열 원본 CSV 재대조(P3-B2 선행, R-A5) ③AttributeTag의 실전투 데미지 계산 소비 여부(P3-B4 선행, R-B2 아님 — §1-5 속성 전제조건). - balance-designer 위임(P3-A): §2-2 배치표를 입력으로 능력치 축 확장 설계.
ele_* 2종 최종 층 확정 재추출→ 완료(2026-08-22) — 개발팀장이 수행(⑤ 확정, GodDem8684211), §2-2·§6 반영 완료. - PD 확인 2건: ①Layer④ 가챠 가격·확률 실제 값 및 확률형 아이템 정책 준수 방식(P3-B3 착수 전제, R-A3) ②가챠 소비 재화(골드 vs 젬) 방향(🔴 원작 근거 부재, §8 기각안9·M-2) — 스키마는 재화 종류 무관하게 설계됐으므로 이 결정이 P2를 재작업시키지 않는다.
- PM 공유: 본 문서 산출 완료를
개발팀_PD_지시_로그.md(BT13-GodDem 단일 관리) 및 대화로그에 반영. - 별건 결함 인지(수정은 범위 외, C3 은폐 금지 목적 기록):
SurvivalActiveSkillRunner.BaselineAttackconst 복제(R-B4) — P3-B1 착수 시 정리 권고.