GitHub Actions cache-mode 공개: 빌드 캐시도 최소 권한으로 운영할 때

GitHub는 2026년 9월 10일 GitHub Actions의 cache-mode를 모든 요금제에 정식 제공한다고 발표했다. 핵심은 빌드 속도를 위한 캐시를 하나의 암묵적 권한으로 두지 않고, 워크플로 또는 작업(job)마다 read, write, write-only, none으로 나누는 것이다. 인력이 적은 팀에도 의미가 크다. CI 권한 검토에서 토큰과 시크릿만 보고 캐시는 빼놓기 쉬웠기 때문이다. 다만 새 옵션을 켜는 것만으로 공급망 위험이 사라지는 것은 아니다. 누가 어떤 이벤트로 캐시를 쓰고, 이후 어떤 신뢰 높은 작업이 그 캐시를 실행 가능한 입력으로 쓰는지까지 연결해서 봐야 한다.

9월 10일 발표에서 확인된 변화

GitHub의 공식 발표에 따르면 read는 복원만, write는 복원과 저장을, write-only는 저장만 허용하며 none은 캐시 접근을 모두 막는다. 작업 수준 설정이 워크플로 수준 설정보다 우선하고, 재사용 워크플로에는 호출자가 부여한 범위보다 높은 캐시 권한이 전달되지 않는다. 설정하지 않은 기존 워크플로는 기존 보안 기본값을 유지한다.

공식 캐시 문서는 캐시가 브랜치나 태그 범위에 따라 공유되며, 읽을 수 있는 실행은 내용을 그대로 추출할 수 있다고 설명한다. 캐시에는 서명이나 무결성 검증이 자동으로 붙는 것이 아니므로, 복원된 파일은 신뢰할 수 없는 입력으로 취급해야 한다. 특히 외부 사용자가 영향을 줄 수 있는 pull_request_target, issue_comment, workflow_run 같은 이벤트가 기본 브랜치 범위의 캐시를 오염시키면, 나중의 고권한 워크플로가 이를 복원해 실행할 위험이 있다.

확인된 사실: 저신뢰 이벤트에는 기본적으로 읽기 전용이 적용되지만, 명시적으로 쓰기 권한을 주면 그 기본값을 덮어쓸 수 있고 GitHub는 경고 주석을 표시한다.

POEMORA 해석: 경고는 통제가 아니라 신호다. 승인 절차 없이 경고를 무시할 수 있다면 운영상 권한 분리는 끝난 것이 아니다.

한국 중소팀이 먼저 그릴 권한 지도

저장소 수가 적어도 워크플로 역할은 분리하는 편이 낫다. 다음 표는 도입 검토의 출발점이다.

먼저 모든 워크플로의 트리거, 캐시 경로, 복원 뒤 실행되는 파일, 호출하는 재사용 워크플로를 한 장에 적는다. 그다음 기본값이 아니라 업무 필요로 모드를 부여한다. “빌드가 빠르니까”는 쓰기 권한의 근거가 아니다. 누가 갱신해야 하는지, 실패하면 어떤 캐시를 삭제하고 어떻게 재빌드하는지까지 담당자를 붙여야 한다.

실패와 복구를 캐시 삭제로 끝내지 않는 법

캐시 이상이 의심되면 해당 키 삭제만 하고 정상화 선언을 해서는 안 된다. 같은 키가 다시 생성되는 경로가 남아 있으면 재발한다. 실무 순서는 다음처럼 짧게 고정할 수 있다.

1. 의심 실행을 중지하고 관련 워크플로의 캐시 쓰기를 임시로 none으로 낮춘다.
2. 캐시 키와 브랜치 범위, 최초 생성 실행, 복원 실행을 기록한다.
3. 신뢰된 커밋에서 의존성을 새로 받아 캐시 없이 빌드하고 결과를 비교한다.
4. 외부 입력이 캐시 경로에 들어가는지와 복원 파일이 스크립트로 실행되는지 점검한다.
5. 오염 경로를 닫은 뒤 신뢰된 push나 별도 생성 작업에서 새 키로 캐시를 만든다.

캐시 키에는 잠금 파일 해시뿐 아니라 런타임·운영체제·중요 도구 버전을 포함해 잘못된 재사용 범위를 줄이는 것이 좋다. 캐시에 토큰, 자격 증명, 환경 파일을 넣지 않는 원칙도 별도 검사 항목으로 둔다. GitHub 공식 문서 역시 민감정보를 캐시 경로에 저장하지 말라고 명시한다.

도입 여부를 가르는 네 가지 질문

cache-mode는 모든 팀이 즉시 복잡한 정책을 만들라는 뜻이 아니다. 아래 질문 중 하나라도 “모른다”면 먼저 관찰과 목록화가 필요하다.

• 외부 사용자가 시작할 수 있는 이벤트와 내부 전용 이벤트를 구분했는가?
• 캐시 복원 후 실행되는 파일과 단순 데이터 파일을 구분했는가?
• 재사용 워크플로 호출 체인에서 권한이 어디서 줄어드는지 확인했는가?
• 캐시 없이 재현 가능한 빌드와 사고 시 삭제·재생성 절차가 있는가?

작은 팀의 현실적인 1차 목표는 모든 YAML을 재설계하는 것이 아니다. 고권한 배포 작업은 none, 저신뢰 검사는 read, 신뢰된 기본 브랜치 빌드만 write로 명시하고 한 달간 경고와 캐시 실패를 관찰하는 정도면 충분하다. 이후 빌드 시간과 실패율을 비교해 write-only 생성 작업을 분리할지 결정한다.

자동화 운영 기준으로 남길 것

이 변화의 본질은 캐시를 성능 옵션에서 권한 자원으로 승격한 데 있다. POEMORA는 도입 판단을 “새 문법을 쓸 수 있는가”보다 “권한 근거와 복구 책임을 설명할 수 있는가”로 본다. 설정 변경은 코드 리뷰 대상이어야 하고, 저신뢰 이벤트에 쓰기 권한을 주는 예외는 만료일과 승인자를 남겨야 한다.

팀의 CI/CD 권한과 실패 복구 흐름을 함께 정리해야 한다면 POEMORA 자동화 서비스에서 현재 워크플로를 기준으로 점검할 수 있다. 먼저 한 저장소에서 권한 지도를 만들고 캐시 없는 복구 훈련을 해본 뒤 확대하는 편이 안전하다.