GitHub가 AI 용량 부족을 겪자 Microsoft가 AWS의 역량을 활용합니다

Business Insider는 화요일에 두 관계자에 인용하여, Satya Nadella의 Microsoft가 코딩 활동의 AI 주도적 급증으로 인해 플랫폼이 부담을 겪으면서 GitHub를 운영하기 위해 Amazon Web Services (AWS)의 용량을 추가하고 있다고 보도했습니다.

이러한 상황은 Microsoft가 2018년에 판매했던 깔끔한 GitHub 인수 스토리와는 거리가 있습니다. 즉, 개발자 플랫폼을 인수하여 인프라를 Azure로 통합하고 Microsoft의 클라우드를 전 세계 소프트웨어 작업의 기본 기반으로 만드는 것이었습니다. 대신, GitHub의 부하 곡선이 마이그레이션 계획보다 더 빠르게 움직였습니다. Business Insider에 따르면, Microsoft는 원래 2027년까지 GitHub 전체를 Azure로 이전할 계획이었으나, 현재 플랫폼이 서비스 중단과 높은 사용량 문제에 직면하면서 AWS로부터 추가 용량을 확보하고 있습니다.

Microsoft는 특정 이름으로 AWS를 확인하지 않으면서 광범위한 멀티 클라우드 전환을 확인했습니다. 한 대변인은 Business Insider에

이러한 압박은 GitHub 자체의 수치에서도 명확히 드러납니다. Business Insider에 따르면, GitHub의 최고 운영 책임자(COO)인 Kyle Daigle(@kdaigle)는 지난 4월, 커밋(commits) 수가 2025년 10억 건에서 2026년 140억 건에 도달할 속도로 증가하고 있다고 밝혔습니다. 커밋이 곧 매출은 아니며 유용한 소프트웨어 산출물을 측정하는 완벽한 척도도 아니지만, 코드를 저장하고, 체크(checks)를 실행하며, 풀 리퀘스트(pull requests)를 처리하고, 검색 인덱스(search indexes)를 업데이트하며, 자동화(automations)를 트리거하고, 협업자에게 알림을 보내야 하는 플랫폼 입장에서는 직접적인 스트레스 신호입니다.

GitHub의 공식 신뢰성(reliability) 게시물들은 이것이 일반적인 성장 주기(growth cycle)가 아님을 분명히 하고 있습니다. 4월 가용성 업데이트에서 GitHub의 CTO인 Vlad Fedorov는 GitHub가 2025년 10월부터 용량을 10배(10X) 늘리는 계획을 실행하기 시작했으며, 이후 2026년 2월에는 30배(30X) 규모에 맞춰 설계해야 한다는 결론을 내렸다고 작성했습니다. GitHub 합류 전 UserClouds를 공동 창업한 전 Meta 엔지니어링 리더인 Fedorov는 이러한 변화를 2025년 12월 하반기에 급격히 가속화된 에이전틱 개발 워크플로(agentic development workflows)와 연관 지었습니다.

GitHub의 5월 가용성 보고서에 따르면, 회사는 이미 상당한 양의 트래픽을 Azure로 이동시키고 있습니다. 모놀리스(monolith) 트래픽의 40%가 Azure에서 서비스되고 있으며, 이는 2월의 8%에서 증가한 수치입니다. Git 트래픽은 30%, 리포지토리 복제(repository replication)는 99%에 달합니다. 또한 GitHub는 4개월 만에 유효 용량(effective capacity)을 두 배 이상 늘렸다고 밝혔습니다. 같은 보고서에서는 GitHub 서비스를 저하시킨 5월의 9가지 장애(incidents)를 공개했는데, 여기에는 사용량이 많은 데이터베이스 테이블의 스키마 마이그레이션(schema migration)으로 인해 발생하여 풀 리퀘스트(pull requests), 이슈(issues), 액션(actions), 웹훅(webhooks) 및 Git 작업으로 연쇄적인 영향을 미친 5월 4일의 중단 사례가 포함되었습니다.

이것이 AWS를 결정하게 된 배경입니다. 문제는 단순히 원시 컴퓨팅(raw compute)만이 아닙니다. AI 코딩 도구들이 기존의 공유 시스템에 가해지는 기계 생성 작업(machine-generated work)의 양을 늘리는 동안, GitHub는 성숙한 협업 플랫폼을 마이그레이션(migrate), 샤딩(shard) 및 강화(harden)하려고 시도하고 있습니다. 플랫폼은 재구축되는 동시에 하부의 사용 패턴이 변화하는 과정에서 더 높은 신뢰성을 갖출 것을 요구받고 있습니다.

신뢰성이 제품의 위협이 되다

GitHub에 가장 치명적인 장애는 단순히 다운타임(downtime) 이벤트만이 아닙니다. 그것은 GitHub가 판매하는 워크플로(workflow), 즉 풀 리퀘스트(pull requests) 검토, 코드 병합(merging), Actions 실행, 이슈(issues) 검색, 인시던트(incidents) 해결 및 릴리스(releases) 푸시를 방해합니다. 이러한 워크플로가 정체될 때, 개발자들은 클라우드 용량 문제를 경험하는 것이 아니라, GitHub를 방해 요소(blocker)로 경험하게 됩니다.

HashiCorp의 공동 창립자이자 Ghostty 터미널 에뮬레이터의 제작자인 Mitchell Hashimoto는 지난 4월 이러한 반발을 대중적으로 보여주는 사례가 되었습니다. The Register의 보도에 따르면, Hashimoto는 18년 동안 해당 플랫폼을 사용해 온 후 Ghostty를 GitHub에서 옮기겠다고 말했습니다. 그의 불만은 이념적인 것이 아니라 운영적인 것이었습니다. GitHub가 하루에 몇 시간씩 접속을 차단한다면, 그곳은 "더 이상 진지한 작업을 위한 장소가 아니다"라는 것이었습니다.

이러한 종류의 이탈은 Hashimoto가 GitHub가 단순한 비판가로 치부할 수 없는 바로 그 사용자이기 때문에 중요합니다. 그는 개발자 인프라 기업들을 세웠고, Vagrant 및 Terraform과 같은 도구 제작을 도왔으며, 그들의 프로젝트가 다른 모든 이들의 습관을 형성하는 고신호(high-signal) 오픈 소스 메인테이너(maintainers) 계층을 대표합니다. 만약 이러한 사용자들이 GitHub의 신뢰성을 일종의 세금처럼 취급하기 시작한다면, 경쟁사들이 GitHub의 네트워크를 정면으로 이길 필요는 없습니다. 그저 GitHub가 매끄럽게 유지하지 못하는 워크플로에 대해 신뢰할 수 있는 수준이 되기만 하면 됩니다.

Business Insider는 GitHub가 Cursor 및 Anthropic의 Claude Code와 같은 AI 도구들로부터 더 많은 경쟁에 직면해 있으며, 작년 말 Microsoft 내부 회의에서 이러한 제품들과 경쟁하기 위해 GitHub를 전면 개편하는 방안이 논의되었다고 보도했습니다. 이러한 경쟁 압력은 장애(outages)의 의미를 변화시킵니다. GitHub는 더 이상 개발자들이 코드를 저장하고 검토하는 장소에 그치지 않습니다. 그것은 AI 지원 소프트웨어 개발을 위한 Microsoft의 컨트롤 플레인(control plane)이 되어야 합니다. 그러한 맥락에서 플랫폼 장애는 Copilot 문제이자, Azure 문제이며, 동시에 Microsoft의 개발자 전략 문제이기도 합니다.

Azure의 제약은 Microsoft의 제약입니다

Microsoft는 GitHub의 AWS 우회 경로가 불필요해 보일 정도로 거대한 규모의 지출을 하고 있습니다. 하지만 그렇지 않습니다. Microsoft의 2026 회계연도 3분기 실적 발표 컨퍼런스 콜에서 CFO Amy Hood는 부품 가격 상승과 관련된 약 250억 달러를 포함하여, 2026년 달력 연도 기준 자본 지출(Capital Expenditures)로 약 1,900억 달러를 투자할 것으로 예상한다고 밝혔습니다. Hood는 또한 GPU, CPU 및 스토리지 용량을 더 빠르게 확보하기 위해 노력하고 있음에도 불구하고, 적어도 2026년까지는 제약이 지속될 것으로 예상한다고 말했습니다.

이것이 GitHub에게 핵심적인 문장입니다. Azure 용량은 Microsoft의 특정 자산이 가져가기를 기다리는 추상적인 풀(Pool)이 아닙니다. 이는 Azure 고객, OpenAI 관련 수요, Microsoft 자체의 Copilot 제품, 보안 워크로드(Security workloads), 데이터 서비스 및 퍼스트 파티(First-party) 애플리케이션 전반에 걸쳐 할당되고 있습니다. GitHub의 문제는 GitHub가 전략적 자산인 동시에, 희소한 인프라를 두고 다투는 또 하나의 내부 청구권자라는 점입니다.

저는 Microsoft 내부에서도 동일한 제약을 목격했습니다. Microsoft for Startups 팀에서 근무할 당시, 창업자들이 AI 워크로드를 위한 용량을 확보하려 할 때마다 GPU 부족 문제에 끊임없이 부딪혔습니다. 그 경험은 GitHub의 보고가 단순한 고립된 조달상의 놀라움이라기보다, 더 광범위한 할당 문제의 증상처럼 느껴지게 합니다. 즉, Microsoft가 Azure에 전략적으로 전념하고 있더라도, AI 도입 속도가 설정하는 타임라인에 맞춰 자사 생태계가 필요로 하는 특정 인프라가 부족할 수 있다는 것입니다.

따라서 Business Insider의 소식통이 정확하다면, AWS로부터 용량을 임대하는 것은 Azure가 확장할 수 없다는 양보라기보다는, Microsoft의 내부 수요가 이제 자체 클라우드 전략의 깔끔한 경계를 넘어섰다는 인정에 가깝습니다. 회사는 여전히 2027년까지 GitHub를 Azure로 옮기기를 원할 수 있습니다. 또한 GitHub의 회복 탄력성(Resilience)을 높이기 위해 이 마이그레이션을 활용할 수도 있습니다. 하지만 시장은 목표 아키텍처가 완성될 때까지 기다려주지 않습니다.

동일한 패턴이 AI 인프라의 다른 곳에서도 나타나고 있습니다. TechCrunch의 보도에 따르면, Google은 컴퓨팅 용량(compute capacity)을 확보하기 위해 2026년 10월부터 2029년 6월까지 매월 9억 2,000만 달러를 SpaceX에 지불하기로 합의했습니다. 이 거래는 GitHub가 AWS에 의존하는 것보다 규모가 더 크고 이례적이지만, 동일한 시장 상황을 가리키고 있습니다. 즉, 세계적인 클라우드 인프라를 구축하는 기업들조차 AI 수요가 계획 주기(planning cycles)를 앞질러 버렸기 때문에 경쟁사나 인접 인프라 소유자로부터 가교 용량(bridge capacity)을 구매하고 있다는 점입니다.

Microsoft의 입장에서 GitHub의 이러한 움직임은 2차적 위험(second-order risk)을 수반합니다. GitHub가 장애로부터 복구하는 데 소비하는 매 시간은, AI 네이티브 개발자 도구들이 기존의 협업 레이어(collaboration layer)가 머신 속도로 풀 리퀘스트(pull requests), 커밋(commits), 테스트 실행(test runs) 및 리포지토리 활동(repo activity)을 생성하는 에이전트 시스템(agentic systems)이 아닌, 인간의 속도에 맞춘 소프트웨어 팀을 위해 구축되었다고 주장할 수 있는 시간이 됩니다. GitHub는 네트워크, 엔터프라이즈 점유율(enterprise footprint), 그리고 Microsoft의 배포력을 보유하고 있습니다. AWS의 용량은 그 지위를 유지하는 데 필요한 시간을 벌어다 줄 수 있습니다.

하지만 이는 또한 전략적 현실을 명확하게 보여줍니다. AI 코딩 시장에서 병목 현상(bottleneck)은 단순히 모델의 품질이나 개발자의 선호도에만 있는 것이 아닙니다. 그것은 워크플로우(workflow) 아래에 있는 플랫폼이, 자신이 해방시킨 에이전트(agents)들을 흡수할 수 있는지 여부에 달려 있습니다.