프로젝트 개요
report · 13 of 18 · 5 commits · 6d528062d5ffcfd7a20700c44ce8eb5942d5f4af..fb53433f510c63657106d6104b59203a8974e491

PlayerState 전환은 진전이나 Prefab 등록과 권한 검증이 아직 위험하다.

HIGH 진행도 48% (+ 2pts) 2026. 4. 30. PM 2:29

프로젝트 예상 진행도

기준: 2026. 4. 30. PM 2:29
48 / 100

문서화 상태

Design
6/10
Technical
7/10
Spec
5/10
#네트워킹 #PlayerState #흑과백 #런타임리스크 #문서화

HANPAN — PlayerState 네트워킹 전환 스냅샷

1. 주요 변경사항

2. 코드 품질 리뷰

이번 변경의 방향성은 좋다. MatchState가 매치 공통 상태만 맡고, 점수·제출 여부·PendingColor를 PlayerState로 분리한 것은 이후 4~6인 게임으로 확장할 때 필요한 구조다. 특히 LED 판정을 점수 변화 추론이 아니라 RoundResult.Outcome으로 처리한 점은 명확하다. 이전 방식은 NetworkVariable 반영 순서에 기대는 코드였고, 이번 방식은 “무엇이 이겼는가”를 이벤트 데이터가 직접 말한다.

다만 현재 구현은 “전략 수립”과 “실행 가능한 Unity 자산 상태” 사이에 빈틈이 있다. diff에는 PlayerState.cs만 있고 PlayerState.prefab 생성이나 NetworkManager 등록 변경이 보이지 않는다. 이 상태면 FindNetworkPrefab<PlayerState>()가 null을 반환하고 게임 초기화가 중단된다. 문서에 에디터 작업을 적는 것으로는 부족하다. Prefab 자산과 등록 상태를 커밋하거나, 최소한 PlayMode 검증으로 누락을 바로 잡아야 한다.

가장 위험한 코드는 2인 전용 가정이 숨은 채 N인 확장처럼 보이는 부분이다. DealTiles()_playerStates.Count만큼 반복하지만 상대 인덱스를 1 - i로 계산한다. 3명 이상이 들어오면 즉시 깨진다. 또한 SurrenderServerRpc()는 호출자가 참가자인지 확인하지 않고 “호출자가 아닌 첫 PlayerState”를 승자로 처리한다. 왜 문제인지 분명하다. 네트워킹 코드에서 참가자 검증이 빠지면 잘못된 클라이언트가 게임 결과를 바꿀 수 있다. FindPlayerState(caller) == null이면 return하고, BlackAndWhite는 clients.Count == 2를 강제해야 한다.

3. 진행도 평가

이전 리포트 대비 네트워크 상태 모델은 확실히 전진했다. PlayerState 도입, Leave idempotent 처리, PendingColor 표시 조건 정리는 의미 있는 개선이다. 하지만 이번 커밋 5개 중 다수가 fix이고, 새 구조가 아직 Unity Prefab 등록과 런타임 검증까지 닫히지 않았다. 코드만 보면 플레이 가능성은 올라갔지만, 실제 에디터 실행 성공은 아직 확인되지 않은 상태다.

진행도는 48%로 본다. 핵심 게임 루프는 형태가 있지만, 네트워크 초기화 실패 가능성·2인 가정 미검증·씬/사양 문서 부채가 남아 있다. 다음 단계는 기능 추가가 아니라 “2인 플레이가 항상 재현되는 기준선”을 잠그는 것이다.

4. 다음 권장사항

5. 문서화 상태

design은 6점이다. 게임별 의도와 네트워크 방향은 잡혀 있으나, 플레이 경험 목표와 시스템 간 선택 이유가 아직 깊게 연결되지는 않았다.

technical은 7점이다. Network_Authority 문서는 이번에 크게 좋아졌다. 권한 매트릭스, Leave 중복 보호, PlayerState 생명주기가 들어간 점은 실무적으로 유효하다. 단, 실제 Prefab 등록 검증 절차가 자동화까지 이어지지 않아 8점 이상은 어렵다.

spec은 5점이다. 흑과 백 구현은 진행 중이나 입력 매핑, UI 상태 전이, HUD 수치, 씬별 완료 조건이 테스트 체크리스트 수준으로 정리되지 않았다. _sample/docs의 10점 기준과 비교하면 아직 “구현자가 그대로 따라 만들 수 있는 사양”은 아니다.

6. Backlog

7. 이전 Backlog 해결

리포트 타임라인

18개 스냅샷 · 최신순
MED 1 commits 3D 보드 비주얼은 전진했으나 씬 직편집 부채가 계속 누적됨. 31% HIGH 6 commits 멀티플레이 복귀 버그를 줄였지만 상태 생명주기 부채가 크다. 43% HIGH 4 commits 복귀 버그는 완화됐지만 씬 전환 책임이 UI에 퍼졌다. 43% HIGH 8 commits Additive 씬 전환은 전진했으나 네트워크 복귀 흐름 위험이 크다. 42% HIGH 9 commits Matching 씬 구조는 전진했지만 대형 씬 커밋 리스크가 계속 크다. 42% HIGH 5 commits PlayerState 전환은 진전이나 Prefab 등록과 권한 검증이 아직 위험하다. 48% HIGH 55 commits 3D 보드와 UI는 전진했지만 씬·네트워크 부채가 커졌다. 46% HIGH 10 commits BlackAndWhite UI는 전진했지만 네트워크 표시 신뢰성이 흔들린다. 45% HIGH 8 commits UI 전진은 있으나 씬 생성물·바인딩 부채가 커졌다. 40% HIGH 22 commits BlackAndWhite 구현은 전진했지만 씬·네트워크 부채가 급증했다. 43% MED 2 commits 흑과백 모델링은 전진했으나 동시 제출 규칙이 흔들린다. 33% MED 3 commits M2 안정화와 사양화는 진전, 게임 본편은 아직 진입 전이다. 45% MED 3 commits 네트워크 문서화는 크게 전진했으나 구현 안전망은 아직 남아 있다. 43% HIGH 10 commits 로비 UI와 Relay WSS는 전진했으나 설계 부채가 누적 중이다. 32% HIGH 7 commits 로비 기능은 전진했지만 네트워크 설계 부채가 커졌다. 34% MED 4 commits NGO 뼈대·00_Boot·asmdef 계층 구축, 단일 클라이언트 로비 검증. 22% MED 3 commits Unity URP 프로젝트 부팅 및 WebGL 전환, 핵심 기술 리스크는 미해결. 18% LOW 3 commits Unity 개발 계획 문서 신규 작성, 컨셉 오탈자 정정. 코드 착수 전 단계. 15%