Choice Overload 측정: 게임 메뉴 선택지와 결정 시간을 로그로 줄이는 방법

핵심 요약

Choice Overload는 선택지 수가 늘어날수록 플레이어의 비교 비용과 결정 시간이 증가하고 선택 중단이나 되돌아가기가 발생하는 현상입니다. menu_open, option_impression, selection_confirmed, menu_close 로그를 남겨 DecisionTime, p50·p90, 이탈률, 되돌아가기 비율을 메뉴별로 비교하면 문제 구간을 찾을 수 있습니다.

해결은 선택지를 무조건 삭제하는 것이 아니라 그룹화, 단계적 공개, 최근 사용 항목, 상황별 기본값, 검색과 필터를 조합한 뒤 동일한 조건에서 A/B 테스트하는 방식으로 진행합니다.

Choice Overload는 왜 발생하는가?

선택지가 많다는 사실 자체가 항상 문제는 아닙니다. 플레이어가 각 항목의 차이를 빠르게 이해하고 목적에 맞는 항목을 예측할 수 있다면 많은 선택지도 처리할 수 있습니다.

문제는 다음 세 가지 비용이 동시에 커질 때 발생합니다.

비용	설명	로그에서 관찰할 신호
비교 비용	여러 선택지의 효과와 차이를 비교하는 데 드는 시간	결정 시간 증가, 마우스 이동 증가
탐색 비용	원하는 항목이 어느 탭이나 카테고리에 있는지 찾는 시간	탭 이동, 스크롤, 검색 반복
되돌림 비용	잘못 선택했을 때 이전 메뉴로 돌아가 다시 고르는 비용	`back`, 메뉴 재진입, 선택 취소

특히 장비 강화, 스킬 트리, 제작 레시피, 퀘스트 보상, 상점처럼 항목 간 차이가 작고 결과가 중요한 메뉴에서 Choice Overload가 두드러집니다. 플레이어가 신중해지는 것은 자연스러운 행동이지만 다음 행동으로 넘어가지 못하거나 메뉴를 닫고 포기한다면 UX 문제로 봐야 합니다.

결정 시간을 어떤 로그로 측정할까?

핵심은 메뉴를 연 시점부터 재는 것이 아니라 플레이어가 선택지를 실제로 인식할 수 있게 된 시점부터 재는 것입니다. 애니메이션, 네트워크 지연, 로딩 시간을 포함하면 UI의 선택 부담과 기술적 지연이 섞입니다.

기준 시점 정의

DecisionTime = t_{confirm} - t_{ready}

t_ready: 메뉴가 표시되고 첫 입력이 가능한 시점
t_confirm: 플레이어가 항목을 확정한 시점
DecisionTime: 선택지 확인부터 확정까지 걸린 시간

메뉴를 닫거나 뒤로 돌아간 경우에는 확정되지 않은 세션으로 별도 기록합니다. 일정 시간 이상 입력이 없었다면 AFK나 이탈 가능성이 있으므로 정상적인 결정 시간과 분리하는 편이 좋습니다.

권장 이벤트 스키마

최소한 다음 필드를 모든 메뉴 이벤트에 공통으로 넣습니다.

필드	예시	목적
`event_name`	`selection_confirmed`	이벤트 종류 구분
`menu_id`	`inventory_weapon`	메뉴별 비교
`session_id`	익명 세션 ID	한 번의 메뉴 사용 흐름 연결
`build_version`	`1.4.2`	패치 전후 비교
`option_count`	`18`	선택지 수와 성과 비교
`menu_depth`	`2`	메뉴 깊이에 따른 탐색 비용 확인
`option_id`	`sword_03`	어떤 항목을 선택했는지 확인
`decision_ms`	`4280`	결정 시간 분석
`input_method`	`mouse`, `gamepad`	입력 장치별 편차 통제
`opened_at`	서버 또는 클라이언트 시각	이벤트 순서 복원

개인정보가 포함된 텍스트나 원본 입력 기록은 기본 로그에 넣지 않습니다. 플레이어 식별이 필요하지 않다면 익명화된 세션 ID와 빌드 버전만 사용해도 충분합니다.

로그 이벤트 흐름

일반적인 선택 메뉴에서는 다음과 같은 이벤트를 기록할 수 있습니다.

menu_open: 메뉴가 열림
menu_ready: 선택지가 표시되고 입력 가능 상태가 됨
option_focus: 키보드 포커스나 커서가 특정 항목에 도달함
option_preview: 툴팁이나 상세 정보가 열림
selection_confirmed: 선택이 확정됨
menu_back: 이전 메뉴로 돌아감
menu_close: 메뉴가 닫힘
menu_timeout: 일정 시간 동안 유효한 상호작용이 없음

option_focus를 무조건 모든 프레임에 기록하면 데이터가 지나치게 커집니다. 포커스 대상이 바뀔 때만 기록하고 동일한 항목에 머문 시간은 클라이언트에서 집계한 뒤 전송하는 방식이 효율적입니다.

Unity에서 Choice Overload 로그를 어떻게 구현할까?

Unity에서는 Time.realtimeSinceStartup을 사용하면 게임 일시정지나 게임 속도 조절의 영향을 덜 받는 실시간 기준을 만들 수 있습니다. 실제 프로젝트에서는 이벤트 큐와 배치 전송을 함께 사용해 메뉴 조작이 네트워크 요청 때문에 지연되지 않도록 합니다.

using System.Collections.Generic;
using UnityEngine;

public sealed class MenuTelemetry
{
    private string menuId;
    private string sessionId;
    private float readyAt;
    private int optionCount;
    private int backCount;
    private bool isOpen;

    public void Open(string id, string session, int count, int depth)
    {
        menuId = id;
        sessionId = session;
        optionCount = count;
        backCount = 0;
        isOpen = true;

        Send("menu_open", new Dictionary<string, object>
        {
            ["menu_id"] = menuId,
            ["session_id"] = sessionId,
            ["option_count"] = optionCount,
            ["menu_depth"] = depth
        });
    }

    public void MarkReady()
    {
        if (!isOpen) return;
        readyAt = Time.realtimeSinceStartup;
        Send("menu_ready", new Dictionary<string, object>
        {
            ["menu_id"] = menuId,
            ["option_count"] = optionCount
        });
    }

    public void Confirm(string optionId, int visibleOptionCount)
    {
        if (!isOpen) return;

        int decisionMs = Mathf.RoundToInt(
            (Time.realtimeSinceStartup - readyAt) * 1000f);

        Send("selection_confirmed", new Dictionary<string, object>
        {
            ["menu_id"] = menuId,
            ["session_id"] = sessionId,
            ["option_id"] = optionId,
            ["option_count"] = optionCount,
            ["visible_option_count"] = visibleOptionCount,
            ["decision_ms"] = decisionMs,
            ["back_count"] = backCount
        });

        isOpen = false;
    }

    public void Back()
    {
        if (!isOpen) return;
        backCount++;
        Send("menu_back", new Dictionary<string, object>
        {
            ["menu_id"] = menuId,
            ["session_id"] = sessionId,
            ["back_count"] = backCount,
            ["elapsed_ms"] = Mathf.RoundToInt(
                (Time.realtimeSinceStartup - readyAt) * 1000f)
        });
    }

    private void Send(string eventName, Dictionary<string, object> data)
    {
        data["event_name"] = eventName;
        data["build_version"] = Application.version;
        data["input_method"] = DetectInputMethod();

        // 실제 프로젝트에서는 이벤트 큐에 넣고 배치 전송한다.
        Debug.Log($"Telemetry: {eventName}");
    }

    private string DetectInputMethod()
    {
        return "unknown";
    }
}

이 코드에서 중요한 부분은 MarkReady()를 별도로 둔 점입니다. Open() 직후에 시간을 재면 메뉴 애니메이션과 데이터 바인딩 지연이 결정 시간에 포함될 수 있습니다.

운영 환경에서는 다음 항목도 함께 고려합니다.

전송 실패에 대비한 로컬 이벤트 큐
한 세션에서 동일 메뉴를 여러 번 연 경우의 시도 번호
decision_ms의 상한값과 이상치 처리
튜토리얼이나 컷신 중 발생한 이벤트의 별도 분류
오프라인 플레이 후 재접속 시 이벤트 순서 보정

Choice Overload를 판단하는 핵심 지표는 무엇인가?

평균 결정 시간 하나만 보면 일부 매우 긴 세션이 전체 결과를 왜곡할 수 있습니다. 기본 리포트는 중앙값과 상위 백분위수를 함께 보여주는 것이 안전합니다.

1. 결정 시간의 p50과 p90

p50: 일반적인 플레이어의 결정 속도
p75: 다소 느린 플레이어가 경험하는 부담
p90: 가장 큰 탐색 부담을 겪는 구간

예를 들어 p50은 2.1초인데 p90이 14초라면 대부분은 처리하지만 일부 플레이어가 특정 항목을 찾지 못하고 있을 가능성이 있습니다. 반대로 p50부터 높다면 메뉴 전체의 정보 구조나 항목 구분이 어려울 수 있습니다.

2. 이탈률

AbandonRate = \frac{opened\ sessions\ closed\ or\ timed\ out\ without\ confirmation}{opened\ sessions}

메뉴를 열고 선택을 확정하지 않은 채 닫거나 시간 초과된 세션의 비율입니다. 정상적으로 선택을 확정한 뒤 메뉴를 닫은 세션은 분자에서 제외하고, 한 세션에서 닫기와 시간 초과 이벤트가 중복 기록되더라도 한 번만 집계해야 합니다. 메뉴를 구경한 뒤 닫은 경우도 포함되므로 이탈률만으로 문제를 확정하지 말고 결정 시간과 함께 봐야 합니다.

3. 되돌아가기 비율

BacktrackRate = \frac{sessions\ with\ menu\_back}{sessions\ with\ menu\_open}

한 번의 메뉴 사용 중 menu_back이 발생한 세션의 비율입니다. 메뉴 깊이가 깊거나 카테고리 이름이 모호할 때 높아질 수 있습니다.

4. 선택 집중도

선택 결과가 특정 항목에 지나치게 몰리는지도 확인합니다. 선택 확률을 이용해 엔트로피를 계산할 수 있습니다.

Entropy = -\sum_{i=1}^{n} p_i \log_2(p_i)

엔트로피가 낮다고 무조건 좋은 것은 아닙니다. 한 항목이 가장 효율적이어서 선택이 몰린 것일 수도 있고 다른 항목이 잘 보이지 않는 것일 수도 있습니다. 선택 집중도는 밸런스 지표와 함께 해석해야 합니다.

5. 포커스와 미리보기 패턴

option_focus와 option_preview를 보면 플레이어가 결정을 내리기 전에 얼마나 많은 항목을 비교했는지 알 수 있습니다. 여러 항목을 빠르게 훑은 뒤 긴 시간 멈추는 패턴은 정보 비교 비용이 높다는 신호입니다.

로그를 어떻게 분석하면 메뉴 구조 문제를 찾을 수 있을까?

분석 단위는 전체 플레이어가 아니라 같은 상황의 메뉴 사용 세션이어야 합니다. 상점과 인벤토리를 하나의 평균으로 합치면 서로 다른 목적과 행동이 섞입니다.

1단계: 비교 집단을 고정한다

먼저 다음 조건으로 데이터를 분리합니다.

menu_id
build_version
플레이어 진행 단계
입력 장치
플랫폼
언어 또는 지역
튜토리얼 여부
메뉴를 연 상황과 목적

예를 들어 게임패드 사용자는 마우스 사용자보다 포커스 이동 비용이 클 수 있습니다. 이 둘을 합치면 메뉴 개편의 효과를 정확히 판단하기 어렵습니다.

2단계: 구간별 지표를 만든다

메뉴별로 다음 표를 생성합니다.

메뉴	표시 선택지	p50 결정 시간	p90 결정 시간	이탈률	되돌리기 비율
무기 장착	8	2.4초	7.1초	4.2%	9.8%
스킬 선택	16	4.8초	15.6초	11.7%	24.3%
제작 목록	42	6.3초	22.4초	18.5%	31.2%

위 표에서 제작 목록의 평균이 가장 높다는 사실보다 p90과 이탈률이 함께 높다는 점이 중요합니다. 스킬 선택도 선택지 수가 많지만 사용 목적이 명확하다면 구조를 조금만 개선해도 문제가 줄어들 수 있습니다.

3단계: 기준선을 정하고 우선순위를 정한다

프로젝트마다 허용 가능한 결정 시간은 다릅니다. 전투 중 열리는 퀵 메뉴와 긴 휴식 공간에서 사용하는 도감 메뉴에 동일한 기준을 적용하면 안 됩니다.

같은 메뉴의 기존 버전을 기준으로 다음과 같은 우선순위 점수를 계산할 수 있습니다.

OverloadScore = z(DecisionTime_{p90}) + z(AbandonRate) + z(BacktrackRate)

각 항목의 z-score는 같은 메뉴군 안에서 계산합니다. 점수가 높을수록 선택 부담이 큰 후보입니다. 이 점수는 정답 판정식이 아니라 조사 순서를 정하는 도구로 사용하는 것이 좋습니다.

메뉴 구조를 어떻게 조정할까?

문제 메뉴를 찾았다면 선택지를 줄이는 것부터 시작하지 말고 정보 구조를 바꿀 수 있는지 확인합니다.

그룹화와 계층화

서로 다른 목적의 항목을 하나의 긴 목록에 넣었다면 카테고리를 분리합니다. 무기는 무기 종류와 장착 부위로 나누고 제작 아이템은 재료, 용도, 제작 가능 여부로 필터링할 수 있습니다.

단, 카테고리를 지나치게 잘게 나누면 메뉴 깊이가 늘어나 탐색 비용이 커집니다. 그룹화 이후에는 menu_depth, 탭 이동 횟수, 뒤로 가기 비율을 함께 측정해야 합니다.

단계적 공개

첫 화면에는 플레이어가 자주 사용하는 핵심 정보만 보여주고 세부 옵션은 펼침이나 상세 화면에 배치합니다. 이 방식은 선택지를 삭제하지 않고 한 번에 처리해야 하는 정보량을 줄입니다.

예를 들어 장비 메뉴에서는 다음 정보를 1차 화면에 둡니다.

장비 이름
현재 장착 여부
핵심 능력치 변화
추천 또는 비교 결과

세부 스탯, 스킬 상호작용, 부가 효과는 상세 화면에서 보여줄 수 있습니다.

상황별 기본값과 최근 사용 항목

플레이어가 반복적으로 같은 행동을 한다면 최근 사용 항목이나 상황별 기본값을 제공합니다. 기본값은 선택을 강제하는 기능이 아니라 판단 비용을 줄이는 제안이어야 합니다.

최근 장착한 장비를 목록 상단에 표시
현재 퀘스트와 관련된 보상을 추천
캐릭터가 사용할 수 없는 항목은 별도 영역으로 이동
제작 가능한 아이템만 보기 필터를 기본 활성화

추천이 틀렸을 때 즉시 취소할 수 있고 추천 기준을 이해할 수 있어야 합니다. 잘못된 기본값은 선택 시간을 줄이는 대신 신뢰도를 떨어뜨릴 수 있습니다.

검색과 필터

선택지 수가 많은 제작 목록이나 인벤토리에는 검색과 정렬이 효과적입니다. 다만 검색어를 입력해야만 원하는 항목을 찾을 수 있다면 처음 사용하는 플레이어에게 부담이 될 수 있습니다.

검색을 추가한 뒤에는 다음 지표를 확인합니다.

검색 사용 세션의 결정 시간
검색 없이 선택한 세션의 결정 시간
검색 후 결과가 0건인 비율
검색어 수정 횟수
검색 사용 후 선택 확정률

검색 사용률이 높아졌다는 사실만으로 성공을 판단하면 안 됩니다. 검색을 많이 사용하지만 결과가 없어 메뉴를 닫는 경우도 있기 때문입니다.

메뉴 개편 효과를 어떻게 A/B 테스트할까?

메뉴 구조 변경은 플레이어의 행동뿐 아니라 콘텐츠 소비량과 밸런스에도 영향을 줄 수 있습니다. 따라서 UX 지표와 게임플레이 지표를 함께 봐야 합니다.

실험 설계

기존 메뉴와 개편 메뉴의 두 버전을 준비한다.
플레이어를 무작위로 배정하고 한 플레이어가 실험 중간에 버전을 바꾸지 않게 한다.
동일한 menu_id, 진행 단계, 플랫폼, 입력 장치별로 결과를 비교한다.
p50·p90 결정 시간, 이탈률, 되돌리기 비율, 선택 확정률을 1차 지표로 둔다.
선택 다양성, 구매율, 장비 사용률, 퀘스트 완료율을 2차 지표로 확인한다.
충분한 표본과 기간을 확보한 뒤 패치 버전과 실험군을 함께 기록한다.

성공 기준 예시

프로젝트의 기준에 맞춰 다음처럼 사전에 조건을 정의할 수 있습니다.

p90 결정 시간 15% 이상 감소
이탈률 10% 이상 감소
선택 확정률 상승
특정 추천 항목으로의 과도한 쏠림 없음
상점 매출이나 장비 사용률 등 핵심 밸런스 지표에 부정적 변화 없음

이 수치는 일반적인 예시일 뿐이며 프로젝트의 기준값으로 간주하면 안 됩니다. 중요한 점은 실험을 시작하기 전에 성공 조건을 정해 결과에 맞춰 기준을 바꾸지 않는 것입니다.

게임 메뉴의 선택지 그룹화와 단계적 공개 구조를 설명하는 UX 분석 화면

로그 분석에서 자주 생기는 함정은 무엇인가?

결정 시간이 길다고 항상 Choice Overload는 아니다

플레이어가 긴 시간을 들여도 결과에 만족하고 선택을 확정한다면 중요한 결정을 신중하게 내리는 과정일 수 있습니다. 반대로 결정 시간이 짧아도 잘못 선택한 뒤 반복해서 되돌아간다면 구조가 명확하다고 보기 어렵습니다.

결정 시간은 이탈률, 되돌리기, 선택 후 결과, 재방문 행동과 함께 해석해야 합니다.

선택지 수를 단순히 세면 안 된다

화면에 20개가 보이더라도 아이콘과 이름이 명확하고 정렬 기준이 안정적이면 부담이 낮을 수 있습니다. 반대로 6개뿐이어도 비슷한 이름과 모호한 설명이 반복되면 더 어렵습니다.

따라서 다음 필드를 별도로 기록하는 것이 좋습니다.

전체 선택지 수
현재 화면에 보이는 선택지 수
비활성 선택지 수
카테고리 수
스크롤 필요 여부
상세 정보 접근 횟수

숙련도 차이를 무시하면 안 된다

처음 메뉴를 사용하는 플레이어와 수십 시간 플레이한 플레이어의 결정 시간을 합치면 변화 원인을 알기 어렵습니다. 플레이 시간, 메뉴 사용 횟수, 해당 시스템을 해금한 뒤 경과한 시간으로 숙련도 구간을 나누십시오.

초보자의 p90이 크게 줄고 숙련자의 p50이 유지된다면 개편이 학습 부담을 낮춘 것으로 볼 수 있습니다. 숙련자의 결정 시간까지 크게 늘었다면 단순화를 위해 효율적인 사용자를 방해했을 가능성이 있습니다.

로그의 누락을 성공으로 착각하면 안 된다

클라이언트가 강제 종료되거나 연결이 끊기면 menu_close 이벤트가 오지 않을 수 있습니다. menu_open은 많지만 종료 이벤트가 부족하다면 이탈률을 계산하기 전에 이벤트 전송 신뢰도부터 확인해야 합니다.

자주 묻는 질문(FAQ)

선택지가 몇 개부터 Choice Overload로 봐야 하나요?

고정된 임계값은 없습니다. 장르, 입력 장치, 선택의 중요도, 정보 표현 방식에 따라 달라집니다. 같은 메뉴의 p90 결정 시간과 이탈률이 선택지 수 증가와 함께 악화되는지 확인하는 것이 더 정확합니다.

평균 결정 시간만 대시보드에 표시해도 되나요?

권장하지 않습니다. 평균은 긴 유휴 시간과 이상치의 영향을 크게 받습니다. 최소한 p50과 p90을 함께 표시하고 이탈률, 되돌리기 비율을 결합해 해석하십시오.

선택지를 줄이면 항상 UX가 좋아지나요?

아닙니다. 선택지 삭제는 기능 손실과 플레이 스타일 제한을 만들 수 있습니다. 먼저 그룹화, 단계적 공개, 필터, 검색, 최근 사용 항목을 검토하고 실제 선택 확정률과 콘텐츠 사용량을 A/B 테스트로 확인해야 합니다.

정리

Choice Overload를 줄이는 출발점은 감이나 의견이 아니라 메뉴 사용 흐름을 재현할 수 있는 로그 설계입니다. menu_ready부터 selection_confirmed까지의 결정 시간과 p50·p90, 이탈률, 되돌리기 비율을 메뉴별로 수집하면 플레이어가 어디에서 멈추는지 확인할 수 있습니다.

그다음 선택지를 목적별로 그룹화하고 한 번에 보이는 정보량을 줄이며 상황별 기본값과 검색 기능을 조합합니다. 마지막으로 입력 장치와 숙련도를 통제한 A/B 테스트를 통해 UX 개선이 실제 게임플레이와 밸런스에도 긍정적인지 검증해야 합니다.