GhostMarch_2 — Phase 0 씬·네트워크 스냅샷

1. 주요 변경사항

• Boot, MainMenu, Lobby 씬과 EditorBuildSettings가 추가되어 실행 진입점이 생겼다.
• Core, Data, Network, Player, UI에 실제 C# 파일이 들어오며 이전보다 모듈 경계가 구체화되었다.
• LobbyManager, BootInitializer, NetworkPrefabsList, DefaultNetworkPrefabs 등 NGO 기반 로비 준비물이 추가되었다.
• TextMesh Pro, 한글 폰트, DOTween, JSAM, SaintsField 설정 등 에셋·툴링 초기 구성이 대량 반영되었다.
• Claude Code 에이전트와 스킬 문서가 추가되어 작업 자동화 방향은 잡혔지만, 게임 설계 문서와는 아직 분리되어 있다.

2. 코드 품질 리뷰

이번 커밋은 “빈 프로젝트”에서 “실행 가능한 Phase 0 골격”으로 넘어간 점은 명확한 전진이다. 특히 EventBus.cs, LobbyEvents.cs, CharacterDataSO.cs처럼 작게 시작한 파일들은 좋은 신호다. 다만 제공된 diff가 대형 폰트 YAML 위주로 샘플링되어 LobbyManager.cs, LobbyUIController.cs, SceneBuilder.cs 내부 구현은 세부 검증이 제한된다. 이 상태에서 네트워크 로비 코드를 병합한 것은 위험하다. 네트워킹은 코드가 짧아도 권한·씬 전환·재접속 문제가 런타임에서만 터지므로, 반드시 에디터 플레이와 빌드 실행으로 확인해야 한다.

가장 큰 위험은 UI, 로비, 네트워크 초기화가 동시에 들어왔는데 권한 모델 문서가 없다는 점이다. 왜 문제냐면 NGO 프로젝트에서 “누가 상태의 주인인가”가 흐리면 나중에 RPC 호출 위치, NetworkVariable 소유권, 씬 재진입 버그가 서로 얽혀 디버깅 비용이 급증한다. 개선하려면 LobbyManager 기준으로 서버 권위 상태, 클라이언트 요청, UI 표시 전용 상태를 표로 나누고, UI는 직접 게임 모듈을 물고 가지 않도록 Core 이벤트 또는 명시적 ViewModel 경계를 둬야 한다.

에셋 관리도 경고 수준이다. NeoDunggeunmoPro-Regular.asset 하나가 62만 줄이고 TMP 리소스까지 합쳐 커밋 대부분을 차지한다. 왜 문제냐면 코드 리뷰 품질을 떨어뜨리고 저장소 크기·충돌 가능성을 키운다. 개선은 간단하다. 폰트 원본과 생성물을 Git LFS 대상으로 분리하고, Resources에 넣어야 하는 자산과 Addressables로 넘길 자산을 정책화해야 한다.

3. 진행도 평가

진행도는 22%로 본다. Boot-Lobby-MainMenu와 Player 프리팹이 생겨 Phase 0 실행 흐름은 잡혔지만, 아직 핵심 전투·적·웨이브·픽업·공명 루프가 비어 있다. 지금은 “플레이 가능한 게임”이 아니라 “멀티플레이 진입을 실험할 수 있는 기반”에 가깝다.

위험도는 high다. 이유는 네트워킹 코드가 들어온 반면 빌드 검증, 권한 모델 문서, 콘텐츠 사양서가 동시에 부족하기 때문이다. 이 조합은 초반에는 빠르게 보이지만, 2주 뒤에는 로비와 게임플레이가 서로 발목을 잡을 가능성이 높다.

4. 다음 권장사항

• Unity 에디터에서 NGO 포함 전체 빌드와 Boot-Lobby 전환 검증을 최우선으로 수행한다.
• LobbyManager 권한 모델을 서버 기준으로 명시하고 RPC 경로를 점검한다.
• UI.asmdef 참조 범위를 Core와 Network 이벤트 계약 중심으로 축소한다.
• 무기·적·웨이브 ScriptableObject 사양서와 최소 데이터를 추가한다.
• SceneBuilder 생성 씬의 참조를 프리팹·데이터 자산 기준으로 고정한다.
• 대형 폰트와 TMP 생성물의 Git LFS·Resources 적재 정책을 정리한다.

5. 문서화 상태

design 점수는 3점이다. concept.md가 갱신되었지만 코어 루프, 플레이어 경험 목표, 시스템 간 상호작용이 아직 의사결정 문서 수준으로 정리되지 않았다.

technical 점수는 3점이다. 에이전트·스킬 가이드는 작업 방식 문서로는 의미가 있으나, 신규 개발자가 네트워크 권한 모델과 모듈 구조를 이해할 수 있는 기술 문서는 부족하다.

spec 점수는 1점이다. 무기, 적, 웨이브, 캐릭터 수치가 들어갈 ScriptableObject 폴더는 생겼지만, 어떤 필드와 밸런스 기준으로 데이터를 만들지 정한 사양서가 없다. 이 상태에서 데이터가 늘어나면 코드가 임시 기준을 대신 떠안게 된다.

6. Backlog

• UI.asmdef의 넓은 참조 문제는 아직 해결 근거가 부족하다. UI는 표시 계층이어야 하며, 게임 모듈 상위 계층처럼 행동하면 구조가 뒤집힌다.
• NGO 2.11.0 의존성은 manifest.json 기준 빌드 확인이 필요하다. 패키지 해석 실패는 런타임이 아니라 프로젝트 오픈 단계에서 막힌다.
• 콘텐츠 사양서 부재는 계속 남아 있다. 무기·적·웨이브 수치가 문서 없이 코드로 먼저 들어가면 밸런싱 추적이 불가능해진다.
• Combat, Enemy, Wave, Pickup, Resonance는 여전히 실질 구현이 거의 없다. 다음 커밋부터 최소 수직 슬라이스로 검증해야 한다.
• SaintsField·JSAM fork 변경 배경과 CLAUDE.md 참조 문서 링크는 정리되지 않았다. 툴링 변경은 재현 가능한 설명이 있어야 한다.
• 대형 TMP·폰트 에셋은 저장소 운영 부채다. LFS와 Addressables/Resources 정책을 분리해야 한다.

7. 이전 Backlog 해결

• asmdef만 존재하던 상태는 일부 해소되었다. Core, Data, Network, Player, UI에 실제 C# 파일이 추가되어 최소한의 모듈 경계 검증은 시작되었다. 다만 Combat·Enemy·Wave 계열은 별도 backlog로 계속 추적해야 한다.