HANPAN — BlackAndWhite 데이터 모델 스냅샷

1. 주요 변경사항

• Tile, Hand, RoundResult, MatchState가 추가되어 흑과백 게임의 서버 권한 데이터 모델이 처음 코드화됐다.
• BlackAndWhite 사양서가 v1.1로 갱신되며 선/후공 구조를 제거하고 AwaitingBothPlayers 기반 제출 흐름으로 바뀌었다.
• 특수룰 “1이 9를 이김”이 문서에 명시됐고, 본 게임과 연장전 모두 같은 비교 규칙을 쓰도록 정리됐다.
• 손패는 서버 메모리에만 두고 색상과 점수만 NetworkVariable로 공개한다는 정보 은닉 방향은 적절하다.

2. 코드 품질 리뷰

이번 변경의 좋은 점은 모델의 책임 경계가 비교적 선명하다는 점이다. Hand는 서버 내부 손패 컨테이너로 두고, MatchState는 공개 가능한 라운드 상태만 NetworkVariable로 분리했다. 이는 멀티플레이 게임에서 가장 중요한 “누가 상태의 주인인가”를 코드에 드러내는 방향이라 긍정적이다. 이번 범위에는 Update, 반복 GetComponent, Instantiate/Destroy 루프 같은 Unity 런타임 비용 문제도 새로 생기지 않았다.

다만 Tile은 핵심 도메인 타입인데 값 검증이 없다. 지금은 주석으로만 1~9를 보장한다.

public byte Number;
public Tile(byte number) { Number = number; }

왜 문제인가 하면, 잘못된 숫자가 한 번 들어오면 색상 계산, 승패 비교, 네트워크 직렬화가 모두 그 값을 정상값처럼 취급한다. 개선은 단순하다. 생성자 또는 정적 팩토리에서 1..9 범위를 강제하고, Compare(1,9), Compare(9,1), 일반 대소 비교, 동률 테스트를 먼저 추가해야 한다.

가장 큰 위험은 “동시 제출”이라는 이름과 실제 설계가 다르다는 점이다. 현재 사양은 먼저 제출한 플레이어의 색상이 즉시 공개되어, 나중에 제출하는 플레이어가 그 정보를 보고 반응할 수 있다. 이것이 의도라면 동시 제출이 아니라 색상 선공개 심리전이다. 진짜 동시 제출이 목표라면 양쪽 선택을 잠근 뒤 둘 다 제출했을 때 색상을 공개하는 commit-reveal 구조로 바꿔야 한다. 또한 PendingColorA/B 기본값이 Black이라 미제출 상태와 흑 제출 상태가 값만으로 구분되지 않는다. UI가 HasSubmitted 게이트를 놓치면 잘못된 정보가 표시될 수 있으므로 Unknown 값을 두거나 제출 상태와 색상을 하나의 구조로 묶는 편이 안전하다.

3. 진행도 평가

이전 대비 전진은 분명하다. 문서가 자연어 아이디어에서 서버 권한, 상태머신, edge case 중심의 개발 사양으로 올라왔고, 코드도 그 사양을 따르는 최소 모델을 만들기 시작했다. 커밋 메시지도 docs(spec), feat(game)로 의도가 분리되어 추적성이 좋다.

하지만 아직 플레이 가능한 루프는 아니다. ServerRpc, ClientRpc, 라운드 전이, UI 입력 활성화, NetworkObject 배치, Player Prefab 전략이 모두 남아 있다. 그래서 진행률은 33%로 본다. 지금 단계에서 동시 제출 규칙을 확정하지 않으면 이후 네트워크 디버깅 비용이 급격히 커진다.

4. 다음 권장사항

• 동시 제출 규칙을 commit-reveal 또는 색상 선공개 룰 중 하나로 확정한다.
• MatchState에 A/B 매핑, 서버 제출 검증, 라운드 전이 테스트를 구현한다.
• Tile 생성 경로에 1~9 검증과 Compare 특수룰 단위 테스트를 추가한다.
• 게임 본편 NetworkObject / Player Prefab / MatchState 배치 전략을 문서와 프리팹 기준으로 확정한다.
• BlackAndWhite HUD의 입력 가능 상태, 제출 표시, 결과 공개 상태 전이 체크리스트를 작성한다.

5. 문서화 상태

design은 6점이다. 흑과백의 정보 은닉과 심리전 방향은 드러나지만, 플레이어 경험 관점에서 왜 동시 제출 또는 선공개 구조를 택하는지 설명이 아직 부족하다.

technical은 6점이다. 서버 권한 모델과 NetworkVariable 공개 범위는 좋아졌으나, NetworkObject 생명주기, Player Prefab, 씬 배치, 이탈 처리 흐름이 아직 연결되지 않았다.

spec은 7점이다. BlackAndWhite 사양서는 상태, 종료 조건, 연장전, 특수룰까지 테스트 기준으로 쓸 수 있는 수준에 가까워졌다. 다만 레벨/씬별 입력 매핑, HUD 수치, 실제 QA 체크리스트는 여전히 별도 사양으로 부족하다.

6. Backlog

• 게임 본편 NetworkObject/Player Prefab 전략 미확정: MatchState가 생겼지만 어디에 붙고 누가 소유하는지 아직 결정되지 않았다.
• 수동 leave 코드와 SDK 자동 leave 훅 중복 가능성 미검증: 네트워크 이탈 처리는 게임 중단과 로비 복귀에 직접 영향을 준다.
• 01_Lobby 씬 UI 하드코딩: 씬 파일 중심 UI는 변경 diff가 커지고 재사용성이 낮아진다.
• 레벨/씬별 상세 사양서 부재: 입력, UI 상태, HUD 수치가 없으면 구현 완료 판정이 흔들린다.
• PendingColor 기본값 문제: 미제출과 흑 제출을 값만으로 구분하지 못해 UI 오표시 여지가 있다.
• URP 템플릿 튜토리얼·Mobile 렌더러 잔존: 빌드 크기와 프로젝트 탐색 비용을 계속 늘린다.