게임패드 스틱 데드존 편차와 드리프트를 기기별 자동 측정하는 입력 장치 QA

TL;DR

게임패드 스틱 드리프트와 데드존 편차는 장치별 원시 축 입력을 고정된 조건에서 수집한 뒤 중심 오프셋, 휴지 상태 반경, 노이즈, 히스테리시스, 최대 입력 편차로 수치화해야 합니다.

VID/PID, 시리얼 번호, 펌웨어, 연결 방식과 함께 결과를 저장하고 모델별 기준값으로 판정하면 빌드 전 회귀 테스트와 불량 패드 분류를 자동화할 수 있습니다.

게임패드 스틱 드리프트는 왜 기기마다 다르게 측정해야 하는가?

스틱 드리프트는 사용자가 스틱을 놓았을 때 입력값이 0, 0으로 돌아오지 않는 현상입니다. 포텐셔미터 마모, 센서 오차, 조립 편차, 스틱 중심 복귀력, 펌웨어 보정, 운영체제의 입력 매핑이 모두 영향을 줍니다.

같은 모델이라도 생산 배치와 사용 시간에 따라 편차가 생기며 XInput, DirectInput, SDL 같은 입력 계층에 따라 전달되는 값도 달라질 수 있습니다. 따라서 QA에서는 ‘게임 안에서 움직였는가’만 확인하지 말고 장치 식별 정보와 측정 조건을 함께 기록해야 합니다.

측정 결과에는 최소한 다음 필드를 포함합니다.

필드	목적
vendorId, productId	제조사와 제품 모델 식별
serialNumber	개별 기기 추적
firmwareVersion	펌웨어별 편차 비교
transport	USB, Bluetooth 등 연결 방식 기록
inputApi	XInput, DirectInput, SDL, Unity Input System 등
sampleRate, duration	측정 조건 재현
leftStick, rightStick	좌우 스틱별 결과 분리

자동 측정은 어떤 입력 데이터를 수집해야 하는가?

측정 파이프라인은 게임의 최종 이동값이 아니라 엔진 입력 계층에서 보정되기 전 또는 최소 보정된 축 값을 수집하는 방식이 바람직합니다. Unity Input System의 stickDeadzone 프로세서가 이미 적용된 값을 측정하면 하드웨어 편차와 게임 설정의 효과를 분리하기 어렵습니다.

정밀한 하드웨어 QA에서는 HID 또는 SDL 이벤트의 타임스탬프를 사용합니다. Unity 기반 테스트에서는 원리를 검증하거나 빌드 회귀를 확인할 때 Gamepad.leftStick.ReadValue()를 사용할 수 있지만 프레임 폴링 주기는 실제 장치 보고율과 다를 수 있다는 점을 리포트에 명시해야 합니다.

권장 측정 조건은 다음과 같습니다.

장치를 연결한 뒤 3~5초 동안 워밍업합니다.
스틱을 놓은 중립 상태를 10초 이상 샘플링합니다.
각 축을 최소값에서 최대값까지 천천히 이동하고 8방향 원형 입력을 3회 반복합니다.
장치를 다시 중립에 둔 뒤 동일한 중립 측정을 수행합니다.
측정 전후의 기기 식별자와 펌웨어 정보를 비교합니다.

정밀 검사에서는 250Hz 고정 주기와 단조 증가하는 타임스탬프를 사용합니다. 장치의 실제 보고율보다 높은 주기를 설정하면 새로운 정보가 늘지 않고 중복 샘플만 증가할 수 있으므로 실제 HID 보고율도 함께 기록하는 것이 좋습니다.

데드존 편차와 드리프트를 어떻게 수치화할까?

스틱 샘플을 $x_i, y_i$ 라고 하면 각 샘플의 중심으로부터의 반경은 다음과 같이 계산합니다.

r_i = \sqrt{x_i^2 + y_i^2}

1. 중심 오프셋

중립 구간의 평균값을 계산하면 장치가 어느 방향으로 치우쳤는지 확인할 수 있습니다.

\bar{x} = \frac{1}{N}\sum_{i=1}^{N}x_i,\quad \bar{y} = \frac{1}{N}\sum_{i=1}^{N}y_i

중심 오프셋의 크기는 $b = \sqrt{\bar{x}^2 + \bar{y}^2}$ 로 계산합니다. 평균값만 저장하면 순간적인 튐을 놓칠 수 있으므로 평균 반경, 95백분위 반경, 최대 반경을 함께 기록합니다.

2. 휴지 상태 드리프트

스틱을 놓은 상태에서 다음 지표를 계산합니다.

지표	의미
meanRadius	중립 입력의 평균 반경
p95Radius	전체 샘플 중 95%가 포함되는 반경
maxRadius	순간적으로 발생한 최대 반경
activeDuration	임계값을 넘은 누적 시간
directionBias	드리프트가 집중된 방향

p95Radius가 낮아도 특정 순간에만 큰 입력이 발생하면 게임에서 카메라나 캐릭터가 튈 수 있습니다. 따라서 단일 최대값만으로 불량을 판정하지 말고 지속 시간과 함께 평가해야 합니다.

3. 데드존 시작점

소프트웨어 데드존은 보통 다음과 같이 적용됩니다. $d_i$ 는 내부 데드존이고 $d_o$ 는 외부 데드존입니다.

r' = \operatorname{clamp}\left(\frac{r-d_i}{d_o-d_i}, 0, 1\right)

출력 벡터는 다음과 같이 계산합니다.

\mathbf{v}' = \frac{\mathbf{v}}{r}r'

QA에서는 보정 전 반경과 보정 후 반경을 모두 저장해야 합니다. 보정 전 반경은 센서 편차를 보여주고 보정 후 반경은 실제 게임 플레이에서 움직임이 시작되는 데드존을 보여줍니다.

4. 히스테리시스와 축 비대칭

스틱을 중심에서 바깥쪽으로 움직일 때와 바깥쪽에서 중심으로 돌아올 때 같은 위치의 입력값이 다르면 히스테리시스가 발생합니다. 8방향 스윕에서 이동 방향별 응답 곡선을 저장하면 마찰이나 복귀력의 차이를 확인할 수 있습니다.

또한 X축과 Y축의 최대값, 양의 방향과 음의 방향의 최대값을 각각 비교합니다. 예를 들어 X축의 양의 최대값이 0.94이고 음의 최대값이 -0.86이면 축 비대칭이 약 8%입니다. 이 값은 조준 감도와 차량 조작감에 직접 영향을 줄 수 있습니다.

게임패드별 스틱 원시 입력과 데드존 경계를 비교한 측정 그래프

기기별 자동 측정 파이프라인은 어떻게 구현할까?

전체 흐름은 장치 식별, 중립 샘플링, 축 스윕, 메트릭 계산, 모델별 판정, 결과 저장 순서로 구성합니다.

flowchart LR
    A[장치 연결] --> B[VID PID 시리얼 펌웨어 수집]
    B --> C[중립 상태 샘플링]
    C --> D[축 스윕과 8방향 입력]
    D --> E[드리프트와 데드존 메트릭 계산]
    E --> F{모델 기준 판정}
    F -->|PASS| G[JSON CSV 리포트]
    F -->|FAIL| H[재현 영상과 이슈 티켓]

Step 1. 장치 식별자를 먼저 고정한다

제품명만 저장하면 같은 이름의 리비전과 펌웨어를 구분하기 어렵습니다. vendorId, productId, serialNumber, 연결 방식, 입력 API, 펌웨어 버전을 조합해 테스트 키를 만듭니다.

시리얼 번호가 없는 기기는 포트 경로, 연결 순서, 장치 해시 같은 보조 식별자를 사용할 수 있지만 이 값은 재연결 후 바뀔 수 있으므로 영구적인 장치 ID로 간주하면 안 됩니다.

Step 2. 중립 상태를 별도로 측정한다

중립 측정 중에는 작업자가 스틱을 만지지 않도록 고정 지그를 사용합니다. 지그가 스틱에 힘을 가하면 실제 사용 환경과 다른 중심값이 나오므로 스틱 캡을 누르지 않는 구조가 좋습니다.

중립 샘플은 최소 10초 동안 수집하고 시작 직후 0.5~1초는 제외할 수 있습니다. 연결 직후의 초기 보정이나 블루투스 재동기화가 결과에 섞일 수 있기 때문입니다.

Step 3. 축 스윕과 반복 입력을 수행한다

자동 지그를 사용한다면 속도와 각도를 일정하게 유지합니다. 수동 측정이라면 최소한 각도, 이동 시간, 반복 횟수를 고정하고 작업자 ID를 기록합니다.

반복 측정 결과는 평균만 보지 말고 분산도 함께 확인합니다. 동일 장치의 반복 결과가 크게 흔들리면 센서 불량뿐 아니라 케이블 접촉, 블루투스 패킷 손실, 입력 API의 이벤트 누락도 의심해야 합니다.

Step 4. Unity 테스트 코드로 기본 측정을 연결한다

아래 예제는 Unity 2022.3 LTS, C# 9, Input System 1.7.x 기준의 프레임 폴링 샘플입니다. 정밀한 250Hz HID 검사는 별도 네이티브 수집기를 사용하고 이 코드는 빌드에서 장치 연결과 기본 드리프트 회귀를 확인하는 용도로 사용합니다.

using System;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.InputSystem;

public sealed class StickSampleCollector : MonoBehaviour
{
    [SerializeField] private float durationSeconds = 10f;
    private readonly List<Vector2> samples = new();
    private Gamepad pad;
    private float startedAt;

    private void OnEnable()
    {
        pad = Gamepad.current;
        if (pad == null)
            throw new InvalidOperationException("Gamepad not found");

        startedAt = Time.realtimeSinceStartup;
    }

    private void Update()
    {
        if (pad == null)
            return;

        samples.Add(pad.leftStick.ReadValue());

        if (Time.realtimeSinceStartup - startedAt < durationSeconds)
            return;

        Vector2 mean = Vector2.zero;
        foreach (Vector2 sample in samples)
            mean += sample;

        mean /= samples.Count;
        var description = pad.device.description;
        Debug.Log($"serial={description.serial}, product={description.product}, samples={samples.Count}, center={mean}");
        enabled = false;
    }
}

여러 패드를 동시에 검사할 때는 Gamepad.current 대신 Gamepad.all을 순회하고 장치별 버퍼를 분리해야 합니다. 또한 테스트 시작 시점에 description.serial, description.product, description.interfaceName을 저장해 결과 파일과 연결합니다.

Step 5. 모델별 기준값으로 판정한다

모든 게임패드에 동일한 임계값을 적용하면 정상적인 모델 특성을 불량으로 분류할 수 있습니다. 먼저 동일 모델의 승인 샘플을 여러 대 측정해 기준 분포를 만든 뒤 중앙값과 MAD를 사용하는 방식이 실용적입니다.

프로젝트 초기 기준으로 사용할 수 있는 예시는 다음과 같습니다. 아래 수치는 산업 표준이 아니라 게임의 조작 감도와 내부 데드존 설정에 맞춰 조정해야 합니다.

메트릭	경고 예시	실패 예시
중심 오프셋 반경	0.05 초과	0.08 초과
중립 p95 반경	0.08 초과	0.12 초과
축 비대칭	8% 초과	10% 초과
히스테리시스 차이	0.03 초과	0.05 초과
임계값 초과 지속 시간	0.5초 초과	2초 초과

판정 결과에는 PASS, WARN, FAIL 외에도 실패 원인을 넣습니다. 예를 들어 LEFT_STICK_CENTER_BIAS, RIGHT_STICK_NOISE, AXIS_ASYMMETRY, DEVICE_ID_UNKNOWN처럼 코드화하면 대시보드와 이슈 자동 생성에 사용할 수 있습니다.

CI와 라이브 운영에서 입력 QA 결과를 어떻게 활용할까?

빌드 파이프라인에서는 게임 빌드가 장치를 인식하는지 기본 입력 액션이 정상적으로 매핑되는지 기준 장치의 데드존 설정이 변하지 않았는지를 회귀 테스트합니다. 하드웨어 측정 결과는 빌드 아티팩트에 JSON으로 저장하고 커밋별로 비교합니다.

라이브 운영에서는 고객 제보의 ‘캐릭터가 혼자 움직인다’는 현상을 입력 장치 문제와 게임 코드 문제로 분리해야 합니다. 재현 로그에 다음 값을 남기면 분석 시간이 줄어듭니다.

장치 모델, 시리얼 번호, 연결 방식
입력 API와 펌웨어 버전
중립 상태의 평균 반경과 p95 반경
게임 설정의 내부·외부 데드존
마지막 입력 이벤트 시각
해당 프레임의 원시 축 값과 최종 액션 값

특히 게임 코드가 Update()와 FixedUpdate()에서 서로 다른 입력 샘플을 사용하면 정상적인 입력도 떨림처럼 보일 수 있습니다. 입력 샘플 수집 시각과 액션 적용 시각을 함께 기록해 장치 드리프트와 프레임 타이밍 문제를 분리해야 합니다.

자주 묻는 질문 FAQ

데드존을 크게 설정하면 스틱 드리프트가 해결되는가?

게임 안에서 발생하는 오작동은 줄일 수 있지만 센서 자체의 중심 편차가 사라지는 것은 아닙니다. 데드존을 과도하게 키우면 미세 조작과 조준 응답성이 떨어지므로 QA에서는 보정 전 값과 보정 후 체감값을 모두 측정해야 합니다.

최대 입력값이 1.0이 아니면 무조건 불량인가?

아닙니다. 입력 API의 정규화 방식과 장치별 캘리브레이션에 따라 달라집니다. 양의 방향과 음의 방향, X축과 Y축의 상대적인 비대칭을 모델 기준과 비교해야 합니다.

Unity의 `ReadValue()`만으로 정밀한 드리프트 검사가 가능한가?

기본 회귀 검사에는 사용할 수 있지만 HID 보고율과 엔진 프레임 주기를 정확히 분리할 수 없습니다. 생산 검수 수준의 검사는 HID 또는 SDL 이벤트를 고정 주기로 수집하고 Unity 결과와 교차 검증하는 편이 안전합니다.

정리

게임패드 입력 장치 QA의 핵심은 ‘움직인다’ 또는 ‘움직이지 않는다’는 수동 확인을 넘어서 장치별 입력 분포를 데이터로 남기는 것입니다. 중립 샘플링, 축 스윕, 8방향 반복, 중심 오프셋, p95 드리프트 반경, 히스테리시스, 축 비대칭을 동일한 프로토콜로 측정하면 모델 편차와 실제 불량을 구분할 수 있습니다.

VID/PID와 펌웨어만으로 충분하지 않은 경우에는 시리얼 번호와 연결 방식까지 리포트에 포함하고 승인 샘플의 분포를 기준으로 PASS, WARN, FAIL을 판정하십시오. 이렇게 구축된 자동 측정 파이프라인은 출시 전 빌드 검증뿐만 아니라 라이브 환경의 입력 관련 버그 분류 및 우선순위 지정에도 효과적으로 활용할 수 있습니다.

게임패드 스틱 데드존 편차와 드리프트를 기기별 자동 측정하는 입력 장치 QA

TL;DR

게임패드 스틱 드리프트는 왜 기기마다 다르게 측정해야 하는가?

자동 측정은 어떤 입력 데이터를 수집해야 하는가?