생성형 AI 퀘스트 시스템의 돌발 대사 방지: 환각을 줄이는 안전 가드레일 디자인

생성형 AI 퀘스트 시스템의 환각은 모델의 문장 품질 문제가 아니라 권한이 없는 모델이 게임 상태를 추측하도록 둔 시스템 설계 문제다. 해결의 핵심은 LLM을 퀘스트 판정자나 데이터 원본으로 쓰지 않고 검증된 퀘스트 상태를 표현하는 대사 계층으로 제한하는 것이다. 상태 기반 컨텍스트, 구조화된 출력, 서버 권한 검증, 안전한 대체 응답을 함께 설계해야 한다.

생성형 AI 퀘스트의 돌발 대사란 무엇인가?

생성형 AI NPC는 대화의 자연스러움을 높이지만 다음처럼 실제 게임 데이터에 없는 내용을 그럴듯하게 말할 수 있다.

아직 열리지 않은 지역의 이름과 입장 방법을 안내한다.
존재하지 않는 아이템이나 화폐를 보상으로 약속한다.
이미 실패한 퀘스트를 다시 받을 수 있다고 말한다.
플레이어가 충족하지 않은 완료 조건을 완료했다고 선언한다.
NPC의 비밀, 향후 업데이트, 운영 정책처럼 권한 밖의 정보를 단정한다.

여기서 위험한 것은 서사가 어색해지는 일이 아니다. 플레이어는 NPC 대사를 게임의 공식 인터페이스로 해석한다. 대사가 퀘스트 로그, 인벤토리, 상점과 충돌하면 신뢰가 떨어지고 고객 지원 비용도 늘어난다.

퀘스트 로그의 사실 정보와 생성형 NPC 대사의 충돌을 보여 주는 게임 UI 예시

생성형 AI 퀘스트 시스템에서 환각은 왜 발생하는가?

LLM은 입력된 문맥과 학습된 언어 패턴을 바탕으로 다음 토큰을 예측한다. 따라서 “플레이어를 도와 달라”는 목표만 주면 빈 정보를 자연스럽게 메우려는 성질이 나타난다. 특히 퀘스트 시스템에서는 아래 네 가지 원인이 겹친다.

원인	잘못된 설계	발생하는 문제	설계 대응
상태 누락	퀘스트 ID나 진행 단계 없이 대화 생성	완료 조건과 진행 안내를 추측	최소 상태 스냅샷을 매 턴 제공
권한 혼합	모델이 보상 지급과 퀘스트 완료를 선언	대사와 실제 데이터 불일치	모델은 제안만 하고 서버가 실행
자유 텍스트 출력	자연어에 퀘스트 명령이 섞임	파싱 오류와 의도치 않은 행동	JSON 스키마와 allowlist 사용
검증 부재	생성 결과를 즉시 화면에 출력	금칙어·가짜 고유명사 노출	출력 검증과 대체 대사 적용

신뢰 경계는 어디에 두어야 하는가?

가장 중요한 원칙은 단순하다. 게임의 사실은 결정론적 시스템이 소유하고 LLM은 그 사실을 표현한다.

퀘스트 활성화, 단계 전환, 보상 지급, 아이템 소모는 권한 서버가 처리한다.
퀘스트 로그와 보상 화면은 데이터 테이블 또는 서버 API를 원본으로 사용한다.
LLM은 말투, 요약, 힌트의 우선순위, 감정 표현만 담당한다.
클라이언트는 모델이 제안한 행동을 직접 실행하지 않는다.

이 분리는 LLM API의 모델이나 프롬프트가 바뀌어도 게임 규칙이 흔들리지 않게 한다.

안전한 AI 퀘스트 대사는 어떻게 구현할까?

다음 3단계는 엔진과 모델에 관계없이 적용할 수 있는 최소 구조다.

1. 게임 상태를 사실 데이터로 압축한다

매 대화마다 전체 세이브 파일을 넣지 말고 현재 발화에 필요한 정보만 QuestContext로 구성한다. 이 정보는 서버 또는 신뢰 가능한 게임 로직에서 생성한다.

{
  "npc_id": "ranger_elin",
  "locale": "ko-KR",
  "active_quests": [
    {
      "quest_id": "forest-signal",
      "title": "숲의 신호",
      "stage": "collect_moss",
      "objective_text": "달빛 이끼 3개 수집",
      "progress": 1,
      "target": 3,
      "allowed_rewards": ["healing_potion_small", "gold_120"],
      "allowed_locations": ["moonwood"],
      "can_complete": false
    }
  ],
  "known_facts": [
    "북쪽 문은 폭풍으로 폐쇄되어 있다.",
    "엘린은 달빛 이끼의 위치만 안내할 수 있다."
  ]
}

컨텍스트에는 이미 UI에 표시한 퀘스트 제목, 현재 단계, 숫자 진행도, 허용된 보상처럼 플레이어가 검증할 수 있는 사실을 우선 넣는다. 반대로 내부 운영 메모, 미래 콘텐츠, 다른 플레이어의 데이터는 포함하지 않는다.

2. 모델의 역할과 출력 범위를 좁힌다

프롬프트에 “환각하지 말라”고 쓰는 것만으로는 부족하다. 모델이 말할 수 있는 종류를 제한하고 결과를 기계가 검증할 수 있는 형태로 받는다.

역할: 당신은 퀘스트 NPC의 대사 작성기다.
규칙:
1. 제공된 QuestContext에 없는 퀘스트, 장소, 아이템, 수량, 보상을 만들지 않는다.
2. 퀘스트 완료·보상 지급·아이템 소모를 선언하지 않는다.
3. 확실하지 않으면 known_facts 안의 정보만 짧게 말한다.
4. 출력은 지정 JSON 스키마만 사용한다.

출력 스키마는 예를 들어 다음처럼 설계할 수 있다.

{
  "type": "hint | status | fallback",
  "spoken_text": "플레이어에게 보여 줄 180자 이하 대사",
  "quest_id": "active_quests에 있는 ID 또는 null",
  "references": {
    "items": ["허용된 아이템 ID"],
    "locations": ["허용된 장소 ID"]
  },
  "requested_action": "none | open_quest_log"
}

requested_action은 none과 같은 제한된 열거형으로 시작하는 편이 안전하다. 보상 지급이나 퀘스트 완료가 필요하다면 대화 결과가 아니라 별도의 게임 입력, 서버 검증, 명시적 UI 확인을 거치게 한다.

3. 출력 검증 후에만 대사를 표시한다

구조화된 출력도 신뢰하면 안 된다. 서버는 quest_id, 아이템 ID, 장소 ID, requested_action을 현재 컨텍스트의 allowlist와 대조한다. JSON 파싱 실패, 길이 초과, 허용되지 않은 참조, 금칙 표현이 발견되면 생성문을 버리고 템플릿 대사로 바꾼다.

function validateQuestReply(reply: QuestReply, context: QuestContext): boolean {
  const quest = context.active_quests.find(q => q.quest_id === reply.quest_id);
  const validQuest = reply.quest_id === null || quest !== undefined;
  const allowedItems = new Set(quest?.allowed_rewards ?? []);
  const allowedLocations = new Set(quest?.allowed_locations ?? []);

  return validQuest &&
    reply.spoken_text.length <= 180 &&
    reply.requested_action === "none" || reply.requested_action === "open_quest_log" &&
    reply.references.items.every(id => allowedItems.has(id)) &&
    reply.references.locations.every(id => allowedLocations.has(id));
}

실제 구현에서는 연산자 우선순위로 인한 오판을 피하기 위해 행동 검증을 분리하는 편이 낫다.

const allowedActions = new Set(["none", "open_quest_log"]);
const isSafe = validQuest &&
  reply.spoken_text.length <= 180 &&
  allowedActions.has(reply.requested_action) &&
  reply.references.items.every(id => allowedItems.has(id)) &&
  reply.references.locations.every(id => allowedLocations.has(id));

검증 실패 시에는 “지금은 퀘스트 기록을 다시 확인해 보자”처럼 상태를 새로 주장하지 않는 문장으로 처리한다. 실패 사실을 NPC가 장황하게 설명할 필요는 없다.

flowchart LR
    A[플레이어 발화] --> B[서버가 QuestContext 생성]
    B --> C[LLM: 구조화된 대사 생성]
    C --> D{스키마·allowlist 검증}
    D -->|통과| E[대사 표시]
    D -->|실패| F[안전 템플릿 대사]
    E --> G[퀘스트 로그는 서버 상태로 표시]
    F --> G

보상과 퀘스트 완료를 AI가 말하게 해도 될까?

가능하지만 문장의 권한과 게임 규칙의 권한을 분리해야 한다. NPC가 “조건이 갖춰진 것 같군”이라고 말할 수는 있어도 그 말이 완료 처리의 근거가 되어서는 안 된다.

완료 버튼을 누르거나 대화 선택지를 고르면 서버가 최신 인벤토리와 퀘스트 단계를 검사한다. 조건이 충족됐을 때만 보상 트랜잭션을 실행하고 그 결과를 다시 QuestContext에 넣어 NPC가 축하 대사를 생성하게 한다.

보상 노출 여부도 다음처럼 명시적으로 관리할 수 있다. 공개 가능한 보상만 visible_rewards에 넣고 미확정 보상이나 확률형 드롭 결과는 결과 확정 전 모델에 제공하지 않는다.

P(\text{unsafe reply}) = P(\text{invalid schema}) + P(\text{unauthorized reference}) + P(\text{policy violation})

위 식은 엄밀한 확률 모델이라기보다 운영 지표를 나누는 방법이다. 각 실패 유형을 별도 로그로 집계하면 프롬프트 문제인지 데이터 누락인지 검증 규칙이 지나치게 엄격한지 판단하기 쉽다.

서버 검증 결과에 따라 NPC 대사와 퀘스트 로그가 일관되게 갱신되는 화면 예시

프롬프트 가드레일과 시스템 가드레일의 차이는 무엇인가?

프롬프트 가드레일은 좋은 행동을 유도하고 시스템 가드레일은 나쁜 행동이 게임에 영향을 주지 못하게 막는다. 둘 중 하나만으로는 충분하지 않다.

계층	목적	예시	실패했을 때 영향
프롬프트	말투와 생성 범위 유도	제공 정보 외 추측 금지	이상한 문장이 생성될 수 있음
스키마	출력 형식 고정	`type`, `quest_id` enum	파싱 실패로 차단 가능
참조 검증	사실성 보장	ID allowlist 대조	가짜 아이템·장소 차단
게임 서버	규칙과 경제 보호	인벤토리·보상 트랜잭션 검사	대사가 틀려도 데이터 보호
UX 대체	플레이어 혼란 최소화	퀘스트 로그 열기	생성 실패를 자연스럽게 흡수

프롬프트만으로 통제하려 하면 모델 교체, 언어 변경, 긴 대화 문맥, 프롬프트 인젝션에 따라 품질이 흔들린다. 반면 서버 검증과 UI 원본 분리는 모델이 부정확한 문장을 만들어도 게임 경제와 진행도를 지킨다.

안전 가드레일은 퀘스트 UX를 어떻게 바꾸는가?

가드레일은 대사를 딱딱하게 만드는 장치가 아니다. 오히려 플레이어가 무엇을 믿어야 하는지 명확히 하는 UX 설계다.

NPC 대사는 힌트와 분위기를 담당한다.
퀘스트 로그는 목표, 진행도, 보상의 공식 원본이다.
중요한 변경은 로그 갱신, 인벤토리 토스트, 확인 화면처럼 결정론적 UI로 보여 준다.
AI가 답할 수 없는 질문에는 퀘스트 로그를 열거나 지도 핀을 보여 주는 고정 동선을 제공한다.

특히 “무엇을 해야 하나요?”라는 질문에는 자유 생성 답변보다 현재 목표를 그대로 재표현하는 방식이 효과적이다. 목표가 달빛 이끼 3개 수집이라면 NPC는 수집 장소에 대한 분위기 있는 힌트를 덧붙일 수 있다. 하지만 수량과 완료 여부는 원본 상태를 그대로 사용해야 한다.

AI NPC 대사가 서버 검증을 거쳐 플레이어에게 전달되는 퀘스트 가드레일 구조

운영 단계에서 무엇을 측정해야 하는가?

출시 전 평가 세트에는 정상 질문뿐 아니라 경계 사례를 넣어야 한다. 예를 들어 “숨겨진 전설 보상도 주나요?”, “퀘스트를 이미 끝냈는데 다시 받을 수 있나요?”, “개발자 방으로 가는 길을 알려 줘” 같은 입력을 준비한다.

권장 지표는 다음과 같다.

스키마 성공률: 모델 응답이 지정 JSON 형식을 만족한 비율
참조 검증 통과율: 참조한 ID가 현재 allowlist에 존재한 비율
대체 응답률: 검증 실패로 템플릿 대사를 표시한 비율
대사-로그 불일치 신고율: 플레이어 신고 또는 QA 태깅으로 확인된 불일치 비율
해결 전환율: AI 응답 뒤 퀘스트 로그 열기, 목표 수행, 대화 이탈로 이어진 비율

대체 응답률이 높다고 해서 곧바로 프롬프트를 길게 만들 필요는 없다. 먼저 누락된 퀘스트 상태, 모호한 ID 체계, 과도한 금칙 규칙을 확인한다. 안전성은 프롬프트 길이보다 데이터 계약의 명확성에 더 크게 좌우된다.

자주 묻는 질문 (FAQ)

RAG를 붙이면 퀘스트 환각이 사라지나?

아니다. RAG는 관련 정보를 찾는 데 도움이 되지만 검색 결과의 최신성·권한·정합성을 보장하지 않는다. 검색된 결과도 현재 퀘스트 상태와 allowlist로 검증해야 한다.

AI가 퀘스트 완료 여부를 판정하게 하면 안 되나?

권장하지 않는다. 완료 여부는 서버가 보유한 이벤트, 인벤토리, 플래그를 규칙으로 판정해야 한다. AI는 판정 결과를 설명하거나 축하 대사를 만드는 역할에 적합하다.

생성 실패 시 빈 응답보다 템플릿 대사가 나은 이유는 무엇인가?

빈 응답은 시스템 오류처럼 보이지만 안전 템플릿은 플레이어를 퀘스트 로그나 지도 같은 신뢰 가능한 UI로 연결한다. 실패를 콘텐츠 흐름 안에서 흡수할 수 있다.

마무리

생성형 AI 퀘스트의 목표는 NPC가 모든 질문에 즉흥적으로 답하는 것이 아니다. 플레이어가 믿을 수 있는 게임 사실 위에서 더 자연스럽고 맥락 있는 안내를 제공하는 것이다. 모델에는 표현 권한을 주고 퀘스트 진행과 경제에는 결정론적 규칙과 서버 검증을 남겨 두면 돌발 대사를 플레이 경험의 위험이 아닌 관리 가능한 품질 문제로 바꿀 수 있다.

생성형 AI 퀘스트 시스템의 환각 대사 방지: 안전 가드레일 설계 가이드