HongSJ — 4주차 씬 플로우 스냅샷

1. 주요 변경사항

• Draft, Match 씬이 추가되고 Main → Match → Draft → Game → Match/Main 으로 이어지는 아레나 반복 흐름이 들어갔다.
• GameSession 이 Game 씬 로드 시 MatchmakingQueue.Pending 을 읽어 세션을 초기화하고, 양쪽 클라이언트 준비 후 턴을 시작하도록 바뀌었다.
• 카드 효과가 effectType/effectVal 중심에서 IOnRevealEffect, IOngoingEffect, IEndOfTurnEffect 인터페이스 기반으로 이동했다.
• 승패 누적, 6승/3패 종료, 다음 씬 준비 메시지 등 아레나 진행 상태가 네트워크 흐름에 포함됐다.
• 다수 카드 에셋과 카드별 ScriptableObject 클래스가 추가되어 효과 표현력은 분명히 좋아졌다.

2. 코드 품질 리뷰

가장 긍정적인 변화는 카드 효과 모델이다. KazarData 처럼 카드별 클래스로 효과를 분리한 것은 기존 수치 필드 하나에 의미를 욱여넣던 구조보다 확장성이 훨씬 낫다. 왜 좋은가 하면, 카드 효과의 발동 시점과 적용 규칙이 타입으로 드러나기 때문에 새 카드를 추가할 때 기존 거대 분기문을 건드릴 필요가 줄어든다. 다만 효과 순서, 중복 적용, 억제 규칙은 이미 GameSession 에 집중되고 있으므로 다음 단계에서는 효과 해석기를 별도 클래스로 떼어 테스트 가능하게 만들어야 한다.

위험 신호는 네트워크 세션 상태다. MatchmakingQueue.Pending 을 정적 전역 슬롯처럼 쓰고 GameSession.OnStartServer() 에서 소비하는 방식은 1매치 데모에서는 편하지만, 동시에 두 매치가 생기거나 씬 로드가 어긋나면 상태가 덮일 수 있다. 왜 문제냐면 멀티플레이 버그는 재현성이 낮고, 전역 상태는 어떤 연결의 덱과 승패가 어느 세션에 들어갔는지 추적을 어렵게 만든다. 매치 ID 기반 세션 테이블이나 연결별 준비 상태 맵으로 바꾸는 편이 안전하다.

자료구조/복잡도 관점에서는 RunOngoingPass, KazarData.ApplyOngoing, HasOnslaught 가 매 공개마다 모든 존과 카드에 대해 CardRegistry.Get 을 반복한다. 현재 카드 수가 작아 성능 병목이라고 단정할 수준은 아니지만, 효과 계산 hot path 가 커질 구조다. 현재 비용은 효과 수 × 존 카드 수 × registry lookup 반복이며, 개선은 CardInstance 에 CardData 캐시 또는 턴 계산용 카드 테이블을 전달하는 방식이 적절하다. 이 프로젝트에서는 성능보다도 효과 테스트와 디버깅 단순화 측면에서 의미가 크다.

3. 진행도 평가

이전 대비 기능 진척은 확실하다. 단순 카드 배치 실험에서 벗어나 draft, match, game, 결과 후 반복까지 프로젝트의 핵심 루프가 형태를 갖췄다. 커밋 메시지도 주차별 구현 범위를 비교적 잘 설명하고 있어 흐름 파악이 가능하다.

다만 완성도 평가는 보수적으로 봐야 한다. 네트워크 권한 모델 문서가 없고, 서버 입력 검증과 세션 격리도 아직 확신하기 어렵다. 지금 상태는 “플레이 가능한 프로토타입 진입”이지 “안정적인 멀티플레이 게임”은 아니다. 남은 기간이 짧다면 신규 카드 추가보다 권한·씬 전환·재현 테스트 고정이 우선이다.

4. 다음 권장사항

• Draft/Match/Game 씬 전환의 서버 권한 흐름을 명시하고, Pending 전역 슬롯 의존을 제거한다.
• 카드 제출 시 서버에서 손패 소유 여부, 에너지, 존 인덱스, 존 수용량을 모두 검증한다.
• docs/technical.md 를 만들고 매칭, 드래프트, 게임 결과, 아레나 종료의 권한 주체를 표로 정리한다.
• OnReveal/Ongoing/EndOfTurn 순서와 Onslaught 중복 적용 규칙을 테스트로 고정한다.
• CardRegistry 의 정적 로딩과 자동 순번 ID 문제는 다음 구조 개선 작업으로 잡는다.

5. 문서화 상태

design 점수는 0점이다. repo 내 GDD나 코어 루프 설명 문서가 확인되지 않으며, 이번 커밋도 문서 갱신 없이 코드와 씬만 추가됐다. 신규 유입자는 왜 Draft → Match → Game 구조인지 코드에서 역추적해야 한다.

technical 점수도 0점이다. Mirror 기반 서버 권위, Command/Message 흐름, 씬 전환 시 상태 보존 전략이 문서화되어 있지 않다. 특히 멀티플레이 프로젝트에서 권한 모델 문서 부재는 단순 아쉬움이 아니라 디버깅 비용을 폭증시키는 결함이다.

spec 점수 역시 0점이다. 카드 효과 타이밍, 아레나 승패 규칙, 드래프트 선택 수, 매치 종료 조건 같은 테스트 가능한 사양이 별도 문서로 정리되어 있지 않다. 지금은 구현이 사양을 겸하고 있어 변경 시 회귀 기준이 없다.

6. Backlog

• 프로젝트 문서 부재는 계속 남아 있다. 현재 구현량이 늘어난 만큼, 문서 없이 설계 의도를 복원하는 비용도 같이 커졌다.
• Mirror 권한 모델은 코드 일부에서 서버 중심으로 보이지만, 카드 draft/배치/점수 계산 권한이 문서로 고정되지 않았다.
• MatchmakingQueue.Pending 정적 전달 방식은 동시 매치와 씬 재로드에 취약하므로 장기 부채가 아니라 가까운 위험이다.
• CardRegistry 의 static Resources.LoadAll 구조는 테스트 격리와 런타임 교체를 어렵게 만드는 문제가 유지된다.
• 자동 증가 cardId 는 에셋 정렬에 의존하는 위험이 그대로 남아 카드 추가 시 회귀 가능성이 높다.

7. 이전 Backlog 해결

• CardData.effectType/effectVal 에 효과를 몰아넣던 문제는 인터페이스 기반 카드 효과 클래스를 추가하면서 실질적으로 개선됐다. KazarData 같은 카드별 구현과 GameSession 의 발동 타이밍 분리가 확인되므로 해결 처리한다.