프롤로그 — "번역은 이제 빌드 파이프라인이다"

2018년에 i18n이라 하면 한 명의 PM이 엑셀 시트에 한·영·일 열을 만들고, 개발자가 그걸 JSON으로 옮겨 commit하는 풍경이었다. 2022년이 되자 Lokalise·Phrase·Crowdin 같은 TMS(Translation Management System)가 키-값 동기화와 번역자 협업을 SaaS로 만들었고, DeepL은 MT 품질을 한 단계 끌어올렸다. 그리고 2024–2026년에 들어와 GPT-4o·Claude·Gemini가 "문서 톤·도메인 컨텍스트 인지" 번역을 만들면서 게임이 또 바뀌었다.

2026년 5월 현재, 우리가 "i18n / 현지화"라 부르는 영역은 **4개의 다른 진영**으로 정리된다.

1. **TMS (Translation Management System)** — Lokalise, Phrase, Crowdin, Tolgee, Weblate, Localazy, POEditor, Transifex, Smartling, Lingo(Locize)

2. **AI / MT 엔진** — DeepL, GPT-4o, Claude translate, Gemini translate, Reverso, 파파고, 카카오 i 번역, NICT VoiceTra, NTT

3. **개발자 라이브러리** — i18next, FormatJS / react-intl, ICU MessageFormat (스펙)

4. **Localization-as-code (LLM 기반)** — Lingo.dev, Locale.dev, OpenStrings

같은 "번역"이라는 라벨을 달고 있어도 Lokalise와 Lingo.dev와 i18next는 서로 다른 층위의 문제를 푼다. TMS는 사람·번역자·번역 메모리(TM)·용어집을 다루고, AI 엔진은 raw 번역 품질을 결정하며, 라이브러리는 런타임 렌더링과 복수/성별 처리를 담당한다. Lingo.dev 같은 새 진영은 "번역을 git diff처럼 PR로 다루자"는 발상이다.

이 글은 2026년 5월 기준 11개+α 도구의 위치, 강점·약점, 가격 모델을 정리한 뒤, 마지막에 **OSS 프로젝트 / 스타트업 / 글로벌 SaaS / 셀프호스팅 규제 산업** 4가지 시나리오별로 "무엇을 골라야 하나"를 답한다.

1장 · 2026년 i18n 지도 — TMS / OSS / 라이브러리 / AI 4 진영

전체 지도를 한 표로 정리하면.

| 진영 | 정체성 | 대표 도구 |

| --- | --- | --- |

| TMS (상용) | SaaS, 번역자 협업 + 키-값 동기화 | Lokalise, Phrase, Crowdin, Smartling, Transifex, Lingo(Locize), POEditor, Localazy |

| TMS (오픈소스) | 셀프호스팅 가능, 커뮤니티 번역 | Tolgee, Weblate |

| AI / MT | 번역 엔진 자체 | DeepL, GPT-4o, Claude, Gemini, Reverso, 파파고, 카카오 i |

| 개발자 라이브러리 | 런타임 i18n, 포맷 처리 | i18next, FormatJS, react-intl, FBT, Lingui, next-intl |

| 표준 | 메시지 포맷 스펙 | ICU MessageFormat, Unicode CLDR, XLIFF, gettext PO |

| Localization-as-code | LLM + git 워크플로 | Lingo.dev, Locale.dev, OpenStrings |

그리고 워크로드별로 보면.

| 시나리오 | 권장 후보 | 이유 |

| --- | --- | --- |

| OSS 프로젝트 (다국어 번역자 모집) | Crowdin, Weblate, Tolgee | 무료/할인 OSS 플랜, 커뮤니티 번역 도구 |

| B2B SaaS 스타트업 (제품 다국어화) | Lokalise, Phrase, Lingo.dev | TMS + GitHub 통합, AI 번역 워크플로 |

| 글로벌 엔터프라이즈 | Smartling, Phrase(RWS), Lokalise | 컴플라이언스, 에이전시 워크플로 |

| 셀프호스팅 (규제·기밀) | Weblate, Tolgee self-host | 데이터 외부 유출 X, GPL/AGPL |

| 마케팅 콘텐츠·블로그 | DeepL Pro + 사람 검수, Lingo.dev | 톤·뉘앙스 처리 |

| 게임·UGC 대량 번역 | GPT-4o / Claude API + glossary | 비용·맥락 인지 |

핵심 통찰 하나: **TMS와 AI 엔진과 라이브러리는 서로 대체재가 아니라 보완재다.** Lokalise를 쓴다고 i18next가 필요 없어지지 않고, DeepL이 잘한다고 TMS가 필요 없어지지 않는다. 우리 팀이 어디에 시간을 쓰고 있는지를 먼저 파악해야 한다.

2장 · Lokalise — TMS의 리더

Lokalise는 2017년 라트비아에서 시작해 2021년 시리즈 B(50M USD)를 받고 글로벌 TMS 1위 자리를 굳혔다. 2026년 현재 5,000+ 팀이 사용하며, "현대적 SaaS 디자인 + 개발자 친화 워크플로"의 표준으로 자리잡았다.

핵심 개념

- **Project** — 한 앱·서비스 단위. 키-값 쌍이 들어간다.

- **Key** — 식별자. `home.welcome.title` 같은 dot-notation이 일반적. 각 키마다 모든 언어의 번역이 매달린다.

- **Translation memory (TM)** — 과거 번역 DB. 새 키가 추가되면 유사도 매칭으로 자동 제안.

- **Glossary** — 용어집. 브랜드명·제품명·금기어 관리.

- **Branching** — 같은 프로젝트의 번역을 git 브랜치처럼 분기. 기능 단위 번역 작업.

개발자 워크플로

- **CLI** — `lokalise-cli` 로 키 push/pull. JSON·YAML·strings·ARB·xml 등 30+ 포맷.

- **GitHub App** — PR이 머지되면 자동 sync. 신규 키는 번역자에게 알림.

- **API + 웹훅** — 번역 완료 시 빌드 트리거.

- **Figma 플러그인** — 디자인 단계에서 카피 추출, 번역 동시 진행.

가격 (2026년 5월 기준)

| 플랜 | 가격 | 키/유저 |

| --- | --- | --- |

| Start | $120/월 | 10 user, 5,000 key |

| Essential | $230/월 | 10 user, 5,000 key + branching |

| Pro | $585/월 | 15 user, 30,000 key |

| Enterprise | 협의 | SSO, audit log, custom |

강점·약점

- 강점: UX가 가장 깔끔. 디자이너·번역자·개발자가 한 화면에서 작업. AI 자동 번역(DeepL·OpenAI·Google 백엔드 선택) 통합.

- 약점: 가격이 비싸다. OSS 프로젝트에는 부담. 셀프호스팅 불가.

언제 고르나

B2B SaaS, 시리즈 A 이상 스타트업, 다언어 모바일 앱. "번역자와 디자이너가 같이 일하는 모던 워크플로"가 필요한 팀.

3장 · Phrase + Memsource (RWS) — 통합 후의 모습

Phrase는 2014년 독일 스타트업으로 시작해 2017년 Memsource를 인수, 2021년에는 다시 영국 RWS Holdings에 합병됐다. 2026년 현재 두 제품 라인을 통합 운영한다.

- **Phrase Strings** — 구 Phrase. 키-값 기반의 개발자 친화 TMS. JSON·YAML·iOS strings·Android xml.

- **Phrase TMS** — 구 Memsource. XLIFF·TMX 기반의 번역자 친화 CAT(Computer-Aided Translation) 도구. Trados 대체용.

핵심 개념

- **Project + Branching** — Strings 쪽은 Lokalise와 거의 동일한 키-값 모델.

- **CAT editor** — TMS 쪽은 문장 단위 segment, TM 매칭, MT(machine translation) suggestion이 한 화면.

- **AI Translation** — Phrase NextMT(자체 엔진) + DeepL + GPT 백엔드 선택 가능. 도메인별 fine-tune 모델 제공(Enterprise).

- **Quality scoring** — MQM(Multidimensional Quality Metrics) 기반 자동 품질 점수.

개발자 워크플로

- **Phrase CLI** — 키 sync. GitHub Action·GitLab CI 공식 통합.

- **In-context editor** — 웹 앱에 SDK 끼우면 번역자가 실제 UI 위에서 카피 수정. (Tolgee 영향)

- **OTA (Over-The-Air)** — 모바일 앱 번역을 앱 재배포 없이 푸시.

가격

- Strings: $135/월 시작. 키·유저 늘면 빠르게 비싸짐.

- TMS: 협의. 엔터프라이즈 중심.

강점·약점

- 강점: TMS와 Strings 두 워크플로를 모두 커버. RWS 글로벌 번역자 네트워크 직접 연결. MQM 품질 측정 표준 지원.

- 약점: 두 제품의 UX가 통합 도중에 일관성이 떨어진다는 평. 가격이 Lokalise보다 약간 비싼 편.

언제 고르나

번역 에이전시와 협업하는 엔터프라이즈, 또는 모바일 앱 OTA 업데이트가 필요한 팀. RWS와의 기존 관계가 있다면 자연스러운 선택.

4장 · Crowdin — OSS 프로젝트 친화

Crowdin은 2009년 우크라이나에서 시작했다. 2026년 현재 OSS·게임 커뮤니티 번역의 사실상 표준. React Native, Docker, Discord, MineCraft, Telegram의 다국어가 모두 Crowdin 위에서 굴러간다.

핵심 개념

- **Crowdin for Open Source** — 공식 OSS 프로젝트 무료 플랜(승인 기반). 무제한 키·번역자.

- **Pre-translation** — Memsource MT + DeepL + ChatGPT 백엔드 선택.

- **Community translation** — 익명·로그인 모든 사용자가 번역 제안. 모더레이터가 승인.

- **Vendors marketplace** — 전문 번역 에이전시를 프로젝트 안에서 직접 호출.

개발자 워크플로

- **Crowdin CLI** — 키 sync.

- **GitHub integration** — main 브랜치 변경 감지 → Crowdin에 push → 번역 완료 시 PR 자동 생성.

- **String repository** — 같은 키를 여러 프로젝트에서 재사용.

- **Screenshot context** — 키별로 UI 스크린샷 첨부, 번역자 맥락 제공.

가격

| 플랜 | 가격 |

| --- | --- |

| Free (소규모) | $0, 1 프로젝트, 60,000 자 |

| Pro | $50/월 |

| Team | $250/월 |

| Business | $450/월 |

| Enterprise | 협의 |

| OSS | 무료 (승인 필요) |

강점·약점

- 강점: OSS 플랜이 압도적으로 관대. 커뮤니티 번역 도구가 가장 성숙. 게이미피케이션(번역자 ranking, badge)이 있어서 자발적 기여가 잘 모인다.

- 약점: UI가 Lokalise·Phrase보다 조금 구식. 엔터프라이즈 RBAC·SSO·감사 로그는 추가 비용.

언제 고르나

OSS 프로젝트, 게임 커뮤니티, 사용자가 직접 번역에 참여하는 제품. "번역자를 채용 안 하고 모집하고 싶다"는 케이스.

5장 · Tolgee — 오픈소스 in-context 에디터

Tolgee는 2020년 체코에서 시작한 비교적 신생 오픈소스 TMS. 2026년 현재 GitHub 4.5k+ star, MIT 라이선스. 셀프호스팅·SaaS 둘 다 제공.

핵심 차별점 — In-context 에디터

Tolgee의 시그니처는 **개발 서버에서 Alt + 클릭으로 카피를 바로 편집**할 수 있다는 점이다. React·Vue·Angular SDK가 DOM에 hidden marker를 심고, Tolgee 브라우저 확장이 그걸 잡는다. 디자이너·PM이 직접 UI 위에서 번역을 고친다.

// React 예시

const tolgee = Tolgee()

.use(DevTools())

.use(FormatIcu())

.init({

apiUrl: 'https://app.tolgee.io',

apiKey: process.env.NEXT_PUBLIC_TOLGEE_API_KEY,

language: 'ko',

})

export default function App() {

return (

)

}

핵심 개념

- **Screenshot auto-capture** — 키가 화면에 나타날 때마다 자동 스크린샷.

- **Translation memory** — 자체 TM + DeepL·OpenAI 자동 번역 통합.

- **Activity** — 키별 변경 이력. 누가 언제 무엇을 바꿨는지.

- **CLI + Push/Pull** — JSON·YAML·xliff·apple strings 등.

가격

| 플랜 | 가격 | 키 |

| --- | --- | --- |

| Free | $0 | 1,000 string, 3 user |

| Cloud Standard | $69/월 | 10,000 string |

| Cloud Enterprise | 협의 | 무제한 |

| Self-hosted Free | $0 | 무제한 (소규모 팀) |

| Self-hosted Business | 협의 | SSO, 감사로그 |

강점·약점

- 강점: in-context 에디터가 가장 매끄럽다. OSS여서 셀프호스팅 가능. 가격이 Lokalise·Phrase보다 훨씬 저렴.

- 약점: 생태계가 아직 작다. 번역자 마켓플레이스·에이전시 통합은 약함.

언제 고르나

"PM·디자이너가 직접 카피 수정"이 필요한 작은 팀, 데이터를 외부에 안 보내고 싶은 스타트업, Phrase·Lokalise 가격이 부담스러운 시리즈 시드 팀.

6장 · Weblate (체코 오픈소스) / Localazy / POEditor

Lokalise·Phrase·Crowdin이 SaaS의 상위 3강이라면, 이 카테고리는 "OSS 커뮤니티·중간 규모 팀"이 자주 고르는 다음 3가지.

Weblate — GPL 풀스택 셀프호스팅

- 2012년 체코 Michal Čihař가 시작. GPL 라이선스, GitHub 4.7k+ star.

- gettext PO 중심. Linux 데스크탑 프로젝트(GNOME, KDE) 번역의 표준.

- 셀프호스팅이 정말 쉽다. Docker compose 한 방. Postgres + Redis만 있으면 됨.

- Hosted Weblate(SaaS)도 있고, OSS 프로젝트는 무료 호스팅 신청 가능.

- AI 자동 번역: DeepL·Google·Microsoft·OpenAI 백엔드 선택.

- 약점: UI가 다소 옛날 스타일. 모바일 앱 워크플로(iOS strings·Android xml)는 Lokalise 대비 약함.

Localazy — 체코 또 하나의 강자

- 2019년 체코 출범. "자동화 + 커뮤니티 번역 마켓플레이스" 컨셉.

- ShareTM — 커뮤니티 번역 메모리. 다른 프로젝트의 번역을 무료로 재사용.

- 모바일 앱 친화. iOS·Android·React Native·Flutter SDK 잘 갖춤.

- 가격: Free 1,000 source, Startup $39/월, Pro $129/월.

- 강점: 가격 대비 기능이 좋다. 자동화·CLI가 매끈.

POEditor

- 2012년 루마니아 출범. 가장 클래식한 키-값 TMS.

- 가격이 가장 낮은 편(Free 1,000 string, Start $14.99/월).

- UI는 미니멀. 작은 팀에 충분.

- GitHub·GitLab·Bitbucket·Azure DevOps 모두 직접 통합.

비교 요약

| 도구 | OSS? | 셀프호스팅 | 강점 | 약점 |

| --- | --- | --- | --- | --- |

| Weblate | GPL | O | Linux 데스크탑·OSS의 표준 | UI 다소 옛날 |

| Localazy | X | X | 모바일 친화, ShareTM | 셀프호스팅 불가 |

| POEditor | X | X | 가장 저렴, 간단함 | 고급 기능 약함 |

7장 · Lingo (Locize) / Transifex / Smartling — 그 외

Lingo / Locize — 플랫 피, i18next의 형제

- Lingo는 Locize로 리브랜딩됐다. i18next 메인테이너 Jan Mühlemann이 만든 TMS.

- 핵심: **플랫 피 가격**. 키 100,000개에 €25/월 같은 식으로 사용량과 무관한 가격.

- i18next와 perfect integration. `i18next-locize-backend` 한 줄로 끝.

- AI 자동 번역 통합(DeepL·Google).

- 약점: UI 디자인이 비교적 단순. 디자이너 친화 워크플로는 Lokalise·Phrase에 밀린다.

- 언제 고르나: i18next 쓰는 React/Node 팀, 가격 예측 가능성이 중요한 곳.

Transifex — 오래된 강자

- 2007년 그리스 출범. 가장 오래된 SaaS TMS 중 하나.

- WordPress, Mozilla, Eclipse의 번역 인프라.

- 2020년대 들어 Lokalise·Phrase에 밀렸지만 여전히 안정적.

- "Live" 기능: in-context 편집, Tolgee보다 먼저 시도.

- 가격: Starter $70/월, Growth $250/월.

- 강점: 안정성, 오래된 통합.

- 약점: 혁신 속도가 느리고 UI가 옛날 스타일.

Smartling — 엔터프라이즈 전용

- 2009년 미국 출범. Lyft·British Airways·Pinterest 같은 글로벌 엔터프라이즈가 고객.

- 자체 TMS + 자체 번역 에이전시 네트워크가 결합된 풀스택.

- LanguageAI — 자체 AI 번역 + 사람 검수 워크플로.

- 가격은 협의. 기본 6자리.

- 강점: 엔터프라이즈 컴플라이언스(SOC2, ISO 27001, GDPR), 에이전시 quality 보장.

- 약점: 작은 팀에는 과잉, 가격 진입장벽 높음.

8장 · AI 번역 — DeepL / GPT-4o / Claude / Gemini / Reverso

TMS가 인프라라면 AI는 엔진이다. 2026년 현재 번역 품질의 새 기준은 LLM 기반이다.

DeepL — 여전히 강한 전문 번역 엔진

- 독일 쾰른 소재. 2017년 출시 이래 EU 언어 쌍(독·불·이·스·포·네)에서 Google·Microsoft를 능가한다는 평을 유지.

- 2024년에 DeepL Write(글쓰기 보조), 2025년에 LLM 기반 차세대 엔진 출시.

- 강점: 격식체·구어체 옵션, 용어집(glossary) 정확도, 도메인 모델(법률·재무 등).

- 약점: 아시아 언어(한·중·일)에서는 GPT-4o·Claude에 약간 밀린다는 의견.

- 가격: API Pro $5.49/월부터 + 사용량.

GPT-4o (OpenAI) translation

- OpenAI의 4o 모델은 100+ 언어 번역에서 상위권.

- 강점: 맥락 인지(앞뒤 문장 보고 의미 결정), 코드 주석 번역, 마크다운/HTML 구조 보존.

- 약점: 가끔 hallucinate. 글로서리 준수가 LLM 자체로는 100%는 아님 → RAG·few-shot 필요.

- 가격: input $2.50/1M token, output $10/1M token.

Claude (Anthropic) translation

- Claude Sonnet/Opus는 긴 문서·장문 번역에서 강점. 1M token context로 책 한 권을 한 번에.

- 톤 유지(브랜드 voice) 능력이 높다는 평가.

- 안정성·환각률이 GPT 대비 낮다는 보고가 많음(2025년 여러 benchmark).

- 가격: Sonnet input $3/1M, output $15/1M.

Gemini (Google) translation

- Google의 본진. 100+ 언어, Vertex AI translate API와 LLM API 두 갈래.

- 강점: Google의 기존 번역 코퍼스 + LLM 결합. 다국어 OCR·문서 번역에서 강함.

- 가격: 1.5 Pro input $1.25/1M, output $5/1M.

Reverso

- 1998년 프랑스 출범. 번역 + 컨텍스트 검색(실제 문서 corpus에서 비슷한 예문 보여주기).

- 번역자들이 "단어 뉘앙스 체크"용으로 함께 쓴다.

- B2C 도구. API도 있지만 인프라급은 아님.

Anthropic translation API + Korean/Japanese majors

- Anthropic은 별도의 "translation API"를 제공하지 않고, Messages API에 system prompt + glossary로 처리.

- 한국 파파고·카카오 i 번역, 일본 NTT·DeepL 일본 데이터 센터는 13장·14장에서 따로 다룬다.

품질 비교 (한·영·일 2025 사내 벤치마크 인용)

| 엔진 | 한↔영 | 한↔일 | 톤·brand voice | 도메인 용어 정확도 |

| --- | --- | --- | --- | --- |

| DeepL | 상 | 상 | 중 | 상 (glossary 사용 시) |

| GPT-4o | 상 | 상 | 상 | 중 (few-shot 필요) |

| Claude Sonnet | 상 | 상 | 상상 | 중 |

| Gemini 1.5 Pro | 상 | 상 | 중 | 중 |

| 파파고 | 상상 (한↔영) | 상 | 중 | 중 |

| 구글 번역 | 중 | 중 | 하 | 하 |

9장 · Lingo.dev — LLM 기반 localization-as-code

Lingo.dev(구 Replicant.ai Translation)는 2024년에 등장한 새 진영. 발상이 다르다: **"번역은 git diff처럼 PR로 다뤄야 한다"**.

핵심 발상

- 개발자가 `en.json`을 수정하면, Lingo CLI가 LLM(OpenAI·Anthropic·Google 선택)으로 자동 번역해 `ko.json`·`ja.json`을 만들고 PR을 연다.

- 사람 번역자·TMS 없이도 OSS·소규모 팀이 다국어를 굴릴 수 있다.

- TMS의 키-값 동기화 대신 git diff가 진실.

예시

설치

npm i -g lingo.dev

초기화

lingo init

i18n.json

{

"source": "en",

"targets": ["ko", "ja", "zh-CN"],

"files": ["locales/*.json"],

"model": "anthropic/claude-sonnet-4",

"glossary": "glossary.json"

}

자동 번역 → PR 생성

lingo translate --open-pr

강점

- TMS 비용 절약. 시드~시리즈 A 스타트업에 합리적.

- LLM 모델 선택 자유. Claude·GPT·Gemini 백엔드 교체 가능.

- glossary로 브랜드 용어 통제.

- git diff로 번역 히스토리 자연스럽게 관리.

약점

- 사람 번역자 워크플로가 없다. "법적·규제 카피"는 여전히 TMS + 사람 검수가 안전.

- 마이너 언어(스와힐리·페르시아 등)에서 LLM 품질 들쭉날쭉.

- 대량 번역 시 LLM API 비용이 TMS 정가보다 비쌀 수 있음.

언제 고르나

OSS 프로젝트, 소규모 SaaS, 마케팅 사이트, 블로그. "한 명의 풀스택이 i18n 인프라까지 책임"인 팀.

경쟁자

- **Locale.dev** — 2025년 등장. Lingo.dev와 거의 유사. PR 기반.

- **OpenStrings** — OSS 라이브러리. 자체 LLM 번역 + cache 관리.

10장 · ICU MessageFormat — 복수/성별 처리

도구의 위층을 정리했으니 표준 스펙으로 내려간다. ICU(International Components for Unicode)는 IBM·Unicode가 만든 i18n 표준. **MessageFormat**은 복수·성별·날짜 같은 까다로운 포맷팅을 한 문자열 안에서 처리한다.

왜 필요한가

영어로 "1 item / 2 items"는 쉽지만, 러시아어는 단수·소수형·복수형 3개가 있고, 아랍어는 6개다. 일본어는 복수형이 없다(같은 단어). 한국어는 "1개·2개" 단위(조사)가 따로 붙는다. 이런 차이를 키 하나로 표현하는 문법.

{count, plural,

=0 {No items}

one {# item}

other {# items}

}

위 문법을 ICU MessageFormat이라 한다. JS·Java·Swift·Kotlin·Go 모두 ICU 호환 라이브러리가 있다.

한국어/일본어 특수성

한국어: {count, plural, other {#개 아이템}}

일본어: {count, plural, other {#件}}

한국어는 plural 규칙이 단순(전부 `other`)이지만 조사(은/는, 이/가, 을/를) 처리는 ICU로 안 됨. 그래서 한국어 i18n에서는 별도 조사 헬퍼를 쓰거나 문장 자체를 재구성한다.

Select (성별·맥락)

{gender, select,

male {그가 등록했습니다}

female {그녀가 등록했습니다}

other {그/그녀가 등록했습니다}

}

SelectOrdinal (서수)

{position, selectordinal,

one {#st}

two {#nd}

few {#rd}

other {#th}

}

MessageFormat 2.0 (MF2)

- 2024년 Unicode가 MessageFormat 2.0 1차 안정 릴리스 발표.

- 기존 MF의 까다로운 escape·중첩 문제 개선.

- 2026년 현재 i18next·FormatJS·LinguiJS 모두 MF2 지원 중.

11장 · i18next — JS i18n의 표준

JavaScript 생태계에서 가장 널리 쓰이는 i18n 라이브러리. 2011년 시작, 2026년 현재 npm 주간 다운로드 8M+. React·Vue·Svelte·Node·Express·Electron 등 모든 환경에서 동작.

핵심 개념

- **i18next core** — 환경 무관 코어. 키 lookup, 보간(interpolation), 복수, 네임스페이스.

- **react-i18next, vue-i18next** — 프레임워크 바인딩.

- **Backends** — locize, http, fs, chained 등 다양.

- **Plugins** — language detector, ICU formatter, postProcessor 등.

예시 (React)

i18n.use(initReactI18next).init({

resources: {

en: { translation: { welcome: 'Hello, {{name}}' } },

ko: { translation: { welcome: '안녕하세요, {{name}}' } },

},

lng: 'ko',

fallbackLng: 'en',

})

function Greeting({ user }) {

const { t } = useTranslation()

return <h1>{t('welcome', { name: user.name })}</h1>

}

위 예시의 `{{name}}` 같은 placeholder는 MDX 본문에서 다룰 때 항상 인라인 코드로 감싸야 한다(빈 식이 아니더라도 MDX가 JSX expression으로 해석하는 케이스 회피).

네임스페이스

큰 앱은 한 JSON에 모든 키를 박지 않는다.

{

"common": { "save": "저장" },

"checkout": { "title": "결제" }

}

`t('checkout:title')` 처럼 콜론으로 접근.

복수 처리

i18next는 자체 복수 규칙(`_one`·`_other` suffix)을 제공하지만 ICU 호환 모드도 있다. `i18next-icu` 플러그인 활성화 시 MF1/MF2 문법 그대로 사용.

Lazy loading

- HTTP backend로 언어별 chunk 분리 → 초기 번들 가벼움.

- Next.js·Remix와 통합 시 SSR 안에서 키 prefetch.

강점·약점

- 강점: 생태계 크기·플러그인 수가 압도적. backend 자유.

- 약점: API가 조금 묵직. React Server Component·App Router 친화도는 next-intl·use-intl이 더 좋다는 평.

12장 · FormatJS / react-intl — React i18n

FormatJS는 Yahoo가 만든 i18n 도구 체인. 핵심은 **ICU MessageFormat 1급 시민**.

구성

- **@formatjs/intl** — 코어. Intl API(Web 표준)를 래핑.

- **react-intl** — React 바인딩.

- **@formatjs/cli** — 메시지 추출(extract) 도구. 소스에서 `defineMessages` 호출 모두 모음.

- **@formatjs/icu-messageformat-parser** — ICU 파서.

예시

const messages = {

ko: { greeting: '안녕하세요, {name}님' },

en: { greeting: 'Hello, {name}' },

}

function App() {

return (

)

}

강점

- ICU MessageFormat이 1급 시민. 복수·성별·날짜·숫자 포맷 일관성.

- 메시지 추출 CLI가 강력. 소스 → JSON 자동 생성 → TMS push.

- `<FormattedNumber>`·`<FormattedDate>`·`<FormattedRelativeTime>` 등 컴포넌트 친화.

약점

- React 외 환경에서 i18next만큼 다재다능하지 않음.

- 메시지 키가 길어지면 디버깅 힘듦.

그 외 React i18n 도구

- **next-intl** — Next.js App Router 최적화. SSG/SSR 모두 지원.

- **LinguiJS** — JSX 인라인 번역 컴포넌트(`<Trans>`). 메시지 ID 자동 생성.

- **FBT** — Meta(페이스북)가 만든 라이브러리. 자체 토크나이저로 복합 문장 처리.

13장 · 한국 — 파파고, 카카오 i 번역

글로벌 도구만 다루기엔 한국 시장이 너무 특수하다.

네이버 파파고

- 2016년 출시, 2026년 현재 한국 내 압도적 1위 번역 서비스.

- 강점: 한↔영, 한↔일, 한↔중에서 글로벌 엔진 대비 우위. 특히 한↔영의 자연스러움이 일품.

- API: 네이버 클라우드 플랫폼(NCP) Papago Translation. 일 10,000자 무료, 이후 자수 단위 과금.

- 2024년에 LLM 기반 차세대 엔진(HyperCLOVA X 기반) 도입.

- 약점: 비영어·비아시아 언어 쌍은 약함. 유럽 언어는 DeepL이 우위.

카카오 i 번역

- 카카오엔터프라이즈가 운영. 카카오톡·다음 검색 통합.

- API는 카카오 i 클라우드. 파파고 대비 점유율은 낮지만 카카오 생태계 내 통합이 강점.

- 비즈니스 콘텐츠·뉴스 도메인에 fine-tune된 모델 별도 제공.

사용 패턴

- 한국 기업의 일반적인 i18n 스택: TMS(Lokalise/Crowdin) + DeepL/파파고 동시 사용 + 사내 검수.

- B2C 콘텐츠 번역(웹툰·웹소설·미디어)은 파파고/카카오 + 사람 검수.

- 글로벌 SaaS는 DeepL/Claude/GPT가 더 일반적.

파파고 API 호출 예시

const res = await fetch('https://naveropenapi.apigw.ntruss.com/nmt/v1/translation', {

method: 'POST',

headers: {

'X-NCP-APIGW-API-KEY-ID': process.env.PAPAGO_ID,

'X-NCP-APIGW-API-KEY': process.env.PAPAGO_KEY,

'Content-Type': 'application/x-www-form-urlencoded',

},

body: new URLSearchParams({

source: 'ko',

target: 'en',

text: '안녕하세요',

}),

})

14장 · 일본 — NICT VoiceTra, NTT, Cygames in-house

NICT VoiceTra

- 일본 국립연구개발법인 정보통신연구기구(NICT)가 만든 다국어 음성 번역 시스템.

- 31개 언어 텍스트 번역 + 17개 언어 음성 인식·합성.

- 정부·관광 인프라(JR역, 공항)에서 광범위하게 사용. 기상청·관세청도 채택.

- 무료 앱(VoiceTra) 제공. 학술·공공기관 우대 API.

- 강점: 일본어 도메인 특화(법률, 의료, 관광, 재해 대응) fine-tune.

NTT — COTOHA Translator·tsuzumi

- NTT 그룹의 AI 사업부 NTT 인공지능 연구소가 운영.

- COTOHA Translator — 비즈니스 문서 특화. 일본 대기업 100+ 채택.

- tsuzumi(2024) — NTT 자체 LLM. 일본어 특화로 OpenAI 대비 일본어 표현 자연스러움 강조.

- 일본 국내 데이터 센터 운영 → 데이터 주권·금융·의료 산업에서 선호.

Cygames 등 게임 회사 in-house

- 일본 대형 게임사(Cygames, Square Enix, Bandai Namco)는 사내 LQA(Localization Quality Assurance) 팀 + 자체 번역 워크플로를 가진다.

- Crowdin·Lokalise·Phrase를 쓰되 사내 용어집과 캐릭터 voice DB를 별도 관리.

- 최근 Cygames는 LLM 기반 사내 번역 도구를 구축해 일본어 → 영어·중국어·한국어를 1차 번역 후 사람 LQA가 다듬는 워크플로 정착.

일본 시장 특수성

- 한자·가타카나·히라가나 3 스크립트의 혼용. LLM이 잘 처리하는지 모델별로 차이가 크다.

- 경어(존경어·겸양어·정중어) — 비즈니스 콘텐츠에서 결정적.

- 영어 차용어를 가타카나로 옮길지, 원래 한자/일본어로 옮길지가 도메인마다 다름.

15장 · 누가 무엇을 골라야 하나 — OSS / 스타트업 / 글로벌 / 셀프호스팅

지금까지의 정리를 4가지 시나리오로 답한다.

OSS 프로젝트 (커뮤니티 번역)

- **첫 선택**: Crowdin OSS 플랜 또는 Weblate.

- **이유**: 무료, 커뮤니티 번역 도구 성숙.

- **라이브러리**: i18next, gettext.

- **AI 보조**: pre-translation 기능으로 DeepL/OpenAI 백엔드 활용.

- **셀프호스팅 우선이면**: Weblate.

B2B SaaS 스타트업 (시드~시리즈 A)

- **첫 선택**: Tolgee Cloud 또는 Lingo.dev.

- **이유**: 가격 합리적. Tolgee는 in-context 편집, Lingo.dev는 PR 기반 자동화.

- **라이브러리**: i18next + react-i18next, 또는 next-intl(Next.js).

- **AI 보조**: Claude·GPT-4o API 직접 호출 또는 Tolgee 자동 번역.

글로벌 엔터프라이즈

- **첫 선택**: Phrase(RWS) 또는 Lokalise.

- **이유**: 컴플라이언스(SOC2/ISO/GDPR), 에이전시 워크플로, MQM 품질 측정.

- **AI + 사람 검수 워크플로**: DeepL + 자체 fine-tune + 번역자 검수.

- **컴플라이언스 우선이면**: Smartling.

셀프호스팅 (규제·기밀)

- **첫 선택**: Tolgee self-hosted 또는 Weblate.

- **이유**: 데이터 외부 유출 X. 의료·금융·정부 산업.

- **AI 통합**: 사내 LLM(예: Llama 3.3, Qwen 2.5) 또는 Azure OpenAI 프라이빗 엔드포인트.

안티패턴 7가지

1. "TMS 하나로 다 된다" — TMS는 인프라일 뿐, 라이브러리(i18next 등) 없으면 런타임에서 곤란.

2. AI 번역만 믿고 검수 생략 — 브랜드 voice·법적 카피가 깨진다.

3. 키 이름을 영문 메시지로 만들기 — 메시지 변경 시 키도 바뀌어 git diff 폭주. ID는 의미 기반.

4. ICU MessageFormat 안 쓰고 if/else 분기 코드로 복수 처리 — 새 언어 추가할 때마다 코드 수정.

5. 모든 페이지의 모든 키를 한 번에 로드 — 번들 크기·SSR 시간 폭주. lazy load.

6. glossary 없이 LLM 번역 — 브랜드명·제품명이 매번 다르게 나옴.

7. 셀프호스팅 OSS 도구의 데이터를 백업 안 함 — Weblate·Tolgee도 DB는 정기 백업 필수.

다음 글 예고

- 다음 후보: **i18n 라이브러리 깊게 — i18next vs FormatJS vs next-intl vs Lingui 코드 비교**, **MessageFormat 2.0 마이그레이션 실전**, **LLM 번역의 품질 평가(MQM·BLEU·COMET)와 사내 벤치마크 만들기**.

> "TMS는 키-값을 관리하고, 라이브러리는 런타임을 렌더링하고, AI는 raw 번역을 만들고, 사람은 톤과 문맥을 책임진다. 네 층 중 하나라도 빠지면 i18n은 무너진다."

— 현지화 & i18n 도구 2026, 끝.

참고 / References

- [Lokalise — Translation Management Platform](https://lokalise.com/)

- [Phrase — Localization Platform (RWS)](https://phrase.com/)

- [Phrase TMS (formerly Memsource)](https://phrase.com/platform/tms/)

- [Crowdin — Localization Management](https://crowdin.com/)

- [Crowdin Open Source program](https://crowdin.com/page/open-source-project-setup-request)

- [Tolgee — Open source localization](https://tolgee.io/)

- [Tolgee GitHub — tolgee/tolgee-platform](https://github.com/tolgee/tolgee-platform)

- [Weblate — Web-based translation](https://weblate.org/)

- [Weblate GitHub — WeblateOrg/weblate](https://github.com/WeblateOrg/weblate)

- [Localazy — Localization for mobile and web](https://localazy.com/)

- [POEditor — Translation management](https://poeditor.com/)

- [Lingo (Locize) — i18next backend service](https://www.locize.com/)

- [Transifex — Localization platform](https://www.transifex.com/)

- [Smartling — Translation Services & Software](https://www.smartling.com/)

- [Lingo.dev — LLM localization-as-code](https://lingo.dev/)

- [Locale.dev — AI translation for developers](https://locale.dev/)

- [DeepL — Translator and Pro API](https://www.deepl.com/)

- [DeepL Pro API documentation](https://developers.deepl.com/)

- [OpenAI API — GPT-4o models](https://platform.openai.com/docs/models/gpt-4o)

- [Anthropic Claude API — Messages](https://docs.anthropic.com/en/api/messages)

- [Google Gemini API](https://ai.google.dev/)

- [Reverso Context](https://context.reverso.net/translation/)

- [i18next documentation](https://www.i18next.com/)

- [i18next GitHub — i18next/i18next](https://github.com/i18next/i18next)

- [react-i18next](https://react.i18next.com/)

- [FormatJS — Internationalize your web apps](https://formatjs.io/)

- [react-intl documentation](https://formatjs.io/docs/react-intl/)

- [next-intl — Next.js i18n](https://next-intl-docs.vercel.app/)

- [LinguiJS](https://lingui.dev/)

- [FBT — Facebook i18n framework](https://facebook.github.io/fbt/)

- [ICU MessageFormat — Unicode CLDR](https://unicode-org.github.io/icu/userguide/format_parse/messages/)

- [MessageFormat 2.0 specification](https://unicode-org.github.io/message-format-wg/)

- [Unicode CLDR](https://cldr.unicode.org/)

- [XLIFF 2.0 specification — OASIS](https://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html)

- [GNU gettext](https://www.gnu.org/software/gettext/)

- [Naver Papago — Translator](https://papago.naver.com/)

- [Naver Cloud Platform Papago Translation API](https://www.ncloud.com/product/aiService/papagoTranslation)

- [Kakao i Translation](https://kakaoi.ai/)

- [NICT VoiceTra](https://voicetra.nict.go.jp/en/index.html)

- [NTT COTOHA Translator](https://www.ntt.com/business/services/application/ai/cotoha-translator.html)

- [NTT tsuzumi LLM](https://www.rd.ntt/e/research/JN202310_19069.html)

- [MQM — Multidimensional Quality Metrics](https://themqm.org/)