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