생성형 AI 전리품 시스템 설계: 랜덤 옵션과 아이템 이름을 안전하게 자동 부여하는 법

생성형 AI 기반 전리품은 AI에게 능력치를 직접 결정하게 두는 시스템이 아니라 검증된 옵션 조합에 맥락 있는 이름과 설명을 부여하는 시스템으로 설계해야 한다. 옵션 수치와 드롭 확률은 시드·예산·규칙으로 결정하고 생성형 AI는 표현 계층을 담당하게 분리하면 밸런스와 재현성을 유지할 수 있다.

생성형 AI 전리품 시스템에서 무엇을 분리해야 하는가?

전리품 생성에는 서로 다른 책임이 섞이기 쉽다. 특히 LLM이 +37% 치명타 피해 같은 최종 수치를 자유롭게 제안하도록 두면 패치 후의 재현성·경제 통제·악용 대응이 모두 어려워진다.

계층	책임	결정 방식	저장 대상
전투 계층	공격력, 치명타, 쿨다운 등 실제 효과	서버 규칙과 난수 시드	옵션 ID, 수치, 시드
밸런싱 계층	희귀도, 옵션 조합, 전력 예산	가중치 테이블과 제약 조건	희귀도, 비용, 검증 결과
표현 계층	아이템 이름, 짧은 서사, 툴팁 문장	생성형 AI 또는 템플릿	이름, 설명, 생성 버전
운영 계층	금칙어, 비용, 실패 처리, 로그	필터와 폴백 정책	프롬프트 버전, 모델 결과

핵심은 AI 출력이 게임 플레이를 바꾸지 않게 하는 것이다. 이름 생성이 실패해도 장비의 실제 옵션은 이미 확정되어 있어야 한다.

랜덤 옵션은 왜 전력 예산으로 제한해야 하는가?

옵션마다 동일한 숫자를 붙여도 체감 성능은 같지 않다. 공격 속도, 추가 투사체, 쿨다운 감소처럼 다른 효과와 곱해지는 옵션은 단순 합산보다 높은 가치를 가진다. 따라서 아이템 희귀도마다 사용할 수 있는 전력 예산을 먼저 정하고 옵션이 그 예산을 넘지 않도록 조합한다.

B_r = B_0 \times m_r

여기서 $B_r$ 은 희귀도 $r$ 의 전력 예산, $B_0$ 은 기본 예산, $m_r$ 은 희귀도 배율이다. 각 옵션의 비용 $c_i$ 와 시너지 보정 $s$ 를 사용해 다음 조건을 검사한다.

\sum_{i=1}^{n} c_i + s \leq B_r

예를 들어 희귀 장비의 예산이 18이고 치명타 확률 +8%의 비용이 6, 치명타 피해 +20%의 비용이 7이라면 두 옵션의 동시 보유로 생기는 시너지 비용을 4로 둔다. 총비용은 17이 아니라 17+4=21이므로 해당 조합을 거절한다.

전력 예산 안에서 희귀도별 옵션 비용과 시너지 비용을 검증하는 전리품 생성 화면

옵션 풀은 어떻게 구성할까?

옵션은 자유 텍스트가 아니라 데이터 테이블의 ID로 정의한다. AI에 전달할 수 있는 정보도 이 허용 목록으로 제한한다.

옵션 ID	효과 예시	비용	태그	배타 조건
`crit_chance_08`	치명타 확률 +8%	6	공격, 치명타	없음
`crit_damage_20`	치명타 피해 +20%	7	공격, 치명타	없음
`cooldown_10`	재사용 대기시간 -10%	8	기술, 시간	`cooldown_15`
`fire_damage_12`	화염 피해 +12%	5	원소, 화염	냉기 전용 옵션

배타 조건, 직업 제한, 아이템 슬롯 제한은 생성 뒤에 수습하는 규칙이 아니라 후보를 뽑을 때부터 적용한다. 후보가 부족하면 낮은 등급의 허용 옵션을 하나 채우는 편이 무효 아이템을 버리고 재생성하는 것보다 예측 가능하다.

생성형 AI 기반 전리품 옵션과 이름은 어떻게 구현할까?

1. 서버에서 결정적 옵션을 생성한다

드롭 이벤트마다 dropId와 서버 비밀값으로 시드를 만들고 희귀도·아이템 유형·플레이어 진행도에 맞는 후보만 추출한다. 클라이언트는 결과를 표시할 뿐 최종 옵션을 결정하지 않는다.

// Unity 2022.3 LTS / C# 예시: 실제 확정과 보상 지급은 서버에서 수행한다.
public static LootRoll RollLoot(int seed, Rarity rarity, IReadOnlyList<Affix> pool)
{
    var rng = new System.Random(seed);
    var budget = rarity switch { Rarity.Rare => 18, Rarity.Epic => 28, _ => 10 };
    var picked = new List<Affix>();

    foreach (var affix in pool.OrderBy(_ => rng.Next()))
    {
        var synergy = GetSynergyCost(picked, affix);
        if (affix.IsCompatibleWith(picked) && affix.Cost + synergy <= budget)
        {
            picked.Add(affix);
            budget -= affix.Cost + synergy;
        }
    }

    return new LootRoll(seed, rarity, picked);
}

System.Random은 예시일 뿐이다. 서버와 클라이언트가 결과를 비교해야 한다면 구현과 버전 차이의 영향을 받지 않는 자체 PRNG 또는 서버 결과 전송 방식을 사용한다. 경쟁 게임이나 거래 가능한 아이템에서는 난수 시드와 비밀값을 클라이언트에 노출하지 않는다.

2. 확정된 옵션만 AI에 전달해 이름을 생성한다

모델 입력에는 옵션 ID를 사람이 읽는 속성으로 변환한 결과와 제한된 문체만 포함한다. 모델이 새 옵션을 발명하거나 수치를 바꾸지 못하도록 출력 형식을 좁힌다.

아이템 유형: 한손 검
희귀도: 희귀
확정 속성: 치명타 확률 +8%, 화염 피해 +12%
허용 문체: 다크 판타지
규칙: 한국어 이름 하나만 출력. 12자 이내. 수치, 등급, 고유명사, 욕설을 쓰지 말 것.

응답은 단순 문자열보다 JSON 스키마로 받고 길이·금칙어·중복 여부를 다시 검사한다. 예를 들어 { "name": "잿불의 송곳니" }만 허용하고 검증에 실패하면 템플릿 이름인 화염의 치명 검으로 즉시 대체한다.

3. 생성 결과를 캐시하고 버전을 기록한다

같은 옵션 조합마다 API를 다시 호출하면 비용이 늘고 아이템 정체성도 흔들린다. itemType + rarity + sortedAffixIds + styleVersion을 캐시 키로 사용한다. 프롬프트나 금칙어 정책이 바뀌면 styleVersion을 올려 새 결과만 갱신한다.

flowchart LR
    A[드롭 이벤트] --> B[서버 시드와 희귀도 결정]
    B --> C[예산·배타 규칙으로 옵션 확정]
    C --> D[옵션 조합 캐시 조회]
    D -->|있음| E[이름 표시]
    D -->|없음| F[AI 이름 생성]
    F --> G[형식·금칙어 검증]
    G -->|통과| H[캐시 저장]
    G -->|실패| I[템플릿 이름]
    H --> E
    I --> E

AI가 만든 이름의 품질과 안전성은 어떻게 관리할까?

이름 품질은 모델의 창의성보다 제약 조건의 품질에 좌우된다. 다음 항목을 자동 검사하면 운영 부담을 줄일 수 있다.

형식 검사: 최대 글자 수, 단일 이름 여부, 허용 문자, JSON 파싱을 확인한다.
의미 검사: 확정 옵션 태그와 이름의 키워드가 충돌하지 않는지 검사한다. 화염 옵션인데 빙결이 들어간 이름은 거절한다.
정책 검사: 욕설, 차별 표현, 상표·실존 인물·운영 금칙어를 차단한다.
중복 검사: 최근 생성 이름 및 고유 아이템 이름과의 완전 일치 여부를 확인한다.

LLM 심사 결과만으로 통과를 결정하지 않는 편이 좋다. 비용이 낮고 결정적인 문자열 규칙을 먼저 적용하고 의미 판정이 정말 필요한 경우에만 별도 심사를 추가한다.

게임 경제에는 어떤 영향을 주는가?

AI 이름은 전투력에 영향을 주지 않아도 수집 욕구와 거래 선호를 키울 수 있다. 따라서 같은 옵션이라도 이름의 희소성이 시장 가격을 과도하게 밀어 올리지 않는지 관찰해야 한다.

추적할 최소 지표는 다음과 같다.

지표	확인할 문제	권장 대응
희귀도별 평균 전력	특정 등급의 과성능	예산 또는 옵션 비용 조정
옵션 조합별 장착률	사실상 필수 조합	배타 조건 또는 시너지 비용 추가
이름 생성 실패율	프롬프트·필터 충돌	폴백 비율과 실패 사유 확인
이름별 거래 프리미엄	표현 희소성이 경제를 왜곡	거래 이름 공개 범위 또는 중복 정책 조정
생성 API 비용	콘텐츠 비용 급증	캐시 적중률 개선, 배치 생성

자주 묻는 질문 (FAQ)

AI가 옵션 수치까지 생성하면 더 다양한 전리품이 되지 않나?

다양성은 늘지만 밸런싱과 재현성이 급격히 나빠진다. 수치는 사전 정의된 옵션 단계에서 선택하고 AI는 이름·설명·세계관 문장에 사용하는 편이 안전하다.

모든 드롭마다 AI API를 호출해야 하나?

아니다. 옵션 조합 캐시, 사전 생성, 템플릿 폴백을 함께 사용하면 실시간 호출은 캐시 미스에만 필요하다.

생성된 이름을 플레이어가 신고할 수 있어야 하나?

공개 거래나 채팅처럼 다른 플레이어에게 노출된다면 신고 경로가 필요하다. 운영자는 생성 버전과 원본 응답을 추적할 수 있어야 재발을 막을 수 있다.

정리

생성형 AI 전리품의 안전한 역할은 무작위 수치 생성이 아니라 확정된 게임 데이터를 읽기 좋은 정체성으로 번역하는 것이다. 서버 시드와 전력 예산으로 옵션을 통제하고 제한된 입력·검증·캐시·폴백으로 이름 생성을 감싸면 콘텐츠의 신선함과 라이브 운영의 예측 가능성을 함께 얻을 수 있다.