CI가 멈추면 배포도 멈춘다: GitHub Actions 장애로 보는 외부 제어면 의존성

• 카테고리: infra_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: CI/CD를 SaaS에 맡겼을 때, 우리는 어떤 부분을 “내 인프라가 아니니 괜찮다”가 아니라 “외부 제어면 의존성”으로 관리해야 할까?
• 핵심 출처:
  • GitHub Availability Report: May 2026 - 2026-06-11, 확인일 2026-06-16
  • GitHub Availability Report: February 2026 - 2026-03-11, 확인일 2026-06-16
  • GitHub Docs: Self-hosted runners - 문서, 확인일 2026-06-16
  • GitHub Docs: Billing and usage - 문서, 확인일 2026-06-16

1. 왜 지금 봐야 하나

GitHub의 2026년 5월 가용성 보고서는 CI/CD를 운영하는 팀에게 꽤 불편한 사실을 보여준다. 5월 한 달 동안 GitHub은 9건의 주요 장애를 보고했고, 그중 여러 건이 GitHub Actions, Pages, Copilot 계열 서비스, GitHub Enterprise Importer처럼 Actions에 직접 또는 간접 의존하는 기능에 영향을 줬다. 특히 5월 5일과 6일에는 호스티드 러너 할당 문제가 반복됐고, 5월 15일에는 계획된 failover 중 서비스 디스커버리 업데이트가 제대로 전파되지 않아 Actions 실행 실패와 지연이 발생했다. 5월 26일에는 자동 계정 검토 시스템이 Actions 서비스 계정을 잘못 정지시키면서 새 워크플로 시작과 액션 다운로드가 막혔다.

2월 보고서도 같은 경고를 준다. 2026년 2월 2일에는 GitHub Actions 호스티드 러너와 Codespaces가 전 지역·러너 유형에서 영향을 받았고, 작업은 러너를 얻지 못해 큐에서 타임아웃됐다. GitHub은 이 사건에서 다른 공급자 위의 self-hosted runner는 영향을 받지 않았다고 설명했다.

이 글의 목적은 “GitHub이 불안정하다”는 이야기가 아니다. 핵심은 CI/CD는 코드 저장소 옆의 부가 기능이 아니라 배포 제어면(control plane) 이라는 점이다. 제어면이 멈추면 애플리케이션 서버, 쿠버네티스 클러스터, 클라우드 계정이 멀쩡해도 새 버전을 배포하거나 긴급 롤백을 실행하기 어려워진다.

2. 핵심 개념

오늘 가져갈 개념은 외부 제어면 의존성이다.

데이터면(data plane)은 사용자의 실제 요청을 처리하는 경로다. 예를 들어 웹 서버, DB, 캐시, 메시지 큐, CDN이 여기에 가깝다. 제어면(control plane)은 이 데이터면을 바꾸고 조정하는 경로다. 배포 승인, 빌드, 테스트, 이미지 생성, 마이그레이션 실행, 인프라 변경, 롤백 트리거가 여기에 들어간다.

GitHub Actions 같은 CI/CD SaaS를 쓰면 팀은 빌드 머신, 큐, 로그, 권한, 마켓플레이스 액션 다운로드, OIDC 토큰 발급 같은 제어면 일부를 외부 서비스에 맡긴다. 장점은 크다. 직접 Jenkins나 러너 풀을 운영하지 않아도 되고, 사용량 기반으로 빠르게 시작할 수 있으며, 공개 저장소나 작은 팀에는 비용도 낮다. 하지만 장애 모드는 바뀐다.

• 러너가 부족하면 워크플로가 시작되지 않는다.
• 액션 다운로드가 막히면 self-hosted runner가 있어도 작업 준비 단계에서 실패할 수 있다.
• 인증·권한 계층이 오작동하면 배포 토큰 발급, 저장소 접근, 아티팩트 다운로드가 같이 흔들린다.
• 상태 페이지가 정상으로 보이거나 늦게 업데이트되면 내부 팀은 “우리 설정 문제인가?”를 먼저 의심하게 된다.

즉 CI/CD 신뢰성은 “러너를 GitHub-hosted로 쓸까 self-hosted로 쓸까”만의 문제가 아니다. 워크플로 시작, 소스 접근, 액션 해석, 비밀/토큰 발급, 아티팩트 저장, 배포 대상 접근 중 어느 고리가 외부 제어면에 묶여 있는지 보는 문제다.

3. 최신 이슈와 연결

5월 보고서에서 눈에 띄는 패턴은 같은 사용 표면이 서로 다른 원인으로 반복해서 멈췄다는 점이다.

첫째, 5월 5일에는 East US 지역의 호스티드 러너에서 VM scale-up 작업이 내부 rate limit에 걸리며 일부 표준 러너와 private networking이 있는 larger runner 요청이 실패하거나 5분 이상 지연됐다. 다음 날인 5월 6일에는 전날 복구 작업 중 들어간 예기치 않은 설정 데이터가 새 할당을 막아 Standard Ubuntu 호스티드 러너 작업의 약 17.1%가 실패했다.

둘째, 5월 15일에는 Actions를 뒷받침하는 인프라의 계획된 failover 중 자동 서비스 디스커버리 업데이트가 제대로 전파되지 않았다. 그 결과 워크플로 오케스트레이션의 핵심 의존성으로 트래픽이 잘못 라우팅되고 요청 타임아웃이 늘었다. GitHub은 피크 시 Actions 실행의 42%가 실패하거나 시작 지연을 겪었다고 보고했다.

셋째, 5월 26일에는 자동 계정 검토 시스템이 GitHub Actions가 워크플로 실행 인증과 액션 다운로드에 쓰는 서비스 계정을 잘못 정지시켰다. 10:4012:16 UTC에는 새로 큐에 들어간 실행이 시작되지 않았고, 12:1612:56 UTC에는 액션 다운로드가 필요한 실행이 계속 실패했다. Pages, Copilot code review, Copilot coding agent, Octoshift, GitHub Enterprise Importer도 Actions 의존성 때문에 영향을 받았다.

2월 사건은 다른 각도다. GitHub은 2월 2일 장애에서 호스티드 러너와 Codespaces가 VM 메타데이터 접근 실패로 새 VM 생성·삭제·리이미지 작업을 할 수 없었다고 설명했다. 이때 작업은 러너를 얻지 못해 큐에서 타임아웃됐고, GitHub은 다른 공급자 위의 self-hosted Actions runner는 영향을 받지 않았다고 밝혔다.

이 네 사례의 공통점은 “내 애플리케이션 코드가 깨져서 배포가 실패했다”가 아니라는 점이다. 제어면의 capacity, configuration, service discovery, authentication, provider policy가 모두 CI/CD 실패 원인이 될 수 있다.

4. 개발자 관점 해석

작은 팀은 보통 CI/CD를 세 단계로 본다. “테스트 돌리기”, “이미지 만들기”, “배포하기”. 하지만 장애 대응 관점에서는 더 잘게 나눠야 한다.

첫 번째 질문은 우리의 긴급 변경 경로가 하나뿐인가이다. 운영 장애가 났을 때 hotfix, feature flag 변경, 설정 롤백, 이전 이미지 재배포를 모두 GitHub Actions 하나로만 실행한다면, GitHub Actions 장애는 곧 복구 수단 장애가 된다. 애플리케이션 가용성과 배포 제어면 가용성이 서로 독립적이지 않은 것이다.

두 번째 질문은 self-hosted runner가 무엇을 해결하고 무엇을 해결하지 못하는가이다. GitHub 문서는 self-hosted runner가 하드웨어, OS, 도구, 네트워크 접근을 더 많이 제어하게 해주지만 OS와 소프트웨어 업데이트, 머신 유지 비용은 사용자가 책임진다고 설명한다. 또한 self-hosted runner는 GitHub Actions라는 오케스트레이션 제어면 안에서 동작한다. 2월처럼 호스티드 러너 capacity 문제가 주원인일 때는 분산 효과가 있지만, 워크플로 시작, 저장소 인증, 액션 다운로드, GitHub API가 막히는 유형에는 여전히 취약할 수 있다.

세 번째 질문은 비용 최적화가 장애 격리를 약하게 만들고 있지 않은가이다. GitHub-hosted runner는 관리 비용이 낮고 사용량 지표로 비용을 파악하기 쉽다. 하지만 모든 배포를 같은 SaaS, 같은 리전, 같은 계정 정책, 같은 마켓플레이스 액션 다운로드 경로에 묶으면 운영 비용은 낮아지는 대신 blast radius가 커진다. 반대로 self-hosted runner나 보조 배포 경로를 두면 인프라 비용과 패치 책임은 늘지만, 특정 러너 capacity 장애나 네트워크 경로 문제를 우회할 수 있다.

네 번째 질문은 보안 자동화가 운영 계정을 잘못 막을 때의 안전장치가 있는가이다. 5월 26일 사건은 자동 계정 검토가 서비스 계정을 정지시키면서 CI/CD가 멈춘 사례다. 우리 팀 내부에서도 비슷한 일이 생길 수 있다. 예를 들어 secret rotation 자동화, IAM 정리 스크립트, 비용 절감 스케줄러, 계정 비활성화 정책이 배포 봇·러너·서비스 계정을 삭제하거나 권한을 빼앗을 수 있다.

5. 내 프로젝트에 적용할 체크포인트

아래 질문에 “예/아니오”로 답해보자.

1. 긴급 롤백을 GitHub Actions 없이 실행할 수 있는가?

   • 예: 클라우드 콘솔, 배포 CLI, Argo CD, Kubernetes rollout undo, Cloud Run revision traffic 전환 같은 절차가 문서화되어 있다.
   • 아니오: CI 장애가 애플리케이션 복구 시간까지 늘릴 수 있다.

2. 배포 워크플로가 외부 액션 다운로드에 강하게 의존하는가?

   • uses: org/action@tag가 많고 pinning, cache, 내부 mirror가 없다면 액션 다운로드 장애에 취약하다.
   • 중요한 배포 단계는 가능하면 검증된 버전 SHA로 고정하고, 핵심 스크립트는 저장소 내부나 내부 패키지로 둔다.

3. 러너 장애와 제어면 장애를 구분해서 모니터링하는가?

   • “workflow queued time”, “runner acquisition time”, “action download failure”, “deployment target auth failure”를 같은 실패로 묶으면 원인 파악이 늦어진다.

4. self-hosted runner를 쓴다면 운영 책임을 명시했는가?

   • OS 패치, runner 버전, 네트워크 egress, secret 접근, job 격리, 디스크 정리, 동시 실행 제한을 누가 보는지 정해야 한다.

5. 배포 서비스 계정이 자동 정리·정지 정책에서 보호되는가?

   • 서비스 계정 allowlist, break-glass 계정, 변경 승인, 감사 로그 알림이 필요하다.

6. CI/CD 비용 절감 정책이 복구 경로를 줄이고 있지 않은가?

   • “모든 runner를 scale-to-zero”로 만들면 비용은 줄지만, 장애 시 cold start와 큐 적체가 커진다.
   • 반대로 상시 러너를 너무 많이 두면 비용이 낭비된다. 핵심은 모든 작업이 아니라 긴급 배포·롤백에 필요한 최소 경로를 따로 계산하는 것이다.

6. 오늘 10분 액션

오늘은 새 도구를 설치하지 말고, 현재 저장소의 배포 워크플로 하나만 열어보자.

1분: 가장 중요한 배포 workflow 파일을 연다. 예: .github/workflows/deploy.yml.

3분: 각 단계 옆에 의존성을 표시한다.

• GitHub 제어면: workflow trigger, approvals, secrets, OIDC token, Actions API
• 러너 capacity: GitHub-hosted runner 또는 self-hosted runner
• 외부 다운로드: marketplace action, container image, package registry
• 배포 대상: cloud API, Kubernetes API, Vercel/GCP/AWS API
• 내부 상태: migration lock, feature flag, artifact bucket

3분: “GitHub Actions가 2시간 멈추면 어떻게 롤백할까?”를 한 문장으로 적는다. 답이 없다면 임시 답이라도 만든다.

예시:

긴급 롤백은 GitHub Actions를 통하지 않고, 온콜이 Cloud Run 콘솔에서 직전 revision으로 traffic 100%를 되돌린다. 실행 후 Slack incident 채널에 revision, 시간, 사유를 남긴다.

2분: 배포 서비스 계정이 자동 정리 대상인지 확인한다. IAM, GitHub App, cloud service account, OIDC provider, secret manager 항목 중 하나라도 “누가 소유하는지 모름”이면 이슈를 만든다.

1분: 다음 스프린트 이슈 제목을 만든다.

CI 장애 시 긴급 롤백 runbook과 외부 제어면 의존성 목록 만들기

7. 더 볼 자료

• GitHub의 2026년 5월 가용성 보고서는 Actions 장애가 러너 capacity, 설정 데이터, 서비스 디스커버리, 서비스 계정 자동 정지처럼 서로 다른 층에서 발생할 수 있음을 보여준다.
• GitHub의 2026년 2월 가용성 보고서는 호스티드 러너와 Codespaces가 underlying compute provider 정책 문제로 전 지역 영향을 받은 사례와, 다른 공급자 위 self-hosted runner가 어떤 경우에 도움이 될 수 있는지 힌트를 준다.
• GitHub Docs의 self-hosted runner 문서는 더 많은 제어와 더 많은 운영 책임이 함께 온다는 점을 명확히 한다.
• GitHub Docs의 billing and usage 문서는 Actions 사용량·비용 지표가 청구뿐 아니라 어느 워크플로가 runner와 storage를 많이 쓰는지 이해하는 운영 지표로도 쓰일 수 있음을 설명한다.

중복 회피 메모

최근 infra_dev 글은 Kubernetes Job suspend, OIDC 기반 배포 secret 축소, Cloud Run worker backpressure, OpenTelemetry Collector 운영, GKE standby buffer, Docker docker cp 보안 경계, PostgreSQL 19 관측 지표, Cloudflare Queues 백로그·재시도·DLQ를 다뤘다. 이번 글은 큐나 워커, Postgres, 컨테이너 보안, 스케일링 기능을 반복하지 않고, GitHub의 2026년 2월·5월 가용성 보고서를 바탕으로 CI/CD SaaS를 외부 제어면 의존성으로 모델링하고 긴급 롤백·러너 선택·서비스 계정 보호·비용/신뢰성 트레이드오프를 점검하는 관점에 집중한다.