배포 파일은 만들어졌지만, 증명이 그 파일을 가리키는지 확신하기 어렵습니다.
가장 빠른 해결은 최종 배포 파일의 요약값과 저장소·커밋·워크플로 신원을 함께 검증하는 것입니다. GitHub Artifact Attestations는 빌드 출처를 확인하는 데 쓰이며, 테스트 통과나 코드 안전성, Apple 서명과 공증을 대신하지 않습니다.
기업 CI 책임자라면 iOS 산출물의 출처 검수 절차를 만들 때 참고하세요.
공급망 보안 담당자라면 증명이 입증하는 범위와 한계를 구분할 수 있습니다.
릴리스 담당자라면 출처 검증을 테스트, 서명, 배포 승인 기록과 연결할 수 있습니다.
GitHub Artifact Attestations iOS CI 검수 범위 정하기
증명 검수의 대상은 “믿을 만해 보이는 빌드”가 아니라 현재 배포하려는 파일입니다. GitHub 공식 문서는 Artifact Attestations를 빌드 산출물의 출처를 설정하고 소비 시 검증하는 방법으로 설명합니다. 따라서 검수 결과에는 파일 자체와 증명에 연결된 요약값, 그리고 증명을 만든 워크플로의 신원이 포함되어야 합니다. 공식 기능 설명
검증을 통과해도 코드가 안전하거나 테스트에 성공했다는 뜻은 아닙니다. Apple 코드 서명과 배포 절차도 별도로 확인해야 합니다. Apple은 코드 서명을 앱의 출처와 코드 변경 여부를 확인하는 보안 기능으로 설명합니다. Apple의 코드 서명 설명
먼저 검수 지표와 책임을 분리합니다
다음 항목을 각각 확인하세요. 한 항목의 성공을 다른 항목의 성공으로 간주하지 않습니다.
| 검수 지표 | 확인할 대상 | 통과 판단 |
|---|---|---|
| 산출물 출처 | 저장소, 커밋, 증명에 기록된 정보 | 승인된 저장소와 릴리스 코드 버전인지 확인합니다. |
| 파일 요약값 | 증명 대상과 실제 배포 파일 | 검증한 파일이 전달·업로드할 최종 파일과 일치해야 합니다. |
| 워크플로 신원 | 워크플로 파일, 저장소 위치, 실행 경로 | 조직이 승인한 빌드 경로인지 정책과 대조합니다. |
| 검증 가능 조건 | 저장소 공개 범위와 조직의 기능 자격 | 해당 저장소에서 생성과 소비 검증이 가능한지 각각 확인합니다. |
| 별도 배포 게이트 | 테스트, 서명, 승인 기록 | 각 결과를 독립된 증거로 보관합니다. |
조직이 신뢰하는 워크플로 목록은 각 기업의 승인 정책으로 정해야 합니다. 공식 검증 기능을 켰다는 이유만으로 모든 워크플로를 신뢰 목록에 넣지 마세요. 재사용 워크플로를 포함한 검증 구성은 GitHub의 보안 등급 향상 안내에서 확인할 수 있습니다.
실제 릴리스 흐름으로 검증합니다
첫 단계: 저장소 자격과 기능 범위를 확인합니다
먼저 각 저장소에서 증명을 생성하고 소비 측에서 검증할 수 있는지 확인합니다. 저장소 공개 범위나 조직 요금제에 따른 기능 자격은 달라질 수 있으므로, 과거에 성공한 저장소의 설정을 다른 저장소에 그대로 적용하지 마세요. 현재 자격은 GitHub 기능별 이용 조건에서 확인합니다.
검증은 생성과 소비를 나누어 확인해야 합니다. CI에서 증명이 생성됐다는 로그만으로 배포 서버나 릴리스 절차에서 검증 가능하다고 판단하지 마세요.
다음 단계: 배포할 최종 파일을 고정합니다
검증할 파일의 위치와 이름을 릴리스 작업에서 분명하게 정합니다. iOS 앱은 아카이브한 뒤 배포 목적에 맞게 내보낼 수 있습니다. 그러므로 아카이브 파일과 내보낸 파일을 같은 산출물로 취급하지 마세요. Apple의 앱 아카이브 및 내보내기 안내는 이 두 작업을 구분해 설명합니다.
예를 들어 아카이브를 만든 뒤 배포용 파일을 별도로 내보내는 파이프라인이라면, 어떤 파일에 증명을 연결할지 결정해야 합니다. 최종 전달물이 바뀌었다면 그 전달물을 대상으로 검증 절차를 다시 수행합니다.
세 번째 단계: gh attestation verify 결과를 확인합니다
GitHub Actions에서 산출물 증명을 만든 뒤, 소비 측에서 gh attestation verify로 검증할 파일을 지정합니다. 명령의 저장소 인수와 검증 옵션은 실제 저장소 구성에 맞춰 공식 안내를 확인하세요. 오프라인 검증 안내와 증명 REST API 문서는 검증 방식과 결과를 확인할 때 참고할 수 있습니다.
검증 성공 여부만 기록하지 말고, 대상 파일, 요약값, 저장소와 커밋, 워크플로 신원도 함께 보관하세요. 검증 실패 시에는 파일 불일치인지, 예상하지 못한 워크플로인지, 증명 자체를 찾지 못한 것인지 구분해 릴리스를 중단하고 담당자가 재검토하도록 설정합니다.
네 번째 단계: 워크플로가 승인된 경로인지 대조합니다
증명에 표시된 출처가 조직에서 허용한 저장소와 워크플로인지 확인합니다. 브랜치나 실행 경로가 예상과 다른데도 서명된 증명이라는 이유로 승인하지 마세요. 증명 검증은 신원을 확인하는 수단이지, 조직의 신뢰 정책을 대신 만들어주는 기능은 아닙니다.
특히 재사용 워크플로를 쓰는 경우에는 호출한 워크플로와 실제 빌드 로직이 있는 위치를 승인 정책에 맞춰 확인합니다. 정책에 포함할 신원 필드와 허용 경로는 플랫폼·보안 담당자가 함께 정하고, 변경 시 검수 기준도 갱신하세요.
다섯 번째 단계: 테스트와 Apple 서명을 별도로 확인합니다
테스트 결과는 해당 커밋과 빌드 작업에 연결해 보관합니다. 서명 검증은 실제 배포 파일과 배포 방식에 맞춰 별도로 수행합니다. iOS 앱의 배포 서명을 macOS 소프트웨어의 공증과 같은 절차로 보지 마세요. Apple의 macOS 소프트웨어 공증 안내는 macOS 배포용 절차를 설명합니다.
이렇게 나누면 출처 증명은 통과했지만 테스트가 실패한 경우, 또는 서명 검증이 실패한 경우에도 원인을 혼동하지 않고 배포를 차단할 수 있습니다.
여섯 번째 단계: 통과와 실패 증거를 함께 남깁니다
릴리스 기록에는 검증한 최종 파일과 요약값, 출처 신원, 테스트 결과, 서명 결과, 승인 담당자를 연결합니다. 실패했을 때 자동으로 재시도할지, 파일을 다시 만들지, 보안 담당자에게 넘길지도 정하세요. 증명 누락과 신원 불일치를 같은 오류로 취급하지 않는 것이 중요합니다.
자주 확인하는 검수 질문
검증 명령이 성공하면 파일을 배포해도 되나요?
아닙니다. 성공 결과는 출처 검수의 일부입니다. 테스트, 서명, 릴리스 승인도 통과했는지 별도로 확인하고, 검증 대상이 실제 업로드 파일인지 대조해야 합니다.
증명에 저장소 이름이 보이면 출처가 신뢰된다고 볼 수 있나요?
그 사실만으로는 부족합니다. 저장소와 커밋이 예상한 코드인지, 워크플로가 조직의 승인 경로인지 확인해야 합니다. 신뢰할 워크플로의 기준은 조직 내부 정책으로 관리하세요.
아카이브에 만든 증명을 내보낸 파일에도 쓸 수 있나요?
파일이 달라졌다면 같은 증명으로 최종 산출물을 검증했다고 단정하지 마세요. 실제 배포 파일을 검증 대상으로 지정하고, 그 파일의 요약값과 증명이 일치하는지 확인해야 합니다.
Artifact Attestations는 Apple 서명이나 공증을 대신하나요?
아닙니다. 출처 증명, 테스트 결과, Apple 서명은 서로 다른 검수 항목입니다. 공증은 macOS 소프트웨어 배포와 관련된 절차이므로 iOS 앱의 서명 검증과 섞지 말고 각각의 결과를 보관하세요.
Mac CI 노드와 배포 증거를 따로 검수합니다
Artifact Attestations는 산출물의 출처를 검증하는 데 도움을 주지만, 빌드에 사용한 Mac 환경이 조직의 보안 기준을 충족한다는 증명은 아닙니다. Mac 노드의 계정 권한, 비밀 정보 접근, 격리와 작업 후 정리 절차는 별도 기준으로 점검해야 합니다. CI 용량을 설계할 때는 기업용 Mac mini 구성 안내에서 실제 전달 조건을 확인하고, 지역별 정보가 필요하면 서울 Mac mini 안내를 참고하세요.
이미 보유한 Mac을 계속 운영하는 방식은 장비 유지와 장애 대응을 직접 맡아야 하고, 일반 클라우드 환경은 macOS 빌드 요건을 충족하지 못할 수 있습니다. 반대로 사용량이 꾸준하고 장기적으로 높은 부하가 예상되거나 물리 인터페이스가 꼭 필요하다면, 직접 장비를 보유하는 편이 맞을 수 있습니다. 필요한 시기에만 Mac 빌드 노드를 확보하려는 팀이라면 MACCOME의 원격 Mac 임대를 검토하고, attestation 검수와 별개로 실제 접속 방식과 작업 환경이 요구 조건에 맞는지 확인하세요.