“i18n이나 L10n 작업은 대충 텍스트만 번역하면 되지 않을까?”라고 생각했다가 실제로 해보니 예상보다 훨씬 복잡한 작업이었습니다. 저는 여러 회사에서 여러 프로젝트를 걸쳐 i18n과 L10n을 경험해봤는데, 이런 과정속에서 생각들과 경험을 공유해봅니다.

먼저 간단한 정의부터:

i18n (Internationalization): 소프트웨어가 다양한 언어와 지역을 지원할 수 있도록 설계하고 개발하는 과정입니다. i와 n 사이에 18글자가 있어서 i18n이라고 부릅니다.
L10n (Localization): 특정 지역이나 언어에 맞게 소프트웨어를 적용하는 과정입니다. l과 n 사이에 10글자가 있어서 L10n이라고 부릅니다. i18n과 구분을 위해서 L은 대문자로 작성합니다.

i18n은 큰 작업입니다

i18n은 생각보다 시간과 에너지가 많이 드는 큰 작업입니다. 개발자, 디자이너, PO 그리고 번역가(현지화 매니저)가 한 팀이 되어서 긴밀하게 일해야 합니다. 프로젝트 초반에 설계하면 좋지만, 프로젝트 중간에 들어간 경우에는 개발 비용이 많이 증가했었습니다. 이미 진행 중인 프로젝트에 i18n을 적용하겠다고 마음먹었다면 계획을 세우고 우선순위에 따라서 일을 진행하시는 것을 권하고 싶습니다.

언어와 범위 정하기

가장 먼저 정해야 할 것은 어떤 언어를 지원할지와 어디까지 현지화할지입니다. 우리가 현재 서비스하는 국가와 앞으로 서비스할 국가의 언어를 명확히 정해야 합니다. 제 경험상 PO나 비즈니스에서 결정이 되었던 거 같습니다.

다음으로 중요한 것은 현지화 범위를 정하는 것입니다. 단순히 텍스트만 번역해서 보여줄 것인지, 숫자 포맷과 날짜 포맷을 현지에 맞게 표현할 것인지, 그리고 더 나아가 색상, 이미지, 문화적 요소까지 고려할 것인지 정해야 합니다.

저는 보통 텍스트와 숫자, 날짜까지 했던 것 같습니다.

Source 언어와 Glossary 준비

Source 언어 선택

Source 언어는 번역의 기준이 되는 언어입니다. 보통 제품을 만드는 팀이 사용하는 언어(한국어)를 선택하지만, 주요 타겟 시장이 정해져 있다면 그 지역의 언어를 source로 사용하는 것도 고려해볼 만합니다.

Glossary 작성

Source 언어가 정해지면 glossary를 정리해야 합니다. 단순히 단어만 나열하는 게 아니라, 각 용어가 우리 제품에서 어떤 의미로 사용되는지 context를 추가해야 합니다. 이렇게 하면 번역자가 정확한 의미를 파악하고 더 적절한 번역을 할 수 있습니다.

RTL(Right-to-Left) 지원 결정

지원할 언어 목록을 살펴보고 RTL 언어가 포함되어 있는지 확인해야 합니다. 우리가 익숙한 한국어, 영어, 일본어 등은 LTR(Left-to-Right)이지만, 아랍어나 히브리어는 RTL(Right-to-Left) 언어입니다.

RTL 언어를 지원해야 한다면 처음부터 UI를 다르게 설계해야 하므로, 프로젝트 초기에 결정하는 게 좋습니다.

RTL CSS 구현

RTL 지원의 핵심은 HTML의 dir 속성과 CSS Logical Properties를 활용하는 것입니다. dir 속성은 텍스트의 방향뿐만 아니라 레이아웃의 시작점도 변경합니다. MDN 문서에 따르면 dir은 요소의 텍스트 방향성을 나타내는 열거형 속성으로, ltr, rtl, auto 값을 가질 수 있습니다:

<!-- HTML에서 전역 방향 설정 -->
<html dir="rtl" lang="ar">  <!-- 아랍어 -->
<html dir="rtl" lang="he">  <!-- 히브리어 -->
<html dir="ltr" lang="en">  <!-- 영어 (기본값) -->
<html dir="auto">           <!-- 자동 감지 -->

<!-- 특정 요소만 방향 변경 -->
<div dir="rtl">이 부분만 RTL로 표시됩니다</div>

dir="auto"는 브라우저가 자동으로 텍스트 방향을 결정하도록 합니다. 요소 내부의 문자를 파싱하여 강한 방향성을 가진 문자(아랍어, 히브리어 등)를 찾으면 해당 방향성을 전체 요소에 적용합니다. 혼합된 언어 콘텐츠를 다룰 때 유용합니다.

/* CSS에서 direction 속성 사용 */
.rtl-container {
  direction: rtl;  /* 텍스트와 레이아웃 방향을 오른쪽에서 왼쪽으로 */
  unicode-bidi: embed;  /* 텍스트 방향 격리 */
}

/* 기존 방식 (물리적 속성) - RTL에서 문제 발생 */
.card {
  margin-left: 20px;
  padding-right: 10px;
  text-align: left;
  float: left;
}

/* Logical Properties - RTL/LTR 자동 대응 */
.card {
  margin-inline-start: 20px;     /* LTR: left, RTL: right */
  padding-inline-end: 10px;      /* LTR: right, RTL: left */
  text-align: start;              /* LTR: left, RTL: right */
  float: inline-start;            /* LTR: left, RTL: right */
  border-inline-start: 2px solid #333;
}

Figma에서는 Auto Layout을 사용하면 RTL 대응이 쉬워집니다. RTLCSS 같은 도구도 고려해볼 수 있겠습니다만, 저는 처음부터 Logical Properties로 작성하는 것을 선호했습니다.

i18n Key 이름 짓기

이제 본격적으로 번역 문자열의 key-value 쌍들을 만들어야 합니다. 여기서 중요한 것은 key 이름입니다. 개발자는 코드에서 실제 텍스트 대신 key를 사용하기 때문에, key만 보아도 어떤 텍스트인지, 어디에 사용되는지 알 수 있어야 합니다.

피해야 하는 key 이름: menu0, menu1, menu2 등과 같이 key값으로 한정된 정보를 얻을 수 없는 이름들

제가 사용했던 key 법칙은 {category}.{action}.{ui}를 주로 사용했습니다. 이를테면 user.signup.button과 같이 이 텍스트가 어디서 사용되는지 알 수 있으면 좋습니다. 이것에 대한 건 딱히 정해져 있지 않으므로 다른 사례를 많이 찾아보고 우리 상황에 맞는 걸 적용하면 좋습니다.

{
  "user.signup.button": "Sign Up",
  "user.signup.title": "Create Your Account",
  "user.signup.description": "Join us today",
  "user.login.button": "Log In",
  "user.login.error": "Invalid credentials",
  "product.add.button": "Add to Cart",
  "product.add.success": "Product added successfully",
  "common.error.network": "Network error occurred",
  "common.button.cancel": "Cancel",
  "common.button.confirm": "Confirm"
}

텍스트 중심 콘텐츠 관리

다른 방법도 있습니다. UI의 label을 관리할 때는 위와 같은 key-value의 쌍으로 관리하는 것이 좋지만, 텍스트가 중심인 콘텐츠인 경우 MD 혹은 HTML로 관리하는 것도 방법입니다. 약관과 같이 페이지 전체가 정적이고 텍스트 위주의 콘텐츠를 번역한다고 할 때 유용합니다.

/content
  /ko
    /terms.md
    /privacy.md
    /about.md
  /en
    /terms.md
    /privacy.md
    /about.md
  /ja
    /terms.md
    /privacy.md
    /about.md

이 방식의 장점은 번역자가 전체 문맥을 파악하면서 작업할 수 있고, Markdown 에디터를 사용해서 쉽게 편집할 수 있다는 점입니다. 특히 긴 문서의 경우 key-value 방식보다 관리가 훨씬 편합니다.

i18n에 맞는 UI 설계하기

i18n을 고려한 UI 설계에서 가장 중요한 원칙은 유연성입니다. 언어마다 텍스트 길이가 크게 달라지기 때문에, 버튼이나 카드 등 UI 요소들이 고정 크기가 아닌 상대적 크기를 가져야 합니다.

우리말에서는 “확인”이 영어에서는 “Confirm”처럼 길어질 수 있으니까 디자이너는 특정 단어가 다른 언어로 변경될 때 최대 몇 자까지 허용될 수 있다고 가이드를 주는 것도 좋습니다.

일반적으로 영어에서 다른 언어로 번역할 때:

독일어: 30% 더 길어질 수 있음
프랑스어: 15-20% 더 길어질 수 있음
중국어/일본어: 50% 더 짧아질 수 있음

언어별 특성에 맞는 폰트를 적용하며, 모든 언어가 잘 보일 수 있도록 글로벌 폰트와 개별 언어 폰트 커스터마이즈를 고려합니다. 언어는 고유 문자와 문자폭, 자간·행간 등이 다르기 때문입니다.

숫자와 날짜 처리

숫자 포맷팅

숫자의 경우는 문화권마다 숫자의 콤마와 쉼표를 찍는 위치가 다릅니다:

const number = 123456.789;

// 미국 (콤마로 천단위, 점으로 소수점)
new Intl.NumberFormat('en-US').format(number); // 123,456.789

// 독일 (점으로 천단위, 콤마로 소수점)
new Intl.NumberFormat('de-DE').format(number); // 123.456,789

// 인도 (특별한 그룹핑 시스템)
new Intl.NumberFormat('en-IN').format(number); // 1,23,456.789

// 아랍어 (아랍 숫자 사용)
new Intl.NumberFormat('ar-EG').format(number); // ١٢٣٬٤٥٦٫٧٨٩

단수/복수 처리

또한 숫자에서 중요한 것은 단수와 복수 처리를 하는 것입니다. 수량을 나타낼 때 우리말에서는 “1개”, “2개”, “3개” 등 단수/복수 표현에서 조금 자유로운 반면, 영어에서는 “1 item”, “2 items”처럼 달라져야 합니다. 그래서 저는 ICU format을 지원하는 라이브러리를 사용했습니다.

// ICU Message Format 예시
const messages = {
  itemCount: `{count, plural,
    =0 {No items}
    one {# item}
    other {# items}
  }`
};

// 서수 처리
const ordinalMessages = {
  position: `{pos, selectordinal,
    one {#st}
    two {#nd}
    few {#rd}
    other {#th}
  }`
};

번역 Key 관리 도구 선택

번역 작업을 효율적으로 관리하려면 전문 도구를 사용하는 것이 좋습니다. 저는 spreadsheet부터 시작해서 여러 도구를 사용해봤는데, 결국 Crowdin, Lokalise, Phrase 같은 전문 서비스를 추천합니다.

이런 서비스들을 선택할 때는 사용성과 pricing, 그리고 역할별 seat가 어떻게 되는지 비교해보고 적절한 것을 선택하면 좋습니다. key 관리도 할 수 있고 번역하는 역할을 나눈다거나, 더 나아가서 Figma에서 플러그인을 제공하기 때문에 UI 디자인상에서 어떻게 보이는지 알 수 있었습니다.

Spreadsheet에서는 번역하는 사람 입장에서는 key만 보고 번역해야 하기 때문에 context의 공유가 제한적이라, Translation Management System(TMS)을 사용하는 것을 권장합니다. 이하에서는 TMS라고 하겠습니다. TMS를 사용하면 해당 text가 어디서 보여지는지 screenshot을 보면서 할 수 있어서 나중에 QA에서 시간을 좀 더 아낄 수 있습니다.

프론트엔드 라이브러리 선택

번역 관리 도구를 정했다면, 이제 실제 프론트엔드에서 사용할 i18n 라이브러리를 선택해야 합니다. 프레임워크별로 많은 라이브러리가 있지만, 저는 ICU 마크업 포맷을 지원하는 라이브러리를 강력하게 추천합니다.

ICU Format을 추천하는 이유

제가 여러 프로젝트에서 ICU(International Components for Unicode) 메시지 포맷을 채택했던 이유는 다음과 같습니다:

복잡한 문법 규칙 처리가 가능합니다: 단순한 텍스트 치환을 넘어서 각 언어의 복잡한 문법 규칙을 처리할 수 있었습니다. 특히 러시아어나 폴란드어처럼 복잡한 복수형 규칙을 가진 언어를 지원할 때 큰 도움이 되었습니다.
CLDR 데이터베이스를 활용합니다: Unicode의 Common Locale Data Repository를 활용하여 각 언어별 정확한 규칙이 이미 정의되어 있어, 새로운 언어를 추가할 때마다 규칙을 직접 구현할 필요가 없었습니다.
포괄적인 포맷팅을 제공합니다: 날짜, 시간, 숫자, 통화 등을 로케일에 맞게 자동으로 포맷팅해주어 개발 시간을 크게 단축시켰습니다.
조건부 메시지 처리가 우아합니다: 성별, 선택 로직 등 조건에 따라 다른 메시지를 보여줘야 할 때 코드가 깔끔하게 유지됐습니다.

사용자 언어 감지와 설정

이제 사용자가 어떤 언어를 선호하는지 알아내야 합니다. 언어 감지는 여러 방법이 있고, 각각의 우선순위를 정해야 합니다:

URL 파라미터
로컬 스토리지 저장값
브라우저 언어 설정
IP 기반 지역 감지
기본 언어

서버 사이드 vs 클라이언트 사이드

서버 사이드 감지:

// Accept-Language 헤더 파싱
app.use((req, res, next) => {
  const acceptLanguage = req.headers['accept-language'];
  const userLang = parseAcceptLanguage(acceptLanguage);
  req.locale = userLang || 'en';
  next();
});

클라이언트 사이드 감지:

// 브라우저 언어 감지
const browserLang = navigator.language || navigator.userLanguage;

// 언어 감지 우선순위 설정
function detectUserLanguage() {
  // 1. URL 파라미터 확인
  const urlParams = new URLSearchParams(window.location.search);
  const urlLang = urlParams.get('lang');
  if (urlLang) return urlLang;
  
  // 2. 로컬 스토리지 저장값
  const savedLang = localStorage.getItem('userLanguage');
  if (savedLang) return savedLang;
  
  // 3. 브라우저 언어
  const browserLang = navigator.language.split('-')[0];
  if (supportedLanguages.includes(browserLang)) return browserLang;
  
  // 4. 기본 언어
  return 'en';
}

저는 클라이언트에서 하는 것을 선호합니다. 그 이유는 사용자가 언어를 변경했을 때 페이지 새로고침 없이 즉시 반영할 수 있고, 서버 부하를 줄일 수 있으며, CDN 캐싱을 더 효과적으로 활용할 수 있기 때문입니다.

URL 구조와 SEO 전략

다국어 사이트를 구축할 때 URL 구조는 SEO와 사용자 경험에 직접적인 영향을 미치므로 신중하게 결정해야 합니다.

URL 구조 선택 기준

저는 서브디렉토리 방식(https://example.com/ko/products)을 권장합니다. 이 방식은 SEO에 가장 유리하며 Google이 공식적으로 권장하는 방식입니다. 언어별 콘텐츠 구조가 명확해서 hreflang 태그 적용이 쉽고, 사용자가 URL만 봐도 현재 어떤 언어로 된 페이지인지 직관적으로 알 수 있습니다. 또한 언어별 트래픽 분석이 용이하며, URL path의 parameter가 source of truth로 사용할 수 있어 사용자 언어를 설정하는 데 우선순위를 결정하기 쉽습니다.

https://example.com/ko/products
https://example.com/en/products  
https://example.com/ja/products

쿼리 파라미터 방식(https://example.com/products?lang=ko)이나 서브도메인 방식(https://ko.example.com/products)도 고려할 수 있는데 추천하지 않습니다. 쿼리 파라미터 방식은 검색엔진이 동일한 콘텐츠로 인식할 가능성이 있고, 언어별 페이지 인덱싱이 어려우며, 캐싱 복잡성이 증가합니다. 서브도메인 방식은 SSL 인증서 관리가 복잡해지고, CDN 설정이 까다로우며, 브랜딩 측면에서도 일관성이 부족해집니다.

SEO 최적화 구현

hreflang 태그 설정:

<!-- 한국어 페이지에서 -->
<link rel="alternate" hreflang="ko" href="https://example.com/ko/products" />
<link rel="alternate" hreflang="en" href="https://example.com/en/products" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/products" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products" />

언어별 Sitemap 생성:

<!-- sitemap-ko.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/ko/products</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/products"/>
    <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/products"/>
    <xhtml:link rel="alternate" hreflang="ko" href="https://example.com/ko/products"/>
  </url>
</urlset>

메타 태그 최적화:

<html lang="ko">
<head>
  <meta charset="UTF-8">
  <title>제품 목록 - 우리 회사</title>
  <meta name="description" content="한국어로 작성된 제품 설명">
  <link rel="canonical" href="https://example.com/ko/products">
</head>

실제 구현 시 고려사항

저는 대부분의 프로젝트에서 서브디렉토리 방식을 선택했는데, 그 이유는 Google이 공식적으로 권장하는 SEO 친화적인 방식이기 때문입니다. 사용자가 URL만 봐도 언어를 직관적으로 알 수 있어 사용자 경험이 좋고, 언어별 트래픽 분석이 간단하며, CDN에서 언어별 캐시 관리가 명확해서 캐싱 효율성도 높습니다.

구현할 때 주의해야 할 점들이 몇 가지 있습니다. 먼저 기본 언어의 경우 /ko/ 없이 루트 경로를 사용할지 결정해야 합니다. 예를 들어 한국어가 기본 언어라면 /products와 /ko/products 중 어떤 것을 사용할지 정해야 하는데, 저는 일관성을 위해 모든 언어에 언어 코드를 포함시키는 방식을 선호했습니다.

또한 사용자 언어 감지 후 리다이렉트할 때는 SEO에 영향을 주지 않도록 302 리다이렉트를 사용해야 하고, robots.txt에서 언어별 크롤링 정책을 명확하게 설정해주는 것도 중요합니다.

마무리

하나의 서비스를 여러 언어로 제공하는 것은 사실 쉽지 않은 일입니다. 이 외에도 화폐는 어떻게 보여줄 것인지 등 현지화에 대한 더 많은 디테일들이 있습니다.

요즘 AI를 통한 번역이 많이 이루어지고 있어 좋은 도구의 힘을 받으면 더 쉽게 할 수 있을 것 같습니다.

읽어보면 좋을 글

국제화 서비스 대충 번역만 해도 되지 않을까?

댓글