우리가 만나는 모든 엔터프라이즈는 결국 같은 두 가지 벽에 부딪힙니다.
첫 번째는 일관성을 유지하기 위해 치르는 조정 비용입니다.
Android 앱은 한 팀이 만들고, 웹 앱은 다른 팀이 만듭니다. 마케팅 사이트, 문서, 내부 툴링까지 각기 다른 팀이 맡고 있고, 각자 릴리스 주기도 다르고, 검토자도 다르고, 배포 파이프라인도 다릅니다.
레거시 도구도 프로젝트 간에 번역 메모리와 용어집을 공유할 수 있습니다. 워크스페이스도 있고, 조직 수준 자산도 있습니다. 하지만 공유된다고 해서 강제되는 것은 아닙니다. 공유 용어집의 용어는 번역자에게는 제안일 뿐, 모델에는 제약이 아닙니다. 결국 팀 간 일관성은 아키텍처가 아니라 운영 규율의 문제가 됩니다. 누군가는 용어집을 계속 맞춰야 하고, 누군가는 팀 사이의 전문 용어 충돌을 조정해야 하며, 누군가는 한 팀이 콜투액션을 이렇게 번역했는데 다른 팀은 다르게 배포한 상황을 따라다녀야 합니다. 일관성은 만들 수 있습니다. 하지만 유지 관리는 끝이 없습니다.
팀별 프로젝트 안에서는 드리프트가 더 빠르게 쌓입니다. 번역 메모리는 세그먼트가 바뀌지 않을 때만 일관성을 유지해 줍니다. 그런데 매주 리팩터링되는 코드베이스에서는 세그먼트도 매주 바뀝니다. 우리의 RAL 연구는 검색된 컨텍스트가 없을 때 용어가 얼마나 빠르게 드리프트하는지 측정합니다.
두 번째 벽은 바로 그 비용을 만들어내는 도구에서 벗어나는 데 드는 비용입니다. 엔터프라이즈에서는 모든 차원이 곱해집니다. 팀마다 쌓여 온 용어집, 프로젝트 전반에 걸쳐 TMX와 벤더 독점 형식으로 축적된 번역 메모리, 각 팀의 CI에 연결된 커넥터, 조달 과정을 거쳐 구성된 번역자 명단, IdP와 연동된 SSO까지 모두 그렇습니다.
그래서 마이그레이션은 어떤 로컬라이제이션 관리자도 떠안고 싶지 않은, 여러 분기에 걸친 엔지니어링 프로그램처럼 보이게 됩니다.
이 멀티팀 구조에 맞는 아키텍처는 두 가지입니다.
하나는 프로젝트 단위 번역 메모리를, 추론 시점에 컨텍스트를 가져오는 조직 단위 로컬라이제이션 엔진으로 대체하는 것입니다. 하나의 용어집, 하나의 브랜드 보이스를 두고 모든 팀의 앱이 같은 로컬라이제이션 엔진을 사용합니다.
다른 하나는 고객이 직접 마이그레이션하는 방식을, Lingo.dev의 전방 배치 로컬라이제이션 엔지니어가 대신 수행하는 방식으로 바꾸는 것입니다. 여러분의 시간이 아니라 우리의 시간으로 마이그레이션을 진행합니다.
이 두 패턴은 이미 여러분의 스택 안 다른 인프라 영역에서는 표준입니다. 이제 로컬라이제이션도 마침내 거기에 맞춰야 합니다.
아키텍처 #1: 로컬라이제이션 엔진#
로컬라이제이션 엔진
팀이 Lingo.dev에서 생성하는 상태 저장형 번역 API로, 조직별로 구성됩니다. 각 로컬라이제이션 엔진은 자체 용어집, 브랜드 보이스, 로캘별 지침, 그리고 우선순위가 지정된 모델 체인을 유지합니다. 모든 요청은 일치하는 용어집 항목을 검색해 첫 토큰이 생성되기 전에 모델의 컨텍스트 윈도에 주입하고, 완료 후에는 별도로 점수화됩니다. 첫 번째 번역은 컨텍스트 없이 시작하지만, 천 번째 번역은 그동안 축적된 모든 맥락의 이점을 누립니다.
로컬라이제이션 엔진은 세그먼트 수준이 아니라 용어 수준에서 일관성을 유지합니다. 범위도 특정 팀의 프로젝트가 아니라 조직 전체입니다. 하나의 용어집, 하나의 브랜드 보이스를 두고 모든 팀의 모든 표면이 같은 로컬라이제이션 엔진을 사용합니다.
"Submit"에 대한 glossary 항목 하나면 버튼, 이메일 제목, 툴팁 등 모든 스페인어 표면에서 작동합니다. 웹 팀이든 모바일 팀이든 상관없습니다. 검색은 문자열이 아니라 의미를 기준으로 매칭됩니다. "Deploy" 항목 하나로 "deploying", "deployment", "Deploy your app"까지 모두 대응할 수 있습니다. 형태별로 항목을 따로 만들 필요가 없습니다.
브랜드 보이스는 로캘별로 로컬라이제이션 엔진에 연결되며, 모든 요청이 이를 사용합니다.
Instructions는 로캘 단위로 적용되는 개별적이고 테스트 가능한 규칙입니다. 약어 규칙, 줄바꿈 없는 공백, 따옴표 같은 요소를 각각 따로 디버깅할 수 있습니다.
model chain은 각 요청을 기본 모델로 라우팅하고, 우선순위가 매겨진 대체 모델을 둡니다. 용어집은 그대로 둔 채 제공자만 바꿀 수 있습니다.
AI 평가자는 독립된 모델에서 실행됩니다. 모든 요청을 용어집과 각 지침에 대해 각각 점수화합니다. 이유가 포함된 합격/불합격 결과를 시계열로 추적할 수 있습니다.
| 항목 | 프로젝트 단위 도구 | 조직 단위 로컬라이제이션 엔진 |
|---|---|---|
| 일관성의 범위 | 프로젝트별, 팀별 | 조직 전체 |
| 일관성의 단위 | 해시를 기준으로 한 전체 세그먼트 | 의미 기반으로 매칭되는 개별 용어 |
| 원문이 다시 쓰여도 유지되는가 | 아니요 | 예 |
| 앱 간, 팀 간 일관성 | 운영 규율에 의존; 사람이 계속 맞춰야 함 | 아키텍처로 해결; 로컬라이제이션 엔진이 계속 맞춤 |
| 품질 측정 | 규칙 기반 검사(태그, 숫자) | 요청별 LLM 점수화 |
| 모델 유연성 | 제공자 종속 | 우선순위 체인 |
| 출력의 최종 기준 | 번역자 재량 | 용어집이 모델보다 우선 |
드리프트는 더 이상 그냥 감수하는 상태가 아니라, 측정할 수 있는 상태가 됩니다. 용어집은 모든 요청에서 작동하고, AI 평가자는 요청별로 준수 여부를 검증합니다.
이 메커니즘의 이름은 retrieval augmented localization (RAL)입니다. 추론 시점에 엔진은 입력을 n-gram 구문으로 분해하고, 이를 임베딩한 뒤 용어집의 벡터 인덱스를 대상으로 코사인 유사도 검색을 수행합니다. 일치한 용어는 첫 토큰이 생성되기 전에 모델의 컨텍스트 윈도에 들어갑니다. 구조적으로는 RAG와 같고, 이를 번역에 적용한 방식입니다.
여러 LLM 제공자와 여러 유럽 언어를 대상으로 한 통제된 평가에서 RAL은 용어 오류를 17–45% 줄였습니다. 쌍으로 비교한 품질 판정은 42,000건 이상이었습니다. 모든 제공자에서 Holm-Bonferroni 보정 p < 0.001이 나왔습니다. 반면 전체 품질 점수만으로는 이 차이를 전혀 포착하지 못했습니다.
아키텍처 #2: 전방 배치 로컬라이제이션 엔지니어링#
두 번째 벽은 마이그레이션입니다. 지금도 돌아가는 스택이 있습니다. 비용을 만들어내긴 하지만, 어쨌든 작동은 합니다. 그리고 그것을 교체하는 비용, 즉 엔지니어링 시간, 통합 재작업, 번역자 재온보딩, 과거 데이터 마이그레이션 비용은 대개 그 조정 비용을 계속 내는 것보다 더 큽니다.
그래서 그 비용은 계속 지불됩니다. 우리는 같은 마이그레이션 병목이 진지한 엔터프라이즈의 전환을 막는 장면을 반복해서 봤고, 결국 그 마이그레이션 자체를 우리가 떠안기로 했습니다.
Lingo.dev가 엔터프라이즈를 온보딩할 때는 우리 엔지니어가 마이그레이션을 수행합니다. 라이선스 위에 별도로 얹는 프로페셔널 서비스 계약이 아니라, 기본 온보딩 경로로 그렇게 합니다.
전방 배치 로컬라이제이션 엔지니어는 여러분의 용어집, 브랜드 보이스 문서, 커넥터 설정, 번역자 계약까지 직접 살펴봅니다. TMX에 있는 번역 메모리도, 어떤 레거시 형식에 있든 그 용어집도 그대로 가져옵니다. 아무것도 새로 추정해 만들지 않습니다. 여러분의 용어를 미리 적재한 상태로 Lingo.dev 위에 로컬라이제이션 엔진을 구축합니다. 이를 CI에 연결하고, 신뢰하는 인력이 계속 프로세스에 남아 있을 수 있도록 번역자 명단도 비동기 파이프라인에 연결합니다.
특히 멀티팀 환경에서 이 아키텍처의 가치가 분명해집니다. 레거시 방식에서는 팀 간 용어를 맞추려면 동기화된 N개의 마이그레이션이 필요합니다. 각 팀이 자기 프로젝트 안에서 키와 TM을 다시 만들어야 하기 때문입니다. 여기서는 로컬라이제이션 엔진을 한 번만 구축하면 됩니다. 각 팀은 자기 일정에 맞춰 앱을 연결하면 됩니다. 앱 간 일관성은 모든 팀이 각자 마이그레이션을 마친 뒤가 아니라, 엔진을 사용하는 첫 번째 로캘부터 바로 나타납니다.
우리 엔지니어는 다음 프로덕션 배포, 그리고 그다음 배포까지 함께하며, 내부 팀이 시스템을 완전히 인수할 때까지 곁에 있습니다.
이것이 우리가 엔터프라이즈 고객을 온보딩하는 방식입니다.
멀티팀 조직이 매주 배포하는 단계에 이르면, 번역은 구매자와 벤더 사이를 오가는 조달 티켓이어서는 안 됩니다. 다음 프로덕션 배포 이후가 아니라, 그 배포와 나란히 돌아가야 합니다. 전방 배치 엔지니어링은 Palantir, Scale AI, Ramp를 비롯한 인프라 벤더들이 10년 넘게 엔터프라이즈 고객을 온보딩해 온 방식입니다.
이제 로컬라이제이션도 마침내 여기에 맞춰야 합니다.
진단
Lingo.dev 엔지니어가 소스 리포지토리, 기존 TM(TMX 익스포트 포함), 용어집, 커넥터, 번역자 계약을 검토합니다. 각 표면을 맡고 있는 모든 팀을 아우릅니다. 그리고 순서와 일정이 담긴 마이그레이션 계획을 수립합니다. 그 계획의 소유권은 여러분에게 있습니다.
현재 품질에 맞춘 엔진 구축
가져온 용어집, 로캘별 브랜드 보이스, 번역자 파이프라인을 바탕으로 로컬라이제이션 엔진을 구성합니다. 프로덕션 트래픽을 붙이기 전에 현재 도구의 출력과 엔진의 출력을 나란히 비교합니다. 같은 문자열, 같은 주차 기준입니다. 품질이 유지되는지는 여러분이 판단합니다.
각 팀의 CI에 연결
전면 교체는 없습니다. 로컬라이제이션 엔진은 각 팀의 기존 파이프라인 안에서 하나의 단계로 동작합니다. 머지 플로, 검토 플로, 검토자까지 모두 그대로 유지됩니다. 엔진이 기존 단계를 대체할 뿐입니다.
여러분의 일정에 맞춘 전환
처음에는 한 팀, 한 로캘 페어부터 시작합니다. 그다음은 세 개, 그리고 나머지로 확장합니다. 순서는 여러분이 정합니다. 우리는 각 단계마다 비교를 수행합니다. 롤백은 커밋 하나면 됩니다.
여러분 팀으로 이관
우리 엔지니어가 시스템을 여러분의 플랫폼 팀에 인계합니다. 문서, 런북, 그리고 팀이 완전히 인수할 때까지 우리가 맡는 온콜 로테이션까지 포함해서 말입니다.
근거#
연구. RAL 연구: 여러 LLM 제공자와 여러 유럽 언어에 걸친 42,000건 이상의 쌍 비교 품질 판정. 모든 제공자에서 Holm-Bonferroni 보정 p < 0.001. 용어 오류 감소 폭은 17–45%였습니다.
모델 선택보다 중요한 것은 구성입니다. Mistral, Gemini, Claude, GPT 전반에서 우리는 좋은 용어집, 브랜드 보이스, 컨텍스트 구성이 있으면 어떤 모델이든 훨씬 낮은 비용으로 배포 가능한 기준급 번역을 일관되게 만들어낸다는 것을 확인했습니다. 모델 자체를 개선했기 때문이 아닙니다. 로컬라이제이션 엔진은 모든 요청에서 유사도 검색으로 일치하는 용어집 항목, 브랜드 보이스, 로캘 지침을 가져와 첫 토큰이 생성되기 전에 모델의 컨텍스트 윈도에 주입합니다.
프로덕션 규모. 플랫폼에서 2억 단어 이상을 번역했습니다.
고객사 공개. Mistral, Solana, SoSafe, Cal.com.
범위#
Lingo.dev는 다양한 형태의 로컬라이제이션 팀을 지원합니다. 단일 제품 기업, 오픈소스 프로젝트, 모바일 전담 팀, 엔터프라이즈 플랫폼까지 모두 포함됩니다. 여기서 소개하는 아키텍처는 20개 이상의 로캘에 걸쳐 여러 앱을 출시하는 복수의 팀을 둔 엔터프라이즈 환경에 맞춰 설계된 구성입니다.
이제 이렇게 진행됩니다#
첫 단계는 2주간의 파일럿입니다. 한 팀, 한 로캘 페어로 시작합니다.
현장에 투입되는 로컬라이제이션 엔지니어가 귀사의 로컬라이제이션 책임자 및 엔지니어링 리드와 긴밀히 협업합니다. 먼저 현재 워크플로를 면밀히 살펴봅니다. 이어서 팀이 구사하지 않는 언어의 번역 품질까지 가시적으로 확인할 수 있도록 측정 체계를 구축합니다. 독립적인 모델에서 실행되는 AI 평가자가 각 번역을 귀사의 용어집과 규칙에 따라 점수화합니다. 이 평가는 번역 품질 평가의 표준 프레임워크인 MQM을 바탕으로 조정되었습니다.
귀사의 용어집과 브랜드 보이스 문서를 기반으로 로컬라이제이션 엔진을 구축합니다. 그리고 현재 사용 중인 도구와 나란히 귀사의 원문 콘텐츠에 적용해 봅니다. 결과의 차이를 직접 확인한 뒤 결정하시면 됩니다.
그다음에는 남은 팀과 로캘에 대한 마이그레이션 일정을 우리의 일정이 아니라 귀사의 일정에 맞춰 잡습니다.
지금 바로 로컬라이제이션 엔지니어링 전문가와 상담하세요.
