GitHub Actions 캐시 모드는 어떻게 설정할까? 2026 기업 맥 CI 캐시 오염 방지 가이드

신뢰할 수 없는 PR이 캐시에 접근해도 되는지 판단하기 어렵고, 맥 러너가 계속 남아 있나요? 가장 빠른 해결은 작업 신뢰도에 따라 권한을 나누는 것입니다. 신뢰할 수 없는 작업은 read 또는 none으로 제한하고, 신뢰된 워크플로만 필요한 경우 캐시를 쓰게 하세요. cache-mode는 호스트 격리나 정리 기능이 아닙니다.

이 글은 기업 GitHub Actions 정책을 담당하는 IT 및 플랫폼 엔지니어를 위한 설정 기준을 제공합니다.
iOS와 macOS CI 책임자는 캐시에서 맥 빌드 작업으로 위험이 이어지는 경로를 점검할 수 있습니다.
보안 담당자는 비신뢰 코드와 서명 자격 증명의 분리 여부를 확인할 수 있습니다.

권한 모드와 복구 동작

GitHub Actions 캐시 모드 기업 설정은 캐시를 복원하는 권한과 저장하는 권한을 따로 살펴야 합니다. 아래 표는 각 모드의 의도된 동작을 요약한 것입니다. 실제 적용 전에는 GitHub의 cache-mode 발표와 모드별 동작 및 워크플로 문법을 확인하세요.

read, write, none은 어떤 차이가 있나요? read는 복원만 허용하고, write는 복원과 저장을 허용합니다. none은 둘 다 허용하지 않습니다. write-only는 기존 캐시를 가져오지 않고 새 캐시만 저장하려는 경우에 씁니다. 이 구분은 캐시 접근 권한이지 코드 실행 권한이나 호스트 보안 설정이 아닙니다.

모드를 생략했을 때의 동작을 추정해 정책을 만들지 마세요. GitHub가 공개한 문법과 기능 지원 범위를 다시 확인한 뒤, 워크플로에 모드를 명시하고 실행 로그로 실제 결과를 확인하는 편이 안전합니다.

트리거 신뢰도와 쓰기 자격

트리거 이름만 보고 안전하다고 결론 내리면 안 됩니다. 누가 코드를 바꿀 수 있는지, 워크플로가 어떤 자격 증명을 받는지, 이후 어떤 작업이 그 결과를 가져오는지를 함께 확인하세요. GitHub의 이벤트별 워크플로 동작 문서는 트리거에 따른 차이를 설명합니다.

이 표는 조직 정책의 출발점입니다. 특히 pull_request_target은 기본 브랜치의 권한 문맥에서 실행될 수 있어, 외부 코드를 내려받아 실행하면 안 됩니다. 안전한 pull_request_target 사용 지침을 검토하고, 비신뢰 입력이 있는 작업은 캐시 쓰기 권한과 서명 자격 증명에서 분리하세요.

pull request 작업은 어떤 캐시 권한으로 시작해야 하나요? 외부 기여가 가능한 작업은 read 또는 none으로 시작하세요. 캐시 복원도 위험 입력을 가져올 수 있으므로, 빌드가 캐시 내용에 의존하지 않거나 출처를 검증할 수 없다면 none을 선택합니다. 신뢰된 작업으로 캐시를 넘겨야 한다면 검증한 산출물만 별도 단계에서 처리하세요.

캐시는 비밀 저장소가 아닙니다. GitHub의 의존성 캐시 보안 안내는 캐시 접근과 분기 범위의 보안 경계를 설명합니다. 토큰, 서명 자료, 민감한 설정 파일을 캐시에 넣지 말고, 복원된 파일은 검증 전까지 신뢰하지 마세요.

캐시 범위와 오염 영향

캐시 키가 정확해 보여도 복구 키가 더 넓은 범위의 캐시를 가져올 수 있습니다. 키를 만들 때 운영체제, 도구 체인, 잠금 파일 등 입력에 영향을 주는 항목을 반영하고, 복구 키가 어느 분기와 작업에서 생성된 캐시까지 찾는지 확인하세요. 캐시 키 자체가 신뢰 경계를 만들지는 않습니다.

Xcode 빌드에서 실행 파일이나 빌드 스크립트가 캐시로 복원된다면, 해당 결과를 검증된 코드로 간주하지 마세요. GitHub 캐시 동작 설명을 기준으로 저장 범위와 복원 절차를 검토하고, 캐시를 사용할 수 없을 때도 빌드가 안전하게 실패하거나 캐시 없이 진행하는지 확인하세요.

신뢰할 수 없는 PR이 신뢰된 분기의 캐시에 쓰지 못하게 하려면 어떻게 하나요? 비신뢰 작업에는 쓰기 모드를 주지 말고, 신뢰된 브랜치의 캐시를 수정할 수 있는 별도 경로가 있는지 점검하세요. 복구 키와 분기 범위도 함께 검토해야 합니다. 캐시가 분리되어 있더라도 복원된 콘텐츠를 자동으로 신뢰해도 된다는 뜻은 아닙니다.

지속형 맥 러너의 격리 경계

원격 캐시 권한과 self-hosted Mac Runner의 로컬 상태는 별개의 통제 대상입니다. 캐시 모드가 작업 폴더를 초기화하거나 키체인, 도구 설정, 작업 후 남은 자격 증명을 지워주지는 않습니다. GitHub의 자체 호스팅 러너 보안 지침은 자체 호스팅 러너에서 비신뢰 워크플로를 실행할 때의 보안 위험을 다룹니다.

캐시 권한만으로 지속형 맥 러너를 보호할 수 있나요? 아닙니다. 캐시 접근을 none으로 막아도 같은 호스트에서 다음 작업이 실행된다면 로컬 파일이나 도구 상태가 남을 수 있습니다. 비신뢰 작업은 별도 러너 그룹이나 폐기 가능한 깨끗한 환경에서 실행하고, 작업 후 재생성 또는 정리 여부를 별도로 검증하세요. 서명 자격 증명은 해당 작업 환경에 노출되지 않게 분리해야 합니다.

맥 실행 환경을 자체 운영할 때는 가상화 여부만 보지 말고 실제 격리와 초기화 책임을 확인해야 합니다. 실제 맥과 가상화된 macOS 환경의 차이를 검토하면 워크로드와 격리 요구에 맞는 실행 형태를 비교하는 데 도움이 됩니다.

배포 전 확인 목록

아래 항목을 테스트 브랜치에서 실행하고 증거를 남기세요. 결과는 설정 파일뿐 아니라 실행 로그, 권한 화면, 정리 절차까지 연결해 확인해야 합니다.

• [ ] 각 이벤트의 코드 작성자와 신뢰 수준을 기록했습니다.
• [ ] 비신뢰 PR의 캐시 모드를 read 또는 none으로 명시했습니다.
• [ ] pull_request_target에서 외부 코드를 내려받아 실행하지 않는지 확인했습니다.
• [ ] 캐시 복원 로그와 저장 로그를 각각 확인해 의도한 동작과 일치시켰습니다.
• [ ] 복구 키와 분기 범위가 신뢰된 캐시를 비신뢰 작업에 노출하지 않는지 확인했습니다.
• [ ] 워크플로 권한과 서명 자격 증명을 캐시 쓰기 권한과 별도로 검토했습니다.
• [ ] 지속형 맥 러너에서 작업 후 파일, 도구 상태, 자격 증명 정리 절차를 확인했습니다.
• [ ] 캐시가 없거나 접근이 거부된 경우의 실패 및 대체 동작을 테스트했습니다.

신뢰된 작업과 비신뢰 작업을 각각 실행해 복원·저장 로그를 비교하세요. 테스트 결과를 일반적인 보장으로 확대하지 말고, 사용 중인 워크플로 문법과 실행 환경에서 확인한 기록으로 남기세요. 이 기록은 정책 검토와 변경 승인 때도 재사용할 수 있습니다.

승인 기준과 적용 판단

아래 평가는 처리량 측정이 아니라 정책 검토용 위험 등급입니다. 모든 기준이 충족되지 않으면 전체 배포 대신 격리 강화 또는 캐시 비활성화를 선택하세요.

플랫폼, 보안, 개발 담당자가 함께 정책에 승인할 때는 트리거별 권한, 캐시 복원·저장 로그, 맥 러너 정리 증거, 자격 증명 분리 결과를 확인하세요. 권한 검증은 통과했지만 호스트 정리 증거가 없다면 확대 적용을 보류하고, 해당 작업을 격리된 환경으로 옮기세요.

다음 단계 선택

현재 방식이 장기간 유지되는 자체 맥 러너라면 로컬 상태 정리, 도구 체인 유지, 자격 증명 분리 책임을 계속 직접 부담합니다. 또한 비신뢰 작업과 신뢰된 작업이 같은 호스트를 공유하면 캐시 권한만으로 작업 간 오염을 막을 수 없습니다. 반대로 맥 장비를 직접 구매하면 초기 조달과 유지 관리도 조직이 맡아야 합니다.

일시적인 테스트 환경이나 수요 변동이 있는 빌드 작업이라면 MacDate의 원격 맥 이용 조건과 비용을 살펴보고, 기존 러너를 유지할지 임시 용량을 보완할지 비교할 수 있습니다. 맥 미니 이용 요금 안내를 확인하되, 실제 격리 방식과 정리 책임은 도입 전에 별도로 검증하세요. GitHub Actions 캐시 권한, 호스트 정리, 서명 자격 증명 분리가 모두 확인된 뒤에만 적용 범위를 넓히는 것이 안전합니다.

마지막 업데이트: 2026년 9월 24일. GitHub의 cache-mode 발표와 워크플로 문법, 캐시 및 자체 호스팅 러너 보안 문서를 기준으로 확인했습니다. 배포 전에는 최신 문서에서 지원 범위와 기본 동작을 다시 검토하세요.