8월 17일, GitHub가 8시간 가까이 먹통이 됐다.
Issues·Pull Requests·Actions·API·Copilot까지 줄줄이 오류를 냈다.
다음 날 GitHub가 근본 원인 분석(RCA)을 공식 상태 페이지에 올렸다.
7시간 47분, 무엇이 멈췄나
GitHub Developer Experience 시니어 디렉터 Cassidy Williams가 2026년 8월 18일 오후 7시 31분(KST) X에 "어제 장애의 RCA가 공개됐다"고 공지했다.
공식 GitHub 상태 페이지 인시던트 리포트에 따르면, 장애는 협정세계시(UTC) 8월 17일 13시 28분부터 21시 15분까지 약 7시간 47분 이어졌다.
정점에서는 웹·API 오류율이 약 20%, 아카이브·원본 파일 다운로드 오류율은 약 50%까지 치솟았다.
SAML·OIDC 기반 인증 시스템도 함께 영향을 받았다.
시작은 사이드카 하나의 확장 실패
공식 RCA는 원인을 미국 중부 데이터센터의 네트워크 포화로 지목했다.
발단은 서비스 메시에 쓰이는 Istio 사이드카 파드가 동시성 한도에 도달했는데, 오토스케일링 정책 설정 오류로 제대로 확장되지 않은 것이었다.
이 병목이 로드밸런서 용량을 소진시켰고, 여기에 "낙관적 재시도(optimistic retry) 로직"이 내부 로드밸런서에 부하를 더 얹으며 장애가 연쇄적으로 커졌다.
GitHub는 VS Code의 재시도 동작이 Copilot 트래픽을 증폭시킨 점도 원인 중 하나로 명시했다.
재발 방지 조치와 실무 시사점
GitHub는 RCA에서 다음 조치를 명시했다: 서비스 메시 사이드카의 오토스케일링 정책 수정, Istio 요청·동시성 한도 전수 점검, 게이트웨이·클라이언트 전반의 재시도 동작 재검토, VS Code의 Copilot 재시도 로직 개선, 로드밸런서 모니터링·장애조치 안전장치 강화.
사이드카 프록시 기반 서비스 메시(Istio 등)를 쓰는 국내 팀이라면, 오토스케일링 한도가 실제 트래픽 급증 상황에서 제대로 작동하는지 점검할 만한 사례다.
클라이언트의 "낙관적 재시도"가 장애 상황에서 오히려 부하를 키운다는 점도 재시도 정책 설계 시 참고할 지점이다.
한 달 13번째 장애, 원인은 언제 나오나
이번 장애는 2026년 8월 들어 GitHub가 겪은 13번째 개별 인시던트였다(9일 동안 분산).
근본적인 아키텍처·분산 시스템 구조 문제가 있는 것 아니냐는 개발자 지적에, Williams는 "월간 가용성 리포트로 크고 작은 이슈와 대응 현황을 공개하고 있다"고 답했을 뿐, 반복되는 장애의 구조적 원인에 대한 별도 설명은 아직 없다.
8월 전체를 다루는 월간 가용성 리포트는 9월 공개 예정이다.
