String Catalog 다국어 테스트: 2026 원격 맥은 어떻게 자동화할까?

String Catalog 다국어 테스트는 번역 상태를 확인하는 작업만 뜻하지 않습니다. Apple은 String Catalog에서 언어, 번역, 복수형, 기기 변형을 관리할 수 있다고 설명합니다. 따라서 편집기에서 상태가 완료로 보이는지, 앱 실행 중 올바른 문자열이 나타나는지, 최종 빌드에 언어 리소스가 들어갔는지를 서로 다른 증거로 다뤄야 합니다.

먼저 로그인, 구매, 핵심 제작 화면처럼 실제 사용 빈도가 높은 경로를 선정합니다. 모든 화면을 처음부터 자동화하면 번역 변경 때마다 유지 비용이 커지고, 정작 출시를 막는 문제를 찾기 어려워집니다. 선정한 경로마다 다음 네 가지 합격 기준을 기록합니다.

• 문자열이 지원되는 방식으로 추출되어야 합니다.
• 복수형과 삽입 변수가 실제 문맥에 맞아야 합니다.
• 언어와 지역을 바꿔도 화면의 핵심 동작이 완료되어야 합니다.
• Archive 또는 앱 번들에 필요한 언어 리소스가 포함되어야 합니다.

Apple의 String Catalog 공식 설명은 변형 문자열과 복수형을 확인할 때 기준 문서로 사용할 수 있습니다. 다만 편집기의 초록색 상태를 배포 성공의 증거로 간주해서는 안 됩니다.

SwiftUI 프로젝트에서는 화면에 보이는 텍스트가 모두 같은 방식으로 추출된다고 가정하면 안 됩니다. Apple은 SwiftUI 코드와 다른 코드에서 번역 대상 문자열을 준비하는 규칙을 따로 설명합니다. 문자열 리터럴을 현지화 가능한 API에 전달했는지, 동적으로 조합한 문장이 카탈로그에 정상적으로 나타나는지 확인해야 합니다.

SwiftUI와 코드의 문자열 추출 규칙을 기준으로 최소 검증 샘플을 만듭니다. 샘플에는 다음 항목을 포함합니다.

• 일반 문장과 버튼 이름
• 복수형이 달라지는 항목 수
• 사용자 이름이나 상품명 같은 삽입 변수
• 길이가 긴 번역문
• 지원하지 않는 지역에서 사용할 대체 언어

Preview만으로는 충분하지 않습니다. Preview는 특정 화면의 모양을 빠르게 확인하는 데 유용하지만, 실제 앱 실행 환경에서 언어와 지역이 바뀔 때 발생하는 데이터 흐름과 화면 전환까지 대신 검증하지는 않습니다. 따라서 짧은 UI 테스트를 만들어 핵심 경로를 실행하고, 번역문이 바뀐 뒤에도 버튼 식별자와 접근성 라벨이 유지되는지 확인해야 합니다.

String Catalog에서 누락된 현지화 문자열을 찾으려면 카탈로그의 항목 수만 세지 말고, 소스 코드의 추출 결과와 핵심 화면의 실행 결과를 함께 비교해야 합니다. 새 화면을 추가한 뒤 카탈로그에 항목이 생겼는지, 사용하지 않는 항목만 남아 있지는 않은지, 변수 이름이 번역문과 호환되는지를 별도 검사 대상으로 둡니다.

UIKit 기반 앱이나 혼합 프로젝트에서는 리소스가 한곳에만 존재하지 않을 수 있습니다. String Catalog, strings, stringsdict, Storyboard, XIB, Info.plist 문자열은 서로 다른 경로에서 빌드에 들어갈 수 있습니다. 기존 파일을 모두 한 번에 바꾸기보다 기능 단위로 나누어 이동하고, 이전 리소스를 제거한 뒤에도 실제 화면이 유지되는지 확인해야 합니다.

특히 다음 Target을 분리해서 확인합니다.

• 앱 본체
• 위젯이나 공유 확장
• 프레임워크
• 테스트 대상

각 Target의 번역 파일이 어느 Bundle에 포함되는지 확인해야 합니다. 편집기에서 항목이 보이는 것보다 빌드 결과와 실행 화면이 더 강한 증거입니다. 테스트가 통과했더라도 확장 화면에서만 기본 언어가 나타날 수 있으므로, 핵심 확장 기능은 별도의 실행 경로로 검사합니다.

기존 프로젝트의 마이그레이션 여부를 결정할 때는 다음 조건을 적용합니다.

• 새 기능과 변경이 잦은 화면이면 String Catalog 중심으로 옮깁니다.
• 오래된 화면이 안정적으로 동작하고 변경이 적으면 기존 리소스를 유지하면서 연결 상태를 검사합니다.
• 여러 Target에서 같은 키를 공유한다면 먼저 Bundle 소유권을 확인한 뒤 이동합니다.
• 자동 추출 결과가 기존 번역 키와 충돌하면 원인을 기록하고, 일괄 삭제보다 단계적 회귀 검사를 우선합니다.

이 방식은 형식을 통일하기 위해 안정적인 리소스를 한 번에 교체하는 위험을 줄입니다. String Catalog 마이그레이션은 파일 확장자를 바꾸는 작업이 아니라, 추출과 실행과 배포 결과를 다시 맞추는 작업입니다.

iOS 앱의 다른 언어와 지역을 일괄 테스트할 때 모든 조합을 기계적으로 만들 필요는 없습니다. 실제 출시 언어, 주요 판매 지역, 문자 방향, 핵심 기기 크기를 기준으로 대표 조합을 선택합니다. 언어와 지역은 같은 값이 아니므로 Application Language와 Application Region을 따로 설정해야 합니다.

Test Plan으로 테스트를 구성하는 Apple 문서는 테스트 설정을 분리하고 반복 실행하는 기준을 제공합니다. 앱 실행 중 현지화를 테스트하는 문서는 실행 환경에서 언어와 지역을 바꾸어 확인하는 절차를 설명합니다.

지역 매트릭스에서는 다음 변화를 확인합니다.

• 날짜와 시간 표시
• 통화와 숫자 구분
• 복수형 규칙
• 오른쪽에서 왼쪽으로 쓰는 화면 배치
• 긴 단어가 버튼과 목록에서 잘리는지 여부
• 대체 언어로 전환될 때 의미가 바뀌지 않는지 여부

현지화 화면 캡처는 번역 검수와 회귀 증거로 사용합니다. Apple의 현지화 담당자용 화면 캡처 안내는 이 목적의 캡처 흐름을 설명하지만, 테스트용 캡처를 App Store 홍보 이미지와 같은 것으로 취급해서는 안 됩니다.

String Catalog 다국어 테스트를 지속적 통합에 넣을 때는 하나의 거대한 작업으로 묶지 않는 편이 안전합니다. 문자열 추출, 지정 언어 테스트, UI 테스트, 결과 보관을 별도 작업으로 나누면 어느 단계에서 실패했는지 바로 확인할 수 있습니다.

권장 흐름은 다음과 같습니다.

1. 저장소를 깨끗한 상태로 준비하고 필요한 의존성을 복원합니다.
2. 지정된 Scheme과 Test Plan으로 문자열 추출 또는 빌드 검사를 실행합니다.
3. 대표 언어와 지역 조합을 사용해 UI 테스트를 실행합니다.
4. 테스트 결과 파일과 환경 정보를 보관합니다.
5. 화면 캡처와 Archive의 언어 리소스를 확인합니다.
6. 실패 원인을 번역 누락, 화면 문제, 빌드 리소스 문제, 실행 환경 문제로 분류합니다.

xcodebuild를 사용하는 자동화에서는 명령 자체보다 실행 조건을 함께 저장해야 합니다. Scheme, Test Plan, 대상 기기, Application Language, Application Region이 달라지면 같은 코드도 다른 결과를 낼 수 있습니다. 테스트 결과 파일은 다음 회귀에서 비교할 수 있도록 보존합니다.

현지화 자료를 외부 번역 과정과 주고받는 프로젝트라면 Apple의 현지화 내보내기 안내와 현지화 가져오기 안내를 기준으로 파일 흐름을 고정합니다. 가져온 파일이 카탈로그에 반영되었는지와 실제 앱 화면에 나타나는지는 별도 단계로 검사해야 합니다.

원격 맥에서는 그래픽 로그인 세션이 필요한 UI 테스트와 SSH만으로 실행할 수 있는 추출 작업을 구분해야 합니다. SSH 연결이 끊겨도 작업이 계속되는지, 호스트가 다시 시작된 뒤 결과 파일이 남는지, 같은 커밋을 다시 실행했을 때 같은 증거가 생성되는지 확인한 뒤 제출 검사나 정기 작업으로 승격합니다.

원격 맥에서 iOS 자동화 테스트 서버를 구성하는 방법을 먼저 정리하려면 원격 맥 테스트 서버 구성 안내를 함께 확인할 수 있습니다. Xcode와 시뮬레이터를 보관할 환경을 검토할 때는 NUKCLOUD 원격 맥 환경에서 접속 방식과 운영 조건을 확인하는 것이 좋습니다.

다음 조건에 따라 자동화 범위를 결정하면 불필요한 전체 조합 실행을 줄일 수 있습니다.

• 지원 언어가 적고 화면 변경이 잦지 않다면 대표 언어와 핵심 경로부터 실행하고, 전체 언어는 Archive 단계에서 리소스를 확인합니다.
• SwiftUI 새 화면이 빠르게 늘어난다면 문자열 추출 검사와 짧은 UI 테스트를 커밋 검사에 둡니다.
• UIKit과 혼합 Target이 함께 있다면 앱 본체와 확장 Bundle을 분리해 검사하고, 안정된 리소스는 단계적으로 이전합니다.
• 지역별 날짜와 통화가 중요하다면 언어 테스트와 지역 테스트를 같은 테스트로 합치지 않고 Test Plan 설정을 분리합니다.
• 상시 보유한 맥이 있다면 로컬에서 빠른 개발자 피드백을 유지하고, 원격 맥은 정기 회귀와 출시 후보 검수에 사용합니다.
• 상시 보유한 맥이 없다면 원격 맥에 Xcode, 시뮬레이터, Test Plan, 결과 보관 경로를 고정한 뒤 반복 실행 환경으로 선택합니다.
• SSH에서만 실행할 예정이라면 그래픽 세션이 필요한 UI 테스트를 먼저 검증하고, 실패하면 대화형 세션이나 별도 실행 방식으로 되돌립니다.

마지막 판정은 세 단계로 나눕니다.

• 번역 누락이나 잘못된 변수는 수정 후 다시 실행합니다.
• 텍스트 잘림과 지역 형식 오류는 출시 차단 문제로 분류합니다.
• 호스트 재시작, 세션 종료, 결과 보관 실패는 테스트 인프라 문제로 분리합니다.

이렇게 해야 번역 담당자의 수정이 필요한지, 개발자가 화면을 고쳐야 하는지, 원격 실행 환경을 복구해야 하는지 혼동하지 않습니다.

현재 로컬 맥만 사용하면 장비를 계속 켜 두어야 하고, Xcode와 시뮬레이터 저장 공간을 따로 확보해야 하며, 출장이나 장비 교체 중에는 예약된 회귀 작업이 멈출 수 있습니다. 반대로 원격 맥은 네트워크와 그래픽 세션을 확인해야 하고, 물리 기기 연결처럼 원격 환경에 맞지 않는 작업도 있습니다. 다만 다국어 UI 테스트와 결과 보관을 반복해야 하는 독립 개발자라면, 전용 맥을 바로 구매하기보다 NUKCLOUD에서 필요한 기간 동안 원격 맥을 유지하는 방식이 더 유연할 수 있습니다.

필요한 것은 단순한 번역 완료 표시가 아니라, 문자열이 추출되고 화면에서 작동하며 최종 앱에 포함되었다는 재현 가능한 증거입니다. 먼저 언어와 지역 매트릭스를 작게 고정한 뒤 원격 맥에서 Test Plan, UI 테스트, 화면 캡처, Archive 검사를 순서대로 실행하면 출시 전 판단을 반복 가능한 절차로 바꿀 수 있습니다.