GitHub 가용성에 대한 업데이트

GitHub는 최근 두 건의 장애를 사과하며, 가용성을 최우선에 두고 용량과 새 기능을 뒤따르게 하는 확장 계획을 공개했다. 2025년 10월부터 10X 확대를 시작했지만, 2026년 2월에는 현재 규모의 30배를 대비해야 한다는 결론에 도달했다. 2025년 12월 하순 이후 에이전트형 개발 워크플로가 급격히 늘면서 저장소 생성, PR, API, 자동화, 대형 저장소 작업이 빠르게 증가하고 있다.

대규모 성장 압력은 Git 저장소, 병합 가능성 검사, 브랜치 보호, GitHub Actions, 검색, 알림, 권한, webhooks, API, 백그라운드 작업, 캐시, DB 전반에 동시에 번진다. GitHub는 의존성과 트래픽 계층을 분석해 우선순위를 정하고, 불필요한 작업을 줄이고, 캐시를 개선하고, 핵심 서비스를 격리하고, 단일 장애 지점을 제거하고, 성능 민감 경로를 맞는 시스템으로 옮기고 있다.

단기적으로는 webhooks를 MySQL 밖의 다른 처리 계층으로 옮기고, 사용자 세션 캐시와 인증/인가 흐름을 재설계해 DB 부하를 크게 줄였다. Azure 이전으로 연산 자원도 추가 확보했다.

중장기적으로는 Git과 GitHub Actions를 다른 워크로드와 분리하고, Ruby 기반 단일 거대 코드베이스에서 성능·스케일 민감 코드를 Go로 옮기며, 공용 클라우드에서 다중 클라우드로 가는 길을 준비하고 있다. 대형 monorepo 확산에 대응해 merge queue 개선도 강화했고, 효율성과 규모를 높이기 위한 새 API 설계도 곧 별도로 공개할 예정이다.

투명성 측면에서는 GitHub 상태 페이지에 가용성 수치를 추가하고, 큰 장애와 작은 장애를 모두 상태 페이지에 반영하며, 장애 분류와 고객 신고 방식도 개선 중이다.

• 2026년 4월 23일 merge queue 장애: merge queue의 squash merge에서 merge group에 PR이 둘 이상 있을 때 잘못된 merge commit이 생성됐다. 이전에 병합된 PR과 선행 commit의 변경이 뒤이어 적용된 merge에서 의도치 않게 되돌려졌고, 230개 저장소와 2,092개 PR가 영향을 받았다. 커밋들은 Git에 그대로 남아 있었고 데이터 손실은 없었지만, 영향받은 기본 브랜치 상태가 잘못돼 모든 저장소를 자동 복구할 수는 없었다.
• 2026년 4월 27일 Elasticsearch 장애: Elasticsearch 하위 시스템이 과부하에 빠져 검색 결과를 반환하지 못했다. 원인은 botnet 공격 가능성이 있으며 아직 원인 분석을 마무리 중이다. 데이터 손실은 없었고 Git 작업과 API는 영향받지 않았지만, 검색에 의존하는 PR, issue, project UI 일부에서 결과가 나타나지 않았다.

GitHub는 이번 장애를 계기로 가용성, 격리, 영향 범위 축소에 더 집중하고, 개방적이고 확장 가능한 플랫폼으로서 개발자를 더 안정적으로 지원하겠다고 밝혔다.