BurningTimesAi/공유/소통/기획팀→개발팀/REQ초안_3성조건_12개_판정로직.md

---
요청번호: REQ-초안 (발행 시 REQ-XXX 부여)
요청일: 2026-04-20 (초안 작성일 — 정식 발행은 개발팀 조건 2·3 완결 후 조율)
요청부서: 기획팀
수신부서: 개발팀 (클라이언트팀)
담당에이전트: 시스템기획자·밸런스기획자 (기획) / 클라이언트팀장 (개발)
우선순위: MID (Phase 3 재개 Day 1-4 후속 — Day 2~3 병행 가능)
상태: 초안 (미발행)
유형: 밸런스수치_요구서 (조건 판정 로직 구현 요청)
관련PD지시: 기획팀 #3 (Phase 3 재개 Day 1-4)
---

# REQ 초안 — ★ 조건 12개 판정 로직 Unity MCP EditMode 구현 요청

> **본 문서는 초안**. 정식 발행은 개발팀 재개 선행 조건 2(실측 검증 리포트)·3(실행 가이드) 완결 후 기획팀장·개발팀장 조율하여 `YYYY-MM-DD_REQ-XXX_3성조건_판정로직.md` 로 확정 발행.

---

## 1. 요구서 식별

| 필드 | 값 |
|------|-----|
| **요구서 ID** | REQ-초안 (정식 발행 시 부여) |
| **기준 버전** | `3성조건_12개_상세명세_v1.md` (2026-04-18 최신화) |
| **기준 커밋** | main (정식 발행 시점 SHA 기록) |
| **작성자** | 기획팀장 (Phase 3 재개 Day 1 사전 준비) |

---

## 2. 변경 필드 목록

개발팀 `Assets/Sim/BurningTimes.Sim.asmdef` 어셈블리 내 **신규 구현** 요청.

| # | 파일·테이블 | 필드 경로 | 변경 유형 |
|---|------------|---------|---------|
| 1 | `Assets/Sim/Conditions/` (신규) | ConditionEvaluator 인터페이스 + 12개 구체 구현 | 신규 |
| 2 | `Assets/Sim/Conditions/ConditionMetricsTracker.cs` (신규) | 런타임 측정 변수 집계기 | 신규 |
| 3 | `시뮬레이터/03_결과_JSON_포맷_v1.md` 결과 스키마 | `conditions_result` 필드 추가 (조건별 달성 여부) | 확장 |

---

## 3. 구현 요청 범위

### 3-1. 조건 12개 판정 로직 (`3성조건_12개_상세명세_v1.md §3·§4` 준수)

| ID | 명칭 | 측정 변수 | 판정식 |
|----|------|---------|-------|
| C1 | 신속 | 스테이지 총 소요 시간 | `total_duration_sec ≤ threshold[stage_id]` |
| C2 | 완벽 클리어 | PC HP (클리어 시점) | `pc_hp_at_clear == pc_max_hp` |
| C3 | 고 HP 완주 | PC HP (클리어 시점) | `pc_hp_at_clear ≥ pc_max_hp × 0.70` |
| C6 | 포션 절제 | 포션 사용 횟수 | `potion_uses ≤ threshold[stage_id]` |
| C9 | 보스 집중 | 보스에게 가한 누적 데미지 / 전체 누적 데미지 | `boss_dmg_ratio ≥ threshold` |
| C12 | (명세서 §3 참조) | (명세서) | (명세서) |
| N1 | (명세서 §4 참조) | 서브맵 단위 측정 | (명세서) |
| N2 | 피격 제한 | 누적 피격 횟수 | `hits_taken ≤ sub_map_count × 1` |
| N3 | 치명타 처치 | 치명타로 처치한 몬스터 수 | `crit_kills ≥ 3` |
| N4 | 쉴드 하한 | 클리어 시점 Shield | `shield_at_clear ≥ pc_max_shield × 0.30` |
| N5 | 후열 선공 | 타겟팅 우선순위 검증 | `first_kill_target == rear_row` |
| N6 | 전열 선공 | 타겟팅 우선순위 검증 | `first_kill_target == front_row` |

**정확한 판정식·엣지 케이스는 `3성조건_12개_상세명세_v1.md §3·§4` 본문을 정(正)**으로 한다. 본 REQ는 구현 범위 합의용 요약.

### 3-2. 런타임 측정 변수 Tracker

스테이지 진행 중 매 턴/이벤트에 측정 변수 누적. 스테이지 종료 시 ConditionEvaluator가 해당 스테이지의 슬롯2·슬롯3 조건 2개만 평가 (Prove-2-of-3).

### 3-3. 결과 JSON 스키마 확장

`03_결과_JSON_포맷_v1.md` 의 `result` 오브젝트에 `conditions_result` 필드 추가:

```json
"conditions_result": {
  "slot2_id": "C1",
  "slot2_passed": true,
  "slot2_metric": {"total_duration_sec": 22.4, "threshold": 25.0},
  "slot3_id": "N2",
  "slot3_passed": false,
  "slot3_metric": {"hits_taken": 5, "limit": 4}
}
```

---

## 4. 재미 근거 (P30 재미 우선 원칙)

- **강화하려는 재미 축**: "재도전 유도 유기성" (Phase 2 §5 PD님 3차 승인 조건 설계 원칙 2)
- **변경 전 재미 문제점**: Prove-2-of-3 체계는 설계 완료되었으나 **판정 로직이 Unity MCP EditMode에 구현되지 않아 시뮬 단위 검증 불가**. Phase 3 성장 요소 기여도 측정과 별개로, 3성 조건 달성률을 스테이지·빌드별로 측정할 수단 부재
- **변경 후 기대 경험**: 유저가 각 스테이지 슬롯2·슬롯3 조건을 인지하고 의도적으로 재도전할 때의 **달성률 분포를 시뮬에서 실측**. 입문 구간 슬롯 배치의 "재도전 유도 강도" 정량 검증
- **측정 지표**: 스테이지별 ★3 달성률, 슬롯별 조건 달성률, 슬롯2·슬롯3 동시 달성률

---

## 5. 개발 관점 우려 예상 (C11 존중)

| 관점 | 예상 우려 | 기획팀 입장 |
|------|----------|-------------|
| **자원 효율성** | 매 턴 측정 변수 갱신 오버헤드 | 누적 변수만 갱신·프레임 단위 재계산 불요. 클리어 시점 1회 평가 |
| **코드 직관성** | 조건 12종 분기 복잡도 | 인터페이스 `IConditionEvaluator` + 클래스 12개로 분리. 각 클래스 단일 책임 |
| **범용성** | 차기 프로젝트 재활용 | `Assets/Sim/Conditions/` 구조는 수상한잡화점 특수. 범용화는 `BT.Framework` Tier 2 검토 (P29-3 인사이트 축적) |

---

## 6. 검증 방법

- **검증 채널**: Unity MCP EditMode 단위 테스트 (`3성조건_12개_상세명세_v1.md §6-1` 테스트 매트릭스 준수)
- **검증 케이스**:
  1. 조건별 경계값 테스트 (예: C3 HP=MaxHP×0.70 정확히 경계 → pass, 0.69999 → fail)
  2. 슬롯2·슬롯3 동시 달성 시나리오 → ★3 반환
  3. 슬롯2만 달성 → ★2, 슬롯 둘 다 실패 → ★1
  4. P17 배타 조합 7종 케이스를 매니페스트에 등록 → 판정 로직에 도달하지 않음 (상위 필터)
- **통과 기준**: `3성조건_12개_상세명세_v1.md §6-1` 단위 테스트 매트릭스 전수 통과
- **회귀 검증**: 기존 전투 시뮬 결과 (Phase 0~2 앵커)에 conditions_result 추가되어도 기존 result 필드 값 불변

---

## 7. 백업·이력 (C6·P16)

- **백업**: 신규 구현이므로 백업 대상 없음
- **변경 이력**: `3성조건_12개_상세명세_v1.md §8` 변경 이력 테이블에 REQ-XXX 발행 일시 append
- **관련 대화로그**: `공유/대화로그/수상한잡화점/YYYY-MM-DD.md`

---

## 8. 기각안 (P24 · C32 계승)

| # | 기각 대안 | 기각 사유 |
|---|---------|---------|
| 1 | 조건 판정을 Unity 실 빌드 PlayMode에만 구현 | 결정론적 시뮬 불가 → Phase 3 재검증 시 ±10% 오차 판정 불가능 |
| 2 | 조건 판정을 Python 시뮬에 구현 | PD님 지시로 단일축 SOT = Unity MCP EditMode. 이원화 금지 |
| 3 | 조건 12종을 하나의 거대 함수로 구현 | C11 개발 관점 (코드 직관성·범용성) 위배. 확장 시 분기 폭발 |

---

## 9. 응답 섹션 (개발팀 작성)

### 9-1. 개발 관점 검토 결과
(정식 발행 후 개발팀이 기재)

### 9-2. 변경 적용 결과
(구현 완료 시 개발팀이 기재)

### 9-3. 후속 필요 작업
(해당 시 개발팀이 기재)

---

## 10. 발행 선행 조건

본 초안은 다음 2종 완결 후 정식 REQ로 전환:
1. 개발팀 재개 선행 조건 2 (Unity MCP EditMode 실측 검증 리포트 완료)
2. 개발팀 재개 선행 조건 3 (기획팀용 Unity MCP 시뮬 실행 가이드 완료)

완결 시점에 기획팀장이 기획팀→개발팀 채널로 `YYYY-MM-DD_REQ-XXX_3성조건_판정로직.md` 로 정식 발행.

---

## 변경 이력

| 일시 | 변경자 | 변경 내역 |
|------|--------|----------|
| 2026-04-20 | 기획팀장 | 초안 작성 (Phase 3 재개 Day 1 사전 준비, 발행 대기) |