next-i18next VS next-intl VS intlayer | Next.js 국제화 (i18n)

Next.js를 위한 세 가지 i18n 옵션인 next-i18next, next-intl, Intlayer의 유사점과 차이점을 살펴보겠습니다.

이 문서는 완전한 튜토리얼이 아니라 선택에 도움을 주기 위한 비교입니다.

우리는 Next.js 13+ App Router (및 React Server Components)에 중점을 두고 다음 항목들을 평가합니다:

1. 아키텍처 및 콘텐츠 구성
2. TypeScript 및 안정성
3. 누락된 번역 처리
4. 라우팅 및 미들웨어
5. 성능 및 로딩 동작
6. 개발자 경험(DX), 도구 및 유지보수
7. SEO 및 대규모 프로젝트 확장성

요약: 세 가지 모두 Next.js 앱을 현지화할 수 있습니다. 만약 컴포넌트 범위 콘텐츠, 엄격한 TypeScript 타입, 빌드 시 누락 키 검사, 트리 쉐이킹된 사전, 그리고 최고급 App Router + SEO 도우미를 원한다면, Intlayer가 가장 완전하고 현대적인 선택입니다.

개발자들이 자주 혼동하는 점 중 하나는 next-intl이 react-intl의 Next.js 버전이라고 생각하는 것입니다. 그렇지 않습니다—next-intl은 Amann이 유지 관리하며, react-intl은 FormatJS가 유지 관리합니다.

요약

• next-intl - 가볍고 직관적인 메시지 포맷팅을 제공하며, 견고한 Next.js 지원을 갖추고 있습니다. 중앙 집중식 카탈로그가 일반적이며, 개발자 경험(DX)은 간단하지만 안전성과 대규모 유지 관리는 주로 사용자 책임입니다.
• next-i18next - Next.js 환경에 맞춘 i18next입니다. 성숙한 생태계와 플러그인(예: ICU)을 통한 기능을 제공하지만, 설정이 장황할 수 있으며 프로젝트가 커질수록 카탈로그가 중앙 집중화되는 경향이 있습니다.
• Intlayer - Next.js를 위한 컴포넌트 중심 콘텐츠 모델, 엄격한 TS 타이핑, 빌드 시 검사, 트리 쉐이킹, 내장 미들웨어 및 SEO 도우미, 선택적 비주얼 에디터/CMS, 그리고 AI 지원 번역을 제공합니다.

Move

Library	GitHub Stars	Total Commits	Last Commit	First Version	NPM Version	NPM Downloads
aymericzip/intlayer				April 2024
amannn/next-intl				Nov 2020
i18next/i18next				Jan 2012
i18next/next-i18next				Nov 2018

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

나란히 기능 비교 (Next.js 중심)

소개

Next.js는 국제화된 라우팅(예: 로케일 세그먼트)을 기본적으로 지원합니다. 하지만 이 기능만으로는 번역을 수행하지 않습니다. 사용자에게 현지화된 콘텐츠를 렌더링하려면 여전히 라이브러리가 필요합니다.

많은 i18n 라이브러리가 존재하지만, 현재 Next.js 환경에서는 next-i18next, next-intl, 그리고 Intlayer 세 가지가 주목받고 있습니다.

아키텍처 및 확장성

• next-intl / next-i18next: 기본적으로 로케일별 중앙 집중식 카탈로그(그리고 i18next의 네임스페이스)를 사용합니다. 초기에는 잘 작동하지만, 점차 결합도가 높아지고 키 변경이 잦아지면서 큰 공유 영역이 되는 경우가 많습니다.
• Intlayer: 코드와 공간적으로 함께 위치한 컴포넌트별(또는 기능별) 사전을 권장합니다. 이는 인지 부하를 줄이고, UI 조각의 복제/이전을 쉽게 하며, 팀 간 충돌을 줄여줍니다. 사용하지 않는 콘텐츠는 자연스럽게 더 쉽게 발견하고 제거할 수 있습니다.

중요한 이유: 대규모 코드베이스나 디자인 시스템 설정에서는 모듈화된 콘텐츠가 단일 카탈로그보다 더 잘 확장됩니다.

번들 크기 및 의존성

애플리케이션을 빌드한 후, 번들은 브라우저가 페이지를 렌더링하기 위해 로드하는 자바스크립트입니다. 따라서 번들 크기는 애플리케이션 성능에 매우 중요합니다.

다국어 애플리케이션 번들 맥락에서 중요한 두 가지 구성 요소는 다음과 같습니다:

• 애플리케이션 코드
• 브라우저가 로드하는 콘텐츠

애플리케이션 코드

이 경우 애플리케이션 코드의 중요성은 미미합니다. 세 가지 솔루션 모두 트리 쉐이킹(tree-shakable)이 가능하여, 사용하지 않는 코드 부분은 번들에 포함되지 않습니다.

다음은 세 가지 솔루션을 사용한 다국어 애플리케이션에서 브라우저가 로드하는 자바스크립트 번들 크기 비교입니다.

애플리케이션에서 포매터가 필요하지 않은 경우, 트리 쉐이킹 후 내보내지는 함수 목록은 다음과 같습니다:

• next-intlayer: useIntlayer, useLocale, NextIntlClientProvider, (번들 크기 180.6 kB -> 78.6 kB (gzip))
• next-intl: useTranslations, useLocale, NextIntlClientProvider, (번들 크기 101.3 kB -> 31.4 kB (gzip))
• next-i18next: useTranslation, useI18n, I18nextProvider, (번들 크기 80.7 kB -> 25.5 kB (gzip))

이 함수들은 React 컨텍스트/상태를 감싸는 래퍼에 불과하므로, i18n 라이브러리가 번들 크기에 미치는 전체 영향은 미미합니다.

Intlayer는 useIntlayer 함수에 더 많은 로직이 포함되어 있어 next-intl 및 next-i18next보다 약간 더 큽니다. 이는 마크다운과 intlayer-editor 통합과 관련이 있습니다.

콘텐츠 및 번역

이 부분은 개발자들이 종종 무시하지만, 10개의 페이지와 10개의 언어로 구성된 애플리케이션의 경우를 생각해 봅시다. 계산을 단순화하기 위해 각 페이지가 100% 고유한 콘텐츠를 통합한다고 가정해 보겠습니다(실제로는 페이지 간에 중복되는 콘텐츠가 많습니다. 예: 페이지 제목, 헤더, 푸터 등).

/fr/about 페이지를 방문하려는 사용자는 특정 언어로 된 한 페이지의 콘텐츠를 로드하게 됩니다. 콘텐츠 최적화를 무시하면 애플리케이션 콘텐츠의 8,200% ((1 + (((10 페이지 - 1) × (10 언어 - 1)))) × 100)를 불필요하게 로드하는 셈입니다. 문제를 이해하셨나요? 이 콘텐츠가 텍스트로만 남아 있더라도, 아마 사이트의 이미지 최적화를 더 신경 쓰고 싶겠지만, 전 세계에 불필요한 콘텐츠를 전송하고 사용자의 컴퓨터가 아무 쓸모 없이 이를 처리하게 만드는 것입니다.

두 가지 중요한 문제:

• 라우트별 분할:

  내가 /about 페이지에 있다면, /home 페이지의 콘텐츠를 로드하고 싶지 않습니다.

• 로케일별 분할:

  내가 /fr/about 페이지에 있다면, /en/about 페이지의 콘텐츠를 로드하고 싶지 않습니다.

다시 말하지만, 세 가지 솔루션 모두 이러한 문제를 인지하고 있으며 이러한 최적화를 관리할 수 있도록 합니다. 세 솔루션 간의 차이는 DX(개발자 경험)에 있습니다.

next-intl과 next-i18next는 중앙 집중식 접근 방식을 사용하여 번역을 관리하며, 로케일별 및 하위 파일별로 JSON을 분할할 수 있습니다. next-i18next에서는 JSON 파일을 '네임스페이스(namespaces)'라고 부르고, next-intl은 메시지를 선언할 수 있게 합니다. intlayer에서는 JSON 파일을 '사전(dictionaries)'이라고 부릅니다.

• next-intl의 경우, next-i18next와 마찬가지로, 콘텐츠가 페이지/레이아웃 수준에서 로드된 후 이 콘텐츠가 컨텍스트 프로바이더에 로드됩니다. 이는 개발자가 각 페이지에 로드될 JSON 파일을 수동으로 관리해야 함을 의미합니다.

실제로는 개발자들이 이 최적화를 종종 건너뛰고, 단순성을 위해 페이지의 컨텍스트 프로바이더에 모든 콘텐츠를 로드하는 방식을 선호합니다.

• intlayer의 경우, 모든 콘텐츠가 애플리케이션 내에서 로드됩니다. 그런 다음 플러그인(@intlayer/babel / @intlayer/swc)이 페이지에서 사용되는 콘텐츠만 로드하도록 번들을 최적화합니다. 따라서 개발자는 로드될 사전을 수동으로 관리할 필요가 없습니다. 이는 더 나은 최적화, 더 나은 유지보수성, 그리고 개발 시간 단축을 가능하게 합니다.

애플리케이션이 커질수록(특히 여러 개발자가 함께 작업할 때) 더 이상 사용되지 않는 콘텐츠를 JSON 파일에서 제거하는 것을 잊는 경우가 흔합니다.

모든 경우에 JSON이 모두 로드된다는 점에 유의하세요 (next-intl, next-i18next, intlayer).

이것이 Intlayer의 접근 방식이 더 성능이 좋은 이유입니다: 컴포넌트가 더 이상 사용되지 않으면 해당 사전은 번들에 로드되지 않습니다.

라이브러리가 폴백(fallback)을 처리하는 방식도 중요합니다. 애플리케이션이 기본적으로 영어로 설정되어 있고 사용자가 /fr/about 페이지를 방문한다고 가정해 봅시다. 프랑스어 번역이 없는 경우 영어 폴백을 고려합니다.

next-intl 및 next-i18next의 경우, 라이브러리는 현재 로케일과 폴백 로케일에 관련된 JSON을 모두 로드해야 합니다. 따라서 모든 콘텐츠가 번역되었다고 가정하면, 각 페이지는 100% 불필요한 콘텐츠를 로드하게 됩니다. 반면에, intlayer는 사전 빌드 시점에 폴백을 처리합니다. 따라서 각 페이지는 사용된 콘텐츠만 로드합니다.

다음은 vite + react 애플리케이션에서 intlayer를 사용한 번들 크기 최적화의 영향 예시입니다:

Move

최적화된 번들	최적화되지 않은 번들

TypeScript 및 안전성

중요한 이유: 강력한 타입 지정은 실패를 오른쪽(런타임)이 아닌 왼쪽(CI/빌드)으로 이동시킵니다.

누락된 번역 처리

next-intl

• 런타임 폴백에 의존합니다(예: 키 또는 기본 로케일 표시). 빌드는 실패하지 않습니다.

next-i18next

• 런타임 폴백에 의존합니다(예: 키 또는 기본 로케일 표시). 빌드는 실패하지 않습니다.

intlayer

• 누락된 로케일이나 키에 대해 빌드 타임 감지와 경고/오류를 제공합니다.

중요한 이유: 빌드 중에 누락을 잡으면 프로덕션에서 “미스터리 문자열”을 방지하고 엄격한 릴리스 게이트와 일치합니다.

라우팅, 미들웨어 및 URL 전략

중요한 이유: 커스텀 연결 계층이 줄어들고, 일관된 사용자 경험(UX)과 깔끔한 SEO를 지역별로 유지할 수 있습니다.

서버 컴포넌트(RSC) 정렬

중요한 이유: 더 깔끔한 정신 모델과 하이브리드 트리에서의 예외 상황 감소.

개발자 경험(DX), 도구 및 유지보수

중요한 이유: 운영 비용을 낮추고 개발자와 콘텐츠 작성자 간의 피드백 주기를 단축합니다.

현지화 플랫폼(TMS)과의 통합

대규모 조직은 종종 Crowdin, Phrase, Lokalise, Localizely, 또는 Localazy와 같은 번역 관리 시스템(TMS)에 의존합니다.

• 기업이 관심을 가지는 이유

  • 협업 및 역할 분담: 개발자, 제품 관리자, 번역가, 검토자, 마케팅 팀 등 여러 이해관계자가 참여합니다.
  • 규모 및 효율성: 지속적인 현지화와 맥락 내 리뷰가 가능합니다.

• next-intl / next-i18next

  • 일반적으로 중앙 집중식 JSON 카탈로그를 사용하므로 TMS와의 내보내기/가져오기가 간단합니다.
  • 위 플랫폼들에 대한 성숙한 생태계와 예제/통합 기능이 존재합니다.

• Intlayer

  • 분산형, 컴포넌트별 사전을 권장하며 TypeScript/TSX/JS/JSON/MD 콘텐츠를 지원합니다.
  • 이는 코드의 모듈성을 향상시키지만, 도구가 중앙 집중식 평면 JSON 파일을 기대할 경우 플러그 앤 플레이 방식의 TMS 통합을 어렵게 만들 수 있습니다.
  • Intlayer는 대안으로 AI 지원 번역(자체 제공자 키 사용), 비주얼 에디터/CMS, 그리고 CLI/CI 워크플로우를 제공하여 누락된 부분을 찾아 채울 수 있도록 합니다.

참고: next-intl과 i18next도 TypeScript 카탈로그를 지원합니다. 만약 팀에서 메시지를 .ts 파일에 저장하거나 기능별로 분산 관리한다면, 유사한 TMS 마찰을 겪을 수 있습니다. 하지만 많은 next-intl 설정은 여전히 locales/ 폴더에 중앙 집중화되어 있어 TMS용 JSON으로 리팩토링하기가 조금 더 쉽습니다.

개발자 경험

이 부분에서는 세 가지 솔루션을 깊이 비교합니다. 각 솔루션의 '시작하기' 문서에 설명된 간단한 사례를 고려하기보다는, 실제 프로젝트와 더 유사한 실제 사용 사례를 고려할 것입니다.

앱 구조

앱 구조는 코드베이스의 유지보수성을 보장하는 데 중요합니다.

.├── public│   └── locales│       ├── en│       │  ├── home.json│       │  └── navbar.json│       ├── fr│       │  ├── home.json│       │  └── navbar.json│       └── es│          ├── home.json│          └── navbar.json├── next-i18next.config.js└── src    ├── middleware.ts    ├── app    │   └── home.tsx    └── components        └── Navbar            └── index.tsx

.├── locales│   ├── en│   │  ├── home.json│   │  └── navbar.json│   ├── fr│   │  ├── home.json│   │  └── navbar.json│   └── es│      ├── home.json│      └── navbar.json├── i18n.ts└── src    ├── middleware.ts    ├── app    │   └── home.tsx    └── components        └── Navbar            └── index.tsx

.├── intlayer.config.ts└── src    ├── middleware.ts    ├── app    │   └── home    │       └── index.tsx    │       └── index.content.ts    └── components        └── Navbar            ├── index.tsx            └── index.content.ts

비교

• next-intl / next-i18next: 중앙 집중식 카탈로그(JSON; 네임스페이스/메시지). 명확한 구조, 번역 플랫폼과 잘 통합되지만, 앱이 커질수록 여러 파일을 동시에 수정해야 할 가능성이 높아집니다.
• Intlayer: 컴포넌트별 .content.{ts|js|json} 사전을 컴포넌트와 함께 배치. 컴포넌트 재사용과 로컬 단위 이해가 용이하며, 파일이 추가되고 빌드 타임 도구에 의존합니다.

설정 및 콘텐츠 로딩

앞서 언급했듯이, 각 JSON 파일이 코드에 어떻게 임포트되는지 최적화해야 합니다. 라이브러리가 콘텐츠 로딩을 처리하는 방식이 중요합니다.

module.exports = {  i18n: {    locales: ["en", "fr", "es"],    defaultLocale: "en",  },};

import { appWithTranslation } from "next-i18next";const MyApp = ({ Component, pageProps }) => <Component {...pageProps} />;export default appWithTranslation(MyApp);

import type { GetStaticProps } from "next";import { serverSideTranslations } from "next-i18next/serverSideTranslations";import { useTranslation } from "next-i18next";import { I18nextProvider, initReactI18next } from "react-i18next";import { createInstance } from "i18next";import { ClientComponent, ServerComponent } from "@components";export default function HomePage({ locale }: { locale: string }) {  // 이 컴포넌트에서 사용하는 네임스페이스를 명시적으로 선언합니다  const resources = await loadMessagesFor(locale); // 로더 (JSON 등)  const i18n = createInstance();  i18n.use(initReactI18next).init({    lng: locale,    fallbackLng: "en",    resources,    ns: ["common", "about"],    defaultNS: "common",    interpolation: { escapeValue: false },  });  const { t } = useTranslation("about");  return (    <I18nextProvider i18n={i18n}>      <main>        <h1>{t("title")}</h1>        <ClientComponent />        <ServerComponent />      </main>    </I18nextProvider>  );}export const getStaticProps: GetStaticProps = async ({ locale }) => {  // 이 페이지에 필요한 네임스페이스만 미리 로드합니다  return {    props: {      ...(await serverSideTranslations(locale ?? "en", ["common", "about"])),    },  };};

import { getRequestConfig } from "next-intl/server";import { notFound } from "next/navigation";// 공통 설정에서 가져올 수 있습니다const locales = ["en", "fr", "es"];export default getRequestConfig(async ({ locale }) => {  // 들어오는 `locale` 매개변수가 유효한지 검증합니다  if (!locales.includes(locale as any)) notFound();  return {    messages: (await import(`../messages/${locale}.json`)).default,  };});

import { NextIntlClientProvider } from "next-intl";import { getMessages, unstable_setRequestLocale } from "next-intl/server";import pick from "lodash/pick";export default async function LocaleLayout({  children,  params,}: {  children: React.ReactNode;  params: { locale: string };}) {  const { locale } = params;  // 이 서버 렌더링(RSC)을 위한 활성 요청 로케일 설정  unstable_setRequestLocale(locale);  // 메시지는 src/i18n/request.ts를 통해 서버 측에서 로드됩니다  // (next-intl 문서 참조). 여기서는 클라이언트 컴포넌트에 필요한  // 일부 메시지만 클라이언트로 전달합니다 (페이로드 최적화).  const messages = await getMessages();  const clientMessages = pick(messages, ["common", "about"]);  return (    <html lang={locale}>      <body>        <NextIntlClientProvider locale={locale} messages={clientMessages}>          {children}        </NextIntlClientProvider>      </body>    </html>  );}

import { getTranslations } from "next-intl/server";import { ClientComponent, ServerComponent } from "@components";export default async function LandingPage({  params,}: {  params: { locale: string };}) {  // 엄격하게 서버 측에서만 로드됨 (클라이언트에 하이드레이션되지 않음)  const t = await getTranslations("about");  return (    <main>      <h1>{t("title")}</h1>      <ClientComponent />      <ServerComponent />    </main>  );}

export default {  internationalization: {    locales: ["en", "fr", "es"],    defaultLocale: "en",  },};

import { getHTMLTextDir } from "intlayer";import {  IntlayerClientProvider,  generateStaticParams,  type NextLayoutIntlayer,} from "next-intlayer";export const dynamic = "force-static";const LandingLayout: NextLayoutIntlayer = async ({ children, params }) => {  const { locale } = await params;  return (    <html lang={locale} dir={getHTMLTextDir(locale)}>      <IntlayerClientProvider locale={locale}>        {children}      </IntlayerClientProvider>    </html>  );};export default LandingLayout;

import { PageContent } from "@components/PageContent";import type { NextPageIntlayer } from "next-intlayer";import { IntlayerServerProvider, useIntlayer } from "next-intlayer/server";import { ClientComponent, ServerComponent } from "@components";const LandingPage: NextPageIntlayer = async ({ params }) => {  const { locale } = await params;  const { title } = useIntlayer("about", locale);  return (    <IntlayerServerProvider locale={locale}>      <main>        <h1>{title}</h1>        <ClientComponent />        <ServerComponent />      </main>    </IntlayerServerProvider>  );};export default LandingPage;

비교

세 가지 모두 로케일별 콘텐츠 로딩과 프로바이더를 지원합니다.

• next-intl/next-i18next를 사용할 경우, 일반적으로 경로별로 선택된 메시지/네임스페이스를 로드하고 필요한 위치에 프로바이더를 배치합니다.

• Intlayer는 빌드 시점 분석을 추가하여 사용을 추론하므로 수동 연결을 줄이고 단일 루트 프로바이더를 허용할 수 있습니다.

팀의 선호도에 따라 명시적 제어와 자동화 중에서 선택하세요.

클라이언트 컴포넌트에서의 사용법

카운터를 렌더링하는 클라이언트 컴포넌트 예제를 살펴보겠습니다.

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

{  "counter": {    "label": "카운터",    "increment": "증가"  }}

"use client";import React, { useMemo, useState } from "react";import { useTranslation } from "next-i18next";const ClientComponentExample = () => {  const { t, i18n } = useTranslation("about");  const [count, setCount] = useState(0);  // next-i18next는 useNumber를 제공하지 않으므로 Intl.NumberFormat 사용  const numberFormat = new Intl.NumberFormat(i18n.language);  return (    <div>      <p>{numberFormat.format(count)}</p>      <button        aria-label={t("counter.label")}        onClick={() => setCount((count) => count + 1)}      >        {t("counter.increment")}      </button>    </div>  );};

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

{  "counter": {    "label": "Compteur",    "increment": "Incrémenter"  }}

"use client";import React, { useState } from "react";import { useTranslations, useFormatter } from "next-intl";const ClientComponentExample = () => {  // 중첩된 객체에 직접 범위 지정  const t = useTranslations("about.counter");  const format = useFormatter();  const [count, setCount] = useState(0);  return (    <div>      <p>{format.number(count)}</p>      <button        aria-label={t("label")}        onClick={() => setCount((count) => count + 1)}      >        {t("increment")}      </button>    </div>  );};

import { t, type Dictionary } from "intlayer";const counterContent = {  key: "counter",  content: {    label: t({ ko: "카운터", en: "Counter", fr: "Compteur" }),    increment: t({ ko: "증가", en: "Increment", fr: "Incrémenter" }),  },} satisfies Dictionary;export default counterContent;

"use client";import React, { useState } from "react";import { useNumber, useIntlayer } from "next-intlayer";const ClientComponentExample = () => {  const [count, setCount] = useState(0);  const { label, increment } = useIntlayer("counter"); // 문자열을 반환합니다  const { number } = useNumber();  return (    <div>      <p>{number(count)}</p>      <button aria-label={label} onClick={() => setCount((count) => count + 1)}>        {increment}      </button>    </div>  );};

비교

• 숫자 포맷팅

  • next-i18next: useNumber 없음; Intl.NumberFormat (또는 i18next-icu) 사용.
  • next-intl: useFormatter().number(value).
  • Intlayer: 내장된 useNumber() 사용.

• 키

  • 중첩 구조 유지 (about.counter.label) 및 훅 범위 지정 (useTranslation("about") + t("counter.label") 또는 useTranslations("about.counter") + t("label")).

• 파일 위치

  • next-i18next는 public/locales/{lng}/{ns}.json에 JSON을 기대.
  • next-intl는 유연하며, 설정에 따라 메시지 로드 가능.
  • Intlayer는 TS/JS 딕셔너리에 콘텐츠를 저장하고 키로 해석.

서버 컴포넌트에서의 사용

UI 컴포넌트의 경우를 살펴보겠습니다. 이 컴포넌트는 서버 컴포넌트이며, 클라이언트 컴포넌트의 자식으로 삽입될 수 있어야 합니다. (페이지 (서버 컴포넌트) -> 클라이언트 컴포넌트 -> 서버 컴포넌트). 이 컴포넌트가 클라이언트 컴포넌트의 자식으로 삽입될 수 있으므로 비동기(async)일 수 없습니다.

import type { GetStaticProps } from "next";import { useTranslation } from "next-i18next";type ServerComponentProps = {  count: number;};const ServerComponent = ({ count }: ServerComponentProps) => {  const { t, i18n } = useTranslation("about");  const formatted = new Intl.NumberFormat(i18n.language).format(count);  return (    <div>      <p>{formatted}</p>      <button aria-label={t("counter.label")}>{t("counter.increment")}</button>    </div>  );};

type ServerComponentProps = {  count: number;  t: (key: string) => string;};const ServerComponent = ({ t, count }: ServerComponentProps) => {  const formatted = new Intl.NumberFormat(i18n.language).format(count);  return (    <div>      <p>{formatted}</p>      <button aria-label={t("label")}>{t("increment")}</button>    </div>  );};

import { useIntlayer, useNumber } from "next-intlayer/server";const ServerComponent = ({ count }: { count: number }) => {  const { label, increment } = useIntlayer("counter");  const { number } = useNumber();  return (    <div>      <p>{number(count)}</p>      <button aria-label={label}>{increment}</button>    </div>  );};

Intlayer는 next-intlayer/server를 통해 서버 안전 훅을 제공합니다. 작동을 위해 useIntlayer와 useNumber는 클라이언트 훅과 유사한 훅 형태의 문법을 사용하지만, 내부적으로는 서버 컨텍스트(IntlayerServerProvider)에 의존합니다.

메타데이터 / 사이트맵 / 로봇

콘텐츠 번역은 훌륭합니다. 하지만 사람들은 보통 국제화의 주요 목표가 웹사이트를 전 세계에 더 잘 보이게 하는 것임을 잊어버립니다. I18n은 웹사이트 가시성을 향상시키는 놀라운 수단입니다.

다국어 SEO와 관련된 좋은 실천 목록은 다음과 같습니다.

• <head> 태그에 hreflang 메타 태그 설정 > 검색 엔진이 페이지에서 어떤 언어가 사용 가능한지 이해하는 데 도움을 줍니다
• http://www.w3.org/1999/xhtml XML 스키마를 사용하여 sitemap.xml에 모든 페이지 번역을 나열하세요. >
• robots.txt에서 접두사가 붙은 페이지를 제외하는 것을 잊지 마세요 (예: /dashboard, /fr/dashboard, /es/dashboard) >
• 가장 현지화된 페이지로 리디렉션하기 위해 커스텀 Link 컴포넌트를 사용하세요 (예: 프랑스어의 경우 <a href="/fr/about">A propos</a>) >

개발자들은 종종 여러 로케일에 걸쳐 페이지를 올바르게 참조하는 것을 잊어버립니다.

export const locales = ["en", "fr"] as const;export type Locale = (typeof locales)[number];export const defaultLocale: Locale = "en";export function localizedPath(locale: string, path: string) {  return locale === defaultLocale ? path : "/" + locale + path;}const ORIGIN = "https://example.com";export function abs(locale: string, path: string) {  return ORIGIN + localizedPath(locale, path);}

import type { Metadata } from "next";import { locales, defaultLocale, localizedPath } from "@/i18n.config";export async function generateMetadata({  params,}: {  params: { locale: string };}): Promise<Metadata> {  const { locale } = params;  // 올바른 JSON 파일을 동적으로 가져옵니다  const messages = (    await import("@/../public/locales/" + locale + "/about.json")  ).default;  const languages = Object.fromEntries(    locales.map((locale) => [locale, localizedPath(locale, "/about")])  );  return {    title: messages.title,    description: messages.description,    alternates: {      canonical: localizedPath(locale, "/about"),      languages: { ...languages, "x-default": "/about" },    },  };}export default async function AboutPage() {  return <h1>소개</h1>; // 페이지 제목을 한국어로 번역}

import type { MetadataRoute } from "next";import { locales, defaultLocale, abs } from "@/i18n.config";export default function sitemap(): MetadataRoute.Sitemap {  const languages = Object.fromEntries(    locales.map((locale) => [locale, abs(locale, "/about")])  );  return [    {      url: abs(defaultLocale, "/about"),      lastModified: new Date(), // 마지막 수정 날짜      changeFrequency: "monthly", // 변경 빈도: 매월      priority: 0.7, // 우선순위      alternates: { languages }, // 대체 언어 경로    },  ];}

import type { MetadataRoute } from "next";import { locales, defaultLocale, localizedPath } from "@/i18n.config";const ORIGIN = "https://example.com";const expandAllLocales = (path: string) => [  localizedPath(defaultLocale, path),  ...locales    .filter((locale) => locale !== defaultLocale)    .map((locale) => localizedPath(locale, path)),];export default function robots(): MetadataRoute.Robots {  const disallow = [    ...expandAllLocales("/dashboard"),    ...expandAllLocales("/admin"),  ];  return {    rules: { userAgent: "*", allow: ["/"], disallow },    host: ORIGIN,    sitemap: ORIGIN + "/sitemap.xml",  };}

import type { Metadata } from "next";import { locales, defaultLocale } from "@/i18n";import { getTranslations } from "next-intl/server";function localizedPath(locale: string, path: string) {  return locale === defaultLocale ? path : "/" + locale + path;}export async function generateMetadata({  params,}: {  params: { locale: string };}): Promise<Metadata> {  const { locale } = params;  const t = await getTranslations({ locale, namespace: "about" });  const url = "/about";  const languages = Object.fromEntries(    locales.map((locale) => [locale, localizedPath(locale, url)])  );  return {    title: t("title"),    description: t("description"),    alternates: {      canonical: localizedPath(locale, url),      languages: { ...languages, "x-default": url },    },  };}// ... 페이지 코드의 나머지 부분

import type { MetadataRoute } from "next";import { locales, defaultLocale } from "@/i18n";const origin = "https://example.com";const formatterLocalizedPath = (locale: string, path: string) =>  locale === defaultLocale ? origin + path : origin + "/" + locale + path;export default function sitemap(): MetadataRoute.Sitemap {  const aboutLanguages = Object.fromEntries(    locales.map((l) => [l, formatterLocalizedPath(l, "/about")])  );  return [    {      url: formatterLocalizedPath(defaultLocale, "/about"),      lastModified: new Date(),      changeFrequency: "monthly",      priority: 0.7,      alternates: { languages: aboutLanguages },    },  ];}

import type { MetadataRoute } from "next";import { locales, defaultLocale } from "@/i18n";const origin = "https://example.com";const withAllLocales = (path: string) => [  path,  ...locales    .filter((locale) => locale !== defaultLocale)    .map((locale) => "/" + locale + path),];export default function robots(): MetadataRoute.Robots {  const disallow = [    ...withAllLocales("/dashboard"),    ...withAllLocales("/admin"),  ];  return {    rules: { userAgent: "*", allow: ["/"], disallow },    host: origin,    sitemap: origin + "/sitemap.xml",  };}

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("page-metadata", locale);  const multilingualUrls = getMultilingualUrls("/about");  return {    ...metadata,    alternates: {      canonical: multilingualUrls[locale as keyof typeof multilingualUrls],      languages: { ...multilingualUrls, "x-default": "/about" },    },  };};// ... 페이지 나머지 코드

import { getMultilingualUrls } from "intlayer";import type { MetadataRoute } from "next";const sitemap = (): MetadataRoute.Sitemap => [  {    url: "https://example.com/about",    alternates: {      languages: { ...getMultilingualUrls("https://example.com/about") },    },  },];

import { getMultilingualUrls } from "intlayer";import type { MetadataRoute } from "next";const getAllMultilingualUrls = (urls: string[]) =>  urls.flatMap((url) => Object.values(getMultilingualUrls(url)) as string[]);const robots = (): MetadataRoute.Robots => ({  rules: {    userAgent: "*",    allow: ["/"],    disallow: getAllMultilingualUrls(["/dashboard"]),  },  host: "https://example.com",  sitemap: "https://example.com/sitemap.xml",});export default robots;

Intlayer는 사이트맵을 위해 다국어 URL을 생성하는 getMultilingualUrls 함수를 제공합니다.

그리고 승자는…

간단하지 않습니다. 각 옵션마다 장단점이 있습니다. 제가 보는 관점은 다음과 같습니다:

최소한의 설정을 선호하고 일부 수동 연결을 감수할 수 있다면 next-intl이 좋은 선택입니다. 모든 기능이 필요하고 복잡성을 감수할 수 있다면 next-i18next가 적합합니다. 하지만 현대적이고 확장 가능하며 모듈식 솔루션과 내장 도구를 원한다면 Intlayer가 바로 그 요구를 충족시키고자 합니다.

기업 팀을 위한 대안: Crowdin, Phrase와 같은 검증된 현지화 플랫폼이나 기타 전문 번역 관리 시스템과 완벽하게 작동하는 검증된 솔루션이 필요하다면, 성숙한 생태계와 검증된 통합 기능을 갖춘 next-intl 또는 next-i18next를 고려해 보세요.

향후 로드맵: Intlayer는 또한 i18next 및 next-intl 솔루션 위에서 작동하는 플러그인 개발을 계획하고 있습니다. 이를 통해 자동화, 구문, 콘텐츠 관리 측면에서 Intlayer의 장점을 제공하면서도, 애플리케이션 코드에서 이러한 검증된 솔루션들이 제공하는 보안성과 안정성을 유지할 수 있습니다.

GitHub STARs

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

결론

세 가지 라이브러리 모두 핵심 로컬라이제이션에서는 성공적입니다. 차이점은 현대적인 Next.js에서 견고하고 확장 가능한 설정을 달성하기 위해 얼마나 많은 작업을 해야 하는가에 있습니다:

• Intlayer를 사용하면, 모듈화된 콘텐츠, 엄격한 TS(타입스크립트), 빌드 타임 안전성, 트리 쉐이킹된 번들, 그리고 일류 App Router + SEO 도구가 기본값으로 제공되며, 번거로운 작업이 아닙니다.
• 다국어, 컴포넌트 기반 앱에서 유지보수성과 속도를 중요시하는 팀이라면, Intlayer가 오늘날 가장 완벽한 경험을 제공합니다.

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