AI 에이전트 부하에 흔들린 GitHub, 왜 다른 서비스보다 더 아팠나

GitHub 장애가 그냥 ‘좀 느림’이 아니었던 이유

• GitHub의 최근 안정성은 꽤 심각한 수준까지 내려갔음

  • 제3자 추적 기준으로 지난달엔 가용성이 90% 수준, 이번엔 86%까지 떨어졌고, 최근 90일 추정치는 85.51%로 잡힘
  • 이 수치가 맞다면 GitHub 일부 기능이 하루 평균 2~3시간씩 영향을 받은 셈이라, 헤비 유저 입장에선 ‘거의 매일 업무가 막힘’으로 느껴질 만함

• 제일 큰 사고는 단순 다운타임이 아니라 데이터 무결성 사고였음

  • 4월 23일, merge queue에서 squash merge를 쓸 때 merge group에 풀 리퀘스트가 2개 이상 있으면 잘못된 merge commit이 만들어지는 버그가 터짐
  • 결과적으로 이후 병합에서 커밋이 되돌려지거나 빠졌고, 총 2,092개 풀 리퀘스트가 영향을 받음
  • Modal, Zipline 같은 회사도 피해를 봤고, 고객들은 GitHub 도움 없이 git 히스토리를 직접 뒤져 빠진 커밋을 복구해야 했음

• 그 뒤에도 장애는 계속 이어졌음

  • 4월 27일엔 GitHub 웹 UI에서 풀 리퀘스트와 이슈가 사라진 것처럼 보이는 6시간짜리 장애가 있었음
  • 원인은 백엔드 Elasticsearch 클러스터 과부하였고, 데이터가 진짜 사라진 건 아니지만 화면에서 안 보이면 개발자에겐 사실상 작업 불가임
  • 4월 28일엔 일부 풀 리퀘스트 미노출과 GitHub Actions 문제, 4월 29일엔 저장소의 불완전한 풀 리퀘스트 문제가 이어짐

• 보안 이슈까지 겹쳤음

  • 보안 업체 Wiz는 git push 명령만으로 GitHub와 GitHub Enterprise Server의 모든 저장소에 접근할 수 있는 치명적 취약점을 공개함
  • GitHub.com은 6시간 안에 고쳤지만, 업데이트하지 않은 GitHub Enterprise Server는 여전히 위험한 상태로 남음

유명 오픈소스 개발자가 GitHub를 떠난 이유

• HashiCorp 창업자이자 Ghostty 개발자인 Mitchell Hashimoto는 GitHub가 전문적인 작업에 부적합하다고 공개적으로 말함

  • 그는 한 달 동안 GitHub 장애가 자기 작업을 방해한 날마다 표시를 해뒀는데, 거의 매일 표시가 있었다고 함
  • 글을 쓰던 날에도 GitHub Actions 장애 때문에 약 2시간 동안 풀 리퀘스트 리뷰를 못 했다고 밝힘
  • 18년 동안 GitHub를 써왔지만, 실제 개선이 있기 전까진 떠나겠다는 입장임

• 이 불만은 꽤 단순함

  • 개발자에게 도구는 일을 도와줘야 하는데, GitHub가 매일 몇 시간씩 일을 막고 있음
  • 오픈소스 프로젝트라도 리뷰, 테스트, 릴리스가 GitHub에 묶여 있으면 GitHub 장애가 곧 프로젝트 장애가 됨
  • 공식 상태 페이지가 괜찮아 보여도, 실제 헤비 유저 경험과는 괴리가 클 수 있음

GitHub의 설명은 ‘AI 에이전트 부하’

• GitHub CTO Vlad Fedorov는 최근 몇 달간의 신뢰성 하락 원인으로 AI 에이전트발 부하 증가를 지목함

  • GitHub가 공개한 그래프는 부하가 천천히 오르다 급격히 치솟는 모양이었지만, 문제는 Y축이 없었다는 점임
  • 기사 작성자가 GitHub에서 받은 데이터 기준으론 부하가 2년 동안 약 3.5배 증가한 수준으로 보임

• 3.5배가 가볍다는 뜻은 아니지만, ‘한 달 만에 10배’ 같은 급변은 아님

  • 다만 pull request 하나가 Git 저장소, mergeability check, branch protection, GitHub Actions, 검색, 알림, 권한, 웹훅, API, 백그라운드 잡, 캐시, 데이터베이스를 전부 건드리는 구조라면 이야기가 달라짐
  • 큐가 밀리고, 캐시 미스가 DB 부하가 되고, 인덱스가 밀리고, 재시도가 트래픽을 증폭시키면 작은 비효율도 여러 제품 경험을 동시에 망침

• GitHub는 2023년 수준의 부하에 도달하는 데 15년이 걸렸는데, 최근 2년 동안 그 위에 훨씬 빠른 증가분이 올라탄 셈임

  • 과거 성장 곡선을 기준으로 장기 인프라 결정을 했다면, AI 에이전트가 만든 새 부하 패턴이 그 계획을 낡게 만들었을 가능성이 큼
  • GitHub는 2025년 10월에야 10배 용량 증설 계획을 실행하기 시작했고, 2026년 2월엔 앞으로 30배 규모를 설계해야 한다고 판단함

왜 다른 서비스보다 GitHub가 더 아팠나

• GitHub는 자체 데이터센터에서 Azure로 이전하는 대형 마이그레이션 중임

  • 이 작업은 2025년 10월 시작됐고, 12개월짜리 프로젝트로 잡혀 있었음
  • 이미 자체 데이터센터 용량 제약이 있었기 때문에 Azure로 옮기는 중이었는데, 그 와중에 부하가 튀면 작은 버그도 사용자 눈에 크게 보임

• GitHub의 시스템은 상태가 많아서 단순 수평 확장만으로 해결하기 어려움

  • 상태가 적은 서비스라면 노드를 더 붙여 처리량을 늘리면 되지만, GitHub는 풀 리퀘스트, 워크플로, 프로젝트, 권한, 검색 인덱스, 알림처럼 상태가 얽힌 기능이 많음
  • 특히 데이터베이스와 워크플로 실행 계층은 ‘서버 더 추가’만으로 깔끔하게 해결되지 않는 경우가 많음

• 18년 된 서비스의 기술 부채와 조직 부채도 같이 터진 듯함

  • 10년 넘은 시스템이 많으면 수정 리스크가 커지고, 빠른 확장이 어려워짐
  • GitHub에는 약 4,000명이 일하고 그중 1,000명이 엔지니어인데, 팀 간 의존성이 많으면 단순한 개선도 여러 팀 조율이 필요함
  • 고객 워크플로를 깨면 안 되기 때문에, 과감한 구조 변경도 속도를 내기 어렵다

• 흥미로운 건 다른 벤더들은 비슷한 AI 성장세를 타면서도 GitHub만큼 크게 무너지진 않았다는 점임

  • Vercel, Linear, Resend, Railway, Sentry 같은 인프라 서비스들도 AI 덕분에 기록적인 성장을 보고 있지만 GitHub 수준의 가용성 논란은 덜함
  • GitLab, Bitbucket 같은 직접 경쟁자들도 비슷한 부하 증가를 겪을 수 있는데, GitHub만큼 자주 내려간다는 인식은 강하지 않음
  • 그래서 이 문제는 단순히 ‘AI가 너무 많이 써서’라기보다 GitHub의 예측 실패와 구조적 대응 지연이 섞인 문제로 보임

개발자 입장에서 현실적인 선택지

• 지금 GitHub를 계속 쓴다는 건 어느 정도 장애 리스크를 감수한다는 뜻이 됨

  • Microsoft가 결국 안정성을 회복할 거라고 믿고 기다릴 수도 있음
  • 하지만 매일 리뷰, 액션, 이슈 관리가 막히는 팀이라면 대안을 검토할 이유가 충분함

• 대안은 이미 있음

  • GitLab과 Bitbucket은 GitHub의 대표적인 경쟁자이고, Git 호스팅과 협업 기능을 제공함
  • 자체 호스팅 git 저장소나 Forgejo 같은 오픈소스 GitHub 대안도 선택지임
  • 앞으로는 GitHub식 코드 호스팅을 더 높은 가용성과 AI 시대 부하를 전제로 다시 설계한 스타트업이 나올 가능성도 있음

---

기술 맥락

• GitHub가 힘든 이유는 pull request가 단순한 텍스트 덩어리가 아니기 때문이에요. 하나의 PR이 저장소, 권한, 브랜치 보호, 테스트, 검색, 알림, 웹훅을 동시에 건드리니까, 한 컴포넌트가 느려지면 개발자가 보는 화면 전체가 같이 흔들려요.

• AI 에이전트 부하는 사람 개발자의 부하와 패턴이 달라요. 사람이 하루에 몇 번 누르던 동작을 에이전트는 반복적으로 호출하고, 실패하면 재시도하고, 여러 저장소와 브랜치를 동시에 건드릴 수 있거든요. 그래서 평균 트래픽보다 피크와 재시도 증폭이 더 무서워져요.

• GitHub의 Azure 이전도 중요한 배경이에요. 대규모 마이그레이션은 평소에도 장애를 숨기기 어렵고, 부하가 안정적이어야 계획대로 움직이기 쉬워요. 그런데 이전 도중에 부하 예측이 틀어지면 용량 계획, 장애 격리, 롤백 전략이 전부 더 빡세져요.

• 이번 사건에서 제일 아픈 부분은 데이터 무결성이에요. 웹 UI가 느린 건 참을 수 있어도, merge queue와 squash merge가 만든 결과를 못 믿게 되면 개발팀은 도구의 핵심 계약을 다시 의심하게 돼요. 코드 호스팅 서비스에서 신뢰는 기능보다 먼저 오는 인프라예요.