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

 (eblog.fly.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 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와 유사 서비스의 낭비와 무능은 단순한 나쁜 제품이 아니라 소프트웨어에 대한 범죄라는 결론으로 이어짐

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • Trac과 Sourcehut도 이 비교에 포함되면 좋겠음

  • AI 에이전트 버튼 4개는 웃기고, 글에 나온 상대적 수치도 흥미롭지만 GitHub를 옹호하려는 건 전혀 아님에도 글의 세부 내용 일부는 맥락이 부족해서 저자의 논지를 뒷받침하기엔 충분하지 않아 보임
    유휴 메모리 사용량은 GitHub가 Codeberg보다 더 많은 일을 한다는 신호일 수 있지만, 48GB RAM 컴퓨터에서의 절대 RAM 사용량을 Apollo 유도 컴퓨터와 비교해 유의미한 결론을 내리긴 어려움
    축소된 JavaScript 번들을 포매팅해서 코드 줄 수를 추정하고, 의존성을 제외한 Zig 프로젝트의 줄 수와 비교하는 것도 사과와 오렌지 비교임. Zig 실행 파일을 역컴파일해서 몇 줄이 나오는지 보라는 얘기
    Codeberg가 “요청 수를 줄이기 위해 JavaScript와 CSS 페이로드를 합쳐야 한다”는 권고도 이해가 안 됨. HTTP 요청의 “추가 오버헤드”를 말하는 걸 보면 저자가 HTTP/2를 알고 있는지도 의문
    웹 페이지 성능에 대해 더 할 말은 많지만 별도 글로 남기겠고, 비슷한 주제에 대해 더 나은 관점으로는 Danluu의 2017년 웹 비대화 글을 다시 읽어보길 추천함: https://danluu.com/web-bloat

  • 저자가 보고 있다면 Casey Muratori와 Uncle Bob 논쟁을 살펴보면 좋겠음. 전자가 매우 흥미로운 성능 저하를 찾아냈음
    “참을 수 없어서 Chrome 성능 캡처를 봤고, 범인이 누군지 알게 됐다 :) ‘emoji picker’였다!”
    “코드는 대충만 봤지만, 문제는 문자를 입력할 때마다 ‘emoji picker’가 뒤로 거슬러 올라가 방금 입력한 게 이모지인지 검사하는 것으로 보인다”
    으악. 다만 이 경우 범인은 GitHub 프런트엔드 코드가 아니라 Chromium 기반 브라우저일 수도 있겠음

  • “Codeberg는 독립 기부에 의존하고 자유 자원봉사자들이 제공하는 제품”이라는 표현은 정확하지 않음
    Codeberg는 회원에 의존함. 회비뿐 아니라 정책 면에서도 그렇고, 현재 회비만으로는 정규직 직원을 고용하기엔 부족해서 자원봉사에 크게 기대지만, 이해하기로는 계약자도 있음
    Codeberg를 깊게 따라가진 않았지만(sourcehut 쪽을 선호함), 협동조합이라는 점이 가치 제안의 핵심 중 하나임. 지출도 투명하게 공개하려고 노력함. 예: https://blog.codeberg.org/codebergs-budget-of-2026.html
    Codeberg를 사용 중이라면 지금 회원 가입을 고려해보면 좋겠음: https://join.codeberg.org/

  • GitHub는 정말 싫음. 내 문제는 가동 시간이 아니라, 말도 안 되게 느리고 메모리를 많이 먹는다는 점임. “이 크기의 diff는 기본으로 보여주지 않습니다”라니 진심인가
    합리적인 개발 흐름에도 망가져 있음. PR을 리베이스하면 리뷰 피드백과 댓글이 사라지고, 커밋을 squash하면 리뷰 피드백과 댓글도 사라짐
    특정 댓글로 가는 링크가 있어도 해당 커밋이 사라지면 댓글도 같이 사라짐 \o/
    버그 수정이 있으면 PR을 만들라고 하고, 그 버그가 다른 변경으로 고쳐졌어도 PR과 버그가 같은 레벨에 존재하니 죽은 PR이 리뷰 큐에 영원히 남음
    이 커밋이 어떤 버그를 고쳤는지 알고 싶어도 PR 이력만 보여줌. 버그가 아니라 PR을 보라는 식이고, 버그를 알고 싶으면 직접 버그를 찾아야 함

    • “pull request”라는 개념 자체는 git과 마찬가지로 Linux 커널 개발에서 왔음. 커널 메인테이너에게 패치를 mainline으로 “pull”해 달라고 요청하는 흐름임
      GitHub는 이 흐름을 “fork” 버튼으로 더 편하게 만들고, 중앙화된 사용자명을 도입해 더 “소셜”하게 만든 뒤, 이슈 추적기와 위키를 붙여 세상을 장악했음. 사업적으로는 천재적이었던 게 맞음
      하지만 전체 흐름은 여전히 서로 떨어져 있는 사람들이 패치를 “pull”해 달라고 요청하는 오픈소스 개발에 맞춰져 있음
      실제 메커니즘이 “브랜치를 논의하고 병합을 승인한다”인 긴밀한 개발팀이 왜 “pull request”를 써야 하는지 이해가 안 됨. 무엇으로부터 pull한다는 건가? 같은 저장소에 있고, 이미 변경을 push했는데
      용어 문제를 빼더라도 누적 변경, 안정적인 댓글, 변경 집합 diff가 부족한 건 말이 안 됨
      또 지루한 GitHub 불평을 올려서 미안함. 더 나은 대안이 있나? 물론 누구도 쓰게 만들 수는 없겠지만…

  • “축 라벨이나 개별 데이터 포인트가 없는 그래프는 언제나 의심스럽다”는 반응을 GitHub가 공개한 그래프에 대해 몇 번 봤음
    그래프에 최댓값은 표시되어 있으니, y축 중간값이 각각 45M, 0.7B, 10M 정도라고 시각적으로 추정할 수 있음. 물론 몰래 로그 스케일이고 부하가 100000배가 된 게 아니라면
    여기서 나쁜 그래프를 “수상하다”고까지 부르진 않겠고, 그냥 커뮤니케이션이 서툴다고 봄. 개인적으로는 원시 ggplot 출력이 늘 더 좋음
    전반적인 정서에는 동의하지만, 뚱뚱한 말과 많은 표 부분에서 살짝 따라가기 어려웠음. 다만 GitHub의 모든 결함을 목록화하고 있었다면 나도 미쳐서 뚱뚱한 말을 타고 석양 속으로 사라지는 꿈을 꾸기 시작했을 듯함
    나도 비슷하게 목록화를 시작했다가 UX/성능 문제가 12개쯤 됐을 때 포기했음. 이 글의 철저한 분석은 좋고, GitHub 팀이 제대로 뜯어보길 바람
    이전에 말했듯 Microsoft는 GitHub에 성능 엔지니어를 일부 배정해야 함. 핵심 성과 지표에 성능 지표가 실제로 들어가기 전까지 이 비대화는 계속될 것이고 다른 플랫폼이 더 매력적으로 보일 것임. 다음 GitHub CEO가 생긴다면 이걸 우선순위로 두길 바람

    • 그래프의 y축이 0에서 시작한다고 가정하고 있음. 이런 비즈니스식 그래프에서는 그렇지 않은 경우가 아주 많음
      “엄청난 성장”을 주장하면서 그래프 선은 전체 그림 영역을 대각선으로 가로지르지만, y축은 100에서 101까지만 가는 식이 흔함

  • “GitHub Actions 로그가 메모리를 누수해서 여러 해 동안 내 브라우저를 죽였고, stdout을 어딘가로 그냥 pipe할 방법도 아직 없다”는 말에 동의함
    아쉽게도 Forgejo도 이걸 물려받았음. 실패한 빌드 알림을 받고 휴대폰에서 빨리 보려 할 때가 있는데, 상당수 경우 휴대폰 브라우저가 출력 내용을 아예 못 불러옴

  • 이 글을 눌렀을 때 GitHub 가동 시간에 대한 또 다른 불평일 거라고 완전히 예상했는데, 결과적으로 GitHub, GitLab, Codeberg의 현재 문제를 차분하고 합리적으로 평가하고 해결책까지 제안한 글이라 기분 좋게 놀랐음
    Tangled도 비교에 포함되면 좋겠음
    저자는 사이트가 모바일에서도 읽히도록 CSS를 좀 작성해주면 좋겠음. 브라우저 읽기 모드를 써야 했음
    동의하지 않는 유일한 부분은 어떤 사이트도 JavaScript/CSS 파일을 하나 넘게 가져서는 안 된다는 주장임
    그 55만 줄 JavaScript가 모두 한 파일이면 파싱과 실행에 훨씬 더 오래 걸릴 것임. CSS는 번들링해도 되겠지만, 예를 들어 공통 청크 하나와 경로별 청크 하나를 두는 패턴은 유용할 수 있음. 이런 접근이나 비슷한 방식은 널리 쓰일 것 같음

  • 이 페이지는 읽을 수가 없음
    그리고 GitHub가 싫다면 안 쓰면 됨. 사람들이 이렇게 긴 불평 목록을 모을 시간이 있다는 게 놀라움. 돈 받고 쓰는 것이거나, 아니면 다른 걸 쓰면 됨

답변달기
GeekBots 가 이제 오픈소스 기반 사내 협업도구 Mattermost 도 지원합니다. 긱뉴스를 사용중인 팀 채널에서 받아보세요.