HongSJ — 2주차 게임 세션 스냅샷

1. 주요 변경사항

• GameSession, Player, MatchmakingQueue가 추가되어 Mirror 기반 세션 흐름이 본격적으로 들어왔다.
• Game.unity에 Canvas UI, 카드 UI, 장소 UI, 로그, 결과 오버레이가 구성되어 테스트 가능한 화면이 생겼다.
• 드래그앤드롭, 장소 시스템, 동시 제출, 턴 진행을 묶는 테스트용 UI가 추가되었다.
• TextMesh Pro 리소스와 ParrelSync 설정이 들어와 멀티 클라이언트 로컬 검증 기반은 좋아졌다.
• devlog_2026-04-23.md, marvel_snap_locations_all.md가 추가되었지만 설계 문서로 보기는 어렵다.

2. 코드 품질 리뷰

가장 큰 전진은 게임 루프를 실제 씬과 네트워크 구조 위에 올린 점이다. 이전보다 “무엇을 만들고 있는가”가 코드상으로 더 분명해졌다. 특히 GameSession을 별도 모듈로 둔 결정은 좋다. 턴, 에너지, 제출, 결과 계산이 흩어지지 않을 수 있는 중심축이 생겼기 때문이다.

반대로 위험 신호도 선명하다. Game.unity에 GameFlowTest, 비활성 DraftTester, 실제 NetworkManager, 운영 UI가 함께 들어 있다. 왜 문제냐면 테스트 훅과 실제 플레이 오브젝트가 같은 씬 생명주기를 공유하면 빌드에서 우연히 테스트 코드가 실행되거나, 네트워크 재접속 시 중복 상태가 생기는 버그를 만들기 쉽다. 개선하려면 운영 씬은 최소 구성으로 두고, 테스트 러너/디버그 HUD는 별도 프리팹 또는 개발 전용 씬으로 분리해야 한다.

또한 씬에 snapgame.duckdns.org, port: 7777, 버튼 텍스트, 오브젝트 이름 기반 연결이 직접 들어간다. 하드코딩 자체보다 더 큰 문제는 설정의 소유자가 불명확하다는 점이다. 서버 주소와 테스트 환경은 ScriptableObject 설정 또는 빌드 프로파일로 분리하고, 버튼 이벤트와 네트워크 명령 경로는 테스트로 잠가야 한다.

3. 진행도 평가

진행도는 약 36%로 본다. 핵심 루프의 뼈대와 UI 검증 장면은 생겼으므로 단순 스캐폴드 단계는 지났다. 다만 현재는 “플레이 가능한 게임”보다 “네트워크와 UI를 붙여보는 프로토타입”에 가깝다.

커밋 메시지는 주차 단위 목표가 드러나며 feature 브랜치 병합도 확인된다. 이 점은 좋다. 그러나 네트워크 권한 모델, 문서, 데이터 ID 안정성이 동시에 밀리면 이후 버그가 런타임에서만 드러난다. 지금 하루를 써서 구조를 고정하지 않으면 다음 주 디버깅 비용이 급격히 커질 가능성이 높다.

4. 다음 권장사항

• GameSession에서 서버만 결정해야 하는 상태를 명확히 분리하라. 점수, 턴 종료, 카드 배치는 서버 권위가 기본이다.
• Game.unity에서 테스트 오브젝트와 운영 오브젝트를 분리하라. 개발용 HUD는 별도 씬이나 프리팹으로 격리해야 한다.
• docs/technical.md를 만들고 Mirror 연결, Player 생성, GameSession 생성, 재접속 정책을 한 장으로 정리하라.
• 카드·장소 ID를 자동 순번이 아닌 명시적 stable key로 바꾸라. 에셋 추가 순서에 게임 데이터가 흔들리면 안 된다.
• 드래그 제출, 패스, 리셋, 결과 표시 경로를 최소 2인 시나리오 체크리스트로 고정하라.

5. 문서화 상태

design은 1점이다. 게임이 Marvel Snap 계열 구조라는 힌트는 있으나, 코어 루프와 플레이어 경험 목표를 설명하는 GDD가 없다. 왜 이 룰을 선택했는지 신규 인원이 추적할 근거가 부족하다.

technical은 1점이다. Mirror, ParrelSync, GameSession이 들어왔지만 권한 모델, 상태 흐름, 씬 생명주기 문서가 없다. 네트워킹 프로젝트에서 이 문서가 없으면 코드 리뷰보다 플레이 중 증상 추적에 의존하게 된다.

spec은 2점이다. 장소 목록 문서는 사양의 씨앗으로 볼 수 있으나 실제 씬, 입력, 카드 효과, 점수 계산, 턴 결과 매핑이 테스트 가능한 표로 정리되지 않았다.

6. Backlog

• 프로젝트 문서 부재는 아직 해결되지 않았다. devlog와 장소 목록은 참고 자료이지 GDD/기술/사양 문서가 아니다.
• Mirror 권한 모델 부재는 더 위험해졌다. 네트워크 코드가 늘어난 만큼 “누가 상태의 주인인가”를 지금 고정해야 한다.
• CardRegistry의 static Resources.LoadAll 구조는 테스트 격리와 런타임 교체를 계속 어렵게 만든다.
• 자동 증가 cardId는 에셋 정렬에 의존하는 구조로 보이며, 카드 추가·삭제 시 저장 데이터와 매칭이 깨질 수 있다.
• effectType/effectVal 단일 수치 효과 모델은 복합 효과가 들어오는 순간 조건문 폭증으로 이어질 가능성이 높다.