GitHub이 멈춘 날 — 개발 세계가 한 회사에 걸려 있다는 것
GitHub이 멈춘 날 — 개발 세계가 한 회사에 걸려 있다는 것
GitHub이 또 멈췄다. 하지만 진짜 질문은 “왜 GitHub이 죽었나”가 아니라 “왜 한 회사의 데이터센터 하나가 전 세계 개발 파이프라인을 동시에 멈출 수 있는가”다 — 이것은 GitHub의 기술적 실패인가, 아니면 우리 모두가 편의를 위해 집중을 선택한 대가인가?
도입 — 로드밸런서 몇 대가 멈춘 7시간 47분
2026년 8월 17일, UTC 기준 13시 28분부터 21시 15분까지 7시간 47분 동안 GitHub.com이 흔들렸다. 이슈(Issues), 풀 리퀘스트(Pull Requests), API, Actions, 그리고 Copilot이 동시에 느려지거나 실패했다. GitHub이 사후에 공개한 인시던트 리포트에 따르면, 정점에서 웹·API 오류율은 약 20%였고 아카이브 다운로드와 raw 저장소 콘텐츠 다운로드는 약 50%까지 치솟았다. SAML·OIDC 인증, SCIM, 팀 동기화(Team Sync)까지 영향을 받았고, 데이터 레지던시를 쓰는 GitHub Enterprise Cloud의 Actions 워크플로 중 GitHub.com에 호스팅된 공개 스텝 정의에 의존하는 것들도 함께 멈췄다.
개발자에게 GitHub 장애는 “웹사이트 하나가 안 열리는” 사건이 아니다. 코드 푸시, CI 빌드, 배포 파이프라인, 패키지 설치, 로그인, 그리고 이제는 에디터 안의 AI 자동완성까지 하루치 작업 흐름 전체가 한꺼번에 멈춘다. 같은 날 해커뉴스에는 장애 스레드와 별개로 “Ask HN: GitHub의 대안은 무엇인가”라는 질문이 올라와 421개의 댓글이 달렸다. 장애가 복구되기도 전에 사람들은 이미 다음 질문으로 옮겨가 있었다 — 우리는 왜 이렇게 한 회사에 걸려 있으며, 빠져나갈 길은 있는가. 이 글은 두 가지를 분리해서 본다. 먼저 무엇이 언제 어떻게 막혔는가(팩트), 그다음 왜 우리가 이 구조에 도달했는가(분석)다.
현상 — 무엇이 막혔나, 그리고 병목은 왜 인증이었나
먼저 사실 관계다. GitHub의 사후 리포트를 시간순으로 따라가면 이날 장애의 형태가 분명하게 드러난다. 14시 58분경 웹·API 트래픽 오류율이 약 20%에 이르렀고, 15시대에는 API·Pages·Git 오퍼레이션·Webhooks가 차례로 성능 저하 상태로 표시됐다. 16시 36분에 미국 중부(Central US) 데이터센터가 회복되면서 대부분의 서비스가 정상으로 돌아왔지만, Actions는 약 18시 03분까지 저하 상태였고, Copilot 토큰 서비스(Copilot Token Service)는 21시 02분에야 완전히 회복됐다. 즉 하나의 장애가 아니라, 회복 뒤에도 꼬리처럼 남은 잔여 실패가 몇 시간을 더 끈 사건이었다.
원인의 구조는 교과서적인 캐스케이드다. 리포트에 따르면 직접적 방아쇠는 미국 중부 로드밸런서의 네트워크 포화였다. 트래픽이 새로운 정점을 찍었고, 애초에 이를 촉발한 것은 이스티오(Istio) 사이드카 파드 하나가 동시성 한계에 도달했는데 오토스케일링 정책이 잘못 설정되어 있어 제대로 확장하지 못한 것이었다 — 정책이 호스트 서비스의 한계는 감시했지만 사이드카의 한계는 감시하지 않았다는 것이다. 이 하나의 실패가 옆으로 번져 결국 네 대의 HAProxy 노드가 플로우 한계를 소진했고, 게이트웨이의 인증 경로가 무너지면서 광범위한 인증 지연과 실패가 발생했다. 여기에 “낙관적 재시도 로직(optimistic retry logic)“이 상황을 악화시켰다. 실패한 요청을 클라이언트들이 반복해서 다시 던지자 내부 로드밸런서가 더 크게 과부하됐다.
이 대목이 핵심이다. 장애는 저장소 서버가 죽어서가 아니라 인증이라는 공통 길목이 막혀서 전방위로 퍼졌다. 인증 토큰은 GitHub의 거의 모든 제품이 반드시 통과해야 하는 관문이다. 토큰 발급이 지연되면 이슈도, PR도, Actions도, Copilot도 동시에 인증에 실패한다. GitHub은 실패하던 트래픽 일부를 중부에서 북버지니아(Northern Virginia)로 옮겨 처리했는데, 이번엔 그쪽에서 재시도 폭풍이 일었다. 백미는 그 폭풍의 정체다. 어떤 내부 엔드포인트 하나의 응답이 지연되자 VS Code에 잠복해 있던 재시도 버그가 발동해 트래픽을 약 10배로 증폭시켰고, 이것이 Copilot 토큰 서비스의 회복을 지연시켰다. 리포트의 수치가 이 증폭을 그대로 보여준다 — 평소 초당 7~9천 건이던 Copilot 토큰 서비스 트래픽이 초당 7만~10만 건으로 뛰었다.
복구 방법 자체도 시사적이다. 문제의 HAProxy 노드들을 동시에 일시 정지시키자 즉시 광범위한 회복이 일어났고, 북버지니아의 재시도 폭풍은 두 가지로 잡았다 — 게이트웨이 재시도 로직을 PR로 임시 축소하고, Copilot 토큰 요청을 로드밸런서 단에서 403으로 차단한 뒤 사이트별로 트래픽을 서서히 다시 올린 것이다. 여기에 코드로드(codeload) 엔드포인트를 노린 스크래핑 공격이 겹쳐 회복을 방해했다는 설명도 붙었다. GitHub이 밝힌 재발 방지책은 오토스케일링 정책이 서비스 메시 사이드카의 동시성까지 반영하도록 고치고, 이스티오의 요청·동시성·스케일링 한계를 전수 점검하며, 게이트웨이와 클라이언트의 재시도·백오프 한계를 재검토하고, 트래픽을 10배로 부풀린 VS Code의 재시도 동작을 손보고, 로드밸런서 용량 모니터링과 리전 페일오버 보호장치를 개선한다는 것이다. 요약하면 이날의 장애는 하나의 잘못된 설정 → 인증 병목 → 재시도 증폭이라는, 대규모 분산 시스템에서 가장 흔하고 가장 무서운 실패 모드였다.
심층 — 왜 개발 세계가 한 회사에 이렇게 걸려 있게 되었나
기술적 원인이 캐스케이드였다면, 파급의 크기를 결정한 것은 구조다. GitHub은 시간이 지나며 서로 다른 계층을 하나의 우산 아래 묶어 왔다. 소스 호스팅에서 시작해 이슈 트래킹, 코드 리뷰(PR), CI/CD(Actions), 패키지 레지스트리(GitHub Packages, 그리고 2020년 인수한 npm), 신원·인증(“Login with GitHub”으로 수많은 외부 서비스가 GitHub 계정에 의존한다), 마지막으로 AI 코드 어시스턴트(Copilot)까지. 각 계층을 더할 때마다 편의는 커졌지만 단일 실패점(SPOF)의 반경도 함께 커졌다. 이날 인증 하나가 막히자 이 모든 계층이 동시에 흔들린 것은 우연이 아니라 설계의 필연이다. 게다가 2018년 마이크로소프트가 약 $7.5B(75억 달러) 규모로 GitHub을 인수한 뒤, GitHub은 단순한 코드 호스팅이 아니라 마이크로소프트의 개발자 생태계 전략(Azure, VS Code, Copilot으로 이어지는) 한복판에 놓였다. 집중은 회사의 실수가 아니라 사업 모델 그 자체다.
그렇다면 왜 다들 떠나지 못하는가. 해커뉴스의 “Ask HN: GitHub 대안” 토론이 이 마찰을 잘 드러낸다. 가장 자주 추천된 대안은 Forgejo였다. 토론에서는 Forgejo가 Gitea에서 갈라져 나온 커뮤니티 주도 포크로, 단일 바이너리에 Podman·Docker로 손쉽게 얹을 수 있어 비용에 민감한 팀에 매력적이라는 평가가 나왔다. Gitea는 빠르고 관리가 쉽지만 GitLab만큼 기능이 완비되진 않았다는 지적, GitLab 셀프호스트 커뮤니티 에디션은 기능이 풍부한 대신 자원을 많이 먹고 유지보수 부담이 크다는 지적이 이어졌다. Codeberg은 Forgejo로 돌아가는 무료 공개 인스턴스로, AI 생성 코드에 대한 강경한 정책으로 화제가 됐다는 언급도 있었다(이 정책을 두고 “터무니없는 진입장벽”이라는 반응과 “합리적인 커뮤니티 보호”라는 반응이 갈렸다는 것이 토론의 요지다). 이 밖에 이메일 기반 워크플로의 미니멀한 SourceHut, 그리고 Radicle·Tangled 같은 실험적 탈중앙 대안이 거론됐다.
문제는 대안의 존재가 아니라 전환의 마찰이다. 토론에서 반복해 나온 마찰점을 정리하면 이렇다. 첫째, 네트워크 효과다. 프로젝트가 GitHub에 없으면 발견되지 않고, 협업자들이 이주를 꺼린다는 지적이다. 둘째, CI/CD 락인이다. GitHub Actions가 사실상 벤더 종속을 만들고, 대안들은 호환을 표방하지만 기능 동등성은 불완전하다는 것이다(한 참가자가 Actions를 두고 “누군가 환각 상태에서 만든 과학 실험 같다”고 비꼰 대목을 토론은 인상적으로 인용했는데, 이는 조롱인 동시에 그 만큼 대체가 까다롭다는 방증이기도 하다). 셋째, 셀프호스트의 운영 비용이다. 유지보수·보안 패치·러너 관리에 전담 인력이 필요하고, 어떤 회사는 수년간 자동 업그레이드를 돌리며 여러 차례 파괴적 변경(breaking change)을 겪었다는 경험담이 올라왔다. 넷째, 기능 공백이다. Forgejo·Gitea에는 페더레이션(federation)이 없어 인스턴스 간 협업이 제한된다는 지적이다. 중요한 것은, 토론의 상당수가 “GitHub이 이긴 이유는 단지 네트워크 효과가 아니라 실제로 더 나은 개발자 경험(DevX)을 제공하기 때문”이라는 실용주의적 입장을 취했다는 점이다. 대안은 기능만이 아니라 DevX 자체를 따라잡아야 한다는 것 — 그리고 아직 대부분은 그러지 못했다는 것이 냉정한 현실 인식이었다.
여기에 git 자체의 아이러니가 겹친다. git은 본래 탈중앙 분산 버전 관리 시스템이다. 모든 클론이 완전한 저장소 사본을 갖는다. 그런데 우리는 그 위에 이슈·PR·CI·신원·AI를 얹은 “포지(forge)“를 중앙화했고, 그 포지가 곧 GitHub이다. 코드 히스토리는 분산되어 있어도 협업의 사회적 계층 전체가 한 곳에 모여 있는 셈이다. 그래서 GitHub이 멈추면, git이 탈중앙이라는 사실은 위로가 되지 못한다. 로컬에 커밋은 할 수 있지만 PR도, 리뷰도, CI도, 배포도 돌지 않는다.
전망 — 헤지의 방향: 미러링, 셀프호스트, 그리고 AI가 키우는 집중
그렇다면 실무자는 무엇을 할 수 있나. 해커뉴스 토론에서 가장 실용적인 제안은 “미러-앤-미러(mirror-and-mirror)” 전략이었다. Forgejo 같은 셀프호스트 인스턴스를 1차로 두고 GitHub을 2차 미러로 쓰거나 그 반대로 두는 절충안이다. 실제로 6년 넘게 셀프호스트 인스턴스를 운영한 한 참가자는 GitHub 클라우드보다 “다운타임이 훨씬 적었다”고 증언했다 — 물론 그 대가로 운영 부담을 스스로 졌다. 반대편에는 GitLab 러너가 “가장 큰 실패 지점”이라 세세한 관리가 필요하다는 불만도 있었다. 즉 셀프호스트는 가용성을 자기 손에 쥐는 대신, 그 가용성을 유지할 책임까지 통째로 떠안는 트레이드오프다. 만병통치약이 아니다.
이번 장애가 준 구체적 교훈은 더 좁고 실천적이다. 첫째, 인증을 자기 배포 파이프라인의 임계 경로에 두지 마라. GitHub 로그인·토큰 발급이 죽으면 배포가 죽는 구조라면, 그것은 남의 SPOF를 내 SPOF로 상속받은 것이다. 둘째, 의존성을 캐시하고 벤더링하라. npm·컨테이너 레지스트리가 GitHub 계열에 걸려 있다면, 사내 프록시·미러에 패키지를 캐시해 두는 것이 장애 시 빌드를 살린다. 셋째, 재시도에 백오프와 상한을 걸어라. 이날 재난을 키운 것은 바로 상한 없는 낙관적 재시도였다. 아이러니하게도 GitHub을 무너뜨린 실패 모드가, 그 GitHub에 의존하는 우리 시스템에도 그대로 숨어 있을 수 있다. 넷째, 복구 순서를 미리 정의하라 — 무엇부터 되살릴지 모르면, 회복 뒤에도 잔여 실패가 몇 시간을 끈다.
한편 AI는 이 집중을 완화하는 게 아니라 심화시키는 방향으로 작동한다. Copilot이 에디터에 깊이 박힐수록 GitHub 생태계의 접착력은 커진다. 이번 장애가 상징적인 것은, VS Code의 재시도 버그가 Copilot 토큰 트래픽을 10배로 부풀려 회복을 지연시켰다는 점이다. 클라이언트(에디터)와 서버(토큰 서비스)가 AI라는 새로운 축으로 더 촘촘히 묶이면서, 실패의 전파 경로도 하나 더 늘어난 셈이다. 낙관 시나리오에서는 이번 사고가 재시도·오토스케일링·페일오버에 대한 업계 전반의 각성으로 이어지고, 미러링과 셀프호스트가 표준 위생으로 자리 잡는다. 비관 시나리오에서는 편의가 다시 이기고, 다음 장애 때 우리는 똑같이 놀란다. 그 사이의 현실은 아마도, 큰 조직은 미러와 캐시로 조용히 헤지하고 대다수 개인·소규모 팀은 GitHub에 남되 “언젠가 옮겨야지”를 되뇌는 상태의 지속일 것이다.
결론 — GitHub의 실패인가, 집중을 택한 대가인가
리드의 질문으로 돌아가자. 이날의 장애는 GitHub의 기술적 실패이면서 동시에 우리가 집중을 선택한 대가다. 잘못된 오토스케일링 설정 하나가 인증 병목을 만들고 재시도 폭풍이 이를 증폭시킨 것은 분명히 GitHub의 엔지니어링 문제다. 그러나 그 문제가 이슈·PR·CI·패키지·인증·AI를 한꺼번에 마비시킬 수 있었던 것은, 우리가 그 모든 계층을 한 회사의 한 우산 아래 기꺼이 모아 두었기 때문이다. 전자는 포스트모템으로 고칠 수 있다. 후자는 포스트모템으로 고쳐지지 않는다.
그래서 남는 질문은 “GitHub을 떠날 것인가”가 아니다. 대부분은 떠나지 않을 것이고, 떠나야 할 이유도 대부분은 없다 — DevX와 네트워크 효과는 실재하는 가치다. 진짜 질문은 “한 회사에 얼마까지 걸 것인가”다. 코드 히스토리는 이미 분산되어 있으니, 최소한 배포를 살리는 미러 하나, 의존성을 살리는 캐시 하나, 재시도를 억제하는 상한 하나 정도는 스스로 갖추는 것 — 그것이 다음 7시간 47분을 견디는 가장 값싼 보험이다. git은 탈중앙으로 태어났다. 그 위에 우리가 중앙을 지었다면, 그 중앙이 흔들릴 때를 대비하는 것도 우리의 몫이다.
출처: