GitHub 전체가 완전히 멈춘 것은 아니지만, 저장소 접근과 다운로드부터 코드 리뷰, CI/CD 자동화, 외부 연동, Copilot까지 개발 과정의 핵심 단계가 광범위하게 불안정해졌다.

오류율은 어느 정도였나

GitHub는 웹 경험과 API 트래픽에서 약 20%의 높은 오류율을 확인했다고 밝혔다. 저장소 아카이브 다운로드와 원시(raw) 저장소 콘텐츠 다운로드의 오류율은 약 **50%**에 달했다.

여기서 20%와 50%는 전체 사용자 비율이 아니라 요청 실패율에 해당한다. 따라서 이 수치만으로 전체 이용자 중 몇 퍼센트가 GitHub를 사용하지 못했는지를 계산할 수는 없다. 당시 보고는 장애가 전 세계적으로 발생했다고 설명했지만, 영향을 받은 이용자의 검증된 총인원은 제시하지 않았다.

어떤 GitHub 기능이 영향을 받았나

이번 사건은 단순히 웹사이트가 느려진 문제가 아니었다. 개발자가 평소 사용하는 여러 기능이 동시에 흔들렸다.

• 저장소와 다운로드: 아카이브와 raw 파일 다운로드가 특히 불안정해 코드와 파일을 내려받기 어려웠다.
• API 요청: GitHub API 오류가 늘면서 스크립트, 개발 도구, 외부 통합 서비스가 정상적으로 요청을 처리하지 못할 수 있었다.
• Pull Requests·Issues: 풀 리퀘스트를 통한 코드 리뷰와 이슈 관리 등 협업 기능의 가용성이 떨어졌다.
• GitHub Actions: CI/CD 파이프라인과 자동화 워크플로가 영향을 받아 작업 실행이나 완료 확인이 지연되거나 실패할 수 있었다.
• Webhooks: 배포, 모니터링, 자동화 시스템으로 전달되는 이벤트가 지연되거나 누락될 가능성이 커졌다.
• Git 작업: 저장소 작업을 포함한 Git 성능도 저하된 것으로 보고됐다.
• Copilot: GitHub Copilot은 장애 또는 심각한 서비스 저하 상태로 별도 표시됐다. 이에 따라 일부 사용자는 IDE나 채팅에서 AI 코딩 지원을 받기 어려웠다.
• 기업용 인증·프로비저닝: 당시 보고에는 SAML·OIDC 인증, SCIM, Team Sync 관련 기능도 영향을 받은 것으로 나타났다. 다만 기능별 영향 범위와 정확한 시간대가 모두 공개된 것은 아니다.

즉, 개발자는 저장소를 열거나 파일을 내려받는 단계에서부터 풀 리퀘스트 검토, Actions 워크플로 실행, 웹훅 수신, 기업 계정 인증, Copilot 사용에 이르기까지 여러 지점에서 오류를 만날 수 있었다.

모든 서비스가 중단된 것은 아니다

아니다. 당시 상황은 GitHub의 모든 구성 요소가 동시에 멈춘 전면 장애라기보다 여러 핵심 서비스가 영향을 받은 부분적·다중 서비스 장애로 보는 것이 정확하다. 한 동시대 상태 요약에서는 Git Operations, Packages, Pages, Codespaces가 정상 운영 중으로 표시됐다.

다만 특정 서비스가 정상으로 표시됐다고 해서 사용자의 전체 개발 워크플로가 작동했다는 뜻은 아니다. 예를 들어 Codespaces나 Pages가 이용 가능해도 저장소 다운로드, Actions, Pull Requests 또는 Webhooks가 불안정하면 실제 개발 업무는 계속 막힐 수 있다. 또한 각 서비스가 장애 기간 내내 완전히 영향을 받지 않았다고 단정할 만한 자료도 확인되지 않았다.

GitHub는 어떻게 복구했나

GitHub는 처음에 일부 서비스에서 성능 문제가 발생해 조사 중이라고 알렸다. 이후 문제를 일으킨 구성 요소를 확인했으며 시정 조치를 적용했다고 밝혔다. 복구 과정에서는 서비스가 뚜렷하게 회복되고 있다는 신호가 나타났지만, 일부 오류율은 한동안 높은 상태로 남아 엔지니어들이 계속 완화 조치와 모니터링을 진행했다.

GitHub 상태 페이지는 이후 GitHub.com 장애를 해결됨으로 표시했다. 다만 일부 애플리케이션에서 Copilot 인증 오류가 간헐적으로 발생해 추가 조치를 진행 중이라는 업데이트가 뒤따랐다. 당시 GitHub CLI와 GitHub App을 통한 Copilot 사용은 영향을 받지 않은 것으로 안내됐다.

장애 원인은 밝혀졌나

제공된 자료만으로는 기술적 근본 원인이 확인되지 않았다. GitHub는 문제가 된 구성 요소를 찾아 완화 조치를 적용했다고 설명했지만, 특정 데이터베이스 장애나 배포 오류, 클라우드 사업자 문제, 인증 시스템 결함 가운데 무엇이 원인이었는지는 공개하지 않았다. 상태 페이지는 가능한 시점에 상세한 사후 분석을 공유하겠다고 밝혔다.

따라서 당시 기준으로는 원인을 특정하지 않고 **“사고 당시 공개적으로 확정되지 않았다”**고 설명하는 것이 가장 정확하다.

최근 GitHub 장애와 비교하면

8월 17일 장애는 최근 발생한 일부 GitHub 장애보다 영향 범위가 훨씬 넓었다.

• 8월 1일: GitHub Copilot의 GPT-5.6 Luna 모델이 간헐적으로 불안정했다. 원인은 외부 모델 제공업체 문제로 보고됐으며, 다른 Copilot 모델은 영향을 받지 않았다.
• 8월 10일: Copilot에서 일부 모델에 접근하는 기능이 중단됐다.
• 8월 13일: Copilot의 Fable 5 모델에서 오류가 발생했고, GitHub는 외부 모델 제공업체 문제로 설명했다.
• 8월 6~7일: 별도의 GitHub Actions 장애로 워크플로 실행이 실패하거나 장시간 대기하는 문제가 발생했다.

이전 사례들이 주로 Copilot이나 Actions처럼 특정 제품 영역에 집중됐다면, 8월 17일 장애는 GitHub 웹 경험, API, 협업 기능, 자동화, 웹훅, 저장소 접근, Copilot을 동시에 흔들었다.

GitHub가 Microsoft 소유라는 점 때문에 Microsoft 365나 Azure 전체 장애와의 연관성을 의심할 수 있지만, 제공된 자료만으로는 이번 사건이 Microsoft 365 또는 Azure 전반의 장애였다고 확인할 수 없다. 후속 조사에서 공통 원인이 제시되기 전까지는 GitHub 플랫폼 장애로 보는 것이 타당하다.

GitHub 전체가 완전히 멈춘 것은 아니지만, 저장소 접근과 다운로드부터 코드 리뷰, CI/CD 자동화, 외부 연동, Copilot까지 개발 과정의 핵심 단계가 광범위하게 불안정해졌다.

오류율은 어느 정도였나

GitHub는 웹 경험과 API 트래픽에서 약 20%의 높은 오류율을 확인했다고 밝혔다. 저장소 아카이브 다운로드와 원시(raw) 저장소 콘텐츠 다운로드의 오류율은 약 **50%**에 달했다.

여기서 20%와 50%는 전체 사용자 비율이 아니라 요청 실패율에 해당한다. 따라서 이 수치만으로 전체 이용자 중 몇 퍼센트가 GitHub를 사용하지 못했는지를 계산할 수는 없다. 당시 보고는 장애가 전 세계적으로 발생했다고 설명했지만, 영향을 받은 이용자의 검증된 총인원은 제시하지 않았다.

어떤 GitHub 기능이 영향을 받았나

이번 사건은 단순히 웹사이트가 느려진 문제가 아니었다. 개발자가 평소 사용하는 여러 기능이 동시에 흔들렸다.

• 저장소와 다운로드: 아카이브와 raw 파일 다운로드가 특히 불안정해 코드와 파일을 내려받기 어려웠다.
• API 요청: GitHub API 오류가 늘면서 스크립트, 개발 도구, 외부 통합 서비스가 정상적으로 요청을 처리하지 못할 수 있었다.
• Pull Requests·Issues: 풀 리퀘스트를 통한 코드 리뷰와 이슈 관리 등 협업 기능의 가용성이 떨어졌다.
• GitHub Actions: CI/CD 파이프라인과 자동화 워크플로가 영향을 받아 작업 실행이나 완료 확인이 지연되거나 실패할 수 있었다.
• Webhooks: 배포, 모니터링, 자동화 시스템으로 전달되는 이벤트가 지연되거나 누락될 가능성이 커졌다.
• Git 작업: 저장소 작업을 포함한 Git 성능도 저하된 것으로 보고됐다.
• Copilot: GitHub Copilot은 장애 또는 심각한 서비스 저하 상태로 별도 표시됐다. 이에 따라 일부 사용자는 IDE나 채팅에서 AI 코딩 지원을 받기 어려웠다.
• 기업용 인증·프로비저닝: 당시 보고에는 SAML·OIDC 인증, SCIM, Team Sync 관련 기능도 영향을 받은 것으로 나타났다. 다만 기능별 영향 범위와 정확한 시간대가 모두 공개된 것은 아니다.

즉, 개발자는 저장소를 열거나 파일을 내려받는 단계에서부터 풀 리퀘스트 검토, Actions 워크플로 실행, 웹훅 수신, 기업 계정 인증, Copilot 사용에 이르기까지 여러 지점에서 오류를 만날 수 있었다.

모든 서비스가 중단된 것은 아니다

아니다. 당시 상황은 GitHub의 모든 구성 요소가 동시에 멈춘 전면 장애라기보다 여러 핵심 서비스가 영향을 받은 부분적·다중 서비스 장애로 보는 것이 정확하다. 한 동시대 상태 요약에서는 Git Operations, Packages, Pages, Codespaces가 정상 운영 중으로 표시됐다.

다만 특정 서비스가 정상으로 표시됐다고 해서 사용자의 전체 개발 워크플로가 작동했다는 뜻은 아니다. 예를 들어 Codespaces나 Pages가 이용 가능해도 저장소 다운로드, Actions, Pull Requests 또는 Webhooks가 불안정하면 실제 개발 업무는 계속 막힐 수 있다. 또한 각 서비스가 장애 기간 내내 완전히 영향을 받지 않았다고 단정할 만한 자료도 확인되지 않았다.

GitHub는 어떻게 복구했나

GitHub는 처음에 일부 서비스에서 성능 문제가 발생해 조사 중이라고 알렸다. 이후 문제를 일으킨 구성 요소를 확인했으며 시정 조치를 적용했다고 밝혔다. 복구 과정에서는 서비스가 뚜렷하게 회복되고 있다는 신호가 나타났지만, 일부 오류율은 한동안 높은 상태로 남아 엔지니어들이 계속 완화 조치와 모니터링을 진행했다.

GitHub 상태 페이지는 이후 GitHub.com 장애를 해결됨으로 표시했다. 다만 일부 애플리케이션에서 Copilot 인증 오류가 간헐적으로 발생해 추가 조치를 진행 중이라는 업데이트가 뒤따랐다. 당시 GitHub CLI와 GitHub App을 통한 Copilot 사용은 영향을 받지 않은 것으로 안내됐다.

장애 원인은 밝혀졌나

제공된 자료만으로는 기술적 근본 원인이 확인되지 않았다. GitHub는 문제가 된 구성 요소를 찾아 완화 조치를 적용했다고 설명했지만, 특정 데이터베이스 장애나 배포 오류, 클라우드 사업자 문제, 인증 시스템 결함 가운데 무엇이 원인이었는지는 공개하지 않았다. 상태 페이지는 가능한 시점에 상세한 사후 분석을 공유하겠다고 밝혔다.

따라서 당시 기준으로는 원인을 특정하지 않고 **“사고 당시 공개적으로 확정되지 않았다”**고 설명하는 것이 가장 정확하다.

최근 GitHub 장애와 비교하면

8월 17일 장애는 최근 발생한 일부 GitHub 장애보다 영향 범위가 훨씬 넓었다.

• 8월 1일: GitHub Copilot의 GPT-5.6 Luna 모델이 간헐적으로 불안정했다. 원인은 외부 모델 제공업체 문제로 보고됐으며, 다른 Copilot 모델은 영향을 받지 않았다.
• 8월 10일: Copilot에서 일부 모델에 접근하는 기능이 중단됐다.
• 8월 13일: Copilot의 Fable 5 모델에서 오류가 발생했고, GitHub는 외부 모델 제공업체 문제로 설명했다.
• 8월 6~7일: 별도의 GitHub Actions 장애로 워크플로 실행이 실패하거나 장시간 대기하는 문제가 발생했다.

이전 사례들이 주로 Copilot이나 Actions처럼 특정 제품 영역에 집중됐다면, 8월 17일 장애는 GitHub 웹 경험, API, 협업 기능, 자동화, 웹훅, 저장소 접근, Copilot을 동시에 흔들었다.

GitHub가 Microsoft 소유라는 점 때문에 Microsoft 365나 Azure 전체 장애와의 연관성을 의심할 수 있지만, 제공된 자료만으로는 이번 사건이 Microsoft 365 또는 Azure 전반의 장애였다고 확인할 수 없다. 후속 조사에서 공통 원인이 제시되기 전까지는 GitHub 플랫폼 장애로 보는 것이 타당하다.