GitHub CTO 블라드 페도로프는 최근 두 건의 장애를 설명하며, 앞으로의 우선순위를 "새 기능보다 가용성, 그다음 용량"에 두겠다고 밝혔다.1 배경에는 AI 에이전트와 자동화 확산으로 저장소 생성, PR, API 호출, 대형 리포지토리 작업이 빠르게 늘고 있다는 판단이 있다.1
중요한 건 "GitHub가 믿을 만한가"를 추상적으로 묻는 데서 멈추지 않는 일이다. 실제 현장에서는 GitHub 전체가 완전히 멈추지 않아도, PR 체크 하나·Actions 지연·인증 문제·웹훅 지연 같은 작은 가정 하나가 배포를 막는다. 비즈니스 리스크는 플랫폼의 평균 업타임이 아니라, 우리 팀이 GitHub의 어떤 기능에 얼마나 깊게 묶여 있는지에서 생긴다.
더 나은 질문: GitHub 장애 중 무엇이 당신 팀을 멈추게 하나
최근 장애들을 보면 문제 양상이 제각각이었다. 4월 23일에는 merge queue의 squash merge 동작 회귀로 230개 저장소, 2,092개 PR이 영향을 받았고, 데이터 손실은 없었지만 기본 브랜치 상태가 잘못될 수 있었다.1 4월 27일에는 Elasticsearch 과부하로 검색 기반 UI가 비어 보였지만, Git 작업과 API는 영향이 없었다.1
여기서 실무적으로 중요한 포인트가 드러난다. 같은 "GitHub 장애"라도 팀마다 타격 지점이 완전히 다르다. 검색이 죽어도 로컬 Git과 외부 CI로 계속 갈 수 있는 팀이 있고, 반대로 merge queue나 branch protection, Actions가 막히면 코드가 있어도 출하를 못 하는 팀이 있다.
2~3월의 다른 장애들도 같은 그림을 보여준다. 2월 9일에는 인증·사용자 관리 쪽 데이터베이스 과부하가 광범위한 서비스 저하로 번졌고, GitHub는 세밀한 로드 셰딩 스위치가 부족했다고 인정했다.2 3월 5일에는 Actions 오케스트레이션 쪽 Redis 구성 문제로 워크플로 시작 실패와 대기열 적체가 발생했다.3 즉, "GitHub가 다운됐나"보다 "우리 개발 흐름의 병목이 어디에 연결돼 있나"가 더 정확한 질문이다.
10분 만에 보는 우리 팀의 GitHub 의존성 점검
간단히 체크해보자. PR 리뷰는 GitHub 웹 UI에서만 가능한가. 필수 체크가 Actions 하나에만 묶여 있는가. 웹훅이 늦으면 배포 파이프라인이 아예 시작되지 않는가. 장애 공지 확인, 대응 기록, 핫픽스 승인까지 GitHub 이슈나 PR에만 의존하는가.
이 질문에 "그렇다"가 많을수록 위험은 커진다. 특히 하루 배포 횟수가 많거나, merge queue·branch protection·자동 배포를 강하게 엮어 둔 팀은 노출도가 높다. 반대로 배포 빈도가 낮고, 로컬 빌드와 수동 릴리스가 가능하며, CI가 GitHub 밖에도 있으면 같은 장애 뉴스가 실제 운영 리스크로 이어지지 않을 수 있다.
여기서 반론도 필요하다. 장애 건수가 많다고 해서 모든 팀이 즉시 GitHub를 떠나야 하는 것은 아니다. 서드파티 집계 기준으로 최근 90일간 GitHub incident 수가 적지 않았고,4 비판적인 해석도 존재한다.5 하지만 incident count는 체감 리스크의 대리 지표일 뿐이다. 경미한 UI 이상과 핵심 배포 차단을 같은 무게로 볼 수는 없다. 중요한 건 빈도보다 "업무 중단 비용"이다.
헤드라인보다 중요한 것: 부러지지 않는 워크플로 만들기
GitHub도 현재 방향을 분명히 했다. 불필요한 작업 감소, 캐싱 개선, 핵심 서비스 분리, 단일 장애 지점 제거, Azure 및 장기적으로 멀티클라우드까지 추진하겠다고 밝혔다.1 이건 긍정적 신호다. 다만 이런 종류의 분산 시스템 개선은 효과가 크지만 시간이 걸린다. 당장 사용자 입장에서 필요한 건 기다림보다 완충 장치다.
과한 이중화까지는 아니어도, 몇 가지는 현실적이다. 핵심 저장소는 미러를 두고, Actions 장애 시 최소 빌드·테스트를 돌릴 대체 CI 경로를 정해 두는 것. 웹훅이 밀려도 수동으로 배포를 시작할 수 있는 브레이크글라스 절차를 문서화하는 것. 의존 패키지와 아티팩트는 가능한 한 캐시하거나 내부 레지스트리로 완충하는 것. 그리고 status page 확인, 배포 중지 기준, 수동 승인 절차를 포함한 "GitHub 장애 시 운영 룰"을 짧게라도 정해 두는 것이다.12
핵심은 공포가 아니라 비례감이다. 스타트업의 소규모 팀이 모든 것을 이중화할 필요는 없다. 하지만 고빈도 배포 팀, 규제 산업, 대형 모노레포 운영 조직, 그리고 GitHub Actions와 merge queue에 깊게 묶인 팀은 이제 신뢰성을 벤더 평가 항목이 아니라 내부 아키텍처 항목으로 봐야 한다. GitHub의 안정성이 아니라, GitHub가 흔들릴 때 우리 팀이 어디서 멈추는지가 판단 기준이다.
참고
2Addressing GitHub's recent availability issues
3GitHub availability report: March 2026
4Is GitHub Down? Check current status and user reports | IsDown
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.