BurningTimesAi/공유/조직자산/시행착오_아카이브/기획_balance_designer_v1.md

# 밸런스 기획 시행착오 아카이브 v1

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

---

## §1. 데이터 파싱 검증 원칙

### §1-1. 문자열 포맷 ≠ 런타임 의미 (퍼센트값 오해 실증)

**교훈**: 수치 테이블의 `%` 등 포맷 기호가 런타임 파싱 로직에 따라 **전혀 다른 결과**를 낼 수 있다. 동일 컬럼에 복수 포맷이 혼재하면 오해 위험이 급증한다.

**실증**: 기획팀이 `s_Value='500%'`를 "500% 배율 적용"으로 해석하여 DPS 수치를 수배 과산출. 실제 파싱은 `float × 0.01f` 고정값 변환이었음.

**차기 프로젝트 원칙**:
- 밸런스 시트 작성 전 **파싱 함수 코드를 개발팀과 공유·확인** 필수
- 테이블 컬럼 헤더에 "런타임 해석 방식" 주석 요청
- DPS·EHP 산출 전 소규모 실측 검증(입력값 → 실제 전투 결과) 선행

### §1-2. 음수값 = 오류 아님 — 디버프·방향성 역전 명세 의무

**교훈**: 장비·스킬 옵션의 음수값이 "오류"인지 "의도된 트레이드오프 페널티"인지 설계 문서에 명시해야 한다. **방향성이 역전되는 스탯**(쿨타임·캐스팅타임 등 감소 = DPS 증가)은 별도 명세표 필수.

**차기 프로젝트 원칙**:
- 음수값 허용 스탯 목록 + 방향성 정의표를 밸런스 설계 착수 전 작성
- DPS/EHP 계산 시 방향성 역전 스탯을 반영하지 않으면 수치 왜곡 발생

### §1-3. JSON/CSV SOT 맹신 금지 — Unity 실측 선행

**실증**: 기획 문서에 "WorldMap 4개 그룹" 표현이 SOT처럼 인용·전파되어 스테이지 구조 전체를 잘못 설계. 실제 데이터는 기획 문서와 다른 규모였음.

**차기 프로젝트 원칙**:
- Unity Export CSV/JSON 직접 실측 선행 의무
- 기획 문서 상단에 **"데이터 소스 실측 일시" 필드 명기** 필수
- 실측 일시 미기입 문서는 참조 금지 (참조 시 실측 재수행)
- 모든 DPS·TTK 계산은 `UTF N/N Passed` 형식으로 검증 통과 여부 기록

---

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

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

어뷰징 판정의 목표는 **"정직한 플레이어의 재미 보호"**다. 이 전제가 모든 임계값 수치를 결정한다.
- **false positive 최소화**: 정상 유저 오판정 = 성취 경험 훼손 = P30 위반
- **안전 마진 존재 이유**: 프레임 드랍·클라 시계 오차·반올림 오차 등 기술적 노이즈가 정상 유저를 "경계 초과"로 만드는 구조 차단

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

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

시뮬 이론 극값 = 10,000회 이상 반복 시뮬레이션 상위/하위 0.1% 값 (절대 최대/최소 불채택 — 시뮬 자체 오차 흡수)

| 벡터 특성 | 마진 방향 | 계수 | 근거 |
|---------|--------|-----|------|
| 클리어타임 (짧을수록 의심) | 하한 = 이론 최단 × 0.80 | 0.80 | 클라 시계 오차 흡수 |
| 획득 재화 (많을수록 의심) | 상한 = 이론 최대 × 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. 달성 조건 위조 차단 (★조건 서버 교차 검증)

서버 검증에 기획팀 정의 ★조건을 포함시켜야 어뷰저의 ★조건 위조를 차단한다. ★조건 통과 보고와 실제 필드값이 모순되면 F3 확정(논리 모순 범주).

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

---

## §3. TTK 기반 난이도 곡선 설계 원칙

### §3-1. 재미 정의 → TTK 목표 → 수치 설계 순서

**재미 정의 선행**: "이 구간에서 플레이어가 어떤 경험을 해야 하는가"를 먼저 확정하고, 그 경험에서 역산하여 TTK 목표를 도출한다. 수치를 먼저 잡고 재미를 끼워맞추는 방향은 금지.

**앵커 포인트 접근법**: 전체 수치를 동시에 잡지 않고 **기준점 1개(앵커 DPS·TTK)를 실측으로 먼저 고정**한 뒤, 각 성장 요소의 기여도를 순차 측정한다.

```
TTK = (HP + Shield 합산) / DPS_결합
```

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

### §3-2. 성장 요소 기여도 표 구조 (EerieVillage 설계 참조)

각 성장 단계(기본 → 일반 장비 → 세트 → 추가 성장)가 TTK를 어떻게 변화시키는지 표로 구성하여 "각 성장 요소가 클리어 경험을 어떻게 바꾸는가"를 수치로 직접 보여준다. 이 구조 자체가 재미 설계의 수치 번역 도구다.

### §3-3. 고내구도 보스 의도 구분

내구도 급등 구간이 오류인지 의도 설계인지는 TTK 수치로 판정한다. 세트·추가 성장 결합 후에도 TTK가 목표 상한을 크게 초과하면 "추가 성장 요소 투자 동기 부여" 의도 여부를 설계 문서에 명기해야 한다.

---

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

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

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

```
{원본명}.bak_{YYYYMMDD_HHMM}.{확장자}
예: balance_table.bak_20260501_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 위반.

---

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

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

모든 밸런스 변경 제안은 "어떤 재미를 강화하는가"를 먼저 정의한다. 대표 원칙:

- **어뷰징 안전 마진**: 기술적 오차 범위가 아니라 "이 범위 안은 재미있게 플레이하는 정상 유저"라는 재미 판단이 선행된 수치
- **내구도 급등 구간**: 오류 여부 판단 전에 "장비 투자 동기 부여" 등 재미 의도 설계인지 먼저 확인
- **수치 재조정 vs 현 수치 수용**: 일관성 있는 재미 경험 보전이 목표 범위 이탈보다 우선될 수 있음

### §5-2. 달성 조건 배타 설계 — 재미 충돌 우선 검토

달성 조건 배타 체계(P17 ★조건 배타 7종)는 기술 제약이 아니라 **이중·삼중 부담이 재미를 손상시키기 때문**에 금지된다.

| 배타 패턴 | 재미 손상 이유 |
|----------|------------|
| 피격 최소화 × 피격 최소화 이중 조건 | 동일 축 이중 부담 — 스트레스 빌드 |
| 회복 억제 + 회복 강제 | 회복 빌드 외 선택지 전면 배제 — 다양성 파괴 |
| 논리 모순 조건 쌍 | 달성 불가 조건 — 플레이어 이탈 |

**차기 프로젝트 원칙**: 유사한 "달성 조건" 체계 설계 시, 각 조건 쌍의 **재미 충돌 여부**를 먼저 검토한다. 배타 목록은 조건 풀 확정 후 프로젝트별 재정의한다.

### §5-3. 빌드 형성 확률 역산 의무

드랍 풀 설계 시 단순 확률 수치만으로는 빌드 형성 가능성을 알 수 없다. **빌드 형성에 필요한 핵심 아이템 등장 확률을 역산**하여 "1런에 빌드 시작이 가능한 최소 확률"을 별도 검증한다.

- 확률 표기: 분수·백분율 동시 기재 (예: 10/1510 ≈ 0.66%)
- 역산 결과 "나오면 기적" 수준이면 해당 빌드는 사실상 형성 불가능 → 드랍 풀 재설계 필요
- **EerieVillage 퇴마 도구 드랍 풀** 설계 시 동일 검증 적용

---

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

| 일시 | 변경자 | 변경 내역 | 재미 근거 | 관련 지시 |
|------|--------|----------|----------|---------|
| 2026-04-20 | 밸런스 기획자 (balance-designer) | 전체 신설 — 수상한잡화점 밸런스 시행착오 5섹션 추출 | BurningTimes EerieVillage 밸런스 설계 품질 향상 | BurningTimes 조직 전환 기점 자산 추출 |
| 2026-04-20 | 밸런스 기획자 (balance-designer) | Phase 2-B 재압축 — 이전 프로젝트 구체 수치·스탯명 제거, 방법론·원칙 중심 재작성 | BT·EerieVillage 활용 가치 기준 정제 | PD님 결정 5번 집행 |

---

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