프로젝트 개요
report · 2 of 8 · 2 commits · 6f9dd7f3a49426339ecb02ae1336473c8399a6ba..1f32eeef0a3f70ef4f3ffde979fb7d5ed11ab81c

던전·로비 기반은 생겼지만 권한·자산 관리 리스크가 크다.

HIGH 진행도 28% (+ 13pts) 2026. 4. 28. PM 2:46

프로젝트 예상 진행도

기준: 2026. 4. 28. PM 2:46
28 / 100

문서화 상태

Design
4/10
Technical
2/10
Spec
2/10
#던전생성 #네트워킹 #에셋관리 #씬구조 #문서부채

Exit-or-die — 던전·로비 도입 스냅샷

1. 주요 변경사항

2. 코드 품질 리뷰

이번 변경은 “바닥 생성 로직”과 “타일 겹침 수정”이 핵심인데, 바로 이 지점이 가장 위험하다. 겹침 버그는 보통 좌표 기준, 타일 크기, 피벗, 점유 상태 관리가 코드 안에 흩어져 있을 때 반복된다. DungeonGenerator.cs는 다음 단계에서 랜덤 생성보다 먼저 “이미 점유된 좌표에는 생성하지 않는다”, “타일 크기는 상수 또는 설정 데이터에서만 읽는다”는 규칙을 코드와 테스트로 고정해야 한다.

네트워킹은 더 직설적으로 경고가 필요하다. ClientNetworkTransform이라는 이름 자체가 클라이언트 주도 이동을 암시한다. 협동 던전 게임에서 이동은 어느 정도 클라이언트 예측이 가능하지만, 점수·피해·상호작용·아이템 획득까지 클라이언트 권위로 번지면 디버깅 불가능한 영역에 들어간다. 개선 방향은 서버 권위 상태와 클라이언트 표시 상태를 분리하고, 로비 입장·스폰·씬 전환마다 “누가 상태의 주인인가”를 코드 주석이 아니라 구조로 드러내는 것이다.

대량 에셋 커밋도 품질 문제다. 에셋 자체가 나쁜 것이 아니라, 예제 씬·폰트·미사용 OBJ가 실제 제품 자산과 같은 변경 단위로 들어오면 리뷰가 사실상 불가능해진다. 앞으로는 외부 에셋 import 커밋과 게임 로직 커밋을 분리하고, 사용하지 않는 샘플은 Assets/ThirdParty 또는 별도 보관 영역으로 격리해야 한다.

3. 진행도 평가

이전 대비 전진은 분명하다. 로비, 게임 씬, 플레이어 프리팹, 던전 생성 코드가 들어오면서 “빈 샘플 프로젝트” 단계는 벗어났다. 다만 아직 핵심 루프가 플레이 가능하다고 보기에는 부족하다. 생성된 던전에서 무엇을 하고, 언제 성공·실패하며, 네트워크 환경에서 그 상태가 어떻게 동기화되는지가 보이지 않는다.

진행도는 28%로 판단한다. 스캐폴드와 기반 시스템은 생겼지만, 현재 리스크는 구현량 부족보다 방향 통제 부족에 가깝다. 특히 네트워킹과 절차적 생성이 동시에 들어온 상태에서 검증 장치가 없으면 이후 버그 비용이 급격히 증가한다.

4. 다음 권장사항

5. 문서화 상태

design 점수는 4점이다. 게임 컨셉 문서는 있는 것으로 보이나, 이번 변경의 던전·로비·멀티플레이 구조가 디자인 의도와 어떻게 연결되는지 갱신되지 않았다.

technical 점수는 2점이다. 네트워크 모듈과 던전 모듈이 추가됐지만 권한 모델, 씬 전환 흐름, 프리팹 등록 방식, 빌드 절차를 설명하는 기술 문서가 보이지 않는다. 신규 팀원이 문서만 보고 구조를 파악하기 어렵다.

spec 점수는 2점이다. 타일 겹침 수정이 있었다면 타일 크기, 좌표 그리드, 방 배치 규칙, 충돌 판정 기준이 사양으로 남아야 한다. 현재는 테스트 체크리스트로 바로 쓸 수 있는 수치와 상태 정의가 부족하다.

6. Backlog

7. 이전 Backlog 해결

리포트 타임라인

8개 스냅샷 · 최신순