---
title: "AI 에이전트 부하에 흔들린 GitHub, 왜 다른 서비스보다 더 아팠나"
published: 2026-05-12T23:27:53.000Z
canonical: https://jeff.news/article/2584
---
# AI 에이전트 부하에 흔들린 GitHub, 왜 다른 서비스보다 더 아팠나

GitHub가 최근 몇 달 동안 가용성 저하, 검색 장애, GitHub Actions 문제, 심지어 squash merge에서 커밋이 빠지는 데이터 무결성 사고까지 겪었다. GitHub CTO는 AI 에이전트발 부하 증가를 원인으로 들었지만, 실제로는 2년간 약 3.5배 증가한 부하와 Azure 이전, 오래된 시스템, 조직적 지연이 겹친 문제에 가깝다. 개발자 입장에선 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 히스토리를 직접 뒤져 빠진 커밋을 복구해야 했음

> [!WARNING]
> 가용성 장애도 짜증나지만, 코드 호스팅 서비스에서 병합 결과가 틀어지는 건 급이 다름. 개발자가 믿고 맡긴 ‘저장소의 진실’이 흔들린 거라서 신뢰 손상이 훨씬 큼.

- 그 뒤에도 장애는 계속 이어졌음
  - 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배 규모를 설계해야 한다고 판단함

> [!IMPORTANT]
> Google은 이미 AI로 인해 코드 생산과 배포, 리뷰, 소스 제어 발자국이 10배 늘어날 수 있다고 준비 중이었다는 점이 기사에서 비교됨. GitHub는 개발자 생태계의 중심 서비스인데도 그 충격을 너무 늦게 반영한 모양새임.

## 왜 다른 서비스보다 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가 만든 결과를 못 믿게 되면 개발팀은 도구의 핵심 계약을 다시 의심하게 돼요. 코드 호스팅 서비스에서 신뢰는 기능보다 먼저 오는 인프라예요.

## 핵심 포인트

- GitHub의 최근 90일 추정 가동률이 85.51%까지 떨어졌고, 일부 기능은 하루 평균 2~3시간씩 영향을 받은 셈
- squash merge queue 버그로 2,092개 풀 리퀘스트에서 커밋이 누락되는 데이터 무결성 사고가 발생
- GitHub는 AI 에이전트 부하를 원인으로 들었지만, 실제 부하 증가는 2년간 약 3.5배였고 대응 계획은 늦게 시작됨
- GitHub는 자체 데이터센터에서 Azure로 이전하는 12개월짜리 대형 작업 중이라 장애가 더 눈에 띄게 터진 상황
- GitLab, Bitbucket, Forgejo 같은 대안이 다시 진지하게 거론되는 분위기

## 인사이트

GitHub 장애는 그냥 ‘요즘 트래픽 많네’ 수준이 아니라, 개발 워크플로 전체가 AI 시대의 부하 패턴을 못 따라간 사례로 봐야 함. 특히 코드 호스팅은 단순 웹서비스가 아니라 리뷰, 액션, 검색, 권한, 알림, 웹훅이 줄줄이 엮인 상태ful 시스템이라 작은 병목이 바로 업무 중단으로 번짐.