2026년 8월 6일 밤 늦게, 세계 최대의 코드 저장소인 GitHub에 대규모 장애가 발생했습니다. 자동화 서비스인 GitHub Actions가 광범위하게 마비되어 작업 대기열이 수시간 동안 정체되었고, 실행 중이던 작업들도 대거 실패했습니다. 웹 호스팅 서비스인 Pages의 성능도 함께 저하되었으며, AI 보조 도구인 Copilot의 코드 리뷰 기능마저 간헐적으로 오작동했습니다. 이 소식은 개발자 커뮤니티 Hacker News에 올라온 지 8시간 만에 299점의 추천과 253개의 댓글을 기록했습니다. 개발자들은 조각난 단서들을 모아 원인을 추적했습니다. 플랫폼을 한계로 몰아넣은 원인은 다름 아닌 AI 코딩 열풍이었습니다. GitHub COO Kyle Daigle이 공개한 데이터에 따르면, Actions의 주간 실행 시간은 2023년 5억 분에서 2025년 10억 분으로 늘어난 데 이어 이번 주에는 21억 분을 돌파하며 2년 만에 4배로 폭증했습니다.
코딩을 하지 않는 독자들을 위해 배경을 설명하자면, GitHub는 전 세계 개발자들이 코드를 저장하고 협업하는 필수 인프라입니다. 우리가 사용하는 대부분의 앱 코드도 이 플랫폼을 거쳐 갑니다. Actions는 코드 관리를 돕는 자동화 서비스로, 개발자가 규칙을 지정해 두면 코드가 변경될 때마다 테스트, 빌드, 배포를 자동으로 수행합니다. 사람이 30분 동안 할 작업을 머신이 단 수분 만에 처리해 주는 셈입니다.
이미지: 이번 GitHub 장애 관련 보도. 출처: The Register
공식 장애 기록에 따르면, 한국 시간 8월 6일 밤 11시경부터 작업 대기열 지연과 타임아웃이 시작되었으며 성공률은 한때 30~40% 수준까지 떨어졌습니다. GitHub 측은 트래픽을 제한하며 복구를 진행했으나, 코드 변경 알림의 15%만 처리되어 수많은 변경 사항이 후속 작업을 트리거하지 못했습니다. 8시간 후 작업 성공률은 99%로 회복되었지만 Copilot과 Pages는 여전히 간헐적인 문제를 보였고, 기업용 데이터 마이그레이션 서비스는 아예 일시 중단되었습니다. 이는 단발성 사건이 아닙니다. 7월 29일에도 유사한 Actions 장애가 발생했으며, 공식 상태 페이지 기록에 따르면 7월 한 달간 26건, 8월 첫 6일 동안 6건의 장애가 추가로 발생했습니다. GitHub는 지난 4월 장애에 대해 사과하고 6월에는 경영진이 구조적 개편을 약속했음에도 불구하고 불과 한 달 만에 다시 시스템이 마비되었습니다.
이미지: GitHub 공식 상태 페이지의 장애 기록. 성능 저하부터 복구까지 약 8시간 소요. 출처: githubstatus.com
장애 보고서의 한 문장은 깊이 살펴볼 필요가 있습니다. “작업 머신에 이미 무효화된 작업이 할당되어 재시도 루프에 갇혔다.” 즉, 머신이 이미 취소된 작업 지시서를 받아 실행한 뒤 무효함을 확인하고 다시 새 작업을 받으러 갔지만, 또다시 무효한 작업을 받아오는 상황이 반복된 것입니다. 시스템이 정체될수록 무효 작업이 늘어나고 악순환은 더욱 깊어졌습니다. 이는 고부하 시스템에서 나타나는 전형적인 고장 양상입니다.
폭증의 원인: AI가 주방의 주문량을 몇 배로 늘렸다
공식 통계 수치는 매우 놀랍습니다. 2025년 한 해 동안 GitHub에 등록된 전체 코드 커밋 수는 10억 건이었으나, 현재는 1주일에만 2억 7,500만 건이 몰리고 있어 이 추세라면 연간 140억 건에 달하게 됩니다. Actions 주간 실행 시간은 2년 만에 4배가 되었습니다. 이를 쉽게 체감할 수 있는 수치로 환산하면, 주간 21억 분은 매 순간 20만 대 이상의 서버가 전 세계 개발자를 대신해 GitHub에서 동시 작업하고 있음을 의미합니다. 주간 2억 7,500만 건의 커밋은 초당 평균 450건의 커밋이 발생하는 셈입니다. 플랫폼은 매초 450번의 요청을 받으며 매번 실행 머신을 할당해야 합니다.
이미지: Actions 주간 실행 시간 2년 만에 4배 증가; 주간 커밋 수는 2025년 주간 평균의 약 14배 달성. 출처: GitHub 공식 (COO Kyle Daigle), 필자 작성
이 엄청난 트래픽은 어디서 왔을까요? 바로 AI 코딩입니다. 현재 AI 보조 도구들은 스스로 코드를 읽고, 수정하고, 커밋하며, 테스트까지 실행할 수 있습니다. 한 번의 세션에서 수십 번의 루프를 돌며 매 루프마다 자동화 작업을 호출합니다. 과거에는 개발자 한 명이 하루에 한두 번 커밋했다면, 이제는 AI가 하루에 수십 번씩 커밋을 쏟아냅니다. 개발자 커뮤니티의 집계에 따르면, AI가 생성한 풀 리퀘스트는 지난해 9월 월 400만 건에서 올해 3월 월 1,700만 건으로 급증했습니다. Claude Code 단일 도구만 해도 매주 260만 건의 커밋을 기록하며 6개월 만에 25배 성장했습니다. 사람이 코드를 작성하는 것이 단품 주문이라면, AI 코딩은 주방 전체의 주문량을 한 번에 몇 배로 늘리는 것과 같습니다.
주방은 그대로인데 주문만 폭증하면 연쇄 반응이 일어납니다. Hacker News에서 대규모 시스템을 오래 다뤄온 엔지니어(cortesoft)는 이 메커니즘을 명쾌하게 설명했습니다. 시스템은 여유 용량을 두고 설계되지만, 부하가 90% 이상으로 올라가면 작은 변동에도 폭발합니다. 작업이 정체되고, 타임아웃이 발생하며, 클라이언트가 재시도를 보내고, 그 재시도가 다시 대기열을 늘립니다. 평소 80% 통행량일 때는 원활하다가 95%가 되면 급브레이크 하나로 도로 전체가 마비되는 고속도로와 같습니다. 그는 이런 상황에서는 머신을 추가하는 것도 소용없으며, 병목은 예상치 못한 곳에서 터진다고 강조했습니다.
공식 해명과 사용자들의 불만
양측의 입장이 팽팽히 맞서고 있습니다. GitHub 공식 측은 용량 한계를 인정하며 엔지니어들이 원인을 파악해 복구 조치를 배포 중이라고 밝혔습니다. 그러나 유료 사용자들의 반응은 냉담합니다. 자체 서버를 운용하는 한 기업 사용자는 자비를 들여 유지하는 머신조차 하루 종일 마비되었다며 유료 서비스의 품질을 비판했습니다. 2009년부터 GitHub를 사용해 온 장기 사용자(zehaeva)는 더욱 강하게 비판하며, 지난 1년 동안 GitHub의 가동률이 ‘포나인(99.99%)‘에서 ‘원나인(90%)’ 수준으로 떨어졌다고 지적했습니다. 포나인은 연간 가동 중단 시간이 1시간 미만임을 의미하지만, 원나인은 연간 30일 이상 서비스가 중단될 수 있음을 뜻합니다. 그는 이를 AI 사용량의 폭발적 증가와 연관 짓지 않을 수 없다고 덧붙였습니다.
댓글 창에서는 클라우드 이전에 대한 오래된 논쟁도 다시 불붙었습니다. GitHub는 마이크로소프트에 인수된 후 인프라를 자회사 데이터 센터에서 Azure 클라우드로 이전하고 있습니다. 한 사용자(toomuchtodo)는 자체 데이터 센터 시절이 훨씬 안정적이었다며, 가변적인 확장 영역만 클라우드로 넘겼어야 했는데 모든 것을 이전한 것이 문제라고 주장했습니다. 일부는 이전 일정이 너무 무리하게 잡혔다고 의심하기도 했습니다. 반면 다른 사용자는 인수된 지 8년이 지났지만 불만이 급증한 것은 최근 1년 사이이며, 이는 AI 코딩의 폭발 시점과 정확히 일치한다고 반박했습니다. 양측의 주장이 엇갈리는 가운데 분명한 사실은 두 가지입니다. 지난 1년간 GitHub의 장애 빈도가 눈에 띄게 늘어났다는 점과 트래픽 폭증이 실제 현실이라는 점입니다.
효율성 혁명과 물리적 세계의 경주
이 사건은 일반 사용자들과 어떤 관련이 있을까요? 스마트폰 앱의 업데이트, 버그 수정, 신규 기능 배포는 대부분 GitHub의 자동화 파이프라인을 거칩니다. 플랫폼이 하루 동안 멈추면 전 세계 수많은 소프트웨어 팀의 배포 일정에 차질이 생깁니다. 더 깊이 들여다보면 이는 디지털 생산 속도와 물리적 세계의 경주입니다. AI는 소프트웨어 생산성을 비약적으로 높이지만, 서버, 대역폭, 데이터 센터의 확충은 물류와 장비 수급이 수반되는 물리적 과정이기에 명확한 한계가 존재합니다. GitHub는 지난해 10월 용량 확장 목표를 10배로 잡았다가 올해 2월 30배로 하향 조정했지만 여전히 몰려드는 트래픽을 감당하기 버거운 상황입니다. 마이크로소프트가 급한 불을 끄기 위해 경쟁사인 AWS의 서버 용량을 임시 임대했다는 보도까지 나올 정도로 인프라의 과부하는 심각한 수준입니다.
“모든 것을 자동화할 수 있다”는 AI 시대의 가장 매력적인 구호입니다. 그러나 현실은 자동화가 만들어 낸 작업도 결국 머신의 차례를 기다려야 한다는 점입니다. 이번 GitHub 장애는 하나의 강력한 경고입니다. 모두가 더 빠르게 생산할 때 가장 희소한 자원은 이 모든 것을 담아내는 인프라가 됩니다. AI의 생산 속도는 소프트웨어의 영역이지만, 인프라의 확장 속도는 물리적 영역입니다. 후자가 전자를 따라잡지 못하면 결국 무너지는 것은 우리가 디딛고 선 발밑이 될 것입니다.
참고 링크:
- GitHub Status: Actions 및 Pages 장애 보고서
- HN 토론 (item?id=49198302)
- The Register: Latest GitHub outage squeezes Actions, Pages to death
- Waxell: GitHub’s AI Agent Crisis: What 9 Outages Cost
- danilchenko.dev: GitHub’s AI Agent Problem: 17 Million PRs, Five Outages, and a Kill Switch
