여기서 20%와 50%는 전체 사용자 비율이 아니라 요청 실패율에 해당한다. 따라서 이 수치만으로 전체 이용자 중 몇 퍼센트가 GitHub를 사용하지 못했는지를 계산할 수는 없다. 당시 보고는 장애가 전 세계적으로 발생했다고 설명했지만, 영향을 받은 이용자의 검증된 총인원은 제시하지 않았다.
이번 사건은 단순히 웹사이트가 느려진 문제가 아니었다. 개발자가 평소 사용하는 여러 기능이 동시에 흔들렸다.
즉, 개발자는 저장소를 열거나 파일을 내려받는 단계에서부터 풀 리퀘스트 검토, Actions 워크플로 실행, 웹훅 수신, 기업 계정 인증, Copilot 사용에 이르기까지 여러 지점에서 오류를 만날 수 있었다.
아니다. 당시 상황은 GitHub의 모든 구성 요소가 동시에 멈춘 전면 장애라기보다 여러 핵심 서비스가 영향을 받은 부분적·다중 서비스 장애로 보는 것이 정확하다. 한 동시대 상태 요약에서는 Git Operations, Packages, Pages, Codespaces가 정상 운영 중으로 표시됐다.
다만 특정 서비스가 정상으로 표시됐다고 해서 사용자의 전체 개발 워크플로가 작동했다는 뜻은 아니다. 예를 들어 Codespaces나 Pages가 이용 가능해도 저장소 다운로드, Actions, Pull Requests 또는 Webhooks가 불안정하면 실제 개발 업무는 계속 막힐 수 있다. 또한 각 서비스가 장애 기간 내내 완전히 영향을 받지 않았다고 단정할 만한 자료도 확인되지 않았다.
GitHub는 처음에 일부 서비스에서 성능 문제가 발생해 조사 중이라고 알렸다. 이후 문제를 일으킨 구성 요소를 확인했으며 시정 조치를 적용했다고 밝혔다. 복구 과정에서는 서비스가 뚜렷하게 회복되고 있다는 신호가 나타났지만, 일부 오류율은 한동안 높은 상태로 남아 엔지니어들이 계속 완화 조치와 모니터링을 진행했다.
GitHub 상태 페이지는 이후 GitHub.com 장애를 해결됨으로 표시했다. 다만 일부 애플리케이션에서 Copilot 인증 오류가 간헐적으로 발생해 추가 조치를 진행 중이라는 업데이트가 뒤따랐다. 당시 GitHub CLI와 GitHub App을 통한 Copilot 사용은 영향을 받지 않은 것으로 안내됐다.
제공된 자료만으로는 기술적 근본 원인이 확인되지 않았다. GitHub는 문제가 된 구성 요소를 찾아 완화 조치를 적용했다고 설명했지만, 특정 데이터베이스 장애나 배포 오류, 클라우드 사업자 문제, 인증 시스템 결함 가운데 무엇이 원인이었는지는 공개하지 않았다. 상태 페이지는 가능한 시점에 상세한 사후 분석을 공유하겠다고 밝혔다.
따라서 당시 기준으로는 원인을 특정하지 않고 **“사고 당시 공개적으로 확정되지 않았다”**고 설명하는 것이 가장 정확하다.
8월 17일 장애는 최근 발생한 일부 GitHub 장애보다 영향 범위가 훨씬 넓었다.
이전 사례들이 주로 Copilot이나 Actions처럼 특정 제품 영역에 집중됐다면, 8월 17일 장애는 GitHub 웹 경험, API, 협업 기능, 자동화, 웹훅, 저장소 접근, Copilot을 동시에 흔들었다.
GitHub가 Microsoft 소유라는 점 때문에 Microsoft 365나 Azure 전체 장애와의 연관성을 의심할 수 있지만, 제공된 자료만으로는 이번 사건이 Microsoft 365 또는 Azure 전반의 장애였다고 확인할 수 없다. 후속 조사에서 공통 원인이 제시되기 전까지는 GitHub 플랫폼 장애로 보는 것이 타당하다.