Xcode Cloud 빌드 산출물은 30일만 보관되나요? 2026 백업 튜토리얼

첫 문장부터 기준을 정하면, Xcode Cloud를 장기 산출물 저장소로 쓰지 말고 빌드가 끝난 날 필요한 파일을 별도 보관해야 합니다. Apple 공식 안내 기준으로 빌드 정보와 산출물의 접근 가능 기간은 최대 30일이므로, 가끔 배포한다면 수동 다운로드를 사용하고 지속적으로 배포한다면 App Store Connect API 자동 보관과 복구 검증을 이번 주에 시작하는 편이 안전합니다.

이 글은 Xcode Cloud로 앱을 빌드하고 배포하지만 산출물을 따로 저장하지 않은 독립 개발자를 위한 글입니다. 과거 버전의 충돌을 조사해야 하거나, xcarchive와 xcresult를 장기간 관리해야 하는 소규모 팀에도 맞습니다.

보관 기간과 산출물의 역할

Apple은 첫 Xcode Cloud 작업 흐름 설정 문서에서 빌드 정보와 산출물에 최대 30일 동안 접근할 수 있다고 안내합니다. 이 기간은 “30일 동안 확인할 수 있다”는 뜻이지, 모든 파일을 장기 백업해 준다는 뜻은 아닙니다.

빌드가 끝난 뒤에는 파일을 용도별로 나눠야 합니다.

• 정식 배포용 App Archive: 같은 버전의 서명 상태와 배포 정보를 다시 확인할 때 사용합니다.
• 기호 정보: 배포된 앱의 충돌 보고서를 사람이 읽을 수 있는 형태로 분석할 때 필요합니다. Apple의 충돌 보고서와 기기 로그 분석 안내도 이 분석 흐름을 설명합니다.
• 빌드 로그: 의존성, 스크립트, 서명 단계에서 실패한 원인을 추적하는 자료입니다.
• 테스트 결과 파일: 테스트 실행 결과와 실패한 테스트를 다시 확인하는 증거입니다. 테스트 결과 해석은 Apple의 테스트 결과 안내 기준으로 확인합니다.
• 일반 브랜치 빌드: 재현 가치가 낮다면 정식 배포 파일과 같은 보존 규칙을 적용하지 않아도 됩니다.

특히 앱을 다시 빌드하면 같은 소스라도 의존성, 서명 자산, 빌드 환경이 달라질 수 있습니다. 소스 저장소가 남아 있다는 이유만으로 배포 당시의 분석 자료까지 남아 있다고 보면 안 됩니다.

빌드 완료 당일의 수동 보관

첫 번째 보관은 자동화보다 대조 기준을 만드는 일이 중요합니다. 다음 순서로 정식 배포 빌드 하나를 기록합니다.

1. Xcode Cloud에서 작업 흐름과 완료 상태를 확인합니다.
2. App Store Connect에서 앱, 버전, 빌드 번호가 배포 대상과 일치하는지 대조합니다.
3. Xcode 또는 App Store Connect에서 공식 산출물 목록을 엽니다.
4. Archive, 기호 정보, 빌드 로그, 테스트 결과 중 필요한 파일을 내려받습니다.
5. 압축 파일을 풀어 xcarchive와 xcresult가 실제로 열리는지 확인합니다.
6. 파일 이름과 보관 경로에 앱 식별자, 버전, 빌드 번호, 작업 흐름, 빌드 날짜를 기록합니다.
7. 파일 목록과 해시 값을 기록하고, 다운로드 상태를 보관 문서에 남깁니다.

App Store Connect의 빌드 실행 정보는 Build Runs API 문서에서 확인할 수 있습니다. 여기서 얻은 식별자를 파일 이름에 그대로 노출하기보다, 내부 규칙에 맞춘 폴더와 기록 파일에 연결하는 방식이 좋습니다. 계정 이름, 앱 식별자, 빌드 식별자, 경로와 로그에는 실제 운영 값을 넣지 말고 문서와 예제에서는 가림 값을 사용해야 합니다.

첫 주의 API 자동화 전환

반복 다운로드를 자동화할 때는 API 목록을 나열하는 것보다 흐름을 먼저 설계해야 합니다.

• 완료된 빌드 실행 중 성공한 작업 흐름만 고릅니다.
• Archive 또는 배포 작업과 연결된 작업 식별자를 확인합니다.
• 작업의 산출물 자원을 조회합니다.
• 산출물 이름, 형식, 연결된 작업 정보를 기록합니다.
• 다운로드가 끝난 파일을 별도 저장소에 씁니다.
• 성공, 실패, 재시도 시각을 로그로 남깁니다.

작업 산출물 조회는 작업 산출물 API 문서와 Artifacts 자료를 기준으로 구현합니다. API 응답에 보이는 산출물과 실제로 보관해야 하는 파일을 먼저 대조해야 합니다. “API 호출 성공”과 “복구에 필요한 파일을 모두 저장”은 같은 상태가 아닙니다.

인증 정보도 세 종류로 나눠야 합니다.

• API 접근 자격 정보: App Store Connect API 호출에만 사용합니다.
• 코드 서명 자산: 인증서와 개인 키, 프로비저닝 프로파일을 뜻하며 일반 산출물 폴더에 섞지 않습니다.
• 원격 Mac 로그인 권한: SSH나 화면 접속을 위한 별도 권한입니다.

예시 설정에는 API_KEY_ID_PLACEHOLDER, ISSUER_ID_PLACEHOLDER, PRIVATE_KEY_PATH_PLACEHOLDER처럼 가림 값을 사용합니다. 개인 키 파일을 압축 산출물 안에 넣거나 로그에 출력하는 방식은 피해야 합니다. API 전체 문서의 권한과 자원 관계는 App Store Connect API 안내에서 다시 확인합니다.

완료 이벤트와 보완 검색

자동화 방식은 배포 빈도에 따라 나눌 수 있습니다.

배포가 드문 경우에는 정기 작업이 단순합니다. 하루에 한 번처럼 자주 확인하는 정책이 아니라, 팀의 배포 주기에 맞춰 완료된 빌드를 찾아 내려받도록 구성합니다. 단, 이 간격을 30일보다 길게 잡으면 공식 접근 기간 안에 산출물을 놓칠 수 있습니다. 이 판단은 Apple이 안내한 최대 30일 보관 범위에 맞춰야 합니다.

배포가 잦은 경우에는 Xcode Cloud webhook으로 완료 이벤트를 받아 즉시 후속 작업을 시작할 수 있습니다. Xcode Cloud webhook 문서는 이벤트를 외부 작업으로 전달하는 방법을 설명하지만, webhook 자체가 저장소는 아닙니다.

따라서 이벤트 방식에는 보완 검색이 필요합니다.

• 이벤트가 오면 빌드 식별자와 작업 흐름을 먼저 저장합니다.
• 같은 식별자가 이미 보관됐는지 검사합니다.
• 성공한 Archive 작업만 다운로드 대상으로 표시합니다.
• 실패한 작업은 산출물 누락이 아니라 실패 상태로 기록합니다.
• 정기 보완 검색에서 이벤트 누락과 다운로드 실패를 다시 찾습니다.

이렇게 해야 재시도 때 같은 파일을 여러 번 만들지 않는 멱등 처리가 가능합니다. 반대로 이벤트만 믿으면 외부 작업의 장애나 네트워크 오류가 발생했을 때 조용히 누락될 수 있습니다.

주의: webhook은 “무엇이 끝났는지” 알려주는 통지 수단입니다. 파일을 장기간 보관하거나 삭제 정책을 적용하는 역할까지 자동으로 수행한다고 가정하면 안 됩니다.

독립 FAQ

오래된 빌드의 접근 기준

Xcode Cloud의 공식 접근 기간은 최대 30일입니다. 그러므로 한 달 전 충돌을 조사할 가능성이 있는 정식 배포본은 기간 안에 별도 저장소로 복사해야 합니다. 저장소에 파일이 있다는 것만으로 충분하지 않으며, 앱 버전과 배포 빌드를 연결한 기록도 함께 있어야 합니다.

xcarchive와 기호 정보의 연결

기호 파일은 어느 배포본에서 생성됐는지 확인할 수 있어야 합니다. 폴더 이름에 앱, 버전, 빌드 번호와 작업 흐름을 기록하고, 내려받은 뒤 실제 파일 목록을 검사합니다. 충돌 보고서 분석을 위해 필요한 기호 정보가 빠졌다면 압축 파일 다운로드 성공만으로는 보관 완료로 처리하지 않습니다.

API 자동 보관의 한계

App Store Connect API는 Xcode Cloud 작업과 산출물을 찾아 내려받는 자동화에 사용할 수 있습니다. 그러나 API가 외부 저장 공간, 파일 무결성 검사, 재시도 기록을 대신하지는 않습니다. 다운로드 결과를 별도 저장소에 쓰고, 동일한 작업을 중복 처리하지 않도록 식별자 기준을 정해야 합니다.

삭제 이후의 복구 판단

Xcode Cloud에서 공식 접근 기간이 지나거나 산출물이 더 이상 제공되지 않으면, 외부 백업이 없는 파일을 복구할 수 있다고 기대하기 어렵습니다. 소스 코드와 새로 만든 빌드는 당시의 Archive와 같지 않을 수 있습니다. 따라서 정식 배포 직후 복사하고, 복구 시험까지 끝낸 파일만 신뢰 가능한 백업으로 분류해야 합니다.

장기 보관 대상의 우선순위

정식 배포용 xcarchive와 기호 정보가 첫 번째 대상입니다. 그 다음은 실패 원인을 분석할 빌드 로그와 테스트 결과 파일입니다. 내부 테스트와 일반 브랜치 빌드는 팀의 조사 필요성에 따라 보관 수준을 낮출 수 있지만, 모든 파일에 같은 보존 기간을 임의로 적용하기보다 앱 유지보수 기준을 먼저 정해야 합니다.

복구 시험과 장기 운영

다운로드가 완료됐다는 표시만으로는 충분하지 않습니다. 다음 순서로 가림 처리한 복구 시험을 진행합니다.

• 보관 기록에서 앱, 버전, 빌드 번호와 작업 흐름을 찾습니다.
• 저장소에서 연결된 xcarchive와 xcresult를 선택합니다.
• 압축을 해제하고 예상 폴더 구조와 파일 목록을 확인합니다.
• Xcode에서 Archive를 열어 앱 정보와 배포 대상이 맞는지 확인합니다.
• xcresult를 읽어 테스트 결과와 실패 항목을 확인합니다.
• 기호 정보가 충돌 분석에 사용할 수 있는지 점검합니다.
• 해시와 보관 기록을 비교해 파일 변경 여부를 확인합니다.
• 시험 결과와 누락 파일을 운영 로그에 기록합니다.

보관 위치는 역할을 나누는 것이 좋습니다. 로컬 디스크는 빠른 확인과 임시 작업에 적합하지만 단일 장애 지점이 될 수 있습니다. 일반 객체 저장소는 장기 보관과 접근 통제에 유리하지만, 파일을 실제로 열어 보는 복구 작업은 별도로 준비해야 합니다. 상시 원격 Mac은 Xcode로 과거 산출물을 열거나 기호화 스크립트를 정기 실행해야 할 때 적합합니다.

장기 운영에서는 내부 테스트, 후보 배포, 정식 배포를 서로 다른 정책으로 관리합니다. 근거 없이 모든 파일에 동일한 보존 기간을 정하지 말고, 법무·지원·장애 분석 요구에 따라 삭제 조건을 문서화합니다. 월간 추출 검사와 배포 직후 검사를 각각 두면 자동화가 조용히 멈춘 상태를 발견하기 쉽습니다.

보관 방식 선택표

현재 Xcode Cloud만 사용하는 방식은 설정이 간단하지만, 30일 접근 한계와 이벤트 누락, 복구 시험 공간 부족이라는 약점이 있습니다. 로컬 Mac 한 대에만 저장하면 디스크 장애와 담당자 의존성이 생기고, 별도 저장소만 두면 Xcode로 직접 열어 보는 운영 작업이 번거로울 수 있습니다.

정식 배포 파일을 정기적으로 열어 확인하거나, 기호화와 다운로드 스크립트를 계속 실행해야 한다면 원격 Mac 기반 iOS 자동화 테스트 환경을 검토할 수 있습니다. 장기 노드를 선택하기 전에 맥 미니 렌탈과 운영 방식을 확인하고, 단순한 일회성 복구라면 짧은 환경으로 충분한지 먼저 판단해야 합니다.

결국 현재 방식은 Xcode Cloud 안의 짧은 접근 기간에 의존하고, 로컬 저장은 단일 장비 장애에 취약하며, 일반 저장소는 Xcode 복구 작업을 별도로 준비해야 합니다. 정기 다운로드와 복구 시험이 필요한데 자체 Mac을 계속 켜 둘 이유가 없다면, VMSPIN의 원격 Mac을 임시 작업 환경이나 상시 노드로 비교해 보는 편이 현실적입니다. 다만 장기간 고정 부하가 계속되거나 물리 포트와 장비 직접 접근이 필요하다면 자체 Mac이 더 적합할 수 있습니다.

이번 주에는 정식 배포 빌드 하나를 골라 수동 다운로드, 파일 연결 기록, 압축 해제, xcarchive와 xcresult 읽기까지 끝내십시오. 이후 배포 빈도가 높다면 App Store Connect API와 webhook을 연결하고, 복구 작업을 반복해야 할 때만 VMSPIN의 원격 Mac 운영을 선택하면 됩니다.