앱 시작 로딩 화면의 짧은 문구가 가끔 늦게 나타나거나 기본 폰트로 잠깐 바뀌었다. 다국어 시스템과 폰트 자산이 준비되기 전에 로딩 화면이 먼저 열렸기 때문이다. 문구 하나를 위해 큰 폰트와 번역 초기화를 앞당기면 시작 시간이 늘고 의존 관계가 더 복잡해졌다.
그래서 초기 몇 초에만 보이는 고정 문구를 언어별 이미지 자산으로 제공하는 선택을 검토했다. 모든 텍스트를 이미지로 바꾸는 게 아니라 부트스트랩 경로의 의존성을 줄이는 제한적인 결정이었다.
로딩 화면의 리소스 의존성
기존 흐름은 텍스트 표시 전에 여러 시스템을 기다렸다.
앱 시작 -> 설정 읽기 -> 언어 결정 -> 폰트 로드
-> 번역 파일 로드 -> 로딩 문구 표시
언어 판단에 필요한 최소 설정과 작은 이미지 묶음만 초기 빌드에 포함하면 다른 초기화와 병렬로 바로 표시할 수 있었다.
이미지 리소스 비용 측정
이미지는 문자열보다 번역 수정이 어렵고 해상도별 품질, 빌드 용량, 접근성 문제가 있었다. 여러 해상도에서 흐려지지 않도록 필요한 크기를 정하고 압축 후 용량을 비교했다.
초기 폰트 자산과 테이블 로드 비용
vs
지원 언어별 로딩 이미지 총용량
언어가 많아지면 이미지 방식의 비용이 빠르게 커지므로 적용 범위를 시작 문구 하나로 제한했다.
자산은 빌드에 포함되는 시점과 메모리에서 해제되는 시점도 확인했다. 로딩이 끝난 뒤에도 언어별 이미지가 모두 남아 있으면 시작 속도를 위해 런타임 메모리를 계속 사용하는 셈이었다. 필요한 자산만 불러오고 메인 화면 전환 뒤 참조를 정리했다.
접근 가능한 대체 정보 유지
이미지 안 글자는 스크린 리더가 읽지 못할 수 있다. 플랫폼이 제공하는 접근성 레이블이나 별도 텍스트 설명을 유지하고, 실제 기능 화면의 문구는 기존 텍스트 시스템을 사용했다.
언어를 아직 모르는 첫 실행에서는 중립적인 로딩 표시와 기준 언어 정책을 정했다. 잘못된 언어 이미지를 오래 보여주지 않게 했다.
번역 수정 때 이미지 재생성이 빠지지 않도록 원본 문구, 디자인 파일, 출력 자산의 버전 흐름도 정리했다. 화면 캡처 비교로 잘림과 비율을 확인했고, 오래된 이미지가 캐시에 남는 배포 경로도 시험했다.
의존성 축소 중심의 최적화
처음에는 텍스트보다 이미지가 빠르다는 단순한 결론처럼 보였다. 실제 이유는 부트스트랩 단계에서 큰 시스템 두 개를 기다리지 않게 만드는 데 있었다.
이 경험 뒤 로딩 최적화를 할 때 파일 크기 하나만 보지 않는다. 첫 화면까지 어떤 의존성을 반드시 준비해야 하는지, 무엇을 뒤로 미룰 수 있는지 본다. 선택의 장점과 함께 번역·접근성·유지보수 비용도 범위 안에 기록하게 됐다.
기술 문서 기반의 책임 경계
나중에 같은 증상을 다시 만나지 않으려고 문서에 적힌 기준으로 구현을 한 번 더 정리했다.
Rect Transform 문서의 anchor와 pivot을 기준으로 보면 해상도 대응은 좌표를 비율로 바꾸는 작업보다 부모 영역과 정렬 기준을 명시하는 작업에 가깝다. WCAG 2.1의 reflow와 orientation 기준도 특정 화면 크기를 맞추는 데서 끝나지 않고, 확대·회전 뒤에도 내용과 조작이 사라지지 않아야 한다는 관점을 준다.
그래서 기준 해상도 한 장만 통과하는 것보다 작은 폭, 긴 번역, 키보드가 올라온 상태를 별도 조건으로 두는 편이 낫다.
다음에 로딩 문구의 이미지 리소스 전환 같은 문제를 보면 아래 순서부터 확인하려고 한다.
- 최소 폭과 최대 글자 확대
- 회전 전후 선택·스크롤 위치
- safe area와 키보드가 줄인 가용 영역
- 이미지 비율과 대체 문구
안전 영역, 글자 확대, 소프트 키보드는 레이아웃 이후에 붙는 예외가 아니라 처음부터 가용 영역을 바꾸는 입력값이다.
공식 참고 자료
- Unity 2021.3 Rect Transform 문서 — 앵커·피벗과 부모 영역에 따른 UI 배치
- W3C WCAG 2.1 — 확대·reflow·orientation·입력 접근성