지속적 현지화: 번역과 코드베이스를 동기화하는 방법

지속적 현지화: 번역과 코드베이스를 동기화하는 방법

TL;DR / 핵심 내용

• 지속적 현지화는 번역을 릴리스 시점의 일회성 작업이 아닌, CI/CD가 테스트와 배포를 처리하는 것과 동일한 방식으로 지속적인 파이프라인 단계로 다룹니다.
• 릴리스 주기가 빨라질수록 배치 번역 워크플로우는 한계를 드러냅니다: 문자열이 오래되고, 머지 충돌이 쌓이며, 번역가가 컨텍스트를 잃게 됩니다.
• 제대로 동작하는 지속적 현지화 파이프라인은 코드 변경, 문자열 추출, 번역 트리거, 검토, 병합, 배포의 여섯 단계로 구성됩니다. 각 단계는 다양한 수준으로 자동화할 수 있습니다.
• 주요 통합 패턴은 동기화를 트리거하는 방식에 따라 다릅니다: VCS의 webhook, CI 단계에서의 CLI 기반 push/pull 명령, 로컬 개발을 위한 파일 워처, 배포 없이 업데이트되는 OTA/CDN 방식이 있습니다.
• 단일 도구로 이 문제의 모든 부분을 해결할 수 없습니다. 최적의 설정은 릴리스 주기, 언어 수, 번역가 워크플로우, 그리고 OTA 업데이트가 제품에 필요한지 여부에 따라 달라집니다.

지속적 현지화란 무엇인가?

지속적 현지화는 번역을 릴리스 주기마다 한 번 발생하는 수동 단계가 아니라, 소프트웨어 개발 수명 주기에 지속적이고 자동화된 프로세스로 통합하는 방식입니다.

이것이 왜 중요한지 이해하려면, 전통적인 방식인 배치 번역 또는 워터폴 번역과의 차이를 살펴보면 됩니다. 배치 워크플로우에서는 개발자가 기능을 완성하면, 제품 관리자가 모든 새 문자열을 스프레드시트나 내보내기 파일로 수집하고, 현지화 관리자가 번역가(내부 또는 외부)에게 제출하고, 번역이 며칠 또는 몇 주 후에 돌아오면, 개발자가 이를 가져오고, 릴리스는 마지막 로케일이 완료될 때까지 기다립니다. 이 사이클은 소프트웨어가 분기별로 출시될 때는 합리적으로 작동했습니다. 그러나 팀이 주 단위나 일 단위로 배포할 때는 한계를 드러냅니다.

CI/CD와의 유사성은 직접적입니다. 지속적 통합 이전에는 개발자들이 오랜 기간 유지되는 브랜치에서 작업하고, 통합이 늦게 이루어지며, 머지 충돌 비용이 시간에 비례하여 증가했습니다. CI는 통합을 더 일찍, 더 자주 수행함으로써 그 비용을 크게 줄였습니다. 지속적 현지화는 번역에 동일한 원칙을 적용합니다: 스프린트 동안 문자열 변경을 누적하고 릴리스 시점에 조정하는 대신, 각 코드 변경이 번역 파이프라인을 즉시 트리거합니다.

이 방식은 때로 시프트-레프트 현지화라고 불리기도 합니다 — 테스트에 적용된 '시프트 레프트' 개념과 동일하게, 문제를 일찍 발견할수록 나중에 발견하는 것보다 비용이 적게 듭니다. 작성된 당일 번역 파이프라인에 들어간 문자열은 완전한 컨텍스트와 함께, 백로그 압박 없이, 릴리스를 막을 위험 없이 번역됩니다. 릴리스 하루 전에 파이프라인에 들어간 문자열은 압박 속에서, 종종 컨텍스트 없이, 400개의 다른 문자열과 함께 배치로 번역되며, 처음에 오역되는 경우가 많습니다.

지속적 현지화가 모든 문자열이 몇 시간 내에 번역되어 배포된다는 의미는 아닙니다. 머신 번역이 속도를 위해 그 간극을 메울 수 있으며, 인간 검토가 뒤따릅니다. 구조적으로 의미하는 바는, 파이프라인이 항상 실행 중이라는 것입니다: 새 문자열이 자동으로 유입되고, 번역가 대기열이 점진적으로 업데이트되며, 번역이 모든 핸드오프를 인간이 조율하지 않고도 코드베이스나 전달 레이어로 돌아갑니다.

배치 번역이 한계에 부딪히는 이유

배치 번역이 본질적으로 잘못된 것은 아닙니다 — 배포 빈도가 낮거나 소수의 문자열을 관리하는 프로젝트에서는 합리적인 방법입니다. 그러나 CI/CD 파이프라인에서 작업하는 엔지니어링 팀에게 배치 워크플로우는 네 가지 특정 실패 모드를 만들어냅니다.

릴리스 지연. 번역이 배포의 전제 조건이고, 번역이 피처 프리즈 후에 트리거되는 배치 작업이라면, 릴리스 일정은 번역가의 처리량에 의해 제한됩니다. 지속적으로 배포하는 팀은 5 영업일이 소요되는 현지화 단계를 수용할 수 없습니다. 릴리스는 번역된 문자열 없이 배포되거나(소스 언어인 영어로 기본값 설정) 기다려야 합니다 — 어느 쪽도 대규모에서 허용될 수 없습니다.

번역 오래됨. 배치 모델에서는 이미 진행된 코드베이스에서 문자열이 내보내지는 경우가 많습니다. 번역이 도착할 때쯤이면 문자열 자체가 변경되었을 수 있습니다 — 버튼 레이블이 수정되거나, 화면이 재설계되거나, 기능이 제거되었을 수 있습니다. 번역가는 구식 스냅샷으로 작업합니다. 결과적으로 번역이 실제 제품과 일치하지 않거나, 번역 작업을 폐기하고 다시 해야 합니다.

번역 파일에서의 머지 충돌. 여러 개발자가 병렬로 작업하고 번역 파일이 저장소에 있을 때(JSON, YAML, XLIFF 등), 해당 파일의 동시 변경은 머지 충돌을 유발합니다. 애플리케이션 로직의 충돌과 달리, 번역 파일 충돌은 해결하기 지루하고 오류가 발생하기 쉽습니다: 두 브랜치가 모두 새 키를 추가하고, 모두 키를 삭제하고, 모두 키를 다른 이름으로 변경한 경우가 있습니다. 배치가 클수록 충돌은 더 심해집니다.

개발자-번역가 마찰. 배치 워크플로우에서 개발자와 번역가 간의 핸드오프는 시간 압박 하에서 무너지는 관례에 의존하는 수동적이고 종종 비동기적인 프로세스입니다. 개발자는 내보내기를 잊습니다. 번역가는 컨텍스트 없이 파일을 받습니다. 내보내기와 가져오기 사이에 키가 이름이 변경됩니다. 가져오기가 번역가가 직접 수행한 변경사항을 덮어씁니다. 이러한 실패들은 개별적으로는 치명적이지 않지만 복합적으로 작용합니다. 시간이 지남에 따라 마찰로 인해 팀이 현지화 품질을 경시하게 되고, 기술 부채가 쌓이는 것과 마찬가지로 현지화 부채가 쌓입니다.

지속적 현지화 파이프라인

지속적 현지화 파이프라인은 문자열 변경 사항을 여섯 단계로 이동시킵니다. 파이프라인은 인간의 결정이 아닌 코드 변경에 의해 트리거됩니다. 각 단계는 다음 단계가 수동 개입 없이 소비할 수 있는 결정론적 출력을 생성합니다.

코드 변경
    |
    v
문자열 추출
    |
    v
번역 트리거
    |
    v
번역 (MT + 인간 검토)
    |
    v
저장소로 병합 (또는 CDN에 push)
    |
    v
배포 (또는 CDN 기반의 경우 OTA 업데이트)

1단계: 코드 변경. 개발자가 코드베이스에서 번역 가능한 문자열을 추가, 수정 또는 삭제합니다. 좋은 i18n 설정에서는 키-값 파일(JSON, YAML, XLIFF)을 업데이트하거나 런타임에 해석되는 코드에 키 참조를 추가하는 것을 의미합니다.

2단계: 문자열 추출. 파이프라인은 현재 상태를 이전 추출 스냅샷과 비교하여 어떤 문자열이 새로 추가되었거나 변경되었거나 삭제되었는지 식별합니다. 이는 일반적으로 현지화 도구의 CLI나 CI 스크립트에 의해 처리됩니다. 출력은 문자열 변경 사항의 diff입니다 — 모든 문자열의 전체 내보내기가 아닌, 변경된 부분만입니다. 차이 대신 매번 전체 내보내기를 수행하는 도구는 불필요한 번역가 작업을 만들고 새 문자열의 우선순위를 정하기 어렵게 만듭니다.

3단계: 번역 트리거. 새로운 문자열과 변경된 문자열이 번역 관리 시스템(TMS)에 전송됩니다. 이는 webhook(VCS 이벤트가 TMS에 대한 API 호출을 트리거), CI 단계(빌드 성공 후 CLI 명령이 문자열 diff를 push), 또는 파일 워처(개발 중, 로컬 에이전트가 파일 변경을 감시하고 지속적으로 동기화)를 통해 발생할 수 있습니다. 트리거는 자동이어야 합니다 — 이 단계를 시작하기 위해 인간이 필요하다면 배치 문제가 재도입됩니다.

4단계: 번역. 번역가(인간 또는 머신, 또는 조합)가 TMS에서 새 문자열에 대해 작업합니다. 잘 설계된 시스템은 번역가가 왔다 갔다 없이 정확한 번역을 생성할 수 있도록 스크린샷, 컴포넌트 컨텍스트, 문자 제한 및 인접한 문자열을 제공합니다. 머신 번역은 초안을 자동으로 생성할 수 있습니다; 인간 검토자는 정확성, 브랜드 음성, 컨텍스트에 민감한 수정에 집중합니다.

5단계: 병합. 완료된 번역은 거버넌스 모델에 따라 pull request로 저장소에 push되거나 번역 브랜치에 직접 커밋됩니다. OTA 가능 플랫폼의 경우, 이 단계는 번역된 문자열을 CDN 또는 API 엔드포인트에 push합니다 — 전달 경로를 위해 저장소를 완전히 우회합니다.

6단계: 배포. 파일 기반 전달의 경우, 번역은 다음 빌드에 번들링되어 애플리케이션과 함께 배포됩니다. CDN 기반 전달의 경우, 번역은 이미 엣지에서 라이브 상태입니다 — 애플리케이션은 새 배포 없이 다음 요청 시 이를 가져옵니다.

핵심 설계 원칙은 2단계에서 5단계까지는 머신 번역 콘텐츠에 대해 완전히 자동화되어야 하며, 인간 검토는 품질을 향상시키지만 전달을 차단하지 않는 선택적 레이어여야 한다는 것입니다. 인간 검토는 비동기적이어야 합니다: MT 번역을 먼저 게시하고, 검토된 번역이 준비되면 대체합니다.

통합 패턴

코드베이스를 번역 파이프라인에 연결하는 방식이 위의 내용이 실제로 얼마나 자동화될 수 있는지를 결정합니다. 네 가지 주요 통합 패턴이 있으며, 각각 다른 트레이드오프를 가집니다.

VCS webhook. 저장소 호스팅 플랫폼(GitHub, GitLab, Bitbucket)이 커밋 또는 pull request가 생성될 때 TMS에 HTTP 이벤트를 전송합니다. TMS는 페이로드를 파싱하고, 어떤 파일이 변경되었는지 식별하며, 새 문자열을 추출하고, 번역을 위해 대기열에 추가합니다. 이는 CI 파이프라인을 변경할 필요가 없으며, main에 병합되기 전의 브랜치에서도 작동합니다. 제한 사항은 TMS가 파일 형식과 프로젝트 구조를 이해해야 한다는 것입니다 — 구성은 TMS 측에서 수행되며, 코드베이스에서 수행되지 않습니다.

CI 단계 (CLI). CI 파이프라인에 TMS CLI를 실행하여 새 문자열을 push하고 선택적으로 번역된 문자열을 pull하는 단계가 포함됩니다. 이는 스크립트가 빌드 컨텍스트에 대한 전체 접근 권한을 가진 CI 환경에서 실행되기 때문에 가장 유연한 패턴입니다. GitHub Actions 마켓플레이스와 GitLab CI에는 대부분의 주요 TMS 플랫폼을 위한 공식 또는 커뮤니티 유지 관리 액션이 포함되어 있습니다. 트레이드오프는 CLI 버전, 시크릿으로서의 인증 자격 증명, 빌드 단계에 대한 push/pull 단계의 순서를 관리해야 한다는 것입니다.

파일 워처. 로컬 데몬이 번역 파일 디렉토리를 감시하고 코드를 작성할 때 실시간으로 TMS에 변경 사항을 동기화합니다. 이는 주로 개발자 경험 도구입니다: 번역가가 CI 실행을 기다리지 않고 개발자가 문자열을 추가한 후 수 초 내에 새 문자열을 볼 수 있습니다. 데몬이 실행 중인 개발자에 의존하고 팀 전체에 걸쳐 일관된 로컬 설정이 필요하기 때문에 프로덕션 파이프라인 메커니즘으로는 적합하지 않습니다.

OTA / CDN 전달. 번역된 문자열을 저장소에 커밋하고 배포 시 번들링하는 대신, 애플리케이션이 런타임에 CDN이나 API에서 번역을 가져옵니다. 번역 업데이트는 새 빌드나 배포 없이 즉시 전 세계적으로 사용 가능합니다. 이 패턴은 애플리케이션이 런타임 번역 로딩을 위해 설계되어야 합니다 — 대부분의 최신 i18n 라이브러리에서는 표준입니다 — 그리고 CDN에 대한 런타임 의존성을 도입합니다. UI 문자열에 대한 가장 운영상 민첩한 패턴입니다.

대부분의 프로덕션 설정은 패턴을 결합합니다: TMS와 코드베이스를 동기화하는 CI 단계(또는 webhook)와 새 배포가 필요 없는 문자열 업데이트를 위한 CDN 전달.

주목해야 할 핵심 기능

모든 현지화 플랫폼이 진정한 지속적 현지화를 지원하는 것은 아닙니다. 도구를 평가할 때, 플랫폼이 수동 번역 포털이 아닌 실제로 CI/CD 파이프라인에 통합될 수 있는지를 결정하는 기능들이 있습니다.

새로운 문자열과 변경된 문자열의 자동 감지. 플랫폼은 수동 내보내기 없이 파일 diff나 VCS 이벤트에서 자동으로 문자열 변경 사항을 식별해야 합니다. 변경 시마다 전체 파일을 내보내고 다시 가져오기를 요구하는 플랫폼은 지속적 워크플로우를 위해 설계되지 않은 것입니다.

번역가 컨텍스트. 개별 문자열을 단독으로 작업하는 번역가는 UI에서 문자열이 어디에 나타나는지 볼 수 있는 번역가보다 낮은 품질의 번역을 생성합니다. 최고의 플랫폼은 스크린샷, 컴포넌트 메타데이터, 또는 실제 제품에서 렌더링된 문자열을 보여주는 인컨텍스트 편집을 허용합니다. 컨텍스트 없이는 "저장", "보기", "취소"와 같은 짧은 문자열이 컨텍스트 없이는 모호하기 때문에 정기적으로 오역됩니다.

브랜칭 지원. 팀이 피처 브랜치를 사용한다면, 현지화 플랫폼은 VCS 브랜치를 미러링하는 번역 브랜치를 지원해야 합니다. 피처 브랜치의 문자열은 브랜치가 main에 병합되기 전에 번역 가능해야 합니다 — 그렇지 않으면 번역은 항상 최소 하나의 머지 사이클만큼 코드보다 뒤처지게 됩니다.

테스트를 위한 의사 현지화. 의사 현지화는 소스 문자열의 문자를 시각적으로 유사한 확장 라틴 문자로 대체하여 실제 번역 없이 번역된 텍스트를 시뮬레이션합니다. 이는 실제 번역이 가능하기 전에 개발 초기에 레이아웃 버그(텍스트 오버플로우, 잘린 레이블, 하드코딩된 너비 가정)를 발견합니다. 자동 의사 로케일 생성을 지원하는 플랫폼은 개발의 모든 시점에서 모든 로케일로 UI 테스트를 가능하게 합니다.

재배포 없는 OTA(Over-the-Air) 업데이트. 번역을 업데이트하기 위해 새 빌드를 배포하는 것이 너무 느리거나 비용이 많이 드는 애플리케이션(모바일 앱, 데스크톱 애플리케이션, 또는 빈도가 높은 웹 앱)의 경우 OTA 전달이 필수적입니다. 플랫폼은 낮은 지연 시간과 번역이 게시될 때 자동 캐시 무효화를 갖춘 전 세계적으로 분산된 엣지 캐시에서 번역을 제공해야 합니다.

번역 메모리 및 일관성 강제. 번역 메모리는 이전에 번역된 문자열을 프로젝트와 컨텍스트에 걸쳐 재사용하여 번역가 노력을 줄이고 일관성을 향상시킵니다. 일관성 강제는 이전에 번역된 용어와 일치하지만 다르게 번역된 문자열을 표시하여 대형 프로젝트에서 용어 변동을 잡아냅니다.

흔한 함정

지속적 현지화 파이프라인은 수동 워크플로우 문제와 구별되는 특정 실패 모드를 도입합니다. 가장 일반적인 것들입니다.

QA 레이어 없는 과도한 자동화. 완전 자동화된 머신 번역 파이프라인은 높은 속도로 번역을 배포할 수 있습니다. 또한 높은 속도로 잘못된 번역을 배포할 수도 있습니다. 인간 검토 없는 머신 번역은 내부 툴링과 위험도가 낮은 UI 문자열에 적합합니다. 고객을 대상으로 하는 마케팅 카피, 법적 공시, 오류 메시지, 또는 브랜드 음성을 반영하는 모든 것에 대해서는 인간 검토 단계가 선택 사항이 아닙니다. MT 번역이 즉시 폴백으로 게시되고, 인간이 검토한 번역이 비동기적으로 대체되도록 파이프라인을 설계하십시오 — 인간 검토에 게시를 차단하지 마십시오, 하지만 모든 콘텐츠에 대해 MT를 최종본으로 취급하지도 마십시오.

번역가를 위한 컨텍스트 무시. 컨텍스트의 핸드오프를 자동화하지 않고 문자열의 핸드오프를 자동화하면 낮은 품질의 번역을 생성하는 빠른 파이프라인이 됩니다. 스크린샷, 설명 또는 문자 제한 없이 checkout.button.primary와 같은 문자열 키는 번역가에게 거의 아무것도 알려주지 않습니다. 처음부터 파이프라인에 컨텍스트 전달을 구축하십시오 — 나중에 개선하는 것은 훨씬 어렵습니다.

키 이름 변경으로 번역 메모리 손상. 번역 메모리는 플랫폼에 따라 번역을 소스 문자열이나 문자열 키에 매핑합니다. 개발자가 키 이름을 변경할 때 — 예를 들어 user.save_button을 profile.save_changes로 변경 — TMS는 종종 이를 삭제된 키와 새롭고 번역되지 않은 키로 처리합니다. 해당 문자열에 대한 모든 이전 번역 작업이 TM에서 손실됩니다. 키 이름 변경 정책을 수립하십시오: 키 이름 변경을 더 이상 사용되지 않고 새로 생성하는 작업으로 처리하거나(번역이 확인될 때까지 이전 키 유지), 키 이름이 아닌 콘텐츠 해시를 사용하여 키 변경을 통해 문자열 정체성을 추적하는 TMS를 사용하십시오.

삭제된 키 처리 안 함. 소스에서 문자열이 제거되면, 대부분의 플랫폼은 TMS에 번역을 무기한으로 남겨둡니다. 시간이 지남에 따라 저장소를 낭비하고, 번역가를 혼란스럽게 하고, 번역 완성도 보고를 부정확하게 만드는 고아 번역이 생성됩니다. CI 스크립트나 TMS 자동화 규칙을 통해 소스에 더 이상 존재하지 않는 키에 대한 번역을 제거하는 정기적인 정리 사이클을 구현하십시오.

모든 로케일을 동일하게 취급. 다른 로케일은 번역가 가용성, 언어 쌍 복잡성, 검토 요구 사항에 따라 다른 번역 속도를 가집니다. 모든 로케일이 번역을 완료하는 것을 기다리며 배포를 차단하는 파이프라인은 가장 느린 로케일에 의해 자주 차단됩니다. 준비된 번역된 로케일과 함께 배포하고 준비되지 않은 로케일에는 소스 언어로 폴백하도록 파이프라인을 설계하십시오 — 로케일이 정의한 완성도 임계값 아래로 떨어지면 알림과 함께.

지속적 현지화를 지원하는 도구

다음은 엔지니어링 중심의 지속적 현지화 파이프라인에서 가장 일반적으로 사용되는 도구들입니다. 각각의 강점과 실제 제한 사항이 있습니다.

Crowdin CLI. Crowdin의 커맨드라인 클라이언트는 기본 통합과 webhook 지원을 통해 GitHub, GitLab, Bitbucket과 긴밀하게 통합됩니다. 브랜칭을 지원하고, 광범위한 파일 형식 라이브러리(JSON, YAML, XLIFF, Android XML, iOS Strings 등)를 갖추고 있으며, 강력한 번역 메모리를 제공합니다. CI 통합이 잘 문서화되어 있습니다. 제한 사항: 복잡한 모노레포의 경우 브랜칭 모델 구성이 혼란스러울 수 있으며, OTA 전달은 상위 플랜에서 사용 가능한 Crowdin OTA 기능이 필요합니다.

Transifex. Transifex는 CLI와 webhook를 통해 오랜 CI/CD 통합 지원을 갖추고 있습니다. 웹 기반 OTA 전달을 위한 "Live Translation"을 도입했습니다 — CDN에서 번역된 콘텐츠로 텍스트 노드를 가로채고 대체하는 JavaScript 스니펫입니다. 이 방식은 빌드 파이프라인을 쉽게 수정할 수 없는 팀에게 유용하며 애플리케이션 빌드 프로세스를 변경하지 않고도 작동합니다. Live 방식은 DOM 레벨에서 작동하기 때문에 성능 트레이드오프가 있습니다.

Lokalise CI. Lokalise는 강력한 GitHub Actions 및 GitLab CI 통합, 잘 설계된 번역 검토를 위한 기여자 워크플로우를 갖추고 있으며, iOS, Android, 웹용 SDK를 통해 OTA를 지원합니다. 브랜칭 지원이 대부분의 경쟁사보다 더 세련되어 있습니다. 웹 편집기는 스크린샷 기반 컨텍스트 지원이 뛰어납니다. Lokalise는 일반적으로 중간~엔터프라이즈 시장을 대상으로 하며 그에 맞는 가격을 책정하고 있습니다.

Phrase CLI (구 Phrase Strings). Phrase(구 Memsource 및 PhraseApp, 현재 통합 브랜드)는 포괄적인 CLI, 강력한 XLIFF 지원(전문 번역 에이전시와 함께 XLIFF 워크플로우를 선호하는 팀에게 유용), 성숙한 번역 메모리 및 품질 보증 기능을 갖추고 있습니다. 전문 번역 에이전시 워크플로우에서 특히 강합니다. CI 통합은 탄탄하지만 VCS 기본 자동화를 위해 Crowdin이나 Lokalise보다 더 많은 구성이 필요합니다.

Better i18n. Better i18n은 CLI, React/Next.js/Vue/Svelte SDK, Cloudflare의 엣지 네트워크를 통한 CDN 기반 전달을 갖춘 개발자 우선 방식을 취합니다. OTA 모델은 번역 업데이트가 게시 후 수 초 내에 전 세계적으로 사용 가능하다는 것을 의미합니다 — 새 빌드나 배포를 트리거하지 않고. AI 지원 초안 번역을 지원하며 코드베이스에 가까운 번역 관리를 원하는 엔지니어링 팀을 위해 설계되었습니다. CLI를 통한 CI 통합이 간단합니다. 2026년 초 기준으로, Crowdin, Lokalise, Phrase보다 초기 단계이며 XLIFF 워크플로우 및 엔터프라이즈 SSO와 같은 영역에서 더 좁은 기능 세트를 갖추고 있습니다.

FAQ

Q: 번역가가 기술적이지 않아도 지속적 현지화를 사용할 수 있습니까?

예. 파이프라인 자동화는 엔지니어링 측면에 있습니다. 번역가는 TMS 웹 인터페이스에서만 상호 작용하며, 여기서 번역 편집기의 문자열을 봅니다 — YAML 파일이나 Git 명령이 아닙니다. 자동화는 코드에서 문자열 추출, TMS로 전송, 번역을 코드베이스로 다시 병합하는 것을 처리합니다. 번역가 경험은 주로 파이프라인 메커니즘이 아닌 TMS 편집기의 품질과 제공하는 컨텍스트에 의해 결정됩니다.

Q: 아직 병합되지 않은 피처 브랜치는 어떻게 처리합니까?

대부분의 TMS 플랫폼은 VCS 브랜치를 미러링하는 번역 브랜치를 지원합니다. 브랜치 매핑을 구성합니다 — 예를 들어 feat/*과 일치하는 피처 브랜치가 해당 TMS 브랜치에 동기화됩니다. 번역가는 브랜치가 병합되기 전에 피처 브랜치의 문자열에 대해 작업할 수 있습니다. VCS에서 브랜치가 병합되면 TMS 브랜치도 병합되고 번역이 이어집니다. 이는 명시적으로 브랜칭을 지원하는 TMS가 필요합니다 — 모든 TMS가 지원하는 것은 아닙니다.

Q: 번역이 저장소에 있어야 합니까, TMS에 있어야 합니까?

이상적으로는 둘 다입니다. 저장소는 소스 문자열(개발자가 작성한 문자열)의 신뢰할 수 있는 소스입니다. TMS는 번역된 문자열의 신뢰할 수 있는 소스입니다. 파이프라인이 두 사이를 동기화합니다: 소스 문자열이 저장소에서 TMS로 흐르고, 번역된 문자열이 TMS에서 저장소로(또는 CDN으로) 돌아갑니다. TMS 없이 저장소에만 번역된 문자열을 저장하면 비개발자가 기여하기 어렵습니다. 저장소에 동기화하지 않고 TMS에만 저장하면 빌드를 결정론적으로 재현하기 어렵습니다.

Q: 현지화 파이프라인의 상태를 어떻게 측정합니까?

다음 네 가지 지표를 추적하십시오: 번역 커버리지(로케일별 번역이 있는 소스 문자열의 비율), 번역 지연(소스에 문자열이 추가된 시점과 첫 번역이 게시된 시점 사이의 시간), 검토 백로그(인간 검토를 기다리는 머신 번역 문자열의 수), 고아 키 비율(소스에 더 이상 존재하지 않는 키에 대한 TMS의 번역). 건강한 파이프라인은 높은 커버리지, 낮은 지연, 관리 가능한 검토 백로그, 거의 0에 가까운 고아 키 비율을 가집니다.

Q: 소규모 팀을 위한 최소한의 지속적 현지화 설정은 무엇입니까?

웹 제품을 배포하는 2~5명의 엔지니어 팀: main에 병합될 때마다 TMS CLI를 실행하여 새 소스 문자열을 push하는 단일 CI 단계, 초안용으로 활성화된 머신 번역, 가장 고객을 대상으로 하는 문자열에 대한 주간 번역가 검토 세션. 이것만으로도 릴리스를 차단하는 배치 번역과 대부분의 머지 충돌을 제거합니다. OTA 전달과 브랜칭 지원은 제품과 번역가 워크플로우가 성숙함에 따라 나중에 추가할 수 있습니다.

결론

지속적 현지화는 제품의 번역 레이어에 CI/CD 사고를 논리적으로 확장한 것입니다. 핵심 통찰은 번역이 릴리스 마일스톤이 아닌 파이프라인 단계라는 것입니다. 문자열이 일반적인 개발 흐름의 일부로 자동으로 추출되고, 번역가에게 전달되고, 검토되고, 병합될 때, 배치 워크플로우에서 현지화를 고통스럽게 만드는 비용들 — 릴리스 지연, 오래된 번역, 머지 충돌, 개발자-번역가 마찰 — 은 엔지니어링 솔루션이 있는 엔지니어링 문제로 줄어듭니다.

이 글에서 설명한 파이프라인은 가상이 아닙니다. 수십 개의 로케일에 배포하는 회사의 팀들이 프로덕션에서 그 변형들을 실행하고 있습니다. 구체적인 사항은 다양합니다 — 어떤 TMS, 어떤 CI 시스템, OTA 전달이 범위에 포함되는지, 인간 검토가 얼마나 필요한지 — 하지만 구조는 일관됩니다: 기계적인 작업을 자동화하고, 인간적인 작업에 컨텍스트를 제공하고, 번역 완성도를 이진 릴리스 게이트가 아닌 지속적인 지표로 취급합니다.

팀에게 가장 마찰이 적은 변경부터 시작하십시오: main 브랜치 병합 시마다 TMS에 새 문자열을 push하는 CI 단계. 거기서부터 브랜칭 지원, 컨텍스트 전달, OTA 업데이트, 자동화된 품질 검사를 점진적으로 추가하십시오. 각 레이어는 전체 파이프라인 재구축 없이 마찰을 줄이고 품질을 향상시킵니다.

목표는 개발자에게 보이지 않는 현지화 워크플로우입니다 — 새 로케일에 배포하는 것이 프로젝트가 아닌 구성 변경인 워크플로우.

참고 문헌

[^1]: Martin Fowler, "Continuous Integration," martinfowler.com, https://martinfowler.com/articles/continuousIntegration.html

[^2]: W3C Internationalization Working Group, "Internationalization Best Practices for Spec Developers," W3C Working Group Note, https://www.w3.org/TR/international-specs/

[^3]: OASIS XLIFF Technical Committee, "XLIFF Version 2.1," OASIS Standard, https://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html

[^4]: GitHub Actions documentation, "Events that trigger workflows," https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

[^5]: GitLab CI/CD documentation, "GitLab CI/CD pipeline configuration reference," https://docs.gitlab.com/ee/ci/yaml/

[^6]: Unicode CLDR Project, "Unicode Common Locale Data Repository," https://cldr.unicode.org/

[^7]: IETF BCP 47, "Tags for Identifying Languages," https://www.rfc-editor.org/rfc/rfc5646

[^8]: Crowdin documentation, "CLI tool," https://developer.crowdin.com/cli-tool/

[^9]: Lokalise documentation, "CI/CD integrations," https://lokalise.com/blog/continuous-localization/

[^10]: Phrase documentation, "Phrase Strings CLI," https://support.phrase.com/hc/en-us/articles/5784095916188

최종 업데이트: 2026년 3월