GitHub, 8월 17일 7시간 47분 먹통 사태의 전말과 재발 방지책
무슨 일이 있었나요?
8월 17일, GitHub가 무려 7시간 47분 동안 장애를 겪었습니다. github.com 접속은 물론 로그인 인증, GitHub Actions, API, 풀 리퀘스트, 이슈, 그리고 Copilot까지 전 세계적으로 먹통이 되면서 수많은 개발자와 팀의 작업이 멈춰 섰죠. 공교롭게도 이번 사고는 8월 6일 GitHub Actions 장애에 이어 같은 달 두 번째 대형 사고였습니다.
원인은 '코드 버그'가 아니라 '용량 부족'
흥미로운 점은 이번 사고가 배포 실수나 코드 결함 때문이 아니라는 것입니다. 트래픽이 사상 최고치를 찍었을 때, Central US 데이터센터의 핵심 인프라가 그 속도를 따라가지 못하고 함께 확장되지 못한 게 화근이었습니다.
- 용량 압박이 시스템 전반으로 번지면서 인증 실패로 이어졌고
- 인증이 흔들리자 도미노처럼 여러 서비스가 연쇄적으로 중단됐습니다
GitHub 측은 8월 6일과 17일 두 사고 모두 "수요를 앞서 핵심 구성요소를 미리 확장하지 못한 용량 문제"라고 명확히 밝혔습니다. 실제로 4월 이후 월간 커밋 수가 14억 개에서 29억 개로 두 배 넘게 늘었는데, GitHub는 이런 성장세를 장애의 변명거리로 삼지 않겠다고 못박았습니다.
복구는 됐는데... 왜 이렇게 오래 걸렸나
복구팀은 트래픽을 우회시키고 문제가 된 인프라를 격리하며 서비스를 하나씩 되살렸습니다. 대부분의 서비스는 비교적 빨리 정상화됐지만, 유독 Copilot이 발목을 잡았습니다. 일부 Copilot 서비스에서 오류가 발생하자 클라이언트가 자동으로 재시도를 반복하는 루프에 빠졌고, 이 재시도 트래픽이 오히려 복구 중인 시스템에 부하를 더했던 것이죠. 이 재시도 폭주를 진정시키고 나서야 비로소 트래픽을 안전하게 되돌릴 수 있었습니다.
GitHub의 대응: "인프라를 통째로 늘린다"
이번 사고 이후 GitHub는 꽤 파격적인 규모의 인프라 증설을 발표했습니다.
- CPU 코어 300만 개 이상, 고속 스토리지 120PB 추가
- 상당한 규모의 네트워크 용량 증설
- 기존 데이터센터에는 전력이 허용하는 한도까지 하드웨어를 꽉 채우는 동시에, Azure 마이그레이션을 가속
특히 눈에 띄는 대목은 Azure 의존도입니다. 5월까지만 해도 GitHub 플랫폼 부하의 12%만 Azure가 처리했는데, 이제는 약 58%, 전체 Git 작업의 절반을 Azure가 떠받치고 있습니다. 대규모 모노레포 확장에도 이 Azure 용량을 적극 활용하고 있고요.
장기적으로는 읽기 요청이 사용자 수에 비례해 선형적으로 확장되고, 사실상 무제한 읽기 작업을 지원하는 아키텍처를 목표로 삼고 있으며, 가장 트래픽이 큰 모노레포부터 순차적으로 적용할 계획입니다.
재발 방지: 재시도 폭주를 막아라
8월 6일과 17일, 두 번의 사고를 겪으며 GitHub는 즉각적인 안전장치도 추가했습니다.
- 서비스 간 상호작용에 일관된 재시도 한도 · 재시도 예산 · 가변 타임아웃을 적용해, Copilot 사태처럼 재시도가 재시도를 부르는 연쇄 부하를 원천 차단
- 그동안 우선순위가 낮아 방치됐던 CPU·메모리 경보를 재검토해, 트래픽이 급증할 때 조용히 무너질 수 있는 구성요소를 미리 찾아내는 작업
또한 핵심 시스템 간 공유 의존성을 제거해 한 곳의 장애가 다른 서비스로 번지는 범위 자체를 줄이는 중이라고 밝혔습니다.
정리하며
이번 사고는 결국 "성장 속도를 인프라가 따라가지 못했다"는 아주 근본적인 문제였습니다. 개발자들이 하루에도 몇 번씩 push하고 배포하는 플랫폼인 만큼, 신뢰성은 선택이 아니라 필수죠. GitHub가 CPU 300만 코어, 스토리지 120PB급의 대규모 투자와 함께 재시도 정책 정비, 의존성 격리 같은 구조적 개선을 병행하겠다고 밝힌 만큼, 앞으로의 안정성 회복 행보를 지켜볼 필요가 있겠습니다.