[TIL] 2026-07-21 — 로비에서 다음 맵을 미리 로드했더니 게임 입장이 막혔다
목차
증상
로비에서 스테이지를 고르고 시작을 누르면 게임 맵으로 넘어가야 하는데, 로딩 화면에서 멈췄다. 호스트가 먼저 이상해지고, 클라이언트는 그 호스트를 기다리다 같이 멈췄다. 어제까지 잘 되던 흐름이라 “뭘 건드렸지” 싶었는데, 범인은 바로 전날 내가 넣은 최적화였다.
내가 넣은 최적화
로비는 방장이 준비되기를 기다리는 시간이 있다. 그 대기 시간이 아까워서, 다음에 갈 스테이지 맵을 백그라운드로 미리 메모리에 올려두면 실제 진입할 때 로딩이 덜 걸리겠다고 생각했다. 그래서 로비 게임모드와 스테이지 선택 지점에서 선택된 맵을 미리 불러오게 했다.
1
2
// 로비 대기 시간을 이용해 스테이지 맵을 백그라운드로 미리 로드
LoadPackageAsync(MapPath, ...);
일반적인 에셋 프리로드라면 맞는 접근이다. 텍스처나 머티리얼을 미리 올려두면 실제로 히치가 줄어든다. 문제는 내가 미리 올린 게 텍스처가 아니라 맵(레벨) 이었다는 점이다.
왜 하필 맵만 문제였나
맵 패키지는 다른 에셋과 취급이 다르다. 게임을 시작하면 서버가 ServerTravel로 그 맵을 여는데, 트래블은 내부적으로 같은 맵 패키지를 LoadMap으로 다시 연다. 즉 내가 로비에서 미리 올려둔 그 레벨(UWorld)을, 곧이어 트래블이 “이 맵을 지금부터 월드로 쓰겠다”며 또 열려고 하는 것이다.
같은 패키지를 두고 프리로드가 만들어 둔 월드와 트래블이 열려는 월드가 부딪혔다. 텍스처였다면 “이미 올라와 있네, 재활용” 하고 넘어갔을 텐데, 맵은 트래블 경로의 주인공이라 이미 다른 목적으로 올라와 있는 상태가 그대로 충돌이 됐다.
한 줄로 정리하면 — 미리 올려둬서 이득을 볼 대상은 “맵이 쓰는 에셋”이지, “맵 그 자체”가 아니었다.
증상이 비대칭이었던 이유
디버깅에서 제일 헷갈렸던 게 “왜 호스트만 먼저 죽고 클라는 멀쩡히 기다리다 멈추냐”였다. 답은 프리로드가 호스트에서만 돈다는 데 있었다.
- 프리로드는 로비 게임모드(
InitGameState)와 스테이지 선택에서 호출된다 → 둘 다 서버 권위 코드라 호스트에서만 실행된다. - 그래서 트래블 충돌도 호스트에서 먼저 터진다(로딩 중 이탈).
- 클라이언트는 잘못한 게 없다. 그냥 호스트가 맵을 열고 자기를 불러주기를 기다리는데, 그 호스트가 로딩에서 자빠졌으니 하염없이 로딩 화면에 남는다.
“클라가 멈췄다”는 표면 증상만 보면 클라 네트워크를 의심하게 되는데, 실제 원인은 호스트 한쪽에만 있었다. 증상이 나타나는 곳과 원인이 있는 곳이 다른, 전형적인 함정이었다.
수정
프리로드 호출 두 곳을 지우고, 함수 자체는 조기 반환으로 껐다. 왜 껐는지와 대안을 주석에 남겨서, 나중에 누가 “이 최적화 왜 안 써?” 하고 되살리지 않게 했다.
1
2
3
4
5
6
7
8
void UTCSessionFlow::PreloadSelectedStageMapAsync()
{
// 맵 패키지는 곧이어 ServerTravel 의 LoadMap 이 같은 패키지를 다시 여는 대상이라,
// 미리 올려둔 UWorld 가 트래블 경로와 충돌한다 (호스트만 프리로드 → 호스트 쪽에서 먼저 터짐).
// 히치 완화가 다시 필요하면 맵이 아니라 '그 맵이 쓰는 머티리얼/텍스처'만 개별 프리로드하거나
// PSO 사전 워밍업으로 접근할 것.
return;
}
로딩 히치를 줄이겠다는 목적 자체가 틀린 건 아니다. 다만 대상을 잘못 골랐다. 다시 손댄다면 맵 통째가 아니라 그 맵이 쓰는 에셋만 개별로 데우거나, 셰이더 쪽(PSO) 워밍업으로 접근하는 게 맞다.
정리
- 맵(레벨) 패키지는 일반 에셋처럼 미리 로드하면 안 된다. 곧이어 트래블이 같은 패키지를 다시 여니까 충돌한다.
- 최적화가 서버에서만 돌면, 그게 깨졌을 때 증상은 클라에서 보여도 원인은 호스트에 있다. 비대칭 증상을 보면 “이 코드는 어느 쪽에서 도는가”부터 따져야 한다.
- 프리로드로 이득을 볼 건 “맵이 끌고 오는 무거운 에셋”이지 “맵 자체”가 아니었다. 좋은 아이디어라도 적용 대상을 틀리면 기능을 통째로 막을 수 있다.