GitHub 장애가 다시 던진 질문: 우리는 정말 GitHub만 믿고 개발하고 있나
핵심 포인트부터 보면, 이번 이슈는 단순한 서비스 장애가 아닙니다
GitHub 장애는 이제 “잠깐 불편한 일”로 끝나지 않습니다.
이번 사례에서 드러난 건, 코드 저장소 하나가 멈춘 게 아니라 개발 워크플로 전체가 같이 멈춘다는 사실입니다.
Pull Request, Issues, Actions, Webhooks, 릴리스, 배포, 리뷰, 협업 기록까지 한 번에 흔들렸습니다.
더 중요한 건 상태 페이지는 정상처럼 보이는데 실제 작업은 막혀 있었다는 점입니다.
즉, 겉으로 보이는 가용성과 실제 개발 생산성 사이의 간극이 생각보다 훨씬 크다는 뜻입니다.
이번 글에서는 GitHub 장애의 진짜 의미, GitHub가 왜 이렇게까지 강해졌는지,
그리고 지금 기업과 오픈소스 프로젝트가 무엇을 분리하고 무엇을 준비해야 하는지까지 체계적으로 정리해보겠습니다.
특히 다른 뉴스에서 잘 안 짚는 핵심인
“GitHub를 떠날지”보다 “GitHub가 멈춰도 계속 돌아가게 만들 수 있느냐”가 더 중요하다는 점을 따로 짚어보겠습니다.
1. GitHub 장애는 왜 이렇게 자주 체감될까
단순 서버 장애가 아니라, 개발 인프라 전체의 동시 정지에 가깝습니다
이번 장애에서는 웹과 API 트래픽의 약 20%,
아카이브와 Raw 콘텐츠 다운로드의 약 50%에서 오류가 발생했습니다.
여기에 Pull Request, Issues, Actions, Webhooks까지 영향을 받았습니다.
문제는 여기서 끝나지 않았습니다.
복구 이후에도 PR 접근이 안 되는데 공식 상태 페이지는 정상으로 나오는 상황이 이어졌습니다.
이건 개발자 입장에서 정말 골치 아픈 유형입니다.
“장애가 났다”보다 더 무서운 건 “장애인지 아닌지조차 헷갈리는 상태”이기 때문입니다.
최근 GitHub 장애의 특징은 범위가 넓다는 점입니다
예전에는 한 기능만 잠깐 흔들리는 정도였다면,
최근에는 서로 다른 업무가 연달아 막히는 패턴이 반복되고 있습니다.
대표적으로
Pull Request 검색 결과 누락으로 인덱스를 다시 만든 장애,
GitHub Actions와 Pages가 6시간 넘게 영향을 받은 장애,
Issues/PR/API/Webhooks/Actions가 동시에 영향받은 장애가 있었습니다.
즉, 개발자들이 실제로 쓰는 핵심 도구들이 한 번에 묶여서 멈추는 형태입니다.
자체 호스팅 러너도 안 움직인 이유가 있습니다
많은 분들이 “러너만 우리 서버에 있으면 되지 않나?”라고 생각하는데,
실제론 그렇지 않습니다.
작업을 할당하는 제어면(Control Plane)은 GitHub에 남아 있는 경우가 많습니다.
즉, 컴퓨팅 자원은 내 서버에 있어도,
누가 어떤 작업을 언제 실행할지 정해주는 핵심은 여전히 GitHub가 쥐고 있는 구조입니다.
이게 바로 “GitHub에 저장소만 둔 게 아니라, 운영의 허리까지 맡기고 있었다”는 뜻입니다.
2. 원인은 하나가 아닙니다. 하지만 부하가 커진 건 분명합니다
AI 에이전트, 인프라 이전, 오래된 내부 구조가 모두 거론됩니다
최근 GitHub 장애 원인으로는 여러 해석이 나옵니다.
AI 에이전트가 만들어내는 커밋과 PR, Actions 작업 급증,
Azure 인프라 이전 이슈,
오래된 내부 구조 문제 등이 함께 거론됩니다.
정확한 단일 원인을 딱 잘라 말하긴 어렵지만,
확실한 건 플랫폼이 감당해야 하는 작업량이 급격히 커졌다는 점입니다.
Actions 사용량은 숫자로도 폭증했습니다
GitHub COO Kyle Daigle가 공개한 수치에 따르면
GitHub Actions 실행 시간은 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었습니다.
그리고 2026년 4월 초에는 그 주 누적 21억 분에 도달했습니다.
이건 단순히 “AI 때문”이라고 결론낼 수 있는 숫자는 아닙니다.
하지만 AI 코딩, 자동화, CI/CD, 릴리스 자동화가 플랫폼 전체에 엄청난 압박을 주고 있다는 점은 분명하게 보여줍니다.
중요한 건 원인보다 결과입니다
원인이 AI든, 인프라든, 설계 한계든 상관없이
현장에서 중요한 건 결국 하나입니다.
한 서비스의 장애가 개발 과정 전체를 멈출 수 있다는 사실입니다.
이건 요즘 같은 AI 시대에 더 크게 느껴집니다.
AI가 코드를 더 빨리 만들수록,
그 코드를 검증하고 배포하고 조정하는 플랫폼 병목이 더 크게 드러나기 때문입니다.
3. GitHub는 단순한 코드 저장소가 아닙니다
GitHub가 이긴 이유는 저장소를 잘 올려둬서가 아닙니다
GitHub는 Git 저장소 호스팅만 잘해서 승리한 게 아닙니다.
적절한 시기에, 개발자 중심의 협업 구조를 정확히 잡아냈기 때문입니다.
예전엔 프로젝트/사용자 중심이었지만,
GitHub는 사용자/프로젝트 중심으로 개발 흐름을 바꿔놨습니다.
포크, Pull Request, 이슈, 팔로우, 발견성, 소셜 협업이 한 화면 안에 들어왔습니다.
즉, GitHub는 저장소가 아니라 개발자 네트워크를 만든 겁니다.
오픈소스의 세계를 바꾼 건 중앙화의 편리함이었습니다
예전 오픈소스 생태계는 프로젝트마다 서버, Trac, Subversion, 메일링 리스트, 릴리스 페이지가 따로 있었습니다.
자율성은 높았지만,
서비스가 사라지면 코드뿐 아니라 이슈와 토론, 릴리스 기록까지 같이 사라지기 쉬웠습니다.
GitHub는 이걸 한곳에 모아 보존하고 발견할 수 있게 만들었습니다.
그 결과 사람들은 편해졌고,
그 편리함이 쌓여 사실상의 표준이 됐습니다.
지금 우리가 GitHub를 쉽게 떠나지 못하는 이유
이유는 단순합니다.
GitHub가 잘 해결해준 문제들이 너무 많기 때문입니다.
코드 리뷰, 이슈 관리, 릴리스, 패키지, 보안 알림, Actions, 협업 기록, 검색 노출, 기여 이력까지
한 번에 묶여 있기 때문에,
하나씩 따로 떼어내려면 생각보다 큰 비용이 듭니다.
4. Git은 분산돼 있지만, 개발 과정은 분산돼 있지 않습니다
코드는 옮기기 쉽지만, 일하는 방식은 옮기기 어렵습니다
Git 저장소 자체는 사실 옮기기 쉽습니다.
모든 개발자의 컴퓨터에 전체 이력이 있고,
다른 원격 저장소를 추가하거나 새 포크로 푸시하면 되기 때문입니다.
하지만 현대 프로젝트의 핵심은 Git 그 자체보다 PR, Issues, Actions, Releases 같은 Forge 기능에 있습니다.
문제는 바로 여기서 생깁니다.
GitHub 의존도는 크게 4층으로 나눌 수 있습니다
코드와 Git 이력
가장 쉽게 복제하고 이동할 수 있는 부분입니다.
정기적인 미러나 다른 원격 저장소만 있어도 코드 자체를 잃을 위험은 크게 줄어듭니다.
Issues와 Pull Request
코드보다 훨씬 옮기기 어려운 부분입니다.
오랜 논의, 설계 판단, 리뷰 기록, 상호 참조가 GitHub 데이터 모델과 URL에 강하게 묶여 있습니다.
내보내기는 가능해도 맥락까지 그대로 옮기기는 어렵습니다.
Actions와 릴리스 과정
실제로 장애가 업무를 멈추게 만드는 핵심 지점입니다.
테스트, 패키징, 배포, 릴리스 생성이 Actions에 연결돼 있으면
저장소 사본이 있어도 당장 할 수 있는 일이 제한됩니다.
정체성과 발견성
가장 옮기기 어려운 부분입니다.
Star, 기여 이력, 검색 노출, 익숙한 PR 관습은 저장소 복사만으로 따라오지 않습니다.
특히 오픈소스는 코드보다 이 네트워크를 잃는 비용이 더 큽니다.
5. AI 시대에 GitHub 장애가 더 민감하게 느껴지는 이유
AI 코딩이 늘수록 플랫폼 병목도 함께 커집니다
요즘은 AI 에이전트가 코드 생성, PR 생성, 테스트 실행, 리팩토링을 빠르게 만들어냅니다.
이 과정이 많아질수록 GitHub Actions, 리뷰, 릴리스, 자동화 파이프라인에 쏠리는 압력이 커집니다.
즉, AI가 생산성을 높이는 동시에
플랫폼 의존도를 훨씬 더 빠르게 키우고 있습니다.
개발 생산성의 중심이 로컬 IDE에서 플랫폼으로 이동했습니다
예전엔 내 컴퓨터에서 코드를 짜는 시간이 가장 중요했다면,
이제는
PR을 만들고,
자동 테스트를 돌리고,
검토를 받고,
배포하는 과정이 더 중요해졌습니다.
그래서 GitHub가 멈추면 “코드를 못 쓰는 문제”보다 “일을 끝낼 수 없는 문제”가 생깁니다.
이 차이는 생각보다 큽니다.
6. Ghostty 사례가 보여주는 현실적인 탈출 전략
핵심은 한 번에 탈출하는 게 아니라, 의존도를 천천히 줄이는 겁니다
Ghostty는 GitHub를 떠나겠다고 하면서도,
어디로 갈지는 먼저 확정하지 않았습니다.
이게 중요합니다.
무작정 옮기는 게 아니라,
GitHub 의존을 점진적으로 줄이고, 기존 GitHub URL에는 읽기 전용 미러를 남기는 방식을 택했습니다.
이 말은 곧
“GitHub를 완전히 버리는 것”보다
“GitHub 없이도 운영 가능한 구조를 먼저 만드는 것”이 더 현실적이라는 뜻입니다.
GitHub를 떠날 때 제일 중요한 건 URL과 맥락입니다
많은 프로젝트가 이주를 망설이는 이유는 단순히 저장소 때문이 아닙니다.
기존 이슈 링크, PR 링크, 리뷰 기록, 검색 노출, 커뮤니티 관성까지 함께 움직이기 때문입니다.
그래서 읽기 전용 미러를 남기고,
주 작업 공간만 천천히 옮기는 전략이 훨씬 현실적입니다.
7. GitHub 대안은 많지만, 대체재는 하나가 아닙니다
무엇을 포기하느냐에 따라 답이 달라집니다
다른 관리형 Forge
GitLab이나 Codeberg처럼 저장소, 이슈, 리뷰, CI를 함께 제공하는 서비스입니다.
이전은 쉽지만 중앙 서비스 의존 구조는 크게 바뀌지 않습니다.
자체 호스팅 Forge
Forgejo, Gitea, GitLab을 직접 운영하는 방식입니다.
데이터와 정책을 통제할 수 있지만, 업그레이드, 백업, 보안, 메일, 러너 운영을 직접 책임져야 합니다.
작은 팀이나 내부 프로젝트에는 현실적입니다.
가벼운 Git 호스팅
SourceHut, cgit, stagit처럼 최소 기능 중심의 방식입니다.
빠르고 단순하지만, GitHub식 PR과 소셜 기능을 포기하거나 이메일 중심 흐름을 새로 익혀야 합니다.
연합형 또는 P2P Forge
Forgejo Federation, Radicle, Tangled처럼 중앙 운영자 의존을 줄이려는 방식입니다.
장기적으로는 흥미롭지만, 아직 일상적인 협업 경험을 완전히 대체할 만큼 성숙하진 않았습니다.
대안으로 옮겨도 정책 위험이 사라지는 건 아닙니다
중요한 점은 다른 중앙 서비스로 간다고 해서
그 플랫폼의 판단과 정책에서 완전히 자유로워지는 건 아니라는 사실입니다.
결국 Microsoft의 판단 대신 다른 운영 주체의 판단을 선택하는 것일 수 있습니다.
그래서 “어디로 갈까”보다 “어디에 무엇을 두고 무엇을 빼낼까”가 더 중요합니다.
무료 CI 실행기 문제는 의외로 큽니다
공개 프로젝트가 GitHub를 쉽게 못 떠나는 이유 중 하나는 무료 CI입니다.
Linux뿐 아니라 Windows, macOS 러너까지 무료로 쓸 수 있다는 점은 꽤 강력합니다.
포지를 옮기면 협업 방식만 바뀌는 게 아니라
이전에 없던 비용이 새로 생길 수 있습니다.
특히 멀티 플랫폼 테스트가 필요한 오픈소스 프로젝트일수록 이 문제가 더 큽니다.
8. 다른 유튜브나 뉴스에서 잘 안 짚는 가장 중요한 내용
진짜 문제는 장애가 아니라 “분리되지 않은 책임 구조”입니다
이번 이슈에서 가장 중요한 메시지는 이겁니다.
우리는 GitHub를 저장소로만 쓰고 있다고 생각하지만,
실제로는 리뷰, 자동화, 배포, 릴리스, 협업 기록, 발견성까지 한 번에 맡기고 있었습니다.
즉, 장애가 났을 때 멈추는 건 서버가 아니라 조직의 일하는 방식입니다.
GitHub를 떠나는 것보다 먼저 해야 할 건 분리입니다
가장 현실적인 전략은 전면 이주가 아닙니다.
먼저 GitHub가 멈춰도 계속 돌아가야 하는 작업을 분리해야 합니다.
코드는 다른 곳에도 존재해야 하고,
릴리스 경로는 별도로 복구 가능해야 하며,
문서와 의사결정은 PR 댓글에만 남기지 말아야 합니다.
이렇게 해야 진짜로 GitHub 의존성을 줄일 수 있습니다.
결국 질문은 이것 하나입니다
GitHub가 몇 시간 멈추면
우리 조직에서 정확히 무엇이 멈추는가.
리뷰만 늦어지는지,
배포가 막히는지,
긴급 복구가 불가능해지는지에 따라 대응이 달라집니다.
이 질문에 답하지 못하면,
다음 장애 때도 똑같이 흔들릴 가능성이 큽니다.
9. 기업과 오픈소스가 지금 바로 점검해야 할 체크리스트
운영 관점에서 바로 확인할 항목들
독립된 원격 저장소나 정기 미러가 있는지 확인해야 합니다.
그리고 그 미러에서 실제로 다시 작업을 시작할 수 있는지도 테스트해야 합니다.
중요한 설계 판단과 운영 절차가 PR 댓글에만 있는지 점검해야 합니다.
필요하다면 저장소 문서로 옮겨야 합니다.
Issues, PR, Releases, Wiki를 주기적으로 보존하고 있는지도 봐야 합니다.
기록을 남기는 것보다, 복구 가능한지 확인하는 게 더 중요합니다.
GitHub Actions가 멈췄을 때 최소한의 릴리스 경로가 있는지도 확인해야 합니다.
자체 호스팅 러너만 추가했다고 끝나는 게 아니라,
작업 배정과 인증이 어디에 남아 있는지도 봐야 합니다.
오픈소스라면 읽기 전용 미러와 주 작업 공간을 분리하는 전략도 충분히 고려할 만합니다.
기여자에게 익숙한 입구는 유지하면서 내부 의존성만 줄이는 방식입니다.
10. 결국 GitHub를 떠나야 할까
정답은 “무조건 떠나라”도, “절대 못 떠난다”도 아닙니다
개인 프로젝트라면 다른 Forge를 시험해보기 쉽습니다.
GitHub의 모든 기능이 필요하지 않다면 Codeberg, SourceHut, 자체 Forge만으로도 충분할 수 있습니다.
공개 오픈소스라면 이주 비용이 훨씬 큽니다.
새 계정, 낮아진 발견 가능성, 기여 절차 변화가 실제 참여 감소로 이어질 수 있습니다.
그래서 Ghostty처럼 점진적으로 이전하는 방식이 더 현실적입니다.
기업이라면 GitHub를 유지하는 결정도 충분히 합리적입니다.
이미 구축한 권한, Actions, 보안, 배포 생태계를 다시 만드는 비용이
몇 시간의 장애보다 더 클 수 있기 때문입니다.
다만 그 경우에도,
GitHub가 멈췄을 때 무엇이 멈추는지 반드시 정의해두어야 합니다.
Summary
GitHub 장애는 단순한 서비스 중단이 아니라 개발 워크플로 전체의 취약성을 드러낸 사건입니다.
핵심은 GitHub를 당장 떠나는지가 아니라, GitHub가 멈춰도 계속 돌아가게 구조를 분리했는지입니다.
AI 코딩과 자동화가 늘수록 Actions, PR, 배포, 릴리스 의존도는 더 커지고 있습니다.
대안은 많지만, 정답은 “이전”보다 “의존성 분리”에 가깝습니다.
지금 필요한 건 탈출이 아니라 복구 가능한 설계입니다.
[관련글…]
GitHub 장애가 반복될수록 더 중요해지는 개발 인프라 점검
AI 코딩 시대, 개발 생산성을 바꾸는 자동화와 플랫폼 의존성
*출처: https://news.hada.io/article/github-is-not-just-git
답글 남기기