목차
팀을 위한 로컬라이제이션 도구 평가 업무를 맡아보셨다면, 아마 이런 점을 느끼셨을 겁니다. TMS 시장은 혼란스럽습니다. 마케팅 페이지에서는 "원활한 워크플로"와 "AI 기반 번역"을 약속하지만, 번역이 실제로 앱에 어떻게 들어가는지, 누가 얼마를 지불하는지, 또는 마이그레이션이 얼마나 어려운지에 대해서는 거의 언급하지 않습니다.
이 가이드는 그 혼란을 정리해 드립니다. TMS가 실제로 무엇을 하는지(그리고 하지 않는지), 마주치게 될 세 가지 아키텍처 모델, 10가지 평가 기준 체크리스트, 그리고 상황에 맞는 올바른 카테고리를 선택하는 데 도움이 되는 의사결정 프레임워크를 다룹니다.
TMS가 실제로 하는 일(그리고 하지 않는 일)
번역 관리 시스템은 소스 콘텐츠와 최종 사용자 사이에 위치합니다. 핵심적으로 세 가지 문제를 해결합니다.
- 번역이 필요한 항목 추적 — 새로운 문자열, 변경된 문자열, 삭제된 문자열
- 번역 담당자 조율 — 번역가 배정, 검토 워크플로 관리
- 번역된 콘텐츠 전달 — 최종 번역을 앱에 적용
대부분의 엔지니어링 팀은 #3에 지나치게 집중하고 #1과 #2를 경시합니다. 이는 실수입니다. TMS가 추적 및 조율에서 실패하는 부분이 바로 로컬라이제이션 백로그가 쌓이는 곳입니다.
TMS가 하지 않는 일은, 일부 공급업체가 암시하는 것과 달리, 소스 코드를 대체하거나 앱을 자동으로 다국어로 만들거나 고위험 콘텐츠에 대한 사람의 검토 필요성을 없애지 않습니다. AI 번역의 품질이 극적으로 향상되었지만, "앱 스토어 설명에 적합한 수준"과 "법적 문서에 적합한 수준"은 다른 기준입니다.
TMS의 세 가지 아키텍처
전달 모델을 이해하는 것이 가장 중요한 아키텍처 결정입니다. 시장의 모든 TMS는 세 가지 카테고리 중 하나에 속합니다.
파일 동기화 TMS
가장 오래되고 가장 일반적인 모델입니다. 앱에는 /locales 또는 /public/lang 같은 디렉터리에 로케일 파일(JSON, YAML, PO 등)이 포함되어 있습니다. TMS는 해당 파일을 가져와 번역을 위해 내보내고, 일반적으로 CLI 도구, GitHub 통합 또는 CI/CD 단계를 통한 동기화 메커니즘으로 번역된 파일을 저장소에 다시 푸시합니다.
실제 작동 방식: tms pull을 실행하여 최신 번역을 가져오고, 커밋한 후 배포합니다. 또는 TMS가 일정에 따라 업데이트된 로케일 파일이 포함된 PR을 열기도 합니다.
장점:
- 모든 스택과 호환 — 앱이 파일을 읽을 수 있으면 작동합니다
- 이해 및 감사가 용이 — 번역이 저장소의 파일에 불과합니다
- 성숙한 도구 및 대규모 에코시스템
- 외부 서비스에 대한 런타임 의존성 없음
단점:
- 로케일 파일이 빠르게 커져 노이즈가 많은 diff를 생성합니다
- 번역 업데이트에 배포 주기가 필요합니다
- 브랜칭 전략이 복잡해집니다 — 어느 브랜치에 "실제" 번역이 있습니까?
- 여러 파일에 걸친 키 관리가 오류가 발생하기 쉽습니다
- 타입 안전성 없음 — 누락되거나 이름이 변경된 키가 런타임에 조용히 실패합니다
API 우선 TMS
파일을 동기화하는 대신 앱이 런타임에 TMS API 엔드포인트에서 번역을 가져옵니다. 이를 통해 저장소에서 로케일 파일이 제거됩니다. TMS는 런타임 의존성이 됩니다.
실제 작동 방식: 앱 시작 시(또는 각 요청 시) 클라이언트가 GET /translations?locale=de&namespace=checkout과 같은 API를 호출합니다. TMS는 현재 번역이 포함된 JSON 객체를 반환합니다.
장점:
- 번역 업데이트가 즉각적 — 재배포 불필요
- 저장소에 로케일 파일이 없습니다
- 많은 수의 키를 더 쉽게 관리할 수 있습니다
단점:
- 신중하게 캐시되지 않으면 콜드 스타트 지연이 발생합니다
- 런타임의 네트워크 의존성 — TMS 장애가 앱을 중단시킬 수 있습니다
- 캐싱 전략이 사용자의 책임입니다
- SDK 품질이 매우 다양 — 타입 안전성이 자주 없음
- 규모에 따라 요청당 과금 모델이 비싸질 수 있습니다
CDN 우선 TMS
API 우선의 전달 이점과 정적 파일의 성능 특성을 결합한 최신 아키텍처입니다. 번역이 컴파일되어 불변의 버전 관리된 번들로 CDN에 게시됩니다. 앱은 로케일 번들을 한 번 가져와(일반적으로 시작 시 또는 로케일 전환 시) 공격적으로 캐시합니다.
실제 작동 방식: TMS에 게시하면 TMS가 번들을 컴파일하여 엣지 위치에 푸시합니다. 앱은 https://cdn.example.com/v42/de.json을 가져와 세션에 사용합니다. URL 구조로 캐시 무효화가 결정적이게 됩니다.
장점:
- 저장소에 로케일 파일 없음
- 번역 게시 시 즉각적인 캐시 무효화
- 예측 가능한 저지연 전달 — CDN 엣지가 API보다 빠릅니다
- 번역 업데이트에 배포가 필요 없습니다
- 스키마에서 SDK를 생성하여 타입 안전성 구현 가능
단점:
- 파일 동기화보다 약간 복잡한 개념적 모델
- 번들 버전 관리 전략에 약간의 계획이 필요합니다
- 파일 동기화 도구에 비해 덜 성숙한 에코시스템
TMS 평가를 위한 10가지 기준
평가를 진행할 때 이 체크리스트를 사용하세요. 각 기준에 대해 각 후보에 1~5점을 부여하세요.
1. 개발자 워크플로 통합
TMS가 팀의 기존 작업 방식에 맞습니까? 다음을 확인하세요. 네이티브 Git 통합(PR 기반 워크플로, 브랜치 감지), CI/CD 파이프라인에서 작동하는 CLI, 그리고 프레임워크(React, Vue, Swift, Android 등)를 이해하는 추출 도구.
위험 신호: TMS 통합이 기존 파이프라인에 없는 별도의 배포 단계를 요구한다면 건너뛰게 될 것입니다.
2. 번역 전달 모델
어떤 아키텍처를 사용합니까? 요구사항에 맞게 선택하세요. 재배포 없이 즉각적인 업데이트가 필요하다면 파일 동기화는 작동하지 않습니다. 번역 로딩의 P99 지연이 50ms 미만이어야 한다면 캐시되지 않은 API 우선 방식도 작동하지 않습니다. 공급업체에 구체적으로 물어보세요. "번역이 귀사 시스템에서 프로덕션 앱으로 어떻게 단계별로 이동합니까?"
3. AI 번역 기능
여기에는 넓은 스펙트럼이 있습니다. 한쪽 끝에는 원시 기계 번역(문자열을 MT 공급업체에 파이핑)이 있습니다. 다른 쪽 끝에는 UI를 이해하고, 용어집을 적용하며, 플레이스홀더를 올바르게 처리하고, 브랜드 보이스에 맞게 조정할 수 있는 컨텍스트 인식 번역이 있습니다.
핵심 질문:
- AI 번역이 용어집과 번역 메모리를 존중합니까?
- 대상 언어의 복수형 규칙을 처리할 수 있습니까?
- 문자열의 동적 변수(예:
Hello, {name})를 어떻게 처리합니까?
4. 타입 안전성 및 SDK 품질
엔지니어링 팀에서 이 부분은 번역 키 누락으로 인한 첫 번째 런타임 충돌이 발생하기 전까지 자주 경시됩니다. 좋은 SDK는 번역 스키마에서 타입을 생성하여 t('checkout.cta.button')이 프로덕션이 아닌 컴파일 타임에 실패하도록 합니다.
SDK 평가 항목: TypeScript 지원, 키 자동완성, 복수형 처리, 보간 타입 안전성, 프레임워크별 통합.
5. 가격 모델 투명성
TMS 가격은 악명 높게 불투명합니다. 일반적인 모델:
- 사용자당(편집자/번역가)
- 번역된 단어당(MT 또는 사람)
- 키당(관리되는 문자열 수)
- 플랫폼 요금 + 사용량
실제 수치를 기반으로 구체적인 견적을 받으세요. 키 수, 로케일 수, 번역가 수, 월별 번역 단어 수. 그런 다음 초과 시 어떻게 되는지 물어보세요.
가격 책정 방식에 대해서는 가격 페이지를 참조하세요.
6. 용어집 및 번역 메모리
번역 메모리(TM)는 이전 번역을 저장하여 일관된 문자열이 두 번 번역되지 않도록 합니다. 용어집 적용은 브랜드 용어, 제품명, 기술 용어가 절대 오역되지 않도록 합니다.
이러한 기능은 비용을 절감하고 일관성을 향상시킵니다. 공급업체에 물어보세요. "한 컨텍스트에서 'dashboard'를 번역하면 모든 로케일에 자동으로 재사용됩니까?"
7. 협업 기능
사내 번역가가 있거나 로컬라이제이션 에이전시와 협력하는 경우 TMS는 그들의 워크플로도 지원해야 합니다. 다음을 확인하세요. 시각적 편집기(실제 UI 컨텍스트에서 번역 편집), 검토/승인 워크플로, 특정 키에 대한 댓글 스레드, 역할 기반 액세스 제어.
팀이 개발자 전용이고 AI 번역 + 외부 검토를 사용하는 경우 여기에서는 가벼운 도구로 충분합니다. 사용하지 않을 엔터프라이즈 협업 기능에 비용을 지불하지 마세요.
8. 확장성
현재 규모의 10배에서 TMS는 어떻게 작동합니까? 구체적으로:
- 키: 번역 키가 100,000개 이상일 때 성능이 어떻게 저하됩니까?
- 로케일: 대상 언어 수에 실질적인 제한이 있습니까?
- 팀 규모: 별도의 팀으로 여러 프로젝트/네임스페이스를 관리할 수 있습니까?
- 요청량: API 우선 또는 CDN 우선 모델을 사용하는 경우 처리량 한계는 무엇입니까?
9. 마이그레이션 노력
TMS 공급업체를 전환하는 것은 고통스럽습니다. 커밋하기 전에 비용을 솔직하게 평가하세요.
- 새 TMS가 기존 로케일 파일이나 TM을 가져올 수 있습니까?
- SDK 마이그레이션 경로는 무엇입니까? 코드베이스 전체에서 번역 호출 위치를 변경해야 합니까?
- 전환 중 다운타임이 있습니까?
- 기존 용어집 및 TM 데이터는 어떻게 됩니까?
10. 공급업체 종속 위험
이것은 마이그레이션 노력과 관련이 있지만 별도의 기준으로 다룰 가치가 있습니다. 물어보세요. "2년 후 플랫폼을 떠나고 싶다면 무엇을 가져갈 수 있습니까?" 번역 메모리, 용어집, 그리고 모든 번역된 콘텐츠를 표준 형식으로 내보낼 수 있어야 합니다. 답이 모호하다면 그것은 신호입니다.
비교표
| 기준 | 파일 동기화 TMS | API 우선 TMS | CDN 우선 TMS |
|---|---|---|---|
| 개발자 워크플로 | Git 친화적, PR 기반 | API/SDK 중심 | Git + SDK, 타입 안전 |
| 번역 전달 | 배포 필요 | 런타임 API 호출 | CDN 번들, 엣지 캐시 |
| 업데이트 속도 | 느림(배포 주기) | 즉각적 | 즉각적 |
| 런타임 의존성 | 없음 | 높음 | 낮음(캐시된 번들) |
| 타입 안전성 | 드묾 | 가능 | 네이티브(스키마 기반) |
| 저장소의 로케일 파일 | 있음 | 없음 | 없음 |
| AI 번역 | 다양 | 다양 | 컨텍스트 인식 |
| 지연 | 해당 없음(번들) | 캐싱에 따라 다름 | 낮음(엣지 CDN) |
| 키 확장 | 노이즈 많아짐 | 일반적으로 양호 | 일반적으로 양호 |
| 종속 위험 | 중간 | 중간~높음 | 공급업체에 따라 다름 |
의사결정 프레임워크
로컬라이제이션 복잡성이 최소한인 소규모 팀이라면, 파일 동기화가 아마도 적합합니다. 단순하고, 잘 이해되어 있으며, 런타임 의존성이 없습니다. 로케일이 많고 번역 업데이트가 빈번해지면 나중에 불편함이 생깁니다.
재배포 없이 즉각적인 번역 업데이트가 필요하고 API 예산이 있다면 API 우선이 한 단계 발전입니다. 다만 신뢰성 의존성을 도입하지 않도록 주의하세요 — TMS API가 새벽 2시에 사용 불가능해지는 것은 이제 당직자의 문제가 됩니다.
TypeScript를 사용하는 최신 프런트엔드 앱을 구축하고, 빠른 첫 번째 상호작용 시간이 필요하며, 배포 파이프라인과 독립적으로 번역 업데이트를 게시하고 싶다면, CDN 우선이 에코시스템이 나아가는 방향입니다. 타입 안전성, 엣지 전달, 배포 독립성의 조합은 한번 경험하면 반박하기 어렵습니다.
3~4개 이상의 로케일로 성장한 팀을 관리하는 엔지니어링 매니저라면, 저장소의 로케일 파일, 느린 번역 배포, 프로덕션의 키 누락 버그에 불편함을 느끼기 시작하는 시점 — 이것이 바로 TMS 아키텍처 전환이 효과를 발휘하는 변곡점입니다. 단순히 동일한 아키텍처 내에서 업그레이드하지 마세요. 세 가지 모두를 평가해 보세요.
다양한 아키텍처를 실제로 비교하려면 비교 페이지를 참조하거나 개발자 중심 기능에 대해 읽어보세요.
마이그레이션 고려사항: 전환 전에 물어봐야 할 것들
새 TMS를 결정하기 전에 공급업체와 함께 이 체크리스트를 검토하세요.
데이터 이식성
- 모든 번역된 문자열을 TMX 또는 XLIFF 형식으로 내보낼 수 있습니까?
- 용어집을 표준 CSV 또는 TBX 파일로 내보낼 수 있습니까?
- [현재 도구]에서 가져오기 위한 마이그레이션 가이드가 있습니까?
SDK 마이그레이션
- 클라이언트 SDK 전환은 어떤 모습입니까? 드롭인 교체입니까, 아니면 번역 호출 위치의 전면 재작성입니까?
- codemod 또는 마이그레이션 스크립트가 있습니까?
- 단계적 롤아웃 중에 두 SDK를 병렬로 실행할 수 있습니까?
전환
- 두 시스템이 동시에 작동하는 기간이 있습니까?
- 진행 중인 콘텐츠(번역을 위해 보내졌지만 아직 반환되지 않은 문자열)를 어떻게 처리합니까?
마이그레이션 중 가격
- 마이그레이션 체험 기간이 있습니까?
- 두 시스템에 비용을 지불하는 병렬 실행 단계 중 비용 모델은 무엇입니까?
결론
TMS 시장은 최신 프런트엔드 아키텍처를 따라잡지 못했습니다. 대부분의 도구는 여전히 로케일 파일이 저장소에 있고, 배포가 번역 업데이트의 허용 가능한 경로이며, "타입 안전성"이 README에 키 명명 규칙을 문서화하는 것을 의미한다고 가정합니다.
그 가정은 2015년에는 합리적이었습니다. 프런트엔드가 CDN에 배포된 정적 번들이고, 팀이 하루에 여러 번 배포하며, 번역 키 누락이 로컬라이즈된 시장의 결제 플로우를 조용히 중단시킬 수 있는 세상에서는 더 이상 유효하지 않습니다.
도구를 평가할 때는 전달 모델에서 시작하세요. 나머지 모든 것 — AI 품질, 협업 기능, 가격 — 은 다음에 우선시되어야 합니다. 번역이 실제로 앱에 어떻게 들어가고, 얼마나 빠른가?
CDN 우선 방식이 실제로 어떤 모습인지 보고 싶다면 기능 탐색을 하거나 이미 평가 중인 도구와 비교해 보세요.
Better i18n은 최신 프런트엔드 팀을 위해 구축된 개발자 우선 로컬라이제이션 플랫폼입니다. 타입 안전 SDK, Git 기반 워크플로, CDN 전달, 그리고 저장소에 로케일 파일 없이 용어집 적용이 가능한 AI 번역을 제공합니다.
