기업 Mac CI 빌드 산출물 보관 기간은? 2026 전략 가이드

빌드가 끝난 뒤 작업 폴더를 정리했더니 출시 버전의 크래시를 조사할 dSYM까지 사라졌다면, 보관 규칙부터 다시 나눠야 합니다.
이번 주에는 모든 파일에 같은 만료 규칙을 적용하지 말고, 배포된 Xcode archive와 짝이 맞는 dSYM을 진단·감사 자료로 따로 보관하며 로그·보고서·캐시는 용도별로 만료와 복구 기준을 정하세요.

기업 iOS 배포와 크래시 진단을 맡은 엔지니어는 archive와 dSYM의 저장 규칙을 정할 수 있습니다.
Mac Runner의 저장 공간과 캐시, 로그를 관리하는 플랫폼 엔지니어는 필요한 자료와 정리 가능한 데이터를 구분할 수 있습니다.
릴리스 감사와 데이터 수명 주기를 담당하는 IT·보안 책임자는 보관 책임자와 증거 위치를 정리할 수 있습니다.

기업 Mac CI 빌드 산출물 보관 전략은 파일의 역할부터 나눕니다

CI 빌드 산출물은 모두 같은 방식으로 보관할 대상이 아닙니다. 배포된 버전을 재현하거나 크래시를 조사할 자료와, 삭제 후 다시 만들 수 있는 데이터가 한 작업 폴더에 섞이면 정리 작업이 증거 삭제로 이어질 수 있습니다.

여기서 CI 빌드 산출물은 보관 위치가 아니라 용도로 분류해야 합니다. Apple은 배포용 archive를 만드는 절차와 디버깅 정보를 다루는 방법을 각각 안내하며, 배포한 앱의 archive를 보존하는 것이 진단에 도움이 된다고 설명합니다. 배포용 앱 archive와 릴리스 절차와 디버깅 정보를 포함한 빌드 및 archive 보관 안내를 기준으로 사내 정책을 확인하세요.

주의: 소스 코드가 같아도 빌드 결과의 식별 정보와 서명 상태가 다르면 기존 archive나 dSYM을 대체할 수 있다고 가정하지 마세요. 보관 여부는 파일 이름이 아니라 실제 릴리스와의 대응 관계로 판단해야 합니다.

archive와 dSYM의 연결이 끊기면 출시 뒤 진단이 막힙니다

배포한 버전의 archive와 dSYM은 얼마나 보관해야 하나요?
모든 조직에 통하는 고정 기간을 정하기보다, 해당 앱 버전을 진단하거나 감사할 필요가 남아 있는 동안 접근 가능한 위치에 보관하도록 규칙을 만드세요. 계약, 내부 보안 정책, 데이터 관리 기준이 있다면 그 조건을 우선 적용해야 합니다.

Apple의 설명에 따르면 dSYM은 빌드에 포함된 디버깅 정보와 연결되어 크래시 보고서를 읽기 쉽게 만드는 데 쓰입니다. 크래시 보고서에 식별 가능한 심볼 이름을 적용하는 안내를 참고해 실제 배포 빌드에 맞는 파일인지 확인하세요. 같은 앱 이름이나 버전 문자열만으로는 짝이 맞는다고 단정하지 말고, 빌드 식별 정보와 심볼 정보를 대조하는 절차를 보관 검수에 넣는 편이 안전합니다.

archive를 지운 뒤에도 dSYM으로 크래시를 심볼화할 수 있나요?
해당 크래시와 일치하는 dSYM이 남아 있다면 심볼화에 필요한 정보가 있을 수 있습니다. 하지만 dSYM이 있다고 archive와 내보낸 배포 파일까지 복원되는 것은 아닙니다. archive를 삭제한 경우에는 그 자체로 다시 확인할 수 없는 정보가 생길 수 있으므로, dSYM만 따로 남기는 방식을 완전한 릴리스 보관으로 취급하지 마세요.

릴리스마다 버전, 빌드 식별 정보, archive, dSYM, 실제 전달 파일, 배포 기록을 하나의 논리적 묶음으로 연결하세요. 저장소가 어떤 제품이든 다음 항목을 기록해야 복구 경로를 확인할 수 있습니다.

로그와 캐시는 같은 만료 규칙으로 묶지 않습니다

Mac CI 로그, 테스트 보고서, 캐시를 같은 기간 보관해도 되나요?
같은 만료 규칙을 일괄 적용하지 마세요. 테스트 결과와 로그는 실패 재현이나 출시 검토에 필요할 수 있지만, 캐시는 다시 생성할 수 있는지와 재생성 비용을 따져 별도로 정리할 수 있습니다.

CI 서비스의 만료 설정은 플랫폼과 설정 범위에 따라 다릅니다. 예를 들어 공식 문서에는 조직 차원의 로그 및 산출물 보관 설정과 개별 워크플로 산출물 설정이 각각 안내되어 있습니다. 조직 수준의 로그·산출물 보관 설정과 워크플로 산출물의 개별 보관 설정을 확인하되, 특정 플랫폼의 기본값을 기업 공통 기준으로 옮기지 마세요.

캐시는 산출물과 목적이 다릅니다. 의존성 캐시는 다시 내려받거나 생성해 빌드를 돕는 데이터이고, 배포 증거의 대체물이 아닙니다. 의존성 캐시와 워크플로 산출물의 용도 차이를 기준으로 캐시 디렉터리의 소유자, 마지막 사용 여부, 다시 만드는 방법을 확인하세요. 다른 CI 플랫폼에서도 만료 동작은 제품별 문서에서 별도로 검증해야 합니다. 작업 산출물 만료와 최신 파이프라인 보관 조건도 플랫폼별 예외가 있을 수 있음을 보여주는 참고 자료입니다.

캐시 정리는 먼저 별도 작업에서 재생성을 검증한 뒤 적용하세요. 마지막 사용 시점만 보고 지우면 진행 중인 빌드와 공유 디렉터리의 의존 관계를 놓칠 수 있습니다. 반대로 장기간 사용하지 않은 캐시를 무조건 계속 보관하면 작업 공간이 불필요한 데이터로 채워집니다. 삭제 기준, 예외 승인, 정리 기록을 함께 두세요.

첫 단계: 보관 규칙을 복구 가능한 절차로 바꿉니다

다음 항목을 담당자와 함께 확인하세요.

• [ ] 배포된 앱 버전마다 archive와 짝이 맞는 dSYM을 찾을 수 있는지 확인합니다.
• [ ] archive, dSYM, 전달 파일, 배포 기록을 같은 릴리스 식별 정보로 연결합니다.
• [ ] CI 작업 폴더 밖에 보관해야 하는 자료와 위치를 기록합니다.
• [ ] 저장 위치별 읽기·삭제 권한과 삭제 승인 책임자를 확인합니다.
• [ ] 로그와 테스트 보고서의 만료 조건을 진단·감사 목적에 맞춰 나눕니다.
• [ ] 캐시와 임시 작업 폴더를 재생성해 보고, 검증된 항목에만 정리 규칙을 적용합니다.
• [ ] 별도 저장 위치에서 필요한 릴리스 파일을 복구해 보고, 결과와 담당자를 기록합니다.

Mac 노드 장애 뒤에도 릴리스 증거를 복구할 수 있는지 어떻게 확인하나요?
작업 디렉터리만 확인하지 말고, 독립된 저장 위치에서 실제 배포 버전의 archive와 dSYM을 찾아보세요. 이어 파일의 식별 정보와 접근 권한을 확인하고, 로그·테스트 보고서가 정해 둔 기준에 맞게 만료되는지 검증합니다. 복구에 실패했다면 만료 기간을 늘리는 데 그치지 말고 저장 위치, 백업 책임, 복구 승인 절차 중 어느 지점이 끊겼는지 기록하세요.

조직에서 쓰는 파이프라인에 보관 설정이 있다면 조직·저장소·개별 항목 중 어떤 수준의 규칙이 우선하는지 공식 문서에서 확인해야 합니다. 예를 들어 파이프라인 실행과 테스트 데이터 보관 정책은 공식 보관 정책 문서에서 설정 범위와 적용 대상을 검토할 수 있습니다. 법적·계약상 보관 기간은 이 기술 설정만으로 결정하지 말고, 귀사의 정책과 담당 부서 확인을 거치세요.

현재 모든 것을 한 대의 Mac 작업 폴더에 두면 노드 장애나 정리 작업이 곧바로 자료 접근 중단으로 이어질 수 있고, 팀이 같은 환경을 공유할 때 권한과 책임 경계도 불명확해질 수 있습니다. 반면 보관 자료를 별도 위치로 옮기지 않고 빌드 노드만 추가해도 증거 보존 문제는 해결되지 않습니다. 장기 보관은 독립 저장소와 복구 검증으로 처리하고, 빌드 수요가 변동하거나 별도 테스트 노드가 필요할 때만 원격 Mac을 보완 자원으로 검토하세요.

이번 주 점검에서 빌드 노드와 데이터 보관 역할을 분리해야 한다면, 원격 Mac 노드 구성 선택을 확인해 CI 환경에 필요한 자원과 운영 범위를 검토할 수 있습니다. 임시 테스트나 탄력적인 빌드 자원이 필요한 경우에는 VPSMAC의 원격 Mac 환경을 살펴보세요. 다만 archive와 dSYM의 장기 보관, 접근 제어, 복구 책임은 별도 저장 정책으로 유지해야 합니다.