기업 저장소에서 워크플로 실행 보호를 적용하고 검수하려면 무엇부터 해야 하나요?

조직과 저장소의 정책 담당자를 정한 뒤, 배포 및 서명 관련 워크플로 경로와 허용할 실행 주체, 이벤트를 목록으로 만드세요. 지원되는 계정 조건을 공식 문서에서 확인하고 평가 모드로 기존 실행을 관찰합니다. 차단 대상과 필요한 예외의 승인 기록을 확인한 다음, 중요도가 높은 배포 흐름부터 강제 적용하는 편이 안전합니다.

평가 모드에서도 GitHub Actions 실행이 실제로 막히나요?

평가 모드는 정책을 강제 적용하기 전에 어떤 실행이 영향을 받을지 확인하는 단계입니다. 평가 결과만으로 실행이 정책에 의해 차단된다고 간주해서는 안 됩니다. 실제 강제 정책과 결과를 혼동하지 않도록 실행 기록과 정책 인사이트를 대조하고, 강제 적용 단계에서 승인된 테스트를 별도로 수행하세요.

pull_request_target 기본 보호 규칙은 어떤 저장소에 적용되나요?

공식 안내에서 기본 보호 규칙의 대상은 조건을 충족하는 공개 저장소로 한정됩니다. 비공개 및 내부 저장소에 동일한 기본 규칙이 자동 적용된다고 가정하면 안 됩니다. 적용 대상과 평가 또는 강제 적용 상태는 정책 문서와 저장소의 실제 설정에서 확인하세요. 강제 적용 예정일은 2026년 11월 2일로 안내되어 있습니다.

워크플로 보호만으로 자체 관리 맥 러너의 권한까지 제한할 수 있나요?

아니요. 워크플로 실행 보호는 실행을 시작할 수 있는 주체와 이벤트, 정책이 적용되는 경로를 다룹니다. 자체 관리 맥의 운영체제 권한이나 러너 프로세스 격리, 서명 자산 접근을 대신 통제하지 않습니다. 러너 계정 권한을 제한하고 토큰 권한과 비밀 정보 접근 범위를 별도 검토해야 합니다.

GitHub Actions 워크플로 실행 보호는 어떻게 검수할까? 2026 기업 맥 CI 가이드

배포 작업은 정책에 걸리는데 일반 빌드는 그대로 실행되거나, 허용한 작업이 의도와 다른 맥 러너에 배정되나요?

가장 빠른 해법: GitHub Actions 워크플로 실행 보호는 먼저 평가 모드로 기존 작업을 확인한 뒤 단계적으로 강제 적용하세요. 배포와 게시 흐름부터 적용하되, 이 정책이 맥 호스트나 러너 권한까지 격리한다고 판단하면 안 됩니다. 기능은 2026년 9월 17일 정식 제공 단계에 들어갔으며, 적용 범위와 평가 모드는 공식 변경 안내와 설정 문서에서 확인할 수 있습니다.

이 글은 기업 IT 및 GitHub 조직 관리자, 맥 CI 플랫폼 엔지니어, 보안·릴리스 책임자를 위한 검수 가이드입니다.
워크플로 실행 정책과 실제 맥 러너 통제를 구분하고, 강제 적용 전 승인 근거를 남겨야 하는 팀에 적합합니다.

마지막 검토: 2026년 9월 28일. 기능 상태와 기본 규칙 일정은 GitHub의 공식 변경 안내와 실행 보호 문서를 기준으로 확인했습니다.

조직 관리자와 저장소 관리자의 정책 범위

정책은 누가 워크플로를 시작할 수 있는지, 어떤 이벤트를 허용할지, 어느 워크플로 경로에 규칙을 적용할지를 제어합니다. 조직 및 저장소에서 정책을 관리하는 책임자는 상위 정책과 개별 저장소 설정의 관계, 대상 경로, 허용 목록과 예외 승인 근거를 함께 기록해야 합니다. 설정 항목과 적용 조건은 GitHub의 실행 보호 구성 안내를 기준으로 확인하세요.

모든 CI 작업을 같은 위험도로 다루면 정책이 지나치게 넓어집니다. PR 검증과 배포·서명 흐름을 분리해 보세요. 특히 배포 워크플로는 허용된 팀과 자동화 계정, 이벤트, 경로를 명시하고, 일반 빌드는 불필요한 예외를 줄이는 방향으로 검토하는 편이 적절합니다.

책임자가 남길 증거는 다음과 같습니다.

조직 및 저장소별 정책 소유자와 승인자
보호 대상 워크플로 경로와 허용할 실행 주체·이벤트
배포와 일반 CI를 구분한 근거
정책 예외의 사유, 승인자, 재검토 조건
상위 설정과 저장소 설정을 대조한 결과

평가 모드와 정책 인사이트가 제공되더라도, 조직의 구독 조건과 설정에 따라 사용 가능 범위가 달라질 수 있습니다. 활성화 전에 공식 설정 문서에서 해당 계정의 적용 조건을 확인하세요. REST API로 정책을 관리하는 경우에는 Actions 정책 API 문서를 기준으로 권한과 대상 범위를 검토해야 합니다.

맥 CI 플랫폼 팀의 러너 인계 검수

실행 보호 정책과 러너 운영은 서로 다른 통제 지점입니다. 보호 정책이 실행을 허용해도 적절한 맥 노드가 배정되는지, 해당 노드에 필요한 권한만 있는지까지 보장하지 않습니다.

흐름을 다음처럼 나눠 기록하면 책임 경계가 분명해집니다.

실행 주체·이벤트·경로 정책 → 워크플로 스케줄링 → 맥 러너 실행 → 아티팩트 전달

플랫폼 팀은 승인된 테스트 워크플로를 실행해 정책 통과 여부와 러너 배정 결과를 각각 확인해야 합니다. 실행 기록에는 요청한 경로, 이벤트, 실행 주체, 예상 러너 풀, 실제 러너 풀, 산출물 전달 결과를 남깁니다. 잘못된 노드에 배정되는 경우에는 정책 허용 여부와 러너 라벨·그룹 운영을 별도로 조사해야 합니다.

주의: 자체 관리 러너는 워크플로가 실행되는 호스트에 접근할 수 있습니다. 신뢰할 수 없는 코드가 실행되는 작업과 서명·배포 자산에 접근하는 작업을 같은 권한 경계에 두지 마세요. 자체 관리 러너의 보안 지침은 워크플로 보호와 호스트 보안이 별개임을 판단할 때 참고할 자료입니다.

운영 기록은 GitHub 설정 자체와 혼동되지 않도록 내부 검수 문서로 분리할 수 있습니다. 아래는 실제 설정 명령이나 제품 출력이 아니라, 검수 증거를 정리하는 예시입니다.

policy_review:
  owner: platform-team
  protected_workflow_paths:
    - release-workflow
  allowed_actors_and_events: recorded
  evaluation_findings: attached
  runner_assignment_test: passed
  exceptions:
    approval_record: attached
  decision: ready_for_staged_enforcement

passed는 테스트 결과가 기록되었다는 예시일 뿐입니다. 실제 검수에서는 실행 로그와 러너 배정 기록을 근거로 판정해야 합니다. 러너 권한을 검토할 때는 워크플로 실행 보호 정책 외에도 GITHUB_TOKEN 권한 최소화 안내를 확인하세요.

보안 담당자의 pull_request_target 검토

pull_request_target은 기본 브랜치의 권한 맥락에서 실행될 수 있으므로, 포크에서 유입된 변경 사항을 다루는 방식을 점검해야 합니다. 이벤트 이름만 보고 안전하다고 판단하지 마세요. PR의 코드를 체크아웃하거나 실행하는 단계가 있는지, 비밀 정보와 쓰기 권한 토큰에 접근할 수 있는지 실제 워크플로를 읽어야 합니다.

GitHub는 조건을 충족하는 공개 저장소에서 pull_request_target 관련 기본 보호 규칙을 평가 모드로 제공하고, 2026년 11월 2일부터 영향을 받는 저장소에 강제 적용할 예정이라고 안내했습니다. 이 기본 규칙은 비공개 또는 내부 저장소에 적용되지 않습니다. 따라서 회사의 모든 저장소에 동일한 상태가 이미 적용됐다고 가정하지 말고, 저장소 유형과 실제 정책 상태를 확인하세요. 대상과 위험 조건은 pull_request_target 보안 문서에서 검증할 수 있습니다.

보안 담당자는 각 워크플로에 대해 다음을 판정해야 합니다.

외부 기여 코드가 실행되거나 체크아웃되는지
기본 브랜치의 비밀 정보 또는 쓰기 권한 토큰에 접근하는지
실행 주체나 이벤트를 제한하면 필수 자동화가 중단되는지
예외가 필요하다면 소유자와 승인 기록이 있는지

기본 보호를 일괄 해제하거나 모든 저장소에 같은 예외를 복사하는 방식은 피해야 합니다. 워크플로의 실제 동작에 따라 차단, 허용 대상 제한, 승인된 예외 중 하나를 선택하세요.

릴리스 팀의 평가 결과와 단계적 적용

평가 모드는 강제 적용 전에 기존 실행이 새 규칙에 걸리는지 살펴보는 데 쓰입니다. 결과를 곧바로 차단 로그로 해석하지 말고, 예상과 다른 실행이 무엇인지 먼저 분류하세요. 계정이 해당 기능을 지원하는지 확인한 뒤 조직 정책과 저장소 설정을 대상으로 평가 결과를 검토합니다.

단계별 검수

[ ] 배포, 서명, 일반 PR 빌드의 워크플로 경로와 소유자를 정합니다.
[ ] 각 경로의 실행 주체와 이벤트를 확인하고 필요한 허용 대상을 기록합니다.
[ ] 계정의 기능 사용 조건을 공식 문서에서 확인한 뒤 평가 모드를 적용합니다.
[ ] 평가 결과에서 기존 실행 중 정책 영향을 받을 작업과 이유를 대조합니다.
[ ] 정상 PR 빌드, 수동 릴리스, 제한된 실행 주체의 테스트를 수행하고 기록합니다.
[ ] 러너 배정과 토큰 권한을 정책 평가와 별도로 확인합니다.
[ ] 승인되지 않은 차단이나 불명확한 예외가 남아 있으면 강제 적용을 보류합니다.
[ ] 책임자와 롤백 담당자를 지정한 뒤 릴리스 흐름부터 단계적으로 강제 적용합니다.

이 절차의 핵심은 정책 통과와 맥 노드의 안전성을 각각 판정하는 것입니다. 승인된 실행이 예상한 러너에서 수행되지 않거나, 토큰 권한이 과도하게 남아 있으면 워크플로 보호의 평가가 통과해도 생산 준비 완료로 보지 마세요.

자주 묻는 질문

워크플로 실행 보호는 어떻게 설정하고 검수하나요?
정책 소유자, 적용 경로, 허용할 실행 주체와 이벤트를 정리하고 계정의 지원 조건을 확인합니다. 평가 모드에서 기존 실행에 미칠 영향을 확인한 뒤 통제된 테스트를 수행하세요. 예외 승인 기록과 실제 러너 배정까지 검증한 후에 강제 적용하는 것이 안전합니다.

평가 모드에서 워크플로가 차단되나요?
평가 모드는 강제 적용 전 영향을 관찰하는 데 사용됩니다. 평가 결과를 실제 차단과 같다고 해석하지 마세요. 기존 실행이 영향을 받는다는 판단과 실제 강제 상태를 구분하고, 강제 단계의 테스트 결과를 별도로 기록해야 합니다.

pull_request_target 기본 보호는 비공개 저장소에도 적용되나요?
기본 규칙은 조건을 충족하는 공개 저장소를 대상으로 하며, 비공개 및 내부 저장소에는 동일한 기본 규칙이 적용되지 않습니다. 저장소 유형과 실제 정책 상태를 직접 확인해야 합니다. GitHub는 영향을 받는 저장소의 강제 적용 예정일을 2026년 11월 2일로 안내했습니다.

워크플로 보호가 자체 관리 맥 러너의 권한을 제한하나요?
아니요. 정책이 제한하는 것은 실행 주체, 이벤트, 적용 워크플로 경로입니다. 호스트 격리, 러너 프로세스 권한, 서명 자산 접근, 토큰 권한은 별도의 통제입니다. 자체 관리 러너 보안 지침과 토큰 최소 권한 설정을 함께 검토하세요.

생산 승인과 맥 인프라 선택

IT 관리자는 적용 범위, 평가 기록, 예외 승인, 러너 권한 검토, 롤백 담당자를 한 묶음의 생산 승인 근거로 제출해야 합니다. 결과는 통과, 기한을 정한 수정, 강제 적용 보류 중 하나로 명시합니다. 보호 정책을 도입했다는 사실만으로 전용 맥 노드가 필요하거나 안전해졌다고 결론 내릴 수는 없습니다.

현재 보유 장비만 사용하는 방식은 추가 구매를 줄일 수 있지만, 수요가 늘면 하드웨어 조달과 교체 시점을 관리해야 하고, 공유 노드의 권한·복구 책임도 내부에 남습니다. 범용 클라우드 실행만으로 해결하려 해도 실제 맥 빌드와 서명 자산의 접근 경계를 별도로 설계해야 합니다. 이 비용과 책임이 일시적인 맥 CI 수요에 비해 큰지 검토할 필요가 있습니다.

고정된 상시 부하와 물리 인터페이스가 필요한 환경은 직접 구매가 더 적합할 수 있습니다. 반면 출시 전 테스트나 일시적인 빌드 용량처럼 기간이 한정된 수요라면, 맥 임대를 비교 대상으로 둘 수 있습니다. 맥 미니 임대 비용 안내를 통해 비용 항목을 확인하고, 서울 맥 미니 주문 안내에서 필요한 운영 환경과 맞는지 살펴보세요. 임대 역시 워크플로 정책이나 호스트 보안을 대신하지 않으므로, 실행 보호와 러너 권한 검수를 먼저 끝낸 뒤 임시 맥 용량이 필요한 경우에 선택하는 편이 타당합니다.