8월 17일 GitHub.com에 다시 장애가 발생함
웹과 API 트래픽의 약 20%, 아카이브와 Raw 콘텐츠 다운로드의 약 50%에서 오류가 발생했고 Pull Request/Issues/Actions/Webhooks까지 영향을 받음
복구된 뒤에도 Pull Request에 접근할 수 없는데 공식 상태 페이지는 모두 정상으로 표시되는 상황이 이어짐
그리고 몇 시간 지나지 않아 GitHub의 대안은 무엇인가, 이제는 다른 서비스로 옮기는 것이 합리적인가라는 질문이 나란히 올라옴
GitHub가 멈출 때마다 장애 신고가 이주 상담으로 이어지는 익숙한 흐름이 보임
하지만 어디로 옮길지 이야기하기 전에 먼저 봐야 할 것이 있음
GitHub가 멈췄을 때 우리에게서 정확히 무엇이 멈추는가
GitHub 장애는 오래됐지만 멈추는 범위가 달라짐
GitHub 장애가 새로운 일은 아님
2023년에도 GitHub.com 서비스 중단이 있었고, 당시에도 상태 페이지와 실제 상황이 다르다는 지적과 오픈소스를 한곳에 모으는 것이 안전한가라는 질문이 나옴
최근에는 장애가 더 자주 보일 뿐 아니라 서로 다른 작업을 연달아 막음
- Pull Request 검색 결과가 누락돼 전체 인덱스를 다시 구축한 장애
- GitHub Actions와 Pages가 6시간 넘게 영향을 받은 장애
- Issues/PR/API/Webhooks/Actions가 함께 영향을 받은 이번 장애
- 상태 페이지에는 정상으로 표시되지만 실제 PR에는 접근할 수 없었던 후속 문제까지
특히 GitHub Actions와 Pages가 6시간 넘게 영향을 받은 장애에서는 자체 호스팅 러너도 작업을 받지 못함
컴퓨팅 자원은 자기 서버에 있는데도, 작업을 배정하는 제어면(Control Plane) 은 GitHub에 남아 있기 때문
Git 저장소만 GitHub에 둔다고 생각했지만 실제로는 리뷰 / 자동화 / 릴리스 / 프로젝트 운영을 함께 맡기고 있었던 것
최근 장애의 원인을 하나로 설명하기는 어려움
AI 에이전트가 만드는 커밋과 PR, Actions 작업이 급증했다는 설명도 있고 Azure 인프라 이전이나 오래된 내부 구조를 지적하는 의견도 있음
원인은 갈리지만 부하가 커졌다는 사실 자체는 확인됨
GitHub COO Kyle Daigle이 공개한 수치에 따르면 GitHub Actions 실행 시간은 2023년 주당 5억 분에서 2025년 주당 10억 분으로 늘었고, 2026년 4월 초에는 그 주 누적 21억 분에 도달함
이 수치가 AI를 장애의 단일 원인으로 증명하지는 않지만, 플랫폼이 감당해야 할 작업량이 급격히 커졌다는 것은 보여줌
GitHub이 침몰하고 있다는 AI가 만들어낸 트래픽과 플랫폼의 방향 전환을 함께 원인으로 지목함
반면 GitHub의 가용성 문제는 최근의 에이전틱 코딩 열풍보다 훨씬 전부터 이어졌음
Microsoft 인수나 AI 하나만으로 모든 장애를 설명하기는 어려움
다만 원인을 정확히 알지 못해도 한 서비스의 장애가 개발 과정 전체를 멈춘다는 사실은 확인할 수 있음
GitHub는 저장소를 잘 호스팅해서만 승리한 것이 아님
GitHub이 실제로 승리한 이유는 적절한 시기와 좋은 감각 때문이었음
Git과 Mercurial이 분산 버전 관리의 가능성을 열었지만 당시 오픈소스에 기여하는 과정은 여전히 복잡했음
GitHub은 저장소를 올리는 공간에 그치지 않고 개발자를 중심으로 프로젝트를 배치함
프로젝트/사용자가 아니라 사용자/프로젝트가 됐고, 포크와 Pull Request는 단순한 Git 명령이 아니라 사람 사이의 협업 방식이 됨
계정 하나로 이슈를 등록하고, PR을 보내고, 다른 개발자를 팔로우하며 새로운 프로젝트를 발견할 수 있었음
이후 Actions/Releases/Packages/보안 알림까지 들어오면서 GitHub는 저장소가 아니라 소프트웨어 개발의 기본 작업 공간이 됨
GitHub 이전의 오픈소스 세계에서는 프로젝트마다 자체 서버, Trac, Subversion, 메일링 리스트와 릴리스 페이지를 운영함
자율성은 있었지만 서비스가 사라지면 코드뿐 아니라 이슈/토론/릴리스 기록도 함께 사라지기 쉬웠음
GitHub의 중앙화는 이런 기록을 한곳에 보존하고 발견할 수 있게 만들었음
지금 우리가 GitHub에서 쉽게 떠나지 못하는 이유도 바로 GitHub가 잘 해결했던 문제들에 있음
Git은 분산돼 있지만 개발 과정은 분산돼 있지 않음
Git 저장소 자체는 옮기기 쉬움
모든 개발자의 컴퓨터에 전체 이력이 있고 다른 원격 저장소를 추가하거나 새 포지로 푸시할 수 있음
그러나 현대적인 프로젝트에서 Git이 담당하는 부분은 생각보다 작음
나만의 GitHub를 만든다면은 실제 업무의 핵심이 Git보다 PR/Actions/Issues/Releases 같은 Forge 기능에서 더 많이 일어난다고 지적함
GitHub 의존은 대략 네 층으로 나뉨
- 코드와 Git 이력
- 가장 쉽게 복제하고 이동할 수 있는 부분
- 다른 원격 저장소나 정기적인 미러만 있어도 코드 자체를 잃을 위험은 크게 줄어듦
- Issues와 Pull Request
- 코드보다 옮기기 어려운 부분
- 오랫동안 쌓인 논의와 설계 판단, 리뷰 기록, 상호 참조가 GitHub 데이터 모델과 URL에 묶여 있음
- 내보내기는 가능하지만 다른 서비스로 옮기면 링크와 대화의 맥락까지 그대로 보존하기 어려움
- Actions와 릴리스 과정
- GitHub 장애가 실제 업무를 멈추게 만드는 부분
- 테스트/패키징/배포/릴리스 생성이 Actions에 연결돼 있다면 저장소 사본이 있어도 할 수 있는 일이 제한됨
- GitHub Actions에 대한 불만도 오래전부터 반복됨
- GitHub Actions는 훨씬 더 좋아질 수 있음은 디버깅과 보안 모델의 어려움을 지적
- GitHub Actions를 다시 사용하기 전에 생각해보려는 이유는 수년간 해결되지 않은 워크플로 문제를 다룸
- 최근에는 GitHub Actions가 엔지니어링 팀을 서서히 죽이고 있다는 강한 제목까지 등장
- 정체성과 발견
- 가장 옮기기 어려운 부분
- 개발자들이 이미 가진 계정/프로젝트의 Star/기여 이력/검색 노출/익숙한 PR 관습은 저장소를 복사한다고 따라오지 않음
- 오픈소스 프로젝트라면 코드 호스팅 비용보다 이 네트워크를 잃는 비용이 더 클 수 있음
나만의 GitHub를 만든다면은 사람들이 왜 떠나고 싶어 하는지도 함께 짚음
문제는 장애 시간만이 아니라 도구가 누구를 위해 만들어지는가에 있음
돈이 있는 사람들은 로켓에 바쁘고, 취향이 있는 사람들은 본업에 바쁘며, 나머지는 자정에 asdfasdf라는 PR을 열고 로봇 검사를 기다리며 하루 종일 쓰는 도구가 언제부터 사용자를 위해 만들어지지 않게 되었는지 묻게 됨
GitHub를 이기게 만든 것이 좋은 감각이었다면, 지금 사람들이 묻는 것은 그 감각이 어디로 갔는가임
그래서 GitHub의 대안은 있지만 대체재는 없다는 저장소를 호스팅하는 서비스와 GitHub 전체를 대체하는 서비스를 구분함
Ghostty는 목적지를 정하지 않고 먼저 떠나기로 함
Ghostty가 GitHub를 떠난다는 발표는 이 문제를 가장 구체적으로 보여줌
Mitchell Hashimoto는 한 달 동안 GitHub 문제로 작업이 막힌 날을 기록했고 거의 매일 영향이 있었다고 밝힘
글을 작성하던 날에도 Actions 장애로 약 2시간 동안 Pull Request를 리뷰하지 못함
그가 지적한 문제는 Git이 아님
Issues, Pull Requests, Actions 같은 주변 인프라가 실제 작업을 막고 있음
흥미로운 것은 발표 당시 어디로 옮길지 결정하지 않았다는 점
여러 상용 서비스와 오픈소스 제공자를 검토하면서 GitHub 의존을 점진적으로 줄이고, 기존 GitHub URL에는 읽기 전용 미러를 남길 계획이라고 밝힘
GitHub가 더 이상 진지한 작업을 위한 장소가 아니라는 발언은 강하게 퍼졌지만 실제 이주 전략은 훨씬 신중했음
GitHub를 한 번에 지우는 것이 아니라 GitHub가 없어도 프로젝트를 운영할 수 있는 부분부터 분리하는 방식
대안은 무엇을 포기하느냐에 따라 달라짐
GitHub 대안 목록은 이미 충분히 길지만 모든 프로젝트에 맞는 하나의 답은 없음
- 다른 관리형 Forge
- GitLab이나 Codeberg처럼 저장소/이슈/리뷰/CI를 함께 제공하는 서비스
- 가장 쉽게 이전할 수 있지만 중앙 서비스 하나에 여러 기능을 다시 맡긴다는 구조는 크게 달라지지 않음
- 자체 호스팅 Forge
- Forgejo/Gitea/GitLab 등을 직접 운영하는 방식
- 데이터와 정책을 통제할 수 있지만 업그레이드/백업/보안/메일/러너 운영을 직접 책임져야 함
- 작은 팀이나 내부 프로젝트에는 충분히 현실적이지만, 공개 오픈소스에서는 기여자마다 새 계정을 만들어야 하는 장벽이 생김
- 가벼운 Git 호스팅
- SourceHut/cgit/stagit처럼 Git 저장소와 최소한의 협업 기능만 사용하는 방식
- 빠르고 단순하지만 GitHub식 Pull Request와 소셜 기능을 포기하거나 이메일 중심 흐름을 새로 익혀야 함
- 연합형 또는 P2P Forge
- Forgejo Federation/Radicle/Tangled처럼 하나의 중앙 운영자에게 의존하지 않으려는 방식
- 장기적으로 가장 흥미롭지만 아직 GitHub의 일상적인 협업 경험을 그대로 대체할 정도로 성숙하지는 않음
- 다른 중앙 서비스로 옮긴다고 정책 위험까지 사라지는 것도 아님
목록에서 자주 빠지는 항목이 하나 더 있음
무료 CI 실행기
공개 프로젝트는 Linux뿐 아니라 Windows와 macOS 표준 러너까지 무료로 사용할 수 있고, 이를 GitHub에 남는 중요한 이유로 꼽는 개발자도 적지 않음
포지를 옮기면 협업 방식만 달라지는 것이 아니라 기존에는 없던 비용이 생길 수 있음
여러 운영체제의 실행 환경을 한꺼번에 제공하는 관리형 CI를 대체하기 어렵다는 점도 이주를 미루게 만드는 요인
Codeberg로 이전한 것을 후회하는 이유는 GitHub를 떠난 한 개발자가 Codeberg의 LLM/암호화폐 프로젝트 정책과 의사 결정 방식을 보고 다시 자체 호스팅을 고민하게 된 사례
이 글 하나로 Codeberg 전체를 평가할 수는 없음
Codeberg는 무료 자원과 명확한 사명을 가진 비영리 서비스이며 어떤 프로젝트를 지원할지 정할 권리가 있음
다만 GitHub에서 Codeberg로 이동하는 것은 플랫폼의 판단에서 완전히 벗어나는 일이 아니라 Microsoft의 판단 대신 다른 운영 주체의 판단을 선택하는 일
우리가 먼저 해야할 건 전면 이주보다 의존성 분리
GitHub를 지금 당장 버리는 것이 모든 프로젝트에 합리적이지는 않음
GitHub가 제공하는 발견/기여/무료 CI/생태계 연결의 가치는 여전히 큼
반대로 잦은 장애를 불평하면서 코드/리뷰/빌드/배포/릴리스를 계속 한곳에만 맡기는 것도 좋은 대응은 아님
먼저 GitHub가 멈췄을 때 계속되어야 하는 작업부터 정해야 함
- 코드는 다른 곳에도 존재해야 함
- 독립된 원격 저장소나 주기적인 미러를 두고 실제 복구가 가능한지 확인
- 미러가 있다는 사실보다 그 미러에서 다시 작업을 시작할 수 있는지가 중요함
- 프로젝트의 기억을 코드 밖에만 두지 않기
- 중요한 설계 판단과 운영 절차를 PR 댓글에만 남기지 않고 저장소의 문서로 옮김
- Issues/PR/Releases/Wiki도 필요에 따라 주기적으로 보존
- 릴리스 경로는 별도로 복구 가능해야 함
- GitHub Actions가 멈췄을 때 모든 테스트를 계속 돌릴 필요는 없을 수 있음
- 하지만 긴급 수정이나 중요한 릴리스까지 전혀 만들 수 없다면 최소한의 대체 경로는 필요함
- 자체 호스팅 러너만 추가하면 충분한지도 확인해야 함
- 작업 배정과 인증이 GitHub 제어면에 남아 있다면 GitHub 전체 장애에서는 함께 멈출 수 있음
- 오픈소스의 입구와 작업 공간을 분리할 수 있음
- 실제 개발은 다른 Forge에서 진행하면서 GitHub에는 읽기 전용 미러를 남길 수 있음
- 반대로 GitHub를 계속 주 작업 공간으로 사용하면서 다른 곳에 코드와 릴리스 사본을 둘 수도 있음
- 기여자에게 익숙한 입구를 유지하면서 내부 의존은 줄이는 절충안
GitHub를 떠나야 할까
개인 프로젝트라면 다른 Forge를 시험하기 쉬움
GitHub의 모든 기능이 필요하지 않다면 Codeberg/SourceHut/자체 Forge만으로 충분할 수 있음
공개 오픈소스라면 이주 비용이 더 큼
새 계정/낮아진 발견 가능성/기여 절차 변화가 실제 참여 감소로 이어질 수 있으므로 Ghostty처럼 기존 URL을 미러로 유지하는 점진적인 이전이 현실적
기업이라면 GitHub를 유지하는 결정도 충분히 합리적
이미 구축한 권한/Actions/보안/배포 생태계를 다시 만드는 비용이 몇 시간의 장애보다 클 수 있음
대신 정확한 질문을 해야함
GitHub가 몇 시간 멈추면 우리 조직에서 정확히 무엇이 멈추는가
리뷰만 늦어지는지, 배포가 막히는지, 긴급 복구가 불가능해지는지에 따라 대응도 달라짐
GitHub를 떠날지 결정하기 전에 GitHub가 멈춰도 계속되어야 하는 작업을 먼저 분리하는 편이 나음
GitHub는 여전히 가장 편리한 입구일 수 있음
하지만 유일한 저장소/유일한 기록/유일한 빌드 시스템/유일한 배포 경로일 필요는 없음
GitHub를 떠나는 것보다 먼저 해야 할 일은, 필요할 때 떠날 수 있는 구조를 만드는 것