맵 생성/미션 진입 최적화에서 유지한 기준 (체감 중심 재배치)
이번 최적화는 "무엇을 덜 만들까"보다 "무엇을 언제 계산해야 플레이어가 덜 끊기게 느끼는가"를 기준으로 진행했습니다. 이 글은 맵 생성/미션 진입 최적화 과정에서 제가 유지한 설계 기준과 판단 순서를 정리한 문서입니다.
왜 평균 FPS보다 전환 경계를 먼저 봤는가
이번 작업에서 가장 먼저 기준으로 둔 것은 평균 성능이 아니라 포탈 오픈 전후 1~2초 구간의 체감 안정성이었습니다. 평균 프레임이 올라가더라도 포탈이 열리기 직전 hitch가 남아 있으면 플레이어 입장에서는 "최적화가 됐다"고 느끼기 어렵기 때문입니다.
그래서 성능 판단도 전체 평균값보다, 전환 경계 구간의 프레임타임 변동성과 순간 스파이크를 더 중요하게 봤습니다. 이번에 허브 콘솔에 프레임 안정성 지표를 추가한 이유도 같은 맥락입니다.
병목을 없애는 게 아니라, 병목이 이동하도록 만든다
이번 최적화에서 확인한 중요한 포인트는, 한 병목을 줄이면 다음 병목이 더 잘 보이기 시작한다는 점이었습니다. 이걸 "최적화했는데 왜 또 느리냐"로 보지 않고, 다음 레이어가 드러난 것으로 해석하는 방식으로 접근했습니다.
최적화는 일회성 수정이 아니라, 계층적으로 병목을 이동시키면서 전체 흐름을 정리하는 과정으로 봅니다. 이번 빌드도 그 기준으로 pre-open 병목을 먼저 줄이고, 이후 단계 병목을 분리해서 보이게 만드는 쪽으로 진행했습니다.
기능 삭제보다 타이밍 재배치를 우선한 이유
이번 최적화의 핵심은 기능을 지우는 것이 아니라 수행 시점을 재배치하는 것이었습니다. 월드 생성에서 필요한 기능 자체(바이옴 생성, RoadMask, 지역 처리, 크리처 스폰 기반 등)는 유지하되, pre-open 단계에 몰려 있던 작업을 post-ready로 넘기거나 지연 가능하게 만들었습니다.
- 오픈 전에는 코어 플레이 가능 상태에 필요한 최소 집합만 확보
- 정밀 계산은 후속 단계에서 회수 (예: 전체 정밀 마스크/원거리 처리)
- 정확 계산과 근사 계산을 단계적으로 분리해 체감과 정합성 균형 유지
이 방식은 절차 생성, 멀티플레이, 연출이 동시에 얽힌 프로젝트에서 품질을 크게 희생하지 않고도 체감 안정성을 개선하기 좋은 전략입니다.
코어 우선 / 후속 스트리밍 구조로 바꾼 의도
이번 구조 재배치의 중심은 "포탈이 열릴 때 플레이 가능한가"와 "월드가 완전히 다 만들어졌는가"를 같은 기준으로 보지 않는 것입니다. 즉, CoreGameplayReady와 WorldReady를 체감 관점에서 분리해 다루는 방향을 더 강화했습니다.
오픈 전 (Core 우선)
- 플레이 시작에 필요한 지형/동선/핵심 상태
- 포탈 커밋과 진입 정합성
- 미션 시작 직후 체감 안정성
오픈 후 (후속 처리)
- 원거리/장식/지역 후처리
- 비코어 경로 품질 보강
- 추가 스폰/풍성함 회복
이 구조를 통해 포탈 오픈 지연을 줄이면서도, 월드 전체 품질을 포기하지 않고 단계적으로 회수하는 방향으로 정리했습니다.
경로 생성에서 알고리즘보다 목적 적합성을 우선한 이유
경로 생성 개선에서는 "정답 알고리즘"을 하나 고정하기보다, 프로젝트 목적에 맞는 조합을 선택하는 쪽으로 판단했습니다. 월드 생성용 경로는 런타임 네비게이션과 목적이 다르기 때문에, 절대 최적해보다 생성 속도/결정론/형태 품질 균형이 더 중요했습니다.
- 코어 경로는 정밀 탐색으로 안정성 확보
- 비코어 경로는 생성형 fallback + shaping으로 비용 절감
- 다단 fallback으로 품질과 안정성 모두 유지
- 탐색 범위 제한으로 비용을 줄이고, 시각적 자연스러움은 후처리로 보완
결과적으로 이 방식은 "멋진 알고리즘 적용"보다 현재 프로젝트의 컨셉과 요구에 맞는 해법을 고르는 데 더 잘 맞았습니다.
관측 도구를 기능과 같은 수준으로 다룬 이유
이번 세션에서 진행률 표시, 경로해결 통계, 프레임 안정성 지표, 허브 콘솔 단계 표시를 함께 강화한 이유는 단순 디버그 편의가 아닙니다. 절차 생성과 전환 연출처럼 재현 조건이 복잡한 시스템에서는 문제를 고치는 코드와 문제를 보이게 만드는 코드가 거의 같은 수준으로 중요하기 때문입니다.
계측이 없으면 최적화는 감에 의존하게 되고, 같은 문제를 여러 번 다시 확인하게 됩니다. 그래서 이번 작업에서는 런타임 최적화와 함께 관측 가능성도 같이 끌어올리는 방향을 유지했습니다.
파라미터 노출을 ‘실험 시스템’으로 쓰는 이유
탐사형 월드 구조, 경로 볼륨, 분포 밀도, 지연 처리 타이밍, 프레임 예산 같은 값을 파라미터로 계속 노출한 이유는 단순히 인스펙터에서 만지기 편하게 하려는 목적이 아닙니다. 핵심은 코드 수정 없이 설계 가설을 빠르게 검증하는 실험 인터페이스를 만드는 것입니다.
이번 작업에서도 구조는 유지한 채 볼륨/밀도/지연 강도만 조절할 수 있게 정리하면서, 탐사형 컨셉을 깨지 않고 빠른 비교 실험이 가능하도록 했습니다.
개발자 작업성도 품질의 일부로 본 이유
인스펙터 정리, 조건부 비활성화, 레거시/현행 옵션 분리 같은 작업은 미관 개선이 아니라 개발 속도와 안정성 개선에 가깝습니다. 옵션 수가 많은 시스템일수록 실수 방지와 인지 부하 감소가 장기적인 품질에 직접 영향을 주기 때문입니다.
- 현재 모드에서 유효한 옵션만 우선 보이게 하기
- 실험용/레거시 옵션을 분리해 오조작 줄이기
- 튜닝 루프에서 필요한 값 접근 속도 높이기
이번 작업에서 내가 정리한 기준 (한 문장)
플레이어 체감과 컨셉 일관성을 최우선으로 두고, 성능 문제는 기능 제거보다 파이프라인 재배치·계층화·가시화·툴링 개선으로 해결합니다.
다음 최적화도 같은 기준으로 진행하되, 이번 빌드에서 줄어든 pre-open 병목 이후에 드러나는 후속 단계 병목을 순서대로 정리할 예정입니다.