GitHub 7시간 장애 원인 분석: 용량 병목·재시도 폭풍과 서버 운영 교훈

GitHub의 2026년 8월 17일 장애는 7시간 47분 동안 인증, Actions, API, Pull Request, Issues와 Copilot에 영향을 줬습니다. 단순한 서버 고장이 아니라 용량 병목과 복구 과정의 재시도 폭풍이 결합된 대규모 분산 시스템 장애였습니다.

GitHub 8월 17일 장애 요약

GitHub 공식 사후 설명에 따르면 장애는 세계 여러 지역의 개발자와 조직에 영향을 줬습니다. github.com 접속뿐 아니라 인증과 Git 작업, CI/CD, 협업 기능이 함께 흔들렸다는 점에서 GitHub를 단일 개발 도구가 아니라 핵심 생산 인프라로 사용하는 조직의 위험이 드러났습니다.

장애는 어떻게 확산됐나

새로운 트래픽 정점에서 Central US 데이터센터의 핵심 구성요소가 필요한 만큼 확장되지 못했습니다. 용량 압박은 인증 실패와 여러 서비스 장애로 이어졌고, GitHub는 트래픽 우회와 인프라 격리, 단계적 복구를 진행했습니다.

대부분 서비스가 먼저 회복됐지만 일부 Copilot 오류가 클라이언트 재시도 루프를 만들었습니다. 실패한 요청이 즉시 반복되면 복구 중인 서버에 정상 트래픽보다 더 큰 부하를 주는 재시도 폭풍이 발생할 수 있습니다. GitHub는 이 동작을 완화한 뒤에야 안전하게 트래픽을 복원할 수 있었다고 설명했습니다.

트래픽 성장이 만든 용량 병목

GitHub는 월간 커밋 수가 2026년 4월 14억 건에서 29억 건으로 증가했다고 밝혔습니다. 빠른 성장은 장애의 배경이지만 면책 사유는 아닙니다. 핵심 시스템의 용량 예측과 확장, 공유 의존성 격리가 서비스 성장 속도를 따라가지 못한 것이 문제였습니다.

회사는 300만 개 이상의 CPU 코어와 120PB의 고속 스토리지를 추가했고 Azure 이전도 확대했습니다. 공식 설명 기준 Azure는 플랫폼 부하의 약 58%, Git 작업의 절반을 처리합니다.

백엔드와 SRE 팀이 배울 점

• 모든 재시도에는 최대 횟수, 지수 백오프와 무작위 지연을 적용합니다.
• 서비스별 재시도 예산을 두어 장애 시 요청 증폭을 막습니다.
• 평균 사용량이 아니라 갑작스러운 피크와 복구 트래픽을 기준으로 용량을 시험합니다.
• 인증처럼 공통으로 사용하는 핵심 시스템은 장애 영역을 분리합니다.
• CI/CD가 외부 SaaS 하나에 전적으로 의존하지 않도록 비상 배포 경로를 준비합니다.

GitHub 의존 조직의 대응 체크리스트

저장소 미러와 빌드 아티팩트 캐시, 긴급 배포용 인증정보를 별도로 관리해야 합니다. 장애 중에도 운영 중인 서비스를 수정할 수 있는 최소한의 절차와 담당자를 문서화하고 정기적으로 훈련하는 것이 중요합니다.

GitHub Actions를 사용하는 조직은 외부 액션과 패키지 저장소까지 포함한 전체 의존 경로를 그려봐야 합니다. 소스 저장소가 복구돼도 패키지·컨테이너·클라우드 인증 중 하나가 막히면 배포는 계속 실패할 수 있습니다.

자주 묻는 질문

이번 GitHub 장애는 해킹 때문이었나요?

GitHub 공식 설명은 코드나 설정 변경이 아니라 용량 실패를 핵심 원인으로 제시했습니다. 공개된 내용만으로 사이버 공격이 원인이라고 볼 근거는 없습니다.

GitHub Actions만 별도로 대비할 수 있나요?

중요 워크로드의 실행 파일과 컨테이너를 캐시하고, 긴급한 경우 사용할 대체 빌드·배포 절차를 준비할 수 있습니다.

재시도는 안정성을 높이는 기능 아닌가요?

일시 오류에는 도움이 되지만 제한 없는 동시 재시도는 장애 서버의 부하를 증폭합니다. 백오프, 지터, 최대 횟수와 재시도 예산을 함께 적용해야 합니다.