目錄
GitHub가 무시하기 어려운 수치를 공개했습니다. 플랫폼이 한 달 동안 처리하는 Commit 수가 올해 4월 14억 건에서 현재 29억 건으로 늘어 불과 4개월 만에 두 배를 넘어섰습니다. 이 수치는 단순 성장 보고서가 아니라 장애 사후 분석에서 공개됐습니다. 8월 17일 GitHub는 7시간 47분 동안 전 세계적인 서비스 장애를 겪었고, github.com, Authentication, GitHub Actions, API, Pull Requests, Issues와 Copilot까지 영향을 받았습니다. GitHub가 공개한 결론은 비교적 명확합니다. 트래픽이 새로운 최고점을 기록했지만 미국 중부 데이터센터의 핵심 인프라 구성요소 하나가 수요에 맞춰 확장되지 못했고, 이후 용량 압력이 다른 서비스로 연쇄적으로 퍼졌습니다.
29억이라는 숫자만 보면 「AI Agent가 GitHub를 과부하시켰다」고 바로 해석하기 쉽습니다. 하지만 현재 공개된 자료만으로는 그렇게 결론 내릴 수 없습니다. GitHub는 29억 건의 Commit 가운데 사람이 직접 만든 것이 얼마나 되는지, Copilot·Claude Code·Codex 또는 다른 Agent가 생성한 것이 얼마나 되는지 공개하지 않았습니다. 4월 이후 추가된 15억 건이 전부 AI 때문이라고 밝힌 적도 없습니다. 다만 GitHub는 올해 4월부터 급격한 트래픽 증가와 agentic development workflows를 함께 언급해 왔습니다. 5월 Reliability Update에서도 GitHub 트래픽이 빠르게 증가하고 있으며, 상당 부분이 AI-assisted 및 agentic development workflows에 의해 촉진되고 있다고 직접 설명했습니다. 따라서 이번 Commit 급증을 Agent 확산이라는 큰 흐름 속에서 보는 것은 합리적이지만, 상관관계를 단일 원인으로 바꿔 쓰면 안 됩니다.
매일 GitHub를 사용하는 개발자에게 이번 사고에서 더 중요한 부분도 여기에 있습니다. AI Coding이 만드는 변화가 이제 IDE나 Pull Request 안에만 머무르지 않습니다. Repository, API, Actions, Authentication, Code Review와 주변 서비스 모두 더 많은 기계 생성 작업을 처리해야 합니다. 이것이 8월 17일 GitHub 대규모 장애를 AI 탓으로 돌릴 수 있다는 뜻은 아닙니다. 다만 GitHub 스스로도 몇 달 전과는 전혀 다른 규모의 트래픽을 전제로 인프라를 다시 설계하고 있다는 사실은 확인할 수 있습니다.
GitHub 월간 Commit이 14억에서 29억으로 늘었다는 것은 무엇을 의미할까?
Commit 수가 두 배가 됐다는 것은 플랫폼 활동량 증가이지, 유효한 코드 생산량이 두 배가 됐다는 뜻은 아니다
GitHub가 8월 공개한 수치는 월간 Commit이 14억 건에서 29억 건으로 증가했다는 것입니다. 같은 자료에서 월간 merged pull requests는 약 1억 3천만 건, 신규 Repository는 약 2,400만 개에 이르렀고, 전체 플랫폼 활동량은 2025년에서 2026년 사이 뚜렷하게 가속했습니다.
하지만 Commit은 그 자체로 소프트웨어 생산량이 아닙니다. 한 개발자가 3일 동안 기능 하나를 완성한 뒤 Commit 한 번을 할 수도 있고, 같은 변경 사항을 10개의 Commit으로 나눌 수도 있습니다. Agent는 수정, 테스트, 실패 결과 확인, 재수정이라는 반복 과정에서 더 많은 중간 Commit을 남길 가능성도 있습니다. 따라서 29억이라는 숫자는 「전 세계 소프트웨어 생산성이 두 배로 늘었다」기보다 GitHub가 처리해야 하는 Repository Activity가 얼마나 늘었는지를 보여 주는 수치로 보는 편이 정확합니다.
GitHub도 현재 human-authored commits와 agent-authored commits의 전체 비율을 공개하지 않았습니다. 확인할 수 있는 것은 회사가 이미 4월부터 2025년 12월 후반 이후 Agentic Development Workflows가 뚜렷하게 가속됐고 Repository Creation, Pull Request Activity, API Usage, Automation과 Large-repository Workloads가 빠르게 증가했다고 설명해 왔다는 점입니다. 2025년 10월 처음 계획했던 10배 규모의 Capacity Expansion도 2026년 2월에는 미래 30배 규모를 기준으로 다시 설계하는 단계로 바뀌었습니다.
따라서 이번에 남겨야 할 핵심 문장은 「AI가 29억 개의 Commit을 만들었다」가 아닙니다. GitHub가 현재 매월 실제로 29억 건의 Commit을 처리하고 있고, GitHub 스스로 Agentic Development를 현재 트래픽 급증의 주요 원인 중 하나로 보고 있다는 점입니다.
GitHub도 성장 자체를 장애의 변명으로 사용하지 않았다
GitHub는 사고 설명에서 이런 성장세가 시스템이 받는 압력을 설명할 수는 있어도 장애를 정당화할 수는 없다는 취지의 문장을 명확하게 남겼습니다.
이 구분이 중요합니다. 29억 Commit은 수요 측에서 발생한 변화입니다. 하지만 수요가 용량을 넘어가기 전에 핵심 인프라를 충분히 확장하지 못한 것은 플랫폼 운영 측에서 해결해야 할 Reliability 문제입니다.
그래서 GitHub도 사고 보고서를 「AI 트래픽이 너무 많아서 어쩔 수 없었다」는 식으로 작성하지 않았습니다. 오히려 회사가 수요가 용량을 초과하기 전에 핵심 구성요소를 확장하지 못했다고 인정하고, 앞으로 Capacity를 늘리고 아키텍처 병목을 제거하며 Observability를 개선하고 Service-to-service Retry 동작까지 다시 설계하겠다고 설명했습니다.
GitHub는 왜 8월 17일 7시간 47분 동안 장애를 겪었을까?
당일 배포가 문제였던 것은 아니지만 Configuration 문제가 전혀 없었다고 쓰면 안 된다
GitHub의 고수준 결론은 Capacity Failure였습니다. 또한 8월 6일과 8월 17일 두 차례의 주요 사고 모두 당일 Code Change 또는 Configuration Change가 직접 Trigger가 된 것은 아니라고 밝혔습니다.
하지만 Technical Root Cause Analysis를 자세히 보면 더 복잡한 상황이 드러납니다. 새로운 Peak Traffic이 먼저 Central US의 Load Balancer에서 Network Saturation을 일으켰고, Istio Sidecar Pod 하나가 Concurrency Limit에 도달했습니다. 문제는 기존 Autoscaling Policy가 Host Service만 관찰하고 Sidecar Limit을 제대로 반영하지 않았다는 점입니다. 결과적으로 실제 병목이 발생한 Sidecar는 수요 증가에 맞춰 제대로 확장되지 않았습니다.
이후 한 서비스의 혼잡이 다른 노드로 퍼졌고, 결국 HAProxy Nodes 네 개가 Flow Limits를 모두 사용했습니다. Gateway Authentication Path에서 지연과 실패가 발생하기 시작했고, 그 영향이 Issues, Pull Requests, API, Actions, Git Operations, Copilot과 기업 인증 기능까지 확대됐습니다. 사고가 가장 심했을 때 Web과 API Error Rate는 약 20%, Archive와 Raw Content Download Error Rate는 한때 50%에 가까웠습니다.
따라서 「Configuration Change가 사고를 유발한 것은 아니다」와 「Technical RCA에 Misconfigured Policy가 등장한다」는 설명은 서로 모순되지 않습니다. 전자는 당일 새로 배포한 코드나 설정 변경 하나가 서비스를 망가뜨린 것이 아니라는 뜻입니다. 후자는 기존 Autoscaling Configuration이 Sidecar Capacity를 충분히 고려하지 못하는 결함을 가지고 있었고, 과거 트래픽 수준에서는 드러나지 않다가 8월 17일 새로운 최고 트래픽에서 처음 심각하게 노출됐다는 의미입니다.
그래서 이번 사고를 단순히 「서버 용량이 부족해서 다운됐다」고만 설명하는 것도 부족합니다. Capacity가 핵심 문제였지만 Autoscaling Policy, Load Balancer Flow Limits, Authentication Dependency와 Retry Behavior가 동시에 한계에 부딪히면서 지역 단위 부하 문제가 여러 서비스로 퍼지는 장애가 됐습니다.
Retry Storm은 왜 GitHub가 회복되기 시작한 뒤에도 Copilot 문제를 계속 키웠을까?
한 번의 실패가 거의 10배의 트래픽으로 증폭될 수 있었다
GitHub는 사고 보고서에서 매우 구체적인 수치를 공개했습니다. Central US가 회복되기 시작한 뒤 일부 트래픽을 Northern Virginia로 이동했는데, VS Code 안에 있던 이전까지 발견되지 않은 Retry Bug가 Copilot Token Operation 실패 시 빠르게 추가 Request를 발생시켰습니다.
그 결과 Copilot Token Service의 정상적인 7,000~9,000 RPS가 70,000~100,000 RPS까지 증가했습니다. 거의 10배 수준입니다.
이 사례는 「서비스가 복구되기 시작했다」고 해서 트래픽도 즉시 정상화되는 것은 아니라는 점을 보여 줍니다. 많은 Client가 동시에 오류를 받고 모두 즉시 Retry하면, Gateway와 Client, 다른 Service가 각각 별도의 재시도 로직을 가지고 있을 경우 원래 개별 Request의 성공률을 높이기 위한 설계가 사고 중에는 정상보다 훨씬 큰 추가 트래픽을 만들 수 있습니다.
GitHub는 결국 Gateway Authentication Retries를 줄였고, 일부 Copilot Token Requests에는 일시적으로 403을 반환해 Retry Loop 자체를 끊었습니다. 이후 Region별로 트래픽을 점진적으로 다시 열었습니다.
이번 Retry Storm에서 「AI는 지치지 않아서 계속 재시도한다」는 설명보다 중요한 부분은 Retry Storm 자체가 원래 AI 전용 문제가 아니라는 사실입니다. 전통적인 Client, Microservices와 자동화 시스템에서도 같은 현상이 일어날 수 있습니다.
Agent가 확산되면서 달라지는 것은 기계 작업량과 Fan-out입니다. 한 사람이 하나의 Intent를 전달했는데 뒤에서 여러 Tool Calls, API Requests, Repository Operations, Tests와 후속 수정이 발생할 수 있습니다. 여기에 Concurrency Limit, Backoff와 전체 Time Budget이 없다면 단순한 사람 중심 Workflow보다 트래픽이 훨씬 빠르게 증폭될 수 있습니다.
GitHub는 어떻게 고칠 계획일까? 서버만 더 추가하는 것이 아니라 연쇄 부하 자체를 제한한다
Autoscaling·Retry Budget·Regional Failover를 함께 수정한다
GitHub Technical RCA가 제시한 후속 작업에는 Autoscaling Policy 수정이 포함됩니다. Service Mesh Sidecar의 Concurrency와 Capacity도 실제 Scaling 결정에 반영하도록 하고, 관련 서비스들의 Istio Request·Concurrency·Scaling Limits를 전면적으로 다시 점검합니다.
Gateway와 Client의 Retry Limit 및 Backoff Behavior도 다시 검토하고, VS Code에서 Copilot Token Traffic을 증폭시킨 Retry 문제를 수정하며, Load Balancer Capacity Monitoring과 Regional Failover Safeguards도 개선할 계획입니다.
GitHub CTO의 전체 설명에는 개발팀에서도 참고할 만한 개념 하나가 추가로 등장합니다. Retry Budget입니다.
GitHub는 Service-to-service Interaction에 일관된 Retry Limits, Retry Budgets와 Variable Timeouts를 적용해 각 서비스가 자기 입장에서 계속 재시도하다가 전체 Downstream을 무너뜨리는 상황을 막을 계획입니다.
Retry Budget은 단순히 「실패하면 세 번 다시 시도한다」와 다릅니다. 예를 들어 Downstream Service가 이미 과부하 상태인데 Caller 1,000개가 각자 「몇 번 더 시도하면 성공할 수 있다」고 판단하면 전체 트래픽은 계속 증가합니다. Retry Budget은 재시도를 제한된 자원으로 취급합니다. 시스템이 대규모 실패 상태에 들어가면 일부 Request는 차라리 Fail Fast하게 두고, 하나의 작업을 살리기 위해 전체 서비스를 더 압박하지 않는 방식입니다.
GitHub는 이미 엄청난 Capacity를 추가하고 있었지만 수요가 더 빨리 증가했다
GitHub가 8월에 와서 처음 하드웨어를 늘리기 시작한 것도 아닙니다. 공식 설명에 따르면 올해 Reliability Work를 통해 300만 개가 넘는 CPU Cores, 120 PB의 High-speed Storage와 대규모 Network Capacity를 추가했고, 서비스의 Azure 이전도 계속 진행하고 있습니다.
현재 Azure는 GitHub Platform Load의 약 58%, Git Operations의 절반 정도를 처리하고 있습니다. 5월에는 Platform Load의 약 12% 수준이었던 것을 감안하면 상당히 빠른 Migration입니다.
하지만 이 수치는 Agentic Software Development가 인프라 팀에 왜 까다로운지 동시에 보여 줍니다. 수요 곡선 자체가 여전히 빠르게 변하기 때문입니다.
GitHub는 지난해 10월 10배 Capacity를 계획했지만 몇 달 뒤에는 30배 규모를 기준으로 다시 설계하기 시작했습니다. 그리고 월간 Commits는 4월에서 8월 사이 14억 건에서 29억 건으로 증가했습니다. 이런 환경에서는 현재 수치에 고정 성장률 하나를 곱하는 방식만으로 Capacity Planning을 끝내기 어렵습니다.
AI Agent 트래픽은 기존 개발 트래픽과 무엇이 다를까?
차이는 ‘AI가 잠을 자지 않는다’가 아니라 하나의 작업이 많은 기계 동작으로 펼쳐질 수 있다는 점이다
사람은 자고 AI는 자지 않는다는 식으로 두 트래픽을 구분하면 이해하기 쉽지만 실제 문제를 지나치게 단순화합니다.
GitHub Actions, CI Bot, Dependabot과 여러 자동화 서비스는 이미 오래전부터 하루 24시간 작동하고 있었습니다. GitHub가 비인간 트래픽을 처음 상대하는 것은 아닙니다.
Agent가 가져오는 더 뚜렷한 변화는 Fan-out입니다.
사용자가 「이 Bug를 고쳐 줘」라고 한 번 입력하면 Agent는 뒤에서 Repository를 읽고, Branch를 만들고, 여러 파일을 수정하고, Tests를 실행하고, Failure Logs를 확인하고, 다시 코드를 수정하고, Push하고, Pull Request를 만든 뒤 Review나 CI 결과에 따라 다시 다음 작업을 수행할 수 있습니다.
GitHub도 4월과 5월 Reliability Update에서 Repository Creation, Pull Request Activity, API Usage, Automation과 Large-repository Workloads의 빠른 증가를 Agentic Development Workflows 확산과 함께 설명했습니다.
따라서 앞으로 플랫폼이 상대해야 하는 것은 단순히 「새벽에도 누군가 Push한다」는 문제가 아닐 수 있습니다. 하나의 User Intent가 과거보다 훨씬 많은 API Calls, Git Operations, Actions Runs와 Review Activity를 만들고, 이런 행동이 동시에 발생하고 빠르게 Retry되며 수많은 Agent가 병렬로 실행될 수 있다는 점이 중요합니다.
AWS가 같은 주 GPT-5.6 Cross-Region Inference를 확대한 것도 Agent 트래픽의 다른 끝을 다루는 사례다
Amazon Bedrock은 같은 시기 GPT-5.6 Sol, Terra, Luna의 API 지원을 확대했습니다. 세 모델은 bedrock-runtime을 통해 Responses, Chat Completions와 Converse APIs를 사용할 수 있고, Global 및 Geo Cross-Region Inference도 추가돼 Request를 여러 AWS Region 사이에서 자동으로 Routing해 더 높은 Throughput을 확보할 수 있습니다.
다만 이를 「GPT-5.6이 25개가 넘는 AWS Regions에 직접 배포됐다」고 표현하면 정확하지 않습니다. 현재 Sol의 In-region Availability는 주로 US East의 N. Virginia와 Ohio에 있고, Terra와 Luna는 US West의 Oregon도 포함합니다. Cross-Region Inference는 Inference Profile을 통해 조건에 맞는 Regions 사이에서 Capacity를 조정하는 구조입니다.
AWS는 8월 18일 Terra와 Luna에 India Geo Cross-Region Inference도 추가해 데이터가 Mumbai와 Hyderabad라는 지리적 범위 안에서 처리될 수 있도록 했습니다.
AWS와 GitHub를 같은 글에서 보는 것은 같은 주에 나온 흥미로운 상·하류 사례가 될 수 있지만 두 회사 사이에 직접적인 인과관계를 만들어서는 안 됩니다.
AWS가 처리하는 것은 고수요 Model Inference Request를 여러 Region에서 Capacity에 맞게 배분하는 문제입니다. GitHub는 Repository, Actions, API와 다른 Developer Infrastructure의 수요 급증을 처리하고 있습니다.
두 사례의 공통점은 Agentic Workloads가 플랫폼에 Throughput, Burst Traffic과 Capacity Scheduling을 다시 설계하도록 요구하기 시작했다는 점입니다. AWS도 GPT-5.6을 공개하면서 Agent Traffic은 상당히 Bursty할 수 있고 하나의 User Request가 많은 Model Calls로 확대될 수 있다고 설명했습니다.
AI Coding Agent를 사용한다면 개발 Workflow에 어떤 방어 장치를 먼저 추가할 수 있을까?
로컬 Git에는 계속 실제로 작업 가능한 Repository를 유지한다
Git 자체가 Distributed Version Control이기 때문에 정상적인 Local Repository에는 Branch, Commit과 대부분의 작업 기록이 이미 저장돼 있습니다. 따라서 GitHub를 사용할 수 없어도 Local Commit, Branch 생성, Merge와 로컬 테스트는 일반적으로 계속할 수 있습니다.
GitHub Outage와 함께 막히기 쉬운 것은 Pull Request Review, Issues, GitHub Actions, Webhooks, Authentication과 GitHub API 또는 Hosted Runner에 의존하는 Deployment Workflow입니다.
따라서 별도의 Git Client를 하나 더 준비하는 것보다 더 중요한 질문은 「GitHub가 없어도 실제로 할 수 있는 작업이 얼마나 남아 있는가」입니다.
GitHub가 오후 내내 장애인데 로컬 테스트조차 실행할 수 없다면 Workflow에서 지나치게 많은 필수 단계가 Remote Service에 묶여 있을 가능성이 있습니다.
Agent의 Retry를 단순히 ‘실패하면 다시 시도’로 설정하지 않는다
자체 구축 Agent, Script 또는 Automation이 GitHub API를 호출한다면 최소한 Maximum Retry Count, Exponential Backoff, Jitter와 전체 Deadline이 있어야 합니다. 서비스가 반환하는 Rate Limit이나 Retry-After 신호도 따라야 합니다.
이번 GitHub 사고에서 Copilot Token Service의 정상 7,000~9,000 RPS가 70,000~100,000 RPS까지 증폭된 사례는 극단적이지만 분명한 경고가 됩니다. Retry는 원래 성공률을 높이기 위한 기능이지만 총량 통제가 없으면 장애를 확대하는 장치가 될 수 있습니다.
Coding Agent에는 Concurrency Limit도 추가할 수 있습니다. 같은 Repository에서 Agent를 동시에 몇 개까지 실행할지, 1분 동안 Push를 몇 번까지 허용할지, CI Failure 뒤 자동 수정은 몇 라운드까지 허용할지를 정하고 그 이상이면 사람에게 넘길 수 있습니다.
Agent가 무한히 다시 시도하도록 두는 것보다 훨씬 통제하기 쉬운 방식입니다.
GitHub 용량을 아껴 주겠다는 이유로 모든 Commit을 Squash할 필요는 없다
Agent가 만든 세분화된 Commit을 전부 Squash한 뒤 Push해야 하는 이유가 「GitHub의 Write Load를 줄이기 위해서」라면 현재 공개된 자료만으로 일반적인 Best Practice라고 보기 어렵습니다.
Commit History를 Squash할지는 Review, Bisect, Rollback과 팀의 Version Control Policy에 따라 결정해야 합니다.
더 실질적으로 조절할 부분은 Push, PR과 CI Frequency입니다.
Agent가 Local Branch에서 여러 번 수정과 테스트를 끝낸 뒤 한 번에 Batch Push하도록 할 수 있습니다. 한 줄 수정할 때마다 새로운 Remote Event, Webhook과 CI Run을 발생시킬 필요는 없습니다.
최종적으로 Main Branch History를 단순하게 유지하고 싶다면 팀 규칙에 따라 Squash Merge를 사용하면 됩니다. 이 방식은 유용한 개발 History까지 지우면서 Commit 수 자체를 억지로 줄이는 것이 아니라 자동화 Workflow의 불필요한 Churn을 줄이는 데 초점을 맞춥니다.
GitHub Status를 사고 확인 Workflow에 직접 넣을 수 있다
GitHub Status는 Issues, Pull Requests, Actions, API, Git Operations와 Copilot의 복구 상태를 지속적으로 업데이트합니다. Status Page 자체도 Email, SMS, Slack, Webhook, Atom과 RSS 구독을 제공합니다.
GitHub 의존도가 높은 팀이라면 공식 Status Feed를 기존 알림 시스템에 넣는 편이 오류가 발생할 때마다 Git을 다시 설치하거나 Router를 점검하는 데 30분을 쓰는 것보다 실용적입니다.
소규모 팀이라고 별도의 대형 Monitoring Platform까지 구축할 필요는 없습니다. GitHub, 주요 Model API, Deployment Platform과 Cloud Provider의 공식 Status를 한곳에서 빠르게 확인할 수 있도록 하는 것만으로도 불필요한 로컬 디버깅을 상당 부분 줄일 수 있습니다.
Single Point of Failure를 다시 확인할 때 Git Repository만 보지 않는다
Git Repository 자체는 Local Copy를 유지하기 쉽습니다. GitHub에서 실제로 대체하기 어려운 것은 Repository 주변의 서비스입니다.
Pull Requests, Code Review, Issues, Actions, Secrets, Branch Protection, Packages, Webhooks, Deployment Approval과 Third-party Integration이 여기에 포함됩니다.
따라서 먼저 구체적인 질문 하나를 던질 수 있습니다.
GitHub가 오전부터 저녁까지 멈추면 어떤 작업은 계속할 수 있고, 어떤 작업은 완전히 중단되는가?
특정 Repository에 매우 엄격한 Recovery Time Objective가 있다면 Secondary Remote, Mirror 또는 대체 CI 경로를 검토할 수 있습니다. 하지만 일반 개인 프로젝트라면 로컬에서 계속 작업한 뒤 GitHub가 복구되면 Push하는 것으로 충분할 수도 있습니다.
Backup이나 이중화 자체에도 유지보수 비용이 있기 때문에 모든 프로젝트를 두 개 플랫폼에서 High Availability로 운영할 필요는 없습니다.
이번 GitHub 사고가 보여 준 것은 단순히 AI가 더 많은 코드를 작성한다는 사실만이 아니다
GitHub의 월간 29억 Commits는 매우 큰 수치입니다. 하지만 AI 생산성 순위도 아니고, 전 세계 소프트웨어 생산량이 4개월 만에 두 배로 증가했다는 증거도 아닙니다.
비교적 확실하게 말할 수 있는 것은 GitHub의 플랫폼 활동량이 매우 빠르게 증가하고 있고, GitHub가 여러 차례 AI-assisted 및 Agentic Development Workflows를 이 트래픽 성장의 중요한 원인 중 하나로 언급하고 있다는 점입니다.
새로운 Peak Traffic이 Sidecar Capacity에 맞춰 제대로 확장되지 않는 Autoscaling Policy와 만났고, 여기에 Load Balancer Flow Limits, Authentication Dependency와 Retry Amplification까지 겹치면서 지역 단위 Capacity Pressure가 7시간 47분 동안 이어진 Cross-service Incident로 확대됐습니다.
매일 Coding Agent를 사용하는 개발자에게는 이 가운데 몇 개의 Commit이 AI가 만든 것인지 추측하는 것보다 다른 문제가 더 실질적입니다.
Coding이 더 저렴해지고 자동화될수록 Push, CI, Review, API, Deployment와 Retry도 함께 늘어날 수 있습니다. Agent가 얼마나 빨리 다음 버전의 코드를 작성하는지는 Workflow의 앞부분일 뿐입니다. 그 뒤에 있는 인프라가 이런 작업량을 얼마나 안정적으로 받아낼 수 있는지도 이제 개발 Workflow의 일부가 되고 있습니다.
자주 묻는 질문 FAQ
현재 자료만으로는 그렇게 결론 내릴 수 없습니다. GitHub는 월간 Commit이 4월 14억 건에서 29억 건으로 증가했다고 확인했고, 최근 트래픽 증가의 상당 부분이 AI-assisted 및 Agentic Development Workflows의 영향을 받고 있다고 공개적으로 설명한 적도 있습니다. 하지만 8월 17일 Peak Traffic 가운데 AI Agent가 차지한 비율은 공개하지 않았고, Agent가 사고의 단일 원인이라고 밝히지도 않았습니다. 직접적인 기술 원인은 Central US의 Capacity Pressure와 이후 Autoscaling, Load Balancer와 Retry 문제가 이어진 연쇄 장애였습니다.
GitHub가 말한 것은 사고가 당일 새로 배포한 Code 또는 Configuration Change 때문에 시작된 것은 아니라는 뜻입니다. 하지만 Technical RCA에서는 기존 Autoscaling Policy가 Host Service만 관찰하고 Istio Sidecar의 Concurrency Limit을 제대로 반영하지 못했다고 설명합니다. 따라서 정확한 표현은 「새로운 설정 변경이 사고를 Trigger한 것은 아니지만 기존 Autoscaling Configuration에 결함이 있었다」입니다.
아닙니다. 29억 건은 GitHub가 현재 한 달 동안 처리하는 Commit Activity를 의미합니다. 이를 유효 코드량, 소프트웨어 생산 가치나 개발자 생산성으로 바로 환산할 수는 없습니다. GitHub는 이 가운데 사람이 만든 Commit과 AI Agent가 만든 Commit의 비율도 공개하지 않았습니다.
GitHub의 플랫폼 부하를 줄인다는 이유만으로 무조건 Squash할 필요는 없습니다. Commit을 유지할지는 팀의 Review, Bisect와 History Policy에 따라 결정해야 합니다. Agent가 만드는 원격 작업량을 줄이고 싶다면 Local Branch에서 여러 번 수정한 뒤 Batch Push하고 PR, CI와 Retry의 발생 빈도를 제한하는 편이 더 실질적입니다.
일반적으로 가능합니다. Git은 분산형 버전 관리 시스템이기 때문에 Local Repository에서는 Commit, Branch 생성, Merge와 History 확인을 계속할 수 있습니다. 주로 영향을 받는 것은 GitHub Server가 필요한 Pull Requests, Issues, Actions, API, Remote Push／Pull과 다른 Hosted Services입니다.
직접적인 관계는 없습니다. AWS는 8월 17일 GPT-5.6 Sol, Terra, Luna에 Cross-Region Inference를 지원해 Model Request를 여러 Region의 Capacity로 분산하고 Throughput을 높이는 기능을 제공했습니다. GitHub는 Developer Platform 자체에서 증가하는 Repository, API, Actions와 기타 트래픽을 처리하고 있었습니다. 두 사례를 Agentic Workloads가 인프라 Capacity에 미치는 영향을 보여 주는 같은 시기의 사례로 볼 수는 있지만, AWS의 상위 모델 Capacity 증가가 GitHub 장애를 직접 일으켰다고 설명해서는 안 됩니다.