유저 플레이 데이터로 난이도 곡선을 재설계한 라이브 운영 사례

핵심 요약

난이도 곡선은 평균 클리어 시간만으로 판단하면 안 된다. 스테이지별 진입 대비 이탈률, 실패율, 재시도 횟수, 체력 소진량을 함께 보면 유저가 ‘도전 중’인지 ‘막혀서 포기 중’인지 구분할 수 있다. 이 글은 Unity 2022.3 LTS와 C# 이벤트 로그를 기준으로 병목 구간을 찾고 난이도와 보상을 조정한 분석 절차를 정리한 사례다.

난이도 곡선은 왜 플레이 데이터로 다시 설계해야 하는가?

출시 전 QA는 콘텐츠가 의도대로 작동하는지 검증하는 데 강하다. 하지만 실제 라이브 환경에서는 숙련도, 기기 성능, 플레이 시간, 과금 여부가 서로 다른 유저가 동시에 유입된다. 내부 테스터의 체감 난이도만으로는 특정 구간의 이탈 원인을 충분히 설명하기 어렵다.

예를 들어 챕터 3의 보스 스테이지에서 클리어율이 낮다고 해서 보스 체력만 낮추면 문제를 놓칠 수 있다. 진짜 원인은 직전 스테이지에서 회복 아이템이 부족한 것, 공격 전조가 모바일 화면에서 잘 보이지 않는 것, 패배 후 재도전까지의 흐름이 긴 것일 수 있다.

지표	계산 기준	해석
진입 대비 이탈률	스테이지 진입 후 다음 이벤트 없이 세션 종료한 유저 / 진입 유저	진입 장벽 또는 피로도를 확인한다.
실패율	실패 횟수 / 도전 횟수	전투 또는 퍼즐의 순수 난이도를 본다.
평균 재시도 횟수	실패 후 같은 스테이지 재진입 횟수의 평균	도전 의지와 좌절을 구분하는 보조 지표다.
클리어 시간 중앙값	클리어 유저의 플레이 시간 중앙값	일부 장기 플레이어의 영향을 줄인다.
체력 소진 중앙값	클리어 시점의 최대 체력 대비 손실 비율	다음 구간으로 이어질 여유를 확인한다.

어떤 플레이 로그를 수집해야 병목 구간을 찾을 수 있을까?

모든 행동을 수집할 필요는 없다. 난이도 판단에 직접 연결되는 전환 지점만 남기면 비용과 분석 복잡도를 줄일 수 있다. 아래 이벤트는 최소 구성이다.

// Unity 2022.3 LTS / C#
public static void LogStageResult(string stageId, bool cleared, int attempts, float elapsedSeconds, float hpRatio)
{
    Analytics.CustomEvent("stage_result", new Dictionary<string, object>
    {
        { "stage_id", stageId },
        { "cleared", cleared },
        { "attempts", attempts },
        { "elapsed_seconds", Mathf.RoundToInt(elapsedSeconds) },
        { "hp_ratio", Mathf.Round(hpRatio * 100f) / 100f }
    });
}

개인 식별 정보, 채팅 원문, 불필요한 입력 로그는 난이도 분석에 필요하지 않다. 익명 사용자 ID와 빌드 버전, 스테이지 ID, 결과 중심으로 수집 범위를 제한하는 편이 운영과 개인정보 관리 모두에 유리하다.

실패율만 보면 안 되는 이유는 무엇인가?

실패율 60%인 두 스테이지도 성격이 다를 수 있다. A 스테이지는 평균 2.1회 만에 재도전해 결국 통과하지만 B 스테이지는 첫 실패 뒤 세션 종료가 많다면 B가 우선 수정 대상이다.

구간 우선순위는 하나의 점수로 정렬할 수 있다. 아래 식은 운영 판단을 돕기 위한 예시이며 각 게임의 장르와 세션 길이에 맞춰 가중치를 조정해야 한다.

$$\text{BottleneckScore}=0.45\times\text{FailRate}+0.35\times\text{ExitRate}+0.20\times\min(\text{RetryRate},1)$$

사례: 챕터 3 보스에서 발생한 이탈을 어떻게 진단했는가?

아래는 특정 상용 게임의 수치를 주장하는 내용이 아니라 라이브 서비스에서 재현 가능한 분석 사례다. 분석 대상은 스테이지형 액션 게임의 챕터 3 보스 B3-10으로 가정했다.

구간	실패율	다음 스테이지 진입률	평균 재시도	관찰 결과
B3-08	31%	82%	1.4회	정상 범위
B3-09	38%	78%	1.8회	전투 강도 상승
B3-10	64%	41%	1.2회	실패 후 이탈이 급증
B3-11	22%	89%	1.1회	B3-10 통과 유저는 안정적

B3-10의 핵심 신호는 높은 실패율 자체보다 낮은 재시도 횟수였다. 리플레이와 사망 원인 이벤트를 확인하니 보스의 광역 공격 전조가 짧고 직전 두 스테이지에서 회복 수단을 사용할 가능성이 높았다. 즉, 보스의 단일 수치보다 ‘진입 자원 부족 + 읽기 어려운 패턴’이 함께 작동한 문제였다.

flowchart TD
    A[스테이지 결과 로그 수집] --> B[실패율·이탈률·재시도 분석]
    B --> C{병목 점수 상위 구간인가?}
    C -- 아니오 --> D[다음 배포까지 관찰]
    C -- 예 --> E[리플레이·사망 원인 확인]
    E --> F[난이도 또는 보상 가설 수립]
    F --> G[A/B 대상 그룹 배포]
    G --> H[클리어율과 다음 구간 진입률 비교]

유저 플레이 데이터로 난이도 곡선을 어떻게 재설계할까?

1. 병목 지표를 같은 시간 창에서 비교한다

패치 전후 비교는 같은 요일과 동일한 신규 유저 구간으로 맞춘다. 주말 이벤트나 광고 캠페인이 섞이면 난이도 변경 효과를 잘못 해석할 수 있다. 최소한 install_cohort, app_version, stage_id를 기준으로 분리한다.

2. 원인 하나당 수정 가설 하나를 만든다

이 사례에서는 다음 세 가지를 동시에 바꾸지 않고 원인과 대응을 연결했다.

• 광역 공격 전조 시간을 0.55초에서 0.85초로 늘린다.
• B3-09 클리어 보상을 소형 회복 아이템 1개로 조정한다.
• 첫 보스 패배 뒤 재도전 화면에 공격 회피 타이밍 안내를 한 줄 표시한다.

보스 최대 체력을 일괄 하향하는 방식은 가장 빠르지만 패턴 가독성 문제와 자원 흐름 문제를 가린다. 먼저 실패 원인에 맞는 작은 조정을 적용하는 편이 다음 패치의 판단 근거를 남긴다.

3. 성공 기준을 클리어율 하나로 고정하지 않는다

목표는 모든 유저가 첫 시도에 통과하는 것이 아니다. 예를 들어 다음 기준을 함께 본다.

지표	변경 전	목표 예시	확인 의미
B3-10 실패율	64%	45~55%	긴장감은 유지하고 과도한 막힘은 완화
실패 후 세션 종료율	37%	20% 이하	좌절 이탈 감소
평균 재시도 횟수	1.2회	1.8~2.5회	재도전 동기 회복
B3-11 진입률	41%	60% 이상	다음 콘텐츠로의 전환 개선

A/B 테스트가 가능하다면 기존 난이도와 조정 난이도를 신규 유저에게 무작위 배정한다. 표본이 작다면 전면 배포 후에도 빌드 버전별 코호트를 분리해 최소 3~7일은 추적해야 한다. 단, 정확한 기간은 일일 신규 유저 수와 목표 지표의 변동성에 따라 정한다.

패치 후에는 무엇을 검증해야 하는가?

난이도 패치는 수치 수정으로 끝나지 않는다. QA와 라이브 운영은 다음 순서로 확인한다.

1. 기능 회귀를 확인한다. 공격 전조 애니메이션, 충돌 판정, 보상 지급, 재도전 화면이 의도대로 동작하는지 테스트한다.
2. 세그먼트를 나눠 확인한다. 신규 유저, 복귀 유저, 고성능·저성능 기기, 컨트롤러·터치 입력군에서 지표가 다르게 변하는지 본다.
3. 후속 구간을 확인한다. B3-10 통과율만 오르고 B3-11 이탈이 증가했다면 난이도를 뒤로 밀어낸 것일 수 있다.

크래시율, ANR, 프레임 타임도 함께 확인해야 한다. 전조 이펙트나 UI 안내를 추가한 패치가 저사양 기기의 렌더링 부하를 높이면 플레이 데이터 자체가 왜곡될 수 있다.

자주 묻는 질문 (FAQ)

난이도 조정은 실패율이 몇 퍼센트일 때 해야 하나?

고정된 정답은 없다. 실패율보다 실패 뒤 세션 종료율, 재시도 횟수, 다음 스테이지 진입률이 함께 악화되는지 보는 것이 안전하다.

데이터가 적은 인디 게임도 난이도 분석이 가능한가?

가능하다. 스테이지 시작·성공·실패·세션 종료 네 이벤트만으로도 병목 후보를 찾을 수 있다. 표본이 작을수록 큰 수치 변경보다 작은 패치와 긴 관찰 기간이 적합하다.

A/B 테스트 없이 난이도를 바꿔도 되는가?

가능하지만 비교 기준을 미리 정해야 한다. 같은 유입 채널, 빌드 버전, 플레이 시작일을 기준으로 패치 전후 코호트를 분리해 해석한다.

정리

좋은 난이도 곡선은 실패를 없애는 것이 아니라 실패 후에도 유저가 다시 시도할 이유를 남기는 구조다. 스테이지별 실패율과 이탈률을 함께 보고 리플레이·사망 원인으로 가설을 좁힌 뒤 작은 패치를 지표로 검증하면 감각에만 의존한 밸런싱보다 훨씬 안전하게 라이브 난이도를 조정할 수 있다.