GitHub 장애가 드러낸 무거운 인프라

제목 : GitHub 장애와 무거워진 개발 인프라를 다시 봐야 하는 이유

개발자라면 GitHub이 느려지거나 장애가 났을 때 일이 멈춰본 경험이 있을 거예요.
이번 참고 글은 단순한 “GitHub가 또 다운됐다”가 아니라, 현대 소프트웨어 인프라가 왜 점점 무거워지고 불안정해지는가를 짚고 있어요.

1. GitHub 신뢰성 논란의 핵심

글의 출발점은 GitHub의 반복적인 장애와 성능 저하예요.
저자는 GitHub가 개발 생태계의 핵심 인프라인 만큼, 단순 웹서비스보다 훨씬 높은 안정성을 가져야 한다고 봅니다.

문제는 장애가 한두 번이 아니라는 점이에요. GitHub의 공식 상태 페이지에는 매달 많은 incident(장애/이슈)가 올라오고, 저자는 실제 체감 장애는 그보다 더 많을 수 있다고 주장합니다.

특히 공식 상태 페이지는 약 99.8% 수준의 가용성을 보여주지만, 비공식적으로 모은 데이터에서는 87%대 가용성처럼 보이는 사례도 언급돼요. 이 차이는 개발자 입장에서 매우 중요합니다. CI/CD, 코드 리뷰, 배포 자동화가 GitHub에 묶여 있다면 GitHub 장애는 곧 팀 전체 생산성 저하로 이어지기 때문이에요.

2. AI 기능 우선순위가 만든 부하

저자는 GitHub와 Microsoft가 Copilot, Agent 같은 AI 기능을 강하게 밀면서 서비스 부하를 스스로 키웠다고 봅니다.
즉, “AI 워크플로가 갑자기 늘었다”는 설명만으로는 부족하다는 거예요.

GitHub 저장소 화면에는 여러 개의 AI 버튼이 노출되고, 사용자는 자연스럽게 agentic workflow(AI 에이전트 기반 작업 흐름)를 실행하게 됩니다. 이런 기능은 pull request, 검색, 알림, 권한, webhook, Actions, 데이터베이스 등 여러 시스템을 동시에 건드려요.

저자는 GitHub의 최근 변경 로그도 근거로 들었어요. 한 달 동안 copilot은 59회, agent는 8회 언급됐지만, performance와 reliability는 0회였다는 점입니다. 이 부분은 플랫폼이 실제로 무엇을 우선순위로 두는지를 보여주는 신호로 해석할 수 있어요.

3. 프론트엔드 성능 비교 실험

이 글의 가장 흥미로운 부분은 GitHub, GitLab, Codeberg를 직접 비교한 실험이에요.
저자는 빈 저장소 하나를 만들고, 동일한 조건에서 각 서비스의 네트워크 요청, 로딩 시간, 메모리 사용량을 측정했습니다.

실험 조건도 꽤 현실적입니다. Firefox에서 캐시를 끄고, 네트워크를 Fast 3G로 제한했어요. 저장소 랜딩 페이지, Pull Request, Issue, Settings 페이지를 대상으로 HAR(HTTP Archive), heap snapshot(메모리 사용량), 압축 지원 여부를 확인했습니다.

결과는 꽤 충격적이에요. GitHub는 빈 저장소 페이지에서도 수백 개 요청과 수십 MiB 수준의 리소스를 내려받았고, 확장 기준으로 약 55만 줄 규모의 코드/데이터가 로드된 것으로 분석됐습니다. 반면 Codeberg는 약 1MiB 수준으로 훨씬 가벼웠고, 메모리 사용량도 GitHub·GitLab보다 낮았습니다.

4. GitHub, GitLab, Codeberg 결과 요약

비교 결과에서 GitHub는 가장 무겁고, GitLab도 가볍지 않으며, Codeberg는 기본기는 좋지만 개선 여지가 있는 서비스로 평가됐어요.
각 플랫폼의 장단점은 실제 도구 선택에도 참고할 만합니다.

• GitHub
  빈 저장소에서도 약 300개 파일, 수십 MiB 리소스, 약 69MiB heap을 사용한 것으로 나타났어요. 저자는 등급을 F로 평가하며, 사용자는 가능하면 의존도를 낮추고 SLA 위반 시 지원 티켓을 검토하라고 조언합니다.

• GitLab
  GitHub보다는 낫지만 약 7~8MiB 리소스, 68MiB heap, 12초대 로드 시간이 관측됐습니다. 자체 기능은 강력하지만, GitLab 전용 기능에 과하게 묶이면 migration(이전)이 어려워질 수 있어요.

• Codeberg
  약 1MiB 리소스, 14MiB heap, 3초대 로딩으로 가장 가벼운 편이었습니다. 다만 gzip/zstd 압축 미지원은 아쉬운 부분이며, 독립 후원 기반 서비스라는 점에서 업무용으로는 백업 전략이 필요합니다.

5. 개발팀이 얻을 수 있는 실전 교훈

이 글은 특정 서비스 비판을 넘어, 우리 팀의 웹서비스에도 적용할 수 있는 성능 점검 체크리스트를 제공합니다.
특히 개발자 도구만으로도 많은 문제를 빠르게 확인할 수 있다는 점이 중요해요.

실제로 팀에서 다음 시나리오를 해볼 수 있습니다. 핵심 페이지를 열고 브라우저 개발자 도구에서 Network 탭을 확인한 뒤, 요청 수와 전송량을 기록해보세요. 그다음 Performance 또는 Memory 탭에서 초기 렌더링 시간과 heap 사용량을 비교하면 됩니다.

점검 포인트는 단순합니다.

• 불필요한 JavaScript/CSS 제거
  쓰지 않는 코드가 많을수록 로딩, 파싱, 실행 비용이 모두 증가합니다.

• 요청 수 줄이기
  작은 파일이 수백 개로 쪼개져 있으면 네트워크 오버헤드가 커집니다.

• 압축 적용 확인
  gzip, 가능하다면 zstd를 적용하면 HTML/CSS/JS 전송량을 크게 줄일 수 있어요.

마무리하며

GitHub는 여전히 개발자 생태계의 중심이지만, 그만큼 성능과 안정성에 대한 기대치도 높아야 합니다.
AI 기능이 늘어나는 것 자체가 문제는 아니지만, 기본적인 속도와 신뢰성을 희생한다면 개발자 경험은 빠르게 나빠질 수밖에 없어요.

우리도 사용하는 도구를 당연하게 믿기보다, 장애 대응 계획과 대체 저장소 전략을 고민해볼 필요가 있습니다. 동시에 내가 만드는 서비스 역시 “기능 추가”보다 빠르고 안정적인 기본기를 먼저 지키고 있는지 점검해보면 좋겠습니다.