iOS 빌드 머신을 바꿀 때 어떤 파일을 먼저 복사해야 하나요?

소스 코드만 복사하지 말고 하위 모듈, 의존성 잠금 파일, 빌드 스크립트, 필요한 환경 설정, 보관 파일과 디버그 기호를 함께 분류해야 합니다. 다시 받을 수 있는 캐시와 다시 만들 수 없는 개인 키를 구분한 뒤, 깨끗한 복제본에서 의존성 설치와 보관 빌드를 직접 검증해야 합니다.

원격 맥을 반납하기 전에 서명 인증서와 개인 키를 어떻게 보관하나요?

인증서 파일만 내보내면 서명 신원이 완성되지 않습니다. Keychain에서 연결된 개인 키를 포함한 PKCS #12 신원을 보호된 위치로 내보내고, 새 환경에서 제한된 접근 권한으로 가져온 뒤 실제 배포용 보관 빌드를 검증해야 합니다. 내보내기와 폐기 전에는 영향 범위와 복구 방법을 기록해야 합니다.

xcarchive와 dSYM은 오래 보관해야 하나요?

공개된 버전의 장애를 분석하거나 같은 빌드를 다시 확인해야 한다면 두 산출물을 장기 보관하는 편이 안전합니다. IPA만 남기면 디버그 기호가 없어 충돌 로그를 읽기 어려울 수 있습니다. 보관 파일, dSYM, 빌드 번호, 버전, UUID의 연결 관계를 기록하고 실제로 열거나 내보내 백업 상태를 확인해야 합니다.

자체 호스팅 Runner를 새 맥으로 옮긴 뒤 어떻게 복구하나요?

새 맥에서 별도 태그와 격리된 검증 작업으로 Runner를 먼저 등록합니다. 저장소 권한, 호스트 로그인 권한, 서명 신원, App Store Connect API 자격 증명을 서로 나누어 점검한 뒤 새 Runner가 보관과 업로드를 완료하는지 확인합니다. 그 다음 기존 Runner의 수신을 중지하고 공식 제거 절차를 진행해야 합니다.

오래된 빌드 머신은 언제 안전하게 정리할 수 있나요?

새 환경에서 기존 맥의 경로와 캐시에 의존하지 않는 깨끗한 복제, 실제 Archive, 목표 배포 방식에 맞는 서명, 업로드 또는 검증, 단절 복구 테스트를 모두 통과한 뒤에만 정리할 수 있습니다. 이후에는 기존 Runner를 제거하고 임시 자격 증명을 폐기하거나 교체하며, 공유 폴더와 셸 기록의 민감한 파일도 확인해야 합니다.

iOS 빌드 머신 이전에 무엇을 백업할까? 2026 Xcode 27 체크리스트

빌드가 새 맥에서 끝났는데 Archive 단계에서 서명 오류가 나고, 이전 맥을 끌 수 없는 상태라면 파일을 덜 옮긴 것입니다.

가장 빠른 해결책은 Xcode 27 iOS 빌드 머신 이전을 파일 복사가 아니라 복구성 검증으로 진행하는 것입니다. 소스, 도구 체계, 서명 신원, 배포 자격 증명, 산출물, 자동화 실행기를 각각 확인하고 새 환경에서 실제 Archive와 업로드를 끝낸 뒤에만 기존 맥을 정리해야 합니다.

판정상 승자는 새 환경에서 독립적으로 다음 배포를 완료할 수 있는 이전 방식입니다. 단순히 프로젝트 폴더만 옮겨도 되는 경우는 서명과 자동화 자산이 외부에서 완전히 재발급되고, 과거 산출물이 별도 저장소에 검증된 경우뿐입니다.

이 글을 읽어야 하는 개발자

원격 맥을 반납하거나 교체하려는 독립 개발자에게 적합합니다. 특히 새 맥에서 Xcode 27 빌드 작업을 이어받아야 하는 CI 유지 담당자, 외주 프로젝트의 배포 환경을 인수하는 소규모 팀이 대상입니다.

마지막 성공 배포의 버전, 빌드 번호, Scheme, 빌드 구성, 사용한 Xcode 경로를 먼저 기록해야 합니다. 이 기록이 없으면 새 환경의 성공이 이전 환경과 같은 결과인지 판단하기 어렵습니다.

프로젝트 복제와 재현 가능한 입력은 다릅니다

소스 저장소가 복제되었다는 사실만으로 빌드 입력이 완성되지는 않습니다. 다음 항목을 먼저 분류해야 합니다.

소스 코드와 하위 모듈
의존성 잠금 파일과 패키지 매니페스트
비공개 저장소에 접근하는 방식
빌드 스크립트와 배포 스크립트
버전 관리에 포함되지 않은 필수 설정
Scheme, 빌드 구성, Bundle ID와 환경별 값
Xcode 27의 설치 경로와 명령줄 도구 경로

의존성을 다시 받을 수 있는지와 개인 키처럼 다시 만들 수 없는지를 나누어 기록합니다. DerivedData는 편리한 캐시일 뿐, 환경 재현의 증거가 아닙니다. 이를 통째로 복사해 성공한 것처럼 판단하면 새 맥에서 깨끗한 빌드가 실패할 수 있습니다.

새 작업 폴더에서 다음과 같이 검증합니다.

git clone <REPOSITORY_URL> clean-checkout
cd clean-checkout
git submodule update --init --recursive
xcodebuild -resolvePackageDependencies \
  -workspace <WORKSPACE>.xcworkspace \
  -scheme <SCHEME>

예상 결과에는 잠금 파일에 맞는 의존성 해석과 오류 없는 완료 상태가 포함되어야 합니다.

Resolved source packages
Command succeeded

프로젝트의 실제 저장소 주소와 계정 이름은 로그에 남기지 않습니다. 외부 저장소 권한이 필요한 경우 새 맥에서 토큰이나 SSH 키를 별도로 등록하고, 저장소에 직접 기록하지 않아야 합니다.

Xcode 27의 시스템 요구 사항과 지원 범위는 설치 전에 공식 시스템 요구 사항 문서에서 확인합니다. 향후 시험판이나 미확정 변경 사항은 이전 기준으로 사용하지 않습니다.

도구 체계와 서명 신원은 별도 지표로 확인합니다

Xcode 경로가 맞아도 서명 신원이 없으면 배포용 Archive를 만들 수 없습니다. 반대로 인증서가 보여도 연결된 개인 키가 없으면 실제 서명에 실패합니다.

도구 체계의 통과 기준

새 환경에서 다음 기록을 남깁니다.

xcode-select -p
xcodebuild -version
xcodebuild -showsdks
security find-identity -v -p codesigning

출력에는 실제 사용 중인 Xcode 경로, Xcode 버전, 필요한 SDK, 유효한 코드 서명 신원이 나타나야 합니다. 출력 전체를 공개 저장소에 올리면 안 됩니다. Team ID와 인증서 이름은 <TEAM_ID>, <DISTRIBUTION_IDENTITY> 같은 표기로 바꿉니다.

인증서와 개인 키의 통과 기준

Apple Distribution 인증서는 공개 인증서만으로 충분하지 않습니다. 연결된 개인 키까지 포함된 신원이 필요합니다. Apple의 신원 가져오기와 PKCS #12 안내는 이 과정을 설명합니다.

인증서와 개인 키를 내보낼 때는 다음 순서를 지킵니다.

현재 Keychain에서 배포 인증서와 연결된 개인 키를 확인합니다.
보호된 위치로 개인 키 포함 신원을 내보냅니다.
백업 파일의 접근 권한과 보관 책임자를 기록합니다.
새 맥의 별도 Keychain에 가져옵니다.
실제 배포용 Archive에서 서명을 검증합니다.
실패하면 기존 신원을 삭제하거나 폐기하지 않고 원인을 먼저 확인합니다.

Provisioning Profile은 인증서와 다른 자산입니다. 새 환경에 필요한 프로파일을 다시 내려받거나 자동 서명 상태를 점검해야 합니다. 프로파일을 삭제하거나 교체하기 전에는 어떤 Bundle ID와 배포 방식에 영향을 주는지 기록해야 하며, 관리 규칙은 공식 프로파일 관리 문서를 기준으로 합니다.

인증서가 Keychain에 보이는 것만으로는 통과가 아닙니다. 기준은 목표 배포 방식과 일치하는 Archive가 생성되고, 새 환경이 그 Archive에 서명할 수 있는지입니다.

보관 산출물은 다시 만들 수 있는 것과 나눠 보관합니다

캐시와 배포 기록을 같은 백업 폴더에 넣으면 우선순위가 흐려집니다. 산출물은 복구 가치에 따라 나눕니다.

xcarchive: 특정 빌드의 보관 결과와 서명 검증에 필요한 핵심 산출물
dSYM: 배포된 앱의 충돌 로그를 사람이 읽을 수 있도록 하는 디버그 기호
xcresult: 테스트와 빌드 결과를 확인할 수 있는 기록
IPA: 실제 배포 파일
Export 옵션과 배포 설정
버전, 빌드 번호, Archive UUID, 릴리스 기록
DerivedData, 중간 오브젝트, 임시 다운로드 캐시

IPA만 보관하면 나중에 충돌 로그를 해석할 때 필요한 dSYM이 없을 수 있습니다. Apple의 dSYM 확인 안내는 Archive와 기호 파일의 대응 관계를 확인하는 기준을 제공합니다.

백업 파일은 존재 여부만 검사하지 않습니다. 복사본을 새 경로에 열어 보고, Archive에서 내보내기 작업을 수행하며, UUID와 빌드 번호가 출시 기록과 맞는지 확인합니다.

find <ARCHIVE_BACKUP_PATH> -maxdepth 2 -type f
dwarfdump --uuid <DSYM_PATH>

예상 결과는 백업된 dSYM의 UUID가 해당 Archive와 연결되는 것입니다.

UUID: <ARCHIVE_UUID> (<ARCHIVE_NAME>)

백업된 파일의 경로와 실제 파일명에는 프로젝트명, Bundle ID, 팀 식별자 같은 민감 정보가 그대로 남을 수 있습니다. 공유 저장소에 올리기 전 이름을 가리고 접근 권한을 제한합니다.

자동화 실행기는 접수 중지와 인수 완료를 분리합니다

자체 호스팅 Runner를 새 맥에 설치할 때 기존 Runner를 먼저 삭제하면 작업 공백이 생깁니다. 반대로 두 Runner를 오랫동안 같은 작업에 연결하면 중복 실행과 이중 업로드가 발생할 수 있습니다.

새 환경에서는 먼저 격리된 검증 작업을 실행합니다. 저장소 권한, 호스트 로그인 권한, 서명 개인 키, App Store Connect API 자격 증명을 하나의 비밀 값으로 취급하지 않는 것이 핵심입니다.

App Store Connect API Key는 파일만 복사하는 방식으로 관리하지 않습니다. Key ID, Issuer ID, 개인 키 파일의 보관 위치와 사용 주체를 분리해 기록하고, 공식 API 키 관리 안내를 기준으로 새 환경에서 업로드를 검증합니다.

검증용 작업에서는 다음 값을 모두 가상 표기로 바꿉니다.

<REPOSITORY>
<RUNNER_LABEL>
<TEAM_ID>
<KEY_ID>
<APP_IDENTIFIER>
<LOG_PATH>

실제 순서는 다음과 같습니다.

새 맥에 Runner를 등록합니다.
새 태그로 제한된 테스트 작업을 실행합니다.
의존성 설치와 Archive 생성을 검증합니다.
서명과 업로드 또는 검증 작업을 실행합니다.
새 Runner가 정상 수신하는지 확인합니다.
기존 Runner의 새 작업 수신을 중지합니다.
기존 Runner를 공식 절차에 따라 제거합니다.
토큰과 임시 자격 증명을 폐기하거나 교체합니다.

Runner 제거 절차는 자동화 플랫폼의 자체 호스팅 Runner 제거 문서를 따릅니다. 기존 호스트가 오프라인이어도 관리 화면에 남은 실행기와 등록 토큰을 별도로 확인해야 합니다.

독립 FAQ

iOS 빌드 머신을 바꿀 때 어떤 파일을 복사해야 하나요?

소스와 하위 모듈, 의존성 잠금 파일, 빌드 스크립트, 필수 설정을 먼저 분류합니다. 그 다음 xcarchive, dSYM, 테스트 결과와 배포 기록을 별도로 보관합니다. 인증서 파일은 개인 키와 함께 검증하고, 캐시를 복사한 결과를 깨끗한 복제본의 성공으로 간주하지 않습니다.

원격 맥 반납 전에 서명 인증서와 개인 키를 어떻게 백업하나요?

Keychain에서 Apple Distribution 인증서와 연결된 개인 키를 함께 확인합니다. 개인 키를 포함한 PKCS #12 신원을 보호된 위치로 내보낸 뒤 새 원격 맥에서 가져옵니다. 새 환경의 실제 Archive 서명까지 성공하기 전에는 기존 인증서를 폐기하거나 호스트를 반납하지 않는 편이 안전합니다.

xcarchive와 dSYM을 오래 보관해야 하나요?

공개 버전의 충돌 분석, 과거 빌드 확인, 재배포 가능성을 고려하면 함께 보관해야 합니다. IPA만 남기면 dSYM이 없어 충돌 로그를 해석하기 어려울 수 있습니다. Archive UUID, 버전, 빌드 번호를 연결하고 실제로 열거나 내보내 백업이 손상되지 않았는지 확인합니다.

자체 호스팅 Runner를 새 맥으로 옮긴 뒤 무엇을 먼저 하나요?

새 Runner를 먼저 등록하되 별도 태그와 제한된 검증 작업만 허용합니다. 의존성 설치, Archive, 서명, 업로드를 순서대로 확인한 뒤 기존 Runner의 작업 수신을 중지합니다. 마지막으로 등록 정보와 토큰을 제거해야 두 호스트가 같은 배포 작업을 동시에 처리하지 않습니다.

오래된 빌드 머신은 언제 정리할 수 있나요?

새 맥이 기존 경로와 캐시에 의존하지 않고 깨끗한 복제, 실제 Archive, 서명, 업로드 또는 검증을 완료한 뒤에 정리합니다. 기존 맥을 끊은 상태에서 핵심 작업을 다시 실행하는 복구 시험도 필요합니다. Runner 제거, 자격 증명 교체, 공유 폴더와 셸 기록 점검까지 끝나야 반납 조건을 충족합니다.

새 맥에서 실제 배포까지 검증합니다

Xcode의 Archive와 분배 과정은 Apple의 공식 Archive 및 배포 안내를 기준으로 확인합니다. 성공 기준은 단순한 빌드 완료가 아닙니다.

다음 명령은 프로젝트의 실제 값으로 바꾸어 실행합니다.

xcodebuild archive \
  -workspace <WORKSPACE>.xcworkspace \
  -scheme <SCHEME> \
  -configuration <CONFIGURATION> \
  -archivePath <ARCHIVE_PATH>

이후 확인할 항목은 다음과 같습니다.

새 환경에서 의존성이 깨끗하게 해석되는가
지정한 Scheme과 빌드 구성이 동일한가
Archive가 생성되고 열리는가
Apple Distribution 서명과 프로파일이 목표 배포 방식에 맞는가
dSYM과 xcresult가 예상 위치에 생성되는가
App Store Connect 업로드 또는 검증이 완료되는가
기존 맥을 끊은 뒤에도 자동화 작업이 실행되는가

실제 업로드가 부담스러운 경우에도 최소한 새 환경에서 목표 분배 방식에 맞는 검증을 완료해야 합니다. 다만 출시 직전이라면 테스트용 성공과 실제 출시 성공을 혼동하지 않아야 합니다.

마이그레이션 자산을 지표별로 비교합니다

다음 표는 어떤 자산을 새 환경으로 옮기고, 무엇을 다시 만드는지 결정하는 기준입니다.

지표	반드시 보관할 대상	다시 받을 수 있는 대상	통과 증거
소스 재현성	소스, 하위 모듈, 잠금 파일, 스크립트	패키지 캐시	깨끗한 복제본의 의존성 해석
도구 체계	Xcode 경로, SDK 기록, Scheme, 빌드 구성	중간 캐시	동일한 명령의 Archive 완료
서명 가능성	개인 키 포함 신원, 프로파일, 자동 서명 설정	만료된 임시 프로파일	목표 방식의 서명된 Archive
산출물 복구성	xcarchive, dSYM, xcresult, IPA, UUID 기록	DerivedData	Archive 열기와 dSYM 대응 확인
자동화 인수	Runner 설정, 태그, 권한, API 자격 증명	임시 로그	새 Runner의 격리 작업과 업로드
구환경 정리	폐기 기록과 회수 목록	빌드 캐시	Runner 제거와 민감 파일 점검

백업 위치를 정할 때는 접근 권한, 암호화, 담당자, 복구 시 필요한 비밀번호의 보관 방식을 함께 기록합니다. 개인 키와 API 자격 증명을 같은 일반 공유 폴더에 두는 방식은 피해야 합니다.

즉시 반납과 병행 유지 중 무엇을 선택할지 판단합니다

구환경을 얼마나 오래 유지할지는 새 환경의 검증 결과로 결정합니다.

선택지	적합한 조건	위험	결정 기준
즉시 정리	실제 Archive와 업로드, 단절 복구가 모두 성공	숨은 경로와 누락된 비밀 값	구환경 없이 핵심 작업 재실행
짧은 병행 유지	출시 일정이 임박했거나 서명 자산 영향이 큼	두 Runner의 중복 작업	새 Runner를 제한 태그로 운영
이전 보류	개인 키, 프로파일, API 자격 증명 복구가 실패	반납 지연과 비용 지속	실패 원인과 회수 경로가 불명확
새 환경 재구축	기존 맥이 오염되었거나 설정이 추적되지 않음	초기 설정 작업 증가	깨끗한 복제와 독립 검증을 우선

현재 환경이 불안정하다면 원격 맥 임대 조건과 이용 방식을 먼저 확인할 수 있습니다. 다만 임대 여부와 관계없이 개인 키와 배포 자격 증명은 이용자가 직접 관리해야 하며, 장기 고정 부하나 물리 장치 접근이 필요한 작업에는 별도 판단이 필요합니다.

현재 방식이 오래된 원격 맥 한 대에만 의존하면 호스트 반납 시 서명 개인 키가 함께 사라질 수 있고, 캐시 중심의 빌드는 새 환경에서 재현되지 않으며, Runner와 API 자격 증명이 어디에 연결되어 있는지 알기 어렵습니다. 반면 SFTPMAC의 원격 맥을 새 빌드 환경으로 사용할 때도 같은 검증표를 적용하면 Xcode 27 설치, 서명, Archive, 상시 자동화 작업을 각각 확인할 수 있습니다. 즉시 장비를 구매하기보다 임시 교체나 복구 시험이 목적이라면 서울 원격 맥 이용 조건처럼 필요한 접근 방식과 기간을 비교하는 편이 현실적입니다.

마지막 단계는 기존 맥의 파일을 지우는 일이 아니라, 새 맥이 없는 상태에서도 다음 배포를 다시 수행할 수 있다는 증거를 남기는 일입니다. 실제 Archive와 업로드, 자동화 인수, 구환경 단절 시험이 모두 끝난 뒤에만 반납과 정리를 진행해야 합니다.