요약
GitHub에서 Actions·이슈·풀 리퀘스트가 2시간 넘게 느려지거나 오류를 냈고, 알림은 8시간 가까이 밀렸습니다.
GitHub 상태 페이지에 올라온 장애 기록입니다. GitHub은 10월 12일 12시 21분(UTC)에 성능 저하 신고를 조사하기 시작했고, 같은 날 20시 16분에 장애를 종료했습니다.
왜 중요한가
- 웹 화면뿐 아니라 REST·GraphQL API도 영향을 받아 GitHub에 연결된 자동화 작업까지 차질을 빚었습니다.
- 리뷰 요청과 CI(코드를 올릴 때 자동으로 도는 빌드·테스트)가 함께 막혀, 장애가 곧 돈 손실이라는 이용자 불만이 나왔습니다.
- HN에서는 AI 코딩 에이전트가 늘린 작업량을 GitHub이 버티지 못한다는 신호로 읽는 시각이 많았습니다.
핵심 내용
- Actions 탭 열기, Checks API, Actions 실행 대기열 등록, 이슈 작성·수정, 풀 리퀘스트 리뷰 요청이 영향을 받았습니다.
- 풀 리퀘스트는 41분 뒤인 13시 2분에 정상으로 돌아왔습니다.
- 첫 조치가 완전히 통하지 않아 Actions·이슈·Projects는 14시 37분에야 복구됐습니다.
- 웹·이메일 알림은 밀린 처리분(백로그)을 소화하느라 이후 몇 시간 더 늦게 도착했습니다.
- 근본 원인은 아직 밝히지 않았고, 상세한 원인 분석을 나중에 공유하겠다고 했습니다.
HN 반응
- 하루 5천만 건이던 작업이 20억 건으로 늘면 어떤 시스템도 버티기 어렵다는 옹호와, 그 정도는 큰 서버 한 대로 감당할 수 있다는 반론이 맞섰습니다.
- 여러 이용자는 Actions가 너무 싸거나 무료라 사용량이 몰린다며 값을 올리거나 무료 제공을 줄이자고 했고, 오픈소스의 혜택을 빼앗는다는 반발도 나왔습니다.
다들 GitHub을 두들기고 싶어 하지만, 솔직히 하루 5천만 건이던 <thing>이 20억 건으로 뛰면 지금까지 사람이 만든 어떤 시스템이라도 거의 다 무너져요. 그게 8개월에 걸쳐 일어났다 해도 여기저기서 터질 거고, 하나를 막으면 다음 도미노가 쓰러지는 식이죠.
팀이 안쓰럽긴 한데, 다들 크게 성장할 기회가 될 거예요.
이건 아마 가격 정책의 실패입니다. 과다 사용으로 시스템이 무너지는 건 가게에 갔더니 물건이 다 팔리고 없는 것과 같습니다. 값을 더 받으면 품절될 가능성은 훨씬 줄어듭니다. 그런데 GitHub은 가격을 올리기는커녕 올해 초에 오히려 내렸습니다: https://github.com/resources/insights/2026-pricing-changes-for-github-actions
게다가 2020년에 Pro 등급을 좌석당 월 7달러에서 4달러로 내린 뒤로는 가격을 건드린 적이 없습니다: https://docs.github.com/en/get-started/learning-about-github/faq-about-changes-to-githubs-plans
또 Pro 등급에 월 3,000분이 포함되고, 최소 좌석 수가 공개되어 있지도 않은 Enterprise 등급(좌석당 월 21달러)에는 월 5만 분이 포함된다는 점도 생각해야 합니다. 1인 사업자에게 월 21달러에 5만 분이면 사실상 가진 걸 다 퍼주는 겁니다.
GitHub은 적어도 Actions만큼은 가격을 대폭 올려야 합니다. 지금 가격은 사실상 WTO 덤핑 위반 수준입니다.
일리는 있습니다. 다만 AI 이후의 세계에서 가치 있는 것이 무엇인지 생각해 봐야 합니다. 소프트웨어 자체가 아니라 데이터와 네트워크 효과입니다. MS는 독점 소프트웨어로 돈을 버는 세계에서, 가둬 둔 네트워크를 만들고 데이터를 쥐는 세계로 옮겨 가야 하는데, GitHub은 그 둘을 다 줍니다.
그러니 자기들이 손해를 보면서까지 서비스를 제공하는 것도 장기적으로는 영리한 전략일 수 있습니다.
컴퓨팅, 스토리지, 전송량은 AI 이전이든 이후든 다 가치가 있다고 확신해요. 적어도 그런 것들이 GitHub에는 여전히 돈이 든다고 확신하고요.
저는 연결이 안 되네요. 가격이 장기 전망에 영향을 줄 수는 있겠지만, 이번 문제들이 계량된 자원이나 할당된 자원의 부족 때문에 생겼다는 증거는 못 봤어요. GitHub은 필요한 만큼 Azure 컴퓨팅을 쓸 수 있어야 하잖아요.
'쓸 수 있어야 한다'가 '쓸 수 있다'는 아니죠. GitHub은 Azure 컴퓨팅이 필요한 다른 모든 Microsoft 제품, 그리고 Microsoft 고객들과 경쟁하고 있습니다. 어떤 고객이 내부 정산 단가보다 높은 마진으로 컴퓨팅을 사겠다고 하면, GitHub이 그 고객을 제치고 컴퓨팅을 받는다는 보장은 전혀 없어요. 요즘은 어디서나 컴퓨팅을 두고 헝거 게임이 벌어지고 있습니다.
그럴 수는 있지만, 여기서 문제가 컴퓨팅 부족이라는 증거는 여전히 없어요. 이런 급증에는 온갖 난제가 따라오는데, 가격 모델 탓이 틀림없다고 단정하는 건 무리 같아요.
https://archive.is/q0cPI
"Microsoft turns to Amazon for help with GitHub's AI-driven capacity issues" (Microsoft, AI 때문에 불거진 GitHub 용량 문제 해결을 위해 Amazon에 도움 요청)
그쪽은 고객에게 서비스를 제공하는 것 말고 다른 목적으로도 저장소에 직접 접근하고 싶었던 거죠. 이를테면 Copilot 학습 데이터로요. 그 밖에 또 뭐가 있을지는 아무도 모르고요.
가격을 낮게 잡은 건 그 데이터에 대한 접근을 확보하는 데 도움이 됐습니다.
하루 20억 건은 평균 초당 23,148건입니다. 피크 때는 초당 10만 건이 넘을 수도 있겠죠. GitHub 규모에서 이걸 따라가는 건 정말 말도 안 되는 수치입니다. 저는 초당 10만 건 넘게 쓰는 시스템을 다뤄 봤는데, 그걸 전 세계에 분산하면서 몇 초 안에 상당한 일관성까지 유지해야 한다면 정말 힘든 과제입니다.
이 댓글을 읽다가 이 부분에 이를 때까지는 정말 흥미로웠습니다.
대체 GitHub의 워크로드 중 무엇 때문에 1초라는 짧은 구간에 일어나는 2만 3천 건이 말도 안 되는 수준처럼 느껴지는 걸까요? 제 경험상 GitHub 활동의 상당수는 이슈의 라벨을 바꾸거나 평문 댓글을 다는 일입니다.
기술적으로 말하면 초당 이 정도 건수는 대형 서버 한 대가 감당할 수 있는 범위 안쪽입니다. GitHub 퍼블릭 클라우드 전체를 기계 한 대로 돌릴 수 있다고 하면 터무니없게 들리겠지만, 최신 서버 플랫폼에서 실제로 쓸 수 있는 I/O 대역폭을 따져 보면 얼마나 터무니없을까요? 2009년 무렵의 VisaNet 전체가 메인프레임 한 대에서 돌아갔습니다. 그것도 전 세계 규모로요. 지금도 그렇게 운영하고 있을 가능성이 충분합니다.
트랜잭션 코어의 I/O를 금방 포화시킬 만한 GitHub의 거의 모든 부분은 블롭 스토리지나 CDN 같은 수평 확장 시스템으로 넘길 수 있습니다.
하루 20억이라는 게 정확히 무엇을 말하는지 찾기가 어렵지만, 모든 작업을 가리키는 건 아닙니다. 최근 GitHub은 한 달에 이벤트 4,733억 건을 처리했는데( https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/ ), 평균 초당 약 18만 3천 건입니다. 그러니 20억이라는 숫자는 훨씬 더 비싼 무언가를 가리키는 겁니다.
...진심이에요?
그냥 머릿속으로 한번 따져 보세요. GH Action 하나가 시작될 때 무슨 일이 벌어지는지, 거기에 얽힌 모든 걸요.
여기서 말하는 쓰기 I/O의 양은 GH 쪽만 따져도 어마어마합니다.
Netflix나 Hulu가 영상을 서빙하는 건 같은 일이 아니에요. 그건 읽기 위주 워크로드라서 CDN에서 아주 잘 돌아가니까요. GitHub은 쓰기 물량이 엄청납니다.
규모가 엄청난 건 맞지만, 한편으로 GitHub은 거대해도 거의 전부가 서로 격리된 데이터의 섬(저장소)으로 이루어져 있습니다. 이건 확장하기가 비교적 쉽습니다. 극단적인 예를 들면 저장소마다 전용 서버를 두고, 그 저장소의 Actions도 각자 격리된 상태로 돌리는 식이죠.
이미 (대부분) 하고 있지 않았다면 불가능하다고 했을 거예요.
불가능이라는 건 아주 강한 말입니다. 주요 클라우드 업체마다 같은 제약 아래서 초당 더 많은 요청을 처리하는 핵심 시스템이 있습니다.
확장성 문제가 플랫폼 전체에 영향을 준다면 뭔가 경제적 유인책이 있어야 해요. 시스템이 감당하지 못한다면 확장이 갖춰질 때까지 이런 에이전트들에게는 통행료 체계가 필요하고요.
분명 KPI가 있을 텐데, 그중 하나가 에이전트·AI 기반 작업의 증가율(%)이라 해도 놀랍지 않아요.
소원을 말할 때는 조심하세요. 대신 사람에게 통행료 체계가 생길 수도 있거든요.
우리도 다들 운영할 사업이 있고, 이 다운타임은 이미 우리 돈을 갉아먹고 있어요.
작년 즈음에 무료 등급과 유료 등급의 사용 비중이 재분배됐을 가능성이 커요.
훈수 두는 얘기이긴 한데, 무료 등급을 (일시적으로) 줄이면 그런 문제 상당수는 풀릴 수 있을 거예요. 무료 등급에서 Actions만 빼도 부하가 크게 줄 것 같아요. 그러면 바이브 코더 대부분은 굳이 CI/CD를 붙이지 않고 로컬 pre-commit 스크립트만 쓰거나 아예 안 쓸 테니까요. CI를 안 쓰면 혼자 하는 프로젝트에서 PR을 쓸 이유도 사라지니까 그쪽 부하도 줄지도 모르고요.
동의해요. 가정용 전기와 수도도 끊는 걸 고려해야 해요. 그 물로 데이터센터에 추가로 배정된 전력이 내는 열을 식힐 수 있을 테니까요.
비유를 좋아하는 사람으로서 말하자면 이건 형편없는 비유입니다. 영향의 크기가 너무 다릅니다. GitHub 변경은 영향을 받는 사람들에게 가볍고 금방 지나가는 불편일 뿐입니다. LLM으로 리팩터링을 시키면 간단하게 끝나니까요. 그리고 GitHub 생태계에서 가장 얌체 같은 사용자들에게 영향을 주니 표적이 분명합니다. 반면 공공 인프라는 모든 사람에게 영향을 주고, 간단한 대안이나 조정 방법도 없어서 사람들은 꼼짝없이 고통을 감수해야 합니다.
비유가 아니에요. 저는 github actions를 써요. 많은 오픈소스 프로젝트가 github actions를 쓰는 건 그게 _거기 있어서_고요. 그 대가로 github은 무료 등급 사용자들이 서비스에 익숙해지고 회사에서도 쓰라고 추천하니까 전환 효과를 얻죠.
이 체제는 LLM 이전에도 잘 돌아갔고 github을 소프트웨어 개발의 사실상 _허브_로 만들었어요. 얼마나 좋았으면 "developers, developers, developers"로 유명했던 microsoft가 거금을 들여 인수하기로 했겠어요.
지금 제안은 우리 모두 기계신을 위해 희생해야 한다는 거예요. 개발자는 코드를 짜지 말고 기계가 틀렸을 때만 바로잡고, 수학자는 슬롭을 읽고 거기서 새로운 과학을 도출하고, 일반인은 기계에게 야한 얘기를 걸지 말아야 한다는 거죠. 그러니까
물이랑 전기까지 바치지 못할 이유가 뭐예요?
제안된 해법은 쓰는 만큼 더 내라는 것이었고, 그러면 소비가 줄어서 시스템이 더 안정된다는 겁니다. 이건 공공 인프라로 확장해서 배급제나 한도제로 바꾸기 전까지는 말이 됩니다. 첫째, GitHub 사용자는 GitHub의 안정성에 신경 씁니다. 다른 사람들은 아닙니다. 둘째, 대안이 있고 아무도 다른 사람에게 GitHub을 강요하지 않습니다. 셋째, 한도를 제안한 게 아니라 비용 조정만 제안했습니다. GitHub 쪽 논리가 타당한 이유는 전부 이것들입니다.
공공 인프라 이용자 대다수는 GitHub이나 AI에 관심이 없습니다. "우리 모두 기계신을 위해 희생해야 한다"는 주장에 따라 배급이나 제한을 제안한다면 아마 꺼지라고 할 겁니다. 데이터센터 개발이 지역사회의 반발을 꽤 사고 있는 것도 바로 그 때문입니다.
당신의 사고방식은 GitHub 사용자 집단에서는 아마 더 평균에 가깝겠지만, 일반 대중과 비교하면 평균에서 크게 벗어난다고 생각합니다.
제 "제안"이 비꼬는 거였다는 건 이해하시죠?
비용을 0에서 0이 아닌 값으로 올리는 건 비용 조정이 아니라 제한이에요.
아니요, 이해 못 했습니다. 비유로 들렸으니까요. 서로 다른 것을 비교하는 거 말입니다. 그걸 부정하고 입장을 더 굳히셨는데, 제가 왜 비꼬는 거라고 짐작해야 하죠?
말이 안 됩니다. "비용을 올리는 것은 비용 조정이 아니다"라니요. 새 비용을 낼 의향이 있다면 제한이 아닙니다. 그러니 직접적인 제한이 아니죠. 서비스를 얼마나 가치 있게 보느냐에 따라 선택하는 겁니다. 물과 전기에 똑같이 한다는 건 요금을 올리고 수요·공급 경제에 맡기는 것일 텐데, 당신은 비용 조정 얘기는 한마디도 없이 사람들이 강제로 덜 쓰게 해야 한다고 말하고 있습니다... 비용 조정이 무슨 뜻인지는 아는 건지 모르겠네요.
이봐요,
비유라는 게 아니라, 이 일에 당신보다 덜 몰입한 어떤 OP가 실제로 제안한 게 그거란 말이에요.
"바이브코더들이 다른 사용자들에게 피해를 주고 있으니 지금껏 자유롭게 허용하던 github actions 사용 권한을 없애야 한다"는 "기계신을 [편집: 기계신의 추종자들을] 달래야 한다"와 같은 말이고, 그건 "기계에게 물과 전기를 내줘야 한다", "웹사이트를 기계 친화적으로 만들어야 한다"와도 같은 말이에요.
이제 위 내용을 당신의 두 번째 논거에 적용해 보세요.
물과 전기는 서비스를 얼마나 가치 있게 보느냐에 따라 선택하는 거죠.
그래서 비꼬는 거라고 짐작했어야 한다는 거예요.
0에서 0이 아닌 값으로 가는 단계가 왜 중요하냐면, 온라인으로 결제할 수단이 없는 사람들은 그 서비스를 쓸 수 없게 되기 때문이에요. 인구로 따지면 세계 대다수가 그럴 텐데요(미안하지만 visa와 mastercard는 서구 영향권 밖에서는 별로 인기가 없어요).
AI 공세가 닥치기 전에 개인 계정을 무료로 하기로 판단한 거죠. 지금은 모든 코딩 에이전트가 GitHub을 파일 시스템 백엔드로 쓰면서 아무도 들어 본 적 없는 한계까지 몰아붙이고 있고요.
Microsoft에 머리가 있다면 cursor나 anthropic이 알아채기 전에 이걸 모든 AI 에이전트의 사실상 표준 파일 시스템으로 만드는 데 활용할 텐데요.
맞아요, 바로 어제 claude에게 오픈소스 프로젝트에 커밋이 올라올 때마다 제 lifx 전구를 깜빡이게 하는 프로젝트를 처음부터 끝까지 만들어서 배포하라고 시켰거든요. 아침에 보니 어제 PST 밤 11시쯤 멈춰 있더라고요. 왜 그런가 싶었고, 이런 완성된 프로젝트를 몇 분 만에 만드는 게 이렇게 쉬운데 사람들이 하루에 이런 걸 수백 개씩 만들지 못할 이유가 뭘까 싶었어요. Github은 이런 시나리오를 위해 만들어진 게 아니었죠.
무료 Github Actions는 이런 시나리오를 위해 만들어진 게 아니었습니다.
Github Actions를 유료 등급 전용으로 만들면 이 문제는 사라집니다.
Github은 자체 러너에 요금을 물리겠다고 했다가 거센 반발을 겪은 뒤라 그렇게 하기를 너무 겁내고 있지만, 이번에는 아주 다른 일일 겁니다. 한 푼도 낸 적 없는 사람들에게 무료 actions 제공을 그냥 중단하면 되니까요.