GitHub와 소프트웨어에 대한 범죄

• GitHub는 개발 인프라의 핵심처럼 쓰이지만, 잦은 인시던트·느린 페이지·브라우저 깨짐 때문에 기본 신뢰성이 흔들린다는 평가를 받음
• Microsoft는 agentic workflows로 부하가 급증했다고 밝혔지만, GitHub와 Copilot·agent 기능을 직접 밀어 넣어 사용을 유도했다는 비판도 커짐
• 최소 저장소 실험에서 GitHub는 291개 요청과 축소 응답 15MiB, 확장 544,564줄을 내려받아 Codeberg의 11개 요청과 크게 대비됨
• 프런트엔드 측정에서 GitHub는 정상 힙 약 69MiB, rust-lang pull 요청 페이지는 148MiB를 써 텍스트 중심 페이지치고 과도하게 낭비적이라는 평가를 받음
• 결론은 GitHub의 낭비가 단순한 제품 악화가 아니라, 사용자 문제 해결보다 AI 기능과 투자자 중심 우선순위를 앞세운 소프트웨어 실패라는 것임

GitHub의 신뢰성과 우선순위

• GitHub는 소프트웨어 개발 인프라의 핵심처럼 쓰이지만, 다운타임·성능 저하·브라우저 호환성 문제로 기본 신뢰성을 의심받음
• GitHub Status 기록에는 매달 수십 건의 인시던트가 있으며, 공식 상태 페이지와 SLA 기준에서도 위반으로 볼 만한 상황이 있음
• Firefox와 Safari에서 자주 깨지고, pull request 댓글·리뷰 페이지가 느리며, RAM 사용량과 힙 스파이크가 과도하게 나타난다는 비판을 받음
• GitHub Actions는 느리고 문서화가 부족하며, 로그 화면은 여러 해 동안 메모리 누수와 브라우저 크래시를 일으킨 것으로 제시됨
• setup-go 같은 기본 액션의 캐시 동작도 무효화가 없거나 지나치게 단순하다는 평가를 받음
• githubstars.com처럼 스타 구매를 공개 광고하는 사이트가 있고, Carnegie Mellon 논문의 “fake stars are highly related to malicious activities” 문구도 인용됨
• GitHub가 지향해야 할 대상은 고성능·고가용성·고용량 분산 시스템이지만, 실제 제품은 기본 신뢰성보다 AI 기능과 에이전트 흐름을 우선하는 것으로 평가됨

“Agentic” 부하와 Microsoft의 책임

• GitHub는 ‘an update on github availability’에서 2025년 12월 하반기 이후 agentic development workflows가 급격히 가속됐고, 저장소 생성·pull request 활동·API 사용·자동화·대형 저장소 워크로드가 빠르게 증가했다고 밝힘
• 이 설명은 부하 증가를 외부 현상처럼 다루지만, GitHub와 모회사 Microsoft가 AI와 “agents”를 여러 제품에 밀어 넣어 직접 사용을 유도했다는 비판으로 이어짐
  • GitHub의 거의 모든 페이지 상단 바에는 AI 버튼이 3개 있고, 그중 2개는 agent 시작 전용이며, 많은 페이지에는 4개가 있음
  • 일반 저장소 랜딩 페이지의 오른쪽 위 영역에는 Copilot을 실행하는 방법이 4개 있음
  • GitHub는 수년간 도구 사용 비용을 보조해 채택을 유도했고, 이는 스스로에게 분산 서비스 거부를 비용 지원한 것과 같다는 비판 링크가 제시됨
• Microsoft는 pull request 하나가 Git 저장소, 병합 가능성 검사, branch protection, GitHub Actions, 검색, 알림, 권한, webhooks, APIs, 백그라운드 작업, 캐시, 데이터베이스를 건드릴 수 있다고 설명함
• 고규모에서는 작은 비효율도 큐 심화·캐시 미스·DB 부하·인덱스 지연·재시도 트래픽 증폭으로 이어질 수 있지만, GitHub의 비효율은 “작은” 수준이 아니라 거대하고 압도적이라는 평가를 받음
• Microsoft는 “availability first, then capacity, then new features”라고 밝혔지만, GitHub 공개 changelog에서 해당 업데이트 이후 30일간 패치 노트에 “copilot”은 59회, “agent”는 8회 등장하고 “performance”와 “reliability”는 0회 등장함
  • changelog 필터에는 copilot 카테고리가 따로 있지만 performance와 reliability 카테고리는 없음
  • Visual Studio Code도 GitHub 및 “agentic” 기능과 직접 통합되어 있고, 내장 터미널 같은 기본 기능이 악화되는 와중에도 agent 기능이 추가된다는 비판을 받음
• Microsoft가 “unnecessary work” 축소, 캐싱 개선, 중요 서비스 격리, 단일 장애점 제거, 성능 민감 경로 이전, 숨은 결합도 축소, 폭발 반경 제한, graceful degradation을 진행한다고 밝힌 대목은 시스템 설계가 잘못됐다는 인정으로 해석됨

프런트엔드가 백엔드 문제를 암시하는 이유

• GitHub의 신뢰성 문제의 뿌리는 백엔드와 데이터베이스에 있지만 외부에서는 볼 수 없고, 대신 매번 내려받는 HTML·JavaScript·CSS 같은 프런트엔드 코드를 관찰할 수 있음
• 피자 가게 식당에 쥐가 보이면 주방이 깨끗할 가능성을 믿기 어렵듯, GitHub 프런트엔드의 눈에 띄는 부패는 백엔드 문제를 시사하지만 증명하지는 못한다고 봄
• GitHub, GitLab, Codeberg 저장소 랜딩 페이지는 링크 목록, 작은 UX 요소, 버튼, 탭, 검색창으로 구성되며, 인터랙티브 미디어나 이미지처럼 비싼 요소가 거의 없음
• 이런 페이지는 좋은 인터넷 연결이 아니어도 거의 모든 컴퓨터나 휴대전화에서 저렴하게 실행되어야 하며, GitHub는 과거 iPhone 4와 3G 연결에서도 실제로 그렇게 동작했다고 제시됨
• 기능이 동일하다면 가장 좋은 코드는 네트워크 대역폭, CPU 시간, RAM을 가장 적게 쓰고 버그가 가장 적은 코드로 정의됨
• 프런트엔드 버그 수를 직접 알 수는 없지만, 역사적 연구에서는 버그 수가 보통 코드 줄 수에 비례한다고 제시됨
  • Steve McConnel, Code Complete, 2nd Ed (2004)는 납품 소프트웨어의 업계 평균 오류가 코드 1000줄당 1~25개라고 인용됨
  • Microsoft Applications Division은 내부 테스트 중 코드 1000줄당 10~20개 결함, 출시 제품에서는 1000줄당 0.5개 결함을 경험했다고 인용됨

실험 설계와 수집 방식

• 혼란 변수를 줄이기 위해 인터넷 속도를 “fast 3G” 연결로 제한함
  • 네트워크 조건 변동의 영향을 줄이고, 농촌 지역 같은 덜 이상적인 상황의 GitHub 고객 경험을 시뮬레이션하기 위한 설정임
• 세 서비스 모두 동일한 최소 저장소 ghsucks를 사용함
  • 단일 브랜치 master
  • 단일 파일 README.md
  • 이슈·태그 등 부가 요소 0개
• 같은 브라우저와 같은 컴퓨터를 사용함
  • Firefox
  • Apple Macbook Pro M5 Max
  • 48GiB RAM
• 각 서비스에서 네 가지 페이지를 조사함
  • “landing” 페이지: 코드 레이아웃
  • “pull requests” 또는 “merge requests” 페이지
  • “issues” 페이지
  • “settings” 페이지
• 깨끗한 캐시 상태로 HTTP Archive(HAR)를 수집해 네트워크 요청을 분석하고, 로딩 완료 뒤 힙 스냅샷을 수집해 정상 상태 RAM 사용량 추정치를 얻음
• HAR 분석에는 직접 작성한 anhar, 압축 지원 분석에는 testcompress, 교차 확인에는 pagespeed.web.dev를 사용함

힙 사용량과 메모리 낭비

• 기본 저장소 페이지의 힙 사용량은 GitHub 69MiB, GitLab 68MiB, Codeberg 14MiB, eblog.fly.dev 1.3MiB로 측정됨
• https://github.com/rust-lang/rust/pulls의 첫 이슈 페이지 렌더링에는 148MiB RAM이 사용됨
• 148MiB는 원래 iPhone보다 많은 메모리이며, 링크 몇 개가 있는 텍스트 중심 페이지치고는 극심한 낭비로 평가됨
• 비교 대상으로 제시된 기기 메모리는 Apple iphone 1 128MiB, iphone 4 512MiB, Sony playstation 2 32MiB, Nintendo wii 88MiB 등임

요청량과 응답 규모 비교

• anhar는 HAR JSON을 파싱하고, 응답의 HTML·CSS·JavaScript를 deno fmt로 자동 포맷한 뒤 요청·응답 크기, MIME별 합계, 로드 시간, 응답 라인 수를 계산하는 Go 프로그램임
• 주요 지표는 요청 크기, 실제 수신한 축소 응답 크기, deno fmt 적용 뒤 확장 응답 크기와 줄 수, 기본 HTML 로드 시간인 Content-Load, 모든 콘텐츠 로드 시간인 Load임
• Codeberg 저장소 페이지는 전체 기준 11개 요청, 요청 9KiB, 응답 1MiB, 확장 응답 1MiB, 확장 3,480줄, Content-Load 2.934s, Load 3.172s로 측정됨
• GitHub 저장소 페이지는 291개 요청, 요청 178KiB, 축소 응답 15MiB, 확장 응답 22MiB, 확장 544,564줄, Content-Load 843ms, Load 21.330s로 측정됨
  • application/javascript: 214개 요청, 응답 12MiB, 확장 응답 19MiB, 확장 481,849줄
  • text/css: 42개 요청, 응답 2MiB, 확장 60,016줄
  • GitHub pulls: 266개 요청, 축소 14MiB, 확장 20MiB, 확장 487,922줄, Content-Load 592ms, Load 6.754s
  • GitHub settings: 255개 요청, 축소 14MiB, 확장 20MiB, 확장 486,067줄, Content-Load 778ms, Load 6.963s
• GitLab은 GitHub보다 작지만 여전히 무거움
  • GitLab 저장소: 78개 요청, 응답 8MiB, 확장 101,682줄, Content-Load 6.880s, Load 12.941s
  • GitLab merge_requests: 65개 요청, 응답 7MiB, 확장 90,567줄, Content-Load 6.947s, Load 12.096s
  • GitLab edit: 117개 요청, 응답 7MiB, 확장 71,916줄, Content-Load 6.964s, Load 13.302s
• GitHub는 빈 저장소 표시에도 약 540K줄의 코드와 데이터를 가져오며, 이는 DOOM 35K줄, Windows Quake 120K줄, MS-DOS 4.0 332K줄, Zig toolchain 460K줄보다 많다는 비교가 나옴
• 개별 페이지가 CSS 파일 40개와 JavaScript 수백 개를 가져오는 구조가 문제로 평가됨
• Webpack의 청크 분할은 이론적으로 핵심 기능과 선택 기능을 나누고 캐싱·CDN에 유리할 수 있지만, 여기서는 각 파일마다 독립 HTTP 요청이 필요해 로드를 늦추는 결과로 해석됨
• 빈 페이지를 보기 위해 22초를 기다리는 것은 용납하기 어렵고, 1GiB/s 이상 광랜과 고성능 소비자용 프로세서에서도 저장소가 어느 정도 사용 가능해지기까지 1초 이상 걸린다고 평가됨

압축 지원 비교

• 압축은 클라이언트·서버·중간 경로의 부하를 낮추는 유용한 방법으로 제시됨
• gzip은 검증된 압축 표준이며 모든 웹사이트가 지원해야 하고, zstd는 성능 특성이 좋지만 더 현대적인 방식이라 지원은 “있으면 좋은” 수준으로 취급됨
• testcompress는 URL이 gzip과 zstd 압축을 지원하는지 테스트하고, 지원하지 않으면 응답 본문을 직접 압축해 잠재 절감량을 보여주는 Go 프로그램임
• eblog.fly.dev/startingsystems3.html: 지원 인코딩 zstd gzip, 원본 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
• github.com/ef0xa/ghsucks: 지원 인코딩 gzip, 원본 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
• gitlab.com/efronlicht/ghsucks: 지원 인코딩 gzip, 원본 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
• codeberg.org/efronlicht/ghsucks: 지원 인코딩 n/a, 원본 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

PageSpeed 모바일 결과

• pagespeed.web.dev 모바일 측정에서 Codeberg는 First Contentful Paint 1.2s, Largest Contentful Paint 1.3s, Interaction to Next Paint 86ms로 PASS를 받음
• eblog.fly.dev는 First Contentful Paint 1.1s, Largest Contentful Paint 1s, Interaction to Next Paint N/A로 PASS를 받음
• GitHub는 First Contentful Paint 1.8s, Largest Contentful Paint 2.1s, Interaction to Next Paint 242ms로 FAIL을 받음
• GitLab은 First Contentful Paint 2.1s, Largest Contentful Paint 2.4s, Interaction to Next Paint 243ms로 FAIL을 받음

서비스별 평가

• GitHub

  • 약 300개 파일, 코드와 데이터 약 550,000줄을 가져오며, 추정 버그 수는 550개로 제시됨
  • Content-Load는 약 800ms, 전체 Load는 약 7s, 정상 상태 힙은 약 69MiB로 요약됨
  • gzip은 지원하지만 zstd는 지원하지 않음
  • 평가는 F로, 코드 무게가 매우 크다는 평가를 받음
  • GitHub는 사용 여부와 관계없이 모든 페이지에서 모든 테마를 가져온다는 지적을 받음
  • pagespeed.web.dev가 JavaScript와 CSS 528KiB가 완전히 사용되지 않는다고 제시하므로 이 부분부터 줄일 수 있다고 봄
  • GitHub에 남아야 한다면 GitHub 자체 SLA를 위반하고 있다고 보고, 환불을 받기 위해 지원 티켓을 제출하라는 제안이 나옴

• GitLab

  • Content-Load는 약 7s, Load는 약 13s이며, 70개 파일 이상으로 7MiB, 약 10,000줄을 가져옴
  • 정상 상태 힙은 약 68MiB이고, gzip은 지원하지만 zstd는 지원하지 않음
  • 평가는 D+ 로, GitHub만큼 낭비적이지는 않지만 너무 많은 리소스를 가져오고 제대로 쓰지 못한다는 평가를 받음
  • JavaScript와 CSS를 1MiB 이상 가져오지만 실제로 전혀 사용되지 않는 부분이 있고, 사용되는 코드에도 3MiB 청크가 있어 파싱만 255ms 걸림
  • 랜딩 페이지에 CSS 55,000줄이 필요 없으며, CSS와 JavaScript 모두 현재의 10분의 1 수준으로 줄일 수 있을 것으로 판단됨

• Codeberg/Forgejo

  • Content-Load는 2.9s, Load는 3.1s이며, 11개 파일에 1MiB, 약 1,100줄을 가져옴
  • 정상 상태 힙은 약 14MiB이고, gzip과 zstd를 모두 지원하지 않음
  • 평가는 C+ 로, 기본기는 있지만 세부에 대한 주의와 경험이 부족하다는 평가를 받음
  • HTML minify를 하지 않는 점은 작은 문제지만, 압축을 지원하지 않는 점은 큰 누락으로 평가됨
  • JavaScript와 CSS 대부분은 페이지 렌더링에 필요 없지만, 렌더링을 막는 방식으로 로드되는 점이 문제로 제시됨
  • JavaScript와 CSS 페이로드를 합쳐 요청 수를 줄이고, HTML을 포함한 HTTP 페이로드에 gzip과 zstd 압축을 지원해야 한다는 제안이 나옴
  • 자유 소프트웨어이므로 다른 인스턴스나 셀프호스팅으로 이전할 수 있다는 점이 장점으로 제시됨

• eblog.fly.dev

  • eblog.fly.dev/startingsystems3.html은 Content-Load 76ms, Load 1.1s, 5개 파일 766KiB, 약 3,800줄로 측정됨
  • 단일 HTML 파일은 576KiB이고 zstd로 약 70KiB까지 압축됨
  • 정상 상태 힙은 약 11MiB이며, zstd와 gzip을 모두 지원함
  • 평가는 A- 로, 전반적으로 좋지만 HTML이 압축을 고려해도 비대하고 반복적이며, 한 번의 요청으로 끝낼 수 있는 페이지가 5개 요청을 필요로 한다는 평가를 받음

단순한 제품 악화가 아닌 비용 문제

• “enshittification”은 좋은 제품이 사용자와 비즈니스 고객에게 유리하게 출발한 뒤, 사용자에게 불리하게 바뀌고, 다시 비즈니스 고객에게도 불리하게 바뀌며 운영자에게 유리해지는 과정으로 요약됨
• Microsoft와 GitHub는 Embrace, Extend, Extinguish와도 무관하지 않지만, 여기서의 문제는 사용자와 비즈니스 고객뿐 아니라 Microsoft에도 비용을 만든다는 점에서 다르다고 봄
• 부풀어 오른 코드베이스는 서버·대역폭 비용을 직접 늘리고, 불안정하고 비대한 코드베이스를 유지하는 데 엔지니어 시간을 간접적으로 소모하게 만듦
• GitHub 엔지니어가 약 800명이고, 1명당 주 40시간·연 48주 근무한다고 가정하면 연 1,536,000 엔지니어-시간에 해당함
• 프런트엔드 문제 대부분은 pagespeed 권고를 따르기만 해도 유능한 엔지니어가 일주일 안에 고치거나 완화할 수 있다고 봄
• 저수준 개선은 비용을 절감할 수 있는데도 방치되는 이유는 무관심, 극단적 무능, 또는 AI와 투자자 중심 리더십에 막힌 상태 중 하나로 해석됨
• 소프트웨어는 한 번 올바르게 작성하면 완벽하게, 영원히, 무료로 복제해 모두가 사용할 수 있다는 점에서 강력하고 아름다운 도구로 묘사됨
• GitHub와 유사 서비스의 낭비와 무능은 단순한 나쁜 제품이 아니라 소프트웨어에 대한 범죄라는 결론으로 이어짐