LabHub

블로그

현지화 & i18n 도구 2026 — Lokalise / Phrase / Crowdin / Tolgee / Weblate / DeepL / Lingo.dev 심층 가이드

2026-05-16 · 36 분 읽기 · #i18n#localization#l10n#lokalise#phrase#crowdin#tolgee#weblate#lingo#transifex#smartling#deepl#i18next#formatjs#react-intl#icu#deep-dive

한국어English日本語

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

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-codeLLM + git 워크플로Lingo.dev, Locale.dev, OpenStrings

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

시나리오권장 후보이유
OSS 프로젝트 (다국어 번역자 모집)Crowdin, Weblate, Tolgee무료/할인 OSS 플랜, 커뮤니티 번역 도구
B2B SaaS 스타트업 (제품 다국어화)Lokalise, Phrase, Lingo.devTMS + 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 디자인 + 개발자 친화 워크플로"의 표준으로 자리잡았다.

핵심 개념

개발자 워크플로

가격 (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

강점·약점

언제 고르나

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

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

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

핵심 개념

개발자 워크플로

가격

강점·약점

언제 고르나

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

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

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

핵심 개념

개발자 워크플로

가격

플랜가격
Free (소규모)$0, 1 프로젝트, 60,000 자
Pro$50/월
Team$250/월
Business$450/월
Enterprise협의
OSS무료 (승인 필요)

강점·약점

언제 고르나

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 예시
import { Tolgee, TolgeeProvider } from '@tolgee/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 (
    <TolgeeProvider tolgee={tolgee}>
      <Page />
    </TolgeeProvider>
  )
}

핵심 개념

가격

플랜가격키
Free$01,000 string, 3 user
Cloud Standard$69/월10,000 string
Cloud Enterprise협의무제한
Self-hosted Free$0무제한 (소규모 팀)
Self-hosted Business협의SSO, 감사로그

강점·약점

언제 고르나

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

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

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

Weblate — GPL 풀스택 셀프호스팅

Localazy — 체코 또 하나의 강자

POEditor

비교 요약

도구OSS?셀프호스팅강점약점
WeblateGPLOLinux 데스크탑·OSS의 표준UI 다소 옛날
LocalazyXX모바일 친화, ShareTM셀프호스팅 불가
POEditorXX가장 저렴, 간단함고급 기능 약함

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

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

Transifex — 오래된 강자

Smartling — 엔터프라이즈 전용

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

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

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

GPT-4o (OpenAI) translation

Claude (Anthropic) translation

Gemini (Google) translation

Reverso

Anthropic translation API + Korean/Japanese majors

품질 비교 (한·영·일 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로 다뤄야 한다".

핵심 발상

예시

# 설치
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

강점

약점

언제 고르나

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

경쟁자

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)

11장 · i18next — JS i18n의 표준

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

핵심 개념

예시 (React)

import i18n from 'i18next'
import { initReactI18next, useTranslation } from 'react-i18next'

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

강점·약점

12장 · FormatJS / react-intl — React i18n

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

구성

예시

import { IntlProvider, FormattedMessage } from 'react-intl'

const messages = {
  ko: { greeting: '안녕하세요, {name}님' },
  en: { greeting: 'Hello, {name}' },
}

function App() {
  return (
    <IntlProvider locale="ko" messages={messages.ko}>
      <FormattedMessage id="greeting" values={{ name: '영주' }} />
    </IntlProvider>
  )
}

강점

약점

그 외 React i18n 도구

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

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

네이버 파파고

카카오 i 번역

사용 패턴

파파고 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

NTT — COTOHA Translator·tsuzumi

Cygames 등 게임 회사 in-house

일본 시장 특수성

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

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

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

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

글로벌 엔터프라이즈

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

안티패턴 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는 정기 백업 필수.

다음 글 예고

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

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

참고 / References

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다