Rougelike-EndWalker — 로비·전투맵 연결 스냅샷

1. 주요 변경사항

• 로비 씬에 테마 선택 패널, 테마 버튼, 진입 버튼, 상호작용 오브젝트가 추가되었다. 플레이어가 로비에서 테마를 고르고 다음 흐름으로 넘어가는 골격이 생겼다는 점은 분명한 전진이다.
• Knight, Veteran, ClearPoint 프리팹이 추가되고 기존 씬 오브젝트 일부가 프리팹 인스턴스로 바뀌었다. 재사용 가능한 단위로 빼기 시작한 점은 좋다.
• CameraFollow, HudController, HpSliderView, StageClearPopup 등 뷰 계층 기능이 늘었다. 카메라 추적, HP 표시, 스테이지 클리어 흐름을 붙이려는 의도가 보인다.
• TemaUse/temas.json이 추가되어 테마 정보를 데이터로 다루려는 방향이 생겼다. 다만 실제 UI는 아직 씬 직렬화와 하드코딩 참조에 강하게 묶여 있다.

2. 코드 품질 리뷰

이번 변경은 “플레이 가능한 흐름”을 만들기 위한 씬 작업량이 많다. 기능 축으로는 로비 → 테마 선택 → 전투맵 → 클리어 팝업의 뼈대가 생겼으므로 방향은 맞다. 그러나 구현 품질 측면에서는 Unity 씬 직렬화에 너무 많은 책임이 몰려 있다. 버튼, 패널, 텍스트, 이미지 참조가 씬에 직접 박혀 있어 프리팹 재사용·리뷰·충돌 해결이 어렵다. 특히 테마 버튼은 _data.id와 이미지가 씬에 직접 들어가 있어 temas.json을 추가한 장점이 아직 코드 구조로 이어지지 않았다.

더 위험한 신호는 UI 루트와 입력 경로의 신뢰성이 낮다는 점이다. diff에 다음과 같은 설정이 보인다.

m_LocalScale: {x: 0, y: 0, z: 0}
m_IsActive: 0
m_OnClick: []

Canvas 루트 스케일 0, 비활성 EventSystem, 비어 있는 Button OnClick은 런타임에서 “화면은 있는데 클릭이 안 됨” 또는 “팝업이 보이지 않음”으로 드러날 가능성이 높다. 스크립트에서 동적으로 보정한다면 그 코드가 명확해야 하지만, 현재 스냅샷만으로는 그 계약이 보이지 않는다. 개선하려면 UI는 프리팹으로 묶고, Awake/Start에서 필수 참조 검증을 수행하며, 버튼 이벤트는 코드에서 등록하더라도 누락 시 Debug.LogError로 즉시 드러나게 해야 한다.

네트워킹 코드는 이번 범위에서 확인되지 않으므로 해당 없음이다. 다만 싱글턴성 GameSession 이동과 씬 전환 로직이 늘고 있으므로, 이후 멀티플레이를 붙일 계획이라면 지금부터 “씬 상태의 주인”을 분리해 두는 편이 좋다.

3. 진행도 평가

이전 대비 기능 진척은 있다. 로비 상호작용, 테마 선택, 플레이어 프리팹화, 카메라 추적, 전투맵 클리어 흐름이 한 번에 들어왔다. 스캐폴드 단계를 지나 핵심 루프를 연결하는 단계로 진입했다고 볼 수 있다.

다만 현재 완성도는 아직 30%대 중반으로 보는 것이 타당하다. 이유는 단순하다. 동작할 것 같은 씬 오브젝트는 많지만, 재현 가능한 검증 흔적과 문서화된 사양이 없다. 지금은 “붙였다”와 “동작한다” 사이의 간극이 크다. 이 간극을 테스트와 QA 체크리스트로 좁히지 않으면 다음 변경부터 회귀 비용이 급격히 오른다.

4. 다음 권장사항

• 씬 전환과 스테이지 클리어 UI를 실제 입력 경로로 검증해야 한다. 로비 진입, 테마 선택, 전투맵 클리어, NodeSelect 복귀까지 한 번의 수동 QA 시나리오로 고정하는 것이 우선이다.
• Canvas와 EventSystem 설정을 정리해야 한다. 루트 스케일 0, 비활성 EventSystem, 중복 Canvas는 입력 문제를 숨기는 대표 원인이다.
• 테마 선택 UI는 temas.json 기준으로 생성해야 한다. 씬에 버튼을 늘려 붙이는 방식은 테마가 늘어나는 순간 유지보수 비용이 커진다.
• CameraFollow는 대상 누락 시 조용히 실패하지 않게 만들어야 한다. 명시 참조 또는 태그 기반 탐색 후 실패 로그를 남기는 구조가 필요하다.
• 플레이모드 테스트와 체크리스트를 추가해야 한다. 지금부터는 “실행해 봄”이 아니라 “같은 절차로 재현됨”이 기준이어야 한다.

5. 문서화 상태

design 점수는 4점이다. 게임 콘셉트와 테마 방향은 일부 존재하는 것으로 보이나, 이번 커밋에서 디자인 문서 갱신은 확인되지 않는다. 테마가 실제 데이터로 추가된 만큼 각 테마의 플레이 경험 목표와 차별점이 문서에 같이 따라와야 한다.

technical 점수는 2점이다. App, Core, Presenter, View로 나누려는 구조는 보이지만, 씬 전환, 세션, UI Presenter, View의 책임 경계가 문서화되어 있지 않다. 신규 인원이 문서만 보고 구조를 이해하기 어렵다.

spec 점수는 3점이다. temas.json 같은 데이터 파일은 생겼지만 스키마, 필수 필드, 씬별 입력·출력, 클리어 조건, 보상 규칙이 사양서 수준으로 정리되어 있지 않다. 테스트 체크리스트로 쓰기에는 아직 부족하다.

6. Backlog

• 테스트 코드·플레이모드 검증 절차 부재는 계속 남아 있다. 이번 변경처럼 씬 연결이 늘어난 시점에서는 가장 먼저 갚아야 할 부채다.
• 확률 노드 가중치와 BO 쿨다운 2 스테이지의 근거 수치는 아직 확인되지 않는다. 밸런싱 값은 감각이 아니라 기준 수치로 관리해야 한다.
• 사서·기록자·최종 보스 등 핵심 인물 특성과 밸런싱 수치도 문서상 해결 근거가 없다. 핵심 캐릭터는 기획 리스크가 크므로 뒤로 미루면 전체 루프가 흔들린다.
• Tema/TemaUse 명명은 오타로 보이며 코드와 리소스 경로에 확산되고 있다. 지금 고치지 않으면 나중에는 마이그레이션 비용이 커진다.
• README의 placeholder와 작성자 표기 혼용은 해결 근거가 없다. 제출물 신뢰도를 떨어뜨리는 낮은 우선순위 문서 부채로 유지한다.