Intlayer: 고급 기능과 최적화가 필요한 전문 Solid 애플리케이션을 위한 추천 선택(v8.7.12).
@solid-primitives/i18n: 단순한 프로젝트를 위한 훌륭한 경량 대안이지만 지연 로딩과 같은 고급 기능이 부족합니다.
solid-i18next: 표준적이지만 무거운 옵션(Intlayer의 약 4.7배)으로 React i18next와 동일한 단점을 공유합니다.
Paraglide: 혁신적인 접근 방식이지만 DX가 복잡하고 일부 설정에서 트리 쉐이킹 문제가 발생합니다.

앱 테스트하기

i18n 누수 문제를 빠르게 파악하기 위해 여기에서 시도해 볼 수 있는 무료 스캐너를 구축했습니다.

intlayer.org

문제점

다국어 앱의 비용을 제한하려면 두 가지 레버가 필수적입니다:

페이지 / 네임스페이스별로 콘텐츠를 분리하여 필요하지 않을 때 전체 사전을 로드하지 않도록 합니다.
필요할 때만 올바른 로케일을 동적으로 로드합니다.

이러한 접근 방식의 기술적 한계 이해:

동적 로딩

동적 로딩이 없으면 대부분의 솔루션은 첫 번째 렌더링부터 메시지를 메모리에 유지하므로 경로와 로케일이 많은 앱의 경우 상당한 오버헤드가 발생합니다.

동적 로딩을 사용하면 초기 JS는 줄어들지만 언어 전환 시 추가 요청이 발생할 수 있는 장단점을 수용하게 됩니다.

콘텐츠 분리

t('a.b.c')를 중심으로 구축된 구문은 매우 편리하지만 런타임에 큰 JSON 객체를 유지하도록 조장하는 경우가 많습니다. 이 모델은 라이브러리가 실제 페이지별 분리 전략을 제공하지 않는 한 트리 쉐이킹을 어렵게 만듭니다.

연구 방법론

이 벤치마크에서는 다음과 같은 라이브러리를 비교했습니다:

Base App (i18n 라이브러리 없음)
solid-intlayer (v8.7.12)
@solid-primitives/i18n (v2.2.1)
solid-i18next (v17.0.2)
@inlang/paraglide-js (v2.17.0)

프레임워크는 Solid이며 10개의 페이지와 10개의 언어를 가진 다국어 앱을 사용했습니다.

네 가지 로딩 전략을 비교했습니다:

테이블의 모든 내용 표시

테이블을 모달로 열어 모든 데이터를 명확하게 확인

전략	네임스페이스 없음 (글로벌)	네임스페이스 포함 (스코프)
정적 로딩	Static: 시작 시 모든 것을 메모리에 로드.	Scoped static: 네임스페이스별 분리; 시작 시 모든 것을 로드.
동적 로딩	Dynamic: 로케일별 온디맨드 로딩.	Scoped dynamic: 네임스페이스 및 로케일별 세분화된 로딩.

전략 요약

Static: 간단함. 초기 로드 후 네트워크 지연 없음. 단점: 큰 번들 크기.
Dynamic: 초기 무게 감소(지연 로딩). 로케일이 많을 때 적합함.
Scoped static: 복잡한 추가 네트워크 요청 없이 코드 구조를 유지(논리적 분리).
Scoped dynamic: 코드 분할 및 성능을 위한 최선의 접근 방식. 현재 뷰와 활성 로케일에 필요한 것만 로드하여 메모리 사용을 최소화함.

측정 내용:

각 스택에 대해 실제 브라우저에서 동일한 다국어 앱을 실행한 후 실제로 전송된 내용과 소요 시간을 기록했습니다. 크기는 일반적인 웹 압축 후에 보고되었습니다. 이는 원본 소스 수보다 사람들이 다운로드하는 내용에 더 가깝기 때문입니다.

국제화 라이브러리 크기: 번들링, 트리 셰이킹 및 축소 후 i18n 라이브러리의 크기는 빈 컴포넌트의 제공자 + 훅/프리미티브 코드의 크기입니다. 여기에는 번역 파일 로딩이 포함되지 않습니다. 콘텐츠가 들어오기 전에 라이브러리가 얼마나 비싼지 답변합니다.
페이지당 JavaScript: 각 벤치마크 경로의 경우, 그 방문 시 브라우저가 가져오는 스크립트의 양은 스위트의 페이지 전체에서 평균화됩니다(보고서가 롤업하는 로케일 전체). 무거운 페이지는 느린 페이지입니다.
다른 로케일의 누수: 감사된 페이지에 실수로 로드되는 다른 언어의 동일 페이지 콘텐츠입니다. 이 콘텐츠는 불필요하며 피해야 합니다. (예: /en/about 페이지 번들의 /fr/about 페이지 콘텐츠)
다른 경로의 누수: 다른 화면의 경우 동일한 개념입니다. 한 페이지만 열었을 때 해당 사본이 함께 로드되는지 여부입니다. (예: /en/contact 페이지 번들의 /en/about 페이지 콘텐츠). 높은 점수는 약한 분할이나 과도하게 광범위한 번들을 의미합니다.
평균 컴포넌트 번들 크기: 일반적인 UI 조각은 하나의 거대한 앱 번호 내에 숨기는 대신 한 번에 하나씩 측정됩니다. 국제화가 일반적인 컴포넌트를 조용히 부풀리는지 여부를 보여줍니다. 예를 들어, 컴포넌트가 다시 렌더링되면 메모리에서 모든 데이터를 로드합니다. 거대한 JSON을 컴포넌트에 연결하는 것은 컴포넌트의 성능을 느리게 할 사용하지 않은 데이터의 큰 저장소를 연결하는 것과 같습니다.
언어 전환 반응성: 앱의 고유한 제어 기능을 사용하여 언어를 전환하고 페이지가 명확하게 전환될 때까지 걸리는 시간을 기록합니다. 이는 방문자가 알아차릴 미시적 단계가 아닌 것입니다.
언어 변경 후 렌더링 작업: 더 좁은 후속 작업입니다. 전환이 진행 중일 때 새로운 언어로 다시 칠하는 데 인터페이스가 소비한 노력입니다. "느껴지는" 시간과 프레임워크 비용이 다를 때 유용합니다.
초기 페이지 로드 시간: 네비게이션에서 브라우저가 테스트한 시나리오에 대해 페이지가 완전히 로드되었다고 간주할 때까지의 시간입니다. 콜드 스타트를 비교하는 데 좋습니다.
하이드레이션 시간: 앱이 노출하는 경우, 클라이언트가 서버 HTML을 실제로 클릭할 수 있는 것으로 변환하는 데 소비하는 시간입니다. 표의 대시는 해당 구현이 이 벤치마크에서 신뢰할 수 있는 하이드레이션 수치를 제공하지 않았음을 의미합니다.

GitHub 스타

GitHub 스타는 프로젝트의 인기, 커뮤니티 신뢰 및 장기적인 관련성을 나타내는 강력한 지표입니다. 기술적 품질을 직접적으로 측정하는 것은 아니지만, 얼마나 많은 개발자가 프로젝트가 유용하다고 생각하고 진행 상황을 팔로우하며 채택할 가능성이 있는지를 반영합니다. 프로젝트의 가치를 평가할 때 스타는 대안 간의 견인력을 비교하는 데 도움이 되며 생태계 성장에 대한 통찰력을 제공합니다.

결과 상세

1 - 피해야 할 솔루션

Solid 에코시스템에서 분명하게 피해야 할 솔루션은 없습니다.

2 - 수용 가능한 솔루션

(solid-i18next) (solid-i18next@17.0.2):

solid-i18next는 JavaScript 앱의 i18n 요구 사항을 충족시킨 초창기 솔루션 중 하나였기 때문에 가장 인기 있는 옵션일 것입니다. 또한 특정 문제를 해결하기 위한 광범위한 커뮤니티 플러그인 세트를 보유하고 있습니다.

패키지가 무겁습니다 (~14.6kb, solid-intlayer의 약 4.7배).

여전히 t('a.b.c') 위에 구축된 스택과 동일한 주요 단점을 공유합니다: 최적화는 가능하지만 시간이 매우 많이 소요되며, 대규모 프로젝트는 나쁜 관행(네임스페이스 + 동적 로딩 + 타입)에 빠질 위험이 있습니다.

(@solid-primitives/i18n) (@solid-primitives/i18n@2.2.1):

Solid primitive는 매우 가볍고 효율적입니다. 소규모 프로젝트에는 이 솔루션을 추천하지만 쿠키 관리, 프록시 리다이렉션, 포맷터 등을 포함한 전문 솔루션에는 기능이 부족할 수 있습니다. 또한 페이지 크기 최적화를 위한 지연 로딩 및 네임스페이스 스코핑 기능도 누락되어 있습니다.

(Paraglide) (@inlang/paraglide-js@2.17.0):

Paraglide는 혁신적이고 잘 설계된 접근 방식을 제공합니다. 그럼에도 불구하고 이 벤치마크에서는 광고된 트리 쉐이킹이 나의 구현에서 작동하지 않았습니다. 워크플로우와 DX 또한 다른 옵션보다 복잡합니다. 개인적으로 푸시할 때마다 JS 파일을 다시 생성해야 하는 것을 선호하지 않으며, 이는 PR을 통한 개발자들 간의 지속적인 머지 충돌 위험을 만듭니다. 마지막으로 다른 솔루션과 비교하여 Paraglide는 콘텐츠를 렌더링하기 위한 현재 로케일을 가져오기 위해 스토어(예: Solid signal)를 사용하지 않습니다. 파싱되는 각 노드에 대해 localStorage / 쿠키 등에서 로케일을 요청합니다. 이는 컴포넌트 반응성에 영향을 미주는 불필요한 로직 실행을 초래합니다.

3 - 추천 사항

(Intlayer) (solid-intlayer@8.7.12):

객관성을 위해 나의 솔루션인 solid-intlayer에 대해서는 직접 판단하지 않겠습니다.

개인적인 의견

이 의견은 개인적인 것이며 벤치마크 결과에는 영향을 미치지 않습니다. 그럼에도 불구하고 i18n 세계에서는 번역된 콘텐츠를 위해 const t = useTranslation('xx') + <>{t('xx.xx')}</>와 같은 패턴에 대한 합의가 자주 보입니다.

Solid 앱에서 함수를 JSX.Element로 주입하는 것은 내 견해로는 안티 패턴입니다. 또한 피할 수 있는 복잡성과 JavaScript 실행 오버헤드(거의 눈에 띄지 않더라도)를 추가합니다.

Vue

Svelte

버전 기록

Solid i18n 라이브러리 - 2026 벤치마크 리포트

목차

인터랙티브 벤치마크

결과 참조:

서론

TL;DR