해커 뉴스에서 303개의 추천. 가동률과 서비스 수준 협약(SLA)에 관한 게시물치고는, 이 숫자는 현대 소프트웨어 인프라의 현주소에 대해 불편한 무언가를 말해준다.
해당 게시물은 많은 개발자들이 수개월간 뼛속 깊이 느껴왔던 것을 상세히 다룬 더 레지스터(The Register)의 보도로 연결된다. 2억 개 이상의 저장소를 호스팅하고 지구상 사실상 모든 주요 소프트웨어 조직의 워크플로를 떠받치는 플랫폼인 GitHub가 99.9% 가용성을 유지하는 데 어려움을 겪고 있다는 것이다. 스리 나인(three nines). 기본선. 최소 기준. 마이크로소프트가 75억 달러를 들여 인수하고 엔터프라이즈급 안정성으로 운영하겠다고 약속한 플랫폼이 아니라, 중간 수준의 SaaS 제품에서나 기대할 법한 수치다.
더 레지스터가 보도한 GitHub의 장애 이력은 어떤 기업 메시지로도 무마할 수 없는 이야기를 들려준다. 반복되는 서비스 중단. 성능 저하 구간. 풀 리퀘스트가 허공에 갇히고. CI/CD 파이프라인이 실행 도중 멈춘다. 개인 개발자에게 이것은 성가신 일이다. 하지만 하루에 수천 건의 배포를 실행하는 조직에게는, 이것은 눈앞에 버젓이 놓인 존재적 위험이다.
"괜찮아 보이는 것"과 "실제로 아픈 것" 사이의 간극
숫자로 이야기해보자. 진짜 피해는 감당할 만해 보이는 것과 실제로 벌어지는 것 사이의 간극에 존재하기 때문이다.
스리 나인, 즉 99.9% 가용성은 연간 약 8.76시간의 다운타임으로 환산된다. 추상적으로는 감내할 만하게 들린다. 하지만 GitHub는 다운타임이 곧 피드를 스크롤할 수 없다는 뜻인 소비자용 앱이 아니다. GitHub는 현대 소프트웨어 개발의 중추 신경계다. GitHub가 다운되거나 심지어 성능이 저하되기만 해도, 그 파급 효과는 충격적이다.
개발자는 코드를 푸시할 수 없다. 자동화된 테스트는 실행할 수 없다. 배포가 중단된다. 보안 패치는 머지되지 못한 채 방치된다. 패키지 관리자가 GitHub 호스팅 저장소에서 패키지를 가져오기 때문에 의존성 해결이 실패한다. 많은 조직이 주요 CI/CD 플랫폼으로 채택한 GitHub Actions는 그냥 멈춘다.
참고로, 핵심 인프라에 대한 업계 기대치는 일반적으로 포 나인(99.99%, 연간 약 52분의 다운타임) 또는 파이브 나인(99.999%, 대략 5분)에 맞춰져 있다. AWS, Azure, Google Cloud는 모두 핵심 컴퓨팅 서비스에 대해 포 나인 이상의 SLA를 공시한다. GitHub — 바로 그 클라우드 인프라 자체의 코드 상당 부분이 구축되고 배포되는 플랫폼 — 은 스리 나인도 일관되게 충족하지 못하고 있다.
7년, 75억 달러, 그리고 끈질기게 미해결인 질문
마이크로소프트는 2018년 10월 GitHub 인수를 마무리했다. 제안은 단순명쾌했다: 마이크로소프트의 인프라 전문성과 탄탄한 자금력이 GitHub에 안정적으로 확장하는 데 필요한 기반을 제공하되, 개발자 문화는 보존하겠다는 것이었다. 7년이 지난 지금, 안정성에 대한 질문은 끈질기게 열려 있다.
이것은 마이크로소프트를 비난하려는 것이 아니다. Azure는 진정으로 유능한 클라우드 플랫폼이다. 마이크로소프트는 지구상에서 가장 까다로운 인프라 중 일부를 운영하고 있다 — Xbox Live, Microsoft 365, LinkedIn. 이 회사는 대규모 서비스를 안정적으로 운영하는 방법을 알고 있다. 그렇기에 GitHub의 지속적인 안정성 문제가 더욱 당혹스러운 것이다.
해커 뉴스의 인프라 엔지니어들 사이에서 돌고 있는 한 가지 이론은 아키텍처 부채를 지목한다. GitHub는 모놀리식 루비 온 레일즈(Ruby on Rails) 애플리케이션으로 구축되었다. 수년에 걸친 점진적 현대화에도 불구하고, 핵심 아키텍처는 여전히 보다 근본적인 재구축 없이는 진정한 고가용성을 달성하기 극히 어렵게 만드는 제약을 안고 있을 수 있다. 마이크로소프트는 서비스를 Azure로 이전하고 마이크로서비스 패턴을 채택하는 데 투자해왔지만, 이 정도 복잡성의 마이그레이션은 수년이 걸리며 — 수술이 진행되는 동안에도 플랫폼은 계속 운영되어야 한다.
또 다른 이론은 더 단순하고 더 불편하다: GitHub가 생태계 내 자신의 실제 중요성에 비해 안정성 엔지니어링에 충분한 투자를 하지 않고 있을 수 있다는 것이다. 이 플랫폼은 공격적으로 기능을 출시해왔다 — Copilot 통합, AI 기반 코드 리뷰, Actions 확장, 새로운 보안 스캐닝 도구. 각각이 엔지니어링 리소스를 소모하고 시스템 복잡성을 더한다. 기능 출시 속도와 안정성 투자 간의 균형이 전자 쪽으로 지나치게 기울었다면, 이 장애 패턴은 정확히 예측 가능한 결과다.
아무도 이름 붙이고 싶어 하지 않는 공급망 취약점
여기서부터 대화는 "GitHub에 약간의 가동 시간 문제가 있다"에서 훨씬 더 심각한 것으로 전환된다.
소프트웨어 산업은 수년간 공급망 보안에 대해 논해왔다. SolarWinds. Log4Shell. xz utils 백도어 공포. 정부는 행정 명령을 발표했다. SLSA와 SBOM 요구사항 같은 프레임워크가 등장했다. 기업들은 소프트웨어 공급망 보안에 수백만 달러를 쏟아부었다.
그러나 그 논의의 거의 전부가 무결성에 초점을 맞춰왔다 — 코드가 변조되지 않았는지 확인하는 것. 가용성에 초점을 맞춘 논의는 거의 없었다 — 코드를 호스팅하고 전달하는 인프라가 필요할 때 실제로 접근 가능한지 확인하는 것.
GitHub는 글로벌 소프트웨어 공급망의 거대한 부분에 대한 단일 장애점(single point of failure)이다. 소스 코드 호스팅뿐만이 아니다 — 패키지 배포, CI/CD, ID 및 접근 관리, Actions 마켓플레이스, 의존성 그래프, 보안 권고 데이터베이스까지.
GitHub가 다운되면 한 회사만 피해를 입는 것이 아니다. 수만 개의 회사가 피해를 입는다. 2026년 GitHub 장애의 폭발 반경은 2016년이었다면 가능했을 것과 범주적으로 다르다. 바로 이 플랫폼이 그토록 많은 인접 기능을 성공적으로 통합했기 때문이다.
더 레지스터의 보도를 둘러싼 해커 뉴스 토론에서, 여러 댓글 작성자들이 최근 GitHub 장애 시 연쇄적 실패(cascading failure)를 묘사했다. 의존성을 가져올 수 없었던 빌드 시스템. 타임아웃으로 서비스를 비일관된 상태로 남겨둔 배포 파이프라인. 수정하려면 접근 불가능한 플랫폼에 코드를 푸시해야 했기에 해결할 수 없는 장애로 호출된 당직 엔지니어들.
당연한 해답이 잔인할 만큼 비싼 이유
집중 리스크에 대한 자연스러운 대응은 다변화다. GitHub가 단일 장애점이라면, GitHub에만 의존하지 마라. 화이트보드 위에서는 충분히 간단하다. 실제로는 잔인하다.
GitLab이 있다. Bitbucket이 있다. 자체 호스팅 Gitea와 Forgejo 인스턴스가 있다. Git은 설계상 분산형이며, 어떤 개발자든 여러 리모트에 푸시할 수 있다. 하지만 실제로는 전환 비용이 막대하다. GitHub Actions 워크플로는 상당한 재작성 없이는 다른 플랫폼으로 이식되지 않는다. GitHub의 권한 모델, 통합 생태계, API 표면은 조직의 도구 체계 깊숙이 내장되어 있다. 그리고 네트워크 효과는 현실적이다: 오픈소스 프로젝트는 기여자가 GitHub에 있기 때문에 GitHub에 있고, 기여자는 프로젝트가 GitHub에 있기 때문에 GitHub에 있다.
일부 조직은 미러를 유지한다 — 핵심 저장소를 보조 호스팅 제공자에 자동으로 복제하는 것이다. 이것은 읽기 전용 안전망을 제공하지만 CI/CD나 협업 문제를 해결하지는 못한다. 미러에서는 풀 리퀘스트를 리뷰할 수 없다.
다른 조직은 더 급진적인 접근법을 취해, 처음부터 GitHub를 멀티플랫폼 전략의 하나의 노드로 취급한다. 하지만 이것은 대부분의 엔지니어링 조직이 감당할 준비가 되어 있지 않은 실질적인 운영 복잡성과 비용을 추가한다.
결과는 일종의 학습된 무력감이다. 모두가 집중 리스크가 존재한다는 것을 안다. 아무도 그것을 완화하는 대가를 치르고 싶어 하지 않는다. 그래서 개발자들은 GitHub가 다시 온라인이 될 때까지 기다리고, 소셜 미디어에서 불평하고, 다시 업무로 돌아간다.
해커 뉴스 스레드가 드러내는 것
303포인트 토론은 의견뿐만 아니라 데이터 포인트 때문에 읽을 가치가 있다 — 다양한 규모의 조직 소속 엔지니어들이 직접 경험을 보고하고 있다. 일부는 GitHub를 옹호하며 자신들의 가용성 수치가 더 나쁘다고 말한다. 다른 이들은 GitHub 자체 상태 페이지보다 더 상세한 그림을 그려주는 구체적인 장애 타임라인을 공유한다.
한 스레드가 특히 눈에 띈다. 한 댓글 작성자가 지적하기를, GitHub의 상태 페이지는 완전한 장애 대신 "성능 저하(degraded performance)"를 표시하는 경우가 많으며, 이는 원시 가용성 수치가 사용자 경험 관점에서 문제를 실제보다 과소평가하고 있을 수 있다는 것이다. 기술적으로는 "가동 중"이지만 API 호출에 평소의 10배 지연 시간으로 응답하는 서비스는, 합리적인 타임아웃 설정을 가진 모든 자동화 시스템에게 사실상 다운된 것이다.
이 구분은 중요하다. "HTTP 엔드포인트가 200을 반환하는가?"로 측정한 스리 나인과 "개발자가 실제로 업무를 수행할 수 있는가?"로 측정한 스리 나인은 매우 다르다. 기능적 가용성 — 실제로 중요한 수치 — 은 GitHub가 내부적으로 추적하는 어떤 지표보다 상당히 나쁠 수 있다.
실행해야 할 네 가지
해결책은 단순하지 않으며, 그렇다고 말하는 사람은 뭔가를 팔려는 것이다.
투명성. GitHub는 상태 페이지와 정기적인 장애 보고서를 발행하고 있지만, 업계는 더 세분화되고 독립적으로 검증 가능한 가용성 데이터가 필요하다. GitHub가 핵심 인프라라면 — 그리고 맞다 — 핵심 인프라 수준의 보고 기준을 적용받아야 한다.
투자. 마이크로소프트는 GitHub가 안정성도 필요한 기능 출시 플랫폼인지, 기능도 출시하는 안정성 최우선 플랫폼인지 결정해야 한다. 외부에서 보이는 신호는 전자를 시사한다. 장애 패턴은 후자를 요구한다.
조직적 성찰. 업계는 집중 리스크에 대한 구체적인 대화가 필요하다. 추상적인 정책 보고서가 아니라 — "화요일에 GitHub가 4시간 동안 접근 불가능하면 우리 조직은 어떻게 하는가?"에 대한 실용적 답변이 필요하다. GitHub 가용성을 전제로 하는 재해 복구 계획은 재해 복구 계획이 아니다.
페더레이션. 오픈소스 커뮤니티는 코드 호스팅을 위한 상호운용성 표준에 더 적극적으로 투자해야 한다. 포지(forge) 간 페더레이션을 가능케 하는 것을 목표로 하는 ForgeFed 같은 프로젝트는 더 많은 관심과 자금을 받을 자격이 있다. 집중 리스크에 대한 답은 반드시 GitHub를 버리는 것이 아니다. GitHub만이 유일하게 실행 가능한 선택지가 아니도록 보장하는 것이다.
업계가 들여다봐야 할 거울
월스트리트는 수십 년 전에 단일 장애점 문제를 해결했다. 1990년대와 2000년대의 일련의 위기 이후, 금융 규제 당국은 핵심 인프라에 대한 이중화 및 복원력 요구사항을 의무화했다. 거래 시스템은 장애 조치(failover) 능력을 갖춰야 한다. 청산소(clearing house)는 다중 데이터 센터를 유지한다. 단일 벤더의 장애로 시장이 멈출 수 없다.
소프트웨어 산업에는 이에 상응하는 프레임워크가 없다. 당신의 배포 파이프라인에 장애 조치 계획이 있는지 묻는 규제 기관은 없다. 핵심 개발 인프라가 포 나인 가용성을 유지하도록 요구하는 표준도 없다. 결과는 개발자 경험과 기능 출시 속도에는 탁월하게 최적화하면서 안정성과 복원력은 남의 문제로 취급해온 산업이다.
GitHub의 스리 나인 고군분투는 단지 GitHub만의 문제가 아니다. 그것은 그 리스크가 요구하는 이중화를 구축하지 않은 채 소수의 플랫폼에 비범한 리스크를 집중시켜 온 산업을 비추는 거울이다.
303명의 엔지니어가 그 해커 뉴스 게시물을 추천한 것은 자신들이 무엇을 보고 있는지 알아챘기 때문이다. 이제 문제는 그것을 고칠 힘을 가진 누군가가 주목하고 있느냐이다.
