Exit-or-die — 초기 프로젝트 스냅샷

1. 주요 변경사항

• Unity URP 기반 초기 프로젝트가 추가됐고, Assets, Packages, ProjectSettings 구조가 커밋됐다.
• InputSystem_Actions.inputactions 가 생성되어 Player/UI 액션 맵과 키보드·패드·터치·XR 바인딩이 포함됐다.
• PlayerController.cs 가 추가됐지만 현재 diff 기준으로는 게임 루프를 판단할 만큼의 구현량은 매우 작다.
• README.md 와 docs 하위 문서들이 추가되어 기획 방향을 남기려는 시도는 확인된다.
• 기본 씬은 아직 SampleScene 중심이며, 프로젝트 고유의 플레이 장면 구조는 거의 드러나지 않는다.

2. 코드 품질 리뷰

이번 커밋은 기능 구현보다 프로젝트 스캐폴드에 가깝다. 따라서 코드 품질의 핵심 문제는 복잡한 로직보다 “초기 설정을 얼마나 깨끗하게 고정했는가”에 있다. 이 기준에서는 위험 신호가 있다. DefaultVolumeProfile.asset 에 Unity 렌더 파이프라인 테스트용으로 보이는 컴포넌트와 m_Script: {fileID: 0} 참조가 포함되어 있다. 이는 당장 게임 로직 버그는 아니지만, 콘솔 경고·누락 스크립트·렌더링 품질 검증을 흐리게 만든다.

m_Script: {fileID: 0}
m_Name: CopyPasteTestComponent2
m_EditorClassIdentifier: Unity.RenderPipelines.Core.Editor.Tests

프로젝트 설정도 아직 템플릿 잔재가 많다. companyName: DefaultCompany, applicationIdentifier 의 Unity template 패키지명, templatePackageId 등이 남아 있다. 왜 문제인가 하면, Android/iOS 빌드 식별자와 서비스 연동, 저장 경로, 클라우드 설정에서 나중에 이름 변경 비용이 커지기 때문이다. 초기 단계에서 바로 정리하면 10분 작업이지만, 빌드 파이프라인 이후에는 회귀 확인까지 필요해진다.

Unity/C# 관점에서는 Input System을 도입한 점은 좋다. 다만 ProjectSettings/InputManager.asset 도 그대로 커밋되어 있어 팀 기준이 모호하다. 개선 방향은 명확하다. 신규 Input System을 표준으로 삼을지, 레거시 입력을 유지할지 문서와 코드에서 하나로 고정해야 한다. 네트워킹 코드는 아직 없으므로 권한 모델, RPC, 동기화 비용 평가는 해당 없음이다.

3. 진행도 평가

진행도는 약 15%로 본다. Unity 프로젝트 생성, URP 설정, 입력 액션 파일, 문서 초안까지는 준비됐지만 아직 “플레이 가능한 핵심 루프”가 확인되지 않는다. 현재 상태는 완성품의 기반 공사이지, 게임 시스템 구현 단계는 아니다.

첫 커밋으로는 정상적인 출발이다. 다만 커밋 메시지 추가 : 초기 유니티 프로젝트 는 변경 범위를 충분히 설명하지 못한다. 앞으로는 init unity urp project, add player input scaffold 처럼 빌드 설정·입력·씬·문서를 분리해 커밋하는 편이 추적과 리뷰에 유리하다.

4. 다음 권장사항

• DefaultVolumeProfile.asset 에 남은 테스트·템플릿 컴포넌트를 제거하고 실제 사용할 후처리만 남겨야 한다.
• PlayerController.cs 를 InputSystem_Actions 와 직접 연결해 이동·상호작용 입력 흐름을 검증해야 한다.
• ProjectSettings.asset 의 회사명, 번들 ID, 템플릿 식별자를 프로젝트 기준으로 정리해야 한다.
• SampleScene 에서 최소 플레이 루프를 구현해 실행하면 무엇을 하는 게임인지 바로 보이게 해야 한다.
• 기술 문서에 씬 구조, 입력 액션, 주요 스크립트 책임을 표로 정리해야 한다.

5. 문서화 상태

design 점수는 5점이다. 기획·컨셉 문서가 존재한다는 점은 좋지만, 코어 루프와 플레이어 경험 목표가 테스트 가능한 구조로 충분히 쪼개졌는지는 아직 부족하다.

technical 점수는 1점이다. Unity 버전과 패키지 구조는 repo 자체로 보이지만, 아키텍처 개요, 씬 전환, 입력 처리, 빌드 절차를 신규 참여자가 문서만 보고 이해하기 어렵다.

spec 점수는 3점이다. 사양서 성격의 문서가 일부 있는 것으로 보이나, 입력-상태-결과 매핑, 레벨 구성, 실패 조건, 밸런싱 수치가 체크리스트로 쓰일 수준은 아니다. 다음 단계에서 기능 구현보다 먼저 최소 사양 테이블을 잡아야 구현 흔들림이 줄어든다.

6. Backlog

• SampleScene 중심 구조가 남아 있다. 실제 게임 씬, 부트스트랩, 플레이 루프 씬을 분리하지 않으면 구조 판단이 계속 늦어진다.
• 신규 Input System과 구 InputManager 가 함께 남아 있다. 입력 정책이 애매하면 컨트롤러 대응과 UI 입력 디버깅 비용이 커진다.
• 문서가 아직 아이디어와 초안 중심이다. 테스트 가능한 수치·상태·성공 조건을 보강해야 다음 리뷰에서 구현 완료 여부를 객관적으로 판단할 수 있다.