AI 텍스트 생성으로 무한 분기 다이얼로그와 호감도를 설계하는 방법
AI 텍스트 생성으로 무한 분기 대화를 만들 때 발생할 수 있는 캐릭터 붕괴와 호감도 인플레이션을 완화하는 설계법을 다룬다. 상태 변수, 점수 수식, 선택지 제약, 검증 파이프라인을 예시로 정리한다.
AI 텍스트 생성 기반의 무한 분기 다이얼로그는 모든 대사를 미리 작성하는 대신, 캐릭터 상태와 호감도 규칙을 먼저 설계하고 AI의 출력 범위를 제한하는 방식으로 만든다. 핵심은 AI가 호감도를 결정하게 두지 않고 게임 규칙이 계산한 결과를 바탕으로 대사와 선택지를 표현하게 하는 것이다.
AI 분기 다이얼로그에서 무엇을 고정해야 하는가?
무한 분기는 선택지가 끝없이 늘어나는 시스템이 아니다. 플레이어의 자유 입력 또는 넓은 선택지를 제한된 게임 상태로 해석하고 그 상태에 맞는 다음 반응을 생성하는 시스템이다.
먼저 대화에서 변하지 않아야 할 정보를 분리한다.
| 구분 | 예시 | 관리 주체 |
|---|---|---|
| 캐릭터 정체성 | 말투, 가치관, 금기, 목표 | 캐릭터 데이터와 시스템 프롬프트 |
| 사실 상태 | 퀘스트 완료, 목격한 사건, 소지품 | 게임 저장 데이터 |
| 관계 상태 | 호감도, 신뢰, 경계, 로맨스 단계 | 규칙 기반 점수 시스템 |
| 표현 | 대사, 어조, 선택지 문장 | LLM |
LLM은 마지막 열인 표현에 집중시키는 편이 안전하다. 예를 들어 NPC가 플레이어를 의심하는 상태인지 여부는 모델이 문맥으로 추측하는 값이 아니라 trust = 18 같은 저장 데이터여야 한다.
그림은 개념 설명용 가상 UI이며 실제 게임이나 AI 도구의 화면이 아닙니다.
호감도는 왜 쉽게 망가지는가?
모든 친절한 선택에 같은 보상을 주면 플레이어가 캐릭터의 맥락보다 보상 효율이 높은 문장을 반복하는 방식으로 시스템을 공략할 수 있다. 이는 발생할 수 있는 설계 위험이며, 실제로 어떤 선택 전략이 우세한지는 플레이테스트로 확인해야 한다.
또한 AI가 매 턴 호감도 변화를 자유롭게 제안하도록 두면 다음 문제가 생길 수 있다.
- 사소한 인사에 큰 점수가 반복 지급된다.
- 캐릭터의 금기와 관계없이 호감도가 오른다.
- 플레이어마다 대화 난이도와 보상이 크게 달라진다.
- 재생성 결과에 따라 같은 선택의 가치가 달라진다.
따라서 호감도는 단일 수치보다 관계의 성격을 드러내는 여러 축으로 설계하는 편이 좋다.
| 변수 | 범위 예시 | 의미 |
|---|---|---|
affection | 0~100 | 정서적 친밀감 |
trust | 0~100 | 약속과 정보에 대한 신뢰 |
respect | 0~100 | 능력과 가치관에 대한 존중 |
suspicion | 0~100 | 경계와 의심 |
예를 들어 위험한 비밀을 지켜 주는 행동은 trust를 올리지만 NPC의 방식에 반대했다면 respect는 떨어질 수 있다. 이 구조는 한 선택을 완전한 정답으로 만들지 않는다.
AI 선택지와 호감도 변화를 어떻게 구현할까?
1. 플레이어 의도를 태그로 정규화한다
자유 입력이나 AI 생성 선택지는 그대로 점수에 연결하지 않는다. 먼저 게임에 필요한 의도로 분류한다.
type Intent = "empathize" | "challenge" | "deceive" | "withdraw";
type DialogueAction = {
intent: Intent;
topic: "quest" | "secret" | "daily";
risk: 0 | 1 | 2;
};LLM에는 선택지 문장과 함께 intent, topic, risk를 JSON으로 반환하도록 요청한다. 게임의 권한 주체가 세 필드의 형식과 허용된 값 범위를 각각 확인한 뒤에만 다음 단계로 넘긴다. 싱글플레이어라면 로컬 게임 코드가 이를 검증할 수 있지만, 멀티플레이어에서 점수의 권위는 서버에 두고 클라이언트 검증은 편의용 사전 검사로 취급해야 한다. 클라이언트 검증은 우회될 수 있으므로 서버에서도 입력을 검사하라는 OWASP 입력 검증 지침과 Unreal 네트워킹 개요의 서버 권한 모델을 참고할 수 있다.
2. 점수는 수식과 규칙으로 계산한다
관계 변화는 캐릭터 성향, 현재 상태, 행동 위험도를 사용해 계산한다. 다음 식은 최대치 Rmax가 양수이고 현재 관계 수치가 0부터 최대치 사이에 있으며 기본 변화량과 배율도 양수인 경우에 적용하는 보상 예시다.
B(i, c): 의도i와 캐릭터 성향c의 기본 변화량R: 현재 관계 수치Rmax: 최대 관계 수치M(q): 퀘스트 단계나 사건 중요도에 따른 배율
상한에 가까워질수록 증가량을 줄이면 초반 관계 형성은 빠르고 후반 신뢰 획득은 신중해진다. 단, 부정 변화까지 같은 방식으로 줄이면 갈등의 결과가 약해질 수 있으므로 손실은 별도 규칙으로 두는 편이 낫다.
function applyTrust(state: number, base: number, questMultiplier: number, maxTrust = 100) {
const gain = Math.round(base * (1 - state / maxTrust) * questMultiplier);
return Math.max(0, Math.min(maxTrust, state + gain));
}
console.assert(applyTrust(0, 10, 1) === 10);
console.assert(applyTrust(90, 10, 1) === 91);3. 계산된 상태만 AI 프롬프트에 전달한다
점수 계산 뒤에는 상태 변화의 원인과 결과를 짧은 구조화 데이터로 전달한다. 모델에게는 “호감도를 올려라”가 아니라 “신뢰가 42에서 48로 변했으며 비밀을 지킨 행동을 인정하되 아직 경계는 남아 있다”처럼 구체적인 연기 지시를 준다.
{
"npc": "마레나",
"relationship": {
"affection": 35,
"trust": 48,
"respect": 52,
"suspicion": 27
},
"recent_event": "플레이어가 밀수 장부의 위치를 숨겼다",
"response_rules": [
"감사는 표현하되 정보를 모두 공개하지 않는다",
"선택지는 3개만 제시한다",
"각 선택지에 intent와 risk를 포함한다"
]
}검증된 같은 intent, 현재 관계 수치, 규칙 입력을 전달하면 LLM이나 생성 설정이 바뀌어도 관계 변화량은 게임 코드의 같은 규칙으로 계산된다. 다만 자유 입력을 의도로 분류하는 결과나 생성 대사는 달라질 수 있으므로 이 단계는 별도로 검증해야 한다.
선택지는 몇 개가 적절한가?
무한 대화라고 해서 한 턴에 많은 선택지를 보여 줄 필요는 없다. 화면형 대화에서 3개, 복잡한 협상이나 조사 장면에서 4개를 시작점으로 시험해 볼 수 있다. 이 수는 검증된 보편 기준이 아니며, 선택지 수보다 각 선택지의 역할이 겹치지 않는지가 중요하다.
| 역할 | 예시 의도 | 설계 목적 |
|---|---|---|
| 공감 | 감정을 인정한다 | 정서적 친밀감 확인 |
| 탐색 | 사실을 질문한다 | 정보 획득과 신뢰 시험 |
| 대립 | 주장에 반박한다 | 가치관 충돌 노출 |
| 이탈 | 대화를 미룬다 | 위험 회피와 시간 선택 |
LLM에 “흥미로운 선택지 3개”만 요청하면 문장이 달라도 기능은 비슷해지기 쉽다. 위처럼 역할을 지정하면 플레이어가 관계, 정보, 안전 중 무엇을 우선할지 판단할 수 있다.
flowchart LR
A[플레이어 입력 또는 선택] --> B[의도 태그 검증]
B --> C[호감도 규칙 계산]
C --> D[퀘스트 및 사실 상태 갱신]
D --> E[LLM에 상태와 연기 지시 전달]
E --> F[대사와 다음 선택지 생성]캐릭터 일관성을 지키는 최소 제약은 무엇인가?
캐릭터마다 긴 설정집을 매번 전송할 필요는 없다. 대화에 직접 영향을 주는 제약부터 우선순위로 관리하고, 5~8개를 시작점으로 시험해 볼 수 있다. 이 개수는 보편적인 제한이 아니다.
캐릭터 카드 예시
- 목표: 실종된 동생의 행방을 찾는다.
- 말투: 짧고 공적인 문장을 선호한다.
- 가치관: 약속을 지키는 행동을 높게 평가한다.
- 금기: 동생의 실종을 농담처럼 다루면 대화를 중단한다.
- 공개 가능한 정보: 항구의 밀수 조직을 의심한다.
- 비공개 정보: 자신도 조직에 빚이 있다.
캐릭터 카드에 최근 대화 요약과 현재 관계 변수를 함께 전달하는 방식을 먼저 시험해 볼 수 있다. 전체 대화 로그를 매번 넣으면 입력 토큰과 컨텍스트 사용량이 늘 수 있으며, 오래된 발언과 현재 상태가 충돌할 때 모델이 어느 정보를 우선할지 모호해질 수 있다. 토큰 단위로 요금을 부과하는 API에서는 입력 토큰이 늘면 비용이 커질 수 있지만, 과금 방식과 단가는 제공자와 모델에 따라 다릅니다. 참고: OpenAI 토큰 계산 안내, OpenAI API 가격. 요약과 생략 기준은 사용하는 모델과 대화 흐름에 맞춰 검증한다.
자주 묻는 질문 (FAQ)
LLM이 호감도 점수를 직접 출력하게 해도 될까?
권장하지 않는다. 모델은 점수 후보나 감정 해석을 제안할 수 있지만 최종 변화량은 열거형 의도와 규칙 테이블을 사용하는 게임 코드가 계산해야 한다.
플레이어 자유 입력은 어떻게 처리할까?
입력을 의도 태그로 분류한 뒤 허용된 행동으로만 변환한다. 분류가 불확실하면 점수를 바꾸지 않고 NPC가 추가 질문을 하게 만들면 된다.
모든 NPC에 같은 호감도 축을 써도 될까?
기본 축은 재사용해도 된다. 다만 퀘스트 핵심 NPC에는 debt, fear, loyalty처럼 해당 관계의 갈등을 설명하는 변수를 추가할 수 있다. 어떤 변수가 유용한지는 캐릭터와 퀘스트 설계에 따라 다르다.
정리
AI 텍스트 생성은 대사를 표현하는 수단으로 두고 관계 수치의 권한은 게임 규칙에 둔다. 검증된 의도 태그 → 규칙 기반 관계 계산 → 상태를 반영한 대사 생성의 흐름을 사용하면 같은 상태와 같은 의도에 같은 점수 규칙을 적용할 수 있다. 밸런스와 대화 품질은 별도의 플레이테스트로 확인해야 한다.
