프로젝트 개요
report · 7 of 9 · 1 commits · a9f55cbc4b55c1a6df7191870246b775261a3710..183d3230dedb5e3d4c1df32b61df65c896a78c9f

서버 턴 권위 도입은 전진이나 동기화 설계가 아직 불안정하다.

HIGH 진행도 34% ( -1pts) 2026. 4. 30. PM 3:26

프로젝트 예상 진행도

기준: 2026. 4. 30. PM 3:26
34 / 100

문서화 상태

Design
3/10
Technical
2/10
Spec
2/10
#네트워킹 #턴동기화 #서버권위 #프로토콜 #문서부채

YJ — 턴제 동기화 수정 스냅샷

1. 주요 변경사항

2. 코드 품질 리뷰

서버가 턴 권한을 검사하기 시작한 점은 명확한 전진이다. 이전에는 클라이언트가 턴 종료와 게임오버를 직접 판단했으나, 이번 변경으로 C_TurnOverHandler 에서 서버가 생명 차감과 게임오버를 결정한다. 멀티플레이 게임에서 “승패와 자원 감소는 서버가 결정한다”는 방향은 맞다.

다만 구현은 아직 중간 상태다. S_TurnOver 는 생명만 보내고 현재 턴은 보내지 않는다. 클라이언트는 수신 후 pc.EndTurn() 으로 로컬 턴을 넘긴다. 즉 서버 권위처럼 보이지만 실제 턴 상태는 여전히 클라이언트 추론에 의존한다. 패킷 유실, 중복 수신, 재접속, 지연 상황에서 다시 불일치가 생긴다. 개선하려면 서버 응답에 currentTurn, blueLife, redLife, 필요하면 turnSequence 를 포함하고 클라이언트는 그 값을 그대로 반영해야 한다.

pc.UpdateLifeUI(pkt.blueLife, pkt.redLife);
pc.EndTurn();

Assets/Scripts/Network/Session.cs 의 빈 Send 는 위험 신호다. 메서드 호출은 성공처럼 보이지만 실제로는 아무것도 전송하지 않는다. 이런 no-op 네트워크 코드는 런타임 디버깅을 매우 어렵게 만든다. 임시 스텁이면 컴파일 전용임을 명확히 분리하고, 실제 코드 경로에서는 예외를 던지거나 진짜 세션 구현으로 연결해야 한다.

3. 진행도 평가

이번 커밋은 “턴 동기화를 서버 중심으로 옮기려는 시도”라는 점에서 전진이다. 그러나 이동·드롭은 여전히 클라이언트 패킷을 그대로 브로드캐스트하고, 턴 상태도 완전한 서버 스냅샷으로 내려오지 않는다. 그래서 현재 진행도는 핵심 루프가 일부 붙은 30%대 초중반으로 보는 것이 타당하다.

가장 큰 장애물은 네트워크 권한 모델이 코드와 문서 양쪽에서 아직 확정되지 않았다는 점이다. 지금 구조로 기능을 계속 얹으면 버그가 “가끔 턴이 꼬임” 형태로만 보이게 된다. 이 단계에서 하루 정도를 투자해 패킷 방향, 상태 소유자, 재접속 정책을 고정하는 편이 이후 비용을 줄인다.

4. 다음 권장사항

5. 문서화 상태

design 점수는 3점이다. 컨셉 문서와 GDD 흔적은 있으나 placeholder 와 문법 깨짐 이슈가 남아 있어 팀원이 디자인 의도를 안정적으로 따라가기 어렵다.

technical 점수는 2점이다. 이번 커밋은 네트워크 권한 모델을 건드렸지만, 서버·클라이언트 상태 소유권, 패킷 방향, 실패 처리 기준이 문서로 남지 않았다. 신규 유입자가 코드를 읽지 않고 구조를 이해할 수 없는 상태다.

spec 점수는 2점이다. 턴 제한, 생명, 승리 조건, 팀 배정, 씬 흐름 같은 실제 테스트 기준이 사양서로 정리되지 않았다. 현재는 구현을 보고 규칙을 역추적해야 하므로 QA 체크리스트로 쓰기 어렵다.

6. Backlog

리포트 타임라인

9개 스냅샷 · 최신순