Xcode Cloud 빌드 산출물은 어떻게 장기 보관할까? 2026 아카이브 가이드

Apple의 Xcode Cloud 안내 문서는 빌드 산출물을 빌드 완료 뒤 최대 30일까지 이용할 수 있다고 설명합니다. 따라서 Xcode Cloud를 영구 보관소로 사용하지 마세요. 필요한 파일을 정해 이용 가능한 동안 내려받고, 빌드와 소스 제출 정보에 연결해 보관한 뒤 실제로 열어 복구를 확인해야 합니다.

이 글은 정식 배포 Archive와 심벌 정보를 남겨야 하는 독립 개발자, 테스트 결과를 다시 확인하려는 개발자, 과거 배포 자료를 이어받아야 하는 소규모 팀을 위한 실행 절차입니다.

배포 장애를 조사할 때: Archive와 심벌 정보를 분리해 보관합니다

정식 버전에서 충돌이나 동작 문제가 생기면 Archive 하나만으로 충분하지 않을 수 있습니다. Archive는 배포에 사용한 빌드 자료이고, dSYM 같은 심벌 파일은 충돌 정보를 읽을 때 필요한 디버깅 자료입니다. 빌드 로그는 빌드 과정에서 발생한 경고와 오류를 살펴보는 기록입니다. 서로 역할이 다르므로 어떤 파일을 보관했는지 따로 남기세요.

Apple의 디버깅 정보 빌드 안내는 디버깅에 필요한 정보가 빌드에 포함되도록 설정하는 내용을 설명합니다. 프로젝트의 빌드 설정과 배포 방식을 확인한 뒤, Archive와 심벌 파일이 모두 필요한지 판단하세요. 특히 나중에 크래시를 조사해야 한다면 해당 배포 빌드와 심벌 파일의 연결 관계를 함께 기록해야 합니다.

빌드 기록을 찾을 때는 앱과 워크플로 이름만으로 판단하지 마세요. 빌드 식별 정보, 앱 버전, 소스 제출 식별 정보를 함께 확인하면 비슷한 이름의 파일이 섞이는 위험을 줄일 수 있습니다. 빌드 실행 리소스 설명을 참고해 기록을 찾고, Archive를 내려받았다면 별도 작업 위치에서 열리는지 확인합니다.

산출물 보관 방식을 목적에 맞게 고릅니다

모든 빌드 파일을 영구 보관하면 불필요한 자료까지 쌓일 수 있습니다. 반대로 Archive만 남기면 테스트를 재현하거나 당시 빌드 실패 원인을 조사할 단서가 사라질 수 있습니다. 먼저 보관 목적을 정하고, 각 파일이 그 목적에 필요한지 판단하세요.

표의 자료를 모두 매번 보관할 필요는 없습니다. 배포 후 진단을 위해서는 Archive와 심벌 정보가 중요할 수 있지만, 일상적인 실패 조사에서는 로그만으로 충분한 경우도 있습니다. 팀의 복구 목적을 기준으로 파일 종류와 내부 보관 규칙을 정하고, 실제 사용하지 않는 자료까지 무기한 보관하는 관행은 피하세요.

테스트를 다시 재현할 때: 결과 파일과 출처를 함께 남깁니다

테스트 결과 묶음이나 자동화 테스트 캡처를 보관하더라도 출처 정보가 빠지면 나중에 어느 실행에서 나온 파일인지 알기 어렵습니다. 결과 파일에는 워크플로와 빌드 기록, 소스 제출 정보를 연결하세요. 캡처를 따로 저장한다면 파일 이름이나 색인에도 같은 식별 정보를 반영합니다.

Xcode Cloud 결과 자료를 내려받을 수 있는지는 해당 빌드와 제공되는 산출물에 따라 확인해야 합니다. Apple의 Xcode Cloud 결과 자료 안내를 살펴보고, 현재 워크플로에서 내려받을 수 있는 파일을 직접 확인하세요. 파일을 저장한 뒤에는 파일이 손상되지 않았는지 확인하고, 테스트 결과 묶음이 열리는지도 별도로 점검합니다.

테스트 증거를 남길 때는 팀이 이후에 무엇을 다시 확인할지 먼저 정하세요. 실패 화면만 필요한지, 결과 묶음과 로그도 필요한지에 따라 보관 범위가 달라집니다. 파일만 모아 두지 말고, 문제가 발생한 상황과 확인 결과를 짧게 기록하면 다른 구성원이 자료를 해석하기 쉬워집니다.

팀 인수인계와 자동 다운로드: 기록에서 파일까지 이어 줍니다

팀원이 바뀌거나 과거 배포를 복구할 때는 파일 이름보다 검색 기준이 중요합니다. 앱과 워크플로, 빌드 식별 정보, 소스 제출 정보를 기준으로 폴더와 색인을 구성하세요. 기록에서 파일 위치를 찾아 내려받은 파일을 열 수 있어야 하고, 빠진 자료가 있으면 누가 확인할지 남겨야 합니다.

자동 다운로드는 API를 통해 빌드 실행을 찾고, 해당 실행과 연결된 산출물을 조회한 다음 파일 정보를 확인해 다운로드하는 흐름으로 나눠 설계합니다. Xcode Cloud 및 빌드 API 안내와 산출물 리소스 설명을 확인하세요. 특정 산출물의 속성은 산출물 속성 문서에서 검토할 수 있습니다.

단일 산출물을 읽는 API 문서를 구현 기준으로 삼되, 다운로드 주소를 영구 링크로 취급하지 마세요. 주소가 유효할 때 파일을 내려받아야 하며, 주소가 만료되었거나 요청이 실패하면 산출물 정보를 다시 조회하는 재시도 절차를 준비합니다. 다운로드 완료 여부, 파일 검사 결과, 보관 위치를 각각 기록하면 일부 단계가 실패했을 때 어디서 복구할지 판단할 수 있습니다.

API 인증 정보는 자동화 코드에 그대로 넣지 마세요. Apple의 API 요청용 토큰 안내에 따라 인증 방식을 확인하고, 토큰 접근 권한과 저장 위치를 제한하세요. 사용이 끝난 자격 증명과 다운로드 상태를 함께 관리해야 담당자 변경 뒤에도 자동화 경로를 통제할 수 있습니다.

보관 및 복구 점검표

• [ ] 배포 진단, 테스트 재현, 일상적인 오류 조사 중 이번 보관의 목적을 정합니다.
• [ ] 필요한 Archive, 심벌 정보, 로그, 테스트 결과 묶음과 캡처를 구분합니다.
• [ ] 앱, 워크플로, 빌드 식별 정보, 소스 제출 정보를 기록에 연결합니다.
• [ ] 이용 가능한 동안 산출물을 내려받고 파일 크기와 저장 완료 상태를 확인합니다.
• [ ] Archive와 테스트 결과 묶음을 별도 작업 위치에서 열어 봅니다.
• [ ] 누락되거나 열리지 않는 파일과 후속 확인 담당자를 기록합니다.
• [ ] API 자동화에서는 자격 증명, 다운로드 실패 재시도, 파일 검사, 처리 상태 기록을 각각 점검합니다.

FAQ: 보관 기간과 복구 가능성을 확인합니다

Xcode Cloud 빌드 산출물의 이용 가능 기간은 어떻게 확인하나요?

Apple 문서에는 빌드 산출물을 빌드 완료 뒤 제한된 기간 동안 이용할 수 있으며, 최대 30일까지라고 나와 있습니다. 그러므로 플랫폼에서 보인다는 사실을 팀의 장기 보관 완료로 간주하지 마세요. 필요한 파일을 선정하고 기간 안에 외부로 내려받은 뒤 열어 확인해야 합니다. 정책이 바뀔 수 있으므로 실제 작업 전에는 공식 안내를 다시 살펴보세요.

App Store Connect API로 산출물을 내려받는 흐름은 어떻게 구성하나요?

먼저 API에서 빌드 실행을 확인하고, 연결된 산출물을 조회한 뒤, 필요한 파일의 세부 정보와 다운로드 주소를 읽어 내려받습니다. 파일 저장과 검증 결과는 API 요청 기록과 분리해 남기세요. 주소가 유효하지 않거나 다운로드가 실패하면 최신 산출물 정보를 다시 확인하도록 설계합니다. 필드와 인증 방식은 구현 시점의 Apple API 문서에 맞춰야 합니다.

Archive와 심벌 파일을 함께 보관할 때 무엇을 확인해야 하나요?

배포에 사용한 Archive가 열리는지 확인하고, 크래시 진단에 필요한 심벌 정보가 같은 빌드와 연결되어 있는지 점검하세요. 앱 버전과 소스 제출 정보를 함께 기록하면 나중에 유사한 Archive 사이에서 올바른 자료를 찾기 쉽습니다. 심벌 정보가 없으면 충돌 원인을 추적하기 어려울 수 있으므로, 프로젝트의 디버깅 정보 설정과 실제 생성 파일을 대조해야 합니다.

보관한 테스트 결과를 복구할 수 있는지 어떻게 검증하나요?

파일을 내려받았다는 상태만으로 복구 가능하다고 판단하지 마세요. 테스트 결과 묶음이 열리는지 확인하고, 필요한 캡처와 로그를 같은 워크플로 및 빌드 기록에서 찾을 수 있는지 시험합니다. 결과와 기록이 일치하지 않거나 파일이 누락되면 원인과 담당자를 색인에 남기세요. 복구를 맡을 팀원이 출처를 찾고 파일 내용을 확인할 수 있어야 검증이 끝납니다.

원격 Mac을 둘 때: 다운로드와 보관 책임을 분리합니다

원격 Mac은 Xcode Cloud에서 받은 파일을 정리하거나 열어 보는 작업 환경으로 검토할 수 있습니다. 그렇다고 원격 Mac을 준비하는 것만으로 자동 다운로드, 지속 보관, 백업이 보장되는 것은 아닙니다. 파일을 어디에 저장할지, 누가 접근할지, 복구용 사본을 어떻게 관리할지는 기존 팀 저장소와 운영 절차를 기준으로 따로 정해야 합니다.

원격 환경을 고려한다면 작업에 필요한 macOS 접근 방식과 보관 책임을 먼저 정의하세요. 실물 맥과 가상화 macOS 환경의 차이를 비교해 필요한 환경을 판단하고, 임시로 빌드 자료를 정리하거나 확인할 목적이라면 원격 맥 요금 안내에서 실제 제공 조건을 살펴볼 수 있습니다. 환경을 선택한 뒤에는 산출물 다운로드와 복구 확인을 직접 해 보고, 팀의 저장 절차가 그 환경에 맞는지 검증하세요.

Xcode Cloud에서 바로 다시 받을 수 있다고 가정하는 방식은 보관 기간, 주소 유효성, 과거 빌드 검색에 의존합니다. 반면 파일을 직접 관리하면 저장 위치와 접근 권한, 백업 상태를 팀이 책임져야 합니다. 기존 저장소가 검색과 복구를 충분히 지원한다면 별도 Mac을 추가할 필요는 없습니다. 현재 방식이 다운로드·정리·검증을 감당하기 어렵고 잠시 사용할 macOS 작업 환경이 필요할 때만 원격 Mac을 대안으로 살펴보세요. MacDate의 원격 환경도 보관 절차를 대신하지 않으므로, 사용 여부와 관계없이 실제 파일 복구 시험을 운영 기준에 포함해야 합니다.