OS 글자 크기·디스플레이 배율 설정에서 UI 접근성을 점검하는 QA

핵심 요약

OS 글자 크기와 디스플레이 확대가 게임에 반영되는지는 플랫폼, 앱 창 모드, 엔진 UI 시스템과 설정에 따라 다르다. 먼저 대상 빌드가 해당 OS 설정을 실제로 따르는지 확인하고, 반영되는 경우 고정 높이 패널·모달·하단 버튼이 잘리는지 검사한다. Unity UI를 쓴다면 ScrollRect의 Viewport, Content 높이와 입력 영역을 함께 검증해 화면 밖 버튼에 도달할 수 있는지 확인한다.

해결의 핵심은 텍스트 영역을 고정 크기로 제한하지 않고 레이아웃이 콘텐츠 크기에 맞춰 재계산되도록 만드는 것이다. 모든 중요 조작 요소는 확대 상태에서도 화면 안에 표시되거나 스크롤로 반드시 도달할 수 있어야 한다.

왜 OS 확대 설정에서 게임 UI 버그가 드러나는가?

게임 UI는 엔진의 기준 해상도와 배율 설정으로 배치되는 경우가 많다. OS의 글자 크기나 디스플레이 배율이 게임의 논리 좌표계 또는 텍스트 크기에 영향을 주는지는 플랫폼과 UI 프레임워크 구현에 달려 있으므로, 이를 보편 동작으로 가정하지 말고 기기에서 확인한다.

이때 다음과 같은 불일치가 발생한다.

영역	개발자가 가정한 상태	확대 설정에서 발생하는 변화
텍스트	한 줄에 들어가는 고정 문자열	여러 줄로 줄바꿈되거나 글리프가 영역을 초과함
버튼	고정 폭·고정 높이	라벨이 잘리거나 터치 영역과 시각 영역이 어긋남
모달	화면 중앙의 고정 크기 패널	상단 또는 하단이 화면 밖으로 밀려남
스크롤	콘텐츠 높이가 초기화 시 한 번만 계산됨	확대 후 늘어난 콘텐츠를 반영하지 못함
입력 포커스	키보드와 마우스 중심의 이동	현재 포커스 요소가 화면 밖에 남음
안전 영역	일반 해상도 기준으로 계산	내비게이션 바와 겹치거나 하단 CTA가 가려짐

문제는 단순히 글자가 커지는 데서 끝나지 않는다. 텍스트가 두 줄이 되면 부모 컨테이너 높이, 버튼 위치, 다음 항목의 시작 위치, 스크롤 가능한 전체 높이가 연쇄적으로 바뀐다.

접근성 UI QA에서 먼저 구분해야 할 확대 유형

테스트를 시작하기 전에 어떤 설정을 바꾸었는지 기록해야 재현 조건을 정확히 공유할 수 있다. 글자 크기와 디스플레이 배율은 비슷해 보이지만 영향을 받는 계층이 다를 수 있다.

테스트 변수	확인 대상	대표적인 실패 유형
OS 글자 크기	대상 앱에서 설정 반영 여부	반영되는 경우 라벨 잘림, 줄바꿈, 버튼 높이
디스플레이 확대	앱의 화면 크기·좌표계 변경 여부	변경되는 경우 모달 잘림, 화면 밖 배치
게임 내 UI 크기	게임 설정의 UI 배율	HUD 겹침, 메뉴 폭 초과, 입력 영역 축소
화면 방향	가로·세로 전환 또는 고정 방향	팝업 재배치 실패, 스크롤 방향 오류
화면 비율	16:9, 16:10, 초광폭, 모바일 비율	빈 공간 또는 하단 콘텐츠 유실

한 번에 모든 변수를 바꾸면 원인을 분리하기 어렵다. 먼저 OS 글자 크기만 최대 수준으로 올리고 테스트한 뒤 디스플레이 확대를 추가하는 방식이 좋다.

버튼 잘림과 스크롤 불가는 어떻게 재현하는가?

1단계: 테스트 기준을 고정한다

다음 정보를 테스트 케이스에 기록한다.

빌드 버전과 플랫폼
운영체제 버전
화면 해상도와 방향
OS 글자 크기 단계
OS 디스플레이 확대 단계
게임 내 UI 스케일 옵션
입력 장치와 입력 방식
언어와 긴 문자열이 포함된 화면

테스트 기기마다 최대 단계의 실제 값이 다를 수 있으므로 단순히 200%라고 쓰기보다 운영체제의 설정 이름과 단계명을 함께 기록한다. 자동화 환경에서는 픽셀 크기와 논리 해상도를 모두 로그로 남기는 편이 안전하다.

2단계: 실패 가능성이 높은 화면을 우선 확인한다

모든 화면을 같은 순서로 검사할 필요는 없다. 다음 화면은 레이아웃이 쉽게 무너지는 지점이다.

로그인과 계정 연결 화면
이용 약관과 개인정보 동의 화면
결제·상점·보상 수령 화면
장비 비교와 상세 정보 모달
튜토리얼 안내창
설정과 접근성 옵션 화면
긴 오류 메시지가 표시되는 네트워크 실패 화면
세로형 모바일 화면의 하단 고정 버튼

각 화면에서 다음 네 가지 질문을 반복한다.

모든 텍스트가 읽히는가?
모든 버튼의 라벨과 상태가 보이는가?
마지막 항목과 확인 버튼까지 도달할 수 있는가?
지원 대상으로 삼은 마우스, 터치, 키보드, 게임패드 입력 방식으로 필요한 조작을 수행할 수 있는가?

3단계: 화면 밖 콘텐츠의 도달 가능성을 검증한다

버튼이 처음부터 보이지 않는 것만 버그는 아니다. 스크롤바가 사라졌거나 입력 포커스가 콘텐츠를 따라가지 못해 사용자가 해당 버튼에 도달할 수 없다면 기능상 차단으로 분류해야 한다.

검증 순서는 다음과 같다.

패널의 첫 항목부터 마지막 항목까지 순서대로 이동한다.
마우스 휠, 터치 스와이프, 드래그, 키보드 방향키, 게임패드 스틱을 각각 확인한다.
포커스가 다음 요소로 이동할 때 해당 요소가 Viewport 안으로 들어오는지 본다.
마지막 버튼을 활성화한 뒤 클릭 또는 확인 입력이 실제로 동작하는지 확인한다.
화면을 닫고 다시 열었을 때 스크롤 위치와 포커스가 의도한 상태로 복원되는지 확인한다.

Unity UI에서 어떤 레이아웃 설정을 점검해야 하는가?

Unity UGUI를 사용한다면 다음 컴포넌트 조합을 우선 점검한다.

목적	확인할 컴포넌트 또는 속성	점검 포인트
전체 UI 배율	`Canvas Scaler`	`Scale With Screen Size`, 기준 해상도, `Match` 값
세로 목록	`Vertical Layout Group`	자식의 폭·높이 제어와 간격
콘텐츠 자동 확장	`Content Size Fitter`	부모 레이아웃과 순환 의존성이 없는지
스크롤 영역	`ScrollRect`	`Viewport`, `Content`, 수직 스크롤 활성화
잘림 처리	`Mask` 또는 `RectMask2D`	의도하지 않은 텍스트·버튼 클리핑 여부
버튼 입력	`Button`, `Graphic Raycaster`	시각 영역과 실제 입력 영역의 일치 여부
안전 영역	`RectTransform` 앵커	노치·내비게이션 영역과의 겹침 여부

Canvas Scaler는 UI 전체의 기준을 맞추는 데 도움이 되지만 콘텐츠가 늘어나는 문제를 자동으로 해결하지는 않는다. 텍스트가 두 줄이 되었는데 버튼의 높이가 고정되어 있다면 스케일 값만 조정해도 잘림은 남는다.

예를 들어 목록형 모달은 다음과 같은 구조를 갖는 편이 관리하기 쉽다.

ModalRoot
└── Panel
    ├── Header
    ├── Viewport
    │   └── Content
    │       ├── Item
    │       ├── Item
    │       └── Item
    └── Footer
        └── ConfirmButton

Viewport는 실제로 화면에 보이는 영역이고 Content는 모든 항목을 담는 영역이다. Content의 높이가 확대된 텍스트를 반영하지 않으면 ScrollRect는 스크롤할 필요가 없다고 판단할 수 있다.

스크롤 가능한 전체 높이는 어떻게 검증하는가?

스크롤 가능 여부는 대략 다음 조건으로 설명할 수 있다.

H_{content} > H_{viewport}

여기서 $H_{content}$ 는 자식 요소, 간격, 패딩을 포함해 Viewport 로컬 좌표계에서 측정한 콘텐츠 높이이고 $H_{viewport}$ 는 표시 영역의 높이다. 확대 설정에서 텍스트 줄 수가 증가했는데도 $H_{content}$ 가 갱신되지 않으면 마지막 버튼이 있어도 스크롤 범위가 생성되지 않을 수 있다.

실행 시점도 중요하다. 다음 순서가 안전하다.

폰트와 로컬라이즈된 문자열을 적용한다.
텍스트의 줄바꿈과 선호 높이를 계산한다.
부모 레이아웃을 재계산한다.
Content의 크기를 갱신한다.
ScrollRect의 스크롤 위치와 포커스를 보정한다.

Unity에서는 레이아웃 변경 직후 값을 읽으면 이전 프레임의 크기가 남아 있을 수 있다. 화면을 열 때 레이아웃을 즉시 강제 갱신한 뒤 스크롤 범위를 검사하는 테스트 훅을 둘 수 있다.

using UnityEngine;
using UnityEngine.UI;

public sealed class AccessibilityLayoutProbe : MonoBehaviour
{
    [SerializeField] private RectTransform content;
    [SerializeField] private RectTransform viewport;
    [SerializeField] private ScrollRect scrollRect;
    [SerializeField] private RectTransform layoutRoot;
    private readonly Vector3[] worldCorners = new Vector3[4];

    public bool HasScrollableOverflow()
    {
        Canvas.ForceUpdateCanvases();
        LayoutRebuilder.ForceRebuildLayoutImmediate(layoutRoot);
        content.GetWorldCorners(worldCorners);

        float minY = float.PositiveInfinity;
        float maxY = float.NegativeInfinity;
        for (int i = 0; i < worldCorners.Length; i++)
        {
            float localY = viewport.InverseTransformPoint(worldCorners[i]).y;
            minY = Mathf.Min(minY, localY);
            maxY = Mathf.Max(maxY, localY);
        }

        return maxY - minY > viewport.rect.height + 0.5f;
    }

    public void MoveToBottom()
    {
        Canvas.ForceUpdateCanvases();
        LayoutRebuilder.ForceRebuildLayoutImmediate(layoutRoot);
        scrollRect.verticalNormalizedPosition = 0f;
    }
}

이 코드는 제품 로직을 대신하는 해결책이 아니라 QA 진단용 예시다. 레이아웃 그룹이 있는 계층에 맞는 layoutRoot를 지정하고, 일반 갱신에서는 ForceRebuildLayoutImmediate 대신 MarkLayoutForRebuild를 우선 검토한다. 즉시 재빌드는 비용이 들 수 있으므로 실제 프로젝트에서는 호출 책임과 화면 열기 수명주기를 명확히 해야 한다.

어떤 버그 패턴을 우선 분류해야 하는가?

고정 높이 버튼

텍스트가 한 줄이라는 가정으로 버튼 높이를 고정하면 확대나 번역된 긴 문자열에서 라벨의 위·아래가 잘린다. 버튼 자체의 높이를 키우는 방법도 있지만 화면 전체가 길어질 수 있으므로 텍스트의 선호 높이를 부모 레이아웃이 반영하도록 만드는 것이 우선이다.

패널 내부의 이중 클리핑

Mask가 적용된 패널 안에 또 다른 고정 크기 컨테이너가 있으면 콘텐츠가 두 번 잘릴 수 있다. 화면에서는 글자 일부가 사라지고 스크롤해도 잘린 상태가 유지된다. 각 계층의 RectTransform 크기와 마스크 경계를 분리해 확인한다.

하단 고정 버튼이 스크롤 영역을 가리는 문제

확인 버튼을 패널 하단에 고정하면서 Viewport의 하단 여백을 확보하지 않으면 마지막 목록 항목이 버튼 아래에 숨는다. Viewport의 실제 높이는 헤더와 푸터를 제외한 영역이어야 한다.

포커스는 이동하지만 화면이 따라오지 않는 문제

키보드나 게임패드에서 포커스가 마지막 버튼으로 이동해도 카메라가 스크롤되지 않으면 사용자는 선택 상태를 확인할 수 없다. 포커스 변경 이벤트에서 선택 요소의 사각형이 Viewport 안에 들어오도록 스크롤을 보정해야 한다.

확대 전 상태를 캐시하는 문제

동적 UI의 높이나 줄 수를 초기화 때만 저장하면 OS 설정 변경, 언어 변경, 폰트 변경 뒤에 오래된 값이 사용될 수 있다. 화면 표시, 문자열 교체, 폰트 교체, 창 크기 변경 시 레이아웃을 다시 계산해야 한다.

재현 결과는 어떤 형식으로 기록해야 하는가?

버그 리포트에는 단순히 “확대 시 버튼이 잘림”이라고 쓰지 않는다. 설정과 도달 불가 상태를 함께 기록해야 개발자가 같은 조건에서 확인할 수 있다.

항목	기록 예시
제목	최대 글자 크기에서 이용 약관 모달의 확인 버튼이 스크롤되지 않음
환경	Windows, 데스크톱 빌드, 1920×1080, 창 모드
설정	OS 글자 크기 최대, 디스플레이 확대 최대, 게임 UI 100%
재현 절차	설정 적용 → 게임 실행 → 이용 약관 열기 → 마지막 문단까지 이동
실제 결과	마지막 문단과 확인 버튼이 패널 아래에 가려지고 휠 입력에도 이동하지 않음
기대 결과	마지막 콘텐츠와 확인 버튼이 스크롤로 표시되고 활성화 가능함
심각도 판단	필수 동의 또는 진행 버튼이면 진행 차단으로 분류
증거	전체 화면, 확대 영역, 입력 동작 영상, 레이아웃 로그

스크린샷에는 운영체제 확대 설정과 게임 화면을 각각 포함한다. 영상은 화면을 끝까지 스크롤하고 마지막 버튼을 클릭하는 장면까지 담아야 “보이지 않음”과 “도달할 수 없음”을 구분할 수 있다.

접근성 UI의 수정 완료 기준은 무엇인가?

다음 기준을 수용 조건으로 사용할 수 있다.

필수 텍스트가 잘리거나 겹치지 않는다.
버튼 라벨 전체가 읽히며 버튼의 시각 영역과 입력 영역이 일치한다.
화면 밖의 콘텐츠는 적절한 스크롤 입력으로 도달할 수 있다.
마지막 버튼이 다른 요소나 안전 영역에 가려지지 않는다.
키보드와 게임패드 입력을 지원한다면 포커스가 현재 선택 요소를 화면 안으로 이동시킨다.
스크롤바가 없더라도 지원되는 입력 방식으로 스크롤할 수 있다.
언어 변경과 창 크기 변경 후에도 레이아웃이 재계산된다.
확대 설정을 일반 상태로 되돌린 뒤 기존 화면 배치가 깨지지 않는다.
자동화 테스트에서 필수 버튼의 표시 여부와 활성화 가능 여부를 확인할 수 있다.

특히 “텍스트가 화면에 표시된다”와 “사용자가 기능을 완료할 수 있다”는 별도 기준으로 관리한다. 확인 버튼이 화면에 보이더라도 클릭 영역이 다른 오브젝트에 덮여 있으면 테스트를 통과시키면 안 된다.

반복 검증을 위한 최소 테스트 매트릭스

초기 스모크 테스트에서는 모든 조합을 실행하기보다 실패 가능성이 높은 조합을 먼저 선택한다.

조합	목적
기본 UI + OS 글자 크기 최대	텍스트 줄바꿈과 버튼 높이 검증
기본 UI + 디스플레이 확대 최대	모달과 안전 영역 검증
긴 언어 + OS 글자 크기 최대	로컬라이제이션과 자동 높이 검증
세로 화면 + 디스플레이 확대 최대	하단 CTA와 스크롤 검증
게임패드 입력 + 확대 상태	포커스 가시성과 자동 스크롤 검증
재실행 또는 화면 재진입 + 확대 상태	캐시된 레이아웃과 초기화 순서 검증

패치 후에는 발견된 화면만 다시 보는 회귀 테스트에 그치지 말고 같은 UI 컴포넌트를 사용하는 다른 화면도 표본 검사한다. 고정 높이 버튼 프리팹이나 공통 모달 템플릿이 원인이라면 여러 화면에서 같은 결함이 발생할 수 있다.

자주 묻는 질문 (FAQ)

OS 글자 크기와 게임 내 UI 스케일을 모두 지원해야 하는가?

가능하면 각각 독립적으로 검증해야 한다. 게임 내 UI 스케일이 OS 글자 크기를 덮어쓰는 구조라면 접근성 설정의 의도와 충돌할 수 있으므로 제품 정책을 명확히 기록해야 한다.

버튼이 잘리지 않으면 스크롤 불가 버그도 해결된 것인가?

아니다. 버튼이 화면 밖에 있고 스크롤 입력이 작동하지 않으면 기능은 여전히 차단된다. 버튼의 가시성, 도달 가능성, 입력 가능성을 별도 항목으로 확인해야 한다.

모든 화면을 최대 확대에서 픽셀 단위로 비교해야 하는가?

픽셀 단위 일치보다 정보 손실과 기능 완료 가능성을 우선한다. 텍스트 잘림, 겹침, 화면 밖에 남은 필수 조작, 포커스 미가시성은 우선 결함으로 보고하고 여백의 미세한 차이는 허용 기준에 따라 판단한다.

정리

OS 글자 크기와 디스플레이 확대를 최대로 설정하는 테스트는 UI가 커지는지 확인하는 단순한 시각 검사가 아니다. 텍스트 측정, 부모 레이아웃 재계산, ScrollRect의 콘텐츠 범위, 안전 영역, 입력 포커스가 하나의 동작 흐름으로 이어지는지 검증하는 접근성 UI QA다.

테스트의 핵심 질문은 “글자가 보이는가?”에서 끝나지 않는다. “필수 정보가 읽히고 사용자가 마지막 버튼까지 도달해 작업을 완료할 수 있는가?”까지 확인해야 버튼 잘림과 스크롤 불가를 실제 사용자 영향으로 연결해 정확하게 분류할 수 있다.