🚀 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을 구현할 때 URL에 언어 코드(/ko, /en)를 포함하는 가장 큰 이유는?

• A) 서버 캐시를 더 많이 쓰기 위해서
• B) 브라우저의 뒤로 가기 기능을 지원하기 위해
• C) 검색 엔진(Google)이 언어별 페이지를 각각 인식하게 하기 위해
• D) 마크다운 형식을 지키기 위해서

✅ 정답: C
해설: URL이 다르면 검색 엔진은 아예 다른 페이지로 봐. 그래야 영미권 유저가 구글링했을 때 우리 커뮤니티의 영어 버전이 결과에 뜨게 돼.

Q2. getDictionary 함수에서 import('server-only')를 사용하는 이유는?

• A) 빌드 속도를 빠르게 하려고
• B) 번역 사전(JSON) 파일이 클라이언트 자바스크립트 번들에 포함되지 않게 하기 위해
• C) JSON 파일을 XML로 변환하려고
• D) 이모지를 더 많이 쓰려고

✅ 정답: B
해설: 번역 사전은 용량이 클 수 있어. server-only를 쓰고 서버 컴포넌트에서만 로드하면, 번역 텍스트는 결과 HTML에만 포함되고 무거운 원본 JSON 파일은 브라우저로 전송되지 않아.

🐣 영철이의 퇴근 일기

오늘은 정말 우리 커뮤니티가 전 세계로 뻗어나갈 수 있게 해주는 'I18n & Localization' 을 배우면서 설레는 마음을 감출 수 없었어! 그동안 단순히 "텍스트만 바꾸면 되겠지" 라고 생각했는데, URL 설계부터 서버 사이드에서의 효율적인 번역 로드까지... 글로벌 서비스를 만드는 게 얼마나 세심한 작업인지 깨달았어.

💡 오늘의 교훈: "서비스의 확장성은 코드뿐만 아니라 언어와 문화에서도 시작된다. URL을 '진실의 근원' 으로 삼아 검색 엔진과 유저 모두에게 친절한 글로벌 커뮤니티를 설계하자!"

영호 리드 님이 검색 엔진 SEO 비유를 들어 설명해 주실 때, 왜 쿼리 스트링보다 경로 기반의 언어 구분이 중요한지 단번에 이해가 가더라. 단순히 번역을 제공하는 걸 넘어, 전 세계 모든 유저가 우리 서비스를 자기 집처럼 편안하게 머물 수 있도록 만드는 게 진짜 실력이라는 걸 깨달았어. 오늘 너무 글로벌한 사고를 했더니 머리가 핑 돌아가네. 퇴근길에 내가 좋아하는 영단어 퀴즈 앱이라도 좀 하면서 뇌를 식혀야겠어. 내일은 더 '세계를 품는' 아키텍처를 설계하는 개발자가 될 거야! 🐣

🔗 더 알아보기

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