---
from: 기획팀장
to: 총괄PM
type: 검토보고
subject: Unity MCP 시뮬레이션 전환 방향 — 기획 관점 검토
priority: high
status: 검토완료
created: 2026-04-17
ref: PD님 직접 지시 (2026-04-17, Unity MCP 전환), 기획팀 PD 지시 로그 #3 (Phase 3 HOLD), 개발팀 PD 지시 로그 #28, 개발팀 RPT 2026-04-16
---

# Unity MCP 시뮬레이션 전환 — 기획 관점 검토

## 0. 요약 (결론부터)

1. **전환 방향 자체는 기획팀 관점에서 타당**. 단, "기획팀이 Unity MCP 도구를 직접 호출"하는 구조는 **비권장**. 권장 구조는 **"개발팀이 Unity MCP로 시뮬 러너·출력 규격을 구축 → 기획팀은 시드·입력 JSON을 지정하고 결과 CSV/JSON을 수령하는 CLI 혹은 MCP 래퍼 호출"**.
2. **Phase 3 HOLD 부분 재개 가능**. 개발팀 조기 산출물 3종(전투공식 SOT v2 / JSON 스키마 문서 / BattleCore 피해 계산 단독 모듈) 중 **첫 2종이 확보되면 Day 1~3 (재개 준비·Phase 0~2 재검증 1~6번)**까지 즉시 진행 가능. Day 4 이후(성장 요소 기여도 본 측정)는 시뮬 러너 실제 동작이 필요.
3. **Python 시뮬은 교차 검증용으로 유지**. 아카이브 금지. 본 검토 시점 `.cache/*.py`는 NerdNavisAi 레포 부재(개발팀 RPT §3 확인). 기획팀 로컬 PC 또는 이전 작업 디렉토리에 잔존 가능성 높음 — **재개 Day 1에 기획팀 로컬 스캔 + 레포 편입 여부 결정** 필요.
4. **리스크 최대 관심사는 반복 실행 속도·결정론**. Unity Editor 재생 기반 시뮬은 수백~수천 회 반복에 부적합할 수 있음 (C3 관점 사전 경고).

---

## 1. Phase 3에 필요한 시뮬레이션 기능 명세 (기획 요구사항)

### 1-1. 필수 시나리오 유형 3종

| 유형 | 용도 | 반복 횟수(기획 기준) |
|------|------|---------------------|
| **A. 단일 전투 노드 시뮬** | 카드 단품 기여도 측정 (#3 G1 카드 1장 DPS) | 시드 100회 × 조합 N |
| **B. 스테이지 전구간 시뮬** | 성장 요소(#16~#21) 단일 축 변화에 따른 클리어율·평균 턴수 측정 | 시드 500~1000회 × 성장 단계 |
| **C. 앵커 재검증 배치 시뮬** | Phase 0~2 재검증 6건 (#1~#6) 실측 | 시드 100회 (기존 Python 결과 대조용) |

### 1-2. 입력값 스키마 (JSON)

```
seed           : int (결정론 보장)
stage_id       : string (예: "stage_1")
deck           : [card_id × 5]  # 카드 덱 구성
growth_vars    : { awakening: int, evolution: int, equipment_set: int, ... }
max_turns      : int (무한 루프 차단 상한)
```

### 1-3. 출력값 스키마 (JSON 1줄/시뮬 + CSV 집계)

```
clear          : bool
turns          : int
final_hp_ratio : float
total_dmg      : int
total_taken    : int
potion_used    : int
```

**핵심 요구**: 시드 고정 시 **100% 동일 결과** (결정론). 개발팀 RPT §4.2 "UnityEngine.Random → 시드 기반 난수 전환 필수" 와 일치.

### 1-4. 반복 실행 요구
- Day 4~7 "성장 요소 기여도 본 측정"에서 **수백~수천 회**가 현실적 요구
- Day 2~3 재검증은 시드 100회 수준으로 충분

---

## 2. Unity MCP 환경 실행 가능성 평가 (기획 관점)

### 2-1. 기획팀 직접 호출 vs 경유 실행

| 경로 | 평가 | 사유 |
|------|------|------|
| **A. 기획팀이 `mcp__unity-mcp__*` 도구 직접 호출** | **비권장** | (1) Unity MCP 도구군은 씬·GameObject·컴포넌트 조작이 주 기능이며 배치 시뮬 러너 실행에는 `execute_code` 또는 `run_tests` 경유 필요 (2) 기획팀 에이전트(밸런스기획자·시스템기획자)가 Unity Editor API·C# 실행 컨텍스트를 직접 제어하는 것은 **학습 부담 과대**·**실수 리스크** (3) C11(개발 관점 원칙)과 C7(재미 우선 원칙)의 역할 경계 교란 |
| **B. 개발팀이 MCP로 러너·입출력 규격 구축 → 기획팀은 "시뮬 실행 요청" JSON 제출 → 결과 CSV 수령** | **권장** | (1) 기획팀은 **입력·출력 스키마만 이해**하면 됨 (2) 개발팀이 Unity MCP로 러너를 씬/에셋으로 구성하고 한 번 안정화되면 반복 사용 (3) 기획팀 UX: "조합 N을 돌려주세요" 요청 → 결과 테이블 수령. 이는 CLI 방식과 사용성 동일 |
| **C. PM·개발팀이 기획 요청 받아 실행 → 결과 전달** | 병행 가능 | Phase 3 초기·디버깅 단계에서 유용. 안정화 후 B로 전환 |

### 2-2. 학습 부담·사용성

- Unity MCP **풀 도구 학습은 불필요**. 기획팀이 알아야 할 것은 "입력 JSON 스펙 + 결과 포맷 + 실행 트리거 방법" 3가지
- CLI(dotnet)·Unity MCP 경유 모두 기획 UX는 **유사**(입력 JSON 넣고 결과 파일 받기). 단 MCP 경유는 Unity Editor 가동 상태에 의존

### 2-3. 기획팀 경로 선호
**권장 B(개발팀 러너 구축 + 기획팀 요청 경로)**. 단 러너 실행 트리거는 (a) 개발팀 세션 경유 또는 (b) 기획팀이 단일 MCP 래퍼 도구(예: `mcp__unity-mcp__execute_code` 1개)만 호출하는 방식 중 개발팀 권고에 따름.

---

## 3. 기존 Python 시뮬 자산 처리

### 3-1. 소재 확인 (본 검토 시점 실측)
- NerdNavisAi 레포 내 `battle_sim.py`·`full_stage_sim.py`·`stage_sim_v2.py` **부재 확인** (Grep 결과 0건, 개발팀 RPT §3 동일 결론)
- 추정 소재: (a) 기획팀 구 로컬 작업 PC `.cache/` (b) 이전 `기획실/` 네임 디렉토리 흔적 (2026-04-16 "개발실→개발팀" 전환 이전 경로) (c) PD님 로컬
- **Day 1 최우선 작업**: 기획팀장이 PD님께 소재 확인 요청 + 소재 파악 시 레포 `프로젝트/수상한잡화점/기획/시뮬_레거시/` 편입

### 3-2. 전환 시 처리 방침 (권장)

| 구분 | 처리 | 사유 |
|------|------|------|
| **Python 시뮬 코드 본체** | 레포 편입 후 **"레거시/교차 검증 참조"**로 유지. 아카이브·삭제 금지 | (1) Phase 3 재개 Day 1-3 Python↔Unity 교차 검증 입력값 (2) Phase 3 v1 붕괴 원인 분석 근거 (3) C6 데이터 보호 원칙 |
| **Python 시뮬로 도출한 밸런스 수치** | 모든 수치는 **Unity 시뮬 재검증 대상**. Python 결과는 참고용으로만 사용 | Phase3 재개준비 체크리스트 v1 §6-3 "이원화 리스크" 교훈 준수 — "모든 수치는 C# 시뮬 기반으로만 산출" |
| **재검증 범위** | Phase 0~2 앵커 시뮬 6건(#1~#6) + 카드 시너지 축 4건 + 성장 요소 6건 = **총 16건 우선 재검증** | Phase3_재개준비_체크리스트_v1.md §3-2 매핑 그대로 |

---

## 4. Phase 3 부분 재개 가능성 평가

### 4-1. 개발팀 조기 산출물 3종 대비 재개 가능 범위

| 개발팀 조기 산출물 (RPT §5-2) | 기획팀 재개 가능 범위 | Phase3 체크리스트 매핑 |
|-------------------------------|---------------------|----------------------|
| **(1) 전투공식 SOT v2 문서** | Day 1-2·1-4 (교차 검증 리뷰·사전 산출물 재독), Day 2~3 재검증 **"설계 레벨" 검토** 가능 (실측은 불가) | Day 1~3 일부 |
| **(2) JSON 데이터 테이블 스키마 문서** | 시뮬 입력값 정비·검증. 스테이지·몬스터·카드 데이터 구조 파악 | Day 1-3 (CLI 가이드 대체 가능) |
| **(3) BattleCore 피해 계산 단독 모듈** | **Day 2~3 재검증 앵커 시뮬 6건 중 #1·#2 (PC DPS·TTK)** 피해 계산 단위까지는 실측 가능 | Day 2-1·2-2 |

### 4-2. 재개 선행 조건 재정리

| 종전 조건 (Phase3 체크리스트 §1-1) | Unity MCP 전환 반영 후 |
|-----------------------------------|----------------------|
| #1 Headless C# 시뮬 추출 완료 | → **Unity MCP 기반 시뮬 러너 동작 확인** (씬·러너·입출력 JSON 스키마 확정) |
| #2 Python ↔ C# 교차 검증 | → **Python ↔ Unity 시뮬 교차 검증** (대상 동일) |
| #3 기획팀용 CLI 가이드 | → **기획팀용 시뮬 실행 가이드** (MCP 래퍼 호출 방식 또는 개발팀 경유 요청 포맷) |
| #4 PD님 재개 지시 | → 동일 |

### 4-3. 즉시 재개 가능 작업 (조건부)
개발팀 조기 산출물 (1)(2) 수령 시점에 Day 1 (선행 확인·사전 산출물 재독·CLI 가이드 정독 대체)·Day 2~3 일부(설계 레벨 재검증) **즉시 착수 가능**. Day 4 이후는 (3) + 반복 실행 환경 구축 완료 조건.

---

## 5. 추가 차단 요인·리스크 (C3 사전 경고)

### 5-1. 반복 실행 속도 리스크 (최대 관심사)

| 리스크 | 내용 | 완화 방안 |
|--------|------|-----------|
| **Unity Editor 기반 시뮬의 반복 속도 병목** | Unity Editor Play Mode 1회 실행 시 씬 로딩·초기화 오버헤드 발생. Day 4~7 성장 요소 측정은 시드 500~1000회 × 성장 축 5종 × 단계 10개 = 최대 **5만 회** 반복 필요 | (a) Headless 모드 러너 권장(에디터 UI 없이 C# 도메인 코드만 실행) (b) **단일 Play Mode 세션 내에서 배치 루프 처리** (씬 로드 1회·내부 반복 N회) (c) 결과 비동기 JSON 라인 출력 |
| **대안**: `run_tests` 기반 배치 | Unity Test Framework의 배치 러너로 수십~수백 회 반복은 현실적. 수천 회는 미지수 | Day 4 착수 전 **개발팀이 시뮬 1000회 런타임 벤치마크** 수행 후 기획팀 공유 |

### 5-2. 결정론 보장 요구
- 기획팀 Phase 3 측정은 **시드 고정 시 재현성 100%** 필수
- 개발팀 RPT §4.2 `UnityEngine.Random → 시드 기반` 이미 식별됨. **기획팀 요구사항과 일치 확인**
- 추가 요구: Coroutine·Time.deltaTime 기반 타이밍 요소도 **틱 기반**으로 환원 필수 (RPT §2.2 "Coroutine → 턴/틱 기반 루프로 전환" 이미 식별됨)

### 5-3. 카드 효과 200종 커버리지

- 개발팀 RPT §4.1 "카드 효과 200종 전수 대응 난이도 **상**"
- **기획 관점 권장**: Phase 3 재개 범위의 **카드 빌드에 실제 사용되는 카드 효과 우선 구현**. 전수 200종이 아닌 **#3~#5 G1 카드 중심 + #16~#21 성장 요소 관련 효과**로 한정
- 전수 커버리지는 Phase 3 종료 후 점진적 보완 트랙으로 분리

### 5-4. 기타 우려

| 우려 | 내용 |
|------|------|
| **Unity 버전·에셋 변경 시 회귀 리스크** | 개발팀 Unity 버전·패키지 업데이트 시 시뮬 결과 회귀 가능성. 기획팀이 수치를 받았는데 환경 차이로 재현 불가 | 시뮬 러너에 **Unity 버전·커밋 해시 기록** 의무화 |
| **조직 레포 ↔ Unity 프로젝트 레포 분리 상태** | Unity 프로젝트는 `${UNITY_PROJECT_ROOT}` 별도 관리(C30). 시뮬 러너 코드·입출력 JSON 저장 위치를 명확히 해야 재현 가능 | **입력 JSON은 조직 레포, 러너 코드는 Unity 레포, 결과물은 조직 레포 재반영** 권장 |
| **C30 준수** | Unity 프로젝트 건드리는 모든 제안은 **작업 착수 전 git 최신 상태 점검** 의무. 본 검토는 제안 단계이므로 Unity 레포 직접 수정 없음 | 실제 러너 구축 착수 시 개발팀이 C30 수행 |

---

## 6. 기획팀 권장 재개 순서 (개발팀 협의 전제)

| 순서 | 작업 | 선행 조건 |
|------|------|-----------|
| 1 | Python 시뮬 소재 확인 + 레포 편입 결정 | 기획팀장 단독 수행 가능 |
| 2 | 개발팀 조기 산출물 (1)·(2) 수령 | 개발팀 작업 완료 |
| 3 | Day 1-2·1-4 (교차 검증 리뷰·사전 산출물 재독) | 2 완료 시 |
| 4 | Day 2~3 재검증 6건 중 설계 레벨 가능 항목 선 수행 | 3 완료 시 |
| 5 | 조기 산출물 (3) + Unity 러너 1000회 벤치 수령 | 개발팀 작업 완료 |
| 6 | Day 2~3 실측 재검증 완료 + Day 4 착수 여부 결정 | 5 완료 + PD님 재개 지시 |
| 7 | Day 4~7 성장 요소 기여도 본 측정 | 6 완료 + 반복 속도 요구 충족 확인 |

---

## 7. 본 검토의 한계 및 후속

### 7-1. 본 검토가 전제한 것
- 개발팀 RPT 2026-04-16 §1~§7 내용 (특히 Phase A 부분 완료·조기 산출물 3종 가능성)
- Phase3_재개준비_체크리스트_v1 Day 1~15+ 로드맵
- Unity MCP 도구군은 본 기획팀장이 직접 사용하지 않았음 — 사용성 판단은 **도구 목록·역할 기반 추정**. 실제 사용성은 개발팀 기술 검토 결과와 교차 확인 필요 (C5 미확인 태그)

### 7-2. 개발팀 병렬 검토와의 접점
- 개발팀장이 병렬로 진행 중인 "Unity Editor 내 시뮬레이션 동작 방안·권장 아키텍처" 검토와 §2-1 경로·§5-1 반복 속도·§5-2 결정론 항목에서 교차 검증 필요
- PM이 양 검토 취합 시 §6 권장 순서를 기준 골격으로 사용 권고

### 7-3. 본 검토의 결정 재량 범위 (P23)
- 기획팀장 재량: §1 기능 명세, §3 Python 자산 처리 방침, §4 부분 재개 가능 범위 판단
- PM 확인 필요: §2-1 권장 경로 B의 개발팀 측 수용 여부, §5-1 벤치마크 요청
- PD님 확인 필요: Phase 3 재개 트리거 조건 재정의 (§4-2), 재개 시점 지시

---

## 8. 변경 이력

| 일자 | 작성자 | 내용 |
|------|--------|------|
| 2026-04-17 | 기획팀장 | Unity MCP 전환 관련 기획 검토 초안 |
