GitHub Actions가 7시간 가까이 멈췄다 — AI 코딩 에이전트 시대, CI/CD 인프라가 먼저 한계에 도달하고 있다

2026년 8월 7일 새벽, 전 세계 개발팀이 사용하는 GitHub Actions에 대규모 장애가 발생했다.

단순히 몇몇 빌드가 느려지는 수준이 아니었다. GitHub Actions 워크플로우가 시작되지 않거나 실행 도중 실패했고, 작업 대기열이 쌓였으며, Push와 Pull Request를 CI/CD 파이프라인으로 연결하는 Webhook까지 대폭 제한됐다.

GitHub Pages와 Copilot Code Review, Copilot Coding Agent 등 Actions에 의존하는 서비스에도 장애가 전파됐다.

특히 눈에 띄는 점은 self-hosted runner 역시 안전하지 않았다는 것이다.

회사 내부 서버에 직접 GitHub Actions Runner를 구축해놓았더라도 작업을 어느 러너에 배정할지 결정하는 GitHub의 중앙 제어면(control plane)에 문제가 발생하면 결국 새로운 작업을 받지 못한다.

이번 장애는 단순한 SaaS 장애를 넘어, 현대 소프트웨어 개발 환경이 얼마나 GitHub라는 하나의 플랫폼에 강하게 결합돼 있는지를 다시 보여준 사건이다.

---

장애는 어떻게 진행됐나

GitHub 공식 Status 페이지에 따르면 장애는 8월 6일 15:22 UTC, 한국시간으로 8월 7일 0시 22분경 시작됐다.

처음에는 Actions 성능 저하 조사로 시작했지만 곧 워크플로우 실행 실패와 Actions REST API 오류, 예상치 못한 rate limit 문제가 보고됐다.

시간이 지나면서 상황은 더 악화됐다.

GitHub는 한때 새로 큐에 들어온 작업 가운데 성공하는 비율이 30~40% 수준까지 떨어졌다고 밝혔다.

복구를 위해 Webhook 처리량 자체를 강제로 줄였는데, 8월 6일 20:34 UTC 업데이트에서는 정상 Webhook의 약 15%만 처리하고 있다고 설명했다.

그 결과 Git Push나 Pull Request를 만들어도 해당 이벤트가 Actions 워크플로우로 전달되지 않는 경우가 대량으로 발생했다.

문제는 GitHub-hosted runner에만 한정되지 않았다.

GitHub는 공식적으로

GitHub-hosted와 self-hosted runner 모두 영향을 받고 있다

고 밝혔다.

원인 분석 과정에서는 일부 runner가 이미 유효하지 않은 작업을 계속 할당받고 재시도하는 상태가 발견됐다.

GitHub는 이에 대한 수정 사항을 배포하면서 점진적으로 정상화에 들어갔다.

한국시간 8월 7일 오전 7시 18분에 게시된 최신 공식 업데이트 기준으로는, 시작된 워크플로우의 성공률이 약 97%까지 회복됐다.

다만 이 시점에도 Webhook throttling은 계속되고 있었으며 Push와 PR 이벤트 가운데 상당수가 아직 새로운 workflow를 발생시키지 못했다.

GitHub Pages, Copilot Code Review, Copilot Coding Agent 역시 실패 또는 지연 가능성이 남아 있었고 GitHub Enterprise Importer를 통한 migration도 일시 중단됐다.

즉, 약 7시간이 지난 시점에서도 완전 정상화가 아니라 대규모 backlog를 처리하며 복구 중인 상태였다.

---

왜 self-hosted runner까지 멈췄을까?

이번 장애에서 많은 개발자들이 가장 의아하게 생각한 부분이다.

“컴퓨팅 서버를 우리가 직접 운영하는데 GitHub가 장애 나면 왜 runner까지 멈추는가?”

GitHub Actions의 self-hosted runner는 계산 자원만 사용자가 제공할 뿐, 완전히 독립적인 CI 서버가 아니다.

대략적인 구조는 다음과 같다.

 

Git Push / Pull Request

→ GitHub Webhook
→ Actions Workflow 생성
→ GitHub Actions Scheduler / Control Plane
→ Runner에 Job 할당
→ self-hosted 또는 GitHub-hosted runner에서 실행

 

따라서 회사 내부에 CPU 100개짜리 runner cluster가 정상적으로 살아 있어도 GitHub 쪽에서 workflow를 생성하지 못하거나 scheduler가 job을 제대로 배정하지 못하면 runner들은 할 일이 없다.

이번에 실제로 GitHub는 self-hosted runner 등록 과정에서 오류와 rate limiting이 발생할 수 있다고 밝혔으며, 이후 기존 self-hosted runner 일부가 job을 가져오지 못하는 문제까지 별도로 수정해야 했다.

이 때문에 self-hosted runner를 GitHub 장애에 대한 완전한 DR(Disaster Recovery) 수단으로 보는 것은 위험하다.

Compute plane을 분리했을 뿐, control plane은 여전히 GitHub에 있기 때문이다.

---

그런데 GitHub 장애가 최근 왜 이렇게 자주 발생할까?

여기서 Hacker News 논쟁이 시작된다.

가장 많이 등장한 가설은 크게 두 가지다.

1. AI 코딩 에이전트 때문에 GitHub 트래픽이 폭발했다.
2. GitHub의 Azure 이전과 아키텍처 재구성이 동시에 진행되고 있다.

흥미로운 점은 두 주장 모두 일정 부분 실제 GitHub 발표와 맞닿아 있다는 것이다.

---

AI 코딩 에이전트가 GitHub의 트래픽 모델을 완전히 바꿨다

AI와 GitHub 장애 사이의 상관관계는 단순한 Hacker News 음모론 수준은 아니다.

 

GitHub CTO Vlad Fedorov는 지난 4월 GitHub의 가용성 문제를 설명하면서 2025년 12월 하반기부터 agentic development workflow가 급격히 증가했다고 공식적으로 밝혔다.

 

그 결과 repository 생성, Pull Request, API 호출, automation, 대형 repository workload가 모두 빠르게 증가하고 있다고 설명했다.

GitHub는 원래 2025년 10월부터 인프라 용량을 10배 확대하는 계획을 실행하고 있었다.

 

하지만 2026년 2월에는 목표 자체를 바꿨다.

 

GitHub가 준비해야 할 규모가 기존 예상치를 넘어 현재의 30배 규모라고 판단했기 때문이다.

숫자로 보면 변화가 더 극적이다.

 

GitHub COO Kyle Daigle이 공개한 수치에 따르면 GitHub Actions 사용량은

• 2023년: 주당 약 5억 분
• 2025년: 주당 약 10억 분
• 2026년 4월 한 주: 약 21억 분

수준까지 올라갔다.

GitHub 전체 commit 수도 2025년 약 10억 건에서 2026년에는 한때 주당 2억7,500만 건 수준의 처리량을 기록했다.

이것이 중요한 이유는 AI 에이전트의 동작 방식이 인간 개발자와 다르기 때문이다.

사람은 코드를 수정한 뒤 잠시 고민하고, 테스트하고, 커밋하고, PR을 생성한다.

 

에이전트는 그렇지 않다.

에이전트는 하루 24시간 API를 호출하고 코드를 수정하고 commit하고 PR을 만들고 CI를 실행하고 실패하면 다시 수정해 재실행할 수 있다.

 

그리고 PR 하나가 만들어질 때 GitHub 내부에서는 단순히 Git object 하나만 추가되는 것이 아니다.

Git storage, branch protection, mergeability check, Actions, search index, notification, permission, Webhook, API, database, background job 등이 연쇄적으로 움직인다.

 

GitHub도 이를 공식 설명에서 인정했다.

대규모 환경에서는 queue가 길어지고 cache miss가 DB 부하로 변하며 retry가 추가 트래픽을 만들고, 하나의 느린 dependency가 여러 서비스의 장애로 확산될 수 있다는 것이다.

 

분산 시스템에서 가장 위험한 전형적인 패턴이다.

트래픽 증가 → 지연 → retry 증가 → 추가 트래픽 → queue 증가 → timeout → 다시 retry

이른바 retry storm이 만들어진다.

---

그렇다면 이번 장애의 원인은 AI인가?

여기서는 주의해서 봐야 한다.

현재까지 GitHub는 이번 8월 6~7일 장애의 직접 root cause를 AI 에이전트 트래픽이라고 발표하지 않았다.

현재 공개된 장애 업데이트에서 확인된 직접적인 기술적 증상은 runner가 더 이상 유효하지 않은 job을 계속 할당받는 문제와 Actions capacity 및 scheduler 주변의 복구 문제다.

 

따라서

“Claude Code나 Copilot 같은 AI Agent가 트래픽을 폭주시켜 이번 GitHub 장애를 일으켰다.”

라고 단정하면 현재 단계에서는 과도한 해석이다.

 

하지만

“AI agent workload의 폭발적 증가가 GitHub 전체 인프라의 여유 용량을 줄이고 기존 병목을 빠르게 드러내고 있다.”

는 주장은 상당한 공식 근거가 있다.

 

GitHub 자신이 agentic development를 현재 인프라 확장의 핵심 배경으로 지목하고 있기 때문이다.

실제로 GitHub는 Actions의 과도한 자동 재실행 부하를 줄이기 위해 2026년 4월부터 하나의 workflow에 대한 rerun 횟수를 50회로 제한하기도 했다.

 

GitHub는 당시 일부 automation이 하나의 workflow에 대해 수백 번 retry하면서 시스템에 추가 부하를 발생시키고 있다고 설명했다.

이것 역시 CI/CD가 점점 인간이 아니라 machine-generated traffic을 상대하는 시스템으로 변하고 있음을 보여준다.

---

Azure 마이그레이션 때문이라는 주장도 있다

Hacker News에서는 또 하나의 원인으로 Azure가 집중적으로 거론되고 있다.

GitHub가 기존 자체 인프라에서 Microsoft Azure로 대규모 workload를 옮기는 과정에서 안정성이 떨어졌다는 주장이다.

Azure 이전 자체는 사실이다.

 

GitHub는 2026년 6월 발표에서 monolith traffic의 약 40%를 Azure에서 처리하고 있으며, 2월의 8%에서 빠르게 증가했다고 밝혔다.

 

Git traffic은 약 30%, repository replication은 99% 수준까지 Azure 기반으로 이동했다.

GitHub는 이 과정과 서비스 분리, DB 격리 등을 통해 4개월 동안 실질 처리 용량을 두 배 이상 늘렸다고 설명했다.

하지만 여기서도 구분이 필요하다.

 

Azure migration이 이번 8월 장애의 직접적인 원인이라는 공식 발표는 아직 없다.

HN의 Azure 관련 주장은 현재로서는 상당 부분 운영 경험을 바탕으로 한 추정이다.

다만 GitHub가 거대한 인프라 migration과 서비스 분리 작업을 진행하는 동시에 역사상 가장 빠른 workload 증가를 맞고 있다는 점은 분명하다.

 

쉽게 표현하면 달리는 자동차의 엔진을 교체하는데 자동차 속도까지 갑자기 몇 배 빨라진 상황에 가깝다.

---

이번 장애가 더 중요한 이유: CI/CD가 새로운 Single Point of Failure가 됐다

과거에는 GitHub 장애가 발생해도 코드를 로컬에서 작성하는 것은 가능했다.

하지만 오늘날 GitHub는 단순한 Git repository가 아니다.

 

GitHub Actions가 build와 test를 실행하고,

Pull Request가 코드 리뷰를 제어하고,

Actions가 Docker image를 만들고,

OIDC를 통해 AWS·Azure·GCP credential을 받아오고,

production deployment까지 실행한다.

 

여기에 Copilot Coding Agent나 Code Review Agent까지 Actions와 연결되고 있다.

GitHub의 5월 장애에서도 Actions 장애가 발생하자 Pages뿐 아니라 Copilot coding agent와 Copilot code review, Enterprise Importer까지 함께 영향을 받은 사례가 이미 있었다.

 

결국 개발 파이프라인의 편의성이 높아질수록 dependency graph도 커지고 있다.

 

GitHub → Actions → Container Registry → Cloud → Production

 

같은 구조에서 GitHub Actions control plane이 멈추면 production deployment 자체가 정지할 수 있다.

---

기업은 GitHub를 버려야 할까?

당장 GitHub에서 Forgejo나 GitLab로 모든 것을 옮기는 것이 현실적인 해결책은 아니다.

GitHub의 ecosystem과 developer experience, integration 규모가 워낙 크기 때문이다.

 

하지만 이번 장애가 던지는 교훈은 명확하다.

Source repository와 deployment capability를 동일한 장애 도메인에 전부 묶어서는 안 된다.

특히 중요한 서비스라면 최소한 다음 정도는 검토할 필요가 있다.

 

첫째, production deployment를 GitHub Actions에서만 실행할 수 있도록 만들지 않는 것이다.

Emergency deployment를 수행할 수 있는 CLI 또는 별도의 deployment pipeline을 준비해둘 필요가 있다.

둘째, self-hosted runner를 사용하는 것만으로 GitHub 장애 대응이 끝났다고 생각하면 안 된다.

self-hosted runner 역시 GitHub Actions의 control plane에 의존한다.

셋째, container image를 CI가 만들어야만 배포할 수 있는 구조라면 최근 정상 build artifact를 별도로 보존하는 것이 좋다.

넷째, GitHub Actions에 문제가 발생했을 때 GitLab CI, Jenkins, Woodpecker CI, Buildkite, Depot 같은 별도 실행 경로로 전환할 수 있는지를 검토할 수 있다.

 

모든 조직에 multi-CI가 필요한 것은 아니다.

하지만 배포 중단 비용이 큰 서비스라면 CI/CD provider 자체를 하나의 장애 도메인으로 취급해야 한다.

---

AI 시대에는 개발자보다 CI 서버가 먼저 지칠 수도 있다

이번 GitHub Actions 장애를 단순히 “GitHub가 또 다운됐다” 정도로 보는 것은 아쉽다.

더 큰 변화가 뒤에서 일어나고 있기 때문이다.

 

AI 코딩 에이전트는 개발자의 생산성을 높이는 동시에 software infrastructure가 처리해야 하는 이벤트의 양을 폭발적으로 늘리고 있다.

GitHub가 공개한 수치만 보더라도 Actions 사용량이 2023년 주당 5억 분에서 2026년 21억 분 수준까지 증가했다.

 

GitHub는 이미 Actions의 핵심 실행 및 runner communication 구조를 재설계하고 있으며, 새로운 architecture는 하루 1억2천만 개 이상의 job을 처리한다고 밝혔다. 이는 migration 이전보다 세 배가 넘는 규모다.

 

그런데 그것조차 빠르게 증가하는 agent workload를 따라잡기 위한 중간 단계일 가능성이 크다.

 

AI가 코드를 작성하는 시대의 병목은 모델의 token generation 속도만이 아니다.

 

코드가 만들어진 다음 거쳐야 하는

Git → PR → CI → 테스트 → 빌드 → Artifact → Deploy

전체 software supply chain의 처리 용량이 새로운 병목이 될 수 있다.

 

이번 GitHub Actions 장애는 그 변화를 꽤 상징적으로 보여줬다.

AI가 개발자를 대체할 것인가를 논쟁하는 동안,

정작 먼저 과부하에 걸리고 있는 것은 개발자가 아니라 개발 인프라일지도 모른다.

---

확인 가능한 GitHub의 최신 공식 incident 업데이트는 오전 7시 18분(KST) 게시분이며, 당시 workflow 성공률은 크게 회복됐지만 Webhook 제한과 일부 downstream 서비스 영향은 남아 있었다. GitHub가 향후 상세 RCA(Post-Incident Review)를 공개하면 이번 장애의 직접적인 기술 원인은 추가 확인이 필요하다.