색각 보정 모드별 적·아군 식별 대비를 이미지 분석으로 검증하는 접근성 QA

핵심 요약

색각 보정 모드의 품질은 설정 화면을 확인하는 것만으로 판단할 수 없습니다. 동일한 게임 장면을 원본과 색각 시뮬레이션 모드로 캡처한 뒤 적·아군 마스크를 추출하고 상대 휘도 대비, CIEDE2000 색차, 오인식률을 함께 측정해야 합니다. 핵심은 색상 하나에 의존하지 않고 외곽선, 아이콘, 패턴 같은 보조 식별 정보까지 정량적으로 검증하는 것입니다.

왜 색각 보정 모드에서도 적과 아군이 헷갈리는가?

게임에서 적과 아군은 흔히 빨강과 파랑처럼 색상 차이로 구분됩니다. 그러나 색각 보정 모드는 플레이어의 시각 특성을 보정하는 방식에 따라 색상 간 거리를 바꾸며 특정 배경에서는 적 표시의 채도와 명도가 동시에 낮아질 수 있습니다.

문제는 평균적인 색상 차이가 아니라 실제 플레이 화면에서 발생합니다. 다음 상황에서는 설정 메뉴의 샘플 이미지가 충분한 대비를 보여도 전투 중 식별성이 급격히 떨어질 수 있습니다.

어두운 배경 위에 적 표시가 겹치는 경우
폭발, 피격 이펙트, 안개처럼 고채도 픽셀이 많은 경우
적과 아군의 외곽선이 서로 다른 색상에만 의존하는 경우
원거리에서 표시 영역이 1~2픽셀로 축소되는 경우
HUD 색상과 월드 공간 표식의 보정 규칙이 다른 경우

따라서 접근성 QA에서는 “색이 달라 보이는가?”보다 “정해진 시간 안에 적과 아군을 안정적으로 분류할 수 있는가?”를 측정해야 합니다.

색각 보정 모드별 전투 장면에서 적·아군 표식과 배경 대비를 비교한 분석 예시

이미지 분석 기반 접근성 QA 파이프라인은 어떻게 구성하는가?

테스트 대상은 최소한 원본 모드와 다음 색각 시뮬레이션 모드를 포함하는 것이 좋습니다. 실제 제품에서 제공하는 보정 모드의 이름과 변환 행렬이 있다면 그 구현을 기준으로 사용해야 합니다.

테스트 모드	주요 검증 대상	대표적인 실패 사례
원본 색상	기본 적·아군 식별성	배경과 표식의 명도 충돌
Protanopia 시뮬레이션	적색 계열 구분	빨강 표식이 녹색 또는 갈색 배경에 묻힘
Deuteranopia 시뮬레이션	녹색·적색 계열 구분	아군 초록색과 적색이 비슷한 명도로 수렴
Tritanopia 시뮬레이션	청색·황색 계열 구분	파랑 아군 표식과 보라색 이펙트가 혼합됨
Achromatopsia 또는 Grayscale	색상 정보 제거 상황	색 이외의 식별 수단이 없는 표식이 사라짐

자동화 흐름은 캡처, 변환, 대상 추출, 지표 계산, 판정 리포트 생성 순서로 구성합니다.

flowchart LR
    A[Unity 테스트 장면 실행] --> B[동일 프레임 캡처]
    B --> C[색각 시뮬레이션 적용]
    C --> D[적·아군 마스크 추출]
    D --> E[휘도 대비와 CIEDE2000 계산]
    E --> F[오인식률 및 임계값 판정]
    F --> G[CI 리포트와 실패 이미지 저장]

동일한 카메라 위치, 해상도, 안티앨리어싱 설정, 조명 시드, 이펙트 시드를 고정해야 모드 간 차이를 비교할 수 있습니다. 특히 파티클과 후처리 효과가 포함된 장면은 프레임마다 픽셀 분포가 달라지므로 고정된 시뮬레이션 시간에 캡처해야 합니다.

어떤 지표로 적·아군 식별 대비를 측정하는가?

1. 상대 휘도 대비

RGB 값을 바로 비교하면 색상은 다르지만 밝기가 비슷한 상황을 놓칠 수 있습니다. 먼저 sRGB 값을 선형 RGB로 변환한 뒤 상대 휘도 $Y$ 를 계산합니다.

C_{lin}=\begin{cases}\frac{C_{sRGB}}{12.92},&C_{sRGB}\le 0.04045\\\left(\frac{C_{sRGB}+0.055}{1.055}\right)^{2.4},&C_{sRGB}>0.04045\end{cases}

Y=0.2126R_{lin}+0.7152G_{lin}+0.0722B_{lin}

두 영역의 상대 휘도가 각각 $L_1$ 과 $L_2$ 일 때 대비율은 다음과 같습니다. 여기서 $L_1$ 은 더 밝은 값입니다.

Contrast=\frac{L_1+0.05}{L_2+0.05}

WCAG 2의 일반적인 텍스트 기준을 게임 월드 표식에 그대로 적용할 수는 없지만 HUD의 이름표와 체력바를 위한 초기 게이트로 활용할 수 있습니다. 월드 표식은 크기, 외곽선 두께, 거리, 움직임을 함께 반영한 별도 기준이 필요합니다.

2. CIEDE2000 색차

색상 차이는 CIELAB 공간에서 계산하는 것이 RGB 유클리드 거리보다 안정적입니다. 적 마스크와 아군 마스크의 대표 색상을 각각 Lab 값으로 변환하고 $\Delta E_{00}$ 를 계산합니다.

평균 색차만 저장하면 작은 표식이 큰 배경에 희석될 수 있으므로 다음 값을 함께 기록합니다.

지표	의미	활용
평균 $\Delta E_{00}$	두 표식 색상의 평균 차이	전체적인 색상 분리 확인
5백분위수 $\Delta E_{00}$	가장 취약한 픽셀 구간	일부 영역의 색상 붕괴 탐지
평균 상대 휘도 대비	표식과 주변 배경의 밝기 차이	어두운 배경에서 가시성 확인
최소 외곽선 대비	외곽선과 배경의 최저 대비	얇은 표식의 소실 확인
적·아군 분류 정확도	분류기 또는 규칙 기반 판정 결과	실제 오인식 위험 확인

3. 오인식률과 검출 안정성

색상 지표가 통과해도 플레이어가 적을 아군으로 인식할 수 있습니다. 테스트 장면의 정답 마스크를 기준으로 적·아군 분류 결과를 비교하고 다음 오류를 구분합니다.

False Negative: 실제 적 또는 아군 표식을 검출하지 못함
False Positive: 배경 이펙트를 적 또는 아군 표식으로 검출함
Class Confusion: 적을 아군으로 또는 아군을 적으로 분류함
Temporal Flicker: 카메라나 이펙트 움직임에 따라 분류 결과가 프레임마다 바뀜

식별성의 실무 판정은 단일 지표보다 복합 게이트가 적합합니다. 예를 들어 “적·아군 마스크 사이의 5백분위수 색차가 기준 이상이고 표식·배경의 최소 휘도 대비가 기준 이상이며 Class Confusion이 0%”처럼 정의할 수 있습니다. 수치는 프로젝트의 UI 크기와 장르에 맞춰 플레이테스트로 보정해야 합니다.

색각 시뮬레이션별 적·아군 마스크와 대비 실패 영역을 표시한 히트맵 예시

Unity 캡처를 테스트 입력으로 고정하는 방법

Unity에서는 테스트 전용 씬과 고정된 시드로 장면을 재현합니다. 캡처 파일명에는 빌드 버전, 모드, 해상도, 프레임 번호를 포함하면 패치 간 비교가 쉬워집니다.

using System.IO;
using UnityEngine;

public class AccessibilityCapture : MonoBehaviour
{
    [SerializeField] private Camera captureCamera;
    [SerializeField] private string outputDirectory = "AccessibilityCaptures";

    public void Capture(string buildId, string mode, int frameIndex)
    {
        Directory.CreateDirectory(outputDirectory);
        string fileName = $"{buildId}_{mode}_{Screen.width}x{Screen.height}_{frameIndex:D04}.png";
        string path = Path.Combine(outputDirectory, fileName);
        ScreenCapture.CaptureScreenshot(path, 1);
    }
}

실제 프로젝트에서는 캡처가 완료되기 전에 다음 프레임으로 넘어가지 않도록 대기해야 합니다. 또한 HDR 렌더 타깃과 일반 PNG의 색 공간이 다를 수 있으므로 분석 입력을 sRGB 기준으로 통일해야 합니다.

색각 시뮬레이션 결과를 OpenCV로 분석하는 방법은?

아래 예시는 이미 추출된 적·아군 마스크와 배경 영역을 비교하는 최소 분석 구조입니다. 색각 변환 자체는 제품에서 사용하는 셰이더 또는 검증된 변환 모듈을 사용하고 분석 단계에서는 OpenCV와 CIE Lab 변환을 적용합니다.

import cv2
import numpy as np


def mean_lab(image_bgr, mask):
    lab = cv2.cvtColor(image_bgr, cv2.COLOR_BGR2LAB).astype(np.float32)
    pixels = lab[mask > 0]
    if len(pixels) == 0:
        raise ValueError("mask has no pixels")
    return pixels.mean(axis=0)


def relative_luminance(image_bgr, mask):
    rgb = cv2.cvtColor(image_bgr, cv2.COLOR_BGR2RGB).astype(np.float32) / 255.0
    linear = np.where(
        rgb <= 0.04045,
        rgb / 12.92,
        ((rgb + 0.055) / 1.055) ** 2.4,
    )
    luminance = (
        0.2126 * linear[:, :, 0]
        + 0.7152 * linear[:, :, 1]
        + 0.0722 * linear[:, :, 2]
    )
    values = luminance[mask > 0]
    if len(values) == 0:
        raise ValueError("mask has no pixels")
    return float(np.mean(values)), float(np.percentile(values, 5))


def contrast_ratio(first, second):
    high, low = max(first, second), min(first, second)
    return (high + 0.05) / (low + 0.05)

CIEDE2000은 구현 실수가 잦으므로 직접 작성한 공식을 새로 운영하기보다 검증된 라이브러리나 사내 공통 모듈을 사용합니다. 중요한 것은 모드별 원본 이미지, 마스크, 계산 버전, 임계값을 함께 저장해 재현 가능한 결과를 만드는 것입니다.

테스트 절차를 1, 2, 3단계로 운영하려면?

1단계: 정답 데이터와 테스트 장면을 만든다

적, 아군, 배경, 주요 이펙트에 대한 마스크를 준비합니다. 마스크는 최종 화면 색상을 기준으로 추출하기보다 렌더 패스의 ID 버퍼나 테스트 전용 오버레이에서 생성하는 편이 안정적입니다.

장면은 최소한 다음 조건을 포함해야 합니다.

밝은 배경과 어두운 배경
근거리와 원거리 표식
적·아군 중첩 상황
피격, 폭발, 연막, 야간 조명
여러 대상이 동시에 움직이는 상황

2단계: 모든 색각 모드에서 동일 프레임을 분석한다

각 모드에서 동일한 프레임을 렌더링하고 표식과 주변 배경을 분석합니다. 적·아군 마스크의 색차뿐 아니라 각 표식과 배경의 대비도 측정해야 합니다. 모드 변환 후 색상값이 기준을 넘더라도 외곽선과 아이콘이 축소될 때 식별성이 유지되는지 별도로 확인합니다.

3단계: 실패 이미지를 패치 게이트에 연결한다

임계값을 넘지 못한 프레임은 숫자만 남기지 말고 원본, 보정 모드, 마스크 오버레이, 실패 지표를 한 장의 리포트 이미지로 저장합니다. CI에서는 다음 조건을 빌드 실패 기준으로 사용할 수 있습니다.

accessibility:
  modes: [original, protanopia, deuteranopia, tritanopia, achromatopsia]
  fail_when:
    class_confusion_rate: "> 0.0"
    marker_background_contrast_5th_percentile: "< 2.0"
    marker_detection_recall: "< 0.98"

위 임계값은 예시일 뿐이며 프로젝트의 표식 크기와 화면 복잡도에 따라 조정해야 합니다. 임계값을 낮추는 방식으로 실패를 숨기기보다 플레이테스트 결과와 함께 기준을 버전 관리하는 것이 중요합니다.

색상 외 보조 식별 정보도 함께 검증해야 하는 이유

색각 보정은 색을 재배치할 뿐 모든 식별 문제를 해결하지 않습니다. 적과 아군을 색상만으로 표시하면 특정 모드에서 색상 군집이 겹칠 때 구조적인 구분이 사라집니다.

권장하는 보조 정보는 다음과 같습니다.

보조 정보	장점	QA 확인 항목
외곽선 형태	배경과 분리하기 쉬움	두께와 최소 대비가 거리별로 유지되는가
아이콘 모양	색상과 독립적으로 분류 가능	크기가 작아져도 실루엣이 유지되는가
패턴 또는 점선	명도와 색상 차이를 보완	움직임 중에도 패턴이 뭉개지지 않는가
방향 표시	시선 유도에 유리	적·아군 의미가 일관되게 유지되는가
텍스트 또는 팀 약어	명시적인 정보 제공	글자 크기와 배경 대비가 충분한가

이미지 분석에서는 보조 정보의 존재 여부도 함께 기록할 수 있습니다. 예를 들어 외곽선 마스크의 면적 비율, 아이콘의 연결 성분 수, 템플릿 매칭 점수를 측정하면 “색상은 실패했지만 형태로 식별 가능한지”를 분리해 판단할 수 있습니다.

자주 묻는 질문 (FAQ)

색각 보정 모드 테스트에 WCAG 대비율만 사용해도 되나요?

아닙니다. WCAG 대비율은 유용한 초기 지표지만 게임 월드 표식의 크기, 거리, 움직임, 이펙트 중첩을 모두 설명하지 못합니다. 대비율과 CIEDE2000, 검출 재현율, 적·아군 혼동률을 함께 사용해야 합니다.

색각 시뮬레이션은 어떤 변환을 사용해야 하나요?

제품에 탑재된 셰이더나 후처리 효과가 있다면 그 구현을 테스트 기준으로 사용해야 합니다. 별도 시뮬레이터를 사용할 경우 Protanopia, Deuteranopia, Tritanopia의 변환 행렬과 색 공간 처리 순서를 명시하고 버전 관리해야 합니다.

자동화 테스트가 통과하면 실제 접근성 문제가 없다고 볼 수 있나요?

그렇게 볼 수는 없습니다. 자동화는 반복성과 회귀 검출에 강하지만 실제 인지 속도와 피로도는 완전히 대체하지 못합니다. 자동 분석으로 위험 장면을 좁힌 뒤 다양한 색각 특성을 가진 플레이어의 짧은 식별성 테스트로 기준을 보정해야 합니다.

정리

색각 보정 모드별 적·아군 식별성은 설정 화면의 샘플 색상만으로 검증하기 어렵습니다. Unity에서 동일한 장면을 재현하고 색각 모드별 캡처를 수집한 다음 OpenCV 기반 마스크 분석, 상대 휘도 대비, CIEDE2000, 오인식률을 조합하면 패치마다 접근성 회귀를 추적할 수 있습니다.

최종 품질 기준은 “색상이 충분히 다르다”가 아니라 “색상 변화와 무관하게 적·아군을 안정적으로 구분할 수 있다”여야 합니다. 외곽선, 아이콘, 패턴 같은 보조 식별 정보를 설계 단계부터 포함하고 그 효과까지 이미지 분석에 연결하면 접근성 QA를 주관적인 확인 작업에서 재현 가능한 빌드 게이트로 발전시킬 수 있습니다.