GitHub는 2026년 9월 10일 cache-mode 공개와 함께 GitHub Actions 캐시 접근을 제어하는 설정을 안내했습니다. 공식 발표에 따르면 이 기능은 모든 요금제에서 사용할 수 있습니다.
증상: Mac CI의 모든 작업이 같은 캐시 권한을 사용해 쓰기 범위가 불필요하게 넓습니다.
빠른 조치: 복원 전용, 복원과 저장, 캐시 접근 차단으로 작업을 나누고 Job별 설정 및 실행 로그로 결과를 확인하세요.
이 글은 Mac CI 캐시를 다루는 개발자, 낮은 신뢰도의 이벤트를 관리하는 보안 담당자, 여러 Apple 프로젝트의 워크플로 규칙을 정하는 플랫폼 팀을 위한 안내입니다.
마지막 업데이트: 2026년 9월 28일. 검증 기준은 GitHub의 cache-mode 발표와 워크플로 문법 문서입니다.
GitHub Actions cache-mode를 권한 기준으로 나눕니다
Mac CI 캐시 권한은 캐시가 맞았는지보다, 각 작업이 캐시에서 무엇을 할 수 있는지를 기준으로 결정해야 합니다. 공식 문서에서 설명하는 선택지는 캐시를 복원하는 권한, 복원과 저장을 허용하는 권한, 캐시 접근을 막는 설정입니다. 실제 설정 이름과 적용 범위는 공식 워크플로 문법에서 확인하세요.
예를 들어 신뢰할 수 있는 브랜치의 빌드 작업은 기존 캐시를 복원하고 결과를 저장할 필요가 있을 수 있습니다. 반면 외부 변경을 검사하는 작업은 캐시를 읽기만 하거나 캐시 없이 실행해도 되는지 따져야 합니다. 배포 승인이나 메타데이터 검사처럼 캐시가 불필요한 작업이라면 접근을 끄는 쪽이 권한을 줄이는 데 유리합니다.
캐시 접근이 줄었다고 워크플로 전체가 안전해지는 것은 아닙니다. 토큰 권한, 비밀값, 실행 코드, 아티팩트 저장 경로도 따로 검토해야 합니다. GitHub의 의존성 캐시 보안 안내는 캐시가 신뢰 경계를 넘을 때 생길 수 있는 위험을 다룹니다. 캐시 오염 가능성을 검토할 때 캐시 설정만으로 모든 공격 경로를 없앨 수 있다고 가정하지 마세요.
Job 우선순위는 설정 파일과 실행 결과로 입증합니다
cache-mode는 워크플로 수준과 Job 수준에서 설정할 수 있으며, Job 수준 설정이 우선합니다. 그래서 워크플로의 기본 권한이 제한적이더라도 특정 Job에 더 넓은 권한을 지정하면 그 Job에는 해당 설정이 적용됩니다. 반대로 Job 설정을 놓치면 의도한 최소 권한과 실제 권한이 달라질 수 있습니다.
설정 변경은 다음 순서로 검증합니다.
- 저장소에서 캐시를 사용하는 워크플로와 Job을 찾아 목록화합니다.
- 각 작업이 캐시 복원, 캐시 저장, 둘 다 불필요 중 무엇인지 기록합니다.
- 워크플로 수준의 기본 설정을 정하고, 예외가 필요한 Job에만 별도 설정을 둡니다.
- 변경 전후의 워크플로 문법을 검토해 설정 위치와 상속 관계를 확인합니다.
- 대표 실행을 발생시켜 로그에서 캐시 복원 및 저장이 각각 허용됐는지 확인합니다.
- 의도하지 않은 저장이나 복원이 보이면 Job 설정을 더 제한하고 다시 실행합니다.
캐시가 적중했거나 Xcode 빌드가 빨라졌다는 사실만으로 권한 설정이 맞았다고 판단하면 안 됩니다. 캐시가 복원됐는지, 새 캐시가 저장됐는지, 둘 중 하나가 차단됐는지를 각각 로그로 대조해야 합니다. Mac CI 작업의 도구 체인과 아티팩트 보존까지 함께 확인하려면 SSHMac 도움말 센터의 관련 안내도 참고할 수 있습니다.
낮은 신뢰도의 이벤트와 재사용 워크플로는 별도로 봅니다
pull_request_target은 이벤트를 처리하는 저장소 권한과 변경 코드의 신뢰 수준을 함께 검토해야 하는 트리거입니다. 캐시 쓰기 권한을 넓히면 신뢰할 수 없는 코드가 캐시에 영향을 줄 가능성이 커질 수 있으므로, 쓰기가 꼭 필요한지부터 판단하세요. GitHub의 안전한 pull_request_target 사용 지침은 이 트리거의 보안상 주의점을 설명합니다.
재사용 워크플로도 호출하는 쪽과 호출되는 쪽을 한 쌍으로 확인해야 합니다. 호출 측이 허용한 캐시 접근 범위를 피호출 워크플로가 넘어설 수는 없습니다. 따라서 피호출 워크플로만 살펴보지 말고, 호출 측의 설정과 실제 실행 결과를 함께 확인하세요. 관련 동작은 재사용 워크플로 공식 안내에서 검토할 수 있습니다.
중간 점검: FAQ
GitHub Actions cache-mode에서는 어떤 권한을 선택할 수 있나요?
복원만 허용할지, 복원과 저장을 모두 허용할지, 캐시 접근을 끌지 작업별로 나눕니다. 권한 이름과 현재 지원 범위는 공식 문서에서 확인하고, 실제 실행 로그에서 복원과 저장 동작이 각각 의도대로 제한되는지 살펴보세요.
Job 설정과 워크플로 설정이 다르면 무엇이 적용되나요?
Job 수준 설정이 우선합니다. 워크플로 전체의 기본 설정만 확인하지 말고, 개별 Job에 별도 설정이 있는지 찾아야 합니다. 캐시 읽기와 쓰기가 모두 예상대로 제한됐는지는 실행 로그로 검증하세요.
pull_request_target에서 캐시 쓰기를 허용해도 되나요?
낮은 신뢰도의 변경 코드를 처리한다면 쓰기 권한을 당연한 기본값으로 두지 마세요. 캐시 쓰기가 필요한 이유를 확인하고, 이벤트와 실행 코드의 신뢰 경계를 검토하세요. GitHub의 해당 트리거 보안 지침도 함께 확인해야 합니다.
재사용 워크플로는 호출 측보다 넓은 캐시 권한을 얻을 수 있나요?
아닙니다. 피호출 워크플로는 호출 측이 부여한 범위보다 높은 권한을 받을 수 없습니다. 양쪽 설정을 함께 검토하고 대표 저장소의 실행 로그로 결과를 확인하세요.
설정 선택은 작업의 신뢰도와 캐시 역할로 결정합니다
아래 비교는 캐시를 사용하는 작업을 권한의 목적에 따라 분류하기 위한 기준입니다. 모든 작업에 같은 설정을 적용하지 말고, 실제 실행 로그에서 각 권한의 효과를 확인하세요.
| 작업 유형 | 권장 접근 방향 | 적합도 | 통과 판정 증거 | 통과하지 못했을 때 |
|---|---|---|---|---|
| 신뢰할 수 있는 브랜치의 반복 빌드 | 복원 및 저장 허용 검토 | 높음 | 복원과 저장 로그가 작업 목적에 부합함 | 저장이 불필요하면 복원 전용으로 축소 |
| 외부 변경을 검사하는 작업 | 복원 전용 또는 접근 차단 검토 | 중간 | 실행 경로가 캐시를 쓰지 않으며 신뢰 경계를 침범하지 않음 | 캐시를 끄거나 트리거와 실행 단계를 분리 |
| 캐시를 쓰지 않는 승인 및 점검 작업 | 접근 차단 | 높음 | 캐시 복원과 저장이 발생하지 않음 | 워크플로와 Job의 설정 위치를 다시 확인 |
| 재사용 워크플로 호출 | 호출 측 범위 안에서 설정 | 높음 | 양쪽 설정과 실행 결과가 일치함 | 호출 측 권한을 제한한 뒤 다시 검증 |
여러 저장소에 적용하기 전에 남길 검증 기록
여러 Apple 프로젝트로 확대하기 전에는 대표 저장소에서 설정, 테스트 조건, 판정 결과, 되돌리는 방법을 함께 기록하세요. 이 기록은 캐시 권한 변경과 워크플로 전체의 안전성 평가를 구분하는 데도 도움이 됩니다. GitHub의 캐시 관리 문서로 저장된 캐시를 확인하고, 안전한 Actions 사용 지침과 함께 권한 경계를 검토하세요.
| 검증 항목 | 통과 기준 | 미통과 시 조치 |
|---|---|---|
| 복원 권한 | 필요한 작업에서만 복원 로그가 확인됨 | 해당 Job의 접근을 제한하고 다시 실행 |
| 저장 권한 | 신뢰도와 작업 목적에 맞는 저장만 확인됨 | 낮은 신뢰도 경로의 쓰기를 제거 |
| Job 우선순위 | Job 설정이 의도한 최종 권한과 일치함 | 워크플로와 Job 설정을 함께 수정 |
| 재사용 워크플로 | 호출 측이 허용한 범위 안에서 동작함 | 호출 측 설정과 피호출 측 동작을 재검증 |
| 회귀와 롤백 | 빌드 결과와 설정 복구 절차를 재현할 수 있음 | 확대 적용을 멈추고 대표 저장소에서 재시험 |
캐시 권한을 줄인 뒤에는 캐시 외의 도구 체인, 인증 정보, 아티팩트 보존 경로도 별도로 점검해야 합니다. 기존 장비에 Mac CI를 붙이면 기기 관리와 로컬 환경 차이를 감수해야 하고, 일반 클라우드 실행 환경은 macOS 전용 빌드와 Xcode 검증에 맞지 않을 수 있으며, 직접 Mac을 구매하면 짧은 기간의 테스트에도 유지와 관리 부담이 생깁니다. 단기간에 실제 Mac 환경이 필요한 팀이라면 SSHMac의 Mac 대여 환경을 검토해 테스트 범위에 맞는지 비교할 수 있습니다. SSHMac의 회사 및 운영 정보를 확인해 서비스 운영 관련 내용을 살펴보고, 필요한 환경과 지원 조건을 비교하세요. 반대로 지속적인 상시 부하나 직접 연결해야 하는 물리 장치가 핵심이라면, 임대보다 전용 장비가 더 적합한지 먼저 따져보세요.