한 화면에서 가로모드를 맞춘 경험이 생겨 다른 화면도 비슷하게 바꾸면 될 줄 알았다. 목록 화면, 차트 화면, 주문 화면은 같은 방향 전환을 겪지만 중요한 정보와 입력 방식이 달랐다. 공통 스크립트에 화면 이름별 조건이 빠르게 늘어났다.
가로모드는 세로 화면을 옆으로 늘리는 작업이 아니라 제한된 높이에서 정보 우선순위를 다시 정하는 일이었다.
공통 계산 값 추출
방향, 안전 영역, 화면 비율처럼 모든 화면이 필요한 값은 하나의 레이아웃 문맥으로 만들었다.
public readonly record struct LayoutContext(
bool IsLandscape,
Rect SafeArea,
float AspectRatio,
LayoutSize Size);
각 화면은 이 문맥을 받아 자신의 배치를 결정했다. 전역 코드가 특정 버튼이나 패널 이름을 알지 않게 했다.
화면별 정보 노출 범위
목록은 열 수를 줄이고 상세 패널을 옆으로 보낼 수 있었다. 차트는 가로 공간을 최대한 쓰되 도구 버튼의 터치 영역을 유지해야 했다. 주문 화면은 입력 항목을 숨기기보다 스크롤을 허용하는 편이 안전했다.
목록 화면: 요약 열 우선, 상세는 선택 시 표시
차트 화면: 차트 영역 우선, 도구는 접을 수 있게
주문 화면: 필수 입력 유지, 보조 설명 축소
공통 규칙은 최소 여백과 안전 영역까지였고 정보 선택은 화면 책임으로 남겼다.
화면 회전 중간 상태
해상도 변경 이벤트가 한 번만 오는 게 아니어서 레이아웃을 연속으로 다시 만들면 흔들렸다. 프레임 끝에서 마지막 크기를 기준으로 한 번 적용하고, 실제 값이 바뀌었을 때만 갱신했다.
팝업이 열린 상태, 키보드가 올라온 상태, 차트 드래그 중 회전하는 경우도 따로 확인했다. 방향만 바꾸고 선택 상태나 입력 값은 유지해야 했다.
검증할 때는 기기 이름을 늘어놓기보다 작은 가로 화면, 넓은 가로 화면, 안전 영역이 있는 화면처럼 조건을 나눴다. 각 조건에서 잘림, 최소 터치 영역, 스크롤 가능 여부를 확인하니 새 기기가 추가돼도 같은 기준을 재사용할 수 있었다.
화면별 정책을 보존하는 공통화
처음에는 한 스크립트로 모든 가로모드를 처리하는 게 깔끔하다고 생각했다. 화면마다 조건문이 늘어나는 걸 보고 공통화할 대상은 환경 계산이고, 화면의 정보 우선순위는 각 화면이 결정해야 한다는 걸 알았다.
여러 화면을 대응하며 반응형 UI를 좌표 문제가 아닌 정책 문제로 보게 됐다. 같은 기기 방향에서도 사용자가 하려는 일이 다르면 레이아웃의 답도 달랐다.
기술 문서 기반의 책임 경계
이 문제를 고친 뒤 관련 공식 자료를 찾아 읽으면서, 당시 코드에서 우연히 맞았던 부분과 규칙으로 남겨야 할 부분을 나눠 봤다.
Rect Transform 문서의 anchor와 pivot을 기준으로 보면 해상도 대응은 좌표를 비율로 바꾸는 작업보다 부모 영역과 정렬 기준을 명시하는 작업에 가깝다. WCAG 2.1의 reflow와 orientation 기준도 특정 화면 크기를 맞추는 데서 끝나지 않고, 확대·회전 뒤에도 내용과 조작이 사라지지 않아야 한다는 관점을 준다.
그래서 기준 해상도 한 장만 통과하는 것보다 작은 폭, 긴 번역, 키보드가 올라온 상태를 별도 조건으로 두는 편이 낫다.
다음에 가로모드의 다중 화면 구조 같은 문제를 보면 아래 순서부터 확인하려고 한다.
- 최소 폭과 최대 글자 확대
- 회전 전후 선택·스크롤 위치
- safe area와 키보드가 줄인 가용 영역
- 이미지 비율과 대체 문구
안전 영역, 글자 확대, 소프트 키보드는 레이아웃 이후에 붙는 예외가 아니라 처음부터 가용 영역을 바꾸는 입력값이다.
공식 참고 자료
- Unity 2021.3 Rect Transform 문서 — 앵커·피벗과 부모 영역에 따른 UI 배치
- W3C WCAG 2.1 — 확대·reflow·orientation·입력 접근성