GitHub Actions macOS Runner의 iOS 서명 키는 어디에 둘까? 2026년 기업 선택

빌드가 끝났는데도 공유 Mac에 서명 키가 남았는지 확인하기 어렵다면, 생산 서명 작업의 경계를 다시 정해야 합니다.
가장 빠른 해법은 서명 키를 재사용 Runner에 장기 보관하지 않고, 신뢰된 배포 작업에만 필요한 권한을 주어 격리된 작업에서 임시 키체인을 사용한 뒤 정리 여부를 확인하는 것입니다.

기업 IT·보안 담당자는 iOS 배포 자산의 보관, 권한 부여, 폐기 절차를 검토할 때 참고할 수 있습니다.
플랫폼 엔지니어는 GitHub Actions macOS Runner에 자격 증명을 주입하고 작업 후 정리하는 흐름을 설계할 때 활용할 수 있습니다.
iOS 기술 책임자는 기존 공유 빌드 노드가 생산 서명에 적합한지 판단할 수 있습니다.

GitHub Actions macOS Runner의 iOS 서명 키 관리 기준

서명 자산은 보관 위치만 정한다고 안전해지지 않습니다. GitHub Secrets는 워크플로에서 값을 사용할 수 있게 하는 자격 증명 관리 수단이고, macOS 키체인은 실행 중 서명 작업이 인증 자료를 이용하는 장소입니다. 두 기능 모두 Runner에서 여러 작업이 서로의 파일이나 프로세스에 접근할 수 있는지를 자동으로 해결하지는 않습니다.

Apple은 코드 서명에서 인증서와 그에 대응하는 개인 키가 서명 신원의 일부임을 설명합니다. 따라서 인증서 파일만 숨기는 데 그치지 않고, 개인 키가 어떤 작업에 제공되고 작업 뒤 어디에 남는지까지 확인해야 합니다. Apple의 코드 서명 인증서 설명과 팀의 서명 인증서 공유 안내를 기준으로 서명 자산의 범위를 확인할 수 있습니다.

표의 평가는 팀이 선택을 비교하기 위한 기준이지, 각 플랫폼의 보안 등급이나 보증을 뜻하지 않습니다. GitHub Secrets의 적용 범위와 동작은 공식 Secrets 문서에서 확인하고, 외부 보관소는 해당 제품의 공식 문서로 실제 지원 기능을 따로 검증해야 합니다. 암호화된 보관과 실행 중 격리는 서로 다른 통제 항목입니다.

자격 증명 보관과 워크플로 권한은 따로 평가합니다

GitHub Secrets와 키체인 중 어디에 저장해야 합니까?

iOS CI 서명 자격 증명의 장기 보관 장소와 실행 중 사용 장소를 구분해야 합니다. GitHub Secrets는 워크플로가 비밀값을 참조하는 경로이고, 키체인은 Mac에서 서명 도구가 인증 자료를 사용하는 실행 환경입니다. 그러므로 “키체인에 가져왔으니 보관도 끝났다”거나 “Secrets에 넣었으니 실행 환경도 격리됐다”고 판단하면 안 됩니다.

외부 보관소를 선택한다면 승인된 작업만 자격 증명을 가져갈 수 있는지, 접근 기록을 검토할 수 있는지, 회수와 교체를 누가 담당하는지 확인합니다. 이런 기능은 선택한 제품과 설정에 따라 다르므로 기능을 일반화하지 않습니다. GitHub 측 보관과 권한 범위는 Secrets 관련 공식 설명으로 확인하고, 팀이 사용하려는 외부 보관소의 문서와 실제 설정을 별도로 대조합니다.

자체 호스팅 Runner에 개인 키를 안전하게 저장할 수 있습니까?

자체 호스팅 Runner를 여러 작업이 재사용한다면, 개인 키를 상시 저장하는 구성을 기본값으로 삼지 않는 편이 낫습니다. GitHub는 자체 호스팅 Runner가 신뢰할 수 없는 워크플로의 영향을 받을 수 있다고 안내하며, 자체 호스팅 환경이 작업마다 깨끗한 상태로 초기화된다고 전제하지 말 것을 경고합니다. GitHub의 자체 호스팅 Runner 문서와 Actions 보안 사용 안내를 확인하십시오.

운영팀은 문서에 명시된 플랫폼 동작과 자체 정책을 구분해야 합니다. 예를 들어 작업별 임시 계정, 작업 공간 분리, 서명 작업 전용 Runner, 작업 뒤 확인 절차는 팀이 설계하고 검증할 통제입니다. 이를 GitHub가 자동으로 제공하는 격리 기능처럼 설명해서는 안 됩니다.

실행 격리와 허용 범위가 서명 노출을 좌우합니다

서로 다른 저장소의 작업이 한 Mac에서 서명 키를 읽지 못하게 하려면 어떻게 합니까?

우선 Runner를 공유하는 저장소와 워크플로의 신뢰 수준을 분류합니다. 같은 Mac에서 신뢰 수준이 다른 작업이 연속 실행된다면, 파일 권한만으로 경계가 충분한지 가정하지 말고 작업 계정, 프로세스, 작업 디렉터리, 키체인 접근 권한이 실제로 분리되는지 시험해야 합니다. 검증할 수 없다면 생산 서명 작업을 별도 Runner로 옮기는 판단이 우선입니다.

비밀값을 받을 수 있는 작업은 배포 목적과 신뢰된 소스로 제한합니다. GitHub 환경 승인은 배포 승인 절차를 구성하는 데 쓸 수 있지만, 그 자체가 Runner를 작업 간 격리된 실행 환경으로 바꾸지는 않습니다. 환경 설정과 승인 동작은 배포 환경 문서에서 확인하십시오. 작업이 요청하는 토큰 권한도 필요한 범위로 줄이고, 워크플로에서 사용하는 Action의 출처와 변경 사항을 검토합니다. 워크플로 권한 설정 문서는 권한 범위를 확인할 때 참고할 수 있습니다.

환경 승인이나 Secrets 접근 제한이 있더라도, 같은 호스트에서 실행되는 다른 작업의 파일·계정·프로세스 접근 가능성은 별도로 점검해야 합니다.

임시 키체인과 작업 종료 절차를 검증합니다

macOS 임시 키체인은 서명 작업의 실행 단계에 사용할 수 있습니다. Apple은 임시 키체인을 만들기 위한 키체인 생성 인터페이스를 문서화합니다. 이 인터페이스가 있다는 사실만으로 키 가져오기, 접근 권한 설정, 작업 후 제거가 자동으로 안전하게 완료된다는 뜻은 아닙니다.

작업 흐름은 다음 순서로 설계하고, 각 단계의 증거를 남깁니다.

• 신뢰 경계 정리: 생산 서명을 수행할 저장소와 워크플로를 식별합니다. 검토되지 않은 외부 변경이나 신뢰할 수 없는 작업이 같은 Runner에 들어오는 경로를 확인합니다.
• 자격 증명 범위 축소: 배포에 필요한 자격 증명만 선택하고, 누가 승인·교체·회수하는지 정합니다. GitHub Secrets 또는 외부 보관소에서 실제로 허용되는 작업 범위를 확인합니다.
• 실행 중 가져오기: 인증 자료를 필요한 작업에서만 키체인에 가져옵니다. 키체인 이름과 파일 경로를 로그에 출력하지 않도록 하고, 작업 계정이 접근할 수 있는 범위를 점검합니다.
• 서명 작업 수행: 서명 도구가 의도한 인증서를 사용했는지 결과를 확인합니다. 비밀값이나 민감한 서명 자료를 로그와 빌드 산출물에 남기지 않도록 설정을 검토합니다.
• 작업 후 정리 확인: 임시 키체인과 임시 파일의 제거를 요청하는 단계와 실제 제거 여부를 확인하는 단계를 분리합니다. 명령이 성공했다는 기록만으로 키가 남지 않았다고 단정하지 않습니다.
• 증거 검토: 실행 로그의 비밀값 노출 여부, 접근 기록, 계정과 디렉터리의 상태, 키체인 정리 결과를 확인합니다. 반복 실행과 실패 중단 상황에서도 같은 확인이 가능한지 시험합니다.

GitHub Actions 작업이 끝나면 가져온 서명 키를 어떻게 처리해야 합니까?

작업은 임시 키체인과 작업 중 만든 임시 파일을 정리하도록 구성하고, 별도 검증으로 정리 결과를 확인해야 합니다. 실패나 취소 경로에서도 정리 절차가 실행되는지 확인하며, 성공 경로만 시험한 결과를 전체 완료 증거로 취급하지 않습니다. 삭제 명령의 실행 기록과 실제 상태 확인은 서로 다른 증거입니다.

감사 기록에는 자격 증명을 노출하지 않은 채 작업 식별 정보, 사용한 권한 범위, 승인 내역, 정리 확인 결과를 남기는 방안을 검토합니다. 팀이 정한 보존 기간과 검토 책임도 문서화합니다. 플랫폼이 제공한다고 확인되지 않은 감사 기능이나 삭제 보장은 있다고 가정하지 않습니다.

팀 위험도에 따라 Runner 구성을 선택합니다

아래 조건 분기는 팀의 서명 흐름을 파일럿으로 평가할 때 사용합니다.

• 서명 전용의 신뢰된 배포 작업이며, 다른 작업과 실행 경계를 확인할 수 있다면 제한된 자격 증명 주입과 작업 중 임시 키체인을 검토합니다. 정리와 로그 검토를 실제 실행으로 확인하기 전에는 생산 적용을 확정하지 않습니다.
• 여러 팀이나 서로 다른 신뢰 수준의 저장소가 같은 Mac을 사용한다면 먼저 Runner와 자격 증명 권한을 분리합니다. 분리가 불가능하거나 경계를 검증할 수 없다면 생산 서명을 공유 노드에 올리지 않습니다.
• 키체인 제거, 임시 파일 정리, 접근 기록을 확인할 수 없다면 스크립트 성공만으로 승인하지 않습니다. 격리 가능한 실행 환경을 마련하거나 서명 작업을 별도 운영 경계로 옮깁니다.
• 외부 보관소의 접근·감사 기능이 문서와 실제 설정으로 확인되지 않는다면 해당 기능을 전제로 아키텍처를 승인하지 않습니다. 보관소 선택을 미루고 권한과 증거 요구사항부터 정리합니다.

시험 운영 기록에는 작업이 사용할 자격 증명, Runner를 공유하는 범위, 승인 조건, 실패 시 처리, 정리 증거를 포함합니다. 마지막으로 실제 저장소와 실제 Runner에서 기록을 대조해야 합니다. 공유 원격 Mac의 팀 권한 관리에 관한 안내도 팀의 접근 경계를 검토할 때 함께 참고할 수 있습니다.

현재 로컬 공유 Mac이나 기존 빌드 서버에 의존하면 장비 구매와 교체, 운영 담당자의 패치·계정 관리, 팀별 실행 경계 구성 부담이 남을 수 있습니다. 반대로 원격 Mac 임대는 시험용 macOS 실행 환경을 확보하고 장비 조달 부담을 줄이는 선택지가 될 수 있지만, 서명 키의 보관·주입·정리 통제까지 대신해 주는 것은 아닙니다. ArmMacs의 원격 Mac 임대 플랜을 검토할 때도 실제 사용 환경에서 계정 경계와 정리 증거를 먼저 확인하고, 기업 데이터 취급 조건은 개인정보 처리 안내와 함께 살펴보는 편이 좋습니다. 안정적인 전용 장비와 물리적 인터페이스가 필요하거나 장기 상시 부하가 확정된 팀은 자체 Mac 구매도 비교해야 합니다.