내 PR이 안 머지되는 게 내 코드 탓이 아니었다 — GitHub→AWS 우회 사건이 알려주는 3가지 응급 조치
핵심 요약 (TL;DR)
Microsoft가 GitHub 트래픽 일부를 경쟁사 AWS로 응급 우회 중입니다. 원인은 AI 코딩 에이전트(Claude Code·Copilot·Cursor·Codex) 폭주. GitHub COO Kyle Daigle은 주당 2.75억 커밋(2025년 10억 → 2026년 페이스 140억, 14배), 6월 가용성 88.4%까지 떨어진다고 인정했습니다. 5월에만 9건의 서비스 저하가 있었고, 바이브코더가 당장 해야 할 일은 재시도 로직 강화, 푸시 시간대 분산, 백업 호스팅 준비입니다.
"내 클라우드론 GitHub를 못 돌리겠다"는 자인
Microsoft가 자기 클라우드인 Azure로 GitHub를 굴리지 못해서 AWS에 도움을 청했습니다. 표면적으로는 "오버플로우 캐파"라고 표현했지만, 본질적으로는 자기 인프라가 자기 도구의 성공에 깔린 거죠. GitHub COO Kyle Daigle이 4월에 발표한 숫자를 보면 이해가 갑니다. 주당 2.75억 커밋, 2025년 한 해 10억 커밋에서 2026년에는 140억 페이스로 14배 폭증입니다.
이 폭증의 정체는 사람이 아닙니다. Claude Code 헤드리스 모드가 자정에 PR을 쏟아내고, Cursor agent가 새벽에 리뷰를 반복하고, Codex가 자동으로 브랜치를 따고, Devin Desktop이 자기 PR을 자기가 닫습니다. 24시간 봇 트래픽이 인적 트래픽을 가정한 인프라 SLA를 무너뜨린 거죠.
5월 한 달에만 GitHub에서 9건의 서비스 저하가 있었고, 6월 가용성은 88.4%까지 떨어졌습니다. 엔터프라이즈 SLA 99.9% 기준이라는 걸 생각하면 11%포인트 부족한 상태가 한 달 가까이 이어진 셈입니다. Daigle은 "9월에 개선 예정"이라고 발표했지만, 그때까지 손 놓고 있으면 안 됩니다.
"내 PR이 머지가 안 되네"가 내 코드 탓이 아닐 수 있다
이 사실이 가장 먼저 충격을 주는 지점은 멘탈 모델입니다. 우리는 PR이 안 머지되거나 CI가 늦게 돌면 으레 "내 코드에 뭔가 문제가 있나" 의심합니다. 하지만 6월에 GitHub가 88.4%였다는 건, 정상 시간의 10분의 1은 그냥 시스템이 못 돈 시간이라는 뜻이죠. 푸시가 누락되거나, Actions가 큐에 끼거나, Webhook이 안 도는 게 흔히 있을 수 있다는 거예요.
여기서 진짜 무서운 건 "Azure 캐파가 한계"라는 부분입니다. Microsoft가 클라우드 1위·2위 자리를 두고 AWS와 싸우는데, 자기 핵심 자산인 GitHub를 자기 클라우드로 못 굴린다는 건 시장에 던지는 메시지가 큽니다. AI 인프라 군비 경쟁이 우리가 생각하던 것보다 훨씬 빡빡하다는 거죠.
오늘 아침 CI 보면서 해야 할 3가지
첫째, 재시도 로직과 exponential backoff를 강화하세요. GitHub API 호출, Webhook 핸들러, Actions 워크플로우 안의 어떤 단계든 단발성 실패를 그대로 받아들이지 마세요. 최소 3회 재시도, 30초→1분→2분 백오프가 표준입니다. CI 스텝마다 재시도 가능한 단계는 명시적으로 재시도하게 만드세요.
- name: Run tests with retry
uses: nick-fields/retry@v3
with:
timeout_minutes: 10
max_attempts: 3
retry_wait_seconds: 30
command: npm test
둘째, 푸시 시간대를 옮기세요. KST 새벽 시간대(밤 22시~새벽 6시)는 미국 동부 아침 출근 시간대입니다. 봇 트래픽도 사람 트래픽도 같이 최고조죠. 가능하면 KST 점심~저녁(미국 새벽)으로 자동 푸시 스케줄을 옮기는 게 가용성을 몇 %포인트는 올려줍니다. 자정에 일괄 PR을 내는 봇 워크플로우가 있다면 새벽 3시 KST로 미루세요.
셋째, 백업 호스팅을 미리 준비하세요. self-hosted GitLab이나 Forgejo, 또는 단순 git remote 미러를 하나 더 두는 일입니다. 매일 동기화하는 cron 하나면 됩니다. 사고가 났을 때 5분 안에 클론 받아서 작업을 이어갈 수 있게요. 실제로 작업할 일은 거의 없겠지만, 보험은 안 들었을 때만 비싸 보이는 법이죠.
# 매일 새벽 4시 KST에 미러 푸시
0 4 * * * cd /repo && git push --mirror gitea-backup
FAQ
Q. Daigle이 "9월에 개선"이라고 했는데 그때까지 기다려도 되나요?
A. 위험합니다. 9월까지 3개월간 가용성이 다시 회복될 거라는 보장이 없고, 그 기간에 새 AI 도구들이 더 쏟아질 가능성이 높습니다. 위 3가지 응급 조치는 9월 이후에도 유지하는 게 안전합니다.
Q. Forgejo나 GitLab 셀프호스팅이 실제로 필요할 만한 일인가요?
A. 핵심 비즈니스 코드라면 필요합니다. 사이드 프로젝트면 git remote 미러 하나로 충분합니다. 비용은 둘 다 거의 0이고, 사고가 나면 그제야 후회해도 늦으니까요.
Q. AI 에이전트 PR이 정말 폭증의 주범인가요?
A. GitHub COO가 공식적으로 인정한 부분이고, 2025년 9월 400만 → 2026년 3월 1,700만/월이라는 4배 증가 곡선이 사람 손으로는 설명이 안 됩니다. AI 에이전트의 24시간 자동 PR이 핵심 요인입니다.
인프라가 너무 잘 돼서 자기 부산물에 깔리는 시기가 있습니다. 지금이 그 시기죠. 우리는 도구가 멈출 때를 대비해 도구 위에 한 겹을 더 깔아야 합니다. 그게 바이브코더가 자기 워크플로우를 지키는 방법입니다.
댓글 0
아직 댓글이 없습니다