🌐 i18n 번들 크기 예측기 | 얼마나 커질까?

지원 언어 수

개

번역 키(문자열) 수

개

문자열 평균 길이

자

방식	초기 로딩 크기 (raw / gzip)
전체 번들 포함 (eager)	0KB / 0KB
언어별 지연 로딩 (lazy)	0KB / 0KB

언어가 늘어날수록 번들도 커진다, 얼마나?

다국어를 지원하는 웹 애플리케이션은 언어별 번역 파일을 관리해야 합니다. 문제는 이 번역 파일을 어떻게 로딩하느냐에 따라 실제 사용자가 다운로드하는 크기가 크게 달라진다는 점입니다. 모든 언어의 번역 데이터를 하나의 자바스크립트 번들에 포함시키면(eager loading), 지원 언어 수에 비례해 번들 크기가 선형적으로 늘어나고, 사용자는 실제로 필요하지 않은 언어의 데이터까지 함께 내려받게 됩니다.

반면 언어별로 파일을 분리하고 사용자가 선택한 언어만 지연 로딩(lazy loading)하면, 초기 로딩 크기는 언어 수와 무관하게 항상 한 언어 분량으로 고정됩니다. 이 계산기는 번역 키 수와 평균 문자열 길이를 기준으로 언어 하나당 대략적인 JSON 크기를 추정하고, 여기에 키·값 구조의 오버헤드를 더해 eager 방식과 lazy 방식의 크기를 비교해 보여줍니다. 번역 텍스트는 반복되는 단어와 패턴이 많아 gzip 압축률이 높은 편이라, 실제 전송 크기는 원본보다 훨씬 작아집니다.

실무에서는 i18next의 네임스페이스 분리, 라우트 단위 코드 스플리팅과 함께 지연 로딩을 적용하는 방식이 가장 널리 쓰입니다. 언어 수가 3개 이하로 적다면 eager 로딩도 무리 없지만, 5개 이상의 언어를 지원한다면 번들 크기 차이가 눈에 띄게 벌어지므로 지연 로딩 구조를 검토해 보는 것을 권장합니다.

자주 묻는 질문

i18n 번들 크기를 줄이는 가장 효과적인 방법은?

사용자가 선택한 언어만 지연 로딩하는 방식이 가장 효과적이며, 전체 언어를 하나의 번들에 담는 것보다 초기 로딩 크기를 크게 줄일 수 있습니다.

번역 파일도 gzip 압축이 효과가 있을까?

네, 번역 텍스트는 반복되는 패턴이 많아 압축률이 높은 편이라 gzip 적용 시 원본 대비 크기가 크게 줄어듭니다.

언어가 늘어나면 번들 크기는 어떻게 증가할까?

모든 언어를 하나의 번들에 포함하면 언어 수에 비례해 늘어나지만, 언어별로 분리해 지연 로딩하면 실제 사용자가 받는 크기는 늘지 않습니다.

언어가 늘어날수록 번들도 커진다, 얼마나?

자주 묻는 질문

같은 카테고리 도구