next-intl VS Intlayer: React & Next.js 국제화(i18n) 벤치마크

next-intl은 Next.js에서 가장 널리 사용되는 i18n 라이브러리입니다. Intlayer는 컴파일러 기반의 컴포넌트 스코프 대안입니다. 두 라이브러리 모두 App Router 애플리케이션을 현지화합니다. 질문은 앱이 빌드된 후 각각의 비용이 얼마인가 하는 것입니다.

이 기사는 튜토리얼이 아닙니다. 각 라이브러리로 동일한 애플리케이션을 빌드하고 브라우저가 실제로 다운로드하고 실행하는 것을 측정하는 오픈 소스 벤치마크 스위트인 Benchmark Bloom의 수치로 뒷받침된 비교입니다.

요약 (tl;dr): next-intl은 런타임 비용만으로도 페이지당 최소 +12.6 KB gzip을 추가하며, 표준 설정(static 및 dynamic)에서 다른 페이지 문자열의 약 90%를 누출합니다. 이 누출을 제거하려면 카탈로그를 네임스페이스로 분할하고 페이지별로 수동 선택해야 하는 번거로운 작업이 필요합니다. 반면 Intlayer 컴파일러는 추가 설정 없이도 누출 0%, 3배 더 작은 컴포넌트 크기, 기본 앱 대비 단 +0.3 KB 증가만을 보장합니다.

한눈에 보기

• next-intl - Next.js 커뮤니티의 표준. 언어별 중앙 집중식 JSON 사전, 완전한 ICU MessageFormat 지원, Next.js 요청 처리 및 라우팅과의 긴밀한 통합.
• Intlayer - 컴포넌트 중심 콘텐츠 모델. .content.ts 파일이 담당 컴포넌트 바로 옆에 위치하며, 빌드 타임 컴파일러가 컴포넌트 및 로케일별로 트리 셰이킹과 지연 로딩을 수행하고 엄격한 TypeScript 타입을 자동으로 생성합니다.

테이블의 모든 내용 표시

테이블의 모든 내용 표시

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

라이브러리	GitHub 스타	총 커밋 수	최근 커밋	첫 릴리스	NPM 버전	NPM 다운로드 수
aymericzip/intlayer				2024년 4월
amannn/next-intl				2021년 3월

배지는 자동으로 업데이트됩니다.

기능별 직접 비교

벤치마크

측정 항목

Benchmark Bloom 테스트 스위트는 각 라이브러리로 동일한 애플리케이션을 빌드합니다. 10개 페이지(home, about, blog, careers, contact, FAQ, pricing, products, settings, team), 10개 언어(en, fr, es, de, it, pt, zh, ja, ko, ru), 동일한 컴포넌트 및 동일한 콘텐츠로 구성됩니다. 페이지는 en과 fr로 측정됩니다. 각 라이브러리는 최대 4가지 로딩 전략으로 구현되었습니다.

Intlayer에는 "scoped" 변형이 없습니다. 컴파일러가 콘텐츠 범위를 컴포넌트별로 자동 제한하므로 static 및 dynamic 행이 이미 스코프화되어 있습니다.

각 빌드에 대해 스위트는 다음을 기록합니다:

• 라이브러리 크기 (Lib size): i18n 라이브러리만 가져오는 빈 컴포넌트의 gzip 크기.
• 페이지 JS (Page JS): 페이지당 다운로드된 gzip JavaScript 크기.
• 로케일 누출률 (Locale leak %): 사용자가 보지 않는 로케일에 속한 문자열의 비율.
• 페이지 누출률 (Page leak %): 사용자가 머물고 있지 않은 페이지에 속한 문자열의 비율.
• 컴포넌트 평균 크기 (Component avg): 격리되어 컴파일된 각 컴포넌트의 평균 gzip 크기.
• E2E 반응성: 새 언어 선택부터 DOM의 html[lang] 업데이트까지의 시간.
• 하이드레이션 (Hydration): React 하이드레이션 단계의 소요 시간.

아래 수치는 next-intl 4.14.2 및 intlayer 9.5.1을 사용한 2026-09-12 실행 결과입니다.

Next.js (App Router) 결과

관심 있는 메트릭과 라이브러리를 선택하세요:

결과 해석

• 런타임 비용. 기본 앱은 페이지당 141.0 KB입니다. next-intl은 이를 153.6 KB(모든 페이지에서 +12.6 KB gzip)로 늘리지만, Intlayer는 141.3 KB(+0.3 KB)로 거의 차이가 없습니다.
• 콘텐츠 누출. 가장 흔히 사용되는 설정(static 및 dynamic)에서 next-intl은 전체 en.json이 클라이언트 공급자에 들어가기 때문에 페이지마다 다른 페이지 문자열의 약 90%를 전송합니다. 이를 0%로 만들려면 복잡한 수동 네임스페이스 분할이 필요하지만, Intlayer는 기본적으로 0%입니다.
• 컴포넌트 크기. useTranslations()를 호출하는 컴포넌트는 평균 21.8 KB로 컴파일되지만, useIntlayer()를 사용하는 동일한 컴포넌트는 단 6.9 KB입니다.

모든 라이브러리와 전략이 포함된 전체 표는 Next.js 벤치마크 보고서에서 확인하세요.

TanStack Start (use-intl) 결과

use-intl은 next-intl의 프레임워크 독립적인 핵심 코어입니다. 동일한 API, 동일한 메시지 형식을 사용합니다. TanStack Start에서 이를 intlayer와 비교하면 방정식에서 Next.js 관련 요소를 배제할 수 있습니다.

결과 해석

• 단순한 use-intl 설정은 기본 앱보다 페이지당 68.8 KB 더 많은 JS를 전송합니다.
• dynamic 모드에서도 use-intl은 119.4 KB에 달하며 여전히 89.8%의 페이지 누출을 유지합니다.
• 아키텍처의 차이는 컴포넌트 크기에서 명확히 드러납니다. use-intl의 76-87 KB 대비 Intlayer는 6-8 KB에 불과합니다.
• 로케일 전환 속도는 Intlayer가 2~4배 더 빠릅니다(3 ms vs 7-21 ms).

전체 표는 TanStack Start 벤치마크 보고서에서 확인하세요.

왜 이런 차이가 발생하는가? 중앙 집중식 카탈로그 vs 컴파일된 사전

next-intl은 전통적인 방식을 따릅니다. 로케일당 하나의 JSON 파일이 getRequestConfig에서 로드되고, NextIntlClientProvider에 전달되며, t("namespace.key")로 읽힙니다.

.
├── messages
│   ├── en.json
│   └── fr.json
└── src
    ├── i18n
    │   ├── request.ts
    │   └── routing.ts
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                └── page.tsx

런타임은 페이지에서 어떤 키가 사용될지 미리 알 수 없으므로 전체 카탈로그를 전송하는 것이 유일하게 안전한 기본값입니다.

최적화에 도달하지 못할 때 발생하는 비용은 페이지와 언어라는 두 축에서 동시에 증가합니다:

Intlayer는 이 구조를 완전히 뒤집습니다. 콘텐츠는 컴포넌트 바로 옆에 선언됩니다.

.
├── intlayer.config.ts
└── src
    ├── middleware.ts
    └── app
        └── [locale]
            ├── layout.tsx
            └── about
                ├── page.tsx
                └── page.content.ts
    └── components
        └── Counter
            ├── index.tsx
            └── index.content.ts

빌드 시 컴파일러는 어떤 컴포넌트가 어떤 사전을 가져오는지 감지하여 활성 로케일에 필요한 사전만 번들링합니다.

dynamic 행의 수치를 얻으려면 intlayer.config.ts에서 dictionary.importMode: 'dynamic'을 설정하세요. 번들 최적화 문서를 참조하세요.

개발자 경험

클라이언트 컴포넌트

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

"use client";

import { useState } from "react";
import { useTranslations, useFormatter } from "next-intl";

export const Counter = () => {
  const t = useTranslations("counter");
  const format = useFormatter();
  const [count, setCount] = useState(0);

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

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>
  );
};

동기식 서버 컴포넌트

디자인 시스템 요소(내비게이션 바, 바닥글, 카드 등)는 클라이언트 컴포넌트의 자식으로 렌더링되는 서버 컴포넌트인 경우가 많으므로 비동기(async)일 수 없습니다.

type ServerCounterProps = {
  t: (key: string) => string;
  formattedCount: string;
};

export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
  <div>
    <p>{formattedCount}</p>
    <button aria-label={t("label")}>{t("increment")}</button>
  </div>
);

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>
  );
};

메타데이터

import type { Metadata } from "next";
import { getTranslations } from "next-intl/server";
import { routing } from "@/i18n/routing";

const localizedPath = (locale: string, path: string) =>
  locale === routing.defaultLocale ? path : `/${locale}${path}`;

export const generateMetadata = async ({
  params,
}: {
  params: Promise<{ locale: string }>;
}): Promise<Metadata> => {
  const { locale } = await params;
  const t = await getTranslations({ locale, namespace: "about" });

  const languages = Object.fromEntries(
    routing.locales.map((l) => [l, localizedPath(l, "/about")])
  );

  return {
    title: t("title"),
    description: t("description"),
    alternates: {
      canonical: localizedPath(locale, "/about"),
      languages: { ...languages, "x-default": "/about" },
    },
  };
};

import { getIntlayer, getMultilingualUrls } from "intlayer";
import type { Metadata } from "next";
import type { LocalPromiseParams } from "next-intlayer";

export const generateMetadata = async ({
  params,
}: LocalPromiseParams): Promise<Metadata> => {
  const { locale } = await params;
  const metadata = getIntlayer("about-metadata", locale);
  const multilingualUrls = getMultilingualUrls("/about");

  return {
    ...metadata,
    alternates: {
      canonical: multilingualUrls[locale as keyof typeof multilingualUrls],
      languages: { ...multilingualUrls, "x-default": "/about" },
    },
  };
};

next-intl API 유지 및 Intlayer 출력 획득

위의 벤치마크 결과를 얻기 위해 기존 컴포넌트를 모두 다시 작성할 필요는 없습니다. @intlayer/next-intl은 드롭인 어댑터입니다. useTranslations, getTranslations, useFormatter, t.rich(), ICU 복수형을 그대로 유지하면서 Intlayer 컴파일러로 컴파일된 Intlayer 사전에서 콘텐츠를 제공합니다.

import type { NextConfig } from "next";
import { createNextIntlPlugin } from "@intlayer/next-intl/plugin";

const withIntlayer = createNextIntlPlugin();

const nextConfig: NextConfig = {};

export default withIntlayer(nextConfig);

벤치마크에서 동일한 앱의 호환 빌드는 애플리케이션 코드를 전혀 수정하지 않고도 페이지당 153.6 KB에서 147.5 KB로, 컴포넌트당 21.8 KB에서 8.1 KB로 줄었으며, 페이지 누출은 약 90%에서 0%로 개선되었습니다. 기존 messages/{locale}.json 파일은 JSON 동기화 플러그인을 통해 계속 단일 소스로 유지할 수 있습니다.

자세한 단계는 next-intl 마이그레이션 가이드를 참조하세요.

언제 무엇을 선택해야 할까요?

자주 묻는 질문 (FAQ)

관련 비교

동일한 벤치마크, 다른 라이브러리:

next-intl 심층 분석:

참고 문서:

이러한 라이브러리가 어디에서 왔는지 이해하려면 JavaScript i18n의 역사를 읽어보세요.

GitHub STARS

GitHub 스타 수는 프로젝트의 인기, 커뮤니티의 신뢰 및 장기적인 지속 가능성을 보여주는 강력한 지표입니다.

커밋 활동

스타는 인기를, 커밋은 프로젝트에 투입된 작업량을 보여줍니다. 작성 시점 기준으로 Intlayer의 커밋 수는 약 7,500개로, 여기서 비교한 대부분의 라이브러리보다 많고 next-intl이나 next-i18next의 약 5배입니다.

Intlayer는 모노레포이므로 이 수치에는 모든 프레임워크 패키지, CLI, 문서가 포함됩니다. 커밋 수는 품질이 아닌 활동의 지표로 읽어 주세요.

npm 다운로드

다운로드 수는 가장 좋은 솔루션이 아니라 가장 오래된 솔루션에 보상을 줍니다. 수년 전에 출시된 라이브러리는 당시 이를 선택한 모든 프로젝트, 모든 CI 실행, 이에 의존하는 모든 패키지에 의해 여전히 설치됩니다. 이 수치는 새로운 선택보다 관성을 측정합니다.

AI 어시스턴트는 이 효과를 더 키웁니다. next-intl, i18next, vue-i18n은 AI가 학습한 코드 곳곳에 있으므로, AI는 대안을 비교하지 않고 이들을 기본으로 추천합니다. 추천이 다운로드를 늘리고, 그 다운로드가 다음 추천을 부추깁니다. 다운로드 수가 아니라 벤치마크로 비교하세요.

결론

next-intl은 탄탄하고 잘 유지 관리되는 라이브러리이며, 벤치마크에서도 Next.js 환경에서 결코 나쁜 선택이 아님을 확인할 수 있습니다. 하지만 중앙 집중식 카탈로그 모델은 최적화의 모든 부담을 개발자에게 전가합니다. 단순한 설정에서는 다른 페이지 콘텐츠가 약 90% 누출되며, 런타임 자체만으로도 모든 페이지에서 +12.6 KB gzip의 비용이 발생합니다.

Intlayer는 이 모든 작업을 컴파일러로 이전합니다. 컴포넌트별 사전, 로케일별 지연 로딩, 미사용 콘텐츠 정리는 규칙이 아닌 자동 빌드 결과물입니다. 동일한 앱에서 얻은 결과는 페이지당 +0.3 KB, 누출 0%, 3배 더 작은 컴포넌트, TanStack Start에서 2~4배 더 빠른 로케일 전환이었습니다.

모든 원시 데이터, 테스트 앱 및 스크립트는 Benchmark Bloom 저장소에 공개되어 있습니다. 직접 실행해 보세요.

자세한 내용은 'Why Intlayer?' 문서를 참조하세요.