BurningTimesAi/공유/기획/GodDem/2026-08-22_P3B1_레벨승급_설계_v1.md

# GodDem 영웅레벨+승급(아웃게임 Layer①②) 수치 설계 v1

> **작성**: balance-designer(기획팀) 2026-08-22 · **P3-B1 산출물** (P32 맥락 분할 · C50 규모 "중")
> **PD 승인 원문 (C42-2 A, 2026-08-22)**: "설계대로 진행" — `2026-08-22_메타아키텍처_재설계_v1.md`(이하 메타v1) 골격에 대한 승인
> **선행 문서(전부 Read 완료)**: [`2026-08-22_메타아키텍처_재설계_v1.md`](./2026-08-22_메타아키텍처_재설계_v1.md)(메타v1, §P3-B1·§3-4·Layer①②) · [`2026-08-22_원작아키텍처_이식청사진_v1.md`](./2026-08-22_원작아키텍처_이식청사진_v1.md)(청사진v1) · [`2026-08-20_원작밸런스_해독_매핑_v1.md`](./2026-08-20_원작밸런스_해독_매핑_v1.md)(매핑v1, §2-2 hero_star) · [`2026-08-22_원작배율_재추출_원본_v1.md`](./2026-08-22_원작배율_재추출_원본_v1.md)(재추출v1) · [`2026-08-22_공격력_원작2층_재설계_v2.md`](./2026-08-22_공격력_원작2층_재설계_v2.md)(2층 구조·4:1 유도 선례)
> **절대 제약**: GodDem 레포(`E:\NerdNavis\GodDem`) Read만 수행, 수정 0건. Unity MCP 미사용. 본 문서가 유일 산출물.
> **범위**: Layer①(영웅레벨)·Layer②(승급) 실수치 설계만. ele_*/가챠(B3·B4)·스테이지(C) 범위 침범 없음.
> **표기 규칙(C5·C44)**: 🟢확정(코드 직접 실측) · 🟡추정(근거 있으나 미확정, 플레이테스트 필요) · 🔴재추출 필요/미확보
> **감사 이력(C35)**: plan-auditor 모드A 1회 수행 — 판정 **조건부통과**(Critical 1·Major 4·Minor 3, 산술은 전량 무오류 확인). 본 v1은 그 지적을 전부 반영한 최종본이다(§2-3·§4-2·§6·§11·§12).

---

## 0. 결론 요약

메타v1이 골격만 정의하고 유보한 실수치·미정 사항 4건을 본 문서에서 확정한다.

| 유보 사항(메타v1 출처) | 본 문서 결정 |
|---|---|
| §1-1 "소비 재화 TBD, 중간재 도입 필요성은 balance-designer 열린 이슈" | **기존 골드(GOLD_ID=201) 직접 소비 채택 + 런종료 전환 브릿지 신규 설계**(중간재 도입 안 함, §2-3) |
| §3-4 "defense 클램프 공유 리스크… 최종 수식·클램프 정책은 P3-B1에서 balance-designer 확정" | **클램프 후 별도 승산항 분리식 확정**(R-B2 해소, §7) |
| §1-2 "레벨캡·비용·보너스 공식 형태만 재사용, 절대 계수는 TBD(P3-B1)" | **영웅레벨 60캡·승급 star11캡, 전 수식·수치 확정**(§4·§5) |
| §1-2 "hero_star 성29·30 레벨캡 불일치, 재실측이 P3-B1 직접 선행 조건" | **우리 설계는 이 불일치 구간을 회피하도록 캡을 선택**(star11=cap60, 클램프 미도달) — 단, 재추출 자체는 미해소이므로 개발팀장 표시 유지(§5-5) |

**⚠️ 원칙 반전 고지(plan-auditor M-4 지적, C36 경계)**: 메타v1 §1-1은 Layer①을 **"상한: 없음(원작 '수확체감 없음' 원칙 승계)"**으로 명시했다. 본 문서는 HeroLevel 60·PromotionStar 11이라는 **유한 캡**을 도입한다 — 이는 메타v1이 명시한 방향과 정면으로 다르므로 축소 은폐하지 않고 여기서 표면화한다. 근거: "상한 없음" 공식은 CSV 테이블 기반으로 실제 구현 불가능하다(무한 행을 미리 채울 수 없음 — 원작조차 실제로는 150에서 멈춘 유한 시스템이었다, 매핑v1 §2-1). 60/11은 **"현재 콘텐츠 패치의 캡"**이며, 향후 PD·system-designer 판단에 따라 동일 공식 형태로 CSV 행만 추가해 확장 가능한 구조로 설계했다(§3-2·§4-2 공식은 L·star에 대해 닫힌 형태라 상한 값 자체는 자유롭게 늘릴 수 있음). 그러나 이것이 "무한 유한화"라는 방향성 조정 자체는 PM·system-designer 인지가 필요한 사안(C36 (b) 해당 가능성)이므로 팀장 확인 후 진행을 권고한다.

**실측 중 신규 발견(C39·C3, 은폐하지 않음)**: 런 종료 시 인게임 골드(`SurvivalBattleManager.Gold`)를 영구 재화(`CurrencyManager`/`GOLD_ID`)로 전환하는 코드가 **현재 존재하지 않는다**(`OnVictoryContinue()`·`OnDefeatContinue()` 직접 확인, `CurrencyManager.Add` 호출 0건). 또한 "Victory" 팝업은 런 종료가 아니라 **스테이지 클리어마다** 뜨는 것으로 확인됐다(`_pendingVictory = M.Stage > _shownStage`, Stage 무한 증가) — 사망(`OnDefeatContinue()`)과 일시정지 메뉴의 수동 재시작(`OnPauseRestart()`) **2곳 모두 `SurvivalBattleManager.Restart()`를 호출**하는 실제 런 종료 지점이다(plan-auditor C-1 지적으로 재확인, §2-2·§2-3). 이 신규 사실이 Layer① 재화 설계의 전제이므로 §2에서 상세를 다룬다.

---

## 1. 설계 전제

| 항목 | 값 |
|---|---|
| 기준 플레이어 수준 | 신규(0/0/미투자) ~ 장기(HeroLevel60·PromotionStar11·풀장착) 4단 밴드 |
| 목표 경험 | "판을 거듭할수록 이번 판 시작점이 조금씩 높아진다"(메타v1 §1-1 P30 근거) — 로그라이크 매판 완결성은 유지, 계정 장기투자자가 신규 유저보다 항상 유리한 출발선 |
| 전제 스탯 앵커 | `SurvivalMeta.BaseAttack=22`/`BaseHp=400`(HeroLevel=0 앵커, 불변) · 장비 상한 `+47atk/+305hp`(S3 v2 §1-2 풀장착) |
| 전제 경제 앵커 | 인게임(매판) 20웨이브 총 골드 2,542G(S3 v2 §2-3 확정 앵커) — 아웃게임 영구 경제의 **보수적 하한 앵커**로 재사용(§2-4) |
| 재화 | 기존 `GOLD_ID=201`(persistent, `CurrencyManager` SOT) 직접 소비. 신규 중간재 도입 안 함 |
| C39 실측 확증 | `SurvivalMeta.cs`·`SurvivalBattleManager.cs`·`SurvivalUpgrade.cs`·`SurvivalItemCatalog.cs`·`SurvivalLobbyController.Hero.cs`·`SurvivalUIController.cs`(BuildResults/OnVictoryContinue/OnDefeatContinue)·`SurvivalStatCatalog.cs`·`SurvivalMetaSkillMastery.csv`·`Constant.cs`(GOLD_ID=201/GEM_ID=101) 직접 Read 완료 |

---

## 2. 실측 확인 — 재화 흐름 (C39·C3)

### 2-1. 현재 구조 (🟢 확정)

```
[인게임, 매판]  SurvivalBattleManager.Gold (int, 런 시작 0)
                  ↑ OnEnemyDied() 가산       ↓ TryUpgrade() 차감(12트랙 강화)
                  → 런 종료(Defeat) 시 그대로 소멸. 영구 재화로 전환 코드 없음.

[영구, 계정]    CurrencyManager.Instance / Constant.GOLD_ID(=201)
                  ← 상점 IAP 골드팩(500/2000/600·12000·48000, SurvivalShopCatalog.cs) 만 확인됨
                  ← Survival 플레이로부터의 유입 경로 0건(🟢 실측)
```

### 2-2. Victory ≠ 런 종료 (신규 발견)

`SurvivalUIController.cs:546` `if (M.Stage > _shownStage) { _pendingVictory = true; ... }` — Stage는 상한이 없으므로(청사진 §3 "Stage 무한 증가") **Victory 팝업은 스테이지 클리어마다 반복 표시되는 중간 보상 연출**이다. `OnVictoryContinue()`는 `Time.timeScale=1f`만 하고 런을 이어간다. `OnDefeatContinue()`(플레이어 사망)는 `M.Restart()`를 호출해 씬을 리로드하는 확실한 런 종료 지점이다 — **단, 유일한 지점은 아니다**. `OnPauseRestart()`(일시정지 메뉴의 수동 재시작)도 동일하게 `M.Restart()`를 호출한다(plan-auditor C-1 지적, 본 balance-designer가 코드로 재확인 완료 — §2-3). 즉 런 종료 경로는 2개이며, 전환 브릿지는 이 **공통 호출 대상인 `Restart()` 자체**에 심어야 두 경로 모두 놓치지 않는다(§2-3).

### 2-3. 설계 결정 — 전환 브릿지 신규 도입 (개발팀 구현 필요)

메타v1이 "디폴트 권고"로 남긴 두 옵션(기존 골드 직접소비 vs 신규 중간재) 중 **기존 골드 직접소비를 채택**하되, 현재 브릿지가 없다는 실측 결과에 따라 다음을 **P3-B1 구현의 필수 동반 항목**으로 명시한다.

**정정(plan-auditor C-1)**: §2-2가 확인했듯 런 종료 경로는 `OnDefeatContinue()`·`OnPauseRestart()` 2개이며 둘 다 `M.Restart()`를 호출한다(`SurvivalUIController.cs:517-523`, 본 balance-designer 재확인 완료 🟢). `OnDefeatContinue()`에만 전환 훅을 심으면 사망 전 일시정지→재시작 경로에서 `TotalGoldEarned`가 소실된다 — §2-3이 없애려던 역유인(스펜드/축적 딜레마)과 **반대 방향의 새 손실 버그**가 되므로, 전환 훅은 `SurvivalUIController` 콜백이 아니라 **`SurvivalBattleManager.Restart()` 자체**(두 호출부의 공통 choke point)에 배치한다.

```csharp
// SurvivalBattleManager.cs — 신규 필드(Gold와 별개, 감소 없음)
public int TotalGoldEarned { get; private set; }

void OnEnemyDied(SurvivalUnit e)
{
    int reward = Mathf.RoundToInt(e.GoldReward * GoldMultiplier);
    Gold += reward;
    TotalGoldEarned += reward;              // ← 신규
    AddExp(Mathf.RoundToInt(e.ExpReward * ExpMultiplier));
}

// Restart() 자체를 단일 choke point로 사용 — OnDefeatContinue()·OnPauseRestart() 양쪽 경로 모두 흡수
public void Restart()
{
    int convert = Mathf.RoundToInt(TotalGoldEarned * HeroCurrencyConversionRate);  // 제안 1.0
    CurrencyManager.Instance?.Add(ItemType.Goods, Constant.GOLD_ID, convert);       // ← 신규
    Time.timeScale = 1f;
    UnityEngine.SceneManagement.SceneManager.LoadScene(
        UnityEngine.SceneManagement.SceneManager.GetActiveScene().name);
}
```
씬 리로드로 `SurvivalBattleManager` 인스턴스 자체가 재생성되므로(`Awake()` 재호출) `TotalGoldEarned`는 다음 런에서 자동으로 0부터 시작한다 — 중복 전환 위험 없음.

**전환율 100% 채택 근거**: `Gold`(런 내 소모 가능)와 별개로 `TotalGoldEarned`(런 내 소모와 무관, 누적만)를 추적해 **"이번 판에서 쓴 골드"와 "영구 재화로 남는 골드"를 완전히 분리**한다. 이러면 "런에서 안 쓰고 아끼는 것이 아웃게임에 유리하다"는 역유인이 생기지 않는다(총 획득량 기준이므로 오히려 잘 플레이할수록 — 더 오래 살아남아 더 많이 죽일수록 — 아웃게임 성장도 빨라져 "실력=보상" 원칙과 정합). 100%는 초기값이며 §11 리스크에 튜닝 구간을 명시한다.

**미해결 표시(plan-auditor M-2 반영) — 보상 팝업 표기 불일치**: `SurvivalUIController.cs`의 Victory/Defeat 팝업 보상란은 현재 `M.Gold`(런 내 잔여, 소비 후 남은 값)를 표시한다(`_victoryReward.text = $"{M.Gold:N0}"` 등, 코드 확인). 전환 재화는 `TotalGoldEarned`(총 획득량, 잔여보다 항상 크거나 같음)를 쓰므로 **팝업에 보이는 숫자와 실제로 영구 전환되는 숫자가 다르다**. 이 문서 범위에서 UI 문구까지 확정하지 않으며, §14 후속 조치에 UI 동반 수정 필요 항목으로 명시한다(ux-designer·클라이언트팀 협의 대상).

**세그먼트 영향**: 현재 상점 IAP 골드팩과 이 브릿지는 **같은 `GOLD_ID` 풀을 공유**한다. 즉 고과금 유저는 골드팩 구매로 Layer①②를 더 빨리 채울 수 있다 — 이는 결함이 아니라 "무과금은 플레이로, 과금은 시간 단축으로" 표준 F2P 구조이며, 메타v1 §1-1의 디폴트 권고(기존 골드 재사용)가 의도한 결과와 일치한다.

---

## 3. Layer① 영웅레벨(HeroLevel) 설계

### 3-1. 설계 전제

원작 `hero_level.csv`(1800행=12진영×150레벨)의 **핵심 비대칭**(예산은 선형, 비용은 3차 — 매핑v1 §2-1)을 형태만 이식한다. 원작 절대치(스탯 1e0~1e3, 비용은 "경험서" 단위)는 규모·통화 단위 모두 불일치하므로 폐기(청사진 §0 승계, 재추출v1 §0이 "hero_level엔 hp 컬럼 자체가 없다"는 사실로 재확인 — 개별 스탯 분해식은 원본 데이터가 애초에 지원하지 않는다).

- **레벨 범위**: 1~60 (0=초기 상태, `SurvivalMetaData.HeroLevel` 기존 필드 그대로)
- **60을 택한 근거**: §4 승급 star11 게이팅(5×12=60)과 나눗셈 없이 정확히 맞물리도록 역산 — 원작의 "성29=148/성30=150 클램프 불일치"(§5-5) 같은 반올림 경계 버그를 원천 회피하는 설계
- **기여 스탯**: 공격력·체력 2종(4:1 비율, `공격력_원작2층_재설계_v2.md` §5가 이미 확립한 유도 방식과 동일 원칙 재사용)

### 3-2. 공식

```
AttackBudget(L) = 2 × L                         (flat, 선형)
HpBudget(L)     = 8 × L  = 4 × AttackBudget(L)   (flat, 선형, A80ChampMatchConfig 4:1 준수)

Cost(L)  [L-1 → L 승급 비용, GOLD_ID]
  = 0.2×L³ + 1.8×L²
  = 0.4 × (0.5×L³ + 4.5×L²)     ← 원작 hero_level cost(L) 형태 × 0.4 축소
```

**0.4 축소 계수 도출**: `Cost(60)`을 목표값 약 50,000G에 맞추기 위해 역산했다. 원작 `cost(60)=0.5×60³+4.5×60²=124,200`(원작 "경험서" 단위, 무의미) → `50,000/124,200≈0.4027` → 깔끔한 계수 **0.4**로 반올림해 `Cost(60)=49,680G`을 얻었다(§3-3 표 확인). 이 축소 계수 0.4가 **본 설계의 1차 튜닝 손잡이**다 — 플레이테스트 결과 레벨업이 너무 빠르거나 느리면 이 상수 하나만 조정하면 전체 곡선 형태(3차 가속)는 그대로 유지된다.

### 3-3. 수치 테이블 (체크포인트 — 전체 60행은 공식 적용 결과, 대표 구간만 표기 C14)

| Level | AttackBudget | HpBudget | 단계 비용(Cost) | 누적 비용 |
|---|---|---|---|---|
| 1 | 2 | 8 | 2 | 2 |
| 5 | 10 | 40 | 70 | 144 |
| 10 | 20 | 80 | 380 | 1,298 |
| 15 | 30 | 120 | 1,080 | 5,112 |
| 20 | 40 | 160 | 2,320 | 13,986 |
| 25 | 50 | 200 | 4,250 | 31,070 |
| 30 | 60 | 240 | 7,020 | 60,264 |
| 35 | 70 | 280 | 10,780 | 106,218 |
| 40 | 80 | 320 | 15,680 | 174,332 |
| 45 | 90 | 360 | 21,870 | 270,756 |
| 50 | 100 | 400 | 29,500 | 402,390 |
| 55 | 110 | 440 | 38,720 | 576,884 |
| **60(캡)** | **120** | **480** | 49,680 | **802,638** |

### 3-4. 성장 곡선 — 예산은 직선, 효율은 급락

- **AttackBudget/HpBudget**: 완전 선형(레벨당 균일 +2/+8) — 원작 "예산은 선형" 원칙 그대로.
- **비용**: 3차 가속. 골드/공격력포인트 단가(`Cost(L)/2`)가 **L1의 1G/point → L60의 24,840G/point로 24,840배 상승**(원작 매핑v1 §2-1의 "181배"보다 가파른 것은 우리가 150레벨을 60레벨로 압축했기 때문 — 같은 상대적 감속을 더 짧은 구간에 눌러 담은 결과, 의도된 설계).
- **후반 집중**: 마지막 10레벨(51~60)의 비용(802,638−402,390=400,248G)이 **전체 누적 비용의 49.9%**를 차지 — 원작의 "후반 급가속" 철학이 정확히 재현됨.
- **런 환산(§2-4 참고 앵커, 🟡추정)**: 아래 §6 참고.

---

## 4. Layer② 승급(Promotion) 설계

### 4-1. 설계 전제

원작 `hero_star.csv`(186행=6등급×31성)의 진짜 기능은 **% 보너스가 아니라 레벨 캡 게이팅**(매핑v1 §2-2 "핵심: 성급의 진짜 기능은... 레벨 캡 게이팅이다"). GodDem은 히어로가 1명뿐이라 원작의 "quality"(진영별 희귀도 1~6) 축이 성립하지 않는다 — 이를 **비용식과 보너스식에서 서로 다르게 처리**한다(사유는 각 항목에 명시, 결정 근거 투명성 C5).

- **star 범위**: 0(초기)~11(캡) — 12단계(원작 31단계 대비 축소)
- **11을 택한 근거**: `5×(star+1)`이 정확히 60(=HeroLevel 캡)에 도달하는 지점이 star=11(`5×12=60`) — 나머지·클램프 없이 딱 맞물림

### 4-2. 공식

**비용 — quality=1 고정, 재계수화 없음**:
```
Cost(star → star+1) = (star+1)³ × (star+50)      [quality=1 대입, 원작 공식 그대로]
```
*채택 사유(plan-auditor M-3 반영 — 근거 재작성)*: 원작 quality 1~6은 히어로 희귀도를 나타내는 축이며, **원작 공식 내부**에서는 비용 대비 보너스 효율이 quality에 무관하게 동일하다(`Cost/Bonus` 비를 대수적으로 정리하면 quality가 약분되어 사라짐 — quality는 원작 내부의 순수 스케일 파라미터). 그러나 이 약분 성질은 quality=1과 quality=6 어느 쪽이든 "원작 안에서는 동등히 정당하다"는 뜻일 뿐 **quality=1을 특정해서 지목하는 근거는 아니며**, quality=1은 "보수적"이 아니라 원작 절대비용이 **가장 저렴한(가장 관대한) 값**이다(quality=6 대비 1/6). 실제 채택 이유는 단순함이다 — 별도 배율 계수를 곱하지 않고 원작 공식의 리터럴 최저 케이스를 그대로 쓸 수 있는 유일한 지점이기 때문이다. **다만 이 선택은 보너스식(아래) 결정과 독립적이다** — 보너스에는 quality=1을 대입하지 않고 §7 목표에서 역산한 별도 계수를 쓰므로, 원작의 "Cost/Bonus 비 불변" 성질은 우리 최종 설계에서 더 이상 성립하지 않는다(계산 결과 우리 Cost/Bonus 비는 원작 대비 약 1/10 — 원작보다 10배 관대, 아래 단락에서 상술). 이는 "원작 그대로"가 아니라 "형태는 원작에서, 절대 관대함은 우리 목표로 재설계"했음을 투명하게 밝히는 것이며(C5), 비용식(원작 리터럴 근거)과 보너스식(§7 클램프 검증을 만족해야 하는 우리 목표치)이 서로 다른 설계 압력을 받으므로 굳이 하나의 quality 값에 묶어둘 이유가 없다는 판단이다.

**보너스 — 원작 축소형(quality×0.002) 대신 목표 역산 채택**:
```
AttackBonusRatio(star) = HpBonusRatio(star) = PromoDefenseAddRatio(star) = 0.02 × star   (3스탯 동일값, 원작 원칙 유지)
```
*채택 사유*: 원작 그대로 quality=1을 보너스 공식(`0.002×quality×star`)에도 대입하면 star=11 최댓값이 `0.002×1×11=0.022`(2.2%)로 무의미한 수준이다 — 원작에서 이 계수가 유의미했던 건 실제 플레이 quality가 최대 6까지 올라가기 때문(원작 최댓값 `0.002×6×30=0.36`, 36%)이며, 우리는 quality 축 자체가 없으므로 이 결합을 그대로 가져오면 "형태 재사용"이 아니라 "의미 없는 숫자 재사용"이 된다. 대신 §7의 defense 클램프 결합 검증(0.8→0.844, 완만한 상승)을 만족하는 **목표값 22%(star11)를 먼저 정하고 역산**해 star당 +2%(선형)를 얻었다. 이는 C5 원칙에 따라 "원작 공식이 아니라 우리 목표에서 역산했다"는 점을 투명하게 밝힌다. **정량 고지**: `0.02÷(0.002×1)=10` — 우리 보너스 계수는 quality=1 대입 원작값의 정확히 10배다. 비용은 quality=1(원작 그대로) 유지·보너스만 10배 인상했으므로, 우리 게임의 Cost/Bonus 비는 원작(quality 무관 고정비)의 약 1/10 — 즉 **원작보다 별 하나당 10배 더 관대한 보너스**를 설계한 것이며, 이는 우연이 아니라 §7 클램프 검증 목표(22%)를 만족시키기 위한 의도적 선택이다.

**레벨캡 게이팅**:
```
MaxHeroLevel(star) = 5 × (star + 1)     [원작 형태 그대로, 재계수화 없음]
CanLevelUp() := SurvivalMeta.Data.HeroLevel < MaxHeroLevel(PromotionStar)
```

### 4-3. 수치 테이블 (전체 12행 — 원작 186행 대비 압축이므로 전량 표기)

| Star | 비용(→Star) | 누적 비용 | AttackBonusRatio | HpBonusRatio | PromoDefenseAddRatio | LevelCap |
|---|---|---|---|---|---|---|
| 0(초기) | — | 0 | 0% | 0% | 0% | 5 |
| 1 | 50 | 50 | 2% | 2% | 2% | 10 |
| 2 | 408 | 458 | 4% | 4% | 4% | 15 |
| 3 | 1,404 | 1,862 | 6% | 6% | 6% | 20 |
| 4 | 3,392 | 5,254 | 8% | 8% | 8% | 25 |
| 5 | 6,750 | 12,004 | 10% | 10% | 10% | 30 |
| 6 | 11,880 | 23,884 | 12% | 12% | 12% | 35 |
| 7 | 19,208 | 43,092 | 14% | 14% | 14% | 40 |
| 8 | 29,184 | 72,276 | 16% | 16% | 16% | 45 |
| 9 | 42,282 | 114,558 | 18% | 18% | 18% | 50 |
| 10 | 59,000 | 173,558 | 20% | 20% | 20% | 55 |
| **11(캡)** | 79,860 | **253,418** | **22%** | **22%** | **22%** | **60** |

### 4-4. 레벨캡 게이팅 검증 — "승급이 레벨의 문지기"

Star0(초기)만으로도 HeroLevel 1~5는 즉시 구매 가능(누적 비용 144G, §3-3 — 1런 미만). Level6부터는 Star1 승급(50G, 사실상 무료 수준)이 선행되어야 한다. 승급 비용은 항상 같은 구간의 레벨업 비용보다 훨씬 저렴하다 — 예: Star4→5 승급(6,750G) vs Level26~30 레벨업(29,194G, 약 4.3배) — 이는 "승급은 저렴한 문 열기, 실제 그라인드는 레벨"이라는 원작 설계 의도(매핑v1 §2-2)가 우리 스케일에서도 유지됨을 확인한다.

### 4-5. 🔴 hero_star 레벨캡 불일치 — 재실측 필요 (개발팀장 APK 재추출 표시)

매핑v1 §2-2가 남긴 "성29=148(공식상 150이어야 함)/성30=150, 6등급×2행=12행 불일치" 이슈는 **본 설계에서는 직접 부딪히지 않는다** — 우리는 star11(=cap60)에서 멈추도록 설계했고, `5×(11+1)=60`은 정확히 딱 떨어져 클램프 자체가 발생하지 않는다(§3-1 근거). 그러나 이 불일치의 **원인 자체**(공식 오류인지 원작의 의도적 상한 클램프 부작용인지)는 여전히 미해소이며, **향후 캡을 확장할 경우**(예: PD가 star12 이상, level65 이상으로 콘텐츠를 늘리기로 결정하는 시점) 동일 클래스의 반올림 경계 버그가 재발할 수 있다.

**재추출 시 필요 데이터(직접 재추출 불가, 개발팀장 표시)**: `hero_star.csv`의 **star=28, 29, 30 행 전체(6등급×3star=18행)**의 `max_level` 컬럼 원본값. 확인 목적: `max_level` 컬럼이 `5×(star+1)` 공식에서 이탈하는 지점이 (a) 150 클램프 로직(설계 의도) 때문인지 (b) 데이터 입력 오류인지 판별. 현재 설계에는 즉시 필요하지 않으므로 **P3-B1 착수 차단 조건은 아니며**, 향후 캡 확장 검토 시점의 선행 조건으로 유보한다.

---

## 5. 매판 시작 베이스 결합 — FinalAttack()/FinalHp() 확정

메타v1 §3-4가 제시한 캡슐화 방향을 그대로 채택하고, Layer①②의 실제 항을 채워 확정한다.

```csharp
// SurvivalMeta.cs — 신규 메서드(호출부는 전부 이것만 부른다, 3중 SOT 방지)
public static float FinalAttack() =>
    (BaseAttack + TotalAttack() + HeroLevelAttackBudget()) * (1f + PromotionAttackRatio());

public static float FinalHp() =>
    (BaseHp + TotalHp() + HeroLevelHpBudget()) * (1f + PromotionHpRatio());

static float HeroLevelAttackBudget() => 2f * Data.HeroLevel;              // §3-2
static float HeroLevelHpBudget()     => 8f * Data.HeroLevel;              // §3-2
static float PromotionAttackRatio()  => 0.02f * Data.PromotionStar;       // §4-2 (3스탯 동일 계수)
static float PromotionHpRatio()      => 0.02f * Data.PromotionStar;
public static float PromotionDefenseRatio() => 0.02f * Data.PromotionStar; // §7 defense 결합식이 참조(public — RecalcPlayer 외부 호출)

// 호출부 정정 (메타v1 §3-4 4곳 그대로 적용)
// ApplyMetaEquipment(): PlayerAttack = SurvivalMeta.FinalAttack(); PlayerHp = SurvivalMeta.FinalHp();
// SurvivalLobbyController.Hero.cs RefreshHeroStats()/UpdatePropertyText(): 동일 호출로 교체
```

`TotalAttack()`/`TotalHp()`는 기존 장비 합산 로직을 그대로 유지하고 그 안에 `HeroLevelAttackBudget()`/`HeroLevelHpBudget()` 항만 추가하는 형태(메타v1 §3-4 스켈레톤과 동일 구조, ③장비강화 항은 P3-B2 범위이므로 본 문서는 자리만 예약).

### 5-1. 결합 시나리오 검증 (신규~맥스 4단 밴드)

| 밴드 | HeroLevel | PromotionStar | 장비 | FinalAttack | FinalHp |
|---|---|---|---|---|---|
| 신규(하위호환 확인) | 0 | 0 | 0/0 | **22**(불변) | **400**(불변) |
| 초반 진행 | 10 | 2 | 0/0 | (22+0+20)×1.04=43.7 | (400+0+80)×1.04=499.2 |
| 중견 | 30 | 5 | 47/305(풀장착) | (22+47+60)×1.10=141.9 | (400+305+240)×1.10=1,039.5 |
| **맥스** | 60 | 11 | 47/305(풀장착) | (22+47+120)×1.22=**230.6** | (400+305+480)×1.22=**1,445.7** |

신규 유저 기준선(22/400)이 기존과 완전히 동일함을 확인 — **비파괴 확인 통과**.

**주의(TTK 연쇄 영향, §11 리스크 연계)**: 맥스 밴드의 FinalAttack 230.6은 현재 "장비만" 상한(69, S3 v2)의 **3.3배**다. 몬스터 스탯(EnemyBaseHp 등)은 아웃게임 진척도와 무관하게 고정이므로, 장기 유저는 초반 웨이브를 지금보다 훨씬 더 압도적으로 통과하게 된다 — 이는 S3 v2가 이미 식별한 R-J("장비 상한 유저 웨이브1~2 무위협")를 **심화**시키는 방향이다. 본 문서 범위(스테이지 설계는 P3-C)에서 대응하지 않되, 은폐하지 않고 §11에 명시한다.

---

## 6. 런 환산 참고표 (🟡 추정 — 플레이테스트 전 안전판)

Layer①② 총 누적 비용(802,638+253,418=1,056,056G)을 "런 몇 회분"으로 환산하려면 "평균 런이 몇 골드를 버는가"가 필요한데, Stage가 무한 증가 구조라 **이 값 자체가 미확정**(스테이지 도달 깊이에 좌우, 플레이테스트 데이터 없음). 확정된 앵커(S3 v2, 20웨이브/2스테이지=2,542G)를 보수적 하한으로, 계단형 지수 공식을 그대로 연장한 스테이지10(100웨이브) 값을 낙관적 참고치로 병기한다.

| 시나리오 | 런당 골드(참고) | Layer① 소요 런수 | Layer② 소요 런수 | 합계 소요 런수 |
|---|---|---|---|---|
| 보수적 하한(S3 v2 앵커, 2스테이지 클리어) | 2,542G | 316런 | 100런 | 416런 |
| 중간 참고(5스테이지 클리어, 계단식 지수 공식 연장) | 8,200G | 98런 | 31런 | 129런 |
| 낙관적 참고(10스테이지 클리어) | 22,550G | 36런 | **12런** | **48런** |

**해석**: 초반 레벨(L1~10, 누적 1,298G 미만)은 어느 시나리오에서도 **1런 이내** 도달 가능(즉각적 보상 체감 확보). 완전 맥스(캡60/star11)는 실력·투자에 따라 **48~416런**의 넓은 폭 — 이는 결함이 아니라 "장기 리텐션 콘텐츠"로서 의도된 넓은 목표이나, 폭 자체가 크므로 **실제 평균 런 도달 스테이지 플레이테스트 데이터 확보 후 §3-2의 0.4 축소계수·§4-2의 quality=1 재검토**를 권고한다(변수화·구간화 원칙).

---

## 7. defense 클램프 분리 결합식 확정 (메타v1 R-B2 해소)

메타v1 §3-4가 스스로 지적한 함정(승급 defense%를 인게임과 같은 0.8 클램프에 그냥 더하면, 인게임 클램프에 이미 근접한 장기 유저는 그 판의 방어 강화 선택이 무의미해짐)을 **곱연산 분리식**으로 해소한다. 이것이 메타v1이 "P3-B1에서 balance-designer 확정" 요청한 바로 그 결정이다.

```csharp
// RecalcPlayer() 확정 수정 — 메타v1 §3-4 코드 스니펫(단순 가산)을 대체
float ingameReduce = Mathf.Clamp(
    t.Total("hurt_reduce") + t.Total("defense_add") + t.Total("dodge_rate"), 0f, 0.8f);   // 기존 로직 완전 불변
float outgameRatio = SurvivalMeta.PromotionDefenseRatio();                                  // §4-2, 0~0.22
Player.DamageReduction = 1f - (1f - ingameReduce) * (1f - outgameRatio);
```

### 7-1. 검증 테이블

| 인게임 감소(클램프 후) | 승급 defense% | 최종 DamageReduction | 비고 |
|---|---|---|---|
| 0 | 0 | 0 | 신규 유저, 기존과 동일 |
| 0 | 22%(star11) | 22% | 인게임 미투자자도 항상 체감(§메타v1 지적 사항 해소 확인) |
| 0.8(캡) | 0 | 80% | 기존 그대로 |
| 0.8(캡) | 22%(star11) | **84.4%** | 클램프 근접 유저도 승급 투자가 여전히 유효(0.8→0.844, +4.4%p) — **함정 해소 확인** |
| 0.5 | 11%(star5) | 55.5% | 중견 밴드 참고 |

100%(완전 무적)에 도달하려면 `ingameReduce=1`이거나 `outgameRatio=1`이어야 하는데, 전자는 기존 0.8 클램프가 막고 후자는 §4 설계상 최댓값이 0.22이므로 **극한에서도 무적화되지 않음**을 수식적으로 확인.

---

## 8. 데이터 모델 — CSV 스키마 실값 (메타v1 §5-2 스키마 준수)

### 8-1. `SurvivalMetaHeroLevel.csv`

```
n_Level,l_RequireCost,f_AttackBudget,f_HpBudget
영웅레벨,강화비용(GOLD_ID),공격력예산(누적아님·해당레벨 1회성 flat),체력예산(동일)
1,2,2,8
2,9,4,16
...(공식 0.2L³+1.8L² / 2L / 8L 적용, 3~59행 생략 — §3-3 체크포인트 참고)
60,49680,120,480
```
*컬럼 의미*: `f_AttackBudget`/`f_HpBudget`은 **그 레벨 1회분 증가량**(누적 아님) — `SurvivalUpgradeTable.Total()`과 동일하게 로더가 `HeroLevel` 이하 전 행을 순회 합산하는 방식(§5의 `HeroLevelAttackBudget()=2×Data.HeroLevel`은 이 합산의 폐쇄형 결과와 동일하므로 런타임은 공식으로 직접 계산해도 무방 — CSV 실값과 공식 계산값이 반드시 일치해야 함을 QA 체크리스트에 명시).

### 8-2. `SurvivalMetaPromotion.csv`

```
n_Star,n_Quality,l_GoldCost,n_LevelCap,f_AttackBonusRatio,f_HpBonusRatio,f_PromoDefenseAddRatio
승급성급,등급(단일히어로 고정값·§4-2 비용식 전용),골드비용(→해당성급),레벨상한,공격%보너스,체력%보너스,방어%보너스
0,1,0,5,0,0,0
1,1,50,10,0.02,0.02,0.02
2,1,408,15,0.04,0.04,0.04
3,1,1404,20,0.06,0.06,0.06
4,1,3392,25,0.08,0.08,0.08
5,1,6750,30,0.10,0.10,0.10
6,1,11880,35,0.12,0.12,0.12
7,1,19208,40,0.14,0.14,0.14
8,1,29184,45,0.16,0.16,0.16
9,1,42282,50,0.18,0.18,0.18
10,1,59000,55,0.20,0.20,0.20
11,1,79860,60,0.22,0.22,0.22
```

**`n_Quality` 필드 주의**: 스키마는 메타v1이 확정했으므로 컬럼 자체는 유지하되(향후 다중 히어로 확장 시 재사용 대비), 현재 로더는 이 값을 비용식 계산에 사용하지 않는다(비용은 이미 `l_GoldCost`에 리터럴로 계산 완료돼 있음, quality=1은 §4-2 도출 근거의 기록용 표기). `f_*Ratio` 3열도 quality 파생이 아니라 §4-2에서 목표 역산한 리터럴값이다 — 런타임이 `n_Quality × 0.002`를 계산하지 않도록 주의(원작 공식과 다른 값이 될 것).

### 8-3. `SurvivalMetaData` 스키마 정정 제안 (메타v1 §5-1 대비)

메타v1 §5-1이 예비해 둔 `public long HeroLevelExp` 필드는 **본 설계에서 불필요**하다 — 원작의 "골드→경험서→소비 2단 경제"를 스킵하고 골드를 직접 소비하기로 확정했으므로(§1, 메타v1 §1-1 열린 이슈의 본 문서 결론) 중간 경험치 자원 자체가 없다. 구현 시 이 필드는 제외 권고(죽은 필드 방지, C22 일관성).

---

## 9. 검증 시나리오

| # | 시나리오 | 통과 기준 | 결과 |
|---|---|---|---|
| 1 | 기준선 무결성 — HeroLevel0/PromotionStar0/미장착 | FinalAttack=22, FinalHp=400 | **통과**(§5-1) |
| 2 | 즉각 접근성 — 신규 유저 Level1~5 | 승급 없이 구매 가능, 누적비용<1런 | **통과**(Star0 캡=5, 누적 144G) |
| 3 | 게이팅 검증 — Level6 시도 | Star0(캡5) 상태에서 차단, Star1 승급(50G) 후 허용 | **통과**(설계상 자명, §4-4) |
| 4 | defense 클램프 안전성 — 극한값 | DamageReduction < 100% 항상 성립 | **통과**(§7-1, 최댓값 84.4%) |
| 5 | 맥스 밴드 인게임 영향 | 참고치(밴드 강제 아님) | FinalAttack 230.6(현재比 3.3배) — **R-J 심화 확인, §11로 이관** |
| 6 | 활성 스킬 증폭 상호작용 | 참고치 | §11 R-C4 참고 |
| 7 | 레벨캡 나눗셈 정합 | `5×(star+1)`이 원작 클램프 버그 구간(성29/30) 재현 안 함 | **통과**(star11=cap60 정확히 나눔, §4-5) |

---

## 10. 밸런싱 제안 표

| 항목 | 현재 값 | 제안 값 | 근거 |
|---|---|---|---|
| HeroLevel 범위 | 없음(신규) | 1~60 | 승급 star11×5 게이팅과 나눗셈 없이 정합(§3-1) |
| HeroLevel AttackBudget/레벨 | 없음 | +2(flat, 선형) | hp Flat 트랙 4:1 유도 관례 계승(§3-2) |
| HeroLevel HpBudget/레벨 | 없음 | +8(flat, 선형) | =4×AttackBudget, A80ChampMatchConfig 4:1(§3-2) |
| HeroLevel 비용식 | 없음 | `0.2L³+1.8L²` | 원작 hero_level cost 형태×0.4(L60=49,680G 역산, §3-2) |
| Promotion 범위 | 없음(신규) | star 0~11 | HeroLevel60을 정확히 게이팅(§4-1) |
| Promotion 비용식 | 없음 | `(star+1)³×(star+50)`, quality=1 | 원작 hero_star quality=1 그대로, 재계수화 없음(§4-2) |
| Promotion 보너스/star | 없음 | +2%(공/방/HP 동일) | defense 클램프 결합 검증(0.8→0.844) 기반 목표 역산(§4-2·§7) |
| defense 결합식 | 없음(메타v1 나이브 가산 초안) | 곱연산 분리식(§7) | R-B2 함정(클램프 근접 시 아웃게임 투자 무의미화) 회피 |
| 런→영구골드 전환 | 없음(브릿지 부재, §2 신규 발견) | `TotalGoldEarned`×100% | 스펜드/축적 딜레마 제거, 실력 비례 성장(§2-3) |

**세그먼트 영향**: 전 항목 **현재 전 세그먼트 동일**(Survival IAP 미연동, S3 v2·공격력2층v2와 동일 고지 승계). `GOLD_ID`가 상점 골드팩과 공유되므로, 향후 상점 IAP 결선 시 **고과금 유저는 골드 구매로 Layer①②를 시간 단축 가능**(🟡추정 리스크, §2-3에서 이미 F2P 표준 구조로 판단·별도 조치 불요).

---

## 11. 리스크

| ID | 리스크 | 심각도 | 내용 |
|---|---|---|---|
| **R-C1(신규, plan-auditor 지적 반영)** | 런→영구골드 브릿지 부재 + 런 종료 경로 2개(`OnDefeatContinue()`·`OnPauseRestart()`) | 높음(구현 필수) | §2 신규 발견 — `TotalGoldEarned` 필드·전환 코드 없이는 Layer①②가 소비할 재화 자체가 유입되지 않는다. 최초 설계는 `OnDefeatContinue()` 1곳에만 훅을 심으려 했으나 plan-auditor가 `OnPauseRestart()`도 동일하게 `M.Restart()`를 호출함을 코드로 확인(본 balance-designer 재확인 완료) — **`SurvivalBattleManager.Restart()` 자체를 단일 choke point로 정정**(§2-3). P3-B1 구현의 **선행 필수 항목**, 팀장급 확인 필요 |
| **R-C2(신규)** | 평균 런 도달 스테이지 미확정 | 중(🟡추정) | §6 — "완전 맥스까지 몇 런"의 폭이 48~416런으로 넓다. 실제 플레이테스트로 축소계수(0.4)·quality(1) 재조정 필요 |
| R-C3(해소) | defense 클램프 공유 시 아웃게임 투자 무의미화(메타v1 R-B2) | — | §7 곱연산 분리식으로 해소 확인(수식 검증 통과) |
| **R-C4(승계·수치 정정, plan-auditor M-1)** | `SurvivalActiveSkillRunner.BaselineAttack=22f` 상수 복제(메타v1 R-B4) | 중 | **최초 계산에 `RecalcPlayer()`의 `atkRatio=Total("attack_add")+Total("hurt_add")` 중 `hurt_add`(누적 0.87) 누락 오류가 있었다 — plan-auditor 지적으로 정정.** 올바른 계산: 현재 맥스(장비만, FinalAttack=69) → `Player.Attack=(69×(1+0.87+0.87)+1650)=1,839` → 배율 1839/22=**83.6배**. 미래 맥스(Hero60+Promo11+장비, FinalAttack=230.6) → `Player.Attack=(230.6×2.74+1650)=2,282` → 배율 2282/22=**103.7배**. 증폭 103.7/83.6=**+24.1%**(최초 발신값 "+17%"보다 큼 — 리스크는 과소 보고돼 있었다). P3-B1 구현과 **병행 수정 권고**(`BaselineAttack`→`SurvivalMeta.BaseAttack` 참조 교체, 1줄 수정) |
| **R-C5(승계·부분 해소)** | hero_star 레벨캡 성29/30 불일치 미해소 | 낮음(현재 무관) | §4-5 — 본 설계(star11=cap60)는 이 구간과 부딪히지 않으나, 향후 캡 확장 시 재발 가능. 재추출 필요 데이터 명시 완료(§4-5) |
| **R-C6(신규)** | 맥스 밴드 인게임 초반 웨이브 무위협 가속 | 중(범위 외) | §5-1 — S3 v2 R-J를 심화. 스테이지 설계(P3-C) 영역이므로 본 문서에서 대응하지 않되, system-designer·PD 인지 필요 사항으로 명시 |
| **R-C7(신규)** | 상점 골드팩 판매력 재산정 필요 가능성 | 낮음(정보성) | §10 — Layer①②라는 새 골드 소모처가 생기면 기존 골드팩(500~48,000) 판매 매력이 상대적으로 상승할 수 있음(소모처 증가=재화 가치 상승). 데이터 없는 선제 조정은 C2 위반이므로 관찰만 권고 |

---

## 12. 기각안 (C32)

| # | 검토안 | 기각 사유 |
|---|---|---|
| 1 | Promotion에 원작처럼 quality 1~6 다중 등급(히어로 희귀도) 도입 | GodDem은 히어로 1명 고정 — 희귀도 시스템 자체가 없어 다중 quality를 도입할 근거 데이터가 없다(범위 밖, 가챠 B3와도 무관한 별개 축) |
| 2 | HeroLevel을 원작 150레벨 그대로 채택 | 청사진 §0 "150레벨 스케일 그대로 대입 불가" 전제 + 재추출v1 §0 "hero_level엔 스탯 개별 분해식 자체가 없음" 확정 — 규모·데이터 양쪽 이유로 재산정 필수 |
| 3 | Promotion 보너스도 quality=1을 그대로 대입(0.002×1×star, 최댓값 2.2%) | 원작 원형은 보존되나 체감 임팩트가 무의미한 수준 — §7 defense 클램프 결합 검증이 성립하는 목표치(22%)를 먼저 정하고 역산하는 편이 "형태는 재사용하되 의미 있는 값" 원칙에 더 부합 |
| 4 | 신규 전용 중간재("영웅 증표" 등) 도입 | 메타v1 §1-1 디폴트 권고(기존 골드 재사용) 존중 + C50 범위 확대 방지 — 기존 골드 재사용만으로 설계 목표(장기 성장 유인) 달성 가능, 별도 통화 UI·환전 로직 등 불필요한 복잡도 회피 |
| 5 | 승급 게이팅을 없애고 HeroLevel 완전 자유 성장 | 원작 실측(매핑v1 §2-2)의 "승급의 진짜 기능=레벨캡 게이팅" 원칙과 메타v1 §1-2 확정 방향을 정면으로 위반 — 이미 PD 승인된 방향(C36) |
| **6(plan-auditor m-3 반영 — #6 재작성)** | HeroLevel·Promotion을 원작처럼 상한 없이(무한 확장) 설계 | 메타v1 §1-1이 이 방향("상한 없음")을 명시했으나, CSV 테이블 구조는 무한 행을 미리 채울 수 없어 실제 구현이 불가능하다(원작조차 실제로는 150에서 멈춘 유한 시스템, 매핑v1 §2-1). 60/11 유한 캡을 채택하되 이 반전 자체는 §0·§3-1에 은폐 없이 명시하고 시스템기획·PD 인지를 요청했다(C36 경계) |

**참고(기각 아님, 튜닝값 명시)**: 런종료 전환율(§2-3)은 100%로 제안했으나 이는 "기각된 대안"이 아니라 **1차 제안값**이다 — §11 R-C2(평균 런 도달 스테이지 미확정) 해소 후 플레이테스트 결과에 따라 50~100% 구간에서 하향 조정 가능한 손잡이로 남겨둔다.

---

## 13. 변경 이력 (P16)

| 일시 | 변경자 | 항목 | 이전값 | 이후값 | 사유 |
|---|---|---|---|---|---|
| 2026-08-22 | balance-designer | 문서 신규 작성(v1) | — | 본 문서 전체(Layer①② 실수치·결합식·CSV 스키마 실값) | PD 승인 "설계대로 진행" 집행, 메타v1 §P3-B1 유보사항 확정 |
| 2026-08-22 | balance-designer | 런→영구골드 브릿지 설계 | 없음(메타v1 미언급) | `TotalGoldEarned`+`Restart()` 단일 choke point 전환 100% | C39 실측 중 브릿지 부재 신규 발견, C3 은폐 없이 반영 |
| 2026-08-22 | balance-designer | defense 클램프 결합식 확정 | 메타v1 나이브 가산 초안(R-B2 리스크 열림) | 곱연산 분리식 `1-(1-in)×(1-out)` | 메타v1이 명시 위임한 "P3-B1에서 balance-designer 확정" 이행 |
| 2026-08-22 | balance-designer | plan-auditor 감사 반영 최종화(같은 v1 내 확정) | 초안(Critical 1·Major 4·Minor 3 지적 전) | Critical(브릿지 choke point `OnDefeatContinue()`→`Restart()` 이전)·Major(R-C4 배율 80.9→83.6배·94.6→103.7배 정정, §4-2 quality 근거 재작성, M-4 상한반전 고지, 보상팝업 표기 불일치 명시)·Minor(인용 §5-3→§0 2건, §6 12런/48런 정정, 기각안#6 재작성) 전부 반영 | C35 감사 게이트 — 조건부통과 정정 완료 후 발신(산술은 전량 무오류 확인됨) |

---

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

1. **개발팀 구현 선행 필수(팀장급 확인 후)**: §2-3 전환 브릿지(`TotalGoldEarned`+`Restart()` 단일 choke point) + §5 `FinalAttack()`/`FinalHp()` 신규 메서드 + §7 `RecalcPlayer()` defense 결합식 교체 + §8-3 `HeroLevelExp` 필드 제외.
2. **병행 권고**: R-C4(`SurvivalActiveSkillRunner.BaselineAttack` 상수 참조 교체) — 별건이나 P3-B1과 동시 작업 시 회귀 리스크 낮음.
3. **UI 동반 수정 필요(ux-designer·클라이언트팀 협의)**: §2-3 M-2 — Victory/Defeat 팝업 보상란이 현재 `M.Gold`(잔여)를 표시하는데 영구 전환은 `TotalGoldEarned`(총 획득)을 쓴다. 표기 문구 정합 필요.
4. **개발팀장 재추출**(차단 조건 아님, 향후 캡 확장 대비): `hero_star.csv` star=28~30 전체(18행) `max_level` 원본(§4-5).
5. **system-designer·PD 인지 필요**: ①R-C6(맥스 밴드 초반 웨이브 무위협 가속, R-J 심화) ②§0·§3-1 M-4(HeroLevel 유한 캡 도입이 메타v1 "상한 없음" 명시 방향과 다름, C36 경계) — 둘 다 본 문서는 문제 제기까지만.
6. **PM 공유**: 본 문서 산출 완료를 `개발팀_PD_지시_로그.md`(GodDem/BT13 단일 관리) 및 대화로그 반영.
7. **plan-auditor 교차검증**: 완료(본 문서 헤더 감사 이력 참조) — 후속은 기획팀장 검증(C49) 재상정.