GitHub가 AWS를 빌린 날: Microsoft 클라우드 전략의 균열 (runtimewire.com)
목차(4)
한줄 요약
Microsoft가 GitHub 급증 트래픽을 감당 못해 AWS 용량을 긴급 도입했다.
AI 에이전트 개발 붐이 GitHub 인프라를 한계까지 밀어붙이면서, Microsoft가 경쟁사인 AWS의 클라우드 용량을 임시 수혈하는 사태가 벌어졌다. 2018년 $7.5억 달러에 GitHub를 인수하며 "모든 개발 워크로드를 Azure로"를 꿈꿨던 전략이, 현실의 트래픽 앞에서 균열을 드러낸 것이다.
무엇이 달라졌나?
커밋 수가 14배 뛰었다. GitHub COO Kyle Daigle에 따르면 2025년 연간 약 10억 건이던 커밋이 2026년에는 140억 건 페이스로 달리고 있다. 단순한 사용자 증가가 아니라, AI 코딩 에이전트가 자동으로 코드를 생성·커밋·PR을 올리는 "에이전틱 개발" 방식이 2025년 하반기부터 급격히 확산된 결과다.
GitHub CTO Vlad Fedorov는 공식 블로그를 통해 2025년 10월 시점에 10배 용량 확장을 목표로 계획을 세웠으나, 2026년 2월에는 30배 규모를 설계해야 한다는 결론에 도달했다고 밝혔다. 4개월 만에 목표치가 세 배로 뛴 셈이다.
인프라 이전은 분명히 진행 중이다. GitHub의 2026년 5월 가용성 보고서에 따르면, 핵심 모놀리스 트래픽의 40%가 Azure에서 처리되고 있다. 2026년 2월의 8%에서 급격히 올랐다. Git 트래픽은 30%, 저장소 복제는 99%가 Azure로 전환됐다. 하지만 그 과정에서 5월 한 달에만 서비스 저하 사고가 9건 발생했고, 그중 5월 4일 장애는 데이터베이스 스키마 마이그레이션 하나가 PR, 이슈, Actions, 웹훅, Git 작업 전반으로 연쇄 장애를 일으킨 사례였다.
이 맥락에서 AWS 용량 도입 결정이 나왔다. Microsoft는 AWS를 직접 언급하지 않았지만, "에이전틱 개발의 급격한 증가"가 GitHub 인프라 한계를 시험했으며 멀티 클라우드 전략으로 탄력성을 확보하겠다고 공식 인정했다.
실무에서 어떤 의미인가?
이 사건이 보여주는 교훈은 세 가지다.
첫째, "내 클라우드니까 우선 배정"은 실제로 작동하지 않는다. Microsoft는 2026년 캘린더 연도 기준 약 1,900억 달러 규모의 자본 지출을 예고했다. 그 막대한 투자에도 불구하고, GPU·CPU·스토리지 용량은 Azure 외부 고객, OpenAI 관련 수요, Copilot 제품, 보안·데이터 서비스 등 수많은 내부 청구자들과 경쟁한다. GitHub는 전략 자산인 동시에 그 경쟁에서 밀릴 수 있는 내부 고객 중 하나다.
둘째, 마이그레이션 중인 플랫폼에 폭발적 트래픽이 겹치면 장애는 필연이다. 레거시 시스템을 Azure로 조각조각 이전하면서, 동시에 그 시스템이 30배 증가한 AI 워크로드를 처리해야 하는 상황은 어떤 엔지니어링 팀에게도 최악의 조합이다. GitHub가 경험한 연쇄 장애들은 아키텍처 결함이 아니라 이 구조적 상황의 산물이다.
셋째, 플랫폼 신뢰성은 경쟁 우위 그 자체다. HashiCorp 공동창업자 Mitchell Hashimoto가 18년 만에 GitHub를 떠나겠다고 선언한 이유는 이념이 아니라 "하루에 몇 시간씩 막힌다"는 실용적 이유였다. 개발 인프라 회사를 세우고, Vagrant와 Terraform을 만든 사람이 "진지한 작업을 하기엔 적합하지 않다"고 말했을 때, 그것은 단순한 개인 불만이 아니라 시장 신호다.
GitHub는 이제 단순한 코드 저장소가 아니다. Microsoft가 AI 보조 개발의 컨트롤 플레인으로 삼으려는 플랫폼이다. 장애가 곧 Copilot 문제이고, Azure 문제이고, Microsoft 개발자 전략 전체의 문제가 된다는 뜻이다.
개발 외주나 플랫폼 선택을 검토 중이라면
이번 사태는 외주 개발이나 자체 서비스 플랫폼 선택을 고민하는 팀에게도 시사점을 준다.
안정성 보장을 공급업체에만 맡기지 마라. 아무리 큰 벤더도 트래픽 급증 앞에서 SLA를 100% 지키기 어렵다. 중요한 배포 파이프라인에는 단일 플랫폼 의존 대신 페일오버 경로를 미리 설계하는 것이 합리적이다.
AI 에이전트 도입 시 인프라 비용을 재산정하라. GitHub 사례처럼, AI가 생성하는 자동화된 커밋·PR·테스트 트리거는 사람 개발자와 비교할 수 없는 속도로 시스템을 두드린다. 외주 개발사나 개발 업체를 선정할 때도 AI 워크로드에 대한 인프라 설계 경험 여부를 확인할 필요가 있다.
멀티 클라우드는 선택이 아니라 리스크 관리다. Microsoft조차 AWS를 빌리는 시대다. 특정 클라우드 벤더에 전략적으로 올인하는 결정은 그 자체로 비용이다.
자주 묻는 질문
Q.Microsoft가 AWS를 쓰는 게 왜 그렇게 이상한 일인가?
Microsoft는 Azure의 소유주이자 경쟁자이기 때문이다. GitHub를 인수하며 Azure 마이그레이션을 핵심 전략으로 내세웠던 만큼, AWS를 쓴다는 사실 자체가 "Azure가 충분하지 않았다"는 공개적 인정이 된다. 기업 전략상의 체면 문제이기도 하지만, 역설적으로 운영 안정성을 체면보다 우선했다는 현실주의적 판단으로 읽힌다.
Q.에이전틱 개발이 인프라에 왜 이렇게 큰 충격을 주나?
사람이 코드를 짜는 속도와 AI 에이전트가 코드를 생성·커밋·테스트 요청을 던지는 속도는 차원이 다르다. 단순히 트래픽이 많아지는 것을 넘어, 짧은 주기로 반복적인 자동화 액션이 플랫폼의 데이터베이스, 검색 인덱스, 웹훅, CI 시스템에 동시 부하를 준다. GitHub COO가 커밋이 연간 1억 건에서 140억 건 페이스로 늘었다고 밝힌 것이 그 규모를 단적으로 보여준다.
Q.이 상황이 GitHub 경쟁자들에게 기회가 되는가?
장기적으로는 그럴 수 있다. Cursor나 Claude Code 같은 AI 개발 도구들이 성장하는 상황에서, GitHub의 반복적인 장애는 "대안을 찾아볼 이유"를 개발자에게 준다. 다만 GitHub의 네트워크 효과, 오픈소스 생태계 집적도, Copilot 통합은 단기간에 대체하기 어렵다. 경쟁자들이 GitHub를 완전히 이기지 않더라도, 신뢰성 문제가 반복되면 특정 워크플로우를 가져가는 것만으로도 유의미한 시장 변화가 생길 수 있다. 📌 원문: [RuntimeWire](https://runtimewire.com/article/microsoft-github-aws-ai-capacity-crunch) 🔗 새로운 기술 도입이나 기술 검토가 필요하다면 → [삼태연구소에 문의하기](/contact)
관련 아티클
관련 사례
이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.
