🌍 Next.js 심화 13장: Advanced I18n — 전 세계 유저를 사로잡는 로컬라이제이션 전략

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 🗺️ App Router의 I18n 기본 철학 🟢
• 🏗️ 동적 사전(Dict) 로드 시스템 설계 🟡
• 🛡️ 타입 안정성 확보하기 (i18next vs Next native) 🟡
• 🚀 미들웨어와 언어 감지(Detection) 최적화 🔴
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 18분 (전체) / 핵심 파트만: 8분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영숙(디자이너): "영수 님, 우리 커뮤니티에 일본이랑 미국 유저들이 엄청 유입되고 있어요! 영어랑 일본어 버전도 만들어주세요."
• 영수(PM): "좋아요! 영철 님, 지금 바로 다국어 기능 추가해줄 수 있죠?"
• 영철(주니어): "네! localStorage에 language 저장해서 바꾸면 되겠죠?"
• 영호(리드): "영철 님, 안 돼요! 그러면 SEO가 훼손돼요. 구글 검색 로봇은 한국어 문서밖에 못 보게 될 거예요. App Router의 경로 기반 I18n으로 가야 합니다."

🎯 이 문서를 다 읽으면 할 수 있는 것

• /ko, /en 처럼 URL 경로를 통해 검색 엔진 최적화(SEO)가 보장되는 다국어를 구현할 수 있다
• 서버 컴포넌트에서 필요한 사전을 동적으로 로드하여 초기 전송량을 최소화할 수 있다
• 미들웨어를 이용해 유저의 브라우저 설정에 맞는 언어로 자동 연결(Redirect) 서비스를 구축할 수 있다

🤔 왜 알아야 하는가

다국어는 단순히 글자를 바꾸는 게 아니야. 비즈니스의 확장성 그 자체지.
Next.js App Router에서는 다국어 처리가 라우팅 시스템의 핵심으로 들어왔어.

핵심 포인트:

1. SEO: 각 언어별로 고유한 URL이 있어야 검색 엔진이 모든 버전의 페이지를 인덱싱할 수 있어.
2. Server-side First: 클라이언트가 번역 파일을 받기 전에, 서버에서 이미 번역된 HTML을 내려줘야 해.
3. PPR & Layouts: 레이아웃 구조를 유지하면서 언어만 갈아 끼우는 우아한 설계가 필요해.

🏗️ 비유로 먼저 이해하기

📖 도서관 안내책자로 설명한다면?
도서관 입구에 안내책자가 쌓여있어.

1. Client-side I18n: 책자는 모두 한국어인데, 서양인이 오면 마술을 부려서 눈앞에서 글자를 영어로 바꾸는 거야. 마술사가 없으면(JS 로드 전) 무조건 한국어만 보여.
2. App Router I18n: 입구에 '한국어 입구', '영어 입구'가 따로 있는 거야. 영어 입구로 들어가면 아예 처음부터 끝까지 영어로 된 책자들만 비치되어 있지. 손님이 마술을 부릴 필요가 없어.

🗺️ App Router의 I18n 기본 철학 🟢

Next.js는 내장된 I18n 시스템을 강제하지 않아. 대신 폴더 구조를 통해 유연하게 구현하라고 권장하지.

구조 예시:

app/
  [lang]/
    layout.tsx
    page.tsx
    about/page.tsx

이렇게 하면 유저가 /en/about으로 들어왔을 때 lang 파라미터가 "en"으로 전달돼.

🏗️ 동적 사전(Dict) 로드 시스템 설계 🟡

모든 실무용 가이드는 서버 사이드 로드를 지향해야 해.

// lib/get-dictionary.ts
import 'server-only'
 
// ✅ 1. 각 언어별 사전 파일을 정의해 (실제로는 public/locales 밑에 두는 게 좋음)
const dictionaries = {
  en: () => import('@/dictionaries/en.json').then((module) => module.default),
  ko: () => import('@/dictionaries/ko.json').then((module) => module.default),
}
 
export const getDictionary = async (lang: 'en' | 'ko') =>
  dictionaries[lang]?.() ?? dictionaries.en() // 해당 언어 없으면 영어가 기본

서버 컴포넌트에서 사용하기

// app/[lang]/page.tsx
import { getDictionary } from '@/lib/get-dictionary'
 
export default async function Page({ params }: { params: { lang: 'en' | 'ko' } }) {
  const { lang } = await params
  const dict = await getDictionary(lang) // ✅ 서버에서 필요한 언어만 쏙 가져옴
 
  return (
    <main>
      <h1>{dict.home.title}</h1>
      <p>{dict.home.description}</p>
    </main>
  )
}

🚀 미들웨어와 언어 감지(Detection) 최적화 🔴

유저가 그냥 youngsu.com으로 들어왔을 때, 브라우저 언어 설정을 읽어서 /ko나 /en으로 보내줘야 해.

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import { match } from '@formatjs/intl-localematcher'
import Negotiator from 'negotiator'
 
const locales = ['ko', 'en']
const defaultLocale = 'ko'
 
function getLocale(request: NextRequest) {
  const headers = { 'accept-language': request.headers.get('accept-language') ?? '' }
  const languages = new Negotiator({ headers }).languages()
  return match(languages, locales, defaultLocale)
}
 
export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl
 
  // ✅ 이미 언어 경로가 붙어있는지 확인
  const pathnameHasLocale = locales.some(
    (locale) => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
  )
 
  if (pathnameHasLocale) return
 
  // ✅ 언어가 없다면 감지해서 리다이렉트
  const locale = getLocale(request)
  request.nextUrl.pathname = `/${locale}${pathname}`
  return NextResponse.redirect(request.nextUrl)
}
 
export const config = {
  matcher: [
    // ⚠️ 정적 자산(images, favicon 등)은 제외하고 라우트만 감지!
    '/((?!api|_next/static|_next/image|favicon.ico).*)',
  ],
}

🏁 이번에 배운 내용 총정리

📋 I18n 설계 핵심 원칙

⚠️ 절대 하지 말 것

📝 마무리 퀴즈

Q1. App Router i18n에서 /ko, /en 같은 경로 기반 locale을 쓰는 가장 큰 이유는 무엇인가?

✅ 정답: 언어별 페이지가 고유 URL을 가져 SEO, 공유, 캐싱, 라우팅 판단이 명확해지기 때문이다.

💡 상세 해설: localStorage에 언어만 저장하면 검색 엔진과 공유 링크는 어떤 언어 문서인지 알기 어렵다. URL에 locale이 있으면 서버 컴포넌트가 처음부터 올바른 사전을 고르고, hreflang 같은 메타데이터도 명확하게 만들 수 있다.

Q2. 번역 사전을 server-only로 관리하는 이유는 무엇인가?

✅ 정답: 큰 JSON 사전과 서버 전용 로직이 클라이언트 번들에 섞이는 실수를 막기 위해서다.

💡 상세 해설: 서버 컴포넌트에서 필요한 번역 결과만 HTML로 내려보내면 브라우저가 모든 언어 사전을 받을 필요가 없다. server-only는 실수로 클라이언트 컴포넌트에서 import할 때 빌드 단계에서 막아 주는 울타리 역할을 한다.

Q3. 영철이의 테스트 타임: 영숙이 "한국어는 날짜가 2026년 4월 30일, 영어는 Apr 30, 2026처럼 보여야 한다"고 요청했다. 단순 번역 키만으로 충분할까?

✅ 정답: 부족하다. locale별 Intl 포맷, 타임존, 숫자/통화 표기까지 로컬라이제이션 규칙으로 분리해야 한다.

💡 상세 해설: i18n은 텍스트 치환이고, localization은 사용자가 자기 문화권의 규칙으로 이해하게 만드는 일이다. 날짜, 통화, 복수형, 정렬, RTL 여부는 문자열 사전만으로 해결되지 않는다. URL locale을 기준으로 포맷터와 메타데이터까지 함께 선택해야 한다.

🐣 영철이의 퇴근 일기

오늘은 다국어를 "문자열 파일을 여러 개 두는 일"로만 생각했던 게 부끄러웠다. URL, 서버 사전 로딩, SEO, 날짜와 통화 포맷까지 이어져야 사용자는 진짜 자기 언어의 서비스라고 느낀다.

💡 "글자를 바꾸는 건 번역이고, 사용자의 맥락에 맞추는 건 로컬라이제이션이다."

다음 i18n 작업에서는 먼저 locale이 라우팅의 일부인지 확인하겠다. 그리고 번역 키를 추가하는 PR에서도 메타데이터, 날짜/숫자 포맷, 누락 키 fallback이 함께 검증되는지 체크하겠다.

🔗 더 알아보기

• Next.js 공식 문서 — Internationalization
• FormatJS (intl-localematcher)
• next-intl (추천 라이브러리)