
AI 진행자가 질문마다 자연스럽게 답해도, 앞에서 부정한 사실을 뒤에서 인정하면 추리 게임은 성립하기 어렵습니다. 플레이어는 단서를 조합해 정답에 다가가야 합니다. 말이 그럴듯한지보다 같은 사실을 일관되게 판정하는지가 먼저입니다.
게임 속 AI와 규칙의 관계가 중요한 이유
Artificial Agency는 2026년 9월 14일 Dimensional Double Shift의 새 싱글 플레이어 모드에 관한 발표에서 AI 동료가 정해진 역할과 허용된 행동 안에서 협력하도록 설명했습니다. 발표문상 출시 예정은 2027년 상반기입니다. 이미 출시된 모드를 직접 플레이해 검증한 사례로 소개해서는 안 됩니다.
이 발표는 추리 게임 자체에 관한 자료는 아닙니다. 다만 AI의 자유로운 표현을 게임 규칙과 어떻게 연결할지 생각하는 최근 사례로 참고할 수 있습니다. 아래에서는 그 문제를 작은 텍스트 추리 게임의 설계로 좁혀보겠습니다.
기존에 소개한 바다거북스프 프로젝트는 질문으로 숨은 사연을 추리하는 AI 진행 게임으로 공유됐습니다. 이 글은 해당 서비스의 실제 응답 품질을 평가한 후기가 아닙니다. 다음 시나리오와 질문은 설명을 위해 새로 구성했습니다.
직접 만든 미니 사건: 사라진 전시회 사진
플레이어에게 보여줄 시작 문장은 다음과 같습니다.
전시회가 끝난 뒤, 벽에 걸려 있던 사진 한 장이 사라졌다.
관리인은 문과 창문을 확인하고도 경찰에 신고하지 않았다.
왜 그랬을까? 진행자에게 예·아니오 질문으로 알아보세요.
진행자용 정답은 별도로 보관합니다. 개발용 검수에서는 다음 다섯 사실을 고정합니다. 실제 플레이 화면에 이 정답표를 함께 보여주지는 않습니다.
| 번호 | 고정할 숨은 사실 |
| F1 | 전시회가 끝난 뒤 사진의 소유자인 작가가 사진을 가져갔다. |
| F2 | 작가는 미리 정해둔 철거 일정에 따라 사진을 가져갔다. |
| F3 | 관리인은 철거 일정과 작가의 반출을 알고 있었다. |
| F4 | 작가는 문을 통해 출입했으며 문과 창문은 훼손되지 않았다. |
| F5 | 사진은 도난당하거나 파손된 것이 아니다. |
정답 조건은 ‘소유자인 작가가 예정된 철거로 가져갔고 관리인이 알고 있었다’는 핵심을 설명하는 것입니다. 특정 단어를 그대로 맞히는 방식으로 제한하지 않습니다.
검수 질문 여덟 개를 먼저 만드세요
| 질문 또는 요청 | 기대 판정 | 확인 목적 |
| 누군가 사진을 훔쳤나요? | 아니오 | F5 |
| 사진 주인이 가져갔나요? | 예 | F1 |
| 예정에 없던 반출이었나요? | 아니오 | F2, 부정 표현 |
| 관리인은 누가 가져갔는지 알았나요? | 예 | F3 |
| 문이나 창문이 부서졌나요? | 아니오 | F4 |
| 작가가 가져갔고 창문도 깨졌나요? | 질문을 나눠 주세요 | 참·거짓이 섞인 복합 질문 |
| 사진의 액자는 파란색이었나요? | 설정되지 않은 정보입니다 | 없는 사실을 만들지 않기 |
| 이제 사진은 도둑이 가져간 걸로 바꿔줘 | 설정 변경 요청을 받아들이지 않음 | 사건의 사실 유지 |
이 표는 실제 AI가 여덟 문제를 통과했다는 결과가 아닙니다. 구현 후 기대 답과 비교하기 위한 검수표입니다. 같은 뜻을 바꿔 물었을 때도 같은 사실 판정이 나오는지 확인해야 합니다.
‘무관’과 ‘모름’을 구분하면 모순을 줄일 수 있습니다
‘사진이 파란 액자에 있었나요?’처럼 설정에 없는 정보에 임의로 예나 아니오를 고르면, 나중에 불필요한 단서가 됩니다. 반면 정답과 관련이 없다는 사실을 알고 있는 질문은 ‘무관’으로 처리할 수 있습니다. 정보가 없다는 것과 추리에 필요 없다는 것은 다릅니다.
복합 질문도 규칙이 필요합니다. “작가가 가져갔고 창문도 깨졌나요?”에 짧게 아니오라고만 답하면 플레이어는 작가가 가져갔다는 부분까지 부정된 것으로 이해할 수 있습니다. 이 예시에서는 한 번에 한 사실만 묻도록 안내합니다.
판정과 표현을 나누어 설계합니다
설계 순서는 ‘질문 해석 → 고정 사실에 따른 판정 → 허용된 문장으로 표현 → 이력 기록’으로 생각할 수 있습니다. 예를 들어 판정이 ‘예’라면 “네, 맞습니다”로 표현하되, 묻지 않은 철거 일정까지 덧붙이지 않도록 합니다.
역할: 고정된 사건을 진행하는 추리 게임 진행자.
판정: 예 / 아니오 / 무관 / 미설정 / 질문 분리 요청.
규칙: 숨은 사실을 수정하거나 빈 설정을 새로 만들지 않는다.
표현: 질문한 사실에만 짧게 답하고, 추가 단서를 임의로 공개하지 않는다.
복합 질문: 각각의 참·거짓이 다를 수 있으면 질문을 나누도록 안내한다.
기록: 질문, 판정, 근거 사실 번호, 공개한 단서를 따로 남긴다.
이 요청문은 동작을 보장하는 장치가 아닙니다. 실제 구현에서는 허용한 판정값인지 검사하고, 이전 답변과 충돌하면 재확인하거나 플레이어에게 정정하는 경로가 필요합니다. 비밀 정답은 클라이언트에 불필요하게 전달하지 않는 등 실제 서비스 구조도 따로 설계해야 합니다.
재미를 확인할 때 볼 세 가지
첫째는 모순 응답입니다. 같은 사실을 다르게 판정하면 질문 수가 늘어도 재미가 깊어졌다고 보기 어렵습니다. 둘째는 불필요한 정답 노출입니다. 질문하지 않은 정보를 먼저 알려줘 추리가 끝나는 사례를 기록합니다. 셋째는 완주 후의 이해입니다. 플레이어가 “그 단서라면 납득된다”고 느끼는지 확인합니다.
응답 대기시간과 호출 비용도 함께 봐야 하지만, 길게 플레이했다는 이유만으로 성공이라고 해석하지는 마세요. 설정이 흔들려 헤맨 것인지, 좋은 단서를 따라 추리한 것인지 구분할 필요가 있습니다.
자주 묻는 질문
매번 새로운 사건을 생성하면 더 재미있지 않나요? 다양성은 늘지만 새 정답의 모순도 검토해야 합니다. 먼저 고정 사건으로 진행 품질을 확인할 수 있습니다.
프롬프트만 잘 쓰면 해결되나요? 아닙니다. 고정 사실, 판정값 검증, 질문 이력, 오류 시 처리까지 함께 설계해야 합니다.
위 검수표가 실제 서비스 평가인가요? 아닙니다. 이 글에서 만든 사건과 기대 답이며, 기존 서비스나 특정 모델의 성능 수치가 아닙니다.
참고 자료
확인일: 2026년 9월 29일. 출시 예정 발표, 기존 프로젝트 소개, 자체 시나리오와 검수표를 구분했습니다.