AI 툴로 스킬 쿨타임·데미지·재화 수급 공식을 자동 스케일링하는 기획법

TL;DR

스킬 쿨타임, 데미지, 재화 수급은 각각 따로 조정하면 특정 레벨 구간에서 전투 시간과 인플레이션이 동시에 무너지기 쉽다.

기준 레벨의 목표 전투 시간(TTK, Time To Kill), 분당 보상, 장비 성장 비용을 먼저 고정하고 AI 툴에는 수식 생성보다 제약 조건 검증과 시뮬레이션 데이터 해석을 맡기면 자동 스케일링 기획을 빠르게 반복할 수 있다.

핵심은 레벨 → 전투력 → 보상 → 성장 비용이 같은 속도로 팽창하지 않도록 기준 지표를 먼저 정하고 변경 결과를 자동 검증하는 데 있다.

왜 스킬 쿨타임·데미지·재화 수급을 함께 설계해야 할까?

플레이어의 성장 체감은 공격력 하나로 결정되지 않는다. 평균 처치 시간, 스킬 사용 빈도, 소모품 비용, 장비 강화 속도가 한 루프를 이룬다. 각 값은 별개의 밸런스 항목처럼 보이지만 플레이어의 성장 체감을 함께 결정한다.

예를 들어 데미지만 빠르게 증가하면 적 처치 시간이 짧아져 분당 골드가 의도보다 높아지고 재화 수급이 낮아지면 다음 성장 목표까지 걸리는 시간이 과도하게 길어진다.

자동 스케일링의 목표는 모든 수치를 동일한 비율로 올리는 것이 아니다. 레벨 구간마다 아래 지표를 목표 범위 안에 유지하는 것이다.

지표	권장 정의	확인 목적
평균 처치 시간(TTK)	일반 몬스터 1마리를 처치하는 데 걸리는 평균 시간(초)	전투 템포 유지
분당 피해량(DPM)	단일 대상에게 실제로 적용되는 1분당 평균 피해량	쿨타임과 스킬 사용 주기 검증
분당 순재화	획득 재화 - 필수 소모 재화	경제 성장 속도 검증
다음 성장까지 시간	다음 장비 또는 레벨 목표까지 필요한 플레이 시간	장기 동기 유지

자동화의 목표는 모든 레벨을 같은 난이도로 만드는 것이 아니다. 일반 전투는 성장 체감을 주고 엘리트와 보스는 패턴 대응 시간을 보장하며 경제 시스템은 다음 목표가 보이면서도 과도한 반복을 요구하지 않도록 만드는 것이다.

항목	직접 영향	함께 확인할 지표	흔한 문제
스킬 쿨타임	행동 빈도, 지속 DPS	분당 시전 횟수, 조작 피로도	고레벨에서 하한에 너무 빨리 도달
스킬 데미지	처치 시간, 보스 패턴 노출	TTK, DPS, 회복량 대비 피해량	특정 계수 조합이 폭발적으로 강해짐
재화 보상	성장 속도, 경제 인플레이션	분당 획득량, 강화 완료 시간	전투 효율 증가분이 보상에 중복 반영됨
성장 비용	목표 레벨 도달 시간	재화 소비처(싱크), 이탈 구간	후반 진입 장벽 또는 재화 과잉

레벨 구간별 전투 시간과 재화 흐름을 함께 보여 주는 게임 밸런싱 대시보드

자동 스케일링 공식은 어떻게 설계할까?

1. 기준 레벨과 목표 지표를 먼저 고정한다

먼저 대표 구간 하나를 기준점으로 정한다. 예를 들어 레벨 20에서 일반 몬스터 체력은 1,500, 목표 TTK는 6초, 플레이어의 목표 DPM은 15,000으로 둔다. 이 기준점이 없으면 AI가 그럴듯한 곡선을 제안해도 좋은 밸런스인지 판단할 수 없다.

기본 입력값은 다음처럼 표로 관리하면 된다.

파라미터	예시	설명
`baseLevel`	20	기준 레벨
`targetTTK`	6초	일반 몬스터 목표 처치 시간
`targetDPM`	15,000	목표 분당 피해량
`targetNetGoldPerMinute`	420	필수 비용 차감 후 분당 재화
`growthLevelRange`	1~60	검증할 레벨 범위

2. 데미지와 몬스터 체력을 같은 목표 함수에 연결한다

레벨 L에서 플레이어의 단일 대상 기준 기대 분당 피해량을 DPM(L)이라고 하면, 목표 TTK를 만족하는 몬스터 체력 HP(L)은 다음처럼 계산할 수 있다.

HP(L)=DPM(L)\times\frac{TTK(L)}{60}

단순 지수 성장은 후반 수치가 지나치게 커지기 쉽다. 이 글의 예시는 기준 관계를 설명하기 위해 지수식을 사용하지만 실제 설계에서는 초반 성장 속도는 빠르고 중후반으로 갈수록 완만해지는 멱함수나 멱함수·지수 혼합식을 검토하는 편이 안전하다.

DPM(L)=DPM_{base}\times\left(1+g\right)^{L-baseLevel}

여기서 g는 레벨당 성장률이다. 다만 치명타, 명중, 방어력 관통, 다단히트처럼 곱연산이 많은 게임은 캐릭터 공격력만으로 DPM을 계산하면 안 된다. 실제 전투 시뮬레이션의 평균 피해량을 사용해야 한다.

3. 쿨타임은 스킬 사용 주기를 기준으로 계산한다

스킬 i의 피해량을 $damage_i$ , 쿨타임을 $cooldown_i$ , 시전 시간을 $castTime_i$ 라고 하자. 아래 식은 각 스킬의 쿨타임이 시전 시작과 동시에 감소하고 글로벌 쿨타임·자원 부족·스킬 간 충돌이 없다고 가정한 단순 모델이다.

DPS_{skill}=\sum_{i=1}^{n}\frac{damage_i}{\max(cooldown_i,castTime_i)}

하지만 실제 전투에는 이동, 회피, 자원 부족, 목표 전환이 있다. 따라서 기획 단계에서는 이론 DPS와 실전 보정 DPS를 분리한다.

DPS_{effective}=DPS_{skill}\times uptime\times hitRate

uptime은 실제로 공격 가능한 시간 비율이며 hitRate는 광역기와 투사체를 포함한 유효 적중률이다. 두 값은 서로 중복되지 않도록 정의해야 한다. AI 툴에 수식을 요청할 때도 이 두 값을 생략하지 않는 것이 중요하다. 누락하면 쿨타임 단축 효과를 실제보다 크게 평가하는 결과가 나온다.

AI 툴로 밸런싱 시뮬레이션을 만드는 3단계

1. 입력 데이터와 변경 가능한 파라미터를 분리한다

AI에게 모든 값을 자유롭게 조정하게 하면 목표를 만족하는 대신 게임의 정체성이 바뀔 수 있다. 변경 금지 데이터와 조정 허용 파라미터를 분리한다.

변경 금지: 목표 TTK, 보스 패턴 주기, 스킬 콘셉트, 장비 획득 조건
조정 허용: 스킬 계수, 쿨타임, 몬스터 체력 계수, 드롭 수량, 강화 비용
검증 지표: TTK, DPM, 분당 순재화, 성장 목표 도달 시간

AI 프롬프트에는 레벨별 입력 테이블과 함께 목표에서 벗어난 행만 표시, 조정 폭은 기존 값의 ±10%로 제한처럼 명확한 제약을 넣는다. 생성형 AI는 답을 만들기 쉽지만 제약이 없는 최적화 문제에서는 설계 의도까지 바꿔 버릴 수 있다.

2. 스프레드시트 또는 스크립트용 계산식을 생성한다

아래 TypeScript 예시는 레벨별 몬스터 체력과 재화 보상을 계산하는 최소 모델이다. AI에게는 이 코드를 기반으로 CSV 입력, 이상치 탐지, 차트용 출력 열을 추가해 달라고 요청할 수 있다.

type BalanceRow = {
  level: number;
  dpm: number;
  targetTtkSeconds: number;
  hp: number;
  grossGoldPerMinute: number;
  consumableCostPerMinute: number;
  netGoldPerMinute: number;
};

const scale = (
  base: number,
  growth: number,
  level: number,
  baseLevel: number,
) => base * Math.pow(1 + growth, level - baseLevel);

function buildBalanceRow(level: number): BalanceRow {
  const baseLevel = 20;
  const dpm = scale(15_000, 0.055, level, baseLevel);
  const targetTtkSeconds = level < 40 ? 6 : 7;
  const hp = dpm * (targetTtkSeconds / 60);
  const grossGoldPerMinute = scale(500, 0.045, level, baseLevel);
  const consumableCostPerMinute = scale(80, 0.035, level, baseLevel);

  return {
    level,
    dpm: Math.round(dpm),
    targetTtkSeconds,
    hp: Math.round(hp),
    grossGoldPerMinute: Math.round(grossGoldPerMinute),
    consumableCostPerMinute: Math.round(consumableCostPerMinute),
    netGoldPerMinute: Math.round(grossGoldPerMinute - consumableCostPerMinute),
  };
}

const rows = Array.from({ length: 60 }, (_, index) =>
  buildBalanceRow(index + 1),
);

핵심은 코드 자동 생성 자체가 아니다. 같은 입력값으로 언제든 다시 계산할 수 있는 구조를 만드는 데 있다. 수동으로 수치를 덮어쓰는 시트는 변경 이력을 잃고 패치마다 밸런스 회귀 버그를 만들기 쉽다.

3. AI에게 이상치 분석을 맡기고 사람은 의도를 판정한다

레벨별 결과를 CSV 또는 Markdown 표로 제공한 뒤 다음 질문을 사용한다.

레벨 1~60 데이터에서 목표 TTK 6~7초를 벗어난 구간, 직전 레벨 대비 분당 순재화 성장률이 5%를 초과하는 구간, 다음 장비 구매 시간이 직전 구간보다 20% 이상 증가하는 구간을 찾아 원인 후보를 표로 정리해 줘. 수치 수정안은 각 파라미터당 ±10% 이내로 제안해 줘.

AI는 반복 계산, 정렬, 이상치 후보 추출에 적합하다. 반면 “레벨 35에서 성장 피로를 의도적으로 줄 것인가” 같은 판단은 플레이 경험과 콘텐츠 맥락이 필요하므로 디자이너가 결정해야 한다.

AI 툴을 이용한 밸런싱 자동화 절차

Step 1. 기획 입력을 구조화된 데이터로 만든다

자연어 요구사항만으로 AI에게 “밸런스를 맞춰 달라”고 요청하면 일관된 결과를 얻기 어렵다. 스프레드시트나 JSON에 기준값, 범위, 금지 조건을 명시한다.

{
  "levelRange": [1, 30],
  "targetTTK": { "normal": 4.5, "elite": 18, "boss": 90 },
  "cooldown": { "minSeconds": 1.5, "maxCdr": 0.4 },
  "economy": { "targetMinutesPerUpgrade": 12, "incomeTolerance": 0.1 },
  "constraints": [
    "normal TTK must remain within 4 to 6 seconds",
    "skill casts per minute must not exceed 24",
    "income per minute must not exceed upgrade cost / 8"
  ]
}

AI 툴에는 이 데이터를 제공하고 레벨별 HP, DPS, 쿨타임, 분당 재화, 강화 비용, 목표 대비 오차 열을 가진 CSV 또는 Markdown 표를 생성하도록 요청한다. 결과는 초안일 뿐이며 수식과 제한 조건은 데이터 원본 또는 코드에서 계산되게 유지한다.

Step 2. AI에게 이상치 탐지와 시나리오 비교를 맡긴다

생성형 AI는 수치의 최종 권위자가 아니라 검토 보조자에 적합하다. 다음과 같이 비교 가능한 질문을 사용한다.

레벨 1~30 중 목표 TTK에서 10% 이상 벗어난 구간을 찾아 달라.
치명타 확률 50%, 쿨타임 감소 40% 조합에서 최대 DPS가 기준 DPS의 몇 배인지 계산해 달라.
분당 수급량이 강화 비용의 1/8을 초과하는 레벨 구간을 표시해 달라.
일반 몬스터와 보스의 TTK 곡선이 역전되는 구간이 있는지 확인해 달라.

프롬프트에는 단위와 반올림 규칙을 포함한다. 예를 들어 시간은 초 단위 소수점 첫째 자리, 재화는 정수 반올림, 비율은 백분율 소수점 첫째 자리로 고정한다. 모델마다 계산 결과가 달라질 수 있으므로 최종 산술은 스프레드시트 수식, TypeScript, Python, Unity C# 등 재현 가능한 계산기로 검증한다.

Step 3. 변경 전후를 시뮬레이션하고 승인 기준을 적용한다

자동 생성한 수치가 안전한지는 단일 레벨의 평균 DPS가 아니라 플레이 세션 전체에서 판단한다. 최소한 기준 장비, 성장 장비, 최적화 장비의 세 프리셋을 만들고 각 프리셋을 레벨 구간별로 실행한다.

flowchart LR
    A[기획 목표: TTK·수급량·비용] --> B[수식과 제약 조건 정의]
    B --> C[AI로 표 생성·이상치 후보 탐지]
    C --> D[스프레드시트 또는 코드로 재계산]
    D --> E{승인 기준 충족?}
    E -- 아니오 --> B
    E -- 예 --> F[플레이테스트와 텔레메트리]
    F --> A

승인 기준의 예시는 다음과 같다.

검증 항목	승인 기준
일반 몬스터 TTK	목표값 대비 ±10% 이내
보스 TTK	목표값 대비 ±15% 이내
분당 재화 수급량	목표값 대비 ±10% 이내
스킬 시전 빈도	스킬별 설계 상한 이하
최대 조합 DPS	기준 조합의 사전 정의된 배율 이하
다음 강화까지 시간	의도한 세션 길이 범위 내

기준 장비와 최적화 장비의 레벨별 TTK 및 분당 재화 수급량 비교 그래프

Unity C#에서 재현 가능한 스케일링 함수를 만들기

기획 수식과 런타임 구현이 다르면 밸런스 표는 빠르게 신뢰를 잃는다. 아래 예시는 레벨 진행도 기반의 피해량, 쿨타임, 처치 보상을 한 곳에서 계산하는 Unity C# 코드다.

using UnityEngine;

public static class BalanceFormula
{
    public static float Progress(int level, int minLevel, int maxLevel)
    {
        return Mathf.InverseLerp(minLevel, maxLevel, level);
    }

    public static float Damage(int level, float baseDamage, float growth)
    {
        float p = Progress(level, 1, 30);
        return baseDamage * Mathf.Pow(1f + growth, p);
    }

    public static float Cooldown(float baseCooldown, float cooldownReduction, float minCooldown)
    {
        float clampedCdr = Mathf.Clamp(cooldownReduction, 0f, 0.40f);
        return Mathf.Max(minCooldown, baseCooldown * (1f - clampedCdr));
    }

    public static int GoldReward(int level, int baseGold, float growth)
    {
        float p = Progress(level, 1, 30);
        return Mathf.RoundToInt(baseGold * Mathf.Pow(1f + growth, p));
    }
}

이 함수는 예시이므로 실제 프로젝트에서는 난이도 계수, 파티 인원, 스테이지 보정, 휴식 보상 등을 별도 계수로 분리하는 편이 좋다. 하나의 growth 값에 모든 보정을 섞으면 어느 시스템이 인플레이션을 일으켰는지 추적하기 어렵다.

재화 수급 공식은 어떤 방식으로 연결해야 할까?

경제 밸런싱에서는 획득량보다 순재화와 소비처를 함께 본다. 레벨 L의 분당 순재화는 다음처럼 정의할 수 있다.

NetCurrency(L)=DropCurrency(L)+QuestCurrency(L)-MandatorySink(L)

다음 장비 구매까지 필요한 예상 시간(분)은 장비 가격과 분당 순재화의 비율로 계산한다. 단, 순재화가 0 이하이면 구매 시간을 계산할 수 없으므로 ‘구매 불가’ 또는 무한대로 처리한다.

TimeToUpgrade(L)=\frac{UpgradeCost(L)}{NetCurrency(L)}

이 값이 레벨이 오를수록 계속 커지면 플레이어는 강해지고 있어도 성장이 느려졌다고 느낀다. 반대로 업그레이드까지 필요한 시간이 너무 빠르게 줄어들면 장비 획득이 콘텐츠 소모 속도를 앞지른다.

증상	흔한 원인	우선 확인할 값
후반 골드가 남아돈다	드롭 성장률이 강화 비용 성장률보다 높음	`grossGoldPerMinute`, `UpgradeCost`
포션 사용이 손해처럼 느껴진다	필수 소모 비용이 수급 대비 과도함	`MandatorySink`, 회복 효율
퀘스트만 하는 편이 유리하다	전투 보상과 퀘스트 보상 간 단위 시간이 다름	활동별 분당 순재화
특정 구간에서 막힌다	다음 업그레이드 비용이 급격히 증가함	`TimeToUpgrade`

보상은 몬스터 한 마리당 수치보다 활동 단위로 환산해야 비교하기 쉽다. 사냥, 던전, 일일 퀘스트의 보상을 모두 분당 순재화 또는 10분당 성장 기여도로 변환하면 AI 분석 결과도 더 일관된다.

자동 스케일링에서 반드시 검증할 회귀 시나리오

공식이 맞아도 콘텐츠 조합에 따라 결과가 달라진다. 최소한 아래 시나리오는 자동 테스트 표에 포함한다.

단일 대상 지속 전투: 기본 스킬 사용 주기로 목표 TTK와 DPM을 검증한다.
광역 사냥: 다수 적중 시 분당 재화와 경험치가 기준치를 초과하지 않는지 확인한다.
쿨타임 감소 빌드: 쿨타임 감소 옵션이 특정 임계점에서 무한 회전을 만들지 검증한다.
장비 수준이 낮거나 높은 경우: 장비 편차가 큰 플레이어도 콘텐츠 진입 시간이 과도하게 벌어지지 않는지 확인한다.
소모품 사용 조건: 회복 아이템 비용을 뺀 순재화가 음수가 되지 않는지 확인한다.

특히 쿨타임 감소는 아래와 같이 쿨타임이 0 이하로 내려가지 않도록 하한값을 둬야 한다.

Cooldown_{final}=\max(Cooldown_{min},Cooldown_{base}\times(1-CDR))

CDR은 0~1 범위로 제한하고 필요하면 스킬별 최소 쿨타임에 맞춰 상한을 계산한다. Cooldown_min은 스킬 연출과 입력 처리, 서버 틱, 애니메이션 캔슬 규칙까지 고려해 정한다. 클라이언트의 프레임 속도만 기준으로 정하면 네트워크 환경에서 의도하지 않은 연속 시전 문제가 생길 수 있다.

자동 스케일링에서 자주 발생하는 실패 패턴

AI가 만든 숫자를 그대로 적용하는 문제

AI는 제약을 누락하거나 서로 충돌하는 목표를 그럴듯하게 처리할 수 있다. 생성 결과는 반드시 테스트 가능한 표와 코드 수식으로 바꿔야 한다. 특히 ‘재미있는 성장감’ 같은 정성 목표는 수치 하나로 해결되지 않으므로 플레이테스트 관찰 기록과 함께 판단한다.

평균값만 보고 최대 조합을 놓치는 문제

평균 장비 기준 TTK가 정상이어도 쿨타임 감소, 치명타, 추가타, 방어력 감소가 겹치면 보스가 패턴을 쓰기 전에 처치될 수 있다. 최저 성능, 기준 성능, 최고 성능 프리셋을 모두 검증 대상에 포함한다.

보상과 비용을 독립적으로 수정하는 문제

신규 이벤트에서 보상을 올린 뒤 강화 비용까지 별도로 낮추면 각각은 작은 수정이어도 경제 전체에는 큰 배수 효과가 난다. 변경 요청마다 IncomePerMinute, 업그레이드당 필요 시간, 보유 재화 중앙값을 함께 기록한다.

자주 묻는 질문 (FAQ)

AI가 제안한 밸런스 수치를 그대로 적용해도 될까?

안 된다. AI 제안은 계산 가능한 후보안이다. 실제 적용 전에는 플레이 테스트, 로그 기반 전투 데이터, 콘텐츠 소모 속도를 함께 검토해야 한다.

초반과 후반에 같은 성장 공식을 써도 될까?

가능하지만 권장되지는 않는다. 초반은 조작 학습과 즉각적인 보상이 중요하고 후반에는 빌드 선택의 폭이 넓어지며 장비 조합의 중요도가 커진다. 구간별 목표 TTK와 성장률을 달리 두는 편이 일반적으로 조정하기 쉽다.

쿨타임 감소 옵션의 상한은 어떻게 정할까?

가장 강한 스킬 조합에서 실제 시전 시간, 자원 회복, 서버 틱을 적용한 뒤 무한 회전이 생기지 않는 값으로 정한다. 단순히 40%나 50% 같은 관행적 숫자를 먼저 정하지 말고 전투 시뮬레이션 결과를 기준으로 잡아야 한다.

재화 수급량은 어떤 지표로 확인해야 할까?

처치당 보상만 보지 말고 분당 수급량, 다음 강화까지 걸리는 시간, 세션 종료 시 잔여 재화를 함께 본다. 전투력이 오르면 처치 수가 달라지므로 분당 기준이 경제 체감에 더 직접적이다.

정리

AI 툴을 활용한 자동 스케일링은 밸런싱 판단을 대신하는 기능이 아니라 반복 계산과 이상치 탐색을 자동화하는 작업 방식이다.

기준 레벨의 TTK와 DPM, 분당 순재화, 다음 성장까지 시간을 하나의 데이터 모델로 연결하고 수치 변경 폭과 검증 조건을 명시하자. 그러면 쿨타임 조정 하나가 전투 템포와 경제에 미치는 영향을 패치 전에 더 빠르고 일관되게 확인할 수 있다.