# 수상한 잡화점 — 개발자 관점 점검

> **작성일**: 2026-04-14
> **목적**: 기획실 인수 내용에 대해 개발자 관점(C11)에서 보완/추가 확인이 필요한 사항 도출
> **판단 기준**: 자원 효율성 / 코드 구조 직관성 / 코드 범용성

---

## 📌 발견 요약

기획실은 **게임 수치·밸런싱 관점**에서 프로젝트를 완전히 파악했으나, **코드·아키텍처 관점의 공백**이 존재한다. 개발실이 추가로 확인·보완해야 할 항목은 아래 12개다.

우선순위: 🔴 즉시 필요 / 🟡 Phase 3 착수 전 / 🟢 상시 점검

---

## 1. 시뮬레이터 이원화 문제 🔴 → 🟡 해소 착수

> **업데이트 (2026-04-14)**: PD님 지시로 기획실 Phase 3 HOLD 되었으며, 본 이슈 해소를 최우선 작업으로 착수. 상세 계획: `07_시뮬레이터_이원화_해소_착수계획_v1.md`

### 현황
- 기획실은 Python으로 3개 시뮬레이터 구현 (`battle_sim.py`, `full_stage_sim.py`, `stage_sim_v2.py`)
- Unity에는 C#으로 실제 전투 로직이 구현되어 있을 것으로 추정 (미확인)
- **Python 시뮬과 Unity C# 구현이 별개로 존재** → 이원화 리스크

### 개발자 관점 문제
- **[자원 효율성]** 동일 로직을 두 언어로 유지 = 유지비 2배, 괴리 발생 시 밸런싱 신뢰도 붕괴
- **[코드 직관성]** 기획이 시뮬 수정 → 개발이 Unity 수정 → 재시뮬 검증 → 괴리 발견의 무한 루프 위험
- **[범용성]** 다른 프로젝트에도 이 문제 반복 발생

### 권장 조치
- **Option A**: Unity 전투 코드를 Headless로 추출 → CLI에서 `dotnet` 실행 → 시뮬레이터를 C#으로 일원화
- **Option B**: Python 시뮬을 "참조 구현"으로 두고 Unity와 자동 동기화 검증 테스트 작성
- **담당**: `/게임플레이` + `/qa` 합동

---

## 2. 데이터 테이블 로딩·캐싱 구조 🟡

### 확인 필요 항목
- 76개 JSON을 **언제·어디서 로드**하는가? (앱 시작 / 씬 진입 / 필요 시)
- **Addressable** 사용 중인가, `Resources.Load`인가, `StreamingAssets`인가?
- 메모리 상주 크기 총합은?
- **핫 리로드**(기획 수치 변경 시 재빌드 없이 반영) 가능한가?

### 개발자 관점 문제
- **[자원 효율성]** 76개 전부 메모리 상주 시 저사양 기기 이슈 가능
- **[코드 직관성]** 테이블 조회 API가 일관된 패턴인가 (`TableManager.Get<CardData>(id)` 같은 통일 인터페이스)
- **[범용성]** 이 로딩 시스템이 `NerdNavisCore`에 있는가, 프로젝트 코드에 있는가? → 후자라면 범용화 필요

### 담당
- `/클라이언트팀장` (구조 파악)
- `/최적화` (메모리 측정)

---

## 3. 카드 효과 311장 구현 방식 🔴

### 확인 필요 항목
- 311장이 **데이터 드리븐** (효과 타입 enum + 파라미터)인가, 카드별 개별 스크립트인가?
- `e_CardType`이 **enum인지 string key인지**
- **시너지 계산**(처치 시 경험치 추가 × 경험치 비례 데미지 보너스 같은 상호작용)이 어떻게 구현되어 있는가?
- 신규 카드 추가 시 **코드 수정 필요 여부**

### 개발자 관점 문제
- **[코드 직관성]** 카드별 스크립트 311개는 유지보수 불가능 수준 → 데이터 드리븐 강제
- **[범용성]** 카드 효과 시스템이 **다음 덱빌딩 프로젝트에 재활용 가능한 범용 모듈**이 되어야 함
- **[자원 효율성]** 시너지 체크를 매 프레임 계산하면 GC·CPU 오버헤드 → 이벤트 기반 구조 필요

### 핵심 판단 질의
> **"신규 카드 추가가 JSON 한 줄 수정으로 끝나는가?"**
> 이 질문의 답이 "아니오"면 아키텍처 리팩토링 대상

### 담당
- `/게임플레이` (구현 방식 파악)
- `/클라이언트팀장` (범용성 리뷰)

---

## 4. 터치 방어 / 회피 메커닉의 SOT 불일치 🔴

### 현황
- 기획문서: "다음 공격 1회 피해 50% 감소" — **쿨다운 미확인**
- Python 시뮬: 단순 50% 감소로 구현
- Unity 실제 코드: 미확인

### 개발자 관점 문제
- **[코드 직관성]** 기획-시뮬-실코드 3자가 다른 동작 → 버그의 온상
- **메커닉 SOT는 "실제 Unity 코드"여야 함** — 기획·시뮬은 이를 참조해야 함

### 권장 조치
1. `/게임플레이`가 실제 Unity 구현을 읽고 정확한 동작 문서화
2. 해당 문서를 기획실에 전달 (`공유/개발실→기획실/`)
3. Python 시뮬을 실제 동작에 맞춰 동기화

---

## 5. 결정론 / 재현성 (시뮬레이터 신뢰도) 🟡

### 확인 필요 항목
- 전투 로직에 **랜덤**(회피, 치명타, 드롭) 사용
- 시뮬이 **동일 시드**로 동일 결과를 내는가?
- Unity 실제 게임도 **재현 가능한 시드 시스템**이 있는가?

### 개발자 관점 문제
- **[코드 직관성]** 재현 불가능한 버그는 디버깅 지옥
- **[QA 자동화]** 시드 기반 리플레이 없으면 회귀 테스트 자동화 불가

### 담당
- `/게임플레이` + `/qa`

---

## 6. NerdNavisCore 범용 라이브러리 내용 파악 🟡

### 확인 필요 항목
- `NerdNavisCore.Runtime.csproj`, `NerdNavisCore.Editor.csproj` 존재 확인됨
- **이 코어에 무엇이 들어있는가?** (UI 프레임워크, 데이터 테이블, 네트워크, 세이브 시스템 등)
- 수상한 잡화점 코드와 **명확히 분리**되어 있는가?

### 개발자 관점 문제
- **[범용성]** 코어가 명확히 분리되면 다음 프로젝트에서 그대로 재활용 가능 → 개발 가속
- **[코드 직관성]** 코어에 프로젝트 특수 로직이 섞이면 코어 오염

### 판단 포인트
> **"이번에 만드는 덱빌딩 시스템의 어느 레벨까지가 코어(다음 프로젝트 재활용)이고, 어느 레벨부터가 프로젝트 전용인가?"**

### 담당
- `/개발실장` (경계 설계)
- `/클라이언트팀장` + `/서버팀장` (현황 조사)

---

## 7. PlayFab / Firebase 서버 연동 범위 🟡

### 확인 필요 항목
- `PlayFab.csproj` 존재 — **어디까지 PlayFab이 처리**하는가? (인증, 클라우드스크립트, 리더보드, 경제, 결제)
- Firebase 용도 (Analytics? Crashlytics? Remote Config?)
- **서버 권위**로 처리되는 로직 vs **클라이언트 권위** 로직 경계

### 개발자 관점 문제
- **[치트 방지]** 인게임 결과가 클라 계산이면 해킹 가능 → 서버 권위 필요 영역 식별
- **[자원 효율성]** 모든 액션을 서버로 보내면 통신 폭증 → 배치 전략 필요
- **[범용성]** PlayFab/Firebase 의존도가 지나치면 서비스 이전 시 락인

### 담당
- `/서버팀장` (아키텍처 파악)
- `/백엔드` (연동 포인트 파악)

---

## 8. 저장 데이터 / 세이브 구조 🟡

### 확인 필요 항목
- 런 진행 상태 저장 방식 (인게임 도중 저장/복구 되는가?)
- 아웃게임 성장 데이터 저장 위치 (로컬 PlayerPrefs? PlayFab 서버?)
- **치트 방지**를 위한 암호화 / 서명 여부
- 데이터 마이그레이션 전략 (구버전 세이브 → 신버전 호환)

### 담당
- `/서버팀장` (세이브 전략)
- `/db` (데이터 구조)

---

## 9. 모바일 성능 예산 미설정 🟢

### 현황
- 기획은 "노드 클리어 ≤30초" 같은 **게임 템포 예산**만 정의
- **기술 예산**(프레임레이트 목표, 메모리 상한, 드로우콜 한계, 빌드 사이즈 상한) 미정의

### 개발자 관점 문제
- **[자원 효율성]** 예산 없으면 최적화 기준 없음 → "일단 만들고 나중에 최적화" 안티패턴

### 권장
- `/최적화`가 타겟 디바이스별 성능 예산 수립
- 예: 저사양(Galaxy S10): 30fps / 중사양(S22): 60fps / 메모리 1.5GB 상한 / 드로우콜 100 이하

### 담당
- `/최적화` + `/개발실장`

---

## 10. 데이터 테이블 무결성 검증 자동화 🟢

### 현황
- 기획실 G-5에 "FK 무결성 검증, 스탯 범위 이상 탐지" 요청 언급됨
- 76개 테이블 간 참조 무결성(MonsterID, CardID, RewardID 등) 검증 도구 필요

### 개발자 관점 판단
- **[코드 범용성]** 이 검증 시스템은 **모든 프로젝트 공통 필요 기능** → `NerdNavisCore`에 범용 툴로 넣을 것
- **[자원 효율성]** CI/CD에 자동 연결되면 기획 데이터 실수 조기 차단

### 담당
- `/qa` (검증 규칙 정의)
- `/devops` (CI 연동)
- 범용화 판단: `/클라이언트팀장`

---

## 11. VFX / 이펙트 범용성 🟢

### 확인 필요 항목
- 신성 / 번개 / 치명타 / 시체 폭발 등 카드 효과별 VFX가 **카드 효과 시스템과 결합**되어 있는가, **파라미터로 분리**되어 있는가?
- 새 카드 추가 시 VFX 새로 만들어야 하는가, 기존 VFX를 파라미터로 커스터마이즈 가능한가?

### 개발자 관점 문제
- **[범용성]** VFX가 파라미터화되면 다음 프로젝트 재활용 + 신규 카드 생산성 증대
- **[자원 효율성]** 중복 VFX가 텍스처·메모리 낭비

### 담당
- `/테크아트`

---

## 12. 빌드 파이프라인 / CI 현황 🟢

### 확인 필요 항목
- Unity Cloud Build / Jenkins / GitHub Actions 중 어떤 CI 사용 중?
- Android/iOS 빌드 자동화 수준
- 데이터 테이블 빌드 자동화 (xlsx → JSON 변환 자동화 여부)
- 테스트 빌드 배포 경로 (TestFlight, Internal Testing 등)

### 담당
- `/devops`

---

## 📋 개발실 Phase 0 작업 제안 (선행 숙지)

기획실의 Phase 3 작업(성장 요소 기여도)이 시작되기 **전에** 개발실이 완료해야 할 숙지 작업:

### Phase 0-A: 코드 전반 매핑 (3 영역 병렬)

| 작업 | 담당 | 산출물 |
|------|------|--------|
| Unity 프로젝트 구조 · 어셈블리 의존성 파악 | `/클라이언트팀장` | `03_Unity프로젝트_구조.md` |
| NerdNavisCore vs 프로젝트 코드 경계 파악 | `/개발실장` | `04_코어_범용성_분석.md` |
| 서버 연동 포인트 (PlayFab·Firebase) 파악 | `/서버팀장` | `05_서버연동_현황.md` |

### Phase 0-B: 핵심 로직 검증 (🔴 우선순위)

| 작업 | 담당 | 산출물 |
|------|------|--------|
| 전투 시스템 코드 리뷰 + 터치방어·회피 SOT 확정 | `/게임플레이` | `06_전투시스템_SOT.md` |
| 카드 효과 311장 구현 방식 파악 | `/게임플레이` | `07_카드시스템_아키텍처.md` |
| 데이터 테이블 로딩·캐싱 구조 파악 | `/클라이언트팀장` | `08_데이터로딩_구조.md` |

### Phase 0-C: 기획 요청 사전 대응

| 작업 | 담당 | 산출물 |
|------|------|--------|
| 기획실 Q-P1/P2/P3 질문에 대한 답변 준비 | `/게임플레이` | `공유/개발실→기획실/` 응답서 |
| 시뮬레이터 일원화 방안 수립 | `/게임플레이` + `/qa` | `09_시뮬레이터_전략.md` |

---

## 📚 교훈 기록 (개발실 로컬)

> **작성 시점**: 2026-04-14 (PD님 지시로 P18 신설과 연계)

### L-1. 설계 문서 누락 재발 방지
- **발생 사실**: 본 문서에서 `06_신규코어_설계안_v1.md`를 참조하였으나 실제 파일이 부재한 상태로 존재 (`05_서버연동_현황_v1.md`도 동일 참조 보유)
- **원인**: 설계 결정사항(기존 NerdNavisCore 소유권 전환 → 신규 코어 제작 결정)을 **참조 표기만 하고 본문 작성 누락**
- **재발 방지 조치**:
  1. 공통 규칙 **P18 (설계 문서화 의무)** 신설됨 — 참조된 설계 문서는 반드시 실제 존재
  2. 문서 간 참조 링크가 추가될 때 **해당 파일의 존재 여부를 즉시 확인**하는 습관 정착
  3. 설계 결정사항은 회의록·구두·요약이 아닌 **전용 설계 문서**로 반드시 명문화
  4. **팀장급**은 자기 팀 산출물의 교차 참조 무결성을 주기적으로 점검
- **연관**: `06_신규코어_설계안_v1.md` (본 교훈을 계기로 작성됨), 공통 규칙 §교훈 [2026-04-14] 항목

### L-2. 시뮬레이터 이원화 해소 착수 (Phase 3 HOLD 해제 조건)
- **발생 맥락**: 본 문서 §1에서 지적한 Python·C# 이원화 상태가 기획실 Phase 3 (성장 요소 기여도 설정) 착수를 막는 블로커로 승격
- **조치**: `07_시뮬레이터_이원화_해소_착수계획_v1.md` 작성하여 Unity C# 로직 Headless 추출 방향으로 일원화 추진
- **교훈**: **이원화는 초기에 차단해야 한다** — 누적되면 밸런싱 신뢰도 붕괴 + 유지비 2배 + 불일치 조용히 축적. C11 관점에서 "동일 로직 이중 유지"는 자원 효율성·직관성·범용성 모두 위배

---

## 💡 개발자 관점에서의 최종 판단

기획실이 제공한 정보는 **수치·밸런싱 레벨에서는 훌륭**하나, 개발팀이 실제 작업에 착수하기 위해서는 **코드 아키텍처 정보**가 턱없이 부족합니다.

**지금 당장 기획 요청(Phase 3) 업무를 받아도 제대로 처리할 수 없는 상태**이며, 위 Phase 0 작업(특히 🔴 항목)을 선행 완료해야 합니다.

또한 C11에 따라 개발실은 다음 원칙을 유지합니다:
- **시뮬레이터 일원화** — 동일 로직 이중 유지 거부
- **카드 시스템 데이터 드리븐 강제** — 카드당 스크립트 금지
- **코어 분리** — NerdNavisCore에 들어갈 범용 기능과 수상한 잡화점 전용 로직 명확히 구분
- **성능 예산 먼저** — "일단 만들고 나중에 최적화" 금지

이상이 개발자 관점의 점검 결과입니다.