번역은 서버 측에서 실행되므로, 규모가 커질수록 신경 써야 할 대부분은 여러분이 아니라 엔진의 영역입니다. lingo push가 작업을 제출하면 엔진이 처리하므로 워커 풀이나 동시성을 따로 설정할 필요가 없습니다. 여러분이 직접 제어하는 건 한 번에 얼마나 푸시할지와 문제가 생겼을 때 어떻게 복구할지입니다.
변경된 것만 푸시하세요#
기본 lingo push는 모든 소스를 lockfile과 해시 비교해 변경된 항목만 제출합니다. 대규모 리포지토리에서는 이 방식이 가장 효율적입니다 — 변경되지 않은 코퍼스는 서버와 통신조차 하지 않는 no-op으로 끝납니다. 변경분만 처리하게 두고, 전면적인 --force는 피하세요.
큰 변경은 범위를 좁히세요#
재번역이 꼭 필요하다면 전체 프로젝트 대신 특정 하위 트리로 범위를 제한하세요:
lingo push 'content/en/marketing/**/*.md' --force이렇게 하면 대규모 실행도 범위가 명확해지고 결과를 예측하기 쉬워집니다. 재번역을 참고하세요.
대규모 실행 전에는 먼저 추정하세요#
큰 실행은 진행하기 전에 먼저 비용을 산정하세요:
lingo push --backfill-missing --estimate예상 비용을 출력한 뒤 종료합니다. 첫 전체 번역을 실행하기 전이나, 많은 로캘에 걸쳐 모델을 전환하기 전에 특히 유용합니다.
실행이 끝날 때까지 기다릴 필요는 없습니다#
대규모 실행이라고 해서 명령이 끝날 때까지 붙잡고 있을 필요는 없습니다. push는 실행 정보를 run state에 기록하므로, 결과는 나중에 받거나 CI에서 수집할 수 있습니다:
# kick it off
lingo push --backfill-missing
# later, or in CI
lingo pull다시 시작하지 말고 이어서 복구하세요#
대규모 실행이 중간에 실패하더라도 전체를 다시 푸시할 필요는 없습니다 — lingo resume가 추가 비용 없이 캐시된 결과를 다시 내보내고, 이어서 --backfill-missing가 비어 있는 부분을 채웁니다.
자동화하세요#
대규모 프로젝트를 항상 최신 상태로 유지하려면, 병합 시 CI가 번역을 실행하고 결과를 담은 PR을 열도록 구성하세요. CI/CD를 참고하세요.
레거시 CLI를 쓰셨나요?
레거시 CLI는 사용자 환경에서 번역을 수행했기 때문에 클라이언트 측 동시성(워커 풀, 병렬 플래그)을 직접 노출했습니다. 현재 CLI는 서버 측에서 번역하므로 그런 설정은 사라졌고, 규모 확장은 알아서 처리됩니다. 이제 중요한 레버는 범위 지정, 백필, 재개입니다.
