GitHub는 2026년 8월 서비스 가용성에 영향을 미친 5건의 사고 세부 내용을 공개했다. 여기에는 GitHub Actions 장애, Copilot Cloud Agent 결과 지연, Kimi K3 모델 요청 실패가 포함된다. 회사는 이러한 사고가 플랫폼 성장과 빠듯한 용량 여유, 자동 확장 결함, 재시도 정책 및 복구 메커니즘의 문제와 관련 있다고 설명했다.
GitHub는 아키텍처 개선과 더 많은 서비스의 Azure 이전에 투자하고 있으며, 가용성, 용량, 기능 순으로 우선순위를 두고 있다고 밝혔다. 또한 용량 모니터링, 큐 관리, 재시도 정책, 핵심 서비스의 복원력을 개선했다고 발표했다.
서로 다른 원인으로 발생한 5건의 사고
- 8월 6일: 사고는 10시간 42분 동안 지속됐다. Actions 내부 서비스에 대한 정기 배포로 한 리전의 용량이 일시적으로 감소한 것이 원인이었다. 이로 인해 서비스가 포화 상태에 이르렀고 오류가 캐시, DNS, API에 전파됐으며, 작업 할당 경로의 결함으로 복구 과정도 느려졌다. 상당수의 워크플로 실행이 실패하거나 지연됐고, 일부 이벤트는 수동으로 재실행해야 했다.
- 8월 17일: 성능 저하는 7시간 35분 동안 지속됐다. 데이터센터의 로드 밸런서가 용량 정점에 도달한 가운데, 서비스 네트워크의 한 보조 구성 요소가 동시성 한계에 도달했음에도 확장되지 않은 것이 원인이었다. 이로 인해 공유 인증 경로가 지연되고 실패했으며, 영향이 Issues, Pull Requests, API, Actions, Copilot으로 확산됐다. 또한 재시도 결함으로 내부 인증 지점에 대한 요청 트래픽이 두 배로 증가했다.
- 8월 20일: 사고는 9시간 54분 동안 지속됐으며, 최소 54개 조직의 Copilot Cloud Agent 작업 상태와 결과에 영향을 미쳤다. 작업 상태를 저장하는 클라우드 데이터베이스 제공업체의 한 리전에서 장애가 발생했고, 스토리지 설정 문제로 지역 전환이 신속하게 이루어지지 않아 상태 업데이트가 누적됐다. 작업 자체는 손실되지 않았지만, 처리가 복구되고 큐가 비워질 때까지 결과 표시가 지연됐다.
- 8월 26일: 성능 저하는 2시간 50분 동안 지속됐다. 이벤트가 급증하면서 한계에 가깝게 작동하던 공유 데이터베이스가 포화 상태에 이른 것이 원인이었다. 이로 인해 Actions 실행 시작이 지연됐고, Copilot Code Review와 일부 GitHub Pages 작업 등 해당 데이터베이스에 의존하는 서비스가 영향을 받았다. 스트레스 징후가 나타날 때 보호 기능을 자동으로 활성화하는 회로 차단기가 없었기 때문에 GitHub는 유입 부하를 점진적으로 제한해야 했다.
- 8월 27일: 사고는 2시간 8분 동안 지속됐으며, 외부 모델 제공업체의 성능 저하로 Copilot에서 Kimi K3 모델로 전송된 요청에만 영향을 미쳤다. 사고 정점에서 해당 요청의 실패율은 50%를 넘었지만, 다른 모델과 Auto 설정은 계속 이용할 수 있었다.
실제로 무엇이 바뀌었나?
발표된 조치는 GitHub가 사고를 단순한 개별 배포 오류가 아니라 용량, 격리, 복구 문제로 다루고 있음을 보여준다. GitHub는 Actions 작업의 33%를 제한된 프로덕션 클러스터에서 예비 용량으로 이전했으며, 그 결과 정점 시 캐시 프로세서 사용률이 98%에서 80%로 낮아졌고 자체 추산으로 약 3개월의 여유가 추가됐다. Azure로 이전된 서비스의 읽기 사용률은 60.4%로 정점에 도달했으며, 단일 시스템의 읽기 사용률은 64.3%, Git의 읽기 사용률은 54%였다.
데이터베이스 측면에서는 8월 11일 Azure에서 첫 번째 프로덕션 MySQL 프라이머리가 가동됐으며, 고객이 관찰한 쓰기 작업에는 눈에 띄는 영향이 없었다. 이후 8월 27일 두 개의 핵심 데이터베이스에서도 같은 방식이 반복됐다. 또한 GitHub는 기존 데이터베이스 복제본에서 초당 약 100만 건의 쿼리를 제거했으며, 다른 변경을 통해 초당 12만 건의 쿼리와 시간당 약 5만 9천 초의 낭비된 작업을 줄였다.
이 보고서가 중요한 이유
이번 사고는 서비스가 데이터베이스, 인증 경로 또는 단일 Actions 인프라를 공유할 때 수평 확장만으로는 충분하지 않다는 점을 보여준다. 또한 통제되지 않은 재시도는 부분적인 성능 저하를 더 광범위한 부하로 전환할 수 있으며, 지역 간 전환이 지연되면 원래 작업이 손실되지 않더라도 상태가 누적될 수 있다. Azure 계획과 격리 조치, 부하 차단기는 아직 구현 중이므로 이 보고서가 위험이 제거됐음을 입증하는 것은 아니다. 다만 GitHub가 앞으로 집중할 영역, 즉 추가 핵심 데이터베이스 이전, 용량 관리 자동화, 종속성 장애 대응 확대가 무엇인지 보여준다.