깃허브 장애, AI 코딩 폭증이 드러낸 인프라 취약점

깃허브가 7시간 47분 동안 멈췄다, 왜 하필 지금일까

솔직히 이 소식을 처음 봤을 때 의아했다. 깃허브 같은 공룡 서비스가 거의 8시간이나 먹통이 됐다는 게 믿기지 않았다.

더 눈에 띄는 건 따로 있었다. 이번 깃허브 장애가 8월 들어 두 번째라는 점이다. 코드나 설정 변경 때문도 아니었다.

필자가 보기엔 이 지점이 핵심이다. 원인은 사람의 실수가 아니라 순수한 트래픽 폭증, 즉 용량 문제였다.

지난 8월 17일, 깃허브 중부 미국 데이터센터의 핵심 인프라가 새로운 트래픽 최고치를 감당하지 못했다. 이 압박이 인증 시스템까지 번지면서 로그인 자체가 막혔다.

연쇄적으로 Actions, API, 풀리퀘스트, 이슈, 그리고 GitHub Copilot까지 줄줄이 영향을 받았다. 대부분 서비스는 낮 동안 복구됐지만, 코파일럿은 유독 오래 걸렸다.

이유가 흥미롭다. 복구 과정에서 클라이언트 쪽 재시도 로직이 오히려 트래픽을 증폭시켰다. 이른바 ‘재시도 폭풍’이 불을 더 키운 셈이다.

개인적으로는 이 부분이 가장 아이러니하다고 느꼈다. 서비스를 살리려는 시도가 오히려 장애를 연장시켰으니 말이다.

깃허브에 따르면 월간 커밋 수는 4월 14억 건에서 8월 29억 건으로 늘었다. 불과 넉 달 만에 두 배로 뛴 셈이다.

이 성장의 상당 부분은 AI 코딩 도구가 밀어붙였다는 분석이 많다. 개발자 한 명이 코파일럿 같은 AI 에이전트를 돌리면 예전보다 훨씬 많은 요청을 서버에 던지게 된다.

구분	내용
발생일	2026년 8월 17일
지속 시간	7시간 47분
주요 원인	중부 미국 데이터센터 인프라의 오토스케일링 실패
증폭 요인	코파일럿 클라이언트의 재시도 폭풍
영향 서비스	Actions, API, PR, Issues, Copilot, 인증
월간 커밋 증가	4월 14억 건 → 8월 29억 건

표로 정리해 놓고 보니 흐름이 더 선명해진다. 원인, 증폭, 결과가 하나의 사슬처럼 이어져 있다.

필자 생각에는 이게 단순한 ‘운이 나빴다’로 끝날 문제가 아니다. 성장 속도 자체가 설계 용량을 앞질렀다는 뜻이기 때문이다.

깃허브는 공식 블로그를 통해 재발 방지책을 공개했다. CPU 코어 300만 개 이상과 스토리지 120페타바이트 이상을 추가하겠다고 밝혔다.

여기서 눈에 띄는 건 마이크로소프트 인프라, 즉 애저로의 이전이 이미 절반을 넘었다는 사실이다. 이건 단순 기술 이슈를 넘어 조직 전략의 문제이기도 하다.

개인적으로는 이 재시도 정책 정비가 가장 실질적인 조치라고 본다. 사실 이번 사고의 본질은 ‘실패 자체’가 아니라 ‘실패가 증폭되는 방식’이었으니까.

클라우드 인프라 장애는 깃허브만의 문제가 아니다. 최근 클라우드플레어의 반복된 장애도 비슷한 맥락을 갖고 있었다. 이번 깃허브 장애 역시 같은 흐름 위에 놓여 있다고 필자는 본다.

공통점은 명확하다. AI 시대에 접어들며 트래픽 패턴 자체가 예측 불가능해졌다는 점이다. 사람이 아니라 에이전트가 요청을 만들어내니 그럴 수밖에 없다.

이 지점이 흥미로운데, 개발 도구 회사들은 이제 단순히 ‘기능’만 잘 만들면 되는 게 아니다. 자기 도구가 만들어내는 트래픽의 물리적 무게까지 설계해야 하는 시대가 됐다.

필자가 이번 깃허브 장애에서 가장 주목한 건 ‘재시도 폭풍’이라는 표현이다. 복구를 도우려는 장치가 오히려 재앙을 키웠다는 사실이 상징적이다.

AI 코딩 도구의 확산은 개발 생산성을 끌어올렸다. 하지만 그 이면에는 인프라가 감당해야 할 트래픽의 급격한 성장이 숨어 있다.

솔직히 이건 깃허브만의 숙제가 아니라고 본다. AI 에이전트가 API를 직접 두드리는 시대에는, 모든 개발 플랫폼이 같은 함정에 빠질 수 있다.

앞으로가 더 중요하다. 애저 이전이 마무리되고 재시도 정책이 자리 잡을 때, 깃허브가 이 폭증하는 트래픽을 진짜로 감당할 수 있을지 지켜볼 일이다.