AI 캐릭터 대화가 추리 게임의 단서를 지어내지 않도록 방지하는 방법

지어낸 단서가 미스터리를 망치는 이유

추리 게임에서 플레이어는 정보를 수집하고, 결론을 도출하며, 알게 된 내용을 바탕으로 더 많은 정보를 찾습니다. 따라서 단서와 플레이어 지식 간의 관계는 단순한 대화 스타일의 세부 사항이 아니라 게임 핵심 루프의 일부입니다. 배치되지 않은 편지를 불쑥 언급하거나 플레이어가 만난 적 없는 인물의 이름을 자신 있게 말하는 캐릭터는 의도치 않게 새로운 단서를 만들어낼 수 있습니다. 플레이어는 그 세부 사항이 기획된 단서인지, 의도적인 거짓말인지, 아니면 생성된 군더더기인지 확실하게 알 방법이 없습니다. 논문 “Generative Forensics: Procedural Generation and Information Games”에서는 정보 게임을 지식을 모으고 이를 사용해 미스터리를 이해하는 과정으로 설명합니다. 이러한 프레임을 적용할 때, 추적되지 않은 생성된 주장은 플레이어가 추론의 근거로 삼아야 할 지식을 흐릴 수 있습니다.

해결책은 명확한 구분에서 시작됩니다. 단서는 플레이어가 행동을 취할 수 있는 게임의 팩트이며, 플레이버는 게임 팩트를 추가하거나 변경하지 않는 표현형 대화입니다. 캐릭터가 불확실해 보이거나, 말을 돌리거나, 재미있거나, 생생하게 말할 수는 있지만, 단지 설득력 있게 표현되었다는 이유만으로 대사가 증거가 되어서는 안 됩니다.

대화를 생성하기 전에 작성된 단서 기록 만들기

실행 가능한 모든 단서에 대해 명시적인 소규모 기록을 유지하세요. 데이터베이스, 콘텐츠 파일 또는 내러티브 도구에 보관할 수 있습니다. 핵심은 모델이 그 내용을 임의로 지어내지 않는다는 점입니다. 단서가 무엇을 말하는지, 어디서 왔는지, 누가 알 수 있는지, 언제 사용 가능해지는지 답하는 필드를 포함하세요.

필드: clue_id; 기록 내용: 증거에 대한 고유 식별자; 예시 (예시용): note_blue_01

필드: canonical_fact; 기록 내용: 게임이 확립하는 팩트; 예시 (예시용): “쪽지에는 이니셜 M이 서명되어 있다.”

필드: source_id; 기록 내용: 이를 뒷받침하는 사전에 작성된 오브젝트, 장면 또는 대사; 예시 (예시용): archive_note_03

필드: discovery_condition; 기록 내용: 논의하기 전에 요구되는 게임 상태; 예시 (예시용): found_archive_note_03

필드: allowed_speakers; 기록 내용: 이를 알거나 논의할 수 있는 캐릭터; 예시 (예시용): Mara, Ivo

필드: certainty; 기록 내용: 출처가 팩트를 진술하는지 아니면 해석을 제시하는지 여부; 예시 (예시용): explicit

필드: player_facing_label; 기록 내용: 해당하는 경우 수첩에 증거가 표시되는 방식; 예시 (예시용): “서명 없는 쪽지”

위의 이름과 값은 형식을 보여주기 위한 가상의 예시일 뿐이며, 특정 게임에 대한 주장이 아닙니다. 이 기록은 출처의 명시적인 내용과 해석을 분리하고 있다는 점에 주목하세요. 서명 이니셜 자체가 누가 쪽지를 썼는지를 규정하지는 않습니다. 이러한 구분을 통해 대화 시스템은 캐릭터가 추측을 새로 검증된 증거로 제시하지 않으면서도 추측을 펼칠 수 있는 여지를 확보합니다.

대화만이 아닌 발견 상태로 단서 통제하기

발견을 게임 소유의 상태로 표현하세요. 예를 들어, found_archive_note_03은 플레이어가 실제로 쪽지를 찾았을 때만 true가 됩니다. 대화가 시작될 때, 플레이어의 발견 상태와 캐릭터의 지식에 따라 필터링하여 캐릭터가 논의하도록 허용된 작성된 팩트 목록을 전달하세요. 단서는 두 가지 검사가 모두 통과할 때만 사용할 수 있습니다. 즉, 플레이어가 발견 조건에 도달했고 발화자가 이를 알 권한이 있는 경우입니다.

이는 검색 증강 생성(RAG)의 실질적인 적용 사례입니다. 관련 기록을 검색하고, 이를 모델의 컨텍스트에 배치한 다음, 해당 기록을 바탕으로 생성하는 것입니다. Microsoft의 RAG 개요에서는 이러한 검색-증강-생성 흐름을 설명하며 부실하거나 불완전한 검색이 여전히 부정확한 출력으로 이어질 수 있음을 경고합니다. 게임의 경우 검색 결과가 모델에 도달하기 전에 발견 조건을 준수해야 합니다. 모델에게 “스포일러하지 마”라고 말하는 것은 아직 발견되지 않은 증거를 아예 전달하지 않는 것보다 통제력이 약합니다.

가능하면 권한 검사는 모델 외부에서 처리하세요. 생성된 산문 대사가 아니라 게임 시스템이 증거가 수첩에 들어갈지, 퍼즐을 해결할지, 상호작용을 드러낼지를 결정해야 합니다. 모델은 권한이 부여된 팩트를 자연스럽게 표현할 수 있지만, 해당 팩트가 애초에 권한이 있는지 여부는 게임 상태가 결정해야 합니다.

모델에 좁은 계약과 안전한 대체 동작(fallback) 제공하기

유용한 프롬프트는 캐릭터의 어조, 현재 장면, 허용된 단서 기록, 증거와 플레이버의 차이를 구체적으로 지정해야 합니다. 질문이 제공된 증거의 범위를 벗어날 때 취해야 할 행동을 명시하세요. 확인을 거부하거나, 캐릭터가 모른다고 말하거나, 캐릭터다운 비실행성 대사로 응답하는 식입니다. 상충되거나 모호한 기록에 대한 지침도 포함해야 합니다. Microsoft의 RAG 프롬프트 엔지니어링 가이드에서는 명시적인 근거 제한, 대체 동작, 출처 식별자, 충돌 처리 지침을 권장합니다. 이는 정보 안내 시스템뿐만 아니라 제어된 캐릭터 대화에도 유용한 설계 원칙입니다.

예를 들어, 플레이어가 이니셜 M이 마라가 쪽지를 썼다는 것을 증명하는지 묻는다면, 허용된 응답은 “M이 적혀 있긴 하지만, 그것만으로는 누가 서명했는지 알 수 없어.”라고 말할 수 있습니다. 시스템은 이 표현이 출처의 팩트와 결론 사이의 차이를 보존하므로 허용할 수 있습니다. 답변을 더 그럴듯하게 만들기 위해 목격자, 필적 일치 또는 두 번째 문서를 즉흥적으로 지어내서는 안 됩니다.

모델이 spoken_text, claim_type, source_ids와 같은 구조화된 필드를 반환하도록 하세요. 단서가 포함된 응답의 경우 최소 하나 이상의 유효한 출처 식별자를 요구하고, 해당 턴에 제공된 기록과 대조하여 그 식별자를 확인하세요. 플레이버의 경우 응답을 비증거(non-evidence)로 표시하고 단서 플래그를 설정하지 못하도록 하세요. 구조화된 출력이 산문의 진실성을 증명하는 것은 아니지만, 게임이 화면에 표시하거나 상태를 변경하기 전에 확인할 수 있는 데이터를 만들어 줍니다.

플레이어가 비중을 파악할 수 있도록 플레이버 라벨 지정하기

플레이버 텍스트에는 캐릭터의 기분, 가벼운 농담, 방에 대한 구체적이지 않은 반응 등이 포함될 수 있습니다. 플레이버 텍스트가 날짜, 장소, 물건, 이름이 언급된 목격자, 동기 등 플레이어가 단서로 받아들일 만한 세부 사항을 은근슬쩍 도입해서는 안 됩니다. 추측성 대화를 원한다면 문구에서 불확실성을 분명히 드러내고 증거 목록, 퀘스트 상태, 단서 기반 상호작용과 같은 객관적 시스템에서는 제외하세요.

이러한 구분은 데이터와 연출 모두에 반영될 수 있습니다. 내부적으로는 대사를 증거, 해석, 플레이버로 태그를 지정하고, 인터페이스에서는 증거 스타일이나 수첩 항목을 게임에서 작성된 단서에만 적용하세요. 캐릭터가 “어쩌면 쪽지를 서둘러 두고 간 걸지도 몰라”라고 말할 수 있지만, 게임이 그 가능성을 허용된 해석으로 사전에 작성해 두지 않았다면 확인된 단서로 나타나거나 새로운 분기를 유발해서는 안 됩니다. 이 3단계 라벨링은 출처가 말하는 내용, 누군가가 추론한 내용, 단순한 표현형 대화를 보존해야 하는 필요성에서 파생된 디자인 권장 사항입니다.

내러티브 도구를 사용하여 상태 및 조건 추적하기

이 접근 방식을 적용하기 위해 특정 엔진이 반드시 필요한 것은 아닙니다. 인터랙티브 내러티브 도구는 일반적으로 구절(passage) 또는 섹션, 변수, 조건부 콘텐츠를 지원합니다. 공식 Ink 작성 문서에서는 스토리 콘텐츠를 제어하기 위한 변수 및 조건부 로직을 설명하며, Twine Cookbook의 패시지 가이드에서는 텍스트가 표시되거나 반응하는 방식에 영향을 미치는 코드를 포함할 수 있는 콘텐츠 섹션으로 패시지를 설명합니다. 이러한 기능은 대사 자체가 생성된 것이든 사전에 작성된 것이든 관계없이 발견 상태, 발화자의 지식, 조건부 대사를 표현할 수 있습니다.

내러티브 기록과 게임 로직 전반에서 단서 ID와 상태 이름을 일관되게 유지하세요. found_archive_note_03과 같은 변수는 서로 다른 장면에서 읽거나 설정할 때 모호한 clue2 플래그보다 감시하기가 훨씬 쉽습니다. 실행 가능한 생성 대사마다 허용된 출처 기록으로 거슬러 올라가는 추적 가능한 링크를 추가하세요. 대사에 유효한 출처가 없다면 런타임 환경에서 이를 증거로 취급하는 대신 거부하거나 안전한 대체 동작을 요청할 수 있습니다.

집중적인 플레이테스트로 경계 점검하기

상태 규칙이 실패할 가능성이 가장 높은 발견 경계에서 대화를 테스트하세요. 단서를 찾기 전, 단서를 찾은 직후, 다른 지식을 가진 캐릭터가 말한 후에 새 대화를 시도해 보세요. 아직 발견되지 않은 증거에 대해 직접적인 질문을 던지고, 출처가 부분적으로만 답하는 질문을 해보며, 게임이 지원하는 경우 장면을 다시 플레이해 보세요. 표시된 대사, 반환된 출처 ID, 수첩이나 스토리 상태의 모든 변경 사항을 비교하세요.

간결한 테스트 체크리스트는 이러한 점검을 구체적으로 유지하는 데 도움이 됩니다:

실행 가능한 모든 주장이 사전에 작성된 단서나 명시적으로 허용된 해석과 매핑되는가.

단서의 발견 조건이 true가 된 후에만 사용할 수 있는 지식으로 나타나는가.

발화자가 해당 장면에서 그 정보를 알 수 있도록 허용되었는가.

근거가 없는 질문을 받았을 때 새로운 구체적 팩트 대신 지정된 대체 동작을 실행하는가.

플레이버 대사가 수첩 항목을 추가하거나, 단서 게이트를 통과하거나, 증거 상태를 변경할 수 없도록 되어 있는가.

모호하거나 상충되는 기록이 조용히 새로운 결론을 내리지 않고 불확실성을 나타내거나 검토 가능한 대체 동작을 생성하는가.

그라운딩(grounding)은 지어낸 단서의 여지를 줄여주지만, 생성된 산문이 제공된 팩트를 항상 존중한다는 것을 보장하지는 않습니다. Microsoft의 RAG 한계 지침에서 언급했듯이, 검색 시 관련 기록을 놓칠 수 있으며 모델은 그라운딩에도 불구하고 여전히 부정확한 텍스트를 생성할 수 있습니다. 단서에 대한 최종 권한은 작성된 기록과 게임 로직에 두어야 합니다. 생성 기능은 이러한 경계 주변에 목소리를 덧입히는 용도로만 사용하세요.

실용적인 규칙은 간단합니다. 단어의 선택은 모델에 맡기되, 작성된 미스터리와 현재 게임 상태가 해당 단어가 확립할 수 있는 권한을 결정하게 하세요. 실행 가능한 모든 단서에 출처, 발견 게이트, 명확한 상태가 있으면, 캐릭터는 게임에 애초에 존재하지 않았던 증거를 플레이어에게 건네지 않고도 훨씬 더 대화다운 생동감을 가질 수 있습니다.

이 주제 더 살펴보기