현대 소프트웨어 개발에서 GitHub는 단순한 코드 저장소가 아니다. CI/CD 파이프라인, 프로젝트 관리, 코드 리뷰, 패키지 레지스트리, 심지어 인증 시스템까지—개발 워크플로우의 거의 모든 것이 GitHub 위에 올라가 있다. 그런 GitHub의 가용성(availability)이 99.9%, 이른바 "three nines"에도 미치지 못하고 있다는 분석이 나왔다.
99.9%라는 숫자는 얼핏 높아 보이지만, 이는 한 달에 약 43분의 다운타임을 허용하는 수준이다. 엔터프라이즈 서비스에서 흔히 목표로 하는 99.99%(four nines, 월 4.3분)나 99.999%(five nines, 월 26초)와 비교하면 상당히 낮은 수치다. 그런데 GitHub는 이 99.9%마저 꾸준히 달성하지 못하고 있다는 것이 핵심 지적이다.
실제로 GitHub의 공식 상태 페이지를 살펴보면, 최근 몇 달간 크고 작은 인시던트가 반복적으로 발생하고 있다. Git 오퍼레이션 지연, Actions 실행 지연, API 오류 증가 등 다양한 형태의 장애가 보고되었다. 이 각각의 장애가 전 세계 수백만 개발팀의 배포 파이프라인, PR 리뷰, 이슈 트래킹에 직접적인 영향을 미친다는 점에서, 단순한 "잠깐 느려졌다" 수준의 문제가 아니다.
🔗 출처: Hacker News
가용성 숫자의 의미: 99.9%와 99.99%의 차이
가용성(availability)은 서비스가 정상적으로 동작하는 시간의 비율을 나타내는 지표다. "nines"라는 표현은 이 비율에서 9가 몇 개인지를 뜻한다. 차이를 체감하기 위해 연간 허용 다운타임으로 환산해보자.
- 99% (two nines): 연간 약 3.65일. 스타트업 초기 서비스 수준.
- 99.9% (three nines): 연간 약 8.76시간. 대부분의 SaaS가 목표로 하는 기본선.
- 99.99% (four nines): 연간 약 52.6분. AWS S3 같은 핵심 인프라가 목표로 하는 수준.
- 99.999% (five nines): 연간 약 5.26분. 통신사 핵심망이나 금융 결제 시스템 수준.
GitHub가 three nines를 놓치고 있다는 것은 곧 연간 8.76시간 이상의 장애가 발생하고 있다는 뜻이다. GitHub의 공식 상태 페이지 데이터를 보면 실제로 월별로 수시간의 degraded performance가 기록되어 있다. 문제는 GitHub가 단순 웹사이트가 아니라 개발 파이프라인의 핵심 경로(critical path)에 있는 서비스라는 점이다. GitHub Actions가 멈추면 배포가 멈추고, PR 머지가 안 되면 개발이 멈춘다. 단순한 "불편"이 아니라 비즈니스 연속성의 문제가 된다.
한 가지 공정하게 봐야 할 점도 있다. GitHub는 전 세계 1억 명 이상의 개발자가 사용하는 거대 서비스이며, 처리하는 트래픽 규모가 엄청나다. 이 정도 규모에서 높은 가용성을 유지하는 것 자체가 극도로 어려운 엔지니어링 도전이다. 그럼에도 Microsoft라는 모회사의 리소스를 감안하면, 사용자들의 기대치가 높아지는 것도 자연스럽다.
경쟁 환경과 대안, 그리고 현실
가용성 문제가 반복되면 당연히 대안에 대한 논의가 나온다. 현재 GitHub의 주요 대안은 GitLab과 Bitbucket이다.
GitLab은 셀프 호스팅이 가능하다는 것이 가장 큰 차별점이다. GitLab Self-Managed를 사용하면 가용성을 자체적으로 관리할 수 있다. 물론 이는 인프라 운영 부담을 직접 지게 된다는 뜻이기도 하다. GitLab.com(SaaS 버전) 역시 별도의 인프라에서 운영되지만, 가용성 측면에서 GitHub보다 월등히 낫다고 보기는 어렵다.
Bitbucket은 Atlassian 생태계(Jira, Confluence)와의 연동이 강점이지만, 오픈소스 커뮤니티에서의 존재감은 미미하다. Gitea는 경량 셀프 호스팅 솔루션으로 소규모 팀에 적합하지만, GitHub의 생태계(Actions 마켓플레이스, Copilot, 보안 기능 등)를 대체하기엔 역부족이다.
현실적으로 GitHub에서 이탈하는 것은 매우 어렵다. 코드 호스팅만 놓고 보면 Git은 분산 버전 관리 시스템이므로 리모트를 바꾸면 되지만, 문제는 GitHub 위에 구축된 나머지 모든 것이다. Issues에 축적된 프로젝트 히스토리, Actions에 정의된 CI/CD 워크플로우, Packages에 올라간 아티팩트, Projects로 관리하는 작업 현황—이 모든 것을 마이그레이션하는 비용은 코드 이전과는 차원이 다르다.
더 근본적인 문제는 네트워크 효과다. 오픈소스 프로젝트는 컨트리뷰터가 있는 곳에 있어야 하고, 컨트리뷰터는 이미 계정이 있는 플랫폼에서 기여한다. 이 선순환 구조가 GitHub의 가장 강력한 해자(moat)이며, 가용성이 다소 불안정하더라도 이탈이 쉽게 일어나지 않는 이유다.
실무에서 GitHub 의존도를 낮추는 방법
GitHub를 완전히 대체하는 것은 비현실적이더라도, 장애 발생 시 업무가 완전히 마비되지 않도록 의존도를 낮추는 것은 가능하다.
Git 미러링: 중요한 저장소는 GitLab이나 자체 Gitea 인스턴스에 미러링해둔다. Git 자체가 분산 시스템이므로 미러링은 비교적 간단하다. GitHub가 다운되어도 코드 접근은 유지할 수 있다.
CI/CD 다각화: GitHub Actions에 모든 CI/CD를 올인하지 말고, 핵심 배포 파이프라인은 독립적인 CI 시스템(Jenkins, GitLab CI, CircleCI 등)에 두는 것을 고려해볼 수 있다. 최소한 프로덕션 배포만이라도 GitHub 장애에 영향받지 않는 경로를 확보해두면 장애 상황에서의 대응이 훨씬 수월해진다.
로컬 워크플로우 강화: PR이 머지가 안 될 때 개발 자체가 멈추는 구조라면, 로컬에서의 개발-테스트 사이클을 더 강화하는 것이 도움이 된다. 로컬에서 충분히 검증할 수 있는 테스트 환경을 갖추면, GitHub가 잠깐 다운되어도 개발자 개개인의 생산성은 유지된다.
여러분의 팀에서 GitHub에 장애가 발생하면 어떤 일이 벌어지는가? 단순히 PR 리뷰가 밀리는 수준인가, 아니면 배포가 완전히 중단되는가? 그 답에 따라 GitHub 의존도 관리의 우선순위가 달라질 것이다.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공
