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

Efron Licht의 소프트웨어 기사

2026년 5월

Abraham Lincoln

이 글을 시작하며, GitHub가 또다시 다운되었습니다. Verge의 기사와 같이 GitHub의 신뢰성(reliability), 보안(security), 성능(performance) 문제에 대해 다룬 많은 기사가 있었지만, 그것들은 단지 표면을 긁는 수준에 불과합니다. GitHub는 GitHub 자체와 빅테크(big tech) 소프트웨어 서비스 전반에서 나타나는 인프라 쇠퇴(infrastructural decay)의 일종의 '신호' 역할을 합니다. AWS에서 Google Search에 이르기까지 거의 모든 빅테크 기업 서비스에서 유사한 쇠퇴를 지적할 수 있겠지만, GitHub는 소프트웨어 개발과 거의 동의어로 쓰이기 때문에 매우 눈에 띄는 사례가 됩니다. 저는 2022년에 한 채용 담당자와 나눈 대화가 기억납니다. 그들은 제가 GitHub 계정이 없다는 이유만으로 제가 '진정한 프로그래머'라는 사실을 믿지 않았습니다.

GitHub가 지향해야 하는 모습, 즉 고성능(high-performance), 고가용성(high-availability), 고용량(high-capacity) 분산 시스템(distributed system)은 저의 개인적인 전문 분야이기에, 일반적인 기술 기자들보다 이 문제에 대해 조금 더 깊은 통찰력을 제공할 수 있습니다.

단순히 가용성(availability)만의 문제가 아닙니다. GitHub는 문제로 가득 차 있습니다. 여기에는 다음과 같은 문제들이 포함되지만 이에 국한되지는 않습니다 (굵은 글씨 부분은 증명될 것입니다).

2026-05-29에 자동 생성됨

GitHub의 공식 상태 페이지(status page)는 약 99.8%의 업타임(uptime)을 주장하지만, 최근에 사용해 본 사람이라면 실제 수치에는 '9'가 하나도 없다는 것을 알고 있습니다. 'missing github status page'와 같은 사이트들은 실제 상황이 어떤지를 잘 보여줍니다.

GitHub는 최근 자신들이 곤경에 처해 있다는 것을 잘 알고 있으며, 비판을 피하기 위해 몇몇 보도 자료(press releases)를 내놓았습니다. 지난달, GitHub는 이러한 비판 중 일부를 해결하기 위해 'GitHub 가용성에 관한 업데이트(an update on github availability)'라는 제목의 보도 자료를 발표했습니다.

Microsoft:

주된 동인은 소프트웨어가 구축되는 방식의 급격한 변화입니다. 2025년 12월 하반기 이후, 에이전트 기반 개발 워크플로우 (agentic development workflows)가 급격히 가속화되었습니다. 거의 모든 지표를 통해 그 방향은 이미 명확합니다. 저장소 (repository) 생성, 풀 리퀘스트 (pull request) 활동, API 사용, 자동화, 그리고 대규모 저장소 워크로드 (large-repository workloads)가 모두 빠르게 성장하고 있습니다.

라벨이 없는 축이나 개별 데이터 포인트가 없는 그래프가 항상 의심의 대상이라는 사실을 넘어, “에이전트 기반 개발 워크플로우가 급격히 가속화되었다”라고 말하면서 수동태를 사용하는 것은 믿기 힘들 정도로 기만적입니다. 마치 이것이 GitHub의 인지나 동의 없이 몰래 찾아온 무언가인 것처럼 말입니다. GitHub은 Microsoft의 소유이며, 이 회사는 AI, 혹은 “에이전트 (agents)”든 간에 수만 가지의 중첩된 방식으로 모든 개별 제품에 이를 밀어넣어 왔습니다. 거의 모든 GitHub 페이지의 핫바 (hotbar)에는 세 개의 서로 다른 AI 버튼이 있으며, 그중 두 개는 전적으로 에이전트를 시작하는 데 할당되어 있습니다. 어떤 페이지는 네 개나 있습니다.

남성은 자신의 행동이 가져올 자연스러운 결과를 의도하며, 자신의 행위가 촉진하는 것처럼 보이는 것을 추구한다고 현명하게 추정된다.

찰스 섬너(Charles Sumner), “캔자스에 대한 범죄 (The Crime Against Kansas)”

GitHub과 Microsoft는 모든 상황에서 사용자들에게 “AI”와 “에이전트 (Agents)”를 사용하도록 끊임없이 압박하고 있습니다.

그들이 당신이 이 도구들을 사용하기를 얼마나 간절히 원하는지는 아무리 강조해도 지나치지 않습니다. 일반적인 저장소 랜딩 페이지의 우측 상단 4분의 1 구역 내에서만 Copilot을 실행하는 방법이 한 가지, 두 가지, 세 가지가 아니라 네 가지나 됩니다. 네 가지입니다.

(이 글을 쓰는 동안, 저는 모든 페이지에 세 번째 에이전트 버튼이 있다는 사실을 발견했습니다. 에이전트를 명시적으로 비활성화하지 않은 프로젝트 저장소의 경우, 네 번째 버튼이 나타납니다. 이것은 병적인 상태입니다.)

나아가, GitHub은 수년간 도입을 유도하기 위해 이러한 도구들의 사용 비용을 보조해 왔으며, 이는 사실상 자기 자신을 대상으로 분산 서비스 거부 (DDoS) 공격을 수행하는 비용을 지불한 것과 다름없습니다.

Microsoft:

이러한 기하급수적인 성장은 한 번에 하나의 시스템만을 압박하지 않습니다. 하나의 풀 리퀘스트 (Pull Request)는 Git 저장소, 병합 가능성 확인 (mergeability checks), 브랜치 보호 (branch protection), GitHub Actions, 검색, 알림, 권한, 웹후크 (webhooks), API, 백그라운드 작업, 캐시, 그리고 데이터베이스에 영향을 미칠 수 있습니다. 대규모 환경에서는 작은 비효율성이 복리로 작용합니다. 대기열 (queues)은 깊어지고, 캐시 미스 (cache misses)는 데이터베이스 부하로 이어지며, 인덱스 (indexes)는 뒤처지고, 재시도 (retries)는 트래픽을 증폭시키며, 하나의 느린 종속성 (dependency)이 여러 제품 경험에 영향을 줄 수 있습니다.

GitHub의 데이터베이스 엔지니어들은 쉬운 일을 하고 있는 것이 아닙니다. 이는 정당한 도전 과제이며, 저 자신이라도 고전했을 과제입니다. 하지만 GitHub는 작은 비효율성을 가진 것이 아니라, 거대하고 경악스러운 비효율성을 가지고 있으며, 이에 대해서는 나중에 자세히 다루겠습니다.

Microsoft:

우리의 우선순위는 명확합니다: 가용성 (availability)이 최우선이며, 그다음은 용량 (capacity), 그리고 새로운 기능 (new features)입니다.

이것은 거짓말입니다. GitHub — 그리고 더 넓게는 Microsoft 조직 전체 — 는 근본적인 신뢰성 (reliability)보다 화려한 AI 기능들을 명백히 우선시합니다. GitHub에는 공개된 변경 로그 (changelog)가 있습니다. 그들이 업데이트를 게시한 후 30일 동안, 패치 노트에는 “copilot”이라는 단어가 59번, “agent”가 8번 등장한 반면, “performance”는 0번, “reliability”는 0번 등장했습니다. 변경 로그에는 카테고리별 필터 기능이 있습니다: copilot은 그 자체로 하나의 카테고리이며, 성능(performance)과 신뢰성(reliability)은 아예 존재하지도 않습니다.

이는 단지 GitHub 자체에만 국한된 것이 아니라, 조직 전체에 만연해 있습니다. Microsoft가 소유한 Visual Studio Code는 세계에서 가장 인기 있는 IDE (통합 개발 환경/코드 에디터)이며, GitHub 및 그 “에이전트적 (agentic)” 기능들과 직접 통합되어 있습니다. 내장 터미널과 같은 기본적인 기능들이 거의 사용할 수 없을 정도로 저하되고 있음에도 불구하고, 점점 더 많은 기능들이 억지로 밀어 넣어지고 있습니다. 오늘 아침 두 번째 초안 작업을 위해 VS Code를 열었을 때, Visual Studio Code는 완전히 새로운 “에이전트 창 (agent window)”이 포함된 업데이트를 푸시했습니다.

Microsoft는 또한 패치 노트에 “주요 수정 사항 (notable fixes)” 섹션을 포함시켰지만, 그곳은 비어 있습니다.

저는 눈이 먼 것이 아닙니다. 저는 인간입니다. 제 신발에 오줌을 싸놓고 비가 온다고 말하지 마십시오.

Microsoft:

우리는 불필요한 작업을 줄이고, 캐싱 (caching)을 개선하며, 핵심 서비스를 격리하고, 단일 장애점 (single points of failure)을 제거하며, 성능에 민감한 경로를 이러한 워크로드에 최적화된 시스템으로 이동시키고 있습니다. 이것은 분산 시스템 (distributed systems) 작업입니다. 즉, 숨겨진 결합 (hidden coupling)을 줄이고, 폭발 반경 (blast radius)을 제한하며, 하나의 하위 시스템이 압박을 받을 때 GitHub가 우아하게 성능 저하 (degrade gracefully)를 일으키도록 만드는 것입니다. 우리는 빠르게 진전을 보이고 있지만, 이러한 사고들은 여전히 해야 할 일이 남아 있음을 보여주는 사례들입니다.

이는 시스템 설계가 잘못되었다는 인정입니다. 성능은 소프트웨어 아키텍처 (software architecture)의 결과물입니다. 뼈대가 튼튼하다면 성능 문제는 발생하는 대로 고칠 수 있지만, 뼈대가 잘못되었다면 그 어떤 편법 (hacks)으로도 충분하지 않으며 처음부터 다시 시작해야 합니다. GitHub의 신뢰성 문제의 근원은 백엔드 (back-end)와 데이터베이스 (databases) 내부에 있으며, 이는 우리에게 숨겨져 있습니다. 하지만 우리는 그들의 프론트엔드 (front-end) 코드, 즉 제가 웹사이트를 방문할 때마다 제 컴퓨터나 휴대폰으로 다운로드되는 HTML, JavaScript, CSS는 볼 수 있습니다. GitHub의 기술적 역량을 파악하기 위해 이 코드를 조사해 봅시다. 만약 피자 가게 식당에 쥐가 수십 마리 보인다면, 이론적으로 주방은 깨끗할 수도 있겠지만, 주인이 하는 말을 믿는다면 바보일 것입니다. 이와 유사하게, GitHub 프론트엔드의 명백한 부패는 백엔드의 더 큰 문제들을 (증명하지는 않더라도) 암시합니다.

다음 섹션에서는 GitHub의 프론트엔드 코드를 실험적으로 살펴봄으로써 그 부패를 입증하고, 이를 상업적 경쟁사인 gitlab 및 무료 대안인 codeberg와 직접 비교해 보겠습니다. (다른 서비스들도 많습니다. 여러분도 직접 이 실험을 반복해 보시길 권장합니다!)

github의 프론트엔드 코드는 엉망진창입니다: github, gitlab, codeberg의 비교

어떤 코드든 판단하기 전에, 먼저 그 코드가 무엇을 하려고 하는지 알아야 합니다. GitHub의 프론트엔드(front-end) 페이지 대부분과 경쟁사들의 페이지는 본질적으로 약간의 UX 요소(버튼, 탭)와 검색창이 포함된 링크 목록에 불과합니다. 인터랙티브 미디어(interactive media)나 이미지와 같이 비용이 많이 드는 요소는 매우 적습니다.

다음 스크린샷에서 볼 수 있듯이, 이 서비스들은 (정상적으로 작동할 때) 기본적으로 모두 동일하게 보이고 기능합니다.

Codeberg와 GitLab 모두 사용자에게 익숙한 경험을 제공하기 위해 의도적으로 GitHub의 UX를 모방했으므로, 이는 놀라운 일이 아닙니다.

이러한 페이지들은 조금이라도 괜찮은 인터넷 연결이 있는 거의 모든 컴퓨터나 휴대폰에서 저렴하고 쉽게 실행될 수 있어야 합니다. 실제로 GitHub은 과거에 그렇게 할 수 있었습니다. 저는 제 첫 스마트폰인 iPhone 4의 3G 연결을 통해 GitHub을 사용했던 것을 분명히 기억합니다.

이 서비스들이 동일한 기능을 제공한다고 가정할 때 — 적어도 제가 사용하는 부분들에 있어서는 기능 세트(feature sets)가 동일합니다 — '최고의' 코드란 가장 적은 자원(네트워크 대역폭(network bandwidth), CPU 및 클록 시간(clock time), RAM))을 사용하고 버그(bug)가 가장 적은 코드일 것입니다. GitHub의 프론트엔드에 버그가 얼마나 있는지 알 수는 없지만, 역사적 연구에 따르면 버그의 수는 일반적으로 코드 라인 수에 비례하는 것으로 나타났습니다. Microsoft의 말을 인용하자면 다음과 같습니다:

배포된 소프트웨어의 경우 업계 평균 경험치는 코드 1,000라인당 약 1~25개의 오류입니다. 소프트웨어는 대개 여러 가지 기술이 뒤섞인 방식으로 개발되었습니다 (Boehm 1981, Gremillion 1984, Yourdon 1989a, Jones 1998, Jones 2000, Weber 2003). 이보다 오류가 10분의 1 수준인 경우는 드뭅니다. 오류가 10배 더 많은 경우는 보고되지 않는 경향이 있습니다. (아마 완성조차 되지 못했을 것입니다!)

Microsoft의 Applications Division는 사내 테스트 중에 1,000줄의 코드당 약 10~20개의 결함(defects)을 경험하며, 출시된 제품에서는 1,000줄의 코드당 0.5개의 결함을 경험합니다 (Moore 1992). 이 수준을 달성하기 위해 사용된 기술은 '기타 협업 개발 관행 (Other Kinds of Collaborative Development Practices)'에서 설명된 코드 읽기 기술과 독립적인 테스트 (independent testing)의 조합입니다.

GitHub의 릴리스 프로세스가 90년대 초반 Microsoft의 엄격한 테스트와 유사할 것이라고는 강력히 의심스럽지만, 여기서는 관대하게 1,000줄당 1개의 결함이라고 가정해 봅시다.

이러한 프론트엔드(front-ends)의 비용을 파악하고 잠재적인 버그를 추정하기 위한 실험을 설계해 봅시다.

모든 좋은 실험과 마찬가지로, 우리는 혼란 변수 (confounding variables)를 최소화하고자 할 것입니다.

재미 삼아 제 개인 웹사이트를 목록에 추가하겠습니다. 당연히 제가 하는 일은 GitHub와 같지 않으므로, 이것이 큰 의미를 갖지는 않습니다.

ghsucks

단일 브랜치 (master), 파일 (README.md), 그리고 이슈(issues), 태그(tags) 또는 기타 불필요한 요소(cruft)가 전혀 없는 상태입니다. (github, gitlab, codeberg). testcompress는 제가 이것을 위해 작성한 작은 프로그램입니다. anhar는 제가 이것을 위해 작성한 작은 프로그램입니다. 사이트들의 결론이 우리의 결론과 일치하는지 확인하기 위해 pagespeed.web.dev를 사용하여 사이트들을 분석할 것입니다. 제2의 의견 (second opinion)을 갖는 것은 언제나 좋습니다. 이 프론트엔드 코드를 비교하기 위해 할 수 있는 일은 훨씬 더 많습니다. 이 실험의 좋은 확장 방식은 프로파일러 (profiler)를 파헤쳐 어떤 코드 세그먼트가 실제로 실행되는지, 얼마나 자주 실행되는지, 무엇이 화면의 초기 페인트 (initial paint)를 차단하는지, 페인트하는 데 가장 오래 걸리는 것은 무엇인지 등을 찾아내는 것입니다. 저는 이미 이 글에 너무 많은 시간을 소비했으므로, 이것을 독자(또는 더 좋게는 이 서비스들을 실제로 유지 관리하는 개발자들)의 과제로 남겨두겠습니다.

1#!/usr/bin/env bash
2 3# create the repo...
4mkdir ghsucks
...

github, gitlab, 그리고 codeberg

1#!/usr/bin/env bash
23git remote add github https://github.com/ef0xa/ghsucks && git push github master
4git remote add gitlab https://gitlab.com/efronlicht/ghsucks && git push gitlab master
...

안타깝게도, 이것은 쉽게 자동화되지 않습니다. 제가 사용한 (수동) 알고리즘과 예시는 다음과 같습니다.

iPhone 4

2012년 (제가 처음 github를 사용했을 때 가지고 있던 휴대폰)입니다.

har

디스크로 아카이브(archive)

힙 스냅샷 (heap snapshots)을 수집하는 것 또한 제가 알기로는 쉽게 자동화할 수 있어 유용합니다. 이전과 마찬가지로, 이번에는 Firefox의 내장 프로파일링 도구 (profiling tool)를 사용하며, "메모리 (memory)" 탭 아래에서 힙 스냅샷을 찍으면 됩니다: