13 KiB
13 KiB
수상한 잡화점 — 개발자 관점 점검
작성일: 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 코드"여야 함 — 기획·시뮬은 이를 참조해야 함
권장 조치
/게임플레이가 실제 Unity 구현을 읽고 정확한 동작 문서화- 해당 문서를 기획실에 전달 (
공유/개발실→기획실/) - 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 소유권 전환 → 신규 코어 제작 결정)을 참조 표기만 하고 본문 작성 누락
- 재발 방지 조치:
- 공통 규칙 P18 (설계 문서화 의무) 신설됨 — 참조된 설계 문서는 반드시 실제 존재
- 문서 간 참조 링크가 추가될 때 해당 파일의 존재 여부를 즉시 확인하는 습관 정착
- 설계 결정사항은 회의록·구두·요약이 아닌 전용 설계 문서로 반드시 명문화
- 팀장급은 자기 팀 산출물의 교차 참조 무결성을 주기적으로 점검
- 연관:
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에 들어갈 범용 기능과 수상한 잡화점 전용 로직 명확히 구분
- 성능 예산 먼저 — "일단 만들고 나중에 최적화" 금지
이상이 개발자 관점의 점검 결과입니다.