소프트웨어에 대한 범죄: GitHub 인프라 붕괴 분석

현대 소프트웨어 개발 환경은 거의 GitHub와 동의어라고 할 수 있습니다. 많은 개발자에게 GitHub 프로필은 전문성을 입증하기 위한 전제 조건입니다. 하지만 세계에서 가장 인기 있는 코드 호스팅 서비스의 깔끔한 인터페이스 아래에는 인프라 붕괴가 점점 심화되고 있습니다. 서비스가 전 세계 소프트웨어 생산의 중추 신경계가 될 때, 그 신뢰성과 성능은 더 이상 단순한 "사용자 경험" 문제가 아니라 시스템적 위험이 됩니다.

최근 발생한 장애와 성능 저하는 종종 "에이전트 기반 개발 워크플로우"의 성장통으로 일축됩니다. 그러나 면밀히 살펴보면 현재 GitHub의 상태는 성장의 우연이 아니라 화려한 AI 기능을 기본적인 엔지니어링 우수성보다 우선시하는 의도적인 우선순위의 결과임을 알 수 있습니다.

AI 우선순위 역설

Microsoft와 GitHub는 "AI Agents"와 Copilot을 플랫폼 구석구석에 공격적으로 밀어넣었습니다. 일반적인 저장소 랜딩 페이지에서는 화면 한 사분면에 네 개에 달하는 AI 버튼이 배치되어 있습니다. 이 추진은 단순한 UX 선택이 아니라 자원 소모입니다.

GitHub는 최근 가용성 문제를 에이전트 기반 워크플로우의 급속한 가속 때문이라고 설명했습니다. 그러나 이 "부하"는 바로 그들의 전략이 만든 직접적인 결과입니다. 채택을 촉진하기 위해 이러한 도구들을 보조금 형태로 제공함으로써, GitHub는 사실상 자체 인프라에 대한 분산 서비스 거부(DDoS) 공격을 자금 지원한 셈입니다.

Microsoft가 "가용성 우선, 그 다음 용량, 그 다음 새로운 기능"이라고 주장하지만, 데이터는 그와 반대임을 보여줍니다. 30일 동안 GitHub 공개 변경 로그를 검토한 결과, 우선순위가 크게 차이 나는 것을 확인했습니다:

Copilot 언급: 59
Agent 언급: 8
Performance 언급: 0
Reliability 언급: 0

부피 측정: 비교 실험

기술적 붕괴 정도를 이해하기 위해, GitHub와 GitLab, Codeberg(Forgejo)의 프런트엔드 자원 사용량을 비교하는 실험을 진행했습니다. 목표는 실제 세계 제약을 시뮬레이션하기 위해 제한된 "Fast 3G" 연결을 사용해 세 서비스 모두에서 최소한의 동일 저장소를 렌더링하는 비용을 측정하는 것이었습니다.

메모리 및 힙 사용량

활성 처리 없이 정상 상태에 머물러도 RAM 소비량은 충격적입니다. PlayStation 2가 3D 그래픽을 렌더링하기 위해 전체 32 MiB RAM을 사용했지만, 현대 웹 프런트엔드 코드 호스팅은 텍스트를 표시하는 데만도 훨씬 더 많은 메모리를 소모합니다.

서비스	정상 상태 힙 사용량
Codeberg	~14 MiB
GitLab	~68 MiB
GitHub	~69 MiB

실제 콘텐츠를 로드하면 낭비는 더욱 가중됩니다. 높은 활동성을 보이는 페이지(예: Rust 언어 풀 리퀘스트)의 힙 스냅샷은 148 MiB가 넘는 급증을 보여주었으며, 이는 원래 iPhone이 가지고 있던 메모리보다 많아 단순히 링크 목록을 렌더링하는 데도 이런 메모리가 필요했습니다.

네트워크 페이로드 및 코드 양

맞춤형 분석 도구(anhar)를 사용해 빈 저장소에 대한 네트워크 요청을 해부했습니다. 결과는 클라이언트에 전달되는 코드 양에 엄청난 격차가 있음을 보여줍니다.

GitHub: 약 300개의 파일을 로드하며 총 ~550,000줄의 코드와 데이터를 포함합니다. 이를 비교하면 원래 DOOM (35k 줄)이나 전체 MS-DOS 4.0 운영체제 (332k 줄)를 만드는 데 필요한 코드보다 더 많습니다.
GitLab: 약 70개의 파일(약 10,000줄)에서 ~7 MiB를 가져옵니다.
Codeberg: 약 11개의 파일(약 1,100줄)에서 ~1 MiB를 가져옵니다.

GitHub가 청크 처리를 위해 Webpack에 의존하면서 수백 개의 독립 HTTP 요청이 필요하게 되어, 상당한 오버헤드가 발생하고 "Time to Interactive"이 허용할 수 없을 정도로 느려집니다. 일부 테스트에서는 제한된 연결에서 빈 페이지가 완전히 로드되는 데 21초가 넘었습니다.

인프라의 “Enshittification”

"enshittification"이라는 일반적인 이론이 있습니다. 제품이 처음에는 사용자에게, 그 다음에는 비즈니스 고객에게, 마지막에는 자체 주주에게만 서비스를 제공하게 되는 과정입니다. 하지만 GitHub의 붕괴는 다르게 느껴집니다. 부피는 사용자만 해치는 것이 아니라 Microsoft까지 해칩니다. Microsoft는 대역폭 비용과 낡은 코드베이스를 유지하기 위한 엔지니어링 시간을 지불합니다.

이는 단순한 기술 부채가 아니라 전문성의 실패입니다. 플랫폼의 프런트엔드가 이 정도 비효율적이라면, 중요한 질문이 떠오릅니다: "식당"(프런트엔드)이 이렇게 방치된다면, "주방"(백엔드 및 데이터베이스 아키텍처)은 어떤 모습일까요?

커뮤니티 관점 및 대안

개발자 커뮤니티의 반응은 엇갈립니다. 일부 사용자는 GitHub의 규모가 어느 정도 비효율성을 정당화한다며 만족해하지만, 다른 이들은 상황을 인식하고 더 가벼운 대안으로 이동하고 있습니다.

"그 강아지를 내 tailnet에 올리고 Gitea를 설치했으며, 모든 프로젝트에 독점적으로 사용하고 있어요. 자유를 느낍니다." — @jodacola

다른 사람들은 실제 "잠금"은 코드가 아니라 사회적 자본, 즉 GitHub 스타라고 경고합니다. @ashishb가 지적했듯이, 스타는 프로젝트 중요성의 통화 역할을 하며, 가짜 스타를 판매하는 서비스가 존재함으로써 소프트웨어 품질 신호가 더욱 왜곡됩니다.

등급 요약

서비스	등급	평결
Codeberg	C+	기본이 유망하지만 압축 및 최소화가 부족합니다.
GitLab	D+	과도한 사용되지 않은 JS/CSS와 열악한 가비지 컬렉션으로 어려움을 겪고 있습니다.
GitHub	F	우스꽝스럽게 과부하; 기본 성능보다 AI 프롬프트를 우선시합니다.

결론

소프트웨어는 사용자를 위한 문제 해결을 목표로 합니다. 우리가 세계 소프트웨어를 구축하는 데 사용하는 도구가 낭비와 무능의 사례가 된다면, 이는 단순히 나쁜 제품이 아니라 매체에 대한 범죄입니다. 현재 산업이 AI 기반 "에이전트"에 집착함으로써 부식의 피드백 루프가 형성되고, AI가 생성한 코드와 AI가 유발한 부하가 이를 호스팅하는 플랫폼 자체를 악화시키고 있습니다. 앞으로 나아가기 위해서는 효율성, 신뢰성, 그리고 사용자의 자원을 존중하는 기본으로 돌아가야 합니다.