# 수상한잡화점 밸런스 기획 시행착오 아카이브 v1

> **조직**: NerdNavis → BurningTimes 전환 기점 추출
> **대상 프로젝트**: 수상한잡화점 (2D 덱빌딩 로그라이트)
> **차기 프로젝트**: EerieVillage (2D 플랫포머 퇴마)
> **추출일**: 2026-04-20
> **추출자**: 밸런스 기획자 (balance-designer)
> **데이터 소스 실측**: 참조 원본 직접 Read 기반 (C23 준수 — 추정·역할연기 없음)

---

## §1. 데이터 파싱 오해 — 퍼센트값·음수값 해석 실증

### §1-1. 각성트리 퍼센트값 오해 경위

**발생 시점**: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ001 기획팀 → 개발팀)

**오해 내용**: `PCAwakening.json` 테이블에서 `s_Value='500%'` 형식이 `s_Value='5'`와 혼재. 기획팀은 `'500%'`를 "기존 스탯의 500% 배율 적용"으로 해석하여 **각성 만렙 시 DPS +1067% / EHP +197%** 라는 비정상 수치를 산출했다.

**실제 동작**: `table_base.cs` `Get_Value()` 메서드가 `%` 포함 문자열을 `float * 0.01f`로 파싱. 즉 `'500%'` = `500 × 0.01 = 5.0f` = `'5'`와 동일한 고정값. 배율 적용이 아님.

```
// 실제 파싱 로직 (REQ001 응답 코드 근거)
if (IsPercentValue(str)) return float.Parse(str.Replace("%", "")) * 0.01f;
```

**만렙 효과 재계산**: `s_Value='500%'`, `s_UpgradeStatValuePara='100%'`, `n_MaxLv=5` 기준
- 기획팀 추정: `500% + 100% × 4 = 900%` (배율 해석 오류)
- 실제 결과: `5.0 + 1.0 × 4 = +9` (고정값 가산)

**정정 방법**:
1. 개발팀에 REQ 발행 → 코드 레벨 파싱 로직 확인 요청
2. 확인 후 기여도 문서 수치 전면 재계산
3. 데이터 입력 형식 통일 권고 (런타임 동작은 정상이나 가독성 문제)

**차기 프로젝트 EerieVillage 적용 원칙**: 수치 테이블의 문자열 포맷(`%`, `s`, `exp` 등)이 런타임 파싱 로직에 따라 전혀 다른 결과를 낼 수 있다. **밸런스 시트 작성 전 반드시 파싱 함수 코드를 개발팀과 공유·확인**한다. 특히 동일 컬럼 내 혼재 포맷은 오해 위험이 높다.

---

### §1-2. 장비 옵션 음수값 — 디버프 의도 명확화

**발생 시점**: Phase 3 성장 요소 기여도 분석 중 (2026-04-14 REQ002 기획팀 → 개발팀)

**발견 내용**: 8부위 풀셋 장착 시뮬에서 `CriDmg -20%`, `Avoid_Melee -3%`, `HitRate -2` 등 음수 값이 합산. 기획팀은 오류 가능성을 제기.

**실제 의미**: 의도적 트레이드오프 설계. 무기 `MainOption2`가 페널티성 옵션을 고정 보유하는 구조.

| 패턴 | 사례 | 밸런스 의도 |
|------|------|------------|
| 무기 고공격력 + 치명타 피해 페널티 | ATK 강화 대신 CriDmg -20% | 딜러 빌드 트레이드오프 |
| 쿨타임 음수 = 보너스 | `AttackCoolTime -3%` = 공속 +3% 증가 | 스탯명 방향성 주의 |
| 강화로도 완화되지 않는 고정 페널티 | `UpgradeStatValuePara = 0` | 성장해도 단점 유지 |
| 세트 옵션 양수/음수 쌍 | HP -10% + 보호막 +10% | 빌드 방향 차별화 |

**핵심 교훈**: `AttackCoolTime -3%`처럼 **스탯명의 방향성**이 음수값 해석을 역전시키는 사례가 존재한다. 쿨타임 감소 = DPS 증가. 밸런스 계산 시 스탯 의미와 음수 방향을 함께 명시해야 한다.

**차기 프로젝트 EerieVillage 적용 원칙**: 장비·스킬 옵션의 음수값이 "오류"인지 "의도된 페널티"인지는 반드시 설계 문서에 명시한다. 특히 "방향성이 역전되는 스탯(쿨타임·캐스팅타임 등)"은 별도 명세표를 작성한다. DPS/EHP 계산 시 이 방향성 역전을 반영하지 않으면 수치가 왜곡된다.

---

## §2. 어뷰징 판정 임계값 설계 — 서버 이관 원칙

**출처**: `공유/소통/완료/2026-04-17_어뷰징판정_솔루션_기획서_v1.md`

### §2-1. 설계 전제 (재미 우선 원칙 P30 연계)

어뷰징 판정은 "어뷰저를 잡는 것"이 목표가 아니라 **"정직한 플레이어의 재미를 보호"**하는 것이 목표다. 이 전제가 임계값 설계의 모든 수치를 결정한다.

- **false positive 최소화**: 정상 유저를 어뷰저로 오판정하면 성취 경험이 훼손된다. 이것이 C7 재미 우선 원칙 위반이다.
- **안전 마진의 존재 이유**: 프레임 드랍, 클라 시계 오차, 반올림 오차 — 이 기술적 노이즈가 정상 유저를 "경계 초과"로 만드는 구조를 막기 위해 마진이 필요하다.

### §2-2. 임계값 도출 공식

```
경계값 = 시뮬_이론_극값 × 안전마진계수
```

시뮬 이론 극값은 10,000회 이상 반복 시뮬레이션의 상위/하위 0.1% 값을 채택한다. **절대 최대/최소가 아닌** 이유: 시뮬 자체 오차 흡수.

| 벡터 특성 | 마진 방향 | 계수 | 근거 |
|---------|--------|-----|------|
| 클리어타임 (짧을수록 의심) | 하한 = 이론 최단 × 0.80 | 0.80 | 클라 시계 오차 15% 흡수 |
| 획득 재화 (많을수록 의심) | 상한 = 이론 최대 × 1.05 | 1.05 | 반올림·버프 중첩 케이스 흡수 |
| 랭킹 점수 (높을수록 의심) | 상한 = 이론 최대 × 1.10 | 1.10 | 신규 카드 출시 과도기 흡수 |
| 피격 수 (적을수록 의심) | 하한 = 0 (음수만 차단) | — | 0회도 이론상 가능 |
| 미션 카운트 | 상한 = 일일 최대 × 1.00 | 1.00 | 마진 불필요 (정수 카운트) |

**"안전 마진 0%" 기각 근거**: 시뮬 극값 그대로 경계값으로 쓰면 false positive 폭발. 정상 유저도 매번 플래그됨. **재미 원칙 위반.**

### §2-3. 플래그 3단계 — 어뷰저 학습 방지와 false positive 보호 균형

| 단계 | 트리거 | 클라 응답 | 자동 조치 |
|-----|-------|---------|---------|
| F1 경미 | 경계값 +5~10% 초과 | 없음 (무감지) | 플래그 기록만 |
| F2 중대 | +10~50% 초과 또는 F1×3 | "서버 동기화 오류" | 보상 보류 + 알림 |
| F3 확정 | +50% 초과 또는 논리 모순 | "blocked" | 보상 미지급 + 계정 플래그 |

F1에서 클라에게 경고를 노출하지 않는 이유: 어뷰저가 경계값을 학습하지 못하도록 막기 위함.

### §2-4. 기각안 (검토했으나 채택 안 한 방법론)

1. **서버 단독 시뮬 재현 검증**: 서버가 클라 입력을 받아 전투 재시뮬 → 기각. CPU 비용 폭증 + 부동소수점 동기화 이슈. 싱글플레이 구조에 과잉 투자.
2. **머신러닝 이상치 탐지**: 학습 데이터 축적 전 초기 출시 대응 불가. 장기 보조 수단으로만 검토.
3. **클라 단독 판정**: 메모리 조작으로 즉시 무력화. 원천 제외.
4. **안전 마진 0% 엄격 검증**: false positive 폭발 → 재미 원칙 위반으로 기각.

### §2-5. ★조건 교차 검증 (P17 배타 배치 연계)

서버 검증에 기획팀이 정의한 ★조건을 포함시켜야 어뷰저가 "달성 못 한 ★조건을 클리어한 것처럼" 위조하는 AV-4 벡터를 막을 수 있다.

```json
"starConditions": {
  "C6": { "field": "potionUsed", "operator": "==", "value": 0 },
  "N2": { "field": "hitsTaken", "operator": "<=", "formula": "subMapCount * 1" }
}
```

★조건 통과 보고와 필드값이 모순되면 F3 확정 (논리 모순 범주).

**차기 프로젝트 EerieVillage 적용 원칙**: 퇴마 클리어 보상·퍼펙트 클리어 인증 등 서버 검증이 필요한 성취 체계가 있다면, 기획팀이 "이론 극값 산정 방법론 + ★조건 검증 규칙"을 서버 개발팀에 제공하는 역할 분담을 사전에 확정한다. 경계값 수치는 시뮬 가동 후 채우는 구조로 설계 틀을 먼저 확정하면 개발팀과 병렬 진행 가능하다.

---

## §3. Day 11~14 밸런스축 본작업 — TTK 기반 난이도 곡선 체계

**출처**: `공유/소통/기획팀→PM/2026-04-20_Day11-14_밸런스축_본작업_v1.md`

### §3-1. 설계 전제 확정 방식 (앵커 포인트 접근법)

밸런스 수치는 전체를 동시에 잡으려 하지 않고 **앵커 포인트(기준점) 1개를 먼저 고정**한 뒤, 그 기준에서 각 요소의 기여도를 순차 측정하는 방식으로 진행했다.

| 기준 | 값 | 출처 |
|------|---|------|
| 앵커 DPS | 1.05 | Phase 0 전투 시뮬 실측 |
| 앵커 TTK | 5.7s | Phase 0 실측 |
| 앵커 EHP | 64 | Phase 0 실측 |
| G1 풀빌드 실전 DPS | 5.24 | Phase 3 실측 (UTF 14/14 Passed) |
| 장비 세트 완성 기여 | +71.46% | Phase 3 실측 (±0.86% 오차) |

### §3-2. TTK를 "재미"로 번역하는 방법

**재미 정의 선행**: Stage 11~15 = "장비를 맞추기 시작해야 안정적으로 클리어되는 중반 구간." 이 재미 정의가 TTK 목표를 결정한다.

- 카드 단독 DPS(5.24)로 타이트 또는 클리어 곤란 → 장비 투자 동기 부여
- 장비 세트 완성(DPS 8.98)으로 TTK 24~45초 범위 → 긴장감 있되 클리어 가능
- ★1 클리어 TTK 목표: 장비 세트 결합 후 **20~35초 (보스 1체 기준)**

**공식**:
```
TTK (카드+세트) = HP + Shield 합산 / DPS_세트결합
DPS_세트결합 = 5.24 × 1.7146 = 8.98
```

주의: Shield는 직접 감소 방식 (방어력 계수 적용 없음). HP는 방어력 계수 적용.

### §3-3. Stage별 검증 결과 요약

| Stage | HP+Shield 합산 | 세트결합 TTK | C9 가능 | 핵심 주의사항 |
|-------|--------------|------------|---------|-------------|
| 11 | 313.5 (+42%) | 24.6~45.2s | 가능 | 흡혈귀여왕2 Shield 급등 — 의도 설계 |
| 12 | 289.0 (-7.8%) | 17.6~45.2s | 최적합 | C2∧N2 동시 배치 회피 권고 |
| 13 | 253.0 (-12.5%) | 28.2s | **금지** | 단독 보스 — P17 배타 #5 C9 불가 |
| 14 | 300.5 (+18.7%) | 28.2~38.8s | 가능 | N4∧C6 동시 배치 주의 (P17 #3) |
| 15 | 308.5 (+2.7%) | 30.0~38.8s | 가능 | 흑기사1 ATK Max 45 — C2∧N2 금지 (P17 #1) |

**고Shield 보스 패턴**: 흡혈귀여왕2(Shield 315), 메두사2(Shield 230)는 세트+각성 결합 기준에서도 35~45초 영역. 이 구간은 "추가 성장 요소(각성·진화) 투자 동기 부여" 의도로 설계됨.

### §3-4. 성장 단계별 DPS 조합표 (EerieVillage 설계 참조용)

| 성장 조합 | DPS 배율 | 해당 Stage 11 보스 TTK |
|---------|---------|-------------------|
| 카드 단독 | ×1.00 | 42.2s (클리어 곤란) |
| 카드 + 일반장비 | ×1.30 | 32.5s |
| 카드 + 세트완성 | ×1.71 | 24.6s (적정) |
| 카드 + 세트 + 각성 1.50 | ×2.57 | 16.4s (쾌적) |
| 카드 + 세트 + 각성 + 진화 1.40 | ×3.59 | 11.7s (매우 쾌적) |

이 테이블 구조는 "각 성장 요소가 클리어 경험을 어떻게 바꾸는가"를 수치로 직접 보여준다. 재미 설계의 수치 번역 예시로 활용 가능.

---

## §4. 밸런스 자산 변경 전 백업 및 버전 관리 (C6-1 실무)

### §4-1. 백업 포맷 표준

수치 밸런스 파일(xlsm·csv·json) 변경 전 반드시 다음 포맷으로 백업한다.

```
{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}
예: PCAwakening.bak_20260420_1430.json
```

**금지 형식**: `.bak-*` (하이픈), Unix timestamp, 버전 번호 단독 (`_v1.bak`).

### §4-2. 경계값 테이블 버전 관리

어뷰징 판정 경계값 테이블은 게임 밸런스 패치마다 갱신이 필요하다. 이때:

1. **정기 갱신**: 카드 수치 변경·신규 몬스터 추가 시 해당 영역 시뮬 재실행
2. **긴급 갱신**: 어뷰징 신고 접수 또는 랭킹 이상치 감지 시 즉시 재실행
3. **버전 관리**: `boundary_table.bak_YYYYMMDD_HHMM.json` 백업 후 교체
4. **변경 이력**: PD 지시 로그·대화로그에 기각안 포함 기록 (P16 산출물 추적성)

### §4-3. 변경 이력 테이블 필수 항목

밸런스 파일 하단에 다음 형식으로 기록한다.

| 일시 | 변경자 | 변경 필드 | 이전값 → 이후값 | 재미 근거 | 관련 PD 지시# |
|------|--------|----------|----------------|----------|--------------|

**"재미 근거" 컬럼이 공란이면 수치 조정 금지**: 어떤 재미를 강화하는지 먼저 정의하지 않은 수치 조정은 P30 위반이다.

### §4-4. JSON/CSV SOT 맹신 금지 (기획팀 데이터 실측 의무 v1 §1-4)

**실증 사건**: `스테이지난이도곡선_v1.md §1`에 "WorldMap_1~4 4개 그룹"이라는 표현이 기획 문서 SOT처럼 인용·전파되어, Phase 4 지역 1 전체를 "Stage 1~6 = 지역 1 = 6개"로 설계하는 오류가 발생했다. 실제 데이터는 **21개 구역 × 각 4개 하위 스테이지 = 총 122 스테이지**였다.

**재발 방지 원칙**:
- 기획 문서의 수치·구조를 **무비판 수용 금지**
- Unity Export CSV/JSON 직접 실측 선행 의무
- 기획 문서 상단에 "데이터 소스 실측 일시" 필드 명기 필수
- 실측 일시 미기입 문서는 참조 금지 (참조 시 실측 재수행)

**수치 검증 체계**: 모든 DPS·TTK 계산은 Unity 실측 데이터 기반이어야 하며, "UTF N/N Passed" 형식으로 검증 통과 여부를 기록한다.

---

## §5. 수치 설계 원칙 — EerieVillage 이관 핵심

### §5-1. 재미 정의 없는 수치 조정 금지 (P30 실무)

수상한잡화점에서 모든 밸런스 변경 제안은 "어떤 재미를 강화하는가"를 먼저 정의했다. 대표 사례:

- **어뷰징 안전 마진 0% 기각**: 이유는 기술적 정확성이 아니라 "false positive가 정상 플레이어 경험을 훼손한다"는 재미 관점이었다.
- **이슈 1 현 수치 고정 결정**: G1 풀빌드 DPS +200~280%가 목표 +80~120% 대비 2배 초과이나, 수치 재조정보다 HP·TTK 설계가 현 DPS를 반영한 상태로 일관성을 유지하는 것이 재미 경험 보전에 유리하다고 판단.
- **Stage 10→11 내구도 +42% 급등**: 오류가 아닌 "장비 투자 동기 부여"라는 재미 의도 설계임을 TTK 수치로 확인.

### §5-2. 어뷰징 임계값과 재미의 교점

어뷰징 판정 기준을 너무 엄격하게 잡으면 실력 있는 정상 유저를 차단하게 된다. 이것은 **재미 설계 실패**다. 임계값 설계는 밸런스 기획자가 개입해야 하는 영역이다.

안전 마진 계수(0.80·1.05·1.10 등)는 "기술적으로 합당한 오차 범위"가 아니라 **"이 오차 범위 안에 있는 유저는 재미있게 플레이하고 있는 정상 유저"**라는 재미 판단이 선행된 수치다.

### §5-3. P17 배타 배치 체계의 의미

★조건 배타 7종(P17)은 단순한 기술적 제약이 아니다. 각 배타 조합이 금지된 이유는 **"그 조합이 플레이어에게 이중·삼중 부담을 주어 재미를 손상시키기 때문"**이다.

| 배타 조합 | 재미 손상 이유 |
|----------|------------|
| C2∧N2 (완벽 클리어 + 피격 제한) | 피격 최소화 부담을 두 방향에서 동시 부과 — 스트레스 빌드 |
| C6∧N4 (포션 절제 + 쉴드 하한) | 회복 빌드 외 빌드 선택지 전면 배제 — 다양성 파괴 |
| N5∧N6 (후열 선공 + 전열 선공) | 타겟팅 자유도 박탈 + 논리 모순 — 달성 불가 조건 |

EerieVillage에서 유사한 "달성 조건" 체계를 설계할 때, 각 조건 쌍의 **재미 충돌 여부**를 먼저 검토한다.

### §5-4. 드랍률·확률 설계 교훈

수상한잡화점 드래프트 확률:
- G1(일반) 66.2%, G2 19.9%, G3 9.9%, G4 3.3%, G5 0.66%

**핵심 교훈**:
- G5 물약 카드 등장 확률 = 0.66% × (G5 중 물약 비율) ≈ **~0.15%** → "나오면 기적" 수준
- 이 확률에서 "물약 빌드"는 설계 의도와 달리 사실상 형성 불가능한 빌드가 되어버림
- **빌드 형성에 필요한 핵심 카드 등장 확률**을 역산해서 "1런에 빌드 시작이 가능한 최소 확률"을 별도로 검증해야 한다
- 확률 표기는 분수·백분율 동시 기재: G5 = 10/1510 ≈ 0.66%

EerieVillage에서 "퇴마 도구" 드랍 풀 설계 시 동일한 검증이 필요하다.

---

## 변경 이력 (P16 산출물 추적성)

| 일시 | 변경자 | 변경 내역 | 재미 근거 | 관련 지시 |
|------|--------|----------|----------|---------|
| 2026-04-20 | 밸런스 기획자 (balance-designer) | 전체 신설 — NerdNavis 수상한잡화점 밸런스 시행착오 5섹션 추출 | BurningTimes EerieVillage 밸런스 설계 품질 향상 | BurningTimes 조직 전환 기점 자산 추출 |

---

*참조 원본: REQ001·REQ002 기획팀→개발팀 소통 (2026-04-14·16) / 어뷰징판정솔루션 기획서 v1 (2026-04-17) / Day11-14 밸런스축 본작업 v1 (2026-04-20) / 대화로그 수상한잡화점 2026-04-20 / 기획팀 데이터 실측 의무 v1 (2026-04-20)*