📘TIL - 메인메뉴 이어하기·불러오기 & 조작키 안내 UI

목차

1. 메인메뉴 "이어하기" — 최근 슬롯 자동 선택과 서버 권위 로드 흐름
2. 불러오기 패널 — 모닥불 저장 슬롯 위젯 재사용의 제약 3가지
3. 퀘스트 진행 저장/복원 — 로드할 때 완료 알림이 다시 우르르 뜨는 문제
4. 저장 시점 "추적 퀘스트" 표시 — HUD의 로컬 상태는 세이브에 없다
5. 메인메뉴에서 패널을 닫으면 커서가 죽는 문제 — 무조건 GameOnly 복원의 함정
6. 조작키 안내 위젯 — 일시정지 메뉴에서 "패널 교체"로 여닫기
7. 소프트 레퍼런스만 있는 UI는 패키징에서 통째로 빠진다
8. 일시정지 "메인 메뉴로"가 조용히 무시된 이유 — 세션 상태머신의 전환 화이트리스트

---

1. 메인메뉴 "이어하기" — 최근 슬롯 자동 선택과 서버 권위 로드 흐름

목표

메인메뉴에서 회색으로 죽어 있던(SetIsEnabled(false) + TODO 주석) "이어하기"·"불러오기" 버튼을 실제로 동작하게 한다. "이어하기"는 슬롯 선택 없이 가장 최근에 저장한 슬롯을 즉시 로드해야 한다.

구현 — "가장 최근"의 판정을 타임스탬프 문자열 비교로

세이브 메타에 이미 있던 SaveTimestamp가 "%Y-%m-%d %H:%M" 형식이라, 파싱 없이 문자열 비교(>)만으로 시간순 정렬이 성립한다(자릿수 고정 + 큰 단위부터 나열되는 형식이라 사전순 == 시간순). GetMostRecentSaveSlotIndex()는 존재하는 슬롯을 순회하며 이 비교 하나로 최신 슬롯을 고른다.

// SaveTimestamp는 "%Y-%m-%d %H:%M" 형식이라 문자열 비교만으로 시간순 정렬이 성립한다.
if (BestSlot == INDEX_NONE || Save->SaveTimestamp > BestTimestamp) { ... }

버튼 → 로드까지의 흐름은 신규 게임과 동일한 서버 권위 경로로 통일했다:

ContinueButton 클릭 → PC->RequestContinueGame() → Server_RequestContinueGame (RPC)
→ GameMode::HandleContinueGame (IsRequestorHost 검사)
→ SaveSubsystem::LoadFromSlot() 성공 시 → GameState::TransitionTo(InGame)

버튼 활성화 조건도 HasSaveGame() 결과(bSaveDataExists)로 바꿔, 세이브가 없으면 이어하기/불러오기가 자연스럽게 비활성화된다.

배운 점

정렬 가능한 문자열 포맷은 그 자체로 인덱스다. FDateTime 재파싱이나 별도 필드 추가 없이, 저장 형식이 "고정 자릿수 + 큰 단위 우선"이기만 하면 문자열 비교로 최신 판정이 끝난다 — 단, 이 성질은 포맷에 의존하므로 포맷을 바꾸는 순간 같이 깨진다는 걸 주석으로 남겨둬야 한다.
메뉴 기능도 게임플레이와 같은 권위 경로를 태운다. "메뉴 버튼인데 뭐" 하고 클라이언트에서 직접 로드하지 않고 Server RPC → GameMode 핸들러(호스트 검사 포함) 구조를 재사용하면, 이후 멀티플레이 확장 시 메뉴 계열만 따로 고칠 일이 없다.

---

2. 불러오기 패널 — 모닥불 저장 슬롯 위젯 재사용의 제약 3가지

목표

"불러오기" 화면(WBP_LoadGame + URetrieveLoadGameWidget)의 슬롯 리스트를, 모닥불 저장 탭에서 이미 쓰고 있는 WBP_SaveSlotEntry를 에셋 수정 없이 그대로 재사용해서 만든다(디자인 일관성 + 중복 위젯 방지).

원인 — 공유 WBP를 "그대로" 재사용하는 걸 막는 제약이 세 가지 있었음

1. OwnerMenu 타입 고정: WBP_SaveSlotEntry의 클릭 통지 대상인 OwnerMenu 변수가 WBP_BonfireMenu_C 전용 타입으로 선언돼 있어, 다른 메뉴가 자신을 Owner로 등록할 수 없다.
2. SlotIndex 인스턴스 편집 불가: 엔트리의 슬롯 번호 변수가 Instance Editable이 아니어서, 디자이너에서 5개를 배치해도 각각에 0~4를 지정할 방법이 없다.
3. 엔트리에 없는 위젯: 썸네일 이미지·추적 퀘스트 텍스트처럼 불러오기 화면에만 필요한 요소가 엔트리 WBP에 없다.

해결 — 전부 "호스트 위젯의 C++"에서 흡수하고 공유 WBP는 건드리지 않음

1. OwnerMenu 경유를 포기하고, 엔트리 내부의 Button을 GetWidgetFromName으로 찾아 C++에서 직접 OnClicked/OnHovered를 바인딩했다 (HandleSlot0Clicked~HandleSlot4Clicked).
2. 슬롯 번호는 ScrollBox 내 배치 순서(ChildIndex)를 유일한 근거로 삼았다 — "0~4 순서로 배치할 것"이 WBP 쪽 계약이 된다는 걸 주석으로 명시.
3. 없는 위젯은 런타임에 WidgetTree->ConstructWidget으로 동적 주입했다(썸네일용 SizeBox+Image, Text_QuestName). 단 여기엔 함정이 있었다 — 부모가 CanvasPanel인 자리(우측 프리뷰의 퀘스트 텍스트)는 동적 생성 시 슬롯 설정 없이 (0,0)에 붙어 화면 좌상단에 떠버리므로, VerticalBox처럼 자동 배치되는 부모 아래에서만 동적 생성 폴백을 두고, CanvasPanel 자리는 WBP에 실제 배치된 위젯만 사용하도록 갈랐다.

부가로, 구형 세이브의 썸네일 PNG가 알파 0으로 저장돼 투명하게 보이는 문제는 디코딩 직후 픽셀 알파를 255로 강제하는 마이그레이션(DecodeThumbnail)으로 로드 시점에 흡수했고, 클릭 선택 하이라이트(골드 글로우)는 모닥불 메뉴와 동일 규칙으로 맞춰 BonfireMenuWidget과 RetrieveLoadGameWidget 양쪽에 같은 코드를 적용했다.

배운 점

공유 WBP 재사용의 진짜 비용은 "위젯을 그리는 것"이 아니라 "그 위젯의 암묵적 계약"에 있다. OwnerMenu 타입, 인스턴스 편집 불가 변수, 없는 서브위젯 — 셋 다 WBP를 고치면 한 줄이지만, 그러면 이미 쓰는 화면(모닥불)에 회귀 위험이 생긴다. 호스트 쪽 C++에서 흡수하는 방식은 코드가 늘어나는 대신 공유 에셋의 기존 사용처를 완전히 보존한다.
동적 위젯 주입은 부모 패널 타입을 먼저 본다. VerticalBox/HorizontalBox는 AddChild만으로 자연스럽게 배치되지만 CanvasPanel은 슬롯(앵커/오프셋)을 직접 설정하지 않으면 (0,0)에 뜬다 — "폴백으로 동적 생성"이 항상 안전한 게 아니라, 부모가 자동 배치형일 때만 안전하다.

---

3. 퀘스트 진행 저장/복원 — 로드할 때 완료 알림이 다시 우르르 뜨는 문제

목표

세이브에 퀘스트 진행(완료 스텝 목록·추적 스텝·대화 분기 선택 기록)을 포함시키고, 불러오기 시 그대로 복원한다. 이때 이미 완료했던 스텝들의 "퀘스트 완료!" 알림이 로드 직후 연쇄로 재생되면 안 된다.

원인 — 복원을 기존 CompleteStep 경로로 태우면 알림 시스템이 전부 "새 완료"로 인식함

UQuestBranchComponent::CompleteStep은 선행 조건 검사와 알림 브로드캐스트가 묶여 있는 게임플레이용 진입점이다. 저장된 스텝 N개를 이 경로로 하나씩 재완료시키면 알림 서브시스템과 복제 클라이언트의 OnRep_CompletedSteps가 전부 "방금 완료됨"으로 판정한다.

해결 — 알림 없는 전용 복원 API + 베이스라인 재시딩 + 갱신 신호 1회

복원 전용 API(MakeQuestSaveData/ApplyQuestSaveData)를 분리해 상태를 통째로 덮어쓰되, 알림이 기준으로 삼는 베이스라인들을 복원된 상태로 재시딩했다:

CompletedSteps = InCompletedSteps;
// OnRep_CompletedSteps가 복제 클라이언트에서 이 스텝들을 "새로 완료됨"으로 재알림하지 않도록 기준선을 맞춘다.
LastSeenCompletedSteps = CompletedSteps;

호출부(SaveSubsystem)는 복원 후 QuestNotificationSubsystem->ResetBaseline()으로 알림 서브시스템의 기준선도 맞춘 뒤, UI(트래커/퀘스트로그)에는 갱신 신호(Channel_Quest_StepChanged)를 딱 한 번만 브로드캐스트한다. "개별 이벤트 재생"과 "최종 상태 통지"를 분리한 것.

배운 점

상태 복원은 상태 전이가 아니다. 게임플레이 진입점(CompleteStep)은 "전이"를 전제로 알림·검증이 묶여 있어서, 로드 복원에 재사용하면 부작용(알림 연쇄)이 따라온다. 복원 전용 API를 분리하고, 그 API가 생략한 책임(알림 베이스라인, UI 갱신)을 호출부 계약으로 문서화하는 편이 명확했다.
"알림 안 함"만으로는 부족하고, 알림 시스템의 '기준선'까지 옮겨야 한다. 복원 시점에 조용히 넘어가도 베이스라인이 옛 상태면 다음 정상 완료 때 밀린 차이가 한꺼번에 알림으로 터진다 — 상태를 덮어쓰는 쪽이 비교 기준(LastSeen, Baseline)도 함께 덮어쓸 책임이 있다.

---

4. 저장 시점 "추적 퀘스트" 표시 — HUD의 로컬 상태는 세이브에 없다

목표

저장 슬롯 리스트와 불러오기 프리뷰에 "이 세이브가 어느 퀘스트를 진행 중이었는지"(퀘스트명 + 첫 미완료 목표 문구)를 보여준다.

원인 — "지금 어떤 퀘스트를 추적 중인가"는 HUD 위젯의 로컬 상태라 세이브 파이프라인에서 접근 불가

플레이어가 명시적으로 추적을 바꿨는지는 QuestTrackerViewModel의 로컬 상태로만 존재하고, 세이브가 접근할 수 있는 GameState/컴포넌트에는 없다. 그렇다고 세이브를 위해 HUD 상태를 GameState로 끌어올리는 건 배보다 배꼽이 커진다.

해결 — 저장 시점에 HUD 트래커와 동일한 "기본 선정 로직"으로 재계산해서 문자열로 박제

QuestTrackerViewModel::Recompute의 기본 선정 규칙(DisplayOrder 정렬 → 잠금 해제됐고 미완료인 퀘스트 중 메인 우선, 없으면 아무거나)을 저장 시점에 그대로 다시 돌려서, 결과를 TrackedQuestName/TrackedQuestObjective 표시용 문자열로 세이브 메타에 저장했다. UI(모닥불 슬롯·불러오기 리스트·프리뷰)는 이 문자열을 그대로 뿌리기만 한다.

배운 점

세이브 메타에는 "재계산 가능한 참조"보다 "박제된 표시 문자열"이 맞을 때가 있다. 슬롯 리스트는 로드 전에 표시돼야 하므로 어차피 세이브 파일 안에서 자급자족해야 한다 — 태그를 저장하고 표시 시점에 DataTable을 다시 조회하는 것보다, 저장 시점에 확정된 문자열을 넣는 쪽이 로드 전 UI에 안전하다(테이블이 바뀌어도 "그때 그 상태"를 보여준다).
원본 상태에 접근할 수 없으면 "같은 로직으로 재계산"이 차선이고, 그 사실을 주석으로 남긴다. 명시적 추적 변경까지 반영하지 못하는 근사치라는 한계는, 코드만 봐서는 안 보이므로 "HUD 로컬 상태라 세이브에 없음, 기본값 기준으로 계산"을 주석으로 박아뒀다.

---

5. 메인메뉴에서 패널을 닫으면 커서가 죽는 문제 — 무조건 GameOnly 복원의 함정

목표

메인메뉴에서 "불러오기"나 "설정" 패널을 열었다 닫아도 메뉴가 계속 조작 가능해야 한다.

원인 — 패널 닫기 공통 경로가 입력 모드를 무조건 GameOnly로 되돌리고 있었음

RemoveActivePanelImmediately()가 패널을 닫은 뒤 FInputModeGameOnly + 커서 숨김을 세션 상태와 무관하게 강제했다. 인게임에서 인벤토리를 닫을 때는 올바른 동작이지만, 메인메뉴(UIOnly + 커서)에서 불러오기/설정을 닫으면 커서와 UI 입력이 죽어 메뉴 전체가 클릭 불가 상태가 됐다 — 이 공통 경로를 쓰는 패널이 메인메뉴에서도 열리기 시작하면서 잠복해 있던 전제가 깨진 것.

해결 — 닫은 뒤의 입력 모드를 "현재 세션 상태"로 결정

if (SessionState == MainMenu || SessionState == Result)
{
    UpdateInputMode(SessionState);   // UIOnly + 커서 유지
}
else
{
    SetInputMode(FInputModeGameOnly()); // 인게임만 기존대로
    bShowMouseCursor = false;
}

배운 점

"닫은 뒤 상태"는 상수가 아니라 문맥이다. 패널 닫기 같은 공통 경로에 하드코딩된 복원 값(GameOnly)은 그 경로가 처음 쓰이던 문맥(인게임)의 전제일 뿐이다 — 같은 패널 시스템을 새 문맥(메인메뉴)에서 재사용하는 순간, 복원 로직은 "원래 상태로"가 아니라 "지금 있어야 할 상태로"를 물어야 한다. 세션 상태머신이 이미 있으니 그걸 단일 진실로 쓰면 끝이었다.

---

6. 조작키 안내 위젯 — 일시정지 메뉴에서 "패널 교체"로 여닫기

목표

일시정지 메뉴의 "조작키 안내" 버튼으로 키보드/마우스 조작법 화면(WBP_ControlsGuide)을 열고, ESC로 자연스럽게 닫히게 한다.

구현 — 전용 C++ 클래스 없이 기존 패널 인프라에 그대로 얹기

• 위젯 자체는 순수 WBP(부모: RetrieveGamePanelWidget)로, 파치먼트 박스 텍스처 + 마우스 좌/중/우 입력 아이콘 + 키 행(KeyRows) 구성. 표시 전용이라 C++ 베이스를 새로 만들 이유가 없었다.
• 여는 쪽은 OpenControlsGuide() 하나 — OpenExclusivePanel(PanelClass, EKeys::Escape)을 그대로 재사용한다. 배타 패널 모델이라 일시정지 패널이 자동으로 조작키 안내로 "교체"되고, ESC(ToggleKey)로 닫힌다. 스택/네비게이션 코드를 새로 만들지 않았다.
• 일시정지 메뉴 쪽은 C++ 베이스(URetrievePauseMenuWidget)가 CommandsButton을 BindWidgetOptional로 집어 PC->OpenControlsGuide()에 배선한다 — WBP는 정해진 이름의 버튼만 배치하면 되고 그래프 배선이 필요 없다.
• 클래스 참조는 TSoftClassPtr + 생성자 기본 경로로 두되, BP 오버라이드가 None으로 남는 사고에 대비해 LoadClass 폴백을 넣었다(7번 항목과 세트).

배운 점

"화면 하나 추가"가 요구하는 코드는 화면 수에 비례하지 않아야 한다. 배타 패널(OpenExclusivePanel) + ESC ToggleKey + BindWidgetOptional 버튼 배선이라는 기존 규약에 얹으니, 새 화면의 비용이 "WBP 1개 + Open 함수 1개"로 끝났다. 반대로 말하면, 패널 인프라를 처음 만들 때 교체/닫기/입력 규약을 일반화해둔 것이 여기서 회수됐다.
표시 전용 위젯에 C++ 베이스를 만들지 않는 것도 설계 결정이다. 바인딩할 상태가 없는 정적 안내 화면은 WBP만으로 충분하고, C++ 클래스를 늘리지 않으면 리컴파일 없이 디자이너가 내용을 계속 다듬을 수 있다.

---

7. 소프트 레퍼런스만 있는 UI는 패키징에서 통째로 빠진다

목표

에디터에선 잘 열리던 설정창·일시정지 메뉴·조작키 안내가 Shipping 패키지에서 "버튼을 눌러도 조용히 아무 일도 안 일어나는" 문제를 막는다.

원인 — TSoftClassPtr/LoadClass 경로 문자열은 쿠커가 따라가지 못함

이 UI들은 전부 TSoftClassPtr(또는 경로 문자열 LoadClass)로만 참조된다 — 하드 레퍼런스 체인이 없으니 쿠커가 해당 폴더에 도달하지 못하고, 패키지에서 LoadSynchronous()가 null을 반환한다. 에러 팝업도 없이 함수가 조기 return하므로 증상이 "무반응"뿐이라는 게 악질이다. 이미 조준점 텍스처, 아이템 획득 토스트에서 두 번 겪은 것과 동일 패턴의 세 번째 재발이었다.

해결 — always-cook 등록 + 알려진 경로 폴백의 이중 방어

; DefaultGame.ini — 소프트 참조만 있는 UI 폴더를 명시적으로 쿠킹에 포함
+DirectoriesToAlwaysCook=(Path="/Game/Retrieve/UI/Interaction")
+DirectoriesToAlwaysCook=(Path="/Game/Retrieve/UI/Settings")
+DirectoriesToAlwaysCook=(Path="/Game/Retrieve/UI/Menu")

코드 쪽에도 PauseMenuClass/ControlsGuideClass가 비어 있으면(BP에 None 오버라이드가 남은 경우 등) 알려진 경로로 LoadClass 폴백을 태워, "프로퍼티 설정 실수"와 "쿠킹 누락"을 각각 다른 층에서 방어한다.

배운 점

TSoftClassPtr로 UI를 참조하는 순간, always-cook 등록까지가 한 세트다. 같은 원인으로 세 번째 당했다 — 이제 규칙화한다: 소프트 참조/경로 문자열 로드를 추가하는 커밋에는 반드시 DirectoriesToAlwaysCook 확인이 따라붙어야 하고, 증상은 항상 "패키지에서만 조용한 무반응"으로 나타난다는 걸 기억할 것.

---

8. 일시정지 "메인 메뉴로"가 조용히 무시된 이유 — 세션 상태머신의 전환 화이트리스트

목표

일시정지 메뉴의 "메인 메뉴로" 버튼이 아무 반응이 없는 문제를 해결한다. WBP 버튼 배선 문제로 보였지만 실제 원인은 전혀 다른 곳에 있었다.

원인 — 클릭 → RPC → GameMode까지 전부 정상인데, 상태머신이 마지막에 거부

배선을 의심하고 추적했지만 흐름은 완벽했다: MainMenuButton 클릭 → HandleMainMenuClicked → Server_RequestQuitToMenu → GameMode::HandleQuitToMenu → GameState::TransitionTo(MainMenu). 문제는 마지막 한 줄 — IsLegalTransition()이 전환 화이트리스트 방식인데, InGame에서 허용된 목적지가 Result뿐이었다. "메인 메뉴로 나가기"는 사망 화면(Result → MainMenu)만 상정하고 설계됐고, 일시정지 메뉴는 게임을 실제로 포즈하지 않아 세션 상태가 InGame인 채로 요청되므로 로그 한 줄 없이 return false로 무시됐다.

해결 — 화이트리스트에 한 줄 추가

case ERetrieveSessionState::InGame:
    // MainMenu 허용: 일시정지 메뉴의 "메인 메뉴로"(Server_RequestQuitToMenu)가 InGame 상태에서 호출된다.
    return To == ERetrieveSessionState::Result || To == ERetrieveSessionState::MainMenu;

전환만 허용되면 기존 HandleSessionStateChanged 경로가 패널 정리 → 위젯 스왑 → 입력모드 → 메뉴 카메라까지 알아서 처리하므로 수정은 이 한 줄이 전부였다.

배운 점

화이트리스트형 상태머신은 "거부"를 로그로 남겨야 한다. TransitionTo가 불법 전환을 조용히 false로 삼키는 바람에, 증상(버튼 무반응)에서 원인(상태머신 거부)까지 거리가 너무 멀었다 — UI 배선부터 RPC까지 전 구간을 거슬러 올라가야 했다. 거부 시 UE_LOG(Warning, "Illegal transition %s -> %s") 한 줄이 있었다면 로그 한 번에 끝났을 문제다.
새 UI 흐름을 추가할 때는 "그 흐름이 밟는 상태 전환"이 화이트리스트에 있는지 먼저 확인한다. 일시정지 메뉴라는 새 진입점이 기존에 없던 전환(InGame → MainMenu)을 요구하게 됐는데, 버튼·RPC·핸들러는 다 만들면서 상태머신 규칙 갱신만 빠졌다 — 상태머신이 있는 프로젝트에서 기능 추가 체크리스트에 "전환 규칙 갱신"을 포함해야 한다.

---

오늘의 핵심 요약

작업	핵심 문제	해결 원칙
이어하기	"가장 최근 슬롯" 판정	정렬 가능한 타임스탬프 포맷 → 문자열 비교, 로드는 서버 권위 경로로 통일
불러오기 패널	공유 슬롯 위젯의 암묵적 계약 3개(OwnerMenu 타입·SlotIndex 편집불가·없는 위젯)	전부 호스트 C++에서 흡수(직접 바인딩·ChildIndex·동적 주입), 공유 WBP 무수정
퀘스트 저장/복원	로드 시 완료 알림 연쇄 재생	복원 전용 API + 알림 베이스라인 재시딩 + 갱신 신호 1회
추적 퀘스트 표시	HUD 로컬 상태는 세이브에 없음	저장 시점에 동일 선정 로직으로 재계산해 표시 문자열로 박제
메뉴에서 패널 닫기	무조건 GameOnly 복원 → 메뉴 커서 사망	닫은 뒤 입력 모드를 세션 상태로 결정
조작키 안내	새 화면 추가 비용	배타 패널 인프라 재사용 — WBP 1개 + Open 함수 1개로 종결
패키징 무반응	소프트 참조만 있는 UI가 쿠킹 누락	always-cook 등록 + LoadClass 폴백 이중 방어 (동일 원인 3번째 재발 → 규칙화)
메인 메뉴로 버튼	상태머신이 InGame→MainMenu를 조용히 거부	화이트리스트 한 줄 추가, "거부는 로그를 남겨야 한다"는 교훈

공통 교훈: 오늘 하루는 "이미 있는 시스템에 새 진입점을 얹을 때 깨지는 전제들"의 하루였다.

1. 공통 경로의 하드코딩은 첫 사용처의 전제다. 패널 닫기의 GameOnly 복원(인게임 전제), 상태머신의 전환 목록(사망 화면 전제), 슬롯 엔트리의 OwnerMenu 타입(모닥불 전제) — 전부 처음 만들 땐 옳았지만, 메인메뉴/일시정지라는 새 문맥이 생기자 조용히 깨졌다. 재사용 전에 "이 값/규칙은 무엇을 전제로 하는가"를 물어야 한다.
2. 조용한 실패가 디버깅 비용의 대부분이다. 상태머신의 무언 거부, 패키지에서의 LoadSynchronous null, 길이 0 몽타주 — 오늘도 "에러 없이 아무 일도 안 일어나는" 증상이 가장 오래 걸렸다. 거부/실패 지점에 로그 한 줄 넣는 것이 최고의 투자다.
3. 상태를 복원하는 코드와 상태를 전이시키는 코드는 다른 API여야 한다. 퀘스트 복원을 CompleteStep에 태우지 않고 전용 API로 분리한 것처럼, "전이"에 묶인 부수효과(알림·검증)를 "복원"이 물려받으면 안 된다 — 대신 복원이 생략한 책임(베이스라인, UI 갱신)은 호출부 계약으로 명시한다.