
AI가 GitHub를 망가뜨릴 뻔한 이야기——커밋 14배, Microsoft가 AWS에 의존한 이유
요약
AI 에이전트의 확산으로 GitHub의 커밋 수가 14배 급증하며 인프라 부하가 폭발하고 있습니다. Microsoft는 Azure의 용량 부족을 해결하기 위해 경쟁사인 AWS의 컴퓨팅 자원을 활용하는 이례적인 결정을 내렸으며, 이는 막대한 설비 투자(CapEx)에도 불구하고 AI 수요를 따라잡기 힘든 현실을 보여줍니다.
핵심 포인트
- AI 에이전트 도입으로 GitHub 커밋 수 약 14배, Actions 실행 시간 4.2배 증가
- Microsoft, Azure 용량 한계로 인해 경쟁사 AWS로부터 컴퓨팅 자원 확보
- AI 수요 폭발로 인한 빅테크 기업들의 천문학적인 설비 투자(CapEx) 경쟁
- 코드 생성 비용은 낮아졌으나, 생성된 코드의 검증 비용은 급격히 상승하는 구조적 역전 발생
조용히 진행되던 인프라의 지각 변동
2026년에 들어서며 AI 지원 코딩 툴이 일반 엔지니어들의 손에 널리 보급되었다. GitHub Copilot, Cursor, Claude Code——이러한 도구들을 사용해 본 사람이라면 "쓰는 것이 무척 빨라졌다"는 감각을 가지고 있을 것이다.
하지만 그 이면에서, 인프라는 조용히 비명을 지르고 있었다.
GitHub를 뒤흔든 「에이전트형 개발」의 충격
GitHub의 COO, Kyle Daigle 씨가 공개한 데이터는 충격적이었다.
연간 커밋 수: 약 10억 건 → 약 140억 건 (전망) = 약 14배 -
GitHub Actions 실행 시간: 주 5억 분 (2023년 실적) → 주 21억 분 = 약 4.2배
이것은 단순한 "사용자 증가"가 아니다. GitHub Copilot, Claude Code, Cursor와 같은 AI 에이전트가 인간을 대신하여 밀리초(ms) 단위로 코드 생성·브랜치 생성·테스트 실행·Pull Request 처리를 자동 루프 (Automatic Loop) 시킨 결과다.
"쓰는 사람이 늘어난" 것이 아니라, "한 명의 엔지니어가 동시에 수십 개의 에이전트를 실행하는" 시대가 된 것이다. 트랜잭션 부하가 늘어나는 방식이 인구 증가 곡선과는 전혀 다른 이유가 바로 이것이다. 2026년에 들어서 GitHub에서 대규모 장애가 다발하는 것도 우연이 아니다.
Microsoft가 AWS를 사용한다는 기묘한 구도
여기서 한 가지 기묘한 사실이 떠오른다.
Microsoft는 GitHub의 모회사다. 그리고 Microsoft에는 자사 클라우드인 Azure가 있다. 일반적인 상식이라면 "GitHub의 인프라 증강 = Azure를 사용"하는 흐름이 되어야 한다.
그런데 실제로는, Azure 자체가 자사의 AI 워크로드만으로 용량 한계(Capacity Crunch)에 직면해 있었다. Microsoft는 원래 GitHub의 인프라를 Azure로 완전히 집약하려는 방침이었으나, 그 Azure가 이미 가득 차 있었던 것이다.
이 위기를 회피하기 위해, Microsoft는 최대의 경쟁자인 Amazon Web Services (AWS)로부터 일시적인 컴퓨팅 능력(Compute Capacity)을 제공받는 이례적인 선택을 했다 (WindowsForum, TechRadar, 2026-06-16).
Microsoft는 2026 회계연도에 과거 최대 규모인 **1,900억 달러 규모의 설비 투자 (CapEx)**를 내걸고 있다. Amazon도 미주리주에 수천억 엔 규모의 데이터 센터를 신설한다고 발표했다. 이 정도의 금액을 쏟아부어도 물리적인 건설 속도는 AI 수요의 폭발을 따라잡지 못하고 있다. "경쟁사와 손을 잡는다"는 선택지가 비즈니스상의 현실적인 답이 된 것이다.
Meta CTO가 토로한 「내부의 참상」
급격한 기술 시프트는 외부 인프라뿐만 아니라 조직 내부에도 균열을 일으키고 있다.
Meta의 CTO, Andrew Bosworth 씨는 사내 AI 연구·인프라 조직의 재편에 대해 다음과 같이 고백했다.
"Atrocious" (지독하게 엉망이었다)
자원 배분과 내부 통제의 어려움을 자사의 최고 기술 책임자가 공개적인 자리에서 이 단어로 표현한 것은 업계 내에서 널리 주목받았다. 기술의 진화 속도가 조직과 의사결정의 속도를 앞질러 버렸을 때 어떤 일이 일어나는지——Meta의 사례는 그 축소판이다.
「쓰는 것은 싸고, 확인하는 것은 비싸다」——비용 구조의 역전
이 상황을 한마디로 나타내는 영어 문구가 엔지니어 커뮤니티에서 유통되고 있다.
"Reviews have become expensive, rewrites have become cheap."
AI에 의한 코드 생성의 용이함은, 사람이 다 검증할 수 없는 방대한 비효율적 코드를 만들어내어 리포지토리와 자동 검증 시스템을 가득 채운다. 결과적으로 일어나고 있는 것은 구조적 역전이다.
코드를 쓰는 비용 → AI에 의해 극도로 저렴해짐 -
리뷰·검증에 소요되는 비용 → 급격히 상승
구체적인 연쇄 반응은 다음과 같다.
- AI 에이전트가 대량의 코드를 생성한다
- 그 코드를 리뷰하는 인간의 시간·주의력은 변하지 않는다 (오히려 피로해진다)
- CI/CD 파이프라인에 흐르는 PR 수·커밋 수가 늘어나고, Actions의 실행 비용이 폭증한다
- 품질 보증을 위한 테스트 실행 시간도 증가하여, 인프라에 가해지는 부하가 치솟는다
「生成 AI는 코드를 작성하고, 그 검증 비용을 인간과 인프라가 부담한다」—이 구조를 이해하지 못한 채 에이전트를 방치하면 빨라지기는커녕 오히려 막히게 된다.
엔지니어에게 주는 실무적 시사점
이번 이야기는 단순히 대기업의 인프라 문제가 아니다. 당신의 팀과도 직접적인 관련이 있다.
커밋/PR 단위 재검토
AI가 방대한 양의 코드를 생성할 때, 하나의 커밋에 너무 많이 담으면 CI(지속적 통합)가 막히고 리뷰어들이 지치게 된다. 'AI에게 작성시킨 후, 작게 나누어 커밋하는' 습관이 팀의 CI 부하를 줄이는 한 방법이다.
테스트 및 CI 비용 의식적인 관리
GitHub Actions의 무료 사용량은 AI 코딩이 당연해지는 시대에는 금방 소진될 것이다. 테스트 캐싱 전략, 불필요한 트리거 제거, 테스트 병렬화 등과 같은 최적화는 '있으면 좋은 것'에서 '필수'가 되어가고 있다.
리뷰 프로세스 재설계
'AI가 작성한 코드는 인간이 검토한다'는 전제가 무너지고 있다. AI를 활용한 코드 리뷰 지원(PR Summary나 Copilot Code Review 등)을 결합하여, 리뷰 비용 상승을 흡수할 수 있는 설계가 요구된다.
요약
AI가 코드를 작성하는 속도는 인프라와 프로세스의 설계 속도를 앞질렀다.
- GitHub의 커밋 14배 증가, Actions 실행 시간 4.2배 증가 (Kyle Daigle COO 발표) - Azure가 캐파시티 크런치(capacity crunch)에 직면하면서 Microsoft가 AWS에 의존하는 이례적인 구도
- Meta CTO가 '끔찍하다(Atrocious)'고 고백한 조직 내부 혼란
- "리뷰는 비싸졌지만, 재작성은 싸졌다."라는 비용 구조의 역전
'생성 AI가 가져오는 것은 효율화만이 아니다'—이 현실을 바탕으로 툴 선정, CI 설계, 리뷰 프로세스를 재구성하는 것이 앞으로의 엔지니어 팀에게 요구되는 조정(adjust)이다.
인프라의 지각 변동은 이미 시작되었다.
참고
토론

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기