i18next VS Intlayer | React & Next.js 국제화 (i18n) 벤チ마크 비교

i18next는 JavaScript 생태계에서 가장 널리 사용되는 i18n 프레임워크입니다. react-i18next와 next-i18next를 통해 수많은 React 및 Next.js 애플리케이션의 다국어를 지원하고 있습니다. Intlayer는 컴파일러 기반의 컴포넌트 스코프 콘텐츠 아키텍처를 제공하는 대안입니다.

이 글에서는 단순한 기능 나열 대신 실제 측정 지표를 바탕으로 두 솔루션을 비교합니다. 모든 수치는 동일한 애플리케이션을 각 라이브러리로 빌드하고 브라우저가 실제로 다운로드하는 리소스를 기록하는 오픈 소스 벤치마크 제품군 Benchmark Bloom에서 추출되었습니다.

요약: i18next는 벤치마크에서 가장 무거운 런타임입니다. 기본 설정의 Next.js에서 페이지당 +77 KB gzip, 네임스페이스와 지연 로딩을 완전히 최적화한 후에도 +22 KB가 추가됩니다. 반면 Intlayer의 증가량은 +0.3 KB에 불과합니다. 완전히 스코프가 분리된 설정을 제외한 모든 i18next 구성은 방문하지 않은 페이지의 문자열을 약 90% 누출시키지만, Intlayer는 기본적으로 0%입니다. 지연 로드 백엔드를 통한 로케일 전환 시간은 react-i18next가 123-185 ms인 반면 Intlayer는 3-4 ms였습니다. i18next API를 그대로 유지하는 호환 어댑터 @intlayer/next-i18next는 원본의 218.5 KB에서 150.7 KB로 페이지 크기를 줄였습니다.

요약 비교

• i18next / react-i18next / next-i18next - 성숙하고 플러그인이 풍부하며 프레임워크에 구애받지 않습니다. 네임스페이스, 언어 감지기, 백엔드, 플러그인을 통한 ICU 지원, 서식 있는 텍스트를 위한 <Trans> 컴포넌트를 제공합니다. 콘텐츠는 locales/{lng}/{ns}.json에 중앙 집중화되어 관리됩니다. 강력하지만 모든 최적화(네임스페이스 분할, 페이지별 로딩, 타입 안전성)를 개발자가 직접 구성하고 관리해야 합니다.
• Intlayer - 컴포넌트 중심의 콘텐츠 모델입니다. .content.ts 사전 파일이 지원하는 컴포넌트 바로 옆에 위치하며, 빌드 타임 컴파일러가 컴포넌트 및 로케일별로 트리 쉐이킹과 지연 로딩을 수행합니다. 작성한 콘텐츠로부터 엄격한 TypeScript 타입이 자동 생성되고, 번역 누락 시 빌드가 실패합니다. 미들웨어, SEO 헬퍼, 비주얼 에디터 / CMS 및 AI 기반 번역 기능을 기본 탑재하고 있습니다.

테이블의 모든 내용 표시

테이블의 모든 내용 표시

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

라이브러리	GitHub 스타	총 커밋 수	최근 커밋	최초 출시	NPM 버전	NPM 다운로드 수
aymericzip/intlayer				2024년 4월
i18next/i18next				2012년 1월
i18next/react-i18next				2015년 12월
i18next/next-i18next				2018년 11월

배지는 자동으로 업데이트됩니다. 스냅샷 수치는 시간에 따라 달라질 수 있습니다.

주요 기능 비교

벤치마크

측정 기준 및 환경

Benchmark Bloom 테스트 스위트는 각 라이브러리를 사용하여 완전히 동일한 애플리케이션을 빌드합니다: 10개 페이지(홈, 소개, 블로그, 채용, 문의, FAQ, 가격, 제품, 설정, 팀), 10개 로케일(en, fr, es, de, it, pt, zh, ja, ko, ru), 동일한 컴포넌트 및 동일한 콘텐츠. 측정은 en과 fr 페이지를 대상으로 진행되었습니다.

각 라이브러리는 최소 설정부터 최적화 설정까지 최대 네 가지 로딩 전략으로 구현되었습니다:

Intlayer는 별도의 "scoped" 변형이 없습니다. 컴파일러가 콘텐츠를 컴포넌트 단위로 자동 분리하므로 static과 dynamic 행이 이미 최적화된 상태입니다.

각 빌드에 대해 측정된 메트릭:

• Lib size: i18n 라이브러리만 import하는 빈 컴포넌트의 gzip 크기. 런타임의 기본 오버헤드.
• Page JS: 페이지당 다운로드되는 JavaScript gzip 크기 (전체 페이지 및 로케일의 평균).
• Locale leak %: 다운로드된 JS 내 번역 문자열 중 사용자가 보고 있지 않은 언어의 비율.
• Page leak %: 다운로드된 JS 내 번역 문자열 중 사용자가 머물고 있지 않은 페이지의 비율.
• Component avg: 개별적으로 격리 컴파일된 각 컴포넌트의 평균 gzip 크기.
• E2E reactivity: 새 언어를 선택한 시점부터 DOM의 html[lang]이 업데이트될 때까지의 실제 소요 시간 (Playwright 5회 측정).
• Hydration: React 하이드레이션 단계 소요 시간.

아래 수치는 next-i18next 16.3.0, react-i18next 17.0.13, intlayer 9.5.1을 사용한 2026-09-12 측정 결과입니다. 테스트 애플리케이션은 의도적으로 작게 설계되었으므로(로케일당 수십 개 문자열), 누출 백분율은 패턴을 나타냅니다. 콘텐츠가 늘어날수록 누출량은 증가하지만 런타임 비용은 고정됩니다.

Next.js 결과 (next-i18next)

결과 분석

• 런타임 오버헤드: i18next 코어와 react-i18next의 결합은 측정된 런타임 중 가장 무거운 19.7 KB gzip을 기록했습니다 (Intlayer는 5.5 KB).
• 기본 구성의 비효율: init()에 resources를 직접 넣는 방식은 기본 앱 대비 +77.5 KB 증가한 218.5 KB/페이지를 다운로드합니다. 모든 페이지에 모든 네임스페이스가 포함되기 때문입니다.
• 최적화에 필요한 많은 비용: 백엔드 방식(dynamic)을 도입하면 49 KB를 절감하지만 여전히 타 페이지 문자열이 90% 누출되며, 이 구성에서는 절반이 다른 로케일의 문자열입니다. 라우트별 네임스페이스 분할(scoped-dynamic)을 적용해야 비로소 0% 누출과 163.4 KB에 도달하지만, 설정이 전혀 필요 없는 Intlayer(141.3 KB)보다 여전히 +22.4 KB/페이지 더 큽니다.
• 컴포넌트 크기: useTranslation()을 호출하는 컴포넌트는 설정에 따라 26~79 KB에 달하지만, useIntlayer()를 사용하는 동일 컴포넌트는 6.9 KB에 불과합니다.
• 하이드레이션 지연: dynamic 구성에서 하이드레이션 시간이 27.7 ms로 급증합니다. React가 하이드레이션을 수행하기 전에 클라이언트에서 i18next 인스턴스가 초기화되고 백엔드를 처리해야 하기 때문입니다.

TanStack Start 결과 (react-i18next)

Next.js 특유의 구조적 차이를 배제하고 TanStack Start 환경에서 순수 react-i18next로 측정한 결과입니다.

결과 분석

• 기본 react-i18next 앱은 기준 앱 대비 +69 KB/페이지를 다운로드하며, 하이드레이션에 85 ms(기준 앱의 4배)가 소요됩니다. 첫 렌더링 전에 전체 리소스 트리가 클라이언트에서 파싱 및 등록되기 때문입니다.
• 로케일 전환 시 지연 문제: 리소스를 필요할 때 로드하는 백엔드를 사용할 경우 언어 변경 시 네트워크 왕복이 발생하여 html[lang] 갱신까지 지연이 발생합니다: dynamic에서 123 ms, scoped-static에서 185 ms. 반면 Intlayer는 두 모드 모두에서 3-4 ms 내에 DOM을 업데이트합니다.
• 고도로 최적화된 scoped-dynamic 설정도 127.2 KB로 여전히 Intlayer의 dynamic보다 +8.6 KB 더 무거우며, 이를 위해 라우트-네임스페이스 맵, 백엔드 및 Suspense 설정이 필요했습니다.
• Intlayer의 static은 해당 페이지의 컴포넌트가 직접 임포트한 사전만 포함하므로 이미 페이지 누출 0%를 달성합니다. importMode: 'dynamic'을 활성화하면 로케일 누출도 완전히 제거됩니다.
• 컴포넌트 크기: react-i18next 컴포넌트가 24-27 KB인 반면 Intlayer는 6-8 KB입니다.

차이의 원인: 글로벌 인스턴스 vs 컴파일된 사전

i18next는 2012년에 런타임 중심 모델로 설계되었습니다: 글로벌 인스턴스가 리소스 저장소를 관리하고 플러그인이 이를 확장하며, 렌더링 시 t()가 키를 조회합니다. 이는 매우 유연하지만(어떤 프레임워크나 포맷도 지원) 구조적인 오버헤드를 유발합니다:

.
├── i18n.ts                      # createInstance().use(...).use(...).init({...})
└── src
    ├── locales
    │   ├── en
    │   │   ├── common.json
    │   │   ├── home.json
    │   │   └── about.json
    │   └── fr
    │       ├── common.json
    │       ├── home.json
    │       └── about.json
    ├── components
    │   └── Counter.tsx          # useTranslation("about") + t("counter.label")
    └── app
        └── [locale]
            └── about
                └── page.tsx     # ["common", "about"] 필요 여부를 직접 알아야 함

인스턴스는 컴포넌트가 어떤 키를 요청할지 미리 알 수 없으므로 지시된 모든 네임스페이스를 유지합니다. 따라서 최적화를 위해 개발자가 카탈로그를 분할하고, 페이지별 네임스페이스를 정의하고, 컴포넌트 이동 시마다 이를 관리해야 합니다. 벤치마크 노트에서 언급하듯 "타입 안전성을 유지하면서 각 페이지에 필요한 네임스페이스를 완벽히 파악하는 것은 매우 번거로운 일"입니다.

Intlayer는 글로벌 인스턴스를 사용하지 않습니다. 콘텐츠가 컴포넌트 옆에 선언되며 컴파일러가 빌드 타임에 종속성 트리를 분석합니다:

.
├── intlayer.config.ts
└── src
    ├── components
    │   └── Counter
    │       ├── index.tsx        # useIntlayer("counter")
    │       └── index.content.ts
    └── app
        └── [locale]
            └── about
                ├── page.tsx
                └── page.content.ts

@intlayer/swc / @intlayer/babel은 어떤 컴포넌트가 어떤 사전을 임포트하는지 확인하여 활성 언어에 필요한 것만 번들링하고 사용되지 않는 항목은 제거합니다. "scoped-dynamic" 패턴이 수동 관리 없이 빌드 결과물로 자동 도출됩니다.

dynamic 행의 성능을 적용하려면 intlayer.config.ts에서 dictionary.importMode: 'dynamic'을 설정하십시오. 자세한 내용은 번들 최적화 문서를 참고하세요.

개발자 경험 (DX)

초기 설정 비교

next-i18next (App Router)

import { createInstance } from "i18next";
import { initReactI18next } from "react-i18next/initReactI18next";
import resourcesToBackend from "i18next-resources-to-backend";
import { defaultLocale } from "@/i18n.config";

const backend = resourcesToBackend(
  (locale: string, namespace: string) =>
    import(`../../locales/${locale}/${namespace}.json`)
);

export const initI18next = async (
  locale: string,
  namespaces: string[] = ["common"]
) => {
  const i18n = createInstance();
  await i18n
    .use(initReactI18next)
    .use(backend)
    .init({
      lng: locale,
      fallbackLng: defaultLocale,
      ns: namespaces,
      defaultNS: "common",
      interpolation: { escapeValue: false },
      react: { useSuspense: false },
    });
  return i18n;
};

여기에 추가로 클라이언트용 I18nProvider, generateStaticParams, 그리고 각 페이지의 namespaces 목록 관리가 필요합니다.

Intlayer

import { type IntlayerConfig, Locales } from "intlayer";

const config: IntlayerConfig = {
  internationalization: {
    locales: [Locales.ENGLISH, Locales.FRENCH],
    defaultLocale: Locales.ENGLISH,
  },
};

export default config;

import { getHTMLTextDir } from "intlayer";
import { IntlayerClientProvider, type NextLayoutIntlayer } from "next-intlayer";

const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
  const { locale } = await params;

  return (
    <html lang={locale} dir={getHTMLTextDir(locale)}>
      <body>
        <IntlayerClientProvider locale={locale}>
          {children}
        </IntlayerClientProvider>
      </body>
    </html>
  );
};

export default LocaleLayout;

클라이언트 컴포넌트

react-i18next

{
  "counter": {
    "label": "Counter",
    "increment": "Increment"
  }
}

"use client";

import { useState } from "react";
import { useTranslation } from "react-i18next";

export const Counter = () => {
  const { t, i18n } = useTranslation("about");
  const [count, setCount] = useState(0);
  const numberFormat = new Intl.NumberFormat(i18n.language);

  return (
    <div>
      <p>{numberFormat.format(count)}</p>
      <button
        aria-label={t("counter.label")}
        onClick={() => setCount((c) => c + 1)}
      >
        {t("counter.increment")}
      </button>
    </div>
  );
};

이 컴포넌트를 렌더링하는 페이지는 about 네임스페이스를 로드해야 하며, CustomTypeOptions를 확장하지 않으면 t("counter.label")에 엄격한 타입이 적용되지 않습니다.

Intlayer

import { t, type Dictionary } from "intlayer";

const counterContent = {
  key: "counter",
  content: {
    label: t({ en: "Counter", fr: "Compteur" }),
    increment: t({ en: "Increment", fr: "Incrémenter" }),
  },
} satisfies Dictionary;

export default counterContent;

"use client";

import { useState } from "react";
import { useIntlayer } from "next-intlayer";
import { useNumber } from "next-intlayer/format";

export const Counter = () => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label} onClick={() => setCount((c) => c + 1)}>
        {increment}
      </button>
    </div>
  );
};

label과 increment는 엄격히 타입이 지정됩니다. 오타는 TypeScript 에러가 되고, 프랑스어 번역 누락은 빌드 에러로 처리됩니다.

동기식 서버 컴포넌트

next-i18next

type ServerCounterProps = {
  t: (key: string) => string;
  locale: string;
  count: number;
};

export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
  <div>
    <p>{new Intl.NumberFormat(locale).format(count)}</p>
    <button aria-label={t("counter.label")}>{t("counter.increment")}</button>
  </div>
);

페이지에서 i18n.getFixedT(locale, "about")를 호출한 후 하위 컴포넌트로 t와 locale을 넘겨주어야 합니다.

Intlayer

import { useIntlayer } from "next-intlayer/server";
import { useNumber } from "next-intlayer/server/format";

export const ServerCounter = ({ count }: { count: number }) => {
  const { label, increment } = useIntlayer("counter");
  const number = useNumber();

  return (
    <div>
      <p>{number(count)}</p>
      <button aria-label={label}>{increment}</button>
    </div>
  );
};

i18next API를 유지하면서 Intlayer의 성능 얻기

기존 컴포넌트를 전부 다시 작성하지 않고도 벤치마크 성능을 누릴 수 있습니다. @intlayer/i18next, @intlayer/react-i18next, @intlayer/next-i18next는 드롭인 호환 어댑터입니다: useTranslation, t(), <Trans>, {{interpolation}}, 복수형 접미사, 컨텍스트 접미사 및 returnObjects가 그대로 작동하며, 백그라운드에서는 Intlayer 컴파일러가 사전을 공급합니다.

import type { NextConfig } from "next";
import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";

const withIntlayer = createNextI18nPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

import { defineConfig } from "vite";
import { reactI18nextVitePlugin } from "@intlayer/react-i18next/plugin";

export default defineConfig({
  plugins: [reactI18nextVitePlugin()],
});

벤치마크에서 동일한 Next.js 앱의 호환 빌드는 애플리케이션 코드를 수정하지 않고도 페이지당 218.5 KB에서 150.7 KB로, 컴포넌트당 78.5 KB에서 9.7 KB로, 페이지 누출은 ~90%에서 0%로, 하이드레이션은 15.6 ms에서 11.3 ms로 단축되었습니다. 기존의 locales/{lng}/{ns}.json 파일은 JSON 동기화 플러그인을 통해 신뢰할 수 있는 단일 원천(source of truth)으로 계속 사용할 수 있습니다.

마이그레이션 가이드를 참고하세요: i18next, react-i18next, next-i18next.

어떤 도구를 선택해야 할까요?

• i18next를 선택할 경우: 광범위한 플러그인 생태계(감지기, 백엔드, ICU, Locize 등)가 필수적이거나, React 외부 환경(Node 서비스, Vanilla JS, 기타 프레임워크)에서도 동일하게 사용해야 하거나, 팀원들이 이미 익숙하거나, 번역 플랫폼이 locales/{lng}/{ns}.json을 요구할 때. 단, 성능이 중요하다면 네임스페이스 분할과 라우트 매핑 관리에 시간을 투자해야 합니다.
• Intlayer를 선택할 경우: 컴포넌트 중심의 콘텐츠 관리, 엄격한 TypeScript 타입 지원, 빌드 시 누락 번역 감지, 무설정 트리 쉐이킹 및 지연 로딩, 즉각적인 로케일 전환, 동기식 서버 컴포넌트, 통합 편집 도구(비주얼 에디터, CMS, AI 번역, MCP 서버)를 원할 때. 모듈식 코드베이스 및 디자인 시스템에 특히 적합합니다.
• @intlayer/*-i18next 어댑터를 선택할 경우: 이미 i18next를 사용 중이며 코드 리팩토링 없이 번들 크기와 반응성을 대폭 개선하고 싶을 때.

관련 비교 자료

• next-intl vs Intlayer (동일 벤치마크)
• Lingui vs Intlayer (동일 벤치마크)
• vue-i18n vs Intlayer 벤치마크 (동일 벤치마크)
• next-i18next vs next-intl vs Intlayer
• react-i18next vs react-intl vs Intlayer
• i18next는 구식인가요?

GitHub 스타

GitHub 스타는 프로젝트의 인기, 커뮤니티의 신뢰도 및 장기적인 지속 가능성을 보여주는 중요한 지표입니다. 기술적 완성도를 직접적으로 나타내는 것은 아니지만, 많은 개발자가 해당 프로젝트의 가치를 인정하고 활발히 채택하고 있음을 반영합니다.

결론

i18next는 뛰어난 범용성과 강력한 플러그인 생태계로 지난 10년 이상 업계 표준의 위치를 지켜왔습니다. 그러나 벤치마크는 런타임 중심 아키텍처가 야기하는 비용을 명확히 보여줍니다. 일반적인 설정은 페이지당 +70~77 KB gzip을 소모하고, 타 페이지 문자열을 ~90% 누출시키며, 지연 로딩 시 언어 전환에 100 ms 이상이 걸립니다. 수동 최적화로 누출을 0%로 줄일 수는 있지만 많은 관리 비용이 수반되며, 그럼에도 Intlayer보다 9~22 KB 무겁습니다.

Intlayer는 이러한 모든 작업을 컴파일러로 이전했습니다. 컴포넌트별 사전 분할, 로케일별 지연 로딩, 미사용 콘텐츠 제거가 빌드 과정에서 자동으로 이루어집니다. 동일한 앱에서: 페이지당 +0.3 KB, 누출 0%, 3~10배 작은 컴포넌트, 3~4 ms 로케일 전환을 경험할 수 있습니다.

모든 원시 데이터, 테스트 앱 및 스크립트는 Benchmark Bloom 저장소에서 직접 확인하고 검증하실 수 있습니다.

자세한 내용은 '왜 Intlayer인가요?' 문서를 참조하십시오.