GitHub는 얼마나 무거운가 — 빈 저장소 한 개를 보기 위해 22초를 기다리는 이유

GitHub은 빈 저장소 한 개를 보기 위해 22초, 50만 줄의 코드를 내려받는다 (출처: eblog.fly.dev)

GitHub는 얼마나 무거운가 — 빈 저장소 한 개를 보기 위해 22초를 기다리는 이유

최근 eblog.fly.dev에 올라온 글 "GitHub as a crime against software"가 화제입니다. 이 글은 단순한 GitHub 불만 글이 아닙니다. "최소한의 작업"을 하기 위해 GitHub 프런트엔드가 어떤 대가를 치르는지, 같은 일을 하는 GitLab, Codeberg와 비교했을 때 얼마나 낭비적인지를 정량 데이터로 풀어낸 분석 보고서입니다. 개발 인프라의 기본 신뢰성이 흔들리고 있다는 진단이며, 동시에 우리가 받아들인 도구에 대해 다시 생각하게 만드는 글입니다.

---

GitHub는 빈 저장소를 어떻게 보여주는가

작성자는 동일한 최소 저장소 ghsucks를 GitHub, GitLab, Codeberg에 각각 만들고 다음 네 페이지를 측정했습니다.

• 랜딩 페이지 (저장소 첫 화면)

• 풀 리퀘스트(또는 머지 리퀘스트) 페이지

• 이슈 페이지

• 설정 페이지

브라우저는 Firefox, 컴퓨터는 Apple MacBook Pro M5 Max 48GiB RAM, 네트워크는 의도적으로 fast 3G로 제한했습니다. 농촌 지역이나 열약한 네트워크에서 GitHub을 쓰는 상황을 시뮬레이션하기 위함입니다.

측정 결과: 압도적 차이

서비스	요청 수	축소 응답	확장 코드 줄 수	정상 힙
Codeberg/Forgejo	11개	1MiB	3,480줄	14MiB
GitLab	78개	8MiB	101,682줄	68MiB
GitHub	291개	15MiB	544,564줄	69MiB
eblog.fly.dev (정적 HTML)	5개	766KiB	3,800줄	11MiB

특히 충격적인 것은 rust-lang 풀 리퀘스트 페이지의 힙 사용량입니다. 148MiB. 오리지널 iPhone 메모리 128MiB보다 많습니다. 텍스트 위주 페이지치고는 도저히 합리화할 수 없는 숫자입니다.

GitHub은 빈 저장소 화면을 그리기 위해 544,564줄의 코드와 데이터를 내려받습니다. 비교를 위해 인용되는 숫자들이 압도적인데요. DOOM 35,000줄, Windows Quake 120,000줄, MS-DOS 4.0 332,000줄, Zig 툴체인 전체 460,000줄보다 많습니다. 빈 페이지를 보기 위해 22초를 기다려야 한다면, 1Gbps 광랜과 고성능 CPU를 가지고 있어도 저장소가 실제로 쓸 수 있는 상태가 되기까지 1초 이상 걸립니다.

왜 이렇게 무거운가 — 300개 파일, 50만 줄의 비밀

GitHub은 한 페이지를 그리기 위해 CSS 파일 40개와 JavaScript 수백 개를 각각의 HTTP 요청으로 가져옵니다. Webpack의 코드 스플리팅은 이론적으로 핵심 기능과 선택 기능을 분리해 캐싱과 CDN에 유리하도록 설계되었지만, 결과적으로 각 파일마다 독립 요청이 발생해 로드를 지연시킵니다.

게다가 GitHub은 사용자가 사용하지 않더라도 모든 테마를 모든 페이지에서 내려받습니다. PageSpeed Insights는 JavaScript와 CSS 528KiB가 완전히 사용되지 않는다고 지적합니다. 이 부분만 줄여도 절반은 가볍게 깎을 수 있다는 의미입니다.

우선순위의 문제 — AI vs 기본 신뢰성

이 글의 핵심 진단은 단순한 성능 비판이 아닙니다. 왜 이런 일이 벌어졌는가에 대한 답입니다.

Microsoft는 2025년 12월 이후 "agentic development workflows"가 급격히 가속되면서 부하가 폭증했다고 설명합니다. 하지만 GitHub은 그 agentic 부하를 스스로 만들어낸 측면이 있습니다.

• GitHub 거의 모든 페이지 상단 바에 AI 버튼이 3개, 그중 2개는 agent 시작 전용

• 일반 저장소 랜딩 페이지 오른쪽 위 영역에 Copilot 실행 경로가 4개

• GitHub은 수년간 도구 사용 비용을 보조해 Copilot 채택을 유도

• changelog 30일간 패치 노트에서 "copilot" 59회, "agent" 8회 등장 vs "performance"와 "reliability" 0회

availability first, then capacity, then new features라고 Microsoft가 공언했지만, 실제 changelog에는 copilot 카테고리만 따로 있고 performance/reliability 카테고리는 존재하지 않습니다. Visual Studio Code도 같은 흐름으로, 내장 터미널 같은 기본 기능이 악화되는 와중에도 agent 기능이 계속 추가되고 있습니다.

프런트엔드가 백엔드를 비추는 거울

이 글의 또 다른 좋은 비유는 "피자 가게 식당에 쥐가 보이면 주방이 깨끗할 가능성을 믿기 어렵다"는 것입니다. GitHub의 신뢰성 문제 뿌리는 백엔드와 데이터베이스에 있지만, 우리는 그 내부를 볼 수 없습니다. 우리가 매번 내려받는 HTML, JavaScript, CSS는 백엔드의 거울과도 같습니다. 눈에 보이는 프런트엔드의 부패는 백엔드의 문제를 시사하지만 증명하지는 못합니다. 다만 증거는 압도적입니다.

버그 수는 코드 줄 수에 비례한다는 역사적 연구(McConnell, _Code Complete_, 2004)에 따르면, GitHub의 50만 줄 코드는 추정 500개의 잠재 버그를 내포합니다.

대안은 무엇인가 — Codeberg, Forgejo, 그리고 eblog

글이 평가한 네 서비스의 등급은 다음과 같습니다.

• GitHub: F — 300개 파일, 55만 줄, gzip만 지원(zstd 미지원), 528KiB 미사용 코드

• GitLab: D+ — 70개 파일, 7MiB, 10만 줄, gzip만 지원, 3MiB 청크 파싱 255ms

• Codeberg/Forgejo: C+ — 11개 파일, 1MiB, 1,100줄, gzip/zstd 미지원, 자유 소프트웨어라 셀프호스팅 가능

• eblog.fly.dev: A- — 5개 파일, 766KiB, 3,800줄, gzip/zstd 모두 지원, 단일 HTML 페이지

Codeberg가 14MiB 힙으로 GitHub(69MiB)의 5분의 1이라는 사실, 그리고 자유 소프트웨어라서 다른 인스턴스로 이전할 수 있다는 사실은 무게 중심의 대안이 실제로 존재함을 보여줍니다. 다만 HTML minify 미적용과 압축 미지원이라는 작은 부주의가 아쉬운 점으로 남습니다.

우리가 받아들인 도구에 대해

이 글이 던지는 가장 본질적인 질문은 성능 최적화 자체가 아닙니다. "어떤 도구를 우리가 받아들였는가"입니다. GitHub은 소프트웨어 개발의 핵심 인프라이지만, 그 신뢰성과 성능은 사용자의 필요보다 AI 기능과 투자자 우선순위에 의해 결정되고 있습니다. 빈 저장소를 보기 위해 22초를 기다리는 일상을 우리는 너무 오래 묵묵히 받아들였습니다.

지금 할 수 있는 작은 실천은 명확합니다.

• Forgejo/Codeberg 셀프호스팅을 검토 — 자유 소프트웨어이며 이주 가능

• 대규모 풀 리퀘스트 페이지에서는 GitHub 모바일 웹이나 CLI로 우회

• Firefox/Safari에서의 깨짐을 본다면 Issue로 기록 — Microsoft가 performance 카테고리를 만들도록 압박

• Copilot을 쓰지 않더라도 GitHub의 비용을 보조하는 구조이므로, agentic 기능의 부하를 인식하고 가끔은 자제

기본 신뢰성을 우선하는 도구가 다시 표준이 되길 기대합니다. 그 시작은 우리가 어떤 도구를 어디에 쓰는지 의식적으로 선택하는 일입니다.

---

출처

• eblog.fly.dev 원문:

• GeekNews:

---

📚 출처

• https://news.hada.io/topic?id=30093