프로젝트 개요
report · 3 of 9 · 2 commits · e94bf222b60043a465a57d2e15a025768c08cc8b..4ac6763ed3c7129498340256b86d945f2c4bede1

커스텀 네트워킹은 시작됐지만 산출물 커밋과 설계 부재가 위험하다.

HIGH 진행도 30% (+ 2pts) 2026. 4. 28. AM 10:15

프로젝트 예상 진행도

기준: 2026. 4. 28. AM 10:15
30 / 100

문서화 상태

Design
2/10
Technical
1/10
Spec
1/10
#네트워킹 #빌드산출물 #유니티 #문서부채

YJ — 네트워킹 도입 스냅샷

1. 주요 변경사항

2. 코드 품질 리뷰

이번 변경에서 가장 긍정적인 점은 멀티플레이를 말로만 남기지 않고 실제 클라이언트 네트워크 코드와 별도 서버 프로젝트까지 만들었다는 점이다. BoardManager, PieceGame 하위로 이동한 것도 도메인별 정리를 시작했다는 신호다. 다만 Listner, Pakcet 같은 오탈자가 서버 핵심 타입명에 남아 있는 것은 가볍게 볼 문제가 아니다. 네트워크 계층은 문자열·타입명·패킷 ID 하나가 런타임 장애로 이어지므로 명명 정확도가 품질이다.

가장 큰 문제는 빌드 결과물 커밋이다. BuildTest/ 의 Unity 런타임 DLL, exe, Mono 설정 파일과 서버 bin/obj 파일은 소스가 아니라 생성물이다. 이것이 저장소에 들어오면 실제 코드 변경 200줄을 검토하기 위해 수만 줄의 산출물을 같이 보게 되고, 이후 브랜치 병합·리뷰·용량 관리가 모두 망가진다. 반드시 삭제하고 .gitignore 로 재발 방지해야 한다.

네트워킹은 현재 위험 구간에 진입했다. NetworkManager, Packet, PacketHandler, 서버 Session 이 생겼지만 스냅샷만으로는 “말 위치와 턴 상태의 최종 권위가 서버인지 클라이언트인지”가 드러나지 않는다. 이 상태로 PlayerController 에 이동·선택·룰 판정·송신이 계속 붙으면 버그 재현이 어려워진다. 입력 처리, 룰 검증, 네트워크 반영을 지금 분리해야 한다.

3. 진행도 평가

이전 대비 전진은 분명하다. 로컬 이동 상호작용에서 네트워크 실험 단계로 넘어갔고, 실행 빌드까지 만들어 본 흔적이 있다. 그러나 “빌드가 있다”와 “재현 가능한 멀티플레이가 있다”는 다르다. 현재는 기능 전진과 저장소 품질 하락이 동시에 발생한 상태다.

진행률은 약 30%로 본다. 핵심 루프 일부와 네트워킹 골격은 생겼지만, 권한 모델·패킷 계약·씬 흐름·문서가 아직 제출 가능한 수준이 아니다. 다음 스냅샷 전까지 생성물 정리와 2인 플레이 재현성을 확보하지 못하면 디버깅 비용이 급격히 커진다.

4. 다음 권장사항

5. 문서화 상태

design 점수는 2점이다. 이전의 placeholder 문제가 해소됐다는 근거가 없고, 게임의 코어 경험·룰 차별점·쇼기 변형 규칙의 의도가 문서로 고정되지 않았다.

technical 점수는 1점이다. 네트워크 서버가 추가됐는데 권한 모델, 패킷 흐름, 접속·해제 시퀀스, 빌드 절차 문서가 없다. 신규 인원이 문서만 보고 구조를 이해할 수 없는 상태다.

spec 점수는 1점이다. 씬 구성, 매칭/대기실/인게임 전환, 입력별 상태 변화, 포로 재배치 규칙, 멀티플레이 검증 기준이 테스트 체크리스트로 쓸 만큼 구체화되지 않았다.

6. Backlog

7. 이전 Backlog 해결

리포트 타임라인

9개 스냅샷 · 최신순