GhostMarch_DOTS — DOTS 전환 기준선 스냅샷
1. 주요 변경사항
Assets/DOTS아래 Components, Systems, Authoring assembly와HelloDots*샘플이 추가되어 DOTS 전환의 컴파일 경계가 생겼다.docs/reference/*,docs/migration/*,docs/architecture/*가 대량 추가되어 레거시 런타임, 프리팹, 씬 직렬화 값, 전환 전략이 문서화되었다.- 기존
Assets/Scripts가 Audio, Combat, Core, Enemy, Items, Player, UI, Utils로 재배치되어 탐색성은 개선되었다. - 무기 진화, 캐릭터 선택, Achievement, HUD, 특수기 관련 버그 수정과 GetComponent 캐싱이 다수 반영되었다.
ProjectSettings,Packages, URP 설정 변경이 함께 들어와 환경 변화와 기능 변화가 같은 범위에 섞였다.
2. 코드 품질 리뷰
가장 긍정적인 변화는 레거시 동작을 추측이 아니라 기준선으로 고정하려는 태도다. weapon-equipment-legacy-spec.md, scene-prefab-serialized-baseline.md는 실제 DOTS 재구현에서 흔히 누락되는 per 오프바이원, 풀 인덱스, 프리팹 태그, 직렬화 값을 구체적으로 잡았다. 이는 좋은 엔지니어링 문서다. 특히 “UI 설명이 아니라 런타임 코드를 기준으로 한다”는 방향은 올바르다.
다만 구현 쪽은 아직 전환 준비 단계다. HelloDotsSystem 수준의 샘플은 assembly 검증에는 충분하지만, 프로젝트의 핵심 리스크인 스폰·피해·수집·무기 발사 중 어느 것도 DOTS로 증명하지 못한다. 왜 문제인가 하면 문서가 아무리 좋아도 첫 vertical slice에서 physics, presentation bridge, pooling 대체 전략이 깨질 수 있기 때문이다. 다음 단계는 작은 기능 하나를 끝까지 옮겨 실제 씬에서 비교 검증하는 것이다.
레거시 코드 정리는 방향이 좋지만, 여전히 GameManager.instance, BroadcastMessage, 풀 인덱스, 태그 문자열 같은 런타임 계약이 강하게 남아 있다. 예를 들어 문서에 기록된 다음 계약은 반드시 테스트로 고정해야 한다.
bullet.GetComponent<Bullet>().Init(damage, -100, Vector3.zero);
player.BroadcastMessage("ApplyGear", SendMessageOptions.DontRequireReceiver);이 패턴이 왜 위험한지는 명확하다. 호출 대상이 누락되어도 조용히 지나가거나, 프리팹 태그 하나로 피해 판정이 사라질 수 있다. 개선 방향은 DOTS 이전에라도 stable id, 명시적 event/request 타입, prefab validation checklist를 만드는 것이다.
3. 진행도 평가
이전 대비 가장 큰 전진은 문서화와 구조화다. 단순 README 수준을 넘어, 레거시 동작을 재구현 가능한 사양으로 풀어낸 점은 확실한 진전이다. 특히 DOTS 재빌드에서 무엇을 보존하고 무엇을 바꿀지 논의할 기반이 생겼다.
진행률은 48%로 본다. 레거시 게임은 플레이 가능한 축이 있는 것으로 보이나, 이번 목표가 GhostMarch_DOTS라면 아직 DOTS 구현은 골격과 계획 단계다. 지금부터는 문서 추가보다 “작게 옮기고, 측정하고, 기존과 비교하는” 반복이 필요하다.
4. 다음 권장사항
- DOTS 첫 vertical slice를 정한다. 예: 적 스폰 1종, 이동, 피격, 사망까지 한 흐름을 실제 씬에서 검증한다.
ProjectSettings와 패키지 변경은 별도 커밋·별도 검증 로그로 분리한다. 환경 변경은 디버깅 비용이 크다.Range_01_Evo_Splash의Untagged상태가 의도인지 버그인지 Unity에서 확인한다.- assembly 참조 방향을 문서로만 두지 말고 asmdef와 CI compile check로 강제한다.
- 커밋은 기능 단위로 압축한다.
fix,wip,safe..?는 나중에 원인 추적을 방해한다.
5. 문서화 상태
design은 7점이다. game-design-spec.md가 생기고 플레이 요소가 정리되었지만, 플레이어 경험 목표와 밸런스 의도가 아직 레거시 관찰값 중심이다. “왜 이 수치인가”가 더 필요하다.
technical은 8점이다. assembly boundary, DOTS rebuild strategy, verification loop, serialized baseline은 신규 참여자가 구조를 이해하기에 충분히 실무적이다. 다만 실제 빌드·CI·테스트 실행 절차가 아직 강제 체계로 연결되지는 않았다.
spec은 8점이다. 무기, 장비, 씬, 프리팹, UI wiring 값이 상당히 구체적이다. _sample/docs의 10점 문서처럼 자동 검증 스키마와 QA 체크리스트까지 붙으면 9점 이상으로 올라갈 수 있다.
6. Backlog
- Unity 버전·패키지 변경이 기능 커밋과 계속 섞인다. 빌드 실패 시 원인 범위가 넓어져 위험하다.
- TextMesh Pro와 ShaderGraph 리소스 대량 변경의 의도는 이번 스냅샷에서도 해결 근거가 없다.
- Input System 샘플 리소스의 관리 경계 문제도 현재 자료만으로 정리되었다고 볼 수 없다.
- 커밋 메시지는 후반부에 좋아졌지만 전체 81개 범위에서는 여전히 fix·revert·wip 계열이 많다.
- AudioGen은 일부 사용처가 문서화되었으나 Aseprite와 대량 자산 전체의 출처·라이선스·사용처는 아직 불완전하다.