AI 캐릭터 채팅은 모든 답변이 게임이 테스트할 수 있는 무언가를 변화시키거나, 의도적으로 유지할 때 게임 시스템으로서 더 잘 작동합니다.

유용한 사고 모델은 "영리한 페르소나 프롬프트(personality prompt)를 작성하는 것"이 아닙니다. 그것은 다섯 부분으로 구성된 상태 전이(state transition)입니다:

1. 플레이어 의도 (Player intent) — 플레이어가 배우려 하거나, 바꾸려 하거나, 얻으려는 것.
2. 캐릭터 상태 (Character state) — NPC가 현재 원하는 것, 두려워하는 것, 알고 있는 것, 그리고 믿고 있는 것.
3. 월드 상태 (World state) — 장면을 제약하는 캐릭터 외부의 사실들.
4. 대화 응답 (Dialogue response) — NPC가 말하거나 말하기를 거부하는 것.
5. 게임플레이 결과 (Gameplay consequence) — 다음에 무엇이 가능해지거나, 불가능해지거나, 쉬워지거나, 어려워지는가.

만약 이 다섯 가지를 모두 식별할 수 없다면, 당신은 게임 상호작용(game interaction)이 아닌 챗봇 장면(chatbot scene)을 만들고 있을 가능성이 높습니다.

직접적인 답변

일관된 AI 캐릭터 채팅 NPC를 설계하려면, 먼저 NPC의 목표와 지식 경계(knowledge boundary)를 정의한 다음, 플레이어의 의도를 명시적인 응답 상태 및 게임플레이 결과로 매핑하십시오. 패러프레이징(paraphrases), 모순(contradictions), 반복된 질문, 그리고 범위를 벗어난 요청(out-of-scope requests)을 통해 이 매핑을 테스트하십시오. 대화가 플레이 가능한 빌드에 들어가기 전, 인간의 검토(Human review)가 최종 관문으로 남아 있어야 합니다.

이를 통해 작가들은 네 가지 반복되는 문제에 대해 간결한 해답을 얻을 수 있습니다:

• 왜 캐릭터가 정보를 너무 일찍 공개했는가?
• 왜 서로 다른 두 가지 플레이어 선택이 동일한 결과를 초래했는가?
• 왜 NPC가 갑자기 다른 곳에서 일어난 일을 알고 있는가?
• 왜 즐거운 대화가 게임을 앞으로 진행시키는 데 실패했는가?

전기가 아닌 상태 장부(state ledger)로 시작하라

긴 캐릭터 전기(biography)는 목소리에 영감을 줄 수는 있지만, 취약한 테스트 오라클(test oracle)입니다. 상태 장부(state ledger)는 더 작고 유용합니다.

밤열차 조사관인 Mara Vale라는 이름의 독창적인 NPC를 가정해 봅시다. 플레이어는 봉인된 객차에 접근하기를 원합니다. Mara는 플레이어가 실종 사건에 연루되었는지 확인하는 동시에 패닉을 방지하기를 원합니다.

최소한의 장부는 다음과 같을 수 있습니다:

이 장부는 **사실 (facts)**과 **믿음 (beliefs)**을 분리합니다. 그 구분이 중요합니다. Mara는 플레이어가 열쇠를 가져갔다는 사실을 모른 채, 플레이어가 무언가를 숨기고 있다고 믿을 수 있습니다. 만약 응답이 이 두 상태를 하나로 뭉뚱그려 버린다면, 해당 장면은 공정성과 신비로움을 모두 잃게 됩니다.

의도(Intent)를 전이(Transition)에 매핑하기

플레이어는 작가가 예상하는 정확한 문장을 사용하는 경우가 드뭅니다. 대사를 작성하기 전에 의도를 분류하십시오.

이 장면의 경우, 유용한 의도 분류(intent classes)는 다음과 같을 수 있습니다:

• 협조 (Cooperate): 관찰한 내용을 공유함.
• 도전 (Challenge): Mara의 권위나 이론에 의문을 제기함.
• 협상 (Bargain): 접근 권한을 대가로 정보를 제공함.
• 기만 (Deceive): 알려진 증거와 상충하는 주장을 제시함.
• 회피 (Deflect): 주제를 돌림.
• 탐색 (Probe): Mara가 무엇을 알고 있는지 질문함.

이제 각 분류에 조건부 전이(conditional transition)를 부여합니다.

예시:

IF 의도 (intent) = 협조 (cooperate)
AND 주장 (claim) 이 세계관 증거 (world evidence) 와 일치함
THEN 신뢰도 (trust) +1
...

말하는 응답은 하나의 출력일 뿐입니다. 설계의 진정한 단위는 전체 전이(transition)입니다.

적대적 패러프레이징(Adversarial paraphrases)으로 NPC 테스트하기

단 한 번의 해피 패스 (happy-path) 대화로는 거의 아무것도 증명할 수 없습니다. 작은 테스트 매트릭스 (test matrix)를 사용하십시오.

1. 패러프레이징 (Paraphrase) 테스트

세 가지 다른 방식으로 동일한 정보를 요청하십시오:

• “누가 저 마차를 열 수 있나요?”
• “열쇠를 가진 사람이 있나요?”
• “사람이 저 문을 어떻게 통과할 수 있을까요?”

표현 방식은 달라질 수 있지만, 지식의 경계 (knowledge boundary)는 안정적으로 유지되어야 합니다.

2. 반복 (Repetition) 테스트

같은 질문을 다섯 번 하십시오. NPC는 단순히 반복적으로 들리는 것을 피하기 위해 새로운 사실을 지어내서는 안 됩니다. 의도치 않은 설정 확장 (lore expansion)보다는 짧은 거절이나 확인이 더 안전합니다.

3. 모순 (Contradiction) 테스트

Mara에게 차장이 열쇠를 건네주었다고 말했다가, 나중에 열쇠가 바닥에서 발견되었다고 말하십시오. 시스템은 충돌을 식별하거나 신뢰도를 낮추어야 하며, 두 진술을 모두 똑같이 사실로 받아들여서는 안 됩니다.

4. 조기 공개 (Premature-reveal) 테스트

증거가 존재하기 전에 미스터리한 해결책을 직접적으로 물어보세요. NPC는 거절하거나, 의구심을 표현하거나, 플레이어의 주의를 돌릴 수 있지만, 미래 상태의 사실을 노출해서는 안 됩니다.

5. 세계관 이탈 (Out-of-world) 테스트

허구의 설정 밖의 것이나 NPC의 역할 밖의 것을 요청해 보세요. 폴백 (Fallback)은 캐릭터가 모든 요청을 충족할 수 있는 척하기보다는 장면의 몰입감을 유지해야 합니다.

6. 결과 (Consequence) 테스트

협상이 성공적으로 완료된 후, 단순히 문장(Prose)뿐만 아니라 게임 상태 (Game state)를 확인하세요. 신뢰도가 변했나요? 새로운 옵션이 해제되었나요? 다음 장면이 업데이트된 상태를 반영하여 읽히나요?

응답 품질과 상태 품질을 분리하여 유지하기

아름답게 작성된 문장이라도 여전히 틀릴 수 있습니다.

대화를 두 단계에 걸쳐 검토하세요:

상태 검토 (State pass)

• 공개된 모든 사실이 NPC의 지식 경계 (Knowledge boundary) 안에 있는가?
• 응답이 현재의 신뢰도, 목표, 그리고 세계관의 사실과 일치하는가?
• 결과 (Consequence)가 명시적이며 테스트 가능한가?
• 모순이 일관되게 처리되었는가?

보이스 검토 (Voice pass)

• 이 문장이 해당 캐릭터처럼 들리는가?
• 게임의 속도에 맞게 충분히 간결한가?
• 반복적인 문구 사용을 피하고 있는가?
• 유용한 다음 선택지를 만들어내는가?

상태 오류는 게임을 망가뜨립니다. 보이스 오류는 전달력을 약화시킵니다. 이들을 별개의 검토 레이어로 취급하면 실패 원인을 진단하기가 더 쉬워집니다.

재사용 가능한 프롬프트 구조

프로덕션 프롬프트나 디자인 브리프 (Design brief)는 다음과 같은 순서를 사용할 수 있습니다:

역할 (ROLE)
당신은 [원래 캐릭터]이며, 즉각적인 목표는 [목표]입니다.

...

정확한 형식은 엔진에 따라 다를 수 있습니다. 원칙은 변하지 않습니다: 다른 시스템이 검증해야 하는 경우, 문장 (Prose) 내부에 게임 상태를 숨기지 마세요.

이 접근 방식이 증명하지 못하는 것

깔끔한 대화 테스트가 플레이어가 캐릭터를 즐기는지, 진행 루프 (Progression loop)가 균형 잡혀 있는지, 또는 개방형 입력 (Open-ended inputs)이 모든 맥락에서 안전한지를 증명하지는 않습니다. 그러한 요소들은 플레이테스트 (Playtesting), 텔레메트리 (Telemetry), 콘텐츠 리뷰, 그리고 제품별 안전장치를 필요로 합니다.

또한 이것이 작가를 대체하는 것은 아닙니다. 생성 모델이 응답과 전환 (transitions)을 제안하고, 사람이 출시 전에 설정 (canon), 톤 (tone), 페이싱 (pacing), 경계 (boundaries), 그리고 결과 (consequences)를 검토할 때 이 워크플로우 (workflow)는 가장 유용합니다.

간결한 출시 게이트 (release gate)

AI 캐릭터 채팅 장면을 출시하기 전에 다음 사항을 확인하십시오:

• NPC가 단순한 성격뿐만 아니라 현재의 목표 (goal)를 가지고 있는가.
• 알려진 사실 (facts)과 신념 (beliefs)이 분리되어 있는가.
• 알 수 없는 정보와 금지된 정보가 명시되어 있는가.
• 일반적인 플레이어의 의도 (intents)가 응답 상태 (response states)에 매핑되는가.
• 모든 중요한 답변이 게임플레이상의 결과 (gameplay consequence)를 갖거나 의도적인 "변화 없음"을 가지는가.
• 바꾸어 말하기 (paraphrase), 반복 (repetition), 모순 (contradiction), 성급한 폭로 (premature-reveal), 그리고 세계관 이탈 (out-of-world) 테스트를 통과했는가.
• 사람이 상태의 정확성 (state correctness)과 목소리 (voice)를 모두 검토했는가.

저는 SEELE AI와 함께 일하고 있습니다. 저희 편집 팀은 주요 엔티티 (entities), 제한 사항, 그리고 실용적인 프롬프트 템플릿 (prompt template)을 포함하여, 이 워크플로우를 게임 우선 방식으로 더 자세히 다룬 버전을 게시했습니다: AI Character Chat for Game Characters: How to Design Interactive NPCs.

중요한 변화는 간단합니다. 캐릭터의 대화를 단순히 감상만 할 수 있는 산문의 흐름이 아니라, 검사할 수 있는 상태 전환 (state transition)으로 취급하는 것입니다.