대용량 번역 파일 분할: 네임스페이스 기반 로딩으로 더 빠른 앱
번역 파일이 페이지 로드 시간을 조용히 죽이고 있습니다. 500개 이상의 키를 가진 일반적인 국제화 앱은 언어당 400-800KB의 번역 번들을 생성합니다. 15개 언어를 곡하면 6-12MB의 번역 데이터를 제공하는 셔이죠 — 대부분 사용자가 보지 않는 것들입니다. 이...
목차
번역 파일이 페이지 로드 시간을 조용히 죽이고 있습니다. 500개 이상의 키를 가진 일반적인 국제화 앱은 언어당 400-800KB의 번역 번들을 생성합니다. 15개 언어를 곡하면 6-12MB의 번역 데이터를 제공하는 셔이죠 — 대부분 사용자가 보지 않는 것들입니다.
이 가이드는 이런 일이 발생하는 이유, 네임스페이스 기반 분할이 이를 해결하는 방법, 번역 페이로드를 90-97% 줄이는 실용적 구현 패턴을 다룹니다.
모놀리식 번역 파일의 숨겨진 비용
실제 사례: Better i18n의 랜딩 페이지는 59개 네임스페이스에 699개 키로 성장했습니다. 영어 translations.json은 478KB였습니다. 힌디어 번역은 841KB였습니다. 모든 방문자가 전체 파일을 다운로드했습니다 — 가격 페이지만 방문해도 (14개 키, ~2KB 필요).
성능 벤치마크
| 지표 | 이전 (모놀리식) | 이후 (namespace 분할) | 개선 |
|---|---|---|---|
| 번역 페이로드 | 478 KB | 12 KB | 97.5% 감소 |
| Time to First Byte | 180ms | 45ms | 75% 빠름 |
| CDN 대역폭/월 | 48 GB | 2.1 GB | 95.6% 감소 |
| 캐시 적중률 | 62% | 94% | +32포인트 |
결론
대용량 번역 파일은 해결 가능한 성능 문제입니다. 15개 이상의 언어와 500개 이상의 키를 제공하는 앱의 경우, 이 하나의 변경으로 번역 페이로드를 90-97% 줄이고 CDN 대역폭을 95% 절감할 수 있습니다.