GitHub, 에이전트 코딩 급증에 30배 확장 모드… 장애 대응도 재설계

GitHub의 이번 가용성 업데이트는 사과문보다 수요 보고서에 가깝다. 4월 28일 공개한 글에서 GitHub는 2025년 10월 10배 용량 확장 계획을 시작했지만, 2026년 2월에는 이미 현재 기준 30배 규모를 전제로 다시 설계해야 했다고 적었다. 배경으로 지목한 것은 에이전트형 개발 워크플로의 급증이다. 2025년 12월 하순 이후 저장소 생성, PR 활동, API 사용, 자동화, 대형 저장소 작업이 한꺼번에 빠르게 늘었다는 설명이다.

이 변화가 무거운 이유는 PR 하나가 거치는 경로가 길기 때문이다. GitHub는 Git 저장소, 병합 가능성 검사, 브랜치 보호, GitHub Actions, 검색, 알림, 권한, 웹훅, API, 백그라운드 작업, 캐시, 데이터베이스까지 한 흐름 안에서 함께 압박받는다고 적었다. 트래픽이 한 지점만 때리는 구조가 아니라는 뜻이다. 사용량이 여러 계층에서 동시에 올라가면 작은 비효율도 곧바로 대기열과 데이터베이스 부하로 번진다.

최근 장애 2건은 그 압박이 실제로 어떻게 나타나는지 보여줬다. 4월 23일 merge queue 사고에서는 squash merge 방식으로 여러 PR을 묶어 처리할 때 잘못된 merge commit이 만들어졌고, 그 결과 230개 저장소와 2,092개 PR이 영향을 받았다. 4월 27일에는 Elasticsearch 하위 시스템 장애로 PR, 이슈, 프로젝트 일부 검색 기능이 멈췄다. GitHub는 데이터 손실은 없었고 Git 작업과 API도 영향받지 않았다고 밝혔지만, 검색이 비어버린 것만으로도 협업 흐름은 크게 흔들렸다.

핵심은 분명하다. AI 코딩 경쟁은 이제 모델 품질만으로 설명되지 않는다. 그 모델이 올라가는 개발 플랫폼이 얼마나 안정적으로 버티는지가 같은 무게를 갖기 시작했다. GitHub가 강조한 격리와 영향 반경 축소는 운영 용어처럼 보이지만, 실제로는 개발자 경험을 지키는 제품 기능이다. 에이전트형 코딩이 계속 늘어난다면 다음 승부처는 더 똑똑한 추천이 아니라, 그 추천이 몰고 오는 폭증을 아무 일 없었다는 듯 처리하는 인프라일 가능성이 크다.