AI 에이전트가 깃허브를 부수고 있다: 주당 커밋 2억7500만건

깃허브 커밋 수가 주당 2억7500만건을 넘어섰다. 이 추세라면 2026년 연간 커밋은 140억건, 전년 대비 14배다. 원인으로 지목된 건 AI 코딩 에이전트다. 트래픽 급증은 이미 서비스 중단 사태로 이어졌다.

커밋이 '완성'이 아니라 '시도'가 됐다

Cursor, GitHub Copilot 같은 AI 코딩 에이전트는 코드를 짜는 속도만 높인 게 아니다. 커밋을 쌓는 단위 자체를 바꿨다. 인간 개발자에게 커밋은 '어느 정도 완성된 코드를 저장하는 행위'다. AI 에이전트에게 커밋은 '한 번의 시도'다. 수정, 재시도, 롤백이 모두 커밋으로 기록된다.

2025년 깃허브 연간 커밋은 처음으로 10억건을 돌파했다. 그런데 지금 속도는 주당 2억7500만건이다. 1년 52주로 환산하면 140억건이 넘는다. 깃허브 인프라는 인간 개발자 기준으로 설계됐다. AI 에이전트가 만들어내는 트래픽 규모는 그 설계 전제를 이미 넘어섰다.

장애를 겪었다면 이게 원인일 수 있다

AI 코딩 도구를 쓰다가 깃허브가 느려지거나 푸시가 막힌 경험이 있다면, 개인 네트워크 문제가 아닐 가능성이 있다. 깃허브는 이미 에이전트 접속 폭증으로 인한 트래픽 급증과 서비스 중단 사태를 겪었다.

빌더 입장에서 이 수치가 중요한 이유는 두 가지다.

• 워크플로우 신뢰성: AI 에이전트 기반 개발에서 깃허브 장애는 단순 불편이 아니라 자동화 파이프라인 전체의 중단이다. CI/CD, 자동 배포, 에이전트 루프가 모두 깃허브에 물려 있을 때 한 번의 장애가 미치는 범위는 인간 개발자 시절과 다르다.
• 인프라 병목 인식: 14배 성장이 예고된 트래픽 앞에서 깃허브가 어떤 대응을 하느냐는 AI 에이전트 도구의 실용성과 직결된다. 도구가 좋아도 인프라가 버티지 못하면 빌더의 생산성이 꺾인다.