Xcode Cloud 빌드 산출물은 어떻게 자동 보관할까? 2026 가이드

Xcode Cloud 빌드 산출물은 빌드 완료 후 필요한 항목을 바로 내려받아 검증한 뒤 팀이 관리하는 저장소에 보관하는 방식이 안전합니다. 낮은 빈도의 작업은 Xcode나 App Store Connect에서 수동으로 저장하고, 반복 작업은 App Store Connect API로 자동화하면 됩니다. API가 돌려주는 다운로드 주소는 장기 보관 링크로 쓰지 않습니다.

과거 실패를 재현하거나 테스트 증거를 남겨야 하는 소규모 팀이라면 이 절차를 적용할 수 있습니다.
빌드 로그와 아카이브를 누가, 어디에, 어떤 권한으로 보관하는지 정하지 못한 팀에도 적합합니다.

Xcode Cloud 빌드 산출물 자동 보관 범위부터 정합니다

모든 파일을 무조건 보관하면 저장소와 접근 관리 부담이 커집니다. 반대로 앱 아카이브만 남기면 실패 원인이나 테스트 결과를 나중에 확인하지 못할 수 있습니다. 먼저 각 산출물이 해결할 문제를 정합니다.

Apple은 Xcode Cloud에서 빌드 정보와 산출물을 최대 30일 동안 이용할 수 있다고 안내합니다. 이 기간은 팀의 장기 보관 정책이 아닙니다. 필요한 파일은 접근 가능할 때 별도 저장소로 옮겨야 합니다. Apple의 Xcode Cloud 산출물 및 보관 안내

보관 범위는 릴리스 추적, 크래시 진단, 테스트 재현 가운데 실제로 필요한 목적에 맞춥니다. 심볼과 테스트 결과는 모든 빌드에서 같은 방식으로 쓰이지 않을 수 있으므로, 프로젝트의 실제 산출물 목록을 확인한 뒤 선택합니다. Apple의 Xcode Cloud 빌드 및 워크플로 API 설명에서 빌드 리소스 구조를 확인할 수 있습니다.

Xcode Cloud 산출물은 얼마나 오래 남나요?

Apple 문서에 따르면 Xcode Cloud 빌드 정보와 산출물은 최대 30일 동안 접근할 수 있습니다. 이 안내는 Apple 클라우드에서의 접근 가능 기간에 관한 것입니다. 팀이 별도로 운영하는 저장소의 보존 기간이나 삭제 책임까지 정해 주지는 않습니다.

따라서 빌드 기록을 장기 추적해야 한다면 클라우드에 남아 있는 동안 복사본을 확보해야 합니다. 보관 위치와 삭제 시점은 팀의 출시 추적, 장애 대응, 규정 요구에 따라 따로 정합니다. 특히 “클라우드에서 확인할 수 있다”는 사실을 “팀이 필요한 기간 동안 보관 중이다”와 동일하게 취급하지 않습니다.

첫 단계: 빌드 보고서에서 실제 파일을 확인합니다

자동화 전에 Xcode 빌드 보고서나 App Store Connect에서 대상 빌드와 작업을 찾습니다. 해당 화면에서 제공되는 로그, 아카이브, 심볼 또는 테스트 결과를 확인하고 필요한 항목을 수동으로 내려받습니다. 화면에서 보이는 파일과 API 응답의 항목이 항상 팀의 보관 요구를 모두 충족한다고 단정하지 말고, 실제 프로젝트의 산출물 목록을 대조합니다.

수동 저장은 빈도가 낮거나 사람이 내용을 검토해야 할 때 적합합니다. 이 방식도 담당자와 저장 위치를 지정해야 합니다. 담당자가 바뀌거나 화면에서 산출물을 더는 받을 수 없게 되면, 보관 공백이 생길 수 있습니다.

다음 단계: App Store Connect API로 자동 수집을 구성합니다

API 자동화는 빌드와 작업을 식별하고, 해당 작업의 산출물을 조회한 다음, 필요한 파일을 즉시 내려받는 흐름으로 만듭니다. Apple 문서에서 빌드 작업의 전체 산출물을 조회하는 리소스와 개별 산출물 정보를 읽는 리소스를 확인할 수 있습니다.

응답 필드의 의미는 산출물 속성 문서를 기준으로 처리합니다. 파일 이름, 유형, 다운로드 정보가 응답에 어떻게 표현되는지 문서와 실제 응답을 함께 확인합니다. API의 경로, 필드, 인증 방식은 바뀔 수 있으므로 샘플을 그대로 고정하지 말고, 구현 시점의 공식 문서에 맞춥니다.

인증에는 App Store Connect API가 요구하는 키와 요청 토큰을 사용합니다. API 키 생성 안내와 요청 인증용 토큰 문서를 읽고, 키 권한은 자동화에 필요한 범위로 제한합니다.

다운로드 흐름은 팀의 자동화에 연결합니다

Apple 문서와 API 응답을 기준으로 다음 단계를 구현합니다. 특정 자동 실행 신호나 보관 완료 보장은 있다고 가정하지 않습니다. 빌드 완료를 알아내는 방법은 팀이 이미 운영하는 자동화 방식에 맞춰 설계합니다.

• 빌드가 완료됐는지 팀의 기존 자동화에서 확인합니다.
• 대상 빌드와 작업을 식별하고 API에서 산출물 목록을 조회합니다.
• 보관 대상으로 정한 파일만 분류하고, 각 산출물의 문서화된 속성을 기록합니다.
• 응답에서 받은 다운로드 주소를 확보한 즉시 파일을 내려받습니다.
• 파일 크기나 열기 가능 여부, 예상 파일 유형을 확인하고 결과를 기록합니다.
• 파일과 함께 빌드 식별 정보 및 저장 시점을 보관합니다.

다운로드 주소는 오래 유지되는 보관 경로가 아닙니다. API가 반환한 주소를 나중에 다시 호출할 링크로 데이터베이스에 저장하는 방식은 피합니다. 주소를 받은 실행 안에서 다운로드를 끝내고, 이후에는 팀 저장소의 파일 경로를 사용합니다.

테스트 결과와 빌드 로그는 목적에 맞춰 보관합니다

테스트 결과는 보고서만 따로 떼어 두기보다 어떤 빌드에서 생성됐는지 연결해 저장합니다. 로그도 파일명만으로 빌드를 구분하지 않습니다. 빌드 식별자, 작업 정보, 커밋 또는 워크플로 정보처럼 팀에서 추적에 필요한 항목을 폴더 구조나 메타데이터에 남깁니다.

로그와 산출물에는 코드 정보나 내부 데이터가 들어갈 수 있습니다. 저장소의 읽기·쓰기 권한을 제한하고, 자동화 로그에 토큰이나 개인 키가 출력되지 않도록 합니다. 인증 비밀은 소스 코드나 일반 로그와 분리된 비밀 저장 방식으로 관리합니다. 저장 작업 자체가 성공했는지뿐 아니라, 권한 없는 사용자가 접근할 수 없는지도 점검합니다.

다운로드 주소를 장기 링크로 써도 될까요?

아니요. App Store Connect API의 산출물 다운로드 주소는 제한된 시간 동안만 유효합니다. 따라서 주소가 응답에 포함됐다는 사실은 파일을 장기간 다시 받을 수 있다는 뜻이 아닙니다. Apple의 산출물 API 설명에 명시된 속성을 확인하고, 주소를 받은 뒤 바로 파일을 저장합니다.

파일을 받은 뒤에는 저장소의 경로를 장기 참조로 사용합니다. 다운로드 주소 자체를 빌드 기록의 영구 위치로 삼지 않습니다. 내려받기 실패 시 재시도할 수 있도록 자동화 실행 상태를 남기되, 주소가 아직 유효하다고 가정하지 말고 API에서 최신 산출물 정보를 다시 조회하는 흐름을 둡니다.

운영 전 확인할 수 있는 보관 점검표

• [ ] 릴리스 추적, 크래시 진단, 테스트 재현 중 보관 목적을 정했습니다.
• [ ] 각 목적에 필요한 로그, 아카이브, 심볼, 테스트 결과를 실제 빌드에서 확인했습니다.
• [ ] 수동 저장이라면 담당자와 저장 위치를 지정했습니다.
• [ ] API를 쓰는 경우 공식 문서에 맞는 인증과 최소 권한을 구성했습니다.
• [ ] 임시 다운로드 주소를 장기 링크로 저장하지 않고 즉시 파일을 받습니다.
• [ ] 파일이 열리는지, 유형이 예상과 맞는지, 대상 빌드와 연결되는지 확인합니다.
• [ ] 저장소 접근 권한과 비밀 정보가 로그에 노출되지 않는지 점검합니다.
• [ ] 실제 워크플로에서 다운로드부터 사후 읽기까지 검증하고 정리 책임을 정했습니다.

팀의 현재 방식이 Xcode Cloud 화면에서 수동으로 내려받는 절차에만 의존하면 담당자 누락과 보관 위치 불일치가 생길 수 있고, 임시 링크를 재사용하려 하면 파일을 다시 받지 못할 수 있습니다. 자동화만 추가해도 인증 비밀 관리와 파일 검증을 놓치면 보관 체계가 완성되지 않습니다.

후처리나 프로젝트 검증을 위해 별도의 macOS 환경이 필요한 흐름이라면, 먼저 한국 배포 환경 안내를 살펴보고 원격 Mac을 보조 검증 환경으로 둘 필요가 있는지 판단할 수 있습니다. 간헐적 검증과 임시 작업이라면 metalvnc의 Mac 렌탈이 실기기 구매보다 유연할 수 있습니다. 반대로 지속적인 고부하 작업이나 물리 인터페이스가 필요한 환경은 자체 Mac 운영이 더 적합할 수 있습니다. 필요 시 metalvnc 요금 안내에서 조건을 확인한 뒤 선택하세요.