게임 상태와 대사 불일치 진단하기: 재현 및 수정 체크리스트

무엇을 상태와 대사의 불일치로 볼 수 있는가?

기록된 월드 상태는 획득한 단서, 보유한 아이템, 완료한 행동, 커밋된 선택 등 플레이에 중요한 사실들에 대한 게임의 신뢰할 수 있는 최종 기록입니다. 대사는 게임이 이러한 사실들을 표현하는 한 가지 방법입니다. 대사가 다른 버전의 사실을 언급할 경우, 플레이어는 얻지 않은 정보를 얻거나, 실패한 행동이 성공했다고 믿거나, 이전에 했던 선택이 나중에 무시되는 상황을 겪게 될 수 있습니다.

이는 단순히 대사의 문체적 문제가 아니라, 플레이 가능한 상태의 결함입니다. 유용한 선례로 내러티브 디자이너 한나 니클린(Hannah Nicklin)의 *Mutazione* 개발 후기를 들 수 있습니다. 그녀는 이전 대화, 소지품 아이템, 정원 상태, 대화 중 설정된 변수 등에 따라 접근을 제어할 수 있는 플롯 라인에 대화를 배치하는 방식을 설명합니다. 이 사례는 대사의 가용성이 여러 명시적 조건에 어떻게 연결될 수 있는지를 보여주며, 모든 게임이 동일한 시스템을 갖춰야 한다고 주장하는 것은 아닙니다. [Nicklin의 *Mutazione* 디자인 사례](https://www.gamedeveloper.com/design/deep-dive-inside-the-narrative-design-and-multiple-middles-of-i-mutazione-i-)

NPC가 플레이어가 획득하지 않은 단서를 언급하는 경우

탐정은 찢어진 페리 티켓을 아직 찾지 못했지만, 항구 관리인은 "그 티켓은 폭풍우가 치던 밤에 누군가 떠났다는 걸 증명하지"라고 말합니다. 이 대사는 나중의 분기에서는 유효할 수 있거나, 이전 대화에서 잘못된 플래그를 설정했을 수도 있습니다. 플레이어의 관점에서 결과는 동일합니다. 게임이 증거에 도달하는 명확한 경로 없이 정보를 누설한 것입니다. 플레이어는 받지도 못한 티켓을 찾아 헤매거나, 특정 장면이나 상호작용이 건너뛰어졌다고 추측하거나, 수사 순서가 의미가 있는지 의심하게 될 수 있습니다.

이것은 정보의 순서 자체가 퍼즐의 일부인 미스터리 장르에서 특히 치명적입니다. 2026년 9월 플레이 가능한 추리 게임 프로토타입인 *The Interrogation of Adrian Gale*에 관한 arXiv 프리프린트에서는 조기 누설과 사실적 일관성을 추리 게임 진행의 주요 우려 사항으로 꼽고 있습니다. 이를 모든 게임에 적용되는 보편적인 척도나 확립된 규칙이 아니라, 한 연구에서의 저자들의 관심사와 연구 결과로 받아들여야 합니다. [Rahmati and Zhao, arXiv 프리프린트](https://arxiv.org/abs/2609.23043)

대사에서는 행동이 성공했다고 하지만 상태가 업데이트되지 않는 경우

페리 매표소에서 플레이어는 직원에게 황동 토큰을 건넵니다. 직원은 "여기 열쇠 있습니다. 기록 보관소가 열렸어요"라고 대답합니다. 하지만 인벤토리에 열쇠는 없고 기록 보관소 문은 여전히 잠겨 있습니다. 성공 대사가 게임에서 커밋되지 않은 거래를 알린 것입니다.

플레이어는 이러한 모순을 해결하기 위해 교환을 반복하거나, 직원을 다시 찾아가거나, 무관한 다른 경로를 시도할 수 있습니다. 아이템은 소모되었는데 보상이 추가되지 않았다면 플레이어는 필요한 자원을 잃은 셈이 됩니다. 두 변경 사항이 모두 발생하지 않았다면 상호작용 버튼이 고장 난 것처럼 보일 수 있습니다. 어느 쪽이든 텍스트는 약속을 했지만 플레이 가능한 상태는 이를 지키지 못한 것입니다.

이후의 대사가 이미 커밋된 선택을 무시하는 경우

플레이어가 항구 관리인에게 경고를 건네고, 확인하는 반응을 본 뒤 떠납니다. 나중에 관리인은 "페리가 위험하다는 말은 전혀 안 했잖아"라고 말합니다. 경고 선택지가 커밋되었다면, 이 나중 대사는 기억된 결정과 모순됩니다. 플레이어는 자신의 선택이 무의미한 껍데기뿐이었다고 결론짓거나, 잘못된 답변을 고른 것인지 의아해하거나, 게임이 이미 닫아버린 분기를 스토리가 다시 다루기를 기대할 수 있습니다.

이러한 실패는 동일한 원인을 공유할 수 있습니다. 대사와 게임플레이가 서로 다른 플래그, 서로 다른 저장 데이터 또는 상태 업데이트의 서로 다른 시점을 읽고 있는 것입니다. 또한 지나치게 광범위한 대화 게이트, 실패한 인벤토리 트랜잭션, 잘못된 선택 변수를 확인하는 후속 대사 등 별개의 버그로 인해 발생할 수도 있습니다. 텍스트 자체가 유일한 결함 요소라고 단정 짓기보다는 추적(trace)부터 시작하세요.

한정된 재현 및 수정 체크리스트

고정된 세이브 파일, 의도된 단일 경로, 한 번에 하나의 플랫폼 또는 빌드만 사용하세요. 다른 디자이너나 엔지니어가 추측에 의존하지 않고 시퀀스를 반복할 수 있도록 시작 조건을 기록하세요.

**테스트 전에 예상 상태를 작성하세요.** 단서 조기 누설 케이스의 경우 `ticket_found`가 false여야 하며 항구 관리인이 티켓을 언급해서는 안 된다고 명시합니다. 교환의 경우, 의도된 전후 인벤토리 상태와 기록 보관소가 열려야 하는지 여부를 명시합니다. 선택지의 경우, 커밋된 경고 값과 그것이 나중에 선택해야 할 응답을 명시합니다. 결함 보고서에는 프로젝트의 실제 변수명을 사용하세요.

**한 번의 실행마다 하나의 불일치만 재현하세요.** 기록된 세이브에서 시작하여 해당 대사에 도달하는 데 필요한 단계만 따르고, 대사, 인벤토리, 관련 플래그 및 상호작용 결과를 캡처합니다. 불러오기, 씬 재진입, 또는 다른 캐릭터와의 대화가 결과를 바꾸는지 확인하세요. 한 번의 실행에서 여러 퀘스트 분기를 섞지 마세요. 불필요한 행동은 실패한 상태 전이를 찾아내기 어렵게 만듭니다.

**대사의 게이트를 기준이 되는 상태와 비교하세요.** 대화를 가능하게 만드는 조건과 특정 대사를 선택하는 조건을 추적하세요. 단서 보유 여부, 이전 대화, 커밋된 선택지, 씬이나 퀘스트의 진행도 값 등 사전 조건을 확인합니다. Nicklin의 사례는 내러티브 시스템에서 이러한 종류의 게이트가 함께 작동하는 구체적인 예시를 제공합니다. 프로젝트의 구현 방식과 명칭은 다를 수 있습니다.

**행동을 하나의 트랜잭션으로 추적하세요.** 토큰 교환의 경우 플레이어 입력부터 자격 확인, 토큰 차감, 열쇠 지급, 문 또는 퀘스트 업데이트, 저장, 응답 선택에 이르기까지 상호작용을 추적하세요. 작업이 성공했는지, 실패했는지, 아니면 부분적으로만 완료되었는지 확인합니다. 대사는 게임이 실제로 커밋한 결과를 반영해야 합니다. 필수 업데이트가 실패하면 성공 응답을 표시하는 대신 해당 실패를 명시적으로 보고하거나 처리하세요.

**선택지가 선택된 순간부터 나중에 사용될 때까지 확인하세요.** 선택된 응답이 의도한 값을 작성하는지, 설계된 대로 씬 전환이나 리로드 후에도 해당 작성이 유지되는지, 그리고 나중의 대화가 동일한 값을 읽는지 확인하세요. 서로 다른 캐릭터, 씬, 퀘스트 버전에 범위가 한정된 유사한 이름의 플래그가 있는지 살펴보세요. 당시 화면에 표시된 대사 텍스트뿐만 아니라 플레이어의 실제 선택을 검증해야 합니다.

**불일치의 원인을 수정하고 경로를 다시 실행하세요.** 추적을 통해 잘못된 것으로 밝혀진 게이트, 상태 작성, 지속성 동작 또는 대사 선택을 수정합니다. 그런 다음 동일한 시작 세이브에서 다시 플레이하여 대사, 인벤토리, 월드 상호작용 및 후속 응답 등 모든 관련 출력을 확인합니다. 티켓을 찾기 전과 찾은 후 모두 관리인에게 말을 걸어보는 등 인접한 경계 검사를 추가하여 수정한 내용이 의도한 페이싱을 해치지 않는지 확인하세요.

대사는 커밋된 상태를 소비하는 주체로 유지할 것

단서, 아이템, 완료된 행동, 선택지에 대한 신뢰할 수 있는 단 하나의 기준 원천으로 기록된 월드 상태를 지정하세요. 대사 조건은 그 원천에서 읽어와야 하며, 게임플레이 상호작용은 정의된 동일한 전이를 통해 이를 업데이트해야 합니다. 대사는 결과를 설명하거나 행동을 유도할 수 있지만, 대사가 나타났다는 사실만으로 아이템을 몰래 지급하거나 문을 열거나 선택지를 커밋해서는 안 됩니다. 그렇지 않으면 텍스트가 상태와 경쟁하는 또 다른 시스템이 되어버립니다.

생성형 대사나 가변성이 높은 대사의 경우에도 동일한 경계를 적용하세요. 현재 커밋된 상태에 맞춰 대사를 선택하거나 유효성을 검사하고, 상태가 뒷받침하지 않는 주장은 거부하거나 대체해야 합니다. 앞서 언급한 arXiv 프리프린트는 가상 용의자가 프로토타입에서 진술할 수 있는 내용을 제어하기 위한 구조화된 접근 방식을 설명하지만, 이는 보고된 하나의 설계 및 연구일 뿐입니다. 여기서 실용적인 진단 원칙은 더 단순합니다. 말을 생성하거나 선택하는 주체가 무엇이든 간에, 이를 보여주기 전에 게임의 권위 있는 사실에 비추어 검증하라는 것입니다.

결함 보고서에 포함해야 할 내용

간결한 보고서를 통해 다른 사람이 문제를 재현하고 관련 전이 과정을 검사할 수 있어야 합니다. 빌드 및 시작 세이브, 정확한 단계, 관찰된 대사, 예상 대사 또는 동작, 관련된 변경 전후 상태, 그리고 리로드 후에도 문제가 지속되는지 여부를 포함하세요. 분기 문제의 경우 선택한 선택지와 그것이 모순을 일으키는 이후의 씬을 명시하세요. 가능한 경우 상태 추적 내역이나 스크린샷을 첨부합니다.

이러한 기록은 대사 선택 결함과 커밋에 실패한 행동, 지속성 문제 또는 잘못된 후속 조건을 구분하는 데 도움이 됩니다. 원인이 수정되면 한정된 경로와 가장 가까운 경계 케이스를 다시 플레이해 보세요. 목표는 게임이 말하는 내용, 인터페이스가 보여주는 내용, 월드가 허용하는 내용이 실제로 일어난 일에 대해 서로 일치하도록 만드는 것입니다.

이 주제 더 살펴보기